Инновации в линуксе (в каком дистрибутиве что именно, будущее)

[sash-kan]

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

http://plan9.bell-labs.com/sources/contrib...les/servers.pdf
биндится файловая система, затем записываете в / читаете из файлов внутри этих фс·

три примера оттуда:

echo add 144.32.112.70 255.255.254.0 0 >/net/ipifc/0/ctl

% cat /mail/fs/mbox/782/subject
Re: [iPAQ] A working 802.11 / AP combination?

cd /mnt/factotum
# add a key:
echo key ’user=badwolf’ ’service=ftp’ ’server=unit.org.uk’ \
’!password=buffalo’ >ctl
# remove all matching keys:
echo delkey ’server=unit.org.uk’ >ctl

[NickLion]

sash-kan, извините, но это тот же rpc только в виде fs. с достаточно мутным управлением параметрами вызова через эти key. т.е. удобство видится только в том, что работать с таким rpc можно в виде знакомых ls/cd/cat/echo - так?

upd дабы быть правильно понятым - я абсолютно соглашаюсь, что представление в виде fs - это удобство. по многим причинам, в частности простота обращения к сервисам из программы без необходимости привлекать лишние библиотеки. но отсутствие этой фичи не делает dbus ужасным. он по сути обладает той же иерархичной fs-подобной структурой, только последним элементом есть не файл, а метод (преимущество в простом указании параметров). и как на dbus можно сделать простой и понятный интерфейс, так и на протоколе plan9 можно нагородить кошмар на улице вязов.

[/dev/random]

sash-kan, извините, но это тот же rpc только в виде fs. с достаточно мутным управлением параметрами вызова через эти key. т.е. удобство видится только в том, что работать с таким rpc можно в виде знакомых ls/cd/cat/echo - так?

[Выскажу своё мнение, хоть вопрос был и не мне. Можете его проигнорировать] Нет, в том, что интерфейс превращается из сугубо внутреннего в универсальный, в том числе пользовательский.

[NickLion]

[Выскажу своё мнение, хоть вопрос был и не мне. Можете его проигнорировать] Нет, в том, что интерфейс превращается из сугубо внутреннего в универсальный, в том числе пользовательский.

я там добавил upd специально. т.е. да - я поддерживаю, что такой способ его делает универсальнее, но это не делает dbus ужасным. менее удобным - да, но не ужасным. как в анекдоте - ну, "ужас", но не "ужас-ужас-ужас!". т.е. проще что-то вроде cat /proc/dbus/mail/inbox/count, чем qdbus org.freedesktop.mail /inbox count, но они не различаются на порядок.

[sash-kan]

это тот же rpc

я не утверждал обратного:

реализация rpc в plan9

собственно, и мой ответ на остальную часть вашего поста содержится в той же фразе:

на фоне d-bus-а реализация rpc в plan9 выглядит просто идеалом простоты и прозрачности

ну и плюс дополнение от уважаемого /dev/random

upd. собственно, некое жалкое (это не файл-серверы) подобие уже позаимствовано: /proc и /sys (может быть, ещё что-то?)·
и, насколько я в курсе, всё это является (пока) интерфейсом только лишь к самому linux-у: нет такого универсального механизма, как 9p, которым могла бы воспользоваться любая программа·

[taaroa]

…и эта реализация (в plan9) нам намекает на ограниченность классического unixway, ага?

Она намекает, что в классических *nix'ах отошли от классического unixway. Plan9 — попытка реализовать средствами классического unixway то, что в классических *nix'ах реализовано через задницу.

Not only is UNIX dead, it's starting to smell really bad. © Rob Pike, 1991

[sash-kan]

…и эта реализация (в plan9) нам намекает на ограниченность классического unixway, ага?

Она намекает, что в классических *nix'ах отошли от классического unixway. Plan9 — попытка реализовать средствами классического unixway то, что в классических *nix'ах реализовано через задницу.

Not only is UNIX dead, it's starting to smell really bad. © Rob Pike, 1991

да, немного не успели:

Initial release
1992 (universities)
1995 (general public)

а ведь если б не Линус, то мир бы выглядел совсем иначе… возможно, хоть чуть-чуть, но прогрессивнее…

[aumit]

…и эта реализация (в plan9) нам намекает на ограниченность классического unixway, ага?

Она намекает, что в классических *nix'ах отошли от классического unixway. Plan9 — попытка реализовать средствами классического unixway то, что в классических *nix'ах реализовано через задницу.

Not only is UNIX dead, it's starting to smell really bad. © Rob Pike, 1991

да, немного не успели:

Initial release
1992 (universities)
1995 (general public)

а ведь если б не Линус, то мир бы выглядел совсем иначе… возможно, хоть чуть-чуть, но прогрессивнее…

Не факт, есть Inferno с Styx, что-то не видно прогресса.

[sash-kan]

Не факт, есть Inferno с Styx, что-то не видно прогресса.

что сказать-то хотели?
wikipedia://inferno_(operating_system)#Design_principles

Inferno was first made in 1995 by members of Bell Labs' Computer Science Research division to bring ideas of Plan 9 from Bell Labs to a wider range of devices and networks.

не успел Роб Пайк сотоварищи, не успел…
если б хоть на пяток лет раньше…

[NickLion]

не успел Роб Пайк сотоварищи, не успел…
если б хоть на пяток лет раньше…

"Но Кристобаль Хозевич успел раньше" © Братья Стругацкие.

[aumit]

Не факт, есть Inferno с Styx, что-то не видно прогресса.

что сказать-то хотели?
wikipedia://inferno_(operating_system)#Design_principles

Inferno was first made in 1995 by members of Bell Labs' Computer Science Research division to bring ideas of Plan 9 from Bell Labs to a wider range of devices and networks.

не успел Роб Пайк сотоварищи, не успел…
если б хоть на пяток лет раньше…

Сообщество как-то не оценило эти инновации.

P.S.
Ничто вам не мешает реализовать Styx/9P в Linux.

[sash-kan]

Ничто вам не мешает реализовать Styx/9P в Linux.

верно, ничто не мешает закрепить автоматическую коробку передач на телеге·

[taaroa]

Ничто вам не мешает реализовать Styx/9P в Linux.

linux, особенно в последнее время, напоминает спортивную площадку на свалке. иногда, если основательно там покопаться, можно отыскать много интересного, н/р, те же namespaces.

[/dev/random]

Ничто вам не мешает реализовать Styx/9P в Linux.

верно, ничто не мешает закрепить автоматическую коробку передач на телеге·

Уже закрепили. Только без соответствующего userspace это бесполезно.

[sash-kan]

Уже закрепили.Только без соответствующего userspace это бесполезно.

я знаю·
знаю так же, что пользы от этой реализации (если речь про v9fs), как от упомянутой коробки в упомянутом транспортном средстве·
и даже userspace-а, imho, будет недостаточно·
лучше уж с нуля начинать реализацию новой операционки·
впрочем, это тоже малоосмысленно, ибо таковая уже есть и даже как минимум в двух инкарнациях·

так что остаётся только потихонечку их ковырять, вздыхая по ходу дела: эх, какие интересные идеи пропали втуне…
хорошо, что хоть немногие, но удалось приживить в мир unix-один·

[kotnaton]

Самая крупная инновация, которую я жду в линуксе, это ликвидация репозиторных зависимостей. Каждая программа должна жить в своей "песочнице", а не расчитывать на то, что у других программ точно такие же требования как у нее самой. Вот, к примеру, недавно выполнил apt-get build-dep wine казалось бы невинное удовлетворение зависимостей для сборки wine ? Так нет же: OpenGL больше не работает. Или вот еще, из недавней новости:

...Более того, уже в ближайшее время Canonical собирается удалить пакет Sun JDK из "партнёрского репозитория", путём замещения его пустым пакетом, которому будет присвоен более новый номер версии.

И не факт, что "пустышки" будут приходить только поводу джавы...

[watashiwa_daredeska]

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

С «песочницами» имеется вагон своих проблем, и не факт, что их решение будет для вас проще и понятней.

[alv]

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

С «песочницами» имеется вагон своих проблем, и не факт, что их решение будет для вас проще и понятней.

Тем паче что такое решение есть - в PC-BSD. Что-то воплей восторга по этому поводу я не слышал.

Вот, к примеру, недавно выполнил apt-get build-dep wine казалось бы невинное удовлетворение зависимостей для сборки wine

А Вы не пользуйте злобный и враждебный wine - всё будет нормально

[Aectann]

Самая крупная инновация, которую я жду в линуксе, это ликвидация репозиторных зависимостей.

Благо, есть все основания предполагать, что ваши ожидания в течение ближайших n-лет точно не оправдаются.

[frp]

Самая крупная инновация, которую я жду в линуксе, это ликвидация репозиторных зависимостей.

Буду надеяться на то, что твоя мечта никогда не сбудется.

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

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

Меня впечатлило использование в ubuntu 9.04 пакетов dkms и upstart, когда как в других дистрибутивах эти технологии не используются.

Наглая ложь. dkms был давно и пришел в убунту с дебиана анстейбла. upstart сейчас есть везде.

[Bizdelnick]

Считаю, что современным пакетным менеджерам не хватает одной возможности - ставить несколько версий одной библиотеки.

А Вы пробовали? Что мешает?

upstart сейчас есть везде.

И где же он есть, окромя убунты и её производных?

[frp]

Ага - я тоже думал так, пока не купил ноут...

Hibernate же.

А Вы пробовали? Что мешает?

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

Ну и еще то, что файлы в пакетах разных версий положено ложить в одно и то же место и так же называть

[taaroa]

upstart сейчас есть везде.

И где же он есть, окромя убунты и её производных?

rhel6.

[frp]

И где же он есть, окромя убунты и её производных?

Например:
Debian
Fedore
OpenSUSE

[Ali1]

И где же он есть, окромя убунты и её производных?

Например:
Debian
Fedore
OpenSUSE

В федоре упстарта уже нет.

[frp]

В федоре упстарта уже нет. wink.gif

Его таки заменили на systemd?

[/dev/random]

А Вы пробовали? Что мешает?

То, что нельзя поставить две версии одного пакета

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

[Ali1]

В федоре упстарта уже нет. wink.gif

Его таки заменили на systemd?

Да.

[Bizdelnick]

А Вы пробовали? Что мешает?

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

Ну и еще то, что файлы в пакетах разных версий положено ложить в одно и то же место и так же называть :)

Во-первых, не иногда, а всегда в порядочных и не очень дистрибутивах к имени пакета с либами добавляют старшую цифру версии ABI. Во-вторых, файлы библиотек тоже содержат в себе номер версии, поэтому друг с другом не конфликтуют (libfoo.so.*). А в-третьих, не ложить, а класть. :-)
В общем, см. http://tldp.org/HOWTO/Program-Library-HOWT...-libraries.html.

В федоре упстарта уже нет. wink.gif

Его таки заменили на systemd?

Как и в openSUSE. А до стабильного Дебиана он ещё добраться не успел.

[den_beckett]

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

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

Тем паче что такое решение есть - в PC-BSD. Что-то воплей восторга по этому поводу я не слышал.

Еще в Chakra для gtk-приложений. Смысл в том, что из-за одной-двух прог не ставить половину Гнома. Очень не хватает подобной фичи в остальных дистрах. Думается, и гномофаны не отказались бы от такой фичи для qt-пакетов.