Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 33
Посмотрите вот сюда — cm.bell-labs.com/plan9/. Насколько я понял, вы изобретаете нечто аналогичное.
Интересно, чем руководствовались разработчики этой ОС, выбирая (осмысленно, я так понимаю) такое название.
Тем самым фильмом и руководствовались :)
Муравей маленький, да удаленький… а вообще, без претензий.
Plan 9, и, особенно, Inferno — прекрасные системы. К сожалению, не получили широкого распостранения.
Можно еще вот сюда сходить lsub.org
(Развитие идей Plan9)
(Развитие идей Plan9)
Да Мисье знает толк (с)
А по факту, похоже на дипломную или вроде того. Это не научная работа?
А по факту, похоже на дипломную или вроде того. Это не научная работа?
На первой картинке не хватает ещё уницикла. ^_~
Остается только пожелать Вам бесконечного энтузиазма. Миллионы людей могут бесконечно долго спорить о необходимости еще одной ОС. Сотни смогут ее написать. И только единицы продать.
> Каждому TID на локальном хосте соответствует только один модуль, даже если есть несколько модулей с одинаковым TID.
вы взорвали мне остатки мозга
вы взорвали мне остатки мозга
Берегите себя ))
Спрошу на всякий случай — про PhantomOS Димы Завалишина слышали? Тоже persistence, отсутствие файловой системы и т.д. Причём, оно уже работает, в примитивном виде пока.
Да, конечно, слышал. Даже немного с ним переписывался. Очень интересный проект, правда, кажется, немного буксует сейчас.
Читал, пытался понять… Скажите прямо: в злых птиц можно будет сыграть или нет?
Не всегда приоритет writer'а над reader'ами это хорошо. Он их может просто задавить. Вообще, политика разграничивания доступа — это целое направление в науке с кучей разных решений под разные сценарии. Получается API должен быть предельно гибким, что усложняет задачу.
Прямо сейчас работаю над HugeSet, может хранить в индексном хранилище очень много строк (ДНК последовательности, что угодно). Да, предоставить доступ через функции - это хорошо. Это сервисная архитектура, которая уже с другой десяток лет успешно используется. А вот не дать проге на прямую работать с данными (в данном случае на прямую читать и лочить страницы файла, пусть даже и раскиданного Lustre по десятку машин), это очень большое ограничение.
Возможный вывод: тут не нужна своя ось. Тут нужно исключительно run-time реализуемой парой библиотек, которые бы предоставляли все необходимые абстракции прикладным программам (публикация сервисов в сети, прозрачная работа со свопом и т.п.). Зато можно всегда нырнуть поглубже к железу, когда песочница оказывается слишком малой.
Дальше глянем и вдруг понимаем, что run-time такой уже есть. К примеру Java. Просто нужна надстройка, которая бы хранила/пробуждала наши объекты во время их жизни. Все абстракции, приведенные в статье легко реализуются.
В таком ключе можно сконцентрироваться на идее и даже ее полностью реализовать. В отличии от наполеоновских планов на новую ОС. Только чует мое сердце, реализовано оно уже… Где то видел «вечные» объекты и даже JVM раскиданную по кластеру машин с возможностью прозрачной миграции объектов. Про сервисы и доступ данных, да рассылка сообщений — это уже индустриальный стандарт по моему.
Прямо сейчас работаю над HugeSet, может хранить в индексном хранилище очень много строк (ДНК последовательности, что угодно). Да, предоставить доступ через функции - это хорошо. Это сервисная архитектура, которая уже с другой десяток лет успешно используется. А вот не дать проге на прямую работать с данными (в данном случае на прямую читать и лочить страницы файла, пусть даже и раскиданного Lustre по десятку машин), это очень большое ограничение.
Возможный вывод: тут не нужна своя ось. Тут нужно исключительно run-time реализуемой парой библиотек, которые бы предоставляли все необходимые абстракции прикладным программам (публикация сервисов в сети, прозрачная работа со свопом и т.п.). Зато можно всегда нырнуть поглубже к железу, когда песочница оказывается слишком малой.
Дальше глянем и вдруг понимаем, что run-time такой уже есть. К примеру Java. Просто нужна надстройка, которая бы хранила/пробуждала наши объекты во время их жизни. Все абстракции, приведенные в статье легко реализуются.
В таком ключе можно сконцентрироваться на идее и даже ее полностью реализовать. В отличии от наполеоновских планов на новую ОС. Только чует мое сердце, реализовано оно уже… Где то видел «вечные» объекты и даже JVM раскиданную по кластеру машин с возможностью прозрачной миграции объектов. Про сервисы и доступ данных, да рассылка сообщений — это уже индустриальный стандарт по моему.
Спасибо за первый содержательный комментарий!
На счёт приоритета писателя я просто стремился представить наиболее простую и универсальную схему (из простых). Разумеется, могут быть специфичные случаи, когда это не будет удобным решением.
Насчёт прямой работы с данными, отвечу так. Да, бывают критичные места. Потому подобная система должна давать возможность вставки доверенного кода, написанного на Си и принебрегающего любыми ограничениями. Однако, по моему мнению, в большинстве случаев желание напрямую работать с данными связанно с неумением правильно произвести декомпозицию (в данном случае, модульную).
Да, есть Java и иже с ней. Беда только в том, что она не может обеспечить истинную и прозрачную персистентность объектов (ведь здесь нужна поддержка со стороны ОС) и удобную прозрачность распределения (абстрагируемся от локальности/удалённости вызываемого объекта).
На счёт приоритета писателя я просто стремился представить наиболее простую и универсальную схему (из простых). Разумеется, могут быть специфичные случаи, когда это не будет удобным решением.
Насчёт прямой работы с данными, отвечу так. Да, бывают критичные места. Потому подобная система должна давать возможность вставки доверенного кода, написанного на Си и принебрегающего любыми ограничениями. Однако, по моему мнению, в большинстве случаев желание напрямую работать с данными связанно с неумением правильно произвести декомпозицию (в данном случае, модульную).
Да, есть Java и иже с ней. Беда только в том, что она не может обеспечить истинную и прозрачную персистентность объектов (ведь здесь нужна поддержка со стороны ОС) и удобную прозрачность распределения (абстрагируемся от локальности/удалённости вызываемого объекта).
> Да, есть Java и иже с ней. Беда только в том, что она не может обеспечить истинную и прозрачную персистентность объектов (ведь здесь нужна поддержка со стороны ОС) и удобную прозрачность распределения (абстрагируемся от локальности/удалённости вызываемого объекта).
А зачем именно Java? Вон есть тот же Erlang с его распределенностью
А зачем именно Java? Вон есть тот же Erlang с его распределенностью
Да, но без поддержки ОС не бывать персистентности.
Что понимаем под перситентностью? Сервис, который никогда не умирает?
В простейшем случае можно dump'ить память с процессом на диск. Но это не безопасно и в целом будет вредит разработке. Я не хочу, что бы мои объекты (события, списки, сообщения, что угодно) жили вечно. Я не хочу, что бы их вне моего ведома сдампила ОС, а потом восстановила, оставив мне работу все это почистить. Я хочу создать кажущуюся персистентность, когда программа может в любой момент продолжить работу. Это все реализуется в user-space. Если прога не большая, то она может запросто выключаться, скидывая только необходимые объекты в сессию. Если это что-то большое, то обычно оставляем небольшого резидента, который держит часть данных/библиотек в памяти. Ест память, зато просыпаемся почти мгновенно. По задаче.
«Была» такая ОС для мобильников, Symbian, почитай ее плюшки в этом направлении)
Пользовательское приложение может крутится в некотором контейнере, который может сам сбрасывать состояние объектов на диск и обратно. Для приложения все прозрачно, оно «всегда» работает, оно реагирует на сообщения (вот окно, заполни его через этот абстрактный интерфейс; вот адресные данные человека, которого пользователь «перетащил» на твое окно/иконку; этот сервис просит фотографию из профиля и т.д.).
ОС занимается доступом к железу, предоставляет всякие абстракции на подобие VFS, реализует стандартные интерфейсы вроде POSIX (вернее системную их часть) и т.д. Это не задача ОС знать что там в user-space происходит. Нынешние ОС на вроде Linux'а предоставляют полный доступ до памяти, со всяким плюшками типа shared memory, copy on write, transactional memory и т.п. На крайняк можно сделать брешь в безопасности системы и написать свой модуль, который по хамски будет лезть в память user-space програм, хотя пользы от этого не вижу. Но я совершенно не вижу причин, зачем тут потребовалась своя ОС.
То же можно сказать о VM. Ее задача абстрагировать скомпилированный код от железа, на лету или через внешний кешь реализуя самого разного рода оптимизации, трансляции в нативный код и работа с памятью. Не вижу где здесь может потребоваться особая поддержка со стороны VM. Даже если написать что-то совсем не безопасное, к примеру любые объекты в системе (включая простейшие массивы) могут мигрировать с машины на машину полностью прозрачно, а также им гарантируется «вечная жизнь» пока их не удалят (да и там versioning и все такое), то совершенно не пойму где тут нужна поддержка VM (кроме отдельных нативных расширений для скорости)? Просто вместо массива всегда используем PersistentArray. Если совсем хотим загнобить программиста, то просто пишем надстройку/валидатор над компилятором, который будет ругаться на не использование Persistent* API. Что бы облегчить труд программиста, можно придумать или взять существующий язык (lua, python, что угодно) и за'map'ить все объекты в свои Persistent*.
Вывод: не ясно зачем тут своя ОС. Не ясно зачем тут своя VM.
Попробуй обосновать «ведь здесь нужна поддержка со стороны ОС», хотя бы примерами.
P.S. извиняюсь за длинную простыню)
В простейшем случае можно dump'ить память с процессом на диск. Но это не безопасно и в целом будет вредит разработке. Я не хочу, что бы мои объекты (события, списки, сообщения, что угодно) жили вечно. Я не хочу, что бы их вне моего ведома сдампила ОС, а потом восстановила, оставив мне работу все это почистить. Я хочу создать кажущуюся персистентность, когда программа может в любой момент продолжить работу. Это все реализуется в user-space. Если прога не большая, то она может запросто выключаться, скидывая только необходимые объекты в сессию. Если это что-то большое, то обычно оставляем небольшого резидента, который держит часть данных/библиотек в памяти. Ест память, зато просыпаемся почти мгновенно. По задаче.
«Была» такая ОС для мобильников, Symbian, почитай ее плюшки в этом направлении)
Пользовательское приложение может крутится в некотором контейнере, который может сам сбрасывать состояние объектов на диск и обратно. Для приложения все прозрачно, оно «всегда» работает, оно реагирует на сообщения (вот окно, заполни его через этот абстрактный интерфейс; вот адресные данные человека, которого пользователь «перетащил» на твое окно/иконку; этот сервис просит фотографию из профиля и т.д.).
ОС занимается доступом к железу, предоставляет всякие абстракции на подобие VFS, реализует стандартные интерфейсы вроде POSIX (вернее системную их часть) и т.д. Это не задача ОС знать что там в user-space происходит. Нынешние ОС на вроде Linux'а предоставляют полный доступ до памяти, со всяким плюшками типа shared memory, copy on write, transactional memory и т.п. На крайняк можно сделать брешь в безопасности системы и написать свой модуль, который по хамски будет лезть в память user-space програм, хотя пользы от этого не вижу. Но я совершенно не вижу причин, зачем тут потребовалась своя ОС.
То же можно сказать о VM. Ее задача абстрагировать скомпилированный код от железа, на лету или через внешний кешь реализуя самого разного рода оптимизации, трансляции в нативный код и работа с памятью. Не вижу где здесь может потребоваться особая поддержка со стороны VM. Даже если написать что-то совсем не безопасное, к примеру любые объекты в системе (включая простейшие массивы) могут мигрировать с машины на машину полностью прозрачно, а также им гарантируется «вечная жизнь» пока их не удалят (да и там versioning и все такое), то совершенно не пойму где тут нужна поддержка VM (кроме отдельных нативных расширений для скорости)? Просто вместо массива всегда используем PersistentArray. Если совсем хотим загнобить программиста, то просто пишем надстройку/валидатор над компилятором, который будет ругаться на не использование Persistent* API. Что бы облегчить труд программиста, можно придумать или взять существующий язык (lua, python, что угодно) и за'map'ить все объекты в свои Persistent*.
Вывод: не ясно зачем тут своя ОС. Не ясно зачем тут своя VM.
Попробуй обосновать «ведь здесь нужна поддержка со стороны ОС», хотя бы примерами.
P.S. извиняюсь за длинную простыню)
Что понимаем под перситентностью? Сервис, который никогда не умирает?Программы, которые всегда в виртуальной памяти. Об этом подробнее можно почитать у Завалишина, когда он это поясняет на примере своей ОС Фантом.
Я не хочу, что бы мои объекты (события, списки, сообщения, что угодно) жили вечно. Я не хочу, что бы их вне моего ведома сдампила ОС, а потом восстановила, оставив мне работу все это почистить. Я хочу создать кажущуюся персистентность, когда программа может в любой момент продолжить работу. Это все реализуется в user-space. Если прога не большая, то она может запросто выключаться, скидывая только необходимые объекты в сессию.Неужели записывать/считывать состояние проще, чем просто игнорировать этот вопрос? Опять же направляю к доводам Завалишина.
«Была» такая ОС для мобильников, Symbian, почитай ее плюшки в этом направлении)Три года под неё писал :)
Даже если написать что-то совсем не безопасное, к примеру любые объекты в системе (включая простейшие массивы) могут мигрировать с машины на машину полностью прозрачно, а также им гарантируется «вечная жизнь» пока их не удалят (да и там versioning и все такое), то совершенно не пойму где тут нужна поддержка VM (кроме отдельных нативных расширений для скорости)?Java, к примеру, не предоставляет распределённую модель вычислений, в отличие от того же Erlang. Т.е. в этой среде нельзя прозрачно вызвать удалённый код. А поддержка ОС нужна, если мы хотим сделать процесс персистентным. Т.е. какая бы ни была надстройка, всё равно снизу у нас процесс, который загружается с файлового образа, а затем уничтожается (например, при перезагрузке).
> Java, к примеру, не предоставляет распределённую модель вычислений.
Есть ведь RMI, да и куча других фреймворков для распределенных вычислений? На крайняк можно даже само приложение, которое ничего не знает о подобном, раскидать по машинам в кластере через Cluster VJM.
Поддержка распределенных вычислений — не часть виртуальной машины, суть которой эффективно предоставить доступ к локальной машине, да и то по сути к процессору и памяти. Все остальное, это библиотеки, включая даже такие железные вещи как RDMA или прямой доступ к USB девайсам.
> Т.е. какая бы ни была надстройка, всё равно снизу у нас процесс, который загружается с файлового образа, а затем уничтожается.
Хм… Ваша ОС будет скидывать память в своп и обратно. Просто мне это станет не подконтрольно. Когда при переключении между процессами, процессор забывает сбросить пару регистров, из-за чего (при большой удаче) можно подсмотреть за чужим процессом — это считается большой дырой в безопасности. А тут я так понимаю даже закодировать часть своей памяти нельзя будет?
Есть некоторый контейнер приложений. Я пишу свое приложение, в котором указываю что «не умирает», а все остальное по умолчанию — просто мусор. Мне не нужно думать о безопасности, быстродействии, потреблении ресурсов и т.п. Я точно знаю, какой код и какие данные — не умирают. А вот клик мыши, генерирующий какой нибудь MouseEvent — это раз отстреляло и исчезло. Для пользователя удобно, его приложение всегда рядом, всегда реагирует на его желания. Для программиста все удобно. Он декларирует свои объекты, которые интегрируются в жизнь системы. Объекты слушают события и реагируют, пользуясь данными, которые «всегда под рукой». Программист ничего не знает, когда его приложение запускается, когда выгружается и как сериализуются его объекты, то в memcached, то на SSD, то в какой либо своп, в зависимости от статистики использования, которую собирает контейнер. Все это - просто контейнер со своим API, в который мы deploy наше приложение. Ну и стандарты на API для разного рода абстракций и семантики, типа работа с графом отношений между людьми, релевантный поиск по документам на десктопе и в сети и т.п.
Чем то это напоминает всякие J2EE, бины и прочее. Опыта в «вечно живущих» сервисах у нас уже много на самом деле.
Вместо этого предлагается ОС, которая будет выполнять все функции обыкновенного user-space контейнера приложений, с дополнительной фичей — дамп всей памяти в своп. Тут сложно будет разобраться что релевантно, что не безопасно, что нужно держать поближе, т.к. требуется каждую минуту, а что собственно уже давно выкинули, но сборщик мусора пока придержал. Ну распределенные вычисления, которые как я уже сказал, никакого отношения к железу не имеют, а наоборот реализуются поверх обычных системных легковесных процессов + сеть. А ведь еще есть работа с железом, куча стандартов и все такое. Тут на крайний случай можно реализовать свой контейнер приложений, как модуль в ядро, как я уже говорил выше. Но тут уже так просто не fork'нешься. Все то, что дают как само собой разумеющееся в user space, придется реализовывать самому в ядре… ну или тянуть с собой user-space библиотеки (что жутко конечно).
На крайний случай можно подумать вы ищите «новые» (микро ядра, tiny ядра и безъядерные гипотетические ОС уже не первый десяток лет как рассмотрели со всех сторон) типы ОС. К примеру некое минимальное ядро, а в user-space у нас один большой контейнер приложений, в котором все живут. Ну и прекрасно. Берем Linux, выкидываем из него все, включая все окружение GNU (ну все конечно не выкинуть), пишем свой контейнер приложений. Сам контейнер лучше на Java/Mono. Пишем свой ClassLoader, который запретит пользовательским приложениям использовать что либо из стандартных библиотек, только ваш persistent API. Готово. Программист в рабстве, пользователь не видит разницы, у вас своя ОС.
По прежнему стался один вопрос: назовите пример приложения, которое бы получило преимущества в вашей ОС/ВМ, при этом не имела бы таких преимуществ в каком либо контейнере приложений.
Если преимущество: поддержка разных платформ, даже нативных приложений, то как я уже говорил — анализ памяти станет крайне сложным и наверное единственной поддержкой «персистентности» будет чистый дамп в своп. А тут тысячи нюансов, от безопасности и до производительности.
P.S. не хочу переубедить писать свое, всегда интересовался системным программированием и даже писал свою RTOS под современный Z80. Просто интересны ваши аргументы, кроме как «просто так хочу».
Есть ведь RMI, да и куча других фреймворков для распределенных вычислений? На крайняк можно даже само приложение, которое ничего не знает о подобном, раскидать по машинам в кластере через Cluster VJM.
Поддержка распределенных вычислений — не часть виртуальной машины, суть которой эффективно предоставить доступ к локальной машине, да и то по сути к процессору и памяти. Все остальное, это библиотеки, включая даже такие железные вещи как RDMA или прямой доступ к USB девайсам.
> Т.е. какая бы ни была надстройка, всё равно снизу у нас процесс, который загружается с файлового образа, а затем уничтожается.
Хм… Ваша ОС будет скидывать память в своп и обратно. Просто мне это станет не подконтрольно. Когда при переключении между процессами, процессор забывает сбросить пару регистров, из-за чего (при большой удаче) можно подсмотреть за чужим процессом — это считается большой дырой в безопасности. А тут я так понимаю даже закодировать часть своей памяти нельзя будет?
Есть некоторый контейнер приложений. Я пишу свое приложение, в котором указываю что «не умирает», а все остальное по умолчанию — просто мусор. Мне не нужно думать о безопасности, быстродействии, потреблении ресурсов и т.п. Я точно знаю, какой код и какие данные — не умирают. А вот клик мыши, генерирующий какой нибудь MouseEvent — это раз отстреляло и исчезло. Для пользователя удобно, его приложение всегда рядом, всегда реагирует на его желания. Для программиста все удобно. Он декларирует свои объекты, которые интегрируются в жизнь системы. Объекты слушают события и реагируют, пользуясь данными, которые «всегда под рукой». Программист ничего не знает, когда его приложение запускается, когда выгружается и как сериализуются его объекты, то в memcached, то на SSD, то в какой либо своп, в зависимости от статистики использования, которую собирает контейнер. Все это - просто контейнер со своим API, в который мы deploy наше приложение. Ну и стандарты на API для разного рода абстракций и семантики, типа работа с графом отношений между людьми, релевантный поиск по документам на десктопе и в сети и т.п.
Чем то это напоминает всякие J2EE, бины и прочее. Опыта в «вечно живущих» сервисах у нас уже много на самом деле.
Вместо этого предлагается ОС, которая будет выполнять все функции обыкновенного user-space контейнера приложений, с дополнительной фичей — дамп всей памяти в своп. Тут сложно будет разобраться что релевантно, что не безопасно, что нужно держать поближе, т.к. требуется каждую минуту, а что собственно уже давно выкинули, но сборщик мусора пока придержал. Ну распределенные вычисления, которые как я уже сказал, никакого отношения к железу не имеют, а наоборот реализуются поверх обычных системных легковесных процессов + сеть. А ведь еще есть работа с железом, куча стандартов и все такое. Тут на крайний случай можно реализовать свой контейнер приложений, как модуль в ядро, как я уже говорил выше. Но тут уже так просто не fork'нешься. Все то, что дают как само собой разумеющееся в user space, придется реализовывать самому в ядре… ну или тянуть с собой user-space библиотеки (что жутко конечно).
На крайний случай можно подумать вы ищите «новые» (микро ядра, tiny ядра и безъядерные гипотетические ОС уже не первый десяток лет как рассмотрели со всех сторон) типы ОС. К примеру некое минимальное ядро, а в user-space у нас один большой контейнер приложений, в котором все живут. Ну и прекрасно. Берем Linux, выкидываем из него все, включая все окружение GNU (ну все конечно не выкинуть), пишем свой контейнер приложений. Сам контейнер лучше на Java/Mono. Пишем свой ClassLoader, который запретит пользовательским приложениям использовать что либо из стандартных библиотек, только ваш persistent API. Готово. Программист в рабстве, пользователь не видит разницы, у вас своя ОС.
По прежнему стался один вопрос: назовите пример приложения, которое бы получило преимущества в вашей ОС/ВМ, при этом не имела бы таких преимуществ в каком либо контейнере приложений.
Если преимущество: поддержка разных платформ, даже нативных приложений, то как я уже говорил — анализ памяти станет крайне сложным и наверное единственной поддержкой «персистентности» будет чистый дамп в своп. А тут тысячи нюансов, от безопасности и до производительности.
P.S. не хочу переубедить писать свое, всегда интересовался системным программированием и даже писал свою RTOS под современный Z80. Просто интересны ваши аргументы, кроме как «просто так хочу».
Даже на комментарии первого уровня надо нажимать «ответить» ;)
Напоминает гибрид идей Oberon, Plan 9 и KeyKOS, во многом идеи перекликаются с тем, что хотят получить в результате работы над проектом Фантом ОС.
Архитектура современная, отчасти идеалистическая. Отлично, если люди идут собственным путем, забывая о классических подходах и обратной совместимости. Такие шаги всегда чреваты прорывами и открытиями. И всегда они движимы личным интересом, а не сферой денег. Так что — здорово, не перевелись Кулибины.
Архитектура современная, отчасти идеалистическая. Отлично, если люди идут собственным путем, забывая о классических подходах и обратной совместимости. Такие шаги всегда чреваты прорывами и открытиями. И всегда они движимы личным интересом, а не сферой денег. Так что — здорово, не перевелись Кулибины.
Главное, что нужно решить в вашей системе — это то, как будут работать распределенные библиотеки, чтобы небыло dll- и so- хелла, как это сейчас происходит в Windows и Linux.
В Windows dll-хелл еще кое-как засунут вглубь системы, так что можно хотя бы ставить программы нужных версий. В Linux всё вообще плохо — обязательно нужны библиотеки конкретных версий, и если две программы требуют разные подверсии, тогда начинается пляска с бубном в неизвестным результатом. Вследствие чего распространять программы в Linux коммерческому производителю невозможно без сборки под каждую разновидность ОС (Etersoft имеет билд-ферму для изготовления сборок на ~50 систем, что явно за пределами здравого смысла).
Так что заранее подумайте о том, как будут распространяться программы под вашу ОС.
В Windows dll-хелл еще кое-как засунут вглубь системы, так что можно хотя бы ставить программы нужных версий. В Linux всё вообще плохо — обязательно нужны библиотеки конкретных версий, и если две программы требуют разные подверсии, тогда начинается пляска с бубном в неизвестным результатом. Вследствие чего распространять программы в Linux коммерческому производителю невозможно без сборки под каждую разновидность ОС (Etersoft имеет билд-ферму для изготовления сборок на ~50 систем, что явно за пределами здравого смысла).
Так что заранее подумайте о том, как будут распространяться программы под вашу ОС.
Сложные приложения могут держать свои библиотеки при себе, так иногда происходит. Просто люди не всегда по хорошему относятся к программе, которая держит у себя, к примеру, zlib, если он уже установлен в системе. Никто в Linux не запрещает сделать свою директорию MyApplication.app, сложить в нее все и работать от туда, прямо как на маке.
Линковка динамическая, обратную совместимость люди обычно поддерживают, либо переименовывают библиотеку, так что возможно установить две версии. Тут не важно какой версии либа, главное что в ней есть необходимые функции с необходимой сигнатурой. Плюсом же подхода будет более эффективная работа с памятью (страницы с загруженной либой расшариваются между всеми), да и запуск/загрузка приложения будет быстрей.
> обязательно нужны библиотеки конкретных версий
Интересно узнать имя дистрибутива и приложений, которые потребовали разные версии одной либы, да так, что в репозитории они под одним именем и не могут быть установлены в одну систему. Короче, покажите танцы с бубном, когда потребовалось руками решать конфликты, которые не сумел решить ваш пакетный менеджер.
Если вас просто смущает большой набор файлов в /usr/lib, то просто не смотрите туда. Там правда все под контролем =)
Линковка динамическая, обратную совместимость люди обычно поддерживают, либо переименовывают библиотеку, так что возможно установить две версии. Тут не важно какой версии либа, главное что в ней есть необходимые функции с необходимой сигнатурой. Плюсом же подхода будет более эффективная работа с памятью (страницы с загруженной либой расшариваются между всеми), да и запуск/загрузка приложения будет быстрей.
> обязательно нужны библиотеки конкретных версий
Интересно узнать имя дистрибутива и приложений, которые потребовали разные версии одной либы, да так, что в репозитории они под одним именем и не могут быть установлены в одну систему. Короче, покажите танцы с бубном, когда потребовалось руками решать конфликты, которые не сумел решить ваш пакетный менеджер.
Если вас просто смущает большой набор файлов в /usr/lib, то просто не смотрите туда. Там правда все под контролем =)
>> обязательно нужны библиотеки конкретных версий
> Интересно узнать имя дистрибутива и приложений, которые потребовали разные версии одной либы, да так, что в репозитории они под одним именем и не могут быть установлены в одну систему. Короче, покажите танцы с бубном, когда потребовалось руками решать конфликты, которые не сумел решить ваш пакетный менеджер.
Ну это постоянно происходит. В одной программе есть глюки, которые исправляются при переходе на нову версию либы. Или наоборот, с новой версией либы появляется глюк в программе. При этом новые версии других программ требуют новую версию либы. Имея контроль через репозитарий, ничего с такой ситуацией не сделаешь — приходится делать выбор:
— Либо иметь старую версию либы, пользоваться рабочей программой без глюка, но при этом не иметь возможность поставить другие программы.
— Либо иметь новую версию либы, иметь новые программы, и использовать рабочую программу с глюком.
— Либо начинать пляски с бубном, пытая удовлетворить и ту и другую программу. Например, попробовать собрать одну программу статически из исходников, чтобы она не влияла на другие.
Живые примеры — программы на основе WxWidwets. Уж там сегфолтов и логических глюков (в поведении окна, в элементах управления) с выходом новой WxWidget хоть отбавляй. А если нужна программа, которая требует только новую версию WxWidgets, тогда другим становится очень, очень плохо.
Да что там WxWidgets. Я одно время верил в Debian Stable, и всегда устанавливатл динамическую сборку Opera. Пока в один прекрасный день новая версия Opera не стала жестко глючить, вёрстка плыла, сертификаты не работали. Вылечилось только установкой статической версии. Небыло бы статики — даже не знал бы что делать.
Но дело в том, что статика не всегда работоспособна — статическим программам зачастую подавай libc определенной версии, и в более редких случаях — нужную версию ядра.
Банальная проверка — вот статическая сборка Linux-игры:
http://webhamster.ru/db/data/articles/84/tropa_1_35_for_2_6_linux_static.tar.gz
Как у вас, запустилась ли она? А есть ли звук? Если вы два раза сказали да, то вам повезло.
> Интересно узнать имя дистрибутива и приложений, которые потребовали разные версии одной либы, да так, что в репозитории они под одним именем и не могут быть установлены в одну систему. Короче, покажите танцы с бубном, когда потребовалось руками решать конфликты, которые не сумел решить ваш пакетный менеджер.
Ну это постоянно происходит. В одной программе есть глюки, которые исправляются при переходе на нову версию либы. Или наоборот, с новой версией либы появляется глюк в программе. При этом новые версии других программ требуют новую версию либы. Имея контроль через репозитарий, ничего с такой ситуацией не сделаешь — приходится делать выбор:
— Либо иметь старую версию либы, пользоваться рабочей программой без глюка, но при этом не иметь возможность поставить другие программы.
— Либо иметь новую версию либы, иметь новые программы, и использовать рабочую программу с глюком.
— Либо начинать пляски с бубном, пытая удовлетворить и ту и другую программу. Например, попробовать собрать одну программу статически из исходников, чтобы она не влияла на другие.
Живые примеры — программы на основе WxWidwets. Уж там сегфолтов и логических глюков (в поведении окна, в элементах управления) с выходом новой WxWidget хоть отбавляй. А если нужна программа, которая требует только новую версию WxWidgets, тогда другим становится очень, очень плохо.
Да что там WxWidgets. Я одно время верил в Debian Stable, и всегда устанавливатл динамическую сборку Opera. Пока в один прекрасный день новая версия Opera не стала жестко глючить, вёрстка плыла, сертификаты не работали. Вылечилось только установкой статической версии. Небыло бы статики — даже не знал бы что делать.
Но дело в том, что статика не всегда работоспособна — статическим программам зачастую подавай libc определенной версии, и в более редких случаях — нужную версию ядра.
Банальная проверка — вот статическая сборка Linux-игры:
http://webhamster.ru/db/data/articles/84/tropa_1_35_for_2_6_linux_static.tar.gz
Как у вас, запустилась ли она? А есть ли звук? Если вы два раза сказали да, то вам повезло.
> А если нужна программа, которая требует только новую версию WxWidgets, тогда другим становится очень, очень плохо.
В системе всегда можно установить несколько версий одной и той же библиотеки. Софт обычно требует конкретных версий библиотеки, к примеру libneon.27.1.3. Если установлена более новая версия и она совместима с предыдущими, то ставятся ссылки с имен старых версий на новую либу. Иначе в системе устанавливается две и более либы, каждая под свою серию совместимых версий.
Задача меинтейнера либы в репозитории решать когда либа совместима с предыдущими версиями, а когда нет, отсюда выбирается метод установки. Если либа нарушает работу других приложений, то меинтейнер получит уведомление, мол либы не совместимы. Тогда вместо ссылки, он позволит установить две и более версии либы.
Если сидим на левом дистрибутиве или используем левый софт, то всегда можно скачать конфликтную либу, собрать самому, положить в укромное место и перед запуском поставить свой LD_LIBRARY_PATH, где и укажем директорию с либой. За все время работы в Debian, Ubuntu, Arch и Gentoo мне ни разу не приходилось этого делать.
Вывод: сливать все либы в одно приложение, как это делает софт под маком или виндой — все таки не unix way. Никто не запрещает такого подхода, крупный софт именно так и поступает. Использовать общие библиотеки — это хорошо, быстрей загрузка, меньше потребление памяти. Обычно проблемы с либами надуманные, человек предполагает наличие проблемы исходя из логики «одна либа на всю систему», не осознавая, что на самом деле версий одной либы может быть несколько. Хотя тут иногда всплывает аллергия на «копии» одной либы, мол зачем столько и все такое.
Статическая программа по определению не требует либ. Это один большой образ со всем необходимым внутри. Прикладной софт никогда не требует особую версию ядра, народ редко делает на прямую системные вызовы. Другое дело, что другие либы могут требовать поддержки ядра (игра требует свежую mesa для OpenGL шейдеров, mesa требует свежее ядро). Тут нет речи о конкретной версии, тут вопрос наличия фичи. Игруху под DX11 тоже не получится запустить под WinМЕ, по той же самой причине.
В системе всегда можно установить несколько версий одной и той же библиотеки. Софт обычно требует конкретных версий библиотеки, к примеру libneon.27.1.3. Если установлена более новая версия и она совместима с предыдущими, то ставятся ссылки с имен старых версий на новую либу. Иначе в системе устанавливается две и более либы, каждая под свою серию совместимых версий.
Задача меинтейнера либы в репозитории решать когда либа совместима с предыдущими версиями, а когда нет, отсюда выбирается метод установки. Если либа нарушает работу других приложений, то меинтейнер получит уведомление, мол либы не совместимы. Тогда вместо ссылки, он позволит установить две и более версии либы.
Если сидим на левом дистрибутиве или используем левый софт, то всегда можно скачать конфликтную либу, собрать самому, положить в укромное место и перед запуском поставить свой LD_LIBRARY_PATH, где и укажем директорию с либой. За все время работы в Debian, Ubuntu, Arch и Gentoo мне ни разу не приходилось этого делать.
Вывод: сливать все либы в одно приложение, как это делает софт под маком или виндой — все таки не unix way. Никто не запрещает такого подхода, крупный софт именно так и поступает. Использовать общие библиотеки — это хорошо, быстрей загрузка, меньше потребление памяти. Обычно проблемы с либами надуманные, человек предполагает наличие проблемы исходя из логики «одна либа на всю систему», не осознавая, что на самом деле версий одной либы может быть несколько. Хотя тут иногда всплывает аллергия на «копии» одной либы, мол зачем столько и все такое.
Статическая программа по определению не требует либ. Это один большой образ со всем необходимым внутри. Прикладной софт никогда не требует особую версию ядра, народ редко делает на прямую системные вызовы. Другое дело, что другие либы могут требовать поддержки ядра (игра требует свежую mesa для OpenGL шейдеров, mesa требует свежее ядро). Тут нет речи о конкретной версии, тут вопрос наличия фичи. Игруху под DX11 тоже не получится запустить под WinМЕ, по той же самой причине.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ещё одна архитектура операционной системы