|
| | Часть сообщений этой темы была выделена в тему "Защита Open Source от ненамеренной поддержки монополистов" (19 января 2007 22:57)
|
Павел Макаров
Member
Откуда: Санкт-Петербург Всего сообщений: 80
Ссылка
Дата регистрации на форуме: 2 сен. 2006 | Профиль | Email | Сообщить модератору
NEW! Сообщение отправлено: 20 января 2007 10:16 Сообщение отредактировано: 20 января 2007 10:34
Кто-то из великих сказал: "Политика - искусство компромисса" Данил, обрати внимание на Глагол (http://glagol.nad.ru/), и "оберонцы" eugrus & Р. Игнатов - твои сподвижники forever  P.S.: На всякий случай: да шучу я...  Теперь не шучу: динамическое связывание - популярный и широко распространённый приём. Но ведь основным его назначением является минимизация использования памяти, что сегодня во многих случаях проблемой уже не является, особенно для компактных приложений (к которым и следует стремиться - см. http://www.minix3.ru/articles/10kloc.pdf). Так не имеет ли смысл отказаться от представления о безусловной и первостепенной важности этого механизма? Не является ли портирование Equinox Desktop Environment (вместе со своей библиотекой eFLTK) неявным признаком предпочтения статического подхода динамическому со стороны Таненбаума сотоварищи? То есть: так ли уж критично "отсутствие пропитанных шпал", особенно на начальном этапе?
|
|
|
alv
Junior Member
Всего сообщений: 16
Ссылка
Дата регистрации на форуме: 6 янв. 2007 | Профиль | | Сообщить модератору
NEW! Сообщение отправлено: 20 января 2007 13:36
2 Павел Макаров
Приемлемость статической линковки очень зависит от назначения и масштабов.
Для встраиваемых приложений - это единственный метод.
И приемлем для маленьких пакетов - tar или gzip более-менее все равно, как линковать.
А теперь представим себе amarok или koffeine (или любое другое серьезное KDE-приложение), статически слинкованное со всем, что ему нужно для работы.
Не зря же даже разработчики FreeBSD отказались от статической линковки программ из /bin и /sbin, теперь статически линкуется только аварийный комплект утилит в отдельном каталоге /resque.
И разработчики PC-BSD не рискнули статически линковать свои pbi-пакеты.
Не говоря уже об удобстве.
Помните историю с критической ошибкой zlib? Все разработчики открытого софта перелинковали свои проги за считанные часы после сообщения.
А разработчики софта закрытого - расхлебывали эту кашу еще долго.
И все же приоритетность VFS для разработчиков мне кажется правильной.
Потому как ныне, если MINIX-машина не имеет флопа и сетевая не поддерживается (а не поддерживаются почти все современные сетевые), то она являет собой черный ящик, наладить связь которого с внешним миром - очень большой геморрой.
Кстати, непосредственно в данный момент лечением этого геморроя и занят. О результатах буду рапортовать по ходу дела.
|
|
|
Павел Макаров
Member
Откуда: Санкт-Петербург Всего сообщений: 80
Ссылка
Дата регистрации на форуме: 2 сен. 2006 | Профиль | Email | Сообщить модератору
NEW! Сообщение отправлено: 20 января 2007 15:14
alv написал: [q] Приемлемость статической линковки очень зависит от назначения и масштабов.
Для встраиваемых приложений - это единственный метод.
И приемлем для маленьких пакетов - tar или gzip более-менее все равно, как линковать.[/q]
Спасибо за моральную поддержку Именно на это я и намекал, говоря о компактных приложениях для MINIX 3 и о концепции 10kloc. Ясен палец, что для гигантских приложений типа OpenOffice "много памяти" не будет ещё очень долго... Меня лично MINIX 3 привлекает в том числе и компактностью (как самой ОС, так и ейных приложений). alv написал: [q] Не говоря уже об удобстве. Помните историю с критической ошибкой zlib? Все разработчики открытого софта перелинковали свои проги за считанные часы после сообщения. А разработчики софта закрытого - расхлебывали эту кашу еще долго.[/q]
Историю сию - виноват - не помню, но смею думать, что догадываюсь, о чём речь Однако каким образом динамическая или статическая линковка связаны с открытостью или закрытостью софта - не врубаюсь  Линковка - дело техники, а открытость - это только политика и/или жажда славы и денег. alv написал: [q] Кстати, непосредственно в данный момент лечением этого геморроя и занят.[/q]
Бог в помощь (без тени шутки), ибо ничем другим - увы - помочь в этом деле не могу.
|
|
|
alv
Junior Member
Всего сообщений: 16
Ссылка
Дата регистрации на форуме: 6 янв. 2007 | Профиль | | Сообщить модератору
NEW! Сообщение отправлено: 20 января 2007 15:35
2 Павел Макаров История с zlib - очень интересна и поучительна. Она произошла года 4 назад, по свежим следам, к сожалению, не описал, а нынче детали подзабыл, надо будет поднять тогдашние материалы. В двух словах суть такая: когда эта самая ошибка обнаружилась (а zlib было сто лет в обед, парень, что ее написал, вероятно, о не давно забыл, распространялась и распространяется она под лицензией BSD-стиля), оказалось, что она статически вкомпилена в бессчетное количество зарытых проприетарных программ. О чем все уже тоже благополучно забыли Ну и пошло веселье Кстати, тогда всякие пуристы от FSF начали говорить - вот какая BSD лицензия плохая, что такие штуки позволяет сделать. Хотя тут, ИМХО, дело не в лицензии, а в радиусе кривизны рук разработчиков производных программ...
|
|
|
Nobody
Junior Member
Всего сообщений: 4
Ссылка
Дата регистрации на форуме: 6 фев. 2007 | Профиль | | Сообщить модератору
NEW! Сообщение отправлено: 6 февраля 2007 18:21
Сори за потенциально тупую мысль, но всё же... Если реализовать виртуальную машину(.net или java), то динамические библиотеки станут не очень нужны. Ведь и .net и java позволяют создавать библиотеки классов, которые вполне способны заменить dll.
|
|
|
Данил
Full Member
Откуда: Тольятти (Togliatti) Всего сообщений: 106
Ссылка
Дата регистрации на форуме: 29 нояб. 2006 | Профиль | Email | Сообщить модератору
NEW! Сообщение отправлено: 7 февраля 2007 12:33
.Net и Java уже реализованы. Сдесь вопрос стоял в портировании, т.е. в переносе этих систем, конкретно .Net (MONO) в MINIX. Переносом не кто не занимается (да и в ближайшее время навряд ли кто будет) Не знаю в чем здесь .dll чинят проблемы?  А вообще если что то надо тебе(себе), то сделай это сам. Это единственно правильный вывод.  ( Это я себе сам и говорю. ) ( при всем уважении к разработчикам и участникам проекта MINIX ) Интерес тсс.
|
|
|
alek111
Junior Member
Всего сообщений: 9
Ссылка
Дата регистрации на форуме: 19 фев. 2007 | Профиль | | Сообщить модератору
NEW! Сообщение отправлено: 19 февраля 2007 17:55
Какие могут быть виртуальные машины когда система еще толком использоваться не может.
Вот когда будут драйвера для PATA, SATA, USB-всяких и поддержка минимального набора мобильных файловых систем (типа CD, DVD, FAT-ов всяких), а также какой нибудь нормальной файловой системы для жестких дисков (типа NTFS или ext3fs), а также драйвера для самой распространенной графики и сетевых чипов, тогда можно будет думать и о всяких извращениях.
|
|
|
Данил
Full Member
Откуда: Тольятти (Togliatti) Всего сообщений: 106
Ссылка
Дата регистрации на форуме: 29 нояб. 2006 | Профиль | Email | Сообщить модератору
NEW! Сообщение отправлено: 19 февраля 2007 23:08
Уважаемый alek111. Полностью согласен с тем, что нужны драйвера и т. д. и т. п. Но почему то вот думается [q] и о всяких извращениях.[/q]
|
|
|
alek111
Junior Member
Всего сообщений: 9
Ссылка
Дата регистрации на форуме: 19 фев. 2007 | Профиль | | Сообщить модератору
NEW! Сообщение отправлено: 20 февраля 2007 10:47 Сообщение отредактировано: 20 февраля 2007 10:56
Данил написал: [q] Уважаемый alek111.Полностью согласен с тем, что нужны драйвера и т. д. и т. п.Но почему то вот думается и о всяких извращениях. [/q]
Потому, что новую операционную систему имеет смысл делать, чтобы под нее было легче и удобнее писать прикладные программы, ну и для надежности тоже, а не в качестве платформы для всяких виртуальных машин. А то с одной стороны все кричат что микроядро медленнее монолитного, а потом разворачивают по верху любой ОС кучу виртуальных машин и интерпретаторов и жалуются что все слишком медленно. И вообще, откуда такое нездоровое пристрастие к виртуальным машинам и интерпретаторам??? Если ктото начнет говорить про простоту программирования, строгий контроль типов, автоматическую сборку мусора и т.д. и т.п., то я тут-же отправлю всех в направлении Oberon-2. В нем все это есть и он компилируемый, а значит существенно быстрее. А то, что у него синтаксис не С-подобный, так это скорее достоинство, чем недостаток. Библиотек под него маловато, и это конечно плохо, но может лучше добавить библиотек к Oberon-у чем писать с нуля какого нибудь монстра типа Mono???
|
|
|
|
|
Время выполнения скрипта: 0.0779. Количество выполненных запросов: 15, время выполнения запросов 0.0088
