GoboLinux 015

корень состоит из директорий /Users, /Programs, /System, /Depot, /Mount и /Files

echo $PATH в студию

Разработчики третьего нома гарантируют.

Ну давай посмотрим в ДОС, там все статично

Или Plan 9. От создателей Unix, кстати.

Он вроде с нуля сделан. То есть ни на чем.

Такие вообще пользуются виндой.

Бинарники под него из воздуха материализовываться должны? Или же всё таки кто-то должен заморочиться и собрать их из исходников? А если собирать из исходников, то собрать можно с любым префиксом, без помощи всяких gobolinux. Так зачем он нужен, ещё раз?

Это хуже ?

Да. Расскажи, как в этом гоболинуксе обновили openssl, например.

А где написано, что они линкуют всё статически? На их сайте сказано, что для поиска бинарников в рантайме перенастраивается глобальное окружение (что разумеется дерьмово, потому как негибко, ну да ладно, в данном контексте это неважно) —

~] cat /etc/ld.so.conf
/System/Links/Libraries

~] echo $PATH
/System/Links/Executables

/] cd /Programs
/Programs] ls

AfterStep     E2FSProgs    Htop        NTP          Subversion
ALSA-Driver   Ed           HTTPD       OpenOffice   Sudo
ALSA-Lib      Eject        Hydrogen    OpenSSH      Swfdec
ALSA-OSS      Elinks       IBM-Java2   OpenSSL      Synaptics
ALSA-Utils    Ethereal     ID3Lib      Pango        SysFSUtils
Ardour        Expat        IEEE80211   Patch        Sysklogd
Audacity      File         IMLib2      Perl         TCL
Aumix         Firefox      InetUtils   Pkgconfig    TeTeX
Autoconf      Flac         Intltool    PodXTPro     Texinfo
Automake      Flex         IpodSlave   Popt         TIFF
Bash          Fontconfig   Iptables    

/System/Links/Libraries] ls -l | cut -b 49-
...
libgtk-1.2.so.0 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk-1.2.so.0.9.1 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk.a -> /Programs/GTK+/1.2.10/lib/libgtk.a
libgtk.la -> /Programs/GTK+/1.2.10/lib/libgtk.la
libgtk.so -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
libgtk-x11-2.0.la -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.la
libgtk-x11-2.0.so -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.so.0.600.7
libgtk-x11-2.0.so.0 -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.so.0.600.7
libhfs.a -> /Programs/CDRTools/2.01/lib/libhfs.a
libhistory.a -> /Programs/Readline/5.0/lib/libhistory.a
libhistory.so -> /Programs/Readline/5.0/lib/libhistory.so.5.0
libhistory.so.5 -> /Programs/Readline/5.0/lib/libhistory.so.5.0

В чём здесь должны возникнуть принципиальные сложности при обновлении openssl?

Где же? Например wincmd/totalcmd со своими библиотеками работы с архивами со всеми вытекающими.

И где ты тут статику увидел?

Актуальность залог работоспособности.

Опять вранье. Если разработчик рассчитывал на определенную версию, то софт будет гарантированно работоспособен только с ней. Например, у софтины использующей буст попробуй подменить библиотеки буста на актуальную версию, а я посмеюсь.

Принятие «root» как имя суперюзера

А раньше что было?

Не нужно несколько версий программ. Разработчики не для того потеют над кодом, чтобы он не использовался.

Да, Arch'е-синдром у меня.

В чём здесь должны возникнуть принципиальные сложности при обновлении openssl?

1. Как же про «имеется возможность установить разные версии одной программы» ? libgtk.so, к примеру, будет что, если поставить разные GTK+ ?

2. Гораздо интереснее, что с чем слинковано.

3. А вот это, libgtk.a и libgtk.la, зачем в системе ? Собственно, и libgtk.so не должно быть тоже.

Согласен.

Не нужно несколько версий программ.

Тебе может быть и не нужно.

Уверен?

Ну то есть вопрос, цитирую, "как в этом гоболинуксе обновили openssl" у тебя отпал, раз ты двинулся дальше? Если что, чёртов сайт работает, там даже на русском есть.

«как в этом гоболинуксе обновили openssl» у тебя отпал, раз ты двинулся дальше ?

Ни в коем случае. Всё ведётся к пониманию именно этого процесса. Пока же я склонен предполагать, исходя из наличия *.a и *.la, что openssl вообще не обновили. ;-)

Раньше «gobo» вроде было.

Вот ты прицепился к a и la, автотулзы их генерят по умолчанию, а также ссылку на so без цифры. В настоящих дистрибах генерацию a обычно либо отключают, либо упаковывают отдельно, чтобы по умолчанию не деплоилась, la просто удаляют, ссылку на so без цифры пакуют в отдельный пакет типа -dev или -devel, точно так же, чтобы не деплоилась по умолчанию. Здесь ребята не заморачивались, как make install свалил всё в prefix, так и оставили.

Важно, что исправление не ломает ABI в пределах so.major, собственно, так что все программы, в которых в заголовок вписан этот so.major (readelf -d binary) не заметят _ничего_. Точно так же они _абсолютно_ ничего не заметят, если им подсунуть через модифицированные окружение обратно совместимое по ABI обновление, распакованное сайд-бай-сайд со старыми версиями. Модификация окружения в свою очередь, может делаться либо грубо, на постоянку, переписыванием конфигов ld.so, как сделано у них, либо более тонко, при желании с точностью до процесса, как это сделано в пакетном менеджере Nix или в SCL в RHEL.

Вот ты прицепился к a и la, автотулзы их генерят по
умолчанию, а также ссылку на so без цифры.

Я в курсе, вообще-то.

Важно, что исправление не ломает

Приложения должны где-то искать библиотеки, либо таскать их с собой. Общее место ты показал, да. Только с этим всплыло то, что приложения могут собираться без использования динамических библиотек. Впрочем, что-то вроде этого я и подозревал, иначе невозможно реализовать «возможность легко полностью удалить программу, просто удалив её директорию из /Programs»: в этой директории или нет библиотек, или они есть и дублируют аналогичные из соседнего приложения. В первом случае получается, что таки не всё удаляется, во втором получается MacOS.

Я в курсе, вообще-то.

А чего вопросы глупые задаешь тогда, "зачем там a и la"?

Только с этим всплыло то, что приложения могут собираться без использования динамических библиотек.

И что? Могут и со статикой линковаться, могут и rpath вписать и покласть на настройки ld.so, могут вообще вручную грузить по захардкоженным путям. Но без дополнительных телодвижений, напомню, линковка идёт именно с so, причём путь к ней не вписывается в elf.

Впрочем, что-то вроде этого я и подозревал, иначе невозможно реализовать «возможность легко полностью удалить программу, просто удалив её директорию из /Programs»: в этой директории или нет библиотек, или они есть и дублируют аналогичные из соседнего приложения.

Так ты "подозреваешь"? Что же, не буду мешать расследованию.

Ну статически слинкованые библиотеки от динамических предназначенных для конкретного ПО отличаются только подачей. Если ты считаешь что статика это когда все в одном екзешнике, то такой подход давно не используется в более-менее сложном ПО, так как это усложняет процесс программирования. А если библиотека ориентирована на использование конкретным ПО с которым она поставляется то ее можно назвать статично привязаной. Следовательно пользы, для другого ПО, от нее особой нет.

Если разработчик рассчитывал на определенную версию, то по хорошему он должен позаботиться о совместимости с будущими версиями которые могут быть в используемой системе.

В openssl нашли ошибку, потенциально страдают от этого apache, ssh, ftp, etc. Разработчик openssl правит ее, создатель дистра пересобирает, пользователь обновляет openssl, все просто. А если б каждый из использующих openssl таскал с собой отдельно эту либу? Разработчик openssl правит, разработчик apache правит, разработчик ssh правит, разработчик ftp правит, разработчик etc правит, да это какой-то хаос.

Если ты считаешь что статика это когда все в одном екзешнике, то такой подход давно не используется в более-менее сложном ПО, так как это усложняет процесс программирования.

Это не я считаю. Есть конкретные определения. А у тебя похоже каша в голове. Иди погугли чем отличается статическая линковка от динамической.

то по хорошему он должен позаботиться о совместимости с будущими версиями которые могут быть в используемой системе.

Зачем ему это делать? И как это вообще можно обеспечить?

Разработчик openssl правит, разработчик apache правит, разработчик ssh правит, разработчик ftp правит, разработчик etc правит, да это какой-то хаос.

Почему хаос?

мне кажется, или в последнее время зачастили выходы такого рода дистрибутивов? Недавно NixOS, теперь вот это..

или правильнее сказать, зачастили новости на лоре о таких дистрибутивах.

20 версий одной и той же библиотеки и все 20 пакетов нужно обновить

Не факт, что все предыдущие версии придется обновлять. Ведь нередко бывает, что уязвимости появляются лишь в более новых версиях.

И правильно сделали что root теперь суперюзер, имхо.

мне кажется, или в последнее время зачастили выходы такого рода дистрибутивов? Недавно NixOS, теперь вот это..

Ну не всё же удобно в корень распаковывать, как диды в первослаке распаковывали двадцать лет назад. Категорически непонятно, конечно, зачем для этого поддерживать самостоятельные мегадистеры, ну да ладно, вопрос риторический.

Сволочи, третьекеды верните!

В текущем виде репозитории для пользователя просто бесполезны.

Давно так не смеялся.

В GoboLinux используется нетрадиционная для Linux оориентация файловой системы

Например, у софтины использующей буст попробуй подменить библиотеки буста на актуальную версию, а я посмеюсь.

Это читерский пример, бустовые шаблоны прекрасно сочетают в себе недостатки одновременно статических и динамических библиотек. То есть ты и обновить их не можешь, и мошонку с крестовым хозяйством при этом не убрать. А вот другой пример — актуальные freetype и fontconfig я лично SxS с системными подтягивал, и ничего, никто не умер, за счёт обратной совместимости в пределах so.major. Кроме разве что одной гномо-проги (gnome-appearance-properties), в ней какой-то мудень оставил rpath, и в ней как было по этой причине шг, так и осталось.

5 лет назад упоминание GoboLinux

Так сейчас уже даже смеяться устали. За 6 лет 0.01% от 1% — это как бы показатель нужности.

и ничего, никто не умер, за счёт обратной совместимости в пределах so.major.

Эту обратную совместимость никто не гаратирует даже в пределах so.major.

Ну допустим я тут действительно намутил. Для чего нужна динамическая линковка? Для совместного доступа различных приложений. Так? Теперь статическая линковка этого нас лишает. Возьмем тот-же totalcmd, допустим он использует свою динамическую либу для работы с архивами, а winrar использует свою. Значит в памяти у нас висят две либы с примерно одним функционалом. А значит динамическая либа totalcmd по своему способу фактического использования совпадает со статической библиотекой, так как кроме totalcmd ее больше никто не будет использовать. То есть разницы мы не ощущаем. С другой стороны, если б totalcmd использовал библиотеку rar, то нам понадобился бы установленный rar, в случае с виндовс, либо отдельная либа архиватора в случае с линукс.

Тут мы плавно подошли ко второму вопросу. Разработчик либы rar внес изменения не совместимые с предыдущей версией. Если не исправить totalcmd, то он не сможет работать с архивами rar. Следовательно разработчик totalcmd должен отслеживать анонсы изменений в предстоящих выпусках rar. А разработчик rar должен предоставлять такую информацию. Я это понимаю как часть концепции открытых проектов.

А хаос, потому, что изменения затронут в десятки, а то и сотни раз больше человеко-часов, чем при централизованном изменении динамической библиотеки. Плюс нет гарантий что все отреагируют одинаково быстро. А тем временем критическая уязвимость будет доступна для использования.

К стати, как отражается статическая линковка на работе fork?

Эту обратную совместимость никто не гаратирует даже в пределах so.major.

Программисты вообще не гарантируют работу чего-либо, лол, так что не надо про "гарантии". А утрата обратной совместимости в пределах so.major убивает саму изначальную идею разделяемой библиотеки, так что является серьёзным косяком.

Для совместного доступа различных приложений.

Да, но не приложений в понимании пользователя. Одно приложение может состоять из многих исполняемых файлов и библиотек.

Разработчик либы rar внес изменения не совместимые с предыдущей версией. Если не исправить totalcmd, то он не сможет работать с архивами rar.

С чего бы это? Работал работал и вдруг перестал? Такое только в линуксах бывает :)

Если не исправить totalcmd

Вот именно, что _исправить_. В новой библиотеке к тебе прилетит новый ABI и/или API. Или что хуже без изменения ABI/API старые функции вдруг заработают чуть-чуть иначе и приложение встанет раком. В линуксах такое часто случается.

На кой хрен это нужно разработчикам прикладного софта?

а то и сотни раз больше человеко-часов,

Сотни человеко-часов это сизифов труд по приведению кучи софта и библиотек к общему знаменателю и поддержанию этого зоопарка в относительно работоспособном состоянии в репозиториях, а в итоге это пользователю не нужно.

Десяток пользовательских приложений обновить по сравнению с адом репозиториев это вообще ничто.

А чего вопросы глупые задаешь тогда, «зачем там a и la» ?

Они напрямую связаны с вопросом. Сборка приложения, при их наличии, заканчивается статически собранным бинарником.

Но без дополнительных телодвижений, напомню, линковка идёт именно с so

Увы, нет. При наличии a/la происходит без телодвижений именно статическакя сборка.

В новой библиотеке к тебе прилетит новый ABI и/или API. Или что хуже без изменения ABI/API
старые функции вдруг заработают чуть-чуть иначе и приложение встанет раком. В линуксах такое
часто случается.

В ALT Linux, например, не прилетит. Точнее, с большим трудом, наверное, может просочиться, но вероятность сильно уменьшена соответствующими проверками.

в ней какой-то мудень оставил rpath

И это вот тоже решается дистрибутивно.

В новой библиотеке к тебе прилетит новый ABI и/или API. Или что хуже без изменения ABI/API старые функции вдруг заработают чуть-чуть иначе и приложение встанет раком. В линуксах такое часто случается

Бред же, ABI и API в пределах одного soname стабильны, а soname указывается в названии пакета.

Как оно может «прилететь», поясни?

При наличии a/la происходит без телодвижений именно статическакя сборка.

С каких пор? Сейчас специально для тебя проверил на проекте http://quvi.sourceforge.net/, там маленькая библиотека и маленькая юзающая её программа. Только если из префикса физически выкинуть so и передать при сборке программы допольнительные LDFLAGS с теми зависимостями, что были в заголовке эльфа so, то тогда и только тогда программа слинкуется с a. Так рассказываешь, как будто я софт не пакетил. (И свой не писал.)

Тише, тише, он траллирует.

Значит и софт тоже не прилетит.

Так только в теории. На практике же, например, имеем поведение memcpy на которое завязано куча софта и поломку после обновления и без изменений ABI/ABI.

поведение memcpy на которое завязано куча софта

Примеры? Про флеш знаю.

поломку после обновления и без изменений ABI/ABI

Примеры?

Достаточно одного примера, а он уже приведен.

не-LSB. обосновал?

Нет: в этом случае виноваты флешеразработчики, т.к. не читали документацию к интерфейсу, а полагались на реализацию, стабильность же undefined behaviour (а тем более явно запрещённых в документации действий) не гарантируется.

The memcpy() function copies n bytes from memory area src to memory area dest. The memory areas must not overlap. Use memmove(3) if the memory areas do overlap.

Принятие «root» как имя суперюзера

чёёёёё???

- Embracing «root» as super user name — that should make recipes more simple to write and soften the task of preparing new releases

кто-нибудь вообще в состоянии объяснить, что господин подразумевает?