Два участника Технического комитета Debian, которому делегировано принятие решения по выбору системы инициализации для будущего выпуска, представили отчёты с анализом целесообразности выбора systemd или upstart. Ян Джексон (Ian Jackson (http://en.wikipedia.org/wiki/Ian_Jackson)), автор dpkg, в прошлом работавший в компании Canonical, выступил (http://lists.debian.org/debian-ctte/2013/12/msg00182.html) в пользу перехода на upstart. Расс Олбери (Russ Allbery (http://www.eyrie.org/~eagle/software/)), отвечающий за сопровождение ряда подсистем Debian, попытался (http://lists.debian.org/debian-ctte/2013/12/msg00234.html) доказать необходимость перехода на systemd.
Доводы в пользу upstart:
- Upstart более прост для портирования на системы, отличные от Linux, в то время как systemd очень жестко завязан на возможностях ядра Linux. Адаптация Upstart для работы в Debian GNU/kFreeBSD и Debian GNU/Hurd выглядит вполне реальной задачей, что нельзя сказать о systemd;- Upstart более привычен для разработчиков Debian, многие из которых по совместительству участвуют в разработке Ubuntu. Два члена Технического комитета Debian (Steve Langasek и Colin Watson) входят в состав группы разработчиков Upstart.
- Upstart проще и легковеснее systemd, как следствие, меньше кода - меньше ошибок;
- Upstart лучше подходит для интеграции c кодом системных демонов. Политика systemd сводится к тому, что авторы демонов должны подстраиваться под upstream (для замены компонента systemd следует предоставить аналог, совместимый на уровне внешнего интерфейса), вместо того чтобы upstream предоставлял комфортные средства для разработчиков демонов.- Upstart проще в плане поддержания и сопровождения пакетов;
- Сообщество разработчиков Upstart более открыто для совместной работы. В случае systemd придётся принимать методы systemd как должное и следовать им, например, поддерживать отдельный раздел "/usr" или использовать только абсолютные пути для запуска.
- Недостатки Upstart относятся к категории поправимых проблем;
- В текущем состоянии Upstart уже полностью готов для использования в Debian 8.0 (Jessie);- В Upstart более привычная модель определения конфигурации сервисов, в отличие от systemd, где настройки в /etc перекрывают базовые параметры настройки юнитов, определённые в иерархии /lib.
- Использование Upstart позволит поддержать здоровый дух конкуренции, который будет способствовать развитию различных подходов и будет держать разработчиков в тонусе.
- Systemd слишком монолитен и не предоставляет возможность выбора, поставляя изначально заданный набор базовых сервисов (например, замену cron, syslog, inetd), в то время как Upstart больше соответствует позиционированию системы инициализации как связующей прослойки между различными программными проектами.
Доводы в пользу systemd:- Systemd опережает Upstart по возможностям и продуманности архитектуры. Без существенность переработки архитектуры Upstart не сможет догнать systemd по функциональности.
- Systemd содержит достаточно самодостаточный набор компонентов, что позволяет сосредоточить внимание на устранении проблем, а не доработке конфигурации с Upstart до возможностей, уже присутствующих в Systemd. Например, в Upstart отсутствуют: поддержка детального статуса и ведения лога работы демонов, множественная активация через сокеты, активация через сокеты для IPv6 и UDP, гибкие средства ограничения ресурсов.
- Использование systemd позволит сблизить между собой и унифицировать средства управления различными дистрибутивами. На systemd уже перешли Fedora, openSUSE, Sabayon, Mandriva, Arch Linux, кроме того systemd будет применён в будущих выпусках RHEL и SUSE Linux.- У systemd более активное, крупное и разноплановое сообщество разработчиков, в которое входят инженеры компанией SUSE и Red Hat;
- При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию (невозможно предугадать останется Ubuntu на upstart или нет).
- Компания Red Hat не без повода решилась на замену upstart на systemd. Существует опасение, что перейдя на upstart проект Debian наступит на те же грабли и через 2-3 года вынужден будет мигрировать на systemd.
- Для реализации некоторых возможностей загрузки в Upstart требуется использовать фрагментов shell-скриптов, что делает процесс инициализации менее надёжным и более трудоёмким для отладки.
- Поддержка systemd реализована в GNOME и KDE, которые все более активно используют (http://www.opennet.me/opennews/art.shtml?num=38447) возможности systemd (например, средства для управления пользовательскими сеансами и запуска каждого приложения в отдельном cgroup). GNOME продолжает позиционироваться в качестве основного окружения Debian, но отношения между проектами Ubuntu/Upstart и GNOME имеют явно напряжённый характер.
URL: http://lwn.net/Articles/578208/rss
Новость: http://www.opennet.me/opennews/art.shtml?num=38762
init=/bin/bash наше всё!
Павлик, ты ретроград ! :-)
> Павлик, ты ретроград ! :-)Зато стабильно и надёжно...
дальше
mount -o remount,rw /
mount -a
ifconfig lo 127.0.0.1 up;
ifconfig eth0 192.168.0.1 up;Фсё, чё ещё надо ...
ах да, $ mc
А то понаделають фигни фсякой, и сидят писками мерятся ...
Вам на openbsd, или netbsd. Там точно ближайшие десять лет никаких
наворотов не предвидится.
Вам шашечки или ехать? Вам работать или нескучные обойчики развешивать? Вам стабильность и обратную совместимость или вагоны скоропортящихся рюшечек и бантиков в каждом релизе?
> Вам шашечки или ехать? Вам работать или нескучные обойчики развешивать? Вам стабильность
> и обратную совместимость или вагоны скоропортящихся рюшечек и бантиков в каждом
> релизе?Известная мантра. Всё должно развиваться-закон вселенной. Вот только с отсутствием
бантиков и рюшечек имеется в окаменелостях и недоразвитость или полное отсутствие
всего, что нужно чтобы ехать. Да мне ехать, и потому выбираю лины, а то, что некоторые
из них поставляются обвешанными бантиками, так это вполне поправимо и опционально.
> Всё должно развиваться-закон вселенной.Вау, вы со вселенной напрямую контактируете?
> Вот только с отсутствием бантиков и рюшечек имеется в окаменелостях
> и недоразвитость или полное отсутствие всего, что нужно чтобы ехать.Ну да, ну конечно, бздунов второй десяток лет все устраивает, и они всем довольны, одним только красноглазикам неймется, и свербит непременно что-то фатально поломать - с самыми лучшими намерениями, разумеется.
И да, претензии неосиляторов к инструменту - это не аргумент. Если у вас инструмент не едет - ищите причину в своей ДНК.
Это мантра номер два про неосиляторов. Да не могу осилить написать десяток драйеров,
чтоб железо работало не хуже чем в линуксах- мне делать больше что ли нечего.
> десяток драйеров,В ответ на это начинаются мантры о том чего не надо делать и какое оборудование не надо использовать, блаблабла.
> Ну да, ну конечно, бздунов второй десяток лет все устраивает,А уж юзеры MS-DOS могут быть вообще стопудово уверены: никто совместимость не сломает, никто не будет ничего менять несовместимым образом, etc.
> Вам шашечки или ехать? Вам работать или нескучные обойчики развешивать? Вам стабильность
> и обратную совместимость или вагоны скоропортящихся рюшечек и бантиковА драйвера GPU - это скоропортящиеся бантики? Мне как, в целях совместимости предлакается это добро с турбинами использовать как VGA адаптер?
Смешно читать подряд идущих два аргумента, где говорится об одном и том же, только разными словами:===
- У systemd более активное, крупное и разноплановое сообщество разработчиков, в которое входят инженеры компанией SUSE и Red Hat;- При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию (невозможно предугадать останется Ubuntu на upstart или нет).
===К тому же, такое предсказание в стиле Ванги, чтоб прокатило за аргумент:
===
Компания Red Hat не без повода решилась на замену upstart на systemd. Существует опасение, что перейдя на upstart проект Debian наступит на те же грабли и через 2-3 года вынужден будет мигрировать на systemd.
===
Не без повода конечно. Опасение существует. Грабли. Вынужден. Мигрировать еще раз.Ох уж эта политика.
RedHat, SuSE думают о деньгах.
Зомбирование Поттерингом прошло, новая партия админов созрела.
Дальше бабло с сертификации, бабло с работодателя который купит RedHat/SuSE.
---
Учитывая структуру systemd - админы будут не так хорошо знакомы с устройством ОС.
Поэтому саппорт будет нужен. Всё просто - чем сложнее система, тем больше бабла с саппорта.На месте RedHat я бы заказал поттыру реализацию реестра на B+-деревьях,
для управления - утилиту с искусственным интеллектом, для разгребания всего этого добра.
Вот прям как OpenStack - года два надо въезжать, чо там да как.
Согласен.
> Учитывая структуру systemd - админы будут не так хорошо знакомы с устройством
> ОС.Если одмин не осилил systemd - гнать пинками такого одмина из профессии.
А зачем? Будет админить тот-же Debian, но на sysV. Это будет гораздо лучше, для его работодателя, чем и upstart, и systemd.
> лучше, для его работодателя, чем и upstart, и systemd.Видели мы, что после таких получается. Самопальная простыня страниц на пять, где конфигурационные параметры прямо в коде вбиты по всей портянке. Очень хорошо что редхат и прочие понимают что такое "конфигурирование" системы - маздай.
> Видели мы, что после таких получается. Самопальная простыня страниц на пять, где конфигурационные параметры прямо в коде вбиты по всей портянке. Очень хорошо что редхат и прочие понимают что такое "конфигурирование" системы - маздай.Где видели? Регулярно пишут о каких-то мифических простынях скриптов, но никто не сказал где и зачем?
Использую Debian c 2.0, много всякого видел, кроме простыней. ;)
на локалхостах проблем нет, один пишет простыню и он же одминит. Залезь в чужой комп с энтерпрайзом, который поддерживался 10+ лет тремя предыдущими магистрами портянок, и получи что искал. Ну и вишенка на торт - таких компов десятки, а нужно подключить к ним свежекупленнвй девайс еще вчера. Но тебе не надо, спи дальше.
А где ты, сцуко, раньше был? Только вчера оформался на работу? Или тебе пофиг было, что там творится на подведомственных компах, пока жареный птиц не клюнет? А девайс - купили на распродаже, "О, какая клевая штука, и скидка рождественская 30%, надо брать"? Гнать таких надо из профессии, кто админит не приходя в сознание.
> Залезь в чужой комп с энтерпрайзомУгу, угу. "Игла лежит в яйце, яйцо в дятле, дятел в зайце..."
> который поддерживался 10+ лет тремя предыдущими магистрами портянок, и получи что искал.
Перевожу: раз в три года тупое руководство "ентерпрайза" нанимает нового студентота, ибо старый уже видать чему-то научился и начал ценить свой труд (ну или просто "просрал все полимеры" (ц)).
Это вопрос к руководству и его отношению к IT. Боюсь, никакие systemd/upstart ситуации не изменят, разве что в заведомо худшую сторону.
> Но тебе не надо, спи дальше.
Полагаю, что человеку таки надо было привести пример реальной "простыни" из того же архива Debian. Вы на это способны? Личные половые проблемы очередного аникея тут мало кого волнуют.
> на локалхостах проблем нет, один пишет простыню и он же одминит. Залезь
> в чужой комп с энтерпрайзом, который поддерживался 10+ лет тремя предыдущими
> магистрами портянок, и получи что искал.А если у тебя не будет гугла под рукой, в обморок упадёшь так и не узнав, что такое declare -g VAR ?
:)
> что такое declare -g VAR ?богомерзкий башизм?
>> что такое declare -g VAR ?
> богомерзкий башизм?Тебе бабло за работу платят. Хочешь денег - разберёшь хоть на Visual Satan++,
нет - мы больше в ваших услугах не нуждаемся.
>> что такое declare -g VAR ?
> богомерзкий башизм?да хоть фашизм. админу деньги платят не за религиозные убеждения, а за то, чтобы всё работало, работало хорошо и при возникновении какой-либо нештатной ситуации не вставало дружно колом.
>>> что такое declare -g VAR ?
>> богомерзкий башизм?
> да хоть фашизм. админу деньги платят не за религиозные убежденияНу вот такие "админы" и вызывают обычно бурю негодования от детишков, со взором горящим и systemd на устах... В данном случае - вполне справедливо. Человек явно не умеет писать переносимые скрипты и не понимает даже в чем проблема. Вот и "портянки" появляются...
что такое «переносимый скрипт» и за каким чёртом он нужен, если парк достаточно унифицирован, везде, где надо, админ озаботился наличием необходимых инструментов и так далее? чтобы скрипт у Васи Лоханкина на его Lohankin Linups заработал? это не задача админа, вообще-то.а на парке машин, которыми управляет адимин, скрипт работает. в наборе документации по парку нежно и бережно указано, что скрипты x, y и z хотят bash не ниже такой-то версии, так что имейте в виду. а если документации нет, и скрипт написан жопой, то совершенно не важно, на чём это было сделано.
> Человек явно не умеет писать переносимые скрипты и не понимает даже в чем проблема.Вопрос на засыпку: соответствующий POSIX скрипт, обламывающийся на известных багах dash -- переносимым считаем?
>> Человек явно не умеет писать переносимые скрипты и не понимает даже в чем проблема.
> Вопрос на засыпку: соответствующий POSIX скрипт, обламывающийся на известных багах dash
> -- переносимым считаем?Конечно. Мы ведь уважаем стандарты, в отличие от?
Вы много таких багов знаете? Кидайте сюда (или в почту) - почту за честь исправить таковые.
> Вы много таких багов знаете? Кидайте сюда (или в почту) -
> почту за честь исправить таковые.Продублирую http://www.opennet.me/openforum/vsluhforumID3/63734.html#28
---
Ну-ну. Скажем, ноябрь прошлого [2009] года...<mike> привет! проверяю один скрипт на работу с ash -- обнаружилась разница в
поведении с bash: read a b при наличии нескольких символов из $IFS подряд
(табов в /proc/cpuinfo в данном разе) отбрасывает только один, а остальные
клеит в b. bash делает то, что и ожидается -- последовательность разделителей
воспринимает как один разделитель
<mike> это как-то регулируется, или что в таких случаях положено делать для
портабельных скриптов?
[...]
<legion> это бага в dash
<legion> и она почти исправлена
---PS: с текстом поведение не сверял, полагаясь на куда более глубокое понимание POSIX Лёшей.
>> Вы много таких багов знаете? Кидайте сюда (или в почту) -
>> почту за честь исправить таковые.
> Продублирую http://www.opennet.me/openforum/vsluhforumID3/63734.html#28
> ---
> Ну-ну. Скажем, ноябрь прошлого [2009] года...Михаил, выходите из анабиоза! "Прошлый год" - это 2013...
> <mike> привет! проверяю один скрипт на работу с ash -- обнаружилась
> разница в
> поведении с bash: read a b при наличии нескольких символов из $IFS
> подряд
> (табов в /proc/cpuinfo в данном разе) отбрасывает только один, а остальные
> клеит в b. bash делает то, что и ожидается -- последовательность
> разделителей воспринимает как один разделительДа, по стандарту вроде должно быть именно последнее (для IFS из табов, проблелов и \n).
http://pubs.opengroup.org/onlinepubs/000095399/utilities/rea...
http://pubs.opengroup.org/onlinepubs/000095399/utilities/xcu...На данный момент - все работает в Debian stable/oldstable.
Пример (не знаю, сохранит-ли форум табы):
$ cat a.sh
#!/bin/shread a b <<EOF
aaa bbb
EOF
echo a:$a
echo b:$bIFS=";:"
read c d <<EOF
;;;:ccccc::;ddd;;:
EOF
echo c:$c
echo d:$d$ sh ./a.sh
a:aaa
b:bbb
c:
d: ccccc ddd$ bash ./a.sh
a:aaa
b:bbb
c:
d: ccccc ddd
> На данный момент - все работает в Debian stable/oldstable.Ура ;-) Спасибо за проверку -- а выводы насчёт тождественности поведения dash и требований POSIX, надеюсь, для себя сделаете.
>> На данный момент - все работает в Debian stable/oldstable.
> Ура ;-) Спасибо за проверкуДа не за что.
Так багов-то таки ждать, или это была такая шутка юмора? Если
последнее, то хотелось бы извинений, особенно за
http://www.opennet.me/openforum/vsluhforumID3/93345.html#298> -- а выводы насчёт тождественности поведения
> dash и требований POSIX, надеюсь, для себя сделаете.Я уже сделал. Для тех кто в танке - процитирую policy:
http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
-->8--
Scripts may assume that /bin/sh implements the SUSv3 Shell Command Language plus the following additional features not mandated by SUSv3.
-->8--Так что - да, dash это именно posix shell (со считанными добавленными фичами, см. policy). Если вы столкнулись с чем-то, противоречащим стандарту - это баг.
> да хоть фашизм. админу деньги платят не за религиозные убеждения, а за
> то, чтобы всё работало, работало хорошоВот именно поэтому и выкинут жуткие простынки скриптов от инита, заменив на мелкие юниты systemd. Поддерживать будет в 20 раз проще и тем кто пришел на замену уволившегося кулсисопа будет в 20 раз проще разобраться что и где.
ты конкретно задолбал. ИНИТ НЕ ВЫПОЛНЯЕТ НИКАКИХ СКРИПТОВ. попробуй повторять эти слова и биться головой о стену — может, хоть так запомнишь.
> ты конкретно задолбал. ИНИТ НЕ ВЫПОЛНЯЕТ НИКАКИХ СКРИПТОВ. попробуй повторять эти слова
> и биться головой о стену — может, хоть так запомнишь.
When starting a new process, init first checks whether the file /etc/initscript
exists. If it does, it uses [u]this script[/u] to start the process.
угу, извиняюсь, довели старика. надо было чОтка определить слово «скрипт», под которым оппонент подразумевал «shell-скрипт».p.s. ЧЁРТ. ну вот, опять я не проснувшись сказал не то, что хотел. уточняю: нормальный init НЕ ИСПОЛНЯЕТ shell-скриптов. никаких. ни в каком виде. никогда. shell-скрипты исполняются — ВНИЗАПНА! — интерпретатором командной оболочки. своего такого у init нет, и *в контексте init* (т.е. pid 1) никакие shell-скрипты не выполняются.
> p.s. ЧЁРТ. ну вот, опять я не проснувшись сказал не то, что
> хотел. уточняю: нормальный init НЕ ИСПОЛНЯЕТ shell-скриптов. никаких. ни в какомКрутись дальше. "Нормальный". Соломки подстелил?
/boot/initrd.img-3.12-veriosn1-amd64 == .cpio.gz >> ucpio:// >> /init :
$ file init
init: POSIX shell script text executable
$ head -1 init
#!/bin/sh
$ _> pid 1) никакие shell-скрипты не выполняются.
>> p.s. ЧЁРТ. ну вот, опять я не проснувшись сказал не то, что
>> хотел. уточняю: нормальный init НЕ ИСПОЛНЯЕТ shell-скриптов. никаких. ни в каком
> Крутись дальше. "Нормальный". Соломки подстелил?
> /boot/initrd.img-3.12-veriosn1-amd64 == .cpio.gz >> ucpio:// >> /init :
> $ file init
> init: POSIX shell script text executable
> $ head -1 init
> #!/bin/sh
> $ _
>> pid 1) никакие shell-скрипты не выполняются.И что не так? То, что init - это shell-скрипт? Или то, что его исполняет /bin/sh (в конкретной системе будет исполнять один из совместимых интерпретаторов, который выбран основным)? Или у Вас в Вашей системе в скрипте init реализован Ваш собственный интерпретатор?
> И что не так?то, что люди не умеют читать. избавьте меня от вашего идиотизма, пожалуйста.
локалхост=лхаса а это проходи дальше мышь
> на локалхостах проблем нет, один пишет простыню и он же одминит. Залезь
> в чужой комп с энтерпрайзом, который поддерживался 10+ лет тремя предыдущими
> магистрами портянок, и получи что искал. Ну и вишенка на торт
> — таких компов десятки, а нужно подключить к ним свежекупленнвй девайс
> еще вчера. Но тебе не надо, спи дальше.отличное описание того, почему всех — включая написавшего — даже к метле нельзя подпускать: они и её испортить сумеют.
тебя правильно спросили: а ты где был всё это время? почему ты не написал своему начальству докладную записку, где пояснил возможные проблемы с текущим состоянием, способы их решения и рекомендовал немедленно выдать официальное распоряжение заняться этой проблемой?
впрочем, понятно, где ты был: играл в контру, или dwarf fortress, или что там сейчас популярно у ленивых эникейщиков.
порядок — это не «там, где не сорят», это там, где регулярно убирают. в системе жуть? в системе мрак? исправь это не тогда, когда тебя жареный петух в зад клюнул, а в рабочем порядке, без авралов и нервотрёпки.
но «ынтырпрайзные админы» обычно на такой подвиг не способны, они сидят и ждут чего-то. а что, над ними же не капает. а когда обрушится ливень, они будут рассказывать про то, что предыдущие админы были жопорукие. вопрос квалификации того, кто знал про жопу в системе, но ничего не делал, чтобы её устранить без аврала, они при этом обходят десятой дорогой.
Я все это время работал на другой работе. Вот пришел на новое место, очевидно твое. Километры потрянок, ультрадорогой станок закуплен, каждый час простоя с копейку, старый одмин не осилил/заболел/уволен после задорного корпоратива с фотками. Ты и 10 летние портянки, с ассемблерными вставками (гордость предыдушего одмина, он так победил 7 лет назад одного местного хацкера, и этот код остался.) или ты и systemd, очевидно что лучше. Врочем я тебе пишу это наверно раз десятый, и ответ будет как и все предыдущие ответы - ты выбираешь портянки баша и безусловно за 5 мин станок заработает. Врочем спи спокойно, локалхост вне опасности, и поцтеринги давно повержены, оплеваны и освистаны.
(пожимает плечами) один жопорукий эникейщик сменил другого жопорукого эникейщика. админить оба не умеют, проблемы предвидеть не умеют, решать тоже не умеют. но орлы!
> Где видели?На компьютерах.
> Регулярно пишут о каких-то мифических простынях скриптов, но никто не
> сказал где и зачем?Половина скриптов поставляемых с программами - редкий крап, который вечно не совместим с желаемой ОС и который геморно фиксить. Так что если программы не оказалось в репах, а она нужна - это грабли. А уж если какой-то кулсисоп писал кастомный скрипт до тебя - вообще сталинград.
> Использую Debian c 2.0, много всякого видел, кроме простыней. ;)
Мало ли. Может вы ставите там полторы программы из репов и на этом ваше использование заканчивается.
>> Регулярно пишут о каких-то мифических простынях скриптов, но никто не
>> сказал где и зачем?
> Половина скриптов поставляемых с программами - редкий крап, который вечно не совместим
> с желаемой ОС и который геморно фиксить. Так что если программы
> не оказалось в репах, а она нужна - это грабли.Подумайте о выборе дистрибутива, где в "репах" есть все нужные программы. Пример такой нужной программы не соблаговолите?
>> Использую Debian c 2.0, много всякого видел, кроме простыней. ;)
> Мало ли. Может вы ставите там полторы программы из репов и на
> этом ваше использование заканчивается.Ну так покажите. Debian большой - найдите пример того, что вы называете "простыней".
> Ну так покажите. Debian большой - найдите пример того, что вы
> называете "простыней".Ну я могу показать - firewall + QoS в одном стакане, 3595 строк бэшэвого ада :)
Все функции описаны, да и просто самих названий хватает, типа
openvpn_allowed_udp_ports()
reject_icmp_types()
allow_get_ntp_time()тут даун только не поймёт.
>> Ну так покажите. Debian большой - найдите пример того, что вы
>> называете "простыней".
> Ну я могу показать - firewall + QoS в одном стаканеПричем тут Debian. Пальцем на скрипт покажите, пожалуйста.
>>> Ну так покажите. Debian большой - найдите пример того, что вы
>>> называете "простыней".
>> Ну я могу показать - firewall + QoS в одном стакане
> Причем тут Debian. Пальцем на скрипт покажите, пожалуйста.В Debian он работает, потому как готовые фаерволы - это утопия. :)
Я, наверное, уже слишком много принял "на грудь" - не вижу каким боком все это относится к Debian.Повторяю, пальцем на скрипт покажите. Ссылку на репозиторий вам дать?
Хуже.
Каким образом это отосится к сабжу вообще и к системд в частности?
Там что, волшевную кноп... юнит "сделать зашибись" в фаерволе изобрели?
> Я, наверное, уже слишком много принял "на грудь" - не вижу каким
> боком все это относится к Debian.А я не знаю чё ты к дебиану пристал. Чувака колбасило от больших скриптов,
ты чёй-то решил всё это завернуть на дебиан. Мож там и нету, но там и фаярвола нету
поэтому нарисовал сам.> Повторяю, пальцем на скрипт покажите.
scp 192.168.0.1:/etc/init.d/firewall.sh ./
Как новый год то?
> Как новый год то?Спасибо, хорошо, обошлись без интеретов. Не знаю как у вас, но у нас во дворе салютов было выпущенно блоьше чем на 9 мая.
> scp 192.168.0.1:/etc/init.d/firewall.sh ./% scp 192.168.0.1:/etc/init.d/firewall.sh ./
ssh: connect to host 192.168.0.1 port 22: Connection timed out
чота не качается.
На RJ45 дыхни и протри, спирт он хорошо жир растворяет.
> На RJ45 дыхни и протри, спирт он хорошо жир растворяет.Рекомендации лучших тролловодов :)
> На RJ45 дыхни и протри, спирт он хорошо жир растворяет.Очень долго пытался найти RJ45, но так и не нашел. Нашел пару LC, но, уж извините, "тонким слоем спирта" их протирать не буду ;)
> поэтому нарисовал сам.Ну тогда и все претензии - к художнику. А не к Debian и тем более не к sysvinit.
ЗЫ:
Открою военную тайну. У меня файервол состоит ровно из 12 строчек. Из них только 4 - не комментарии и пробелы.
> Из них только 4 - не комментарии и пробелы.iptables \
-t filter \
-I INPUT \
-j DROP;? :)
>> Из них только 4 - не комментарии и пробелы.
> iptables \
> -t filter \
> -I INPUT \
> -j DROP;
> ? :)Да нет. Правил там далеко за сотню выйдет. Учи матчасть, в общем...
>>> Из них только 4 - не комментарии и пробелы.
>> iptables \
>> -t filter \
>> -I INPUT \
>> -j DROP;
>> ? :)
> Да нет. Правил там далеко за сотню выйдет.Народ! Задача века!!!
1. Определить и активировать "за сотню правил" iptables в четыре строки!
2. Внешние программы, скрипты и файлы не использовать. Только iptables.
3. Знаки логического перечисления и завершения команд (";", ",", "&&", "||",...,"\", "\n" ) равносильны новой строке.
4. Код должен быть читаем на терминале 80x25.
5. Тип фаервола: "Всё запрещено, что не разрешено" или "Всё разрешено, что не запрещено" - на выбор.Хотя, чёй-то я... ВЫПОЛНЕННЫМ РЕШЕНИЕМ ЯВЛЯЕТСЯ цифра 4 в РЕЗУЛЬТАТЕ РАБОТЫ СТРОКИ:
# iptables-save | egrep -v -E "#|:|\*|COMMIT" | wc -l
4Фпирёд с припрыжкой!
> Учи матчасть, в общем...
Так и я умею.
> 2. Внешние программы, скрипты и файлы не использовать. Только iptables.Что это еще значит?
> Хотя, чёй-то я... ВЫПОЛНЕННЫМ РЕШЕНИЕМ ЯВЛЯЕТСЯ цифра 4 в РЕЗУЛЬТАТЕ РАБОТЫ
> СТРОКИ:
> # iptables-save | egrep -v -E "#|:|\*|COMMIT" | wc -l
> 4Это еще почему? Правил-то - "за сотню", забыл?
> Фпирёд с припрыжкой!
Проспись, в общем.
>> Учи матчасть, в общем...
> Так и я умею.Умение не наблюдается.
>> 2. Внешние программы, скрипты и файлы не использовать. Только iptables.
> Что это еще значит?
> Это еще почему? Правил-то - "за сотню", забыл?Давай показывай, отмазки потом будет предъявлять...
> Давай показывай, отмазки потом будет предъявлять...А чего там показывать - man iptables-restore. Функциональной является
одна строчка, остальные - разные проверки путей на вшивость и т.п.
>> Давай показывай, отмазки потом будет предъявлять...
> Функциональной является одна строчка,# iptables-restore
^C
Не работает.
>>> Давай показывай, отмазки потом будет предъявлять...
>> Функциональной является одна строчка,
> # iptables-restore
> ^C
> Не работает.Ну протрезвей, наконец, прочитай ман - и заработает.
> Из них только 4 - не комментарии и пробелы.И чего ваш "файрвол" умеет?
>> Из них только 4 - не комментарии и пробелы.
> И чего ваш "файрвол" умеет?Пускать только то, что мне нужно, остальное drop/reject. Кое что - идет в лог.
> Подумайте о выборе дистрибутива, где в "репах" есть все нужные программы.Таких не бывает.
> Пример такой нужной программы не соблаговолите?
Ну так, наобум:
1) в debian нет unrealircd (наиболее фичастый и удобный ircd, между прочим).
2) Или, например, такая утилитка как 3proxy - мелкий, аккуратный и очень фичастый прокси, умеющий кучу полезностей. Но вот в дебиане его как-то нету.> Ну так покажите. Debian большой - найдите пример того, что вы
> называете "простыней".Я уже показал пример - скрипт инициализации udev, где конфигурационные параметры на второй странице только. Очень удобно, да...
> Я уже показал пример - скрипт инициализации udev, где конфигурационные параметры на
> второй странице только. Очень удобно, да…$ head /etc/rc.d/rc.udev
#!/bin/sh
# This is a script to initialize udev, which populates the /dev
# directory with device nodes, scans for devices, loads the
# appropriate kernel modules, and configures the devices.PATH="/sbin:/bin"
OPT="". /etc/udev/udev.conf
предлагаю тебе догадаться, что это за файл: /etc/udev/udev.conf. а заодно предлагаю перестать пользоваться непонятно чем, где написано *странное*.
>> Подумайте о выборе дистрибутива, где в "репах" есть все нужные программы.
> Таких не бывает.Бывают, если люди начинают делать работу, а не шариться по помойкам, собирая все самостоятельно.
>> Пример такой нужной программы не соблаговолите?
> Ну так, наобум:
> 1) в debian нет unrealircd (наиболее фичастый и удобный ircd, между прочим).
> 2) Или, например, такая утилитка как 3proxy - мелкий, аккуратный и очень
> фичастый прокси, умеющий кучу полезностей. Но вот в дебиане его как-то
> нету.http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718219Собирай? (Правда, первый выглядит как полутруп - его могут и не принять в архив.)
>> Ну так покажите. Debian большой - найдите пример того, что вы
>> называете "простыней".
> Я уже показал пример - скрипт инициализации udev, где конфигурационные параметры на
> второй странице только.См. #178. Осталось две попытки из трех. Удачи.
>> Подумайте о выборе дистрибутива, где в "репах" есть все нужные программы.
> Ну так, наобум:
> 1) в debian нет unrealircd (наиболее фичастый и удобный ircd, между прочим).
> 2) Или, например, такая утилитка как 3proxy - мелкий, аккуратный и очень
> фичастый прокси, умеющий кучу полезностей. Но вот в дебиане его как-то нету.Если что, оба давно есть в альте. :)
>> Регулярно пишут о каких-то мифических простынях скриптов, но никто не
>> сказал где и зачем?
> Половина скриптов поставляемых с программами - редкий крапВнимание, вопрос: если те, кто их поставляют, не справляются с простейшим последовательным инитскриптом -- что будет с системой при _следующей_ загрузке (а то и при выключении) при виде того, что эти же деятели наколбасят в unit-файле и какая потребуется квалификация для ликвидации даунтайма и выяснения причин происшедшего?
> Где видели? Регулярно пишут о каких-то мифических простынях скриптов, но никто не
> сказал где и зачем?и не скажут никогда ничего конкретного. это как я в своё время про «софты, которые на иксах мегатормозят, потому что иксы крап» пытался выяснить. через несколько месяцев оказалось, что это одна-единственная софтина, тормозящая на конкретном конфиге постера и написаная не лучшим образом. тут то же самое наверняка: какой-то мегадревний скрипт, который не трогают, потому что работает.
> Если одмин не осилил systemd…его стоит брать на работу. потому что это явно не безмозглый хипстер, который бегает за каждой распиареной фигнёй.
> …его стоит брать на работу. потому что это явно не безмозглый хипстер,
> который бегает за каждой распиареной фигнёй.Эта "распиаренная фигня" судя по всему будет в брутальном редхате. Так что если админ не будет этого знать - пойдет лесом с интересом в половине контор, только и всего. А вот олдскульщики будут на гумно исходить, что технологии времен дедушки ленина теперь не пользуются спросом, это да...
олдскульщики и дальше продолжат улыбаться, глядя на то, как хипстеров с фигнёй имеют титановым ломом в задницу за то, что сервера колом встали.
> Зомбирование Поттерингом прошло, новая партия админов созрела.Уточним: они задолбались управлять "боингом" самолично дергая рули и элероны. И возжелали, блин, автопилот. Какая наглость :).
Не автопилот, но полетный компьютер.
> На месте RedHat я бы заказал поттыру реализацию реестра на B+-деревьях,Ты опоздал, почти все современные ФС ими пользуются. Это майкрософт не мог нормальную ФС сделать, так что реестр пришлось костылить.
>> На месте RedHat я бы заказал поттыру реализацию реестра на B+-деревьях,
> Ты опоздал, почти все современные ФС ими пользуются.Вы не путайте, пожалуйста, «использование микроскопа для рассмотрения мелких объектов» и «использование микроскопа для забивания гвоздей».
> Краснoглaзие на марше...Чего? Файловая система - суть БД "ключ-значение". Маппит ключ "название файла" в значение "содержимое файла". Реестр по логике вещей весьма дублирующаяся функциональность. Но поскольку фат откинул бы коньки при попытке хранить в нем 100500 файлов с разлапистой иерархией - пришлось вот так вот. Но у пингвиноидов нормальные ФС, с b-деревьями и все такое, там 100500 мелких конфиг-файлов никого не напрягает.
Зато в отличие от винды это можно колупать любым редактором. А не одним особо-горбатым регэдитом, где даже найти все ключи содержащие Вася но не содержащие Петя - отдельный головняк. И самих ключей чуть более 100500 штук, даже сразу после инсталла. Это чтобы совсем уж хорошо.
> Но поскольку фат откинул бы коньки при попытке хранить в нем 100500 файлов с разлапистой иерархиейну на самом деле там было другое ограничение — текстовый редактор от MS не мог понимать конфиги длиной более 64кб. А реестр всяко длиннее.
А потом уже появилась идея о том, что в бинарном реестре поиск будет осуществляться быстрее, чем по ФС. Но воз и ныне там — редактирование реестра это отличная заноза в заднице.
> MS не мог понимать конфиги длиной более 64кб. А реестр всяко длиннее.Ну вообще-то реестр иерархический, как и ФС, и найти там отдельный ключ на 64 кило - еще умудриться надо. А вот FAT околел бы если б в него такую иерархию напрямую вгрузить. И грузилась бы винда битый час...
> А потом уже появилась идея о том, что в бинарном реестре поиск
> будет осуществляться быстрее, чем по ФС.С чего бы вдруг? ФС делает примерно те же действия что и база реестра. А под базой реестра еще и ФС есть, которая может тормознуть вторым уровнем вложенности до кучи. Так что появляются всякие дефрагеры реестра в пару к дефрагерам ФС.
>> MS не мог понимать конфиги длиной более 64кб. А реестр всяко длиннее.
> Ну вообще-то реестр иерархический, как и ФС, и найти там отдельный ключ
> на 64 кило - еще умудриться надо. А вот FAT околел
> бы если б в него такую иерархию напрямую вгрузить. И грузилась
> бы винда битый час...Никто и не собирался хранить 100500 значений в отдельных файлах. Значения хранились в стандартном текстовом файле вида переменная=значение, такие файлы назывались ini-файлами, они и сейчас встречаются.
Вот при переходе с Windows 3.11 на Windows 95 от ini-файлов отказались в пользу реестра именно из-за ограничения на размер ini-файла.
>> А потом уже появилась идея о том, что в бинарном реестре поиск
>> будет осуществляться быстрее, чем по ФС.
> С чего бы вдруг? ФС делает примерно те же действия что и
> база реестра. А под базой реестра еще и ФС есть, которая
> может тормознуть вторым уровнем вложенности до кучи. Так что появляются всякие
> дефрагеры реестра в пару к дефрагерам ФС.На тот момент не была разработана даже FAT32, поэтому под ФС понималась FAT16, которая, как бы это… не того.
> Никто и не собирался хранить 100500 значений в отдельных файлах. Значения хранились
> в стандартном текстовом файле вида переменная=значение, такие файлы назывались
> ini-файлами, они и сейчас встречаются.А если не делать большую иерархию и вгрузить все в линейный файл - тогда начнет тормозить парсинг такого файла, да и юзер который там что-то попытается поменять взвоет. Попробуйте вывалить все файлы в / - увидите как сие вылгядит на примере файловой системы :)
> Вот при переходе с Windows 3.11 на Windows 95 от ini-файлов отказались
> в пользу реестра именно из-за ограничения на размер ini-файла.Насколько я помню,
1) В 9x были ini файлы
2) А в 3.x уже был реестр.
Его где-то там и начали костылить. Ибо ничего кроме FAT оно не умело, а насколько хорошо фат работает с большими иерархиями - мы догадываемся...> На тот момент не была разработана даже FAT32, поэтому под ФС понималась
> FAT16, которая, как бы это… не того.Ну так я о чем. Дисковые технологии MS (да и не только) тогда были весьма примитивны, вот и закостылили. Но какой смысл сейчас это делать - хз. EXT4 какой-нибудь - тормозизмом как-то не страдает особо, например. Смысл его лечить от тормознутости, пуская поверх него еще 1 слой делающий примерно то же самое?
> Реестр по логике вещей весьма дублирующаяся функциональность.Более того, там и права доступа как у NTFS. ;-) Единственное отличие реестра - большая часть файлов имеют фиксированный размер, которые ещё и очень мал.
> Более того, там и права доступа как у NTFS. ;-)Ну а у пингвинов просто права доступа на файлы. Что как-то более очевидная для админа сущность, которую куда проще сбэкапать, например.
> Единственное отличие реестра - большая часть файлов имеют фиксированный размер,
Кто вам такую глупость сказал? Оно умеет расти и при том до довольно внушительных размеров. Какие-то лимиты есть, но в NT эти файлы бывают и довольно жирными. Оно напоминает обычный двигун простой базы данных. Транзакционные логи, нечто типа страничной механики. Если есть место в пустоте - пхается в пустоту. Если нет - файл жиреет и дописываеься в хвост.
>> Краснoглaзие на марше...Почему в ответе на мой комментарий вы начинаете с цитаты того, чего я не говорил? И без каких-либо пояснений.
> Чего? Файловая система - суть БД "ключ-значение". Маппит ключ "название файла" в
> значение "содержимое файла". Реестр по логике вещей весьма дублирующаяся функциональность.
> Но поскольку фат откинул бы коньки при попытке хранить в нем
> 100500 файлов с разлапистой иерархией - пришлось вот так вот. Но
> у пингвиноидов нормальные ФС, с b-деревьями и все такое, там 100500
> мелких конфиг-файлов никого не напрягает.И? Где я этому противоречил? Зачем тут всё это капитанство?
> Зато в отличие от винды это можно колупать любым редактором. А не
> одним особо-горбатым регэдитом, где даже найти все ключи содержащие Вася но
> не содержащие Петя - отдельный головняк. И самих ключей чуть более
> 100500 штук, даже сразу после инсталла. Это чтобы совсем уж хорошо.И это тоже вообще к чему?
У нас, похоже, произошло какое-то недоразумение. Я лишь пытался сообщить, что «ты опоздал» в примененном контексте было некорректным высказываением. Использование B-деревьев для ФС - это нормально и правильно. А вот создание реестра для RHEL - это бред. Не надо путать применение B-деревьев в ФС и для конфигурационных значений ОС.> Вы не путайте, пожалуйста, «использование микроскопа для рассмотрения мелких объектов» и «использование микроскопа для забивания гвоздей».
Конфигурацию ОС осуществлять за счёт реестра (с B-деревьями) - это, IMHO, бред. Меня куда больше устраивает то как сейчас.
> RedHat, SuSE думают о деньгах.
> Зомбирование Поттерингом прошло, новая партия админов созрела.
> Дальше бабло с сертификации, бабло с работодателя который купит RedHat/SuSE.Абсолютно с вами согласен. Однако почему бы об этом не написать сюда? —
727708@bugs.debian.org
Да нет, аргументы как раз одинаковые. Второй аргумент:
>Компания Red Hat не без повода решилась на замену upstart на systemdи первый:
>У systemd более активное, крупное и разноплановое сообщество разработчиков, в которое входят инженеры компанией SUSE и Red Hat.А вот когда ты выдаёшь фразы типа "добро пожаловать в реальный мир", перед тем заявив о неумении читать и понимать прочитанное оппонентом, ты ведёшь себя как безмозглый фанатик. Каковым и являешься на самом деле, потому что твой оппонент по факту прав.
> К тому же, такое предсказание в стиле Ванги, чтоб прокатило за аргумент:Вообще-то это FUD в кристаллическом виде.
> ===
> Компания Red Hat не без повода решилась на замену upstart на systemd.
> Существует опасение, что перейдя на upstart проект Debian наступит на те
> же грабли и через 2-3 года вынужден будет мигрировать на systemd.
> ===PS: хотя бесноватая старуха и впрямь по стилю недалеко ушла, да.
Польза Upstart обоснована технически, тогда как от Systemd преимущества не обоснованы, а лишь заявлена ее крыша в виде Redhat и Suse.
> Польза Upstart обоснована технически, тогда как от Systemd преимущества не обоснованы, а лишь заявлена ее крыша в виде Redhat и Suse.Хорошая в общем то крыша. Если к ней добавить Debian и Ubuntu то, считай, эта крыша покроет всю аудиторию юзеров Linux. Если Ubuntu уже не под ней (не знаю).
> Польза Upstart обоснована технически, тогда как от Systemd преимущества не обоснованы,
> а лишь заявлена ее крыша в виде Redhat и Suse.Тем не менее, крыша - это не совсем то, что можно откинуть. С другой стороны, это обоюдоострое оружие: если systemd специально переусложнить так, что спецы по его настройке/адаптации будут только в RH, Debian сильно рискует.
> С другой стороны, это обоюдоострое оружие: если systemd специально переусложнить так, что спецы по его настройке/адаптации будут только в RH, Debian сильно рискует.RH разрабатывает systemd. И никто не гарантирует во что выльется эта разработка в конечном счёте. Никто не мешает RH закрыть код или намеренно его усложнить (увеличив издержки на поддержку, что неприемлимо для некоммерческих дистрибутивов) или насовать туда туеву тучу никому не нужных функций, отчего systemd начнёт неистово тормозить. Риск Дебиана состоит в контроле Редхата над systemd, где Редхат неизбежно получит конкурентные преимущества перед другими дистрибутивами.
> Никто не мешает RH закрыть кодУбейте это! Ну прочитай уже ты GPL, наконец. Краткий курс истории ВКПб^W^Wпо GPL (что нужно знать, чтобы не казаться сразу полным идиотом):
http://www.gnu.org/licenses/quick-guide-gplv3.ru.html
> Ну прочитай уже ты GPL,GPL мешает закрыть код? Нет. Просто ты можешь сделать форк последней версии, которая была ещё под GPL. И остаться с тонной кода, который некому поддерживать, кроме тебя. Так все разрыбы остались в RH работать за деньги.
Давай лучше про рептилоидов, или про базы нацистов на летающих дуршлагах в Антарктиде. И много кода закрыли RedHat за последний десяток лет?
> И много кода закрыли RedHat за последний десяток лет?Ничего не закрыли. Но никто не гарантирует, что это не может случиться при определённых обстоятельствах. Лучшей гарантией является наличие конкурирующих платформ, технологий и компаний.
>> Ну прочитай уже ты GPL,
> GPL мешает закрыть код?Да, детка. Чтобы закрыть - тебе сперва надо сменить лицензию проекта. Смекаешь?
> Просто ты можешь сделать форк последней версии,
> которая была ещё под GPL.Разработчик не может вот так взять и сменить лицензию. Для этого *каждый*, внесший хоть что-то в код - должен передать авторские права RH.
Да и не в интересах RH это. Зачем этот проект закрывать - RH его итак с потрохами контролирует?
> Да, детка. Чтобы закрыть - тебе сперва надо сменить лицензию проекта.
> Смекаешь?Это, кстати, когда как. Обычный проект (не AGPL) можно основательно допатчить и не распостранять. Тогда и сорц можно не выкладывать. Правда, тогда половина кайфа обламывается, но это уже второй вопрос...
> Да, детка. Чтобы закрыть - тебе сперва надо сменить лицензию проекта.
> Смекаешь?Когда все разработчики работают в одной компании (а в случае systemd это именно так) -- перелицензировать код несложно.
> Разработчик не может вот так взять и сменить лицензию. Для этого
> *каждый*, внесший хоть что-то в код - должен передать авторские права
> RH.RH не просто так делает свои инновационные проекты с нуля силами своих разработчиков и стремится на 100% контролировать разработку и код. Systemd, wayland написаны с нуля программистами RH.
> Да и не в интересах RH это. Зачем этот проект закрывать
> - RH его итак с потрохами контролирует?А вот о своих интересах RH не спешит Вам рассказывать. Поэтому Ваши выводы относительно RH не более чем гипотеза. На самом деле, RH -- коммерческая компания, которая стремится к максимизации прибыли. И монополизация контроля над технологиями, пусть даже открытыми, не противоречит целям коммерческой компании, а очень даже соответствует.
>> Да, детка. Чтобы закрыть - тебе сперва надо сменить лицензию проекта.
>> Смекаешь?
> Когда все разработчики работают в одной компании (а в случае systemd это
> именно так) -- перелицензировать код несложно.Ну я, например, точно знаю, что мейнтейнеры Debian в RH пока не работают. Патчи от них - уже прибегали. Ы?
>> Да и не в интересах RH это. Зачем этот проект закрывать
>> - RH его итак с потрохами контролирует?
> А вот о своих интересах RH не спешит Вам рассказывать. Поэтому Ваши выводы относительно RH не более чем гипотеза.Ну так расскажи сам, повесели народ, покажи в чем выгода. Всегда интересно выслушать нового человека с головным убором из фольги ;)
> Зачем этот проект закрывать - RH его итак с потрохами контролирует?Теплее... :)
> Убейте это! Ну прочитай уже ты GPL, наконец.Дорогой друг, в RH прочитали GPL, когда ты еще пешком под стол ходил. И прямо тогда же нашли пути обхода этой лицензии. Они несложные - например, можно сделать закрытый блоб, с которым GPL программа будет взаимодействовать через конвейеры.
Ну и помимо того, никто же не запрещает наваять на портабельном ассемблере такой ужас, что никто в нем не сможет разобраться.
>> Убейте это! Ну прочитай уже ты GPL, наконец.
> Дорогой друг, в RH прочитали GPL, когда ты еще пешком под стол
> ходил. И прямо тогда же нашли пути обхода этой лицензии.Еще один пионер на зимних каникулах, блин...
> Они несложные - например, можно сделать закрытый блоб, с которым GPL программа
> будет взаимодействовать через конвейеры.Дурилка. Речь об исходном коде той самой GPL программы, а не об использовании этой GPL программы с какими-то закрытыми блобами. systemd вообще под LGPL - тут еще куча вариантов.
Код GPL программы нельзя закрыть, если ты его собираешься распространять. Сперва надобно лицензию сменить. В общем, RTFM по адресу #271 (как и второму школьнику).
> Ну и помимо того, никто же не запрещает наваять на портабельном ассемблере
> такой ужас, что никто в нем не сможет разобраться.Книжки лучше умные почитай на каникулах - нефиг трепаться о том, в чем не разбираешься ;)
> Код GPL программы нельзя закрыть, если ты его собираешься распространять. Сперва надобно лицензию сменить. В общем, RTFM по адресу #271 (как и второму школьнику).Лапочка, тупо берёшь и творчески переписываешь, например на другой язык, но исходники уже закрываешь. Переписывать уже написанное легко и просто - справится тупой кодер, прямо как ты.
> Дурилка. Речь об исходном коде той самой GPL программы, а не об использовании этой GPL программы с какими-то закрытыми блобами. systemd вообще под LGPL - тут еще куча вариантов.
Зайка, исходный GPL код, который сильно устарел по сравнению с upstream, никому не нужен. Сама по-себе система инициализации ничего "гениального" из себя не представляет - люди подобные вещи и на make делали. Важно же - поддержка и развитие кода, поддержание его консистентности с ядром, udev и прочими частями системы.
Поэтому если надо закрыть, делают так - постепенно закрывают части upstream'а, избавляясь от GPL компонент.
В общем, Солнышко, протрезвей, потом мозги почини, а потом слегка подумай. Может быть получится.
> Лапочка, тупо берёшь и творчески переписываешь, например на другой язык, но исходники
> уже закрываешь.в общем-то — это нарушение лицензии. доказать, правда, весьма сложно (если вообще возможно). но технически — нарушение.
> доказать, правда, весьма сложно (если вообще возможно).Что и требовалось.
>> Код GPL программы нельзя закрыть, если ты его собираешься распространять. Сперва надобно лицензию сменить. В общем, RTFM по адресу #271 (как и второму школьнику).
> Лапочка, тупо берёшь и творчески переписываешь, например на другой язык, но исходники
> уже закрываешь. Переписывать уже написанное легко и просто - справится тупой кодерИ дурака, который нанял этого кодера (вернее, программиста - машины с задачей перевода справляются плоховато...) - посодют. Доказать, правда, сложновато.
Ну, как более вероятный вариант, пинком под зад наградят акционеры за выдающийся идиотизм.
>> Дурилка. Речь об исходном коде той самой GPL программы, а не об использовании этой GPL программы с какими-то закрытыми блобами. systemd вообще под LGPL - тут еще куча вариантов.
> Зайка, исходный GPL код, который сильно устарел по сравнению с upstream, никому
> не нужен.Он не может устареть. Для этого upstream сперва обязан сменить лицензию на продукт. Все иные варианты закрытия нового кода - незаконны.
PS: Мда. Может и не школьник. Ишшо один инвалид умственного труда...
>> Никто не мешает RH закрыть код
> Убейте это! Ну прочитай уже ты GPL, наконец.Никогда не видели проприетарного кода под GPL? Ох уж эти новенькие.
>>> Никто не мешает RH закрыть код
>> Убейте это! Ну прочитай уже ты GPL, наконец.
> Никогда не видели проприетарного кода под GPL? Ох уж эти новенькие.Под *двойной* лицензией - видел. Под GPL - нет.
Михаил, вы действительно считаете, что GPL позволяет закрыть код без предварительной смены лицензии? Тогда жду аргументы - и давайте напишем батько RMS что он проглядел...
> Михаил, вы действительно считаете, что GPL позволяет закрыть код без предварительной
> смены лицензии?Да, иначе бы не писал.
> Тогда жду аргументы - и давайте напишем батько RMS что он проглядел...
В GPLv3 фиксили тивоизацию, а в условной next пора фиксить юнитизацию, как тут уже отмечалось в рамках одного из обсуждений со страждущими.
PS: разумеется, s/v2/v3/ (ну или s/условной next/v3/ тогда).
>> Михаил, вы действительно считаете, что GPL позволяет закрыть код без предварительной
>> смены лицензии?
> Да, иначе бы не писал.Я ведь вот об чем - просветите малых сих о сей технологии закрытия кода.
> просветите малых сих о сей технологии закрытия кода#373
>> просветите малых сих о сей технологии закрытия кода
> #373Можно для, видимо, умственно отсталых, вроде меня? "Два раза и медленно"?
Гадать что означает "юнитизация" в данном контексте - я не хочу. Может юристу это сразу понятно, но я не юрист.
> Можно для, видимо, умственно отсталых, вроде меня? "Два раза и медленно"?Давайте всё-таки сошлюсь (не путать с пошлю) на уже написанное.
> Гадать что означает "юнитизация" в данном контексте - я не хочу.
>> Можно для, видимо, умственно отсталых, вроде меня? "Два раза и медленно"?
> Давайте всё-таки сошлюсь (не путать с пошлю) на уже написанное.Нет уж. Давайте либо конкретный алгоритм обхода GPL - либо извиняйтесь за #359.
>> Гадать что означает "юнитизация" в данном контексте - я не хочу.
> http://www.opennet.me/openforum/vsluhforumID3/93214.html#92Ну рад, теперь ясно что это каким-то боком относится к unity. Осталось
выяснить причем здесь обход GPL.
> Осталось выяснить, при чем здесь обход GPL.Не спешите отвечать, подумайте. TiVo тоже букву GPL не нарушала.
>> Осталось выяснить, при чем здесь обход GPL.
> Не спешите отвечать, подумайте.За свои слова - я готов отвечать. За чужие - не намерен.
>При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию (невозможно предугадать останется Ubuntu на upstart или нет).
>Компания Red Hat не без повода решилась на замену upstart на systemd. Существует опасение, что перейдя на upstart проект Debian наступит на те же грабли и через 2-3 года вынужден будет мигрировать на systemd.Обратите внимание, что у Upstart аргументация в основном носит технический характер, а у systemd сплошной маркетинговый буллшит.
>Для реализации некоторых возможностей загрузки в Upstart требуется использовать фрагментов shell-скриптов
Олбери забыл сказать, что в systemd тоже частенько приходится писать скрипты, ведь в его юнитах нет даже самых примитивных ветвлений, циклов и операций с переменными. Везде есть, а в systemd нет.
> Обратите внимание, что у Upstart аргументация в основном носит технический характер, а у systemd сплошной маркетинговый буллшит.Надо быть слепошарым хейтером, чтобы сделать такой вывод из новости.
Увы, я всего лишь описываю то, что у меня перед глазами.
То, что у тебя перед глазами, не жоходит до твоего мозга, потому что у тебя предвзятое отношение к systemd (к тому же наверняка основанное на иррациональном "нинужно", как у 95% systemd-хейтеров).Технические аргументы в пользу systemd:
> Systemd опережает Upstart по возможностям и продуманности архитектуры. Без существенность переработки архитектуры Upstart не сможет догнать systemd по функциональности
> Systemd содержит достаточно самодостаточный набор компонентов, что позволяет сосредоточить внимание на устранении проблем, а не доработке конфигурации с Upstart до возможностей, уже присутствующих в Systemd. Например, в Upstart отсутствуют: поддержка детального статуса и ведения лога работы демонов, множественная активация через сокеты, активация через сокеты для IPv6 и UDP, гибкие средства ограничения ресурсов
> Поддержка systemd реализована в GNOME и KDE, которые все более активно используют возможности systemd (например, средства для управления пользовательскими сеансами и запуска каждого приложения в отдельном cgroup)Остальные аргументы носят стратегический характер, называть их маркетинговым буллшитом может только клинический красноглазик-эльф с опухшим ЧСВ.
> Технические аргументы в пользу systemd:и дальше системды-фанбой радостно процитировал маркетинговый булшит. just as planned.
> и дальше системды-фанбой радостно процитировал маркетинговый булшит. just as planned.Не вижу чем это хуже от старперовского "а я привык вот так!"
ты сначала «простыни» продемонстрируй, которые в героиновом бреду себе выдумал.
> То, что у тебя перед глазами, не жоходит до твоего мозгаВы часом не из русфедоры? Таких постоянно безграмотных, но крайне агрессивных пока встречал преимущественно там (в убунте безграмотные, но скорее глупо-гиперактивные).
PS: странно, гентушники такие были скорее лет десять тому, когда оно было агрессивно-модное... реликт, однако.
> Технические аргументы в пользу systemd:
>> Systemd опережает Upstart по возможностям и продуманности архитектуры. Без существенность переработки архитектуры Upstart не сможет догнать systemd по функциональности
>> Systemd содержит достаточно самодостаточный набор компонентов, что позволяет сосредоточить внимание на устранении проблем, а не доработке конфигурации с Upstart до возможностей, уже присутствующих в Systemd. Например, в Upstart отсутствуют: поддержка детального статуса и ведения лога работы демонов, множественная активация через сокеты, активация через сокеты для IPv6 и UDP, гибкие средства ограничения ресурсовЭто противоречит: http://ru.wikipedia.org/wiki/Философия_UNIX
IMHO, UNIX/UNIX-like системы хороши ровно по той причине, что они пытались соответствовать философии UNIX.
А systemd - это просто шаг в сторону Windows.
>> Поддержка systemd реализована в GNOME и KDE, которые все более активно используют возможности systemd (например, средства для управления пользовательскими сеансами и запуска каждого приложения в отдельном cgroup)
Не пользуюсь ни Gnome, ни KDE, а cgroup управляю отдельными приложениями. Поэтому этот пункт мне тупо не понять.
Однако мне кажется, что если бы systemd выполнял задачу init-системы и ничего более (в соответствии с UNIX way), то «поддержка» в Gnome и KDE и не требовалась бы. Извиняюсь, если не прав.
> Остальные аргументы носят стратегический характер, называть их маркетинговым буллшитом
> может только клинический красноглазик-эльф с опухшим ЧСВ.Конечно, давайте переходить на личности! Это определённо поможет сделать диалог конструктивным.
> у systemd сплошной маркетинговый буллшит.Не согласен, есть и вполне технические моменты. Скажем, в upstart нет внятной работы с cgroups/lxc/kvm/... а самолично все это вкостыливать - может и утомить. И как они верно заметили, реверс-трекинг зависимостей... нет, обычно с ним нормально. Но иногда может потребоваться основательно попарить мозг.
>Скажем, в upstart нет внятной работы с cgroups/lxc/kvmНо этого добра нет и в ядре FreeBSD, которое проекту Debian тоже нужно поддерживать. В свете этого внятная работа с названными фичами как-то теряет свою привлекательность. Поддерживать одну систему инициализации будет попроще, чем две.
Если Debian не планирует забрасывать ядро FreeBSD, то systemd так и останется опциональной системой для _одного_ из ядер.
> Но этого добра нет и в ядре FreeBSD,У них много чего нет. А hurd вообще почти не работает. Хотя если дебиан мечтает профукать пользователей в пользу других дистров - да, там можно и на hurd ориентироваться. А лучше на реактос, так эпичнее. Debian/kNT - звучит, да.
> которое проекту Debian тоже нужно поддерживать.
ИМХО это страдание фигней. Пользуется этим всем полтора извращенца на всю планету. И нагибать ради них всех остальных, создавая им неудобства - просто глупо.
> теряет свою привлекательность. Поддерживать одну систему инициализации будет попроще,
> чем две.У бздюков сроду была своя система иниицализации и их вообще никогда не парила совместимость с чем либо. Так что опять же - или надо всех урезать по возможностям до hurd и прочих реактосов, или таки придется наткнуться на платформенную специфику.
> опциональной системой для _одного_ из ядер.
Было бы логично сватать его по дефолту для линуксного ядра. А остальное пусть майнтайнят те кому это надо. Так вполне честно, имхо.
Реверс-трекинг зависимостей - это жирный плюс. Дает униформность в действиях, так как всё являетя событиями.
> Реверс-трекинг зависимостей - это жирный плюс. Дает униформность в действиях, так как
> всё являетя событиями.ты что, это же урезание количества сущностей! а сейчас модно, чтобы в ините всего побольше было.
>Обратите внимание, что у Upstart аргументация в основном носит технический характер, а у systemd сплошной маркетинговый буллшит.Это неправда. У обоих есть и то, и другое примерно в равных количествах.
Ну нормальная же зрелая система - Debian. Debian Linux. Ну какого лешего пихать туда FreeBSD, Hurd и ещё бог весть что? Ладно хрен с ним пихать. Если тихой сапой где-то там. Но чтобы эти эксперименты учитывались при развитии основной 99.(9)% пользовательской базы и стопорили её - это уже пардон легкий маразм. Без относительно upstart vs systemd. Аргумент 'upstart проще портировать под GNU/FreeBSD' в контексте деба просто убивает. Причем что FreeBSD, замечательной системе, от всего этого ни горячо ни холодно. Она идет своим путем.
Только портируют не под FreeBSD, а под ядро FreeBSD и утилиты GNU.
> Только портируют не под FreeBSD, а под ядро FreeBSD и утилиты GNU....при том пользуется таким гибридом полтора умственных паралитика на всю планету, но геморроя от этих людей - миллионам. За это мы нежно любим всех этих цифровых извращенцев.
Ориентироваться на большинство -- ущербная политика.
> Ориентироваться на большинство -- ущербная политика.Ориентироваться надо на тех кто готов обслуживать свой зад. Если кому этот выпердыш нужен - пусть тогда майнтайнят под него и портируют вовремя все что надо.
так именно от того что дебиановцы готовы обслуживать свой зад, и стоит вопрос о трудной портабельности системде в сравнении с апстарт.
А ориентироваться на всякие секс-меньшинства, значит, нормально?
> ...при том пользуется таким гибридом полтора умственных паралитика на всю планету, но
> геморроя от этих людей - миллионам. За это мы нежно любим
> всех этих цифровых извращенцев.Это одна из особенностей Debian. Очевидно, что если эти особенности выкинуть, получится очередной недоRH. А такие дистрибутивы совершенно никому не нужны.
> очередной недоRH. А такие дистрибутивы совершенно никому не нужны.Осталось только рассказать редхату о том какие они лохи...
>> Только портируют не под FreeBSD, а под ядро FreeBSD и утилиты GNU.
> ...при том пользуется таким гибридом полтора умственных паралитика на всю планетуТолько разработчиков Debian/kFreeBSD будет поболее чем "полтора". Уже то, что они являются разработчиками Debian - говорит об их умственных способностях не меньше, чем вопли анонимусов типа вас.
Для Debian GNU/Hurd - вообще нет иной альтернативы. Так что бросаться такими проектами в пользу бесполезных анонимусов - это больше чем глупо...
>> Только портируют не под FreeBSD, а под ядро FreeBSD и утилиты GNU.
> ...при том пользуется таким гибридом полтора умственных паралитика на всю планету, но
> геморроя от этих людей - миллионам. За это мы нежно любим
> всех этих цифровых извращенцев.Тррр! Ну, когда то и Линус был в количестве полутора "как Вы там изволили выразится"!
А сейчас Вы с пеной у рта будете доказывать что другого Бога Вам не надо ;)
Да и Леннарт когда то пешком под стол ходил. Но это ничего не значит.
А то, что они свое дело любят и делают его, это видно.
И кто же виноват, что миллионам пользователей вдруг понадобился такой комбайн как systemd?
Главное в другом,...
> И кто же виноват, что миллионам пользователей вдруг понадобился такой комбайн как
> systemd?ровно те, кто лгут о том, что «миллионам пользователей вдруг понадобился такой комбайн как systemd». это ложь. те, кто распространяют эту ложь — либо идиоты, либо сволочи, либо идиоты-сволочи. других вариантов нет.
Есть такая штука - совместимость. В твоем детском саду про нее, наверное, не рассказывали. Ну вот прикинь - совместимое только с собой пoделие никому не нyжно, кроме малолетних кульхaцкеров и копрорасов, надеящихся поиметь прoфит с вендорлока.
Кроме того, Дебиан не Арчег. Тамошний народ перед тем, как радостно сигануть, привык проверять - а есть ли в бассейне вода. И вообще, бассейн ли это, или сoртирное очко.
> совместимое только с собой пoделие никому не нyжноСледующий RHEL будет уже с systemd, а это значит, что верещащих одминов рано или поздно обяжут изучить systemd и мигрировать на него. Или погонят вон пинками.
> Следующий RHEL будет уже с systemd, а это значит, что верещащих одминов"Верещащие одмины" просто свалят на дебиан и убунту (и правильно сделают).
Особенно те компании, у которых была полноценная поддержка от RedHat, свалят на Debian, чтобы не осиливший systemd одмин оставался один на один с возникающими проблемами, бухоха -))
Не таких компаний, где вендор-лок рэдхэта был бы хотя бы в 10 часть от мс.
Даже без учётов десктопов.
Будут сидеть на шестёрке ещё лет десять, а там всё что угодно сшучиться сможет.
> Особенно те компании, у которых была полноценная поддержка от RedHat, свалят на
> Debian, чтобы не осиливший systemd одмин оставался один на один с
> возникающими проблемами, бухоха -))одминчег локалхоста и папиного компа рассказывает про Мощь Коммерческой Поддержки RedHat. спешите видеть!
> Следующий RHEL будет уже с systemd, а это значит, что верещащих одминов
> рано или поздно обяжут изучить systemd и мигрировать на него. Или
> погонят вон пинками.Не нужно быть семи пядей во лбу, чтобы проэкстраполировать на будущее текущую ситуацию с постепенным снижением доли RedHat и CentOS в пользу тех же Debian и Ubuntu. Если учесть это обстоятельство, то становится ясно, что RedHat своим systemd сами себе роют могилу. Скоро они будут довольствоваться положением Oracle, как поставщиков готовых решений с платной поддержкой, а не универсальных систем под самые разные нужды.
Оставшихся на RedHat фанатиков гнать никуда не придётся - сами отомрут, как _неоправданно_ дорогие и негибкие узкие специалисты.
> обяжутА давайте я Вас обяжу писать здесь стопроцентно грамотно? И даже расстрельная статья под это есть, осталось только применять потщательней.
> Есть такая штука - совместимость....на которую те же бздюки вечно клали с прибором :).
У BSD'шников иное мнение -- достаточно установить /usr/ports/emulators/compatNx, где N -- номер интересующей версии, и совместимость на уровне бинарников у вас в кармане.А что надо установить в Линуксе, чтобы нормально работали бинарники, собранные под ядро 2.2?-)
Ничего, потому что юзерспейсовый интерфейс с тех пор не менялся?
>Ничего, потому что юзерспейсовый интерфейс с тех пор не менялся?Угу. Что у нас там с ядерным dbus?
Он появился. Проблемы?
А что надо установить, чтобы Кольчугин из солярщика стал бздишнегом?Вот и весь секрет.
Гну/линух не проприетарный(!) юних. Кто думает иначе, тот почти что "бывший солярщик".
Как и я кстати.Зыж
Чингаджук два раза на одну и ту же швабру не наступает.
> У BSD'шников иное мнение -- достаточно установить /usr/ports/emulators/compatNx, где
> N -- номер интересующей версии, и совместимость на уровне бинарников у
> вас в кармане.Да, покажите совместимость с линухом выше 2.6.22 - чтоб с LXC/cgroups/kvm? Ну и вообще, кой-кто такой "совместимый" что KMS стали пилить лишь когда жареный петух укусил и оказалось что половина драйверов GPU по другому работать вообще не собираются.
И при чем здесь совместимость? С какой вообще стати система должна быть совместима с бинарниками другой системы? Это не совместимость - это реализация ABI, который, вряд ли сильно изменился со времен 2.6. Ах да, по-моему в линуке и этого нет, не так ли?
Смахивает на то, что вы не в курсе что такое ABI.
> Смахивает на то, что вы не в курсе что такое ABI.оно, кажется, не в курсе, чем отличаются внутренности ядра и предоставляемый наружу интерфейс с ядром. собственно, хэйтеронубьё так и детектируется.
> А что надо установить в Линуксе, чтобы нормально работали бинарники, собранные под
> ядро 2.2?-)в первый раз вижу, чтобы юзермодный софт собирался под версию *ядра*. натурально, если это не юзермодная часть ядерной подсистемы, которая в бсд всё равно работать не будет, как ни эмулируй.
в остальном — я сейчас разрушу твой уютный мирок: сисколы не ломают. прикинь: сисколы, бывшие в той версии ядра, до сих пор работают. да, их не рекомендуют использовать, как устаревшие. но они работают. и софт, их использующий, работает. проверено лично на своём софте со статической линковкой, собраным году эдак в 2k+1. ну да, нечаянно попался под руку старый диск с архивами, собирался сразу выкинуть, но решил глянуть, как молод я был.
>Аргумент 'upstart проще портировать под GNU/FreeBSD' в контексте деба просто убивает.Нужно просто привыкнуть к мысли, что Debian - не дистрибутив Linux. Это отдельная система. Подумайте об этом. Сначала отбросьте все мысли, сделайте глубокий вдох и проникнитесь одной только этой мыслью. Примите её, потом рассуждайте.
>Причем что FreeBSD, замечательной системе, от всего этого ни горячо ни холодно. Она идет своим путем.
Это тоже отдельная система, они всеми силами избавляются в базе от всех наработок, сделанных вне мира BSD. Им вообще никогда не было горячо или холодно. Это NetBSD ещё может быть как-то пытается соревноваться с Linux: внедряет у себя поддержку LVM, работает в Xen dom0 и т.п., но FreeBSD всегда игнорировали существование всего остального мира.
Если взглянуть на дело так, то становится понятно, что Debian - это единственный проект, который заботится о том, чтобы максимально использовать наработки всех разработчиков свободного ПО. И именно поэтому они не должны вставать на сторону лагеря оголтелого Linux'а и отказаться от systemd. Потому что systemd не способствует объединению наработок разных проектов.
P.S. ИМХО, в последнее время становится всё заметнее, что FreeBSD - это прикормыши Apple. Они всеми силами пытаются удовлетворить своего покровителя: избавляются от не-BSD в базе, в том числе от GCC, хотят портировать себе launchd и делают т.п. телодвижения.
> FreeBSD - это прикормыши Appleнеа. у бсдшников просто своё представление о том, как правильно. плохое или хорошее — не важно в данном случае, оно просто другое.
This. А то действительно, давайте еще Debian GNU/Solaris притащим и будем на его особенности ориентироваться.
http://osdyson.org
Вспомнился детский мультик: "Кто похвалит меня лучше всех, тот получит большую и сладкую конфету"
Вообще, очень неоднозначная ситуация. С одной стороны, systemd очень хорош, за ним огромное сообщество и единая система управления демонами на всех крупных дистрах - это плюс, с другой - монополия никогда до добра не доводила, да и неплохо бы дебиану быть независимым от Red Hat (всё-таки Debian и RHEL/CentOS целят в одну нишу).Непростая дилемма, очень непростая.
я вот иногда думаю что разработчика launch для FreeBSD укусил Поттеринг
казалось бы при чём тут Debian/upstart/systemd.
там тоже видно кого укусил Поттеринг
> я вот иногда думаю что разработчика launch для FreeBSD укусил Поттерингlaunchd разрабатывается в apple, причем с первой половины нулевых, а бздишники его только пытаются портировать.
Вообще, у upstart один из аргументов можно смело выкинуть. Если systemd, опережает его по функциональности, то и кода в systemd больше. Значит, в updstart меньше потенциальных багов, раз меньше кода. Они это заявили, как козырь.Я один нахожу этот козырь абсурдным? Почему бы тогда не откатить Firefox до версии 1.0? Там меньше кода, меньше багов. Если уж выдвигают какой-то тезис, так будьте любезны следовать ему.
Предлагаю урезать все программы до "Hello, world!" и жить спокойно.
> Если доводить до абсурда, то так и есть. Идеальная программа по мнению
> противников systemd — это заглушка, которая ничего не делает, но зато
> состоит из двух строчек кода.а идеальная программа по мнению сторонников системды — это вообще отсутствие программы, потому что «это уже внедрено в системды».
> Предлагаю урезать все программы до "Hello, world!" и жить спокойно.DJBDns как-то так и сделан. В результате его так никто и не сломал. Правда, радости от этого мало, т.к. пользоваться им тоже мало кто желает.
>> Предлагаю урезать все программы до "Hello, world!" и жить спокойно.
> DJBDns как-то так и сделан. В результате его так никто и не
> сломал. Правда, радости от этого мало, т.к. пользоваться им тоже мало
> кто желает.Вы про чью радость сейчас говорили?
- DJB
- хакеров
- свою
- всех остальныхМожно выбирать несколько вариантов ;)
Все те дополнительные возможности, которые есть у systemd, давным давно уже реализованы другими проектами, код их отлажен, проверен в продакшене и доказал свою стабильность и надежность. Именно поэтому модульная струкрута, которой следует upstart, содержит меньше кода и проще в поддержке - потому что весть остальной код содержится в других проектах и поддерживают его другие люди. Но фанбоям systemd ведь этого не понять, они то думают, что все на свете придумал ленька потный и без его глюко-софта жизни нет...
> Все те дополнительные возможности, которые есть у systemd, давным давно уже реализованы
> другими проектами, код их отлажен, проверен в продакшене и доказал свою
> стабильность и надежность.И где у этих других проектов запуск KVM-виртуалок? Работа с LXC? Cgroups? Да еще отлаженная. Вы с лора машину времени угнали? Или просто врете с три короба?
>> Все те дополнительные возможности, которые есть у systemd, давным давно уже реализованы
>> другими проектами, код их отлажен, проверен в продакшене и доказал свою
>> стабильность и надежность.
> И где у этих других проектов запуск KVM-виртуалок? Работа с LXC? Cgroups?покажи мне проблему, и будет тебе решение.
> Да еще отлаженная.
и отглаженная.
> Я один нахожу этот козырь абсурдным?Нет, конечно. Дураков кругом, извините - навалом.
> Почему бы тогда не откатить Firefox до версии 1.0?
Потому что браузер - это не init.
Есть области, в которых задача должна быть поставлена четко и функционал должен быть заранее полностью спроектирован и специфицирован. Иначе можно будет в systemd добавлять поддержку логгирования, веб-сервер, фичи для проактивного мониторинга (a-la monit) и т.д. До бесконечности, по желанию левой пятки "погроммиста". Именно это и происходит на практике.
> быть заранее полностью спроектирован и специфицирован.Это ты про свалку скриптокостылей в ините так? Я уже насмотрелся на "прекрасно спроектированные" этажерки по 5 страниц, писаные полными укурками. И после этого полагаю что будет очень хорошо, если те кто так конфигурит систему - отправятся на мороз, к тамбовским волкам. Вместе с такими "спецификациями" по которым логика перемешана с конфигурационными данными.
> "погроммиста". Именно это и происходит на практике.
При том большинство этих задач давно стали типовыми и стандартными вещами в системном администрировании, так что у "погромиста" есть пойнт. Он догадывается что и где костылят.
>> быть заранее полностью спроектирован и специфицирован.
> Это ты про свалку скриптокостылей в ините так?Если ты про sysvinit - то там нету скриптов вовсе. Малыш, ты не знал? Любуйся:
http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/?ro...> Я уже насмотрелся на "прекрасно спроектированные" этажерки по 5 страниц
Можно пример того, что ты считаешь "этажерками, писанными укурками"? Конкретно, с сайта debian.org.
> И после этого полагаю что будет очень хорошо, если те кто так конфигурит
> систему - отправятся на мороз, к тамбовским волкам.После чего "этого"?
> Вместе с такими "спецификациями" по которым логика перемешана с конфигурационными данными.
Это проблемы конкретных дистрибутивов (или даже конкретных пакетов). В Debian есть /etc/default/.
> При том большинство этих задач давно стали типовыми и стандартными вещами в
> системном администрировании, так что у "погромиста" есть пойнт.Типовые и стандартные вещи решаются типовыми и стандартными способами. Зачем тут еще запихивать cron в свой разжиревший "автопилот"? Cron давно работает нормально.
И, боюсь, идиотские socket-activation - далеко еще не стали "стандартными вещами". Вне десктопа, как минимум. А вот некоторые укурки (спасибо за подходящий термин!) - слыхал, в Fedore так уже sshd пущают.
> Если ты про sysvinit - то там нету скриптов вовсе.Да, они есть у тех кто потом прописывает старт демонов.
> Любуйся:
Кого вы хотите надуть? Меня не интересуют ваши жонглирования формальностями.
> Можно пример того, что ты считаешь "этажерками, писанными укурками"?
> Конкретно, с сайта debian.org.Да пожалуйста! Как тебе нравится скрипт udev, с параметрами конфигурации на второй странице? Здорово, правда? Это далеко не хучший пример. Если инсталлить какую-нибудь программу не из репов дебиана - можно и более веселые примеры найти, где скрипт думает что у меня есть какое-нибудь /opt, при том чтобы его переубедить его в этом - надо лезть в середину скрипта и фиксить. А если это творчество кулсисопа который до тебя сервак админил - там вообще волосы на ж...е от ужаса могут шевелиться.
> После чего "этого"?
После натыкания на некоторые поделки которые выпернули под init некоторые индивиды. Так что без фиксинга не работает, а фиксинг достаточно мерзкий, ибо конфигурация бывает размазана по всей простыне.
> Это проблемы конкретных дистрибутивов (или даже конкретных пакетов).
Меня как админа совершенно не интересует как и кто отбрешется от проблем. Меня интересует фактические затраты усилий на администрирование. В том числе и в случае "собрали программу которой не было в репах", например.
> В Debian есть /etc/default/.
А еще в дебиане в репах есть все-таки не все программы. Да и для тех которые есть - скрипты бывают весьма средненькими. См. пример с udev где часть конфигурационных переменных - на второй странице скрипта. Очень, блин, удобно. Особенно когда натыкаешься на такой шедевр и там надо что-то поменять.
> Типовые и стандартные вещи решаются типовыми и стандартными способами.
И где эти решения? И размазня из конфигов в посторонних программах на еще 20 закоулков - тоже как-то не очень прикольно. Кому нравится - флаг ему в руки, а я бы предпочел держать все что связано с запуском программ более-менее в одном месте.
> Зачем тут еще запихивать cron в свой разжиревший "автопилот"?
Затем что я не вижу большой разницы - взлетит ли программа по критерию "о, сетка появилась!" или "о, наступило полшестого". Чего ради это должно настраиваться в разных местах - мне как-то совершенно не очевидно. Более того - это даже до апстартеров дотумкало и такие планы есть и у них IIRC.
> Cron давно работает нормально.
Лично мне не нравится что запуск программ настраивается в куче разных закоулков. Это повышает риск ошибок и усложняет конфигурирование.
> И, боюсь, идиoтские socket-activation - далеко еще не стали "стандартными вещами".
Ну да, и всякие *inetd - нераспостраненный, малопопулярный софт. Правда половина программ почему-то хочет себе такое.
> подходящий термин!) - слыхал, в Fedore так уже sshd пущают.Не вижу чем это так плохо. Только поумнее надо сделать, чтоб порткнокинг еще до этого был. Чтобы боты куковали. А то когда брутфорсеры тяжеленную криптографию в 100 конекций дергают - нагрузка на проц неиллюзорная весьма. Но можно конечно сделать козью морду и в очередной раз предоставить админу самому костылить вполне стандартную проблему.
>> Если ты про sysvinit - то там нету скриптов вовсе.
> Да, они есть у тех кто потом прописывает старт демонов.
>> Любуйся: http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/?ro...
> Кого вы хотите надуть? Меня не интересуют ваши жонглирования формальностями.Ну, если тебя не интересуют факты...
>> Можно пример того, что ты считаешь "этажерками, писанными укурками"?
>> Конкретно, с сайта debian.org.
> Да пожалуйста! Как тебе нравится скрипт udev, с параметрами конфигурации на второй
> странице? Здорово, правда?О каких конкретно "параметрах" в данном случае идет речь? (Разбиение на страницы для меня ровно никакой информации не несет, ты хоть это понимаешь?) "Скрипт udev" - это который?
> Если инсталлить какую-нибудь
> программу не из репов дебиана - можно и более веселые примеры
> найти, где скрипт думает что у меня есть какое-нибудь /opt, при
> том чтобы его переубедить его в этом - надо лезть в
> середину скрипта и фиксить.Debian не использут /opt. Но этот каталог должен у тебя быть по FHS. Если ты его удалил, то буратин именно ты, а уже во-вторых - автор deb-а "не из репов дебиана" (для таких авторов, собственно, /opt и предназначен).
> А если это творчество кулсисопа который до
> тебя сервак админил - там вообще волосы на ж...е от ужаса
> могут шевелиться.Учитывая вышесказанное - я бы на твоем месте задумался о *своей* профпригодности в первую очередь.
>> После чего "этого"?
> После натыкания на некоторые поделки которые выпернули под init некоторые индивиды. Так
> что без фиксинга не работает, а фиксинг достаточно мерзкий, ибо конфигурация
> бывает размазана по всей простыне.В принципе, init-скрипты в том же Debian считаются конфигурационными файлами. Но реально практика их модификации не поощеряется, ты должен использовать /etc/default. Если какой-то пакет данное правило игнорирует - есть багтрекер.
>> Это проблемы конкретных дистрибутивов (или даже конкретных пакетов).
> Меня как админа совершенно не интересует как и кто отбрешется от проблем.Тогда убеди руководство купить RHEL с поддержкой Premium. Ты сможешь спокойно уволиться, а проблемы в дистрибутиве будут решаться - вне зависимости от того какая "Маша" из вашего офиса будет им слать аччтоты об ошибках.
systemd не решит всех проблем, пора бы это уже понять. Особенно те, что техническими вовсе не являются. Он не отменит необходимости сообщать о проблемах в багтракер, следить за их статусом и вообще участвовать в их решении (для community-driven дистрибутивов) и т.д.
> Меня интересует фактические затраты усилий на администрирование. В том числе и
> в случае "собрали программу которой не было в репах", например.Много раз приходилось просто писать новый инит-скрипты в таких условиях. В 99% - достаточно элементарной модификации /etc/init.d/skeleton. Откуда такие адовы проблемы, можно реальный пример?
>> Типовые и стандартные вещи решаются типовыми и стандартными способами.
> И где эти решения?sysvinit, cron, at, udev, monit, скрипты shell. Разные задачи, разные инструменты, разные языки. Это нужно быть *очень* большим фанатом поттцеента, чтобы у****ский INI-формат был для тебя адекватной заменой простому кронтабу (при эквивалентном функционале).
> а я бы предпочел держать все
> что связано с запуском программ более-менее в одном месте.Угу, я понял, в реестре Windows.
>> Зачем тут еще запихивать cron в свой разжиревший "автопилот"?
> Затем что я не вижу большой разницы - взлетит ли программа по
> критерию "о, сетка появилась!" или "о, наступило полшестого".Я правильно понял, что если я выделил в emacs текст и хочу натравить на него aspell - это теоретическое приложение для systemd? "Взлет программы" наличествует, критерий есть. Ы?
> Лично мне не нравится что запуск программ настраивается в куче разных закоулков.
В дебиан - это настраивается в /etc.
>> подходящий термин!) - слыхал, в Fedore так уже sshd пущают.
> Не вижу чем это так плохо.Вот в этом и дело. Что ты "не видишь" очевидных (для любого профессионального системного администратора) проблем: отложенный запуск sshd - это отложенная активация мины. Тупо конфиг sshd побит: может твои кривые ручки постарались перед предыдущим перезапуском сервиса, может файл поврежден. Ты не узнаешь об этом в заранее предсказуемый момент времени (напр., плановый ребут).
> Только поумнее надо сделать, чтоб порткнокинг
> еще до этого был.Вот-вот. Что еще в systemd потянете - OpenOffice?
PS:
С НГ!
>> быть заранее полностью спроектирован и специфицирован.
> Это ты про свалку скриптокостылей в ините так? Я уже насмотрелся на
> "прекрасно спроектированные" этажерки по 5 страниц, писаные полными укурками. И после
> этого полагаю что будет очень хорошо, если те кто так конфигурит
> систему - отправятся на мороз, к тамбовским волкам. Вместе с такими
> "спецификациями" по которым логика перемешана с конфигурационными данными.Нет! Эти "полные укурки" (как Вы изволили выразится), во первых (возможно) ждут от Вас конструктивной критики на счет своих "скриптокостылей", во вторых (наверняка) если не дождутся то наверняка объединятся с systemd и вооооот тогда волосы на Вашей голове не только встанут дыбом но сами вырвутся с корнями (если чо ;)
Ну или одно из двух...
> Если systemd опережает его по функциональности, то и кода в systemd больше. Значит, в updstart меньше потенциальных багов, раз меньше кода. Они это заявили, как козырь.Нужна ли эта функциональность?
> Нужна ли эта функциональность?Мне вот например пригодится. Самолично прошибать все стены своим лбом можно и подзадолбаться.
> Я один нахожу этот козырь абсурдным? Почему бы тогда не откатить Firefox до версии 1.0?Потому что весь большая часть этого самого очешуенного функционала systemd лишняя, нужна только в 0,01% юнитов и легко может быть реализована в самих юнитах через вызов соот-щих утилит. Те же cgroups можно использовать хоть в инитскриптах, хоть в openrc, хоть где-то ещё безо всяких systemd.
Тут уместно сравнивать не с ff, а с Неро самой дорогой и навороченной версии, которые виндовые кулхацкеры обожают ставить на любой чих.
> Я один нахожу этот козырь абсурдным? Почему бы тогда не откатить Firefox
> до версии 1.0?А что с тех пор появилось существенно нового и полезного? По мне так пусть бы и до сих пор была версия 1.0, только пусть в ней совместимость с новыми стандартами ACID делали бы и улучшали производительность. А то маркетинга много, а по-настоящему нового - почти ничего. Только жиреет с каждым годом.
> Там меньше кода, меньше багов. Если уж выдвигают какой-то тезис, так будьте любезны следовать ему.
Ваше утверждение даже оспаривать не собираюсь, потому что оно попахивает приёмами демагога - подменой понятий, предложением ложных альтернатив и утрированием.
> Только жиреет с каждым годом.А бенчмарки, однако, этот тезис не подтверждают...
>> Только жиреет с каждым годом.
> А бенчмарки, однако, этот тезис не подтверждают...парадокс, правда? xD
>> Только жиреет с каждым годом.
> А бенчмарки, однако, этот тезис не подтверждают…если ты хочешь сказать, что Ff двадцать-очередной-версии запускается быстрее первой версии и страницы быстрее первой версии рендерит, то иди проспись, ты уже достаточно возлияний совершил.
Мде, остается надеяться на мудрость Debian'овцев, которая заставит их выбрать systemd, уменьшив, тем самым, кардинально огромный зоопарк стандартов в linux-мире
Стандарты разные нужны.
..... вся сила opensource в наличии альтернатив и возможности выбора обусловленного конечной, прикладной задачей. Если все поголовно перейдут на systemd/upstart/v_pupkin_mego_init то альтернативы не будет.У каждого инита есть свои приимущества и недостатки, главное для меня лично чтоб была нормальная документация, а я уж осилю.
А у systemd на сегодняшний день даже API меняется в зависимости от настроения Леннарта.
Так что рановато его ещё в во все дистры пихать, потом хрен выкосишь.[сообщение отредактировано модератором]
> Мде, остается надеяться на мудрость Debian'овцев, которая заставит их выбрать systemd,
> уменьшив, тем самым, кардинально огромный зоопарк стандартов в linux-миреА если взглянуть на проблему шире и на время вспомнить о том, что Linux - это лишь часть большого мира OpenSource, то upstart выглядит более годной альтернативой, т.к. действительно может уменьшить зоопарк различных систем инициализации: он более универсальный и может работать на разных системах, в то время как systemd остаётся специализированным изделием, не годным нигде кроме мира Linux.
А я считаю ошибкой пытаться объять необъятное - от этого больше проблем чем пользы. Что до systemd, то он прекрасно работает на серверах, на десктопе, на ноутбуке, на SoC, быст, прост, гибок и логичен, поддерживается серьезными компаниями, а не маленькой но гордой canonical, которая, кстати, глядя на их телодвижения, стремится превратить ubuntu во второй android, эдакий хоть и Linux, но ни с чем не совместимую вещь в себе.
А то что systemd не совместимо в freebsd на новом холодильнике samsung так это пардоньте проблемы freebsd и холодильника, если уж так хотят пусть прикручивают слой совместимости, а не хотят - пишут свое, что гораздо правильнее, ведь оно больше нигде кроме этого конкретного холодильника не понадобится.
Множество альтернатив прикладного софта - это несомненно прекрасно, но низкоуровневое API должно быть едино и стабильно, это позволит программистам писать прекрасное прикладное ПО а не отвлекаться на поддержку костылей десятка популярных дистрибутивов.
Т.е. сегодняшняя пресловутая "свобода выбора" есть причина низкого качества 95% прикладного софта для linux и нежелания компаний его писать. А без прикладного софта ОС никому не даром не уперлась.
> systemd … быст, прост, гибок и логичен,Я просто оставлю это здесь: http://www.linux.org.ru/forum/desktop/9990706
> После очередного обновления ... ArchOkay :D
>> После очередного обновления ... Arch
> Okay :DУ арчеводов всегда так, не только с systemd. Они и libc помнится так же обновляли недавно.
>>> После очередного обновления ... Arch
>> Okay :D
> У арчеводов всегда так, не только с systemd. Они и libc помнится
> так же обновляли недавно.пусть арч такой, а он действительно такой. Но где решение для системде? Где спицыаглисты? Или все специалисты собрались тут, расхваливать какой системде - решение всех проблем? Ау, вы нужны там. Помогите чуваку.
> пусть арч такой, а он действительно такой. Но где решение для системде?
> Где спицыаглисты? Или все специалисты собрались тут, расхваливать какой системде -
> решение всех проблем? Ау, вы нужны там. Помогите чуваку.Местные "специалисты" разделы после выдёргивания флешек размонтируют, а ты хочешь, чтобы они что-то умное написали.
> пусть арч такой, а он действительно такой. Но где решение для системде?
> Где спицыаглисты? Или все специалисты собрались тут, расхваливать какой системде —
> решение всех проблем? Ау, вы нужны там. Помогите чуваку.они не могут: заняты написанием постов о том, как системды всех спасёт. им не до мелочных проблем, они Мир Осчастливить желают.
> А я считаю ошибкой пытаться объять необъятное - от этого больше проблем
> чем пользы.Расскажите это Леннарту с Кеем, а?
> Что до systemd, то он прекрасно работает на серверах, на десктопе, на ноутбуке, на SoC
Запихать можно, а вот о "прекрасности" могу поговорить отдельно по всем перечисленным категориям (есть подозрение, что в отличие от Вас).
> быст, прост, гибок и логичен,
Нет. И что самое занимательное, все эти горячие фанбойские сопли радости моментально разбегаются по кустам, когда вылезешь и спросишь о конкретной проблеме.
> поддерживается серьезными компаниями
Вот это вменяемым людям даёт особый повод для опасений -- кто знает айбиэмовский подход вида "и ничего не трогай", тот поймёт.
> Множество альтернатив прикладного софта - это несомненно прекрасно, но низкоуровневое
> API должно быть едино и стабильно, это позволит программистам писать прекрасное
> прикладное ПО а не отвлекаться на поддержку костылей десятка популярных дистрибутивов.Очередной FUD не слышавшего про LSB initscripts. Ну и есть устойчивое ощущение, что в Before/WantedBy/etc запутается даже поставщик, у которого получались инитскрипты хотя бы среднего качества. И "фикситься" это будет ведущим индусским методом биосописателей -- "а мы протестировали на винде" (бишь федоре).
> Мде, остается надеяться на мудрость Debian'овцев, которая заставит их выбрать systemd,
> уменьшив, тем самым, кардинально огромный зоопарк стандартов в linux-миреВы считаете systemd одним из стандартов? Номерочек назовете или это Ваш личный-собственный "стандарт" a la "стандарты" Мерзкософта?
> - Systemd опережает Upstart по возможностям и продуманности архитектуры.Перевотчик может объяснить какой текст в цитированной переписке сподвиг его на сей "перевот"?
>> - Systemd опережает Upstart по возможностям и продуманности архитектуры.
> Перевотчик может объяснить какой текст в цитированной переписке сподвиг его на сей
> "перевот"?https://wiki.debian.org/Debate/initsystem/upstart
https://wiki.debian.org/Debate/initsystem/systemd
http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems
>> - Systemd опережает Upstart по возможностям и продуманности архитектуры.
> Перевотчик может объяснить какой текст в цитированной переписке сподвиг его на сей
> "перевот"?I concluded that systemd has a substantial technical advantage over upstart, primarily in
terms of available useful features, but also in terms of fundamental design.
...
I think the technical comparison between upstart and systemd as both
projects exist today substantially favors systemd, at both the feature and
design level.
мда читаю эту ахинею и охреневаю - все такие правильные - что лять никто не вступается за оставление сисвинит ибо это правильный никс вей, а не поделки хз кого в лице космонафта или шляпы
> мда читаю эту ахинею и охреневаю - все такие правильные - что
> лять никто не вступается за оставление сисвинитИ Jan и Russ - входят в tech-ctte, что уже характеризует уровень
их грамотности. Естественно, что для них недостатки sysvinit
достаточно очевидны. Лучшие пожелания, ваш КО.
ненене мне конкретика нужна, а это так съезд за чужой счет
можешь не отвечать читать не буду у меня почти полтора часа до нового года
> ненене мне конкретика нужна,Фигня вопрос: иди и майнтайни этот скриптошит сам. Вот тебе и будет конкретика. Не забудь рассказать нам о своих приключениях в стране г-нокода.
>> ненене мне конкретика нужна,
> Фигня вопрос: иди и майнтайни этот скриптошит сам. Вот тебе и будет
> конкретика. Не забудь рассказать нам о своих приключениях в стране г-нокода.и тут нет ответа а одно балаболство
Ian. То есть И-ан, а не Ян.
> У systemd более активное, крупное и разноплановое сообщество разработчиков, в которое входят инженеры компанией SUSE и Red Hat. При использовании upstart дистрибутив становится зависим от Canonical, без поддержки которой upstart останется без разработчиков и будет обречён на стагнацию (невозможно предугадать останется Ubuntu на upstart или нет). Для участия в разработке upstart требуется подписание соглашения о передаче имущественных прав компании Canonical.Собственно, после этого решение должно быть очевидно. Canonical славятся тем, что в их багтрекере баги гниют годами, и ничего не меняется. Сколько ни писал туда, сколько не видел багов - часто тянутся с незапамятных времён и ничего не меняется. Типа вот сегодня столкнулся: течёт indicator-applet. За несколько дней набегает гиг. Проблема известна ещё с 2009 года. И? Воз и ныне там.
Зачем нужен Upstart, который непойми как поддерживается? У разрапотчиков которого один Mir на уме...
Одного поля ягода. В systemd тоже всем положить на баги https://bugs.freedesktop.org/buglist.cgi?query_format=advanc... Особенно вот этот доставляет: https://bugs.freedesktop.org/show_bug.cgi?id=55239
> Особенно вот этот доставляет: https://bugs.freedesktop.org/show_bug.cgi?id=55239Отличный баг. Это из разряда законодательного предписания писать в инструкции к бензопиле: "Во включенном состоянии к гениталиям не подносить".
>> Особенно вот этот доставляет: https://bugs.freedesktop.org/show_bug.cgi?id=55239
> Отличный баг. Это из разряда законодательного предписания писать в инструкции к бензопиле:
> "Во включенном состоянии к гениталиям не подносить".Там описана реальная проблема, заключающаяся в невозможности вытащить лог с повисшей намертво системы. Странно, что у тебя это с гениталиями ассоциируется. Видимо, личный опыт.
> Отличный баг.да, очень хороший и показательный. логи — они нужны в том числе и тогда, когда систему напрочь перекосило. системды-лаверы, понятно, живут в стране поняш, где такого не бывает — но пусть уж снизойдут до остальных, которым они пытаются впарить это поделие. не все в стране поняш живут.
> да, очень хороший и показательный. логи — они нужны в том числе
> и тогда, когда систему напрочь перекосило.На десктопе практически только тогда и нужны, когда что-то не работает. Но фиг же объяснишь фанату systemd, что иногда приходится диск читать с помощью dd, т.к. на нём файловая структура слетела, и искать с помощью grep'а содержимое файлов. Или что иногда память битая, иногда диск битый, поэтому начало лога подпорчено.
> Собственно, после этого решение должно быть очевидно. Canonical славятся тем, что в
> их багтрекере баги гниют годами, и ничего не меняется. Сколько ни
> писал туда, сколько не видел багов - часто тянутся с незапамятных
> времён и ничего не меняется.Всяких "песателей" там повидал пачками. На мой вкус - больше таких, что два слова связать не умеют. Возможно, это одна из причин.
А вообще, на статистическое исследование - не тянет.
> Типа вот сегодня столкнулся: течёт indicator-applet.
> За несколько дней набегает гиг. Проблема известна ещё с 2009 года.На баг можешь указать?
https://bugs.launchpad.net/indicator-applet
- не вижу.> Зачем нужен Upstart, который непойми как поддерживается?
Зачем нужен systemd, который непойми как поддерживается? Живой пример:
https://bugs.freedesktop.org/show_bug.cgi?id=53837
Сами ломаем - сами потом в собственном дистрибутиве чиним...
> Зачем нужен Upstart, который непойми как поддерживаетсяапстарт работает.
системд сегфолтится.
зачем 2е нужно да еще на сервере?
> Systemd содержит достаточно самодостаточныйи этим все сказано
> Upstart более прост для портирования на системы, отличные от Linux, в то время как systemd очень жестко завязан на возможностях ядра LinuxСобственно говоря, после этого на всё остальное можно и не смотреть.
systemd это "матрица". Сейчас все передерутся и придет смит.
Вы меня, прикладного программиста, уж извините...
Но!
А в чём проблема текущей системы?
Вроде всё загружается. Я с Дебианом работаю. Там в нужнвю директорию кидаешь самописный скрипт с нужным именем и он при запуске системы отработает.
Уже, вроде, лет 10 так работает.
Зачем менять? Что-то в ядре сильно изменилось?P.S. Я не троллю. Я просто программист, которому иногда приходится чуток поддерживать железо и системы на нём. Киньте ссылку. В чём трагедия?
Все это просто какая-то политическая возня, очевидно же.
> Уже, вроде, лет 10 так работает.
> Зачем менять? Что-то в ядре сильно изменилось?
> P.S. Я не троллю. Я просто программист, которому иногда приходится чуток поддерживать
> железо и системы на нём. Киньте ссылку. В чём трагедия?Трагедия в том, что современные компьютеры могут на ходу менять собственную конфигурацию, а система в процессе этого изменения должна предпринимать соответствующие действия. Прошли те времена, когда достаточно было один раз настроить систему в процессе загрузки. Прошли те времена, когда было вполне комфортно что-то перезапустить вручную. Сейчас настали времена USB, WiFi, планшетных компьютеров. Воткнули 3G-модем - должен не только подгрузиться соответствующий драйвер, должно вывестись уведомление пользователю, сеть должна автоматически изменить конфигурацию. Выдернули флешку - нужно автоматически отмонтировать раздел. Воткнули принтер - нужно автоматически запустить "диспетчер печати", показать пользователю апплет принтера. Воткнули Bluetooth-адаптер - нужно подргузить драйвер, настроить сеть, уведомить пользователя и запустить апплет для обнаружения устройств и обмена файлами по протоколу Bluetooth. Запустили виртуальную машину - нужно настроить на хост-машине сеть для работы с виртуальной машиной. Если DHCP-клиент обновил настройки и получил новый список DNS-серверов, об этом должны узнать все заинтересованные сервисы - кэширующий DNS-сервер, почтовый сервер, прокси-сервер. Вы можете сказать, что это крайне необычная ситуация, когда какой-либо сетевой сервер работает на компьютере с динамически настраиваемым сетевым интерфейсом, но со временем возможных комбинаций таких событий и взаимодействующих сервисов становится всё больше.
Количество возможных вариантов настолько велико, что простые init-скрипты уже не могут покрыть всех необходимых потребностей.
> Трагедия в том, что современные компьютеры могут на ходу менять собственную конфигурацию,Самое интересное, что при всем этом дистрибутив "для десктопа" сидит на апстарте и в ус не дует, а дистрибутиву "для сервера" вожжа под хвост попала... :)
> Прошли те времена, когда достаточно было один раз настроить систему в процессе
> загрузки. Прошли те времена, когда было вполне комфортно что-то перезапустить вручную.
> Сейчас настали времена USB, WiFi, планшетных компьютеров. Воткнули 3G-модем - должен
> не только подгрузиться соответствующий драйвер, должно вывестись уведомление пользователю,
> сеть должна автоматически изменить конфигурацию. Выдернули флешку [...]И это все десктоп. Не, из перечисленного вами - конкретно *все*.
> Вы можете сказать, что это крайне необычная ситуация, когда какой-либо сетевой
> сервер работает на компьютере с динамически настраиваемым сетевым интерфейсом, но со
> временем возможных комбинаций таких событий и взаимодействующих сервисов становится всё
> больше.Ну вот *со временем* какое-то разумное и нормально спроектированное решение и займет нишу systemd. А сейчас init-скриптов "не хватает" (и то, с большой натяжкой) - только для десктопных применений. Надо ли ради этого чинить то, что не поломано?
>[оверквотинг удален]
> и обмена файлами по протоколу Bluetooth. Запустили виртуальную машину - нужно
> настроить на хост-машине сеть для работы с виртуальной машиной. Если DHCP-клиент
> обновил настройки и получил новый список DNS-серверов, об этом должны узнать
> все заинтересованные сервисы - кэширующий DNS-сервер, почтовый сервер, прокси-сервер.
> Вы можете сказать, что это крайне необычная ситуация, когда какой-либо сетевой
> сервер работает на компьютере с динамически настраиваемым сетевым интерфейсом, но со
> временем возможных комбинаций таких событий и взаимодействующих сервисов становится всё
> больше.
> Количество возможных вариантов настолько велико, что простые init-скрипты уже не могут
> покрыть всех необходимых потребностей.ляяя про флешку это жоска - т.е. система инициализации должна предугадать когда юзер выдернет флешку и перед этим ее отмонтировать?
>> Выдернули флешку - нужно автоматически отмонтировать раздел
> ляяя про флешку это жоска - т.е. система инициализации должна предугадать когда
> юзер выдернет флешку и перед этим ее отмонтировать?Ты не понял, у него раздел отмонтируется *после* вытаскивания флешки, а не до!
>>> Выдернули флешку - нужно автоматически отмонтировать раздел
>> ляяя про флешку это жоска - т.е. система инициализации должна предугадать когда
>> юзер выдернет флешку и перед этим ее отмонтировать?
> Ты не понял, у него раздел отмонтируется *после* вытаскивания флешки, а не
> до!ааа - не ну у меня то не по человечески у меня до вытаскивания я сам анмончу.
> Ты не понял, у него раздел отмонтируется *после* вытаскивания флешки, а не до!ну а че ты удивляешься, в системды - всё так ...
> Количество возможных вариантов настолько велико, что простые init-скрипты уже не могут
> покрыть всех необходимых потребностей.самое печальное -- это укурки, полагающие всё вышеперечисленное задачей инита
> Трагедия в том, что современные компьютеры могут на ходу менять собственную конфигурацию,Более того, вещи стали сложными. Могучий сервер хотят пилить на контейнеры и виртуалки, и не очень хотят каждый раз делать закат солнца вручную.
А причет тут инит скрипты?
А wifi, как сейчас работает, без системд и апа? А openvnp и т.п. ? всё уже есть и вроде как пашет.
Нужна какая-то ересь ? Сделайте gnome-init (x11-init/way-init) хрень, которая нужна для десктопа и планшетников. Пусть оставят init в покое !!!
> А wifi, как сейчас работает, без системд и апа? А openvnp и т.п. ?это всё НЕМОДНО!
>[оверквотинг удален]
> и обмена файлами по протоколу Bluetooth. Запустили виртуальную машину - нужно
> настроить на хост-машине сеть для работы с виртуальной машиной. Если DHCP-клиент
> обновил настройки и получил новый список DNS-серверов, об этом должны узнать
> все заинтересованные сервисы - кэширующий DNS-сервер, почтовый сервер, прокси-сервер.
> Вы можете сказать, что это крайне необычная ситуация, когда какой-либо сетевой
> сервер работает на компьютере с динамически настраиваемым сетевым интерфейсом, но со
> временем возможных комбинаций таких событий и взаимодействующих сервисов становится всё
> больше.
> Количество возможных вариантов настолько велико, что простые init-скрипты уже не могут
> покрыть всех необходимых потребностей.Да, да, конечно, и "интырнет" нужен для того, чтобы "вконтактике" сидеть... Как, ты еще не выложил "вконтактике" утреннюю фоточку себя неумытого-небритого? И даже номер и пин-код банковской карточки не выложил? И даже не "твитнул", что уже проснулся и идешь умываться? Ну ты и динозавр! Это же писк современной моды! Все должны так делать! Ну и что, что кто-то деньги с этой карточки уведет - иначе ж не модно и не стильно...
> самописный скриптСамописные скрипты сами по себе могут являться проблемой.
Я вот столкнулся с тем, что в CentOS 5 /etc/init.d/nfsd status возвращает ненулевое значение, даже если сервис работает. В итоге пришлось костылить в своем скрипте.
> А в чём проблема текущей системы?у пацанов из соседнего квартала грузится на пол-секунды быстрее. это же самый важный параметр рабочей системы, неужели не ясно?!
Странный подход, я лично считаю, что нужно при проектах нужно в первую очередь отталкиваться от активности и обширности сообщества разработчиком это хороший показатель для оценки проекта т.к. нужно учитывать последующее развитие и в этом systemd намного выгоднее Upstart так как ребята из Upstart самолично тянут одеяло на себя например пример с Mir поэтому переход на Upstart это заведомо гибельная идея для Debian.
Друзья мои, а вам не кажется странным, что вся ситуация абсурдна? Каждый свое нахваливает, а кто проведет независимую экспертизу? Почему не взять человека, который не будет предвзят (данный спор ему до лампочки), сможет разобраться в вопросе самостоятельно и доверить ему принятие решения?
> Друзья мои, а вам не кажется странным, что вся ситуация абсурдна? Каждый
> свое нахваливает, а кто проведет независимую экспертизу?Потому что она невозможна? Ну как если бы в 41-м вопрос о существовании СССР доверили бы решать "независимой экспертизе" в лице какой-нибудь Швейцарии...
> Почему не взять человека,
> который не будет предвзят (данный спор ему до лампочки), сможет разобраться
> в вопросе самостоятельно и доверить ему принятие решения?Человек должен обладать кучей нетривиальных параметров:
1) пользователи Debian должны ему доверять
2) будущее Debian должно быть ему не безразлично (до этой самой лампочки)
3) должен достаточно хорошо разбираться в Debian с технической стороны
4) в systemd/upstart/sysvinit - такжеКак минимум, первые три параметра уже гарантируют членство человека в tech-ctte.
Самый надежный эксперт - время. Поэтому пусть будет альтернатива systemd. Многообразие пакетных менеджеров никого уже давно не напрягает. Тут будет тоже самое.
> Недостатки Upstart относятся к категории поправимых проблемТонко!
Зачем переделывать то, что работает?
> Зачем переделывать то, что работает?тут как видишь - колесо не достаточно круглое - одним спицы по короче нужны другим подшипники по шире
> Зачем переделывать то, что работает?Затем что работает - понятие растяжимое. Зачем на новый самолет ставят по компьютеру в каждый двигатель? Ведь раньше же и без них как-то работало...
>> Зачем переделывать то, что работает?
> Затем что работает - понятие растяжимое. Зачем на новый самолет ставят по
> компьютеру в каждый двигатель? Ведь раньше же и без них как-то
> работало...То то я думаю что так падают ;)
Видать нечетное число не фонтан ;)
Надо по два ставить!
;)
> То то я думаю что так падают ;)
> Видать нечетное число не фонтан ;)
> Надо по два ставить!
> ;)Ну если бы ты учился где положенно знал бы что только нечёт и минимум 3.
>> То то я думаю что так падают ;)
>> Видать нечетное число не фонтан ;)
>> Надо по два ставить!
>> ;)
> Ну если бы ты учился где положенно знал бы что только нечёт
> и минимум 3.Не знаю где, там, кому, чего, положено ;)
Слава Богу, три все таки больше двух 80)
И таки да, беру обратно свои слова на счет нечетного количества.
Так что теперь буду спокойно спать, при поездках на наземном транспорте ;)
Тут и обсуждать нечего. Есть systemd и есть велосипед для неосиляторов. Это иллюзия выбора. Помните фильм "Матрица", и две пилюли, которые Морфеус предлагал Нео? Там на самом деле не было выбора. Так и тут. Жить иллюзией, что Canonical будет и дальше развивать Upstart - это не вариант. Canonical любит бросать велосипеды не допиленными...
> Тут и обсуждать нечего. Есть systemd и есть велосипед для неосиляторов. Это
> иллюзия выбора. Помните фильм "Матрица", и две пилюли, которые Морфеус предлагал
> Нео? Там на самом деле не было выбора. Так и тут.
> Жить иллюзией, что Canonical будет и дальше развивать Upstart - это
> не вариант. Canonical любит бросать велосипеды не допиленными...от опять детский сад - переверну - есть апстарт и есть велосипед для неосиниляторов
не ну гон чистой воды
разжованные доводы приводите, а не перениначивание слов
стыдно читать
Главный довод - наконец-то мы имеем адекватные юниты, поддающиеся стандартизации, вместо корявых скриптов на баше. Кроме того, очень важна стандартизация. Единая система инициализации приближает нас на шаг ближе к популярности платформы среди обычных пользователей. Кроме того, большим плюсом systemd является агрессивное распараллеливание запуска сервисов.
> Главный довод - наконец-то мы имеем адекватные юнитыИнтересно, безграмотные фанатики поццеринга хоть когда-нибудь прекратят делать вид, что кроме systemd и инитскриптов больше никаких систем инициализации не существует?
> на шаг ближе к популярности
Отсутствие выбора ещё никого ближе к популярности не делало.
> Отсутствие выбора ещё никого ближе к популярности не делало.Да ладно? На офтопик и макось смотрим, медитируем и опять смотрим. И так до полного просветления...
Угу. Смотрим — пользователи, потребители,.. да кого я обманываю?! Ламеры.
Вы кому это впариваете? Мне нужно смотреть на людей кто вообще не знает архитектуры?Популярность в среде профи.
Потому линух и жив.
Несмотря на недоумение мс, ябла, этк.
> Популярность в среде профи.
> Потому линух и жив.
> Несмотря на недоумение мс, ябла, этк.ахрeнeть. На опеннет случайно зашёл хоть кто-то не упopoтый?!?!
Я: "О чём ты говоришь, Рюк? Я между прочем очень вменяемый человек! Я лучший юзер опеннета в японии... и я стану.... богом этого нового мира..." М. Шигорин: "Всё-таки людям порой удается...меня удивить"
> Главный довод - наконец-то мы имеем адекватные юниты, поддающиеся стандартизации, вместо
> корявых скриптов на баше.Чем скрипты на баше (которого в нормальных скриптах вообще не используют) так вам помешали стандартизации? Для текущих LSB (на кое systemd, кстати, плюет) это не является проблемой. Стандарты systemd такие стандарты...
> Единая система инициализации приближает нас на шаг ближе к популярности
> платформы среди обычных пользователей.Остался вопрос - а оно надо?
> Кроме того, очень важна стандартизация.ссылочку на документ-стандарт, описывающий системды, пожалуйста. а то мне как-то затруднительно считать «стандартизованой» систему, у которой в документации пишут, что «доки могут не соответствовать, надёжней всего смотреть исходный код». если ты не в курсе, то я тебе таки скажу: это нечто, прямо противоположное «стандартизации».
inb4: да, апстарт в этом плане тоже не идеал. но «стандартизация» и «системды» — это вообще антонимы.
Структура юнитов в systemd имеет четкую структура(фактически стандарт). У вас просто не получится написать юнит 10 разными способами. А upstart без кривеньких костылей на баше пока нормально инициализировать систему не научился. В результате скрипты на баше всё ещё используются для инициализации. Это ли не позор?
бла-бла-бла. я не просил «бла-бла-бла», я просил ссылку на документ, где описываются стандарты.
> Структура юнитов в systemd имеет четкую структура(фактически стандарт).
> У вас просто не получится написать юнит 10 разными способами.Любезный, Вы их сами-то писали? А я вот писал и разве что матом не ругался, что вообще-то нехарактерно.
И в том числе _именно_ из-за того, что фига с два угадаешь, какой из N большого разных способов эти придурки подразумевали -- решение задачки превращается в подгон под ответ автора (в т.ч. это в сторону Before/After, WantedBy и ещё нескольких плохо документированных полусинонимов).
Попробуйте, что ли, сами уже. А то бегають, хвалють, как оголтелые, а очевидного не замечают.
> Тут и обсуждать нечего. Есть systemd и есть велосипед для неосиляторов.Правда прикол в том что в шестом RHEL этот велосипед. И вообще, велосипед раньше появился. С другой стороны systemd активнее развивается и в нем больше фич нужных при администрировании типовой современной системы. Не на уровне "на дворе 1997 год" а нормально.
Да, беда что в rhel 6 много устаревшего мусора. Но скоро все начнут миграцию на седьмую версию, и проблемы 6 версии станут не актуальны.
> Но скоро все
> начнут миграцию на седьмую версию, и проблемы 6 версии станут не
> актуальны.О, миграция будет, несомненно, отдельной темой для троллинга "счастливых" RH-хомячков. Сама идея миграции на другой init два релиза подряд - говорит о каком-то весьма альтернативном содержимом головы разработчиков. Ну как у Винни-Пуха что-ли...
> Тут и обсуждать нечего. Есть systemd и есть велосипед для неосиляторов. Это
> иллюзия выбора. Помните фильм "Матрица", и две пилюли, которые Морфеус предлагал
> Нео? Там на самом деле не было выбора. Так и тут.
> Жить иллюзией, что Canonical будет и дальше развивать Upstart - это
> не вариант. Canonical любит бросать велосипеды не допиленными...да хоть заминусуйся - у тебя детский гон
С тупого конца бить яйцо или с острого? This is the serious question! :)))))))))))
А обязательно надо чем-то заменять System V init?
Он же работает.
Может, просто обновить, и будет работать дальше?
> Systemd опережает Upstart по … продуманности архитектурыдальше не читал: не смог. живот от смеха заболел.
Столько шума из-за простой системы инициализации. Объясните анонимусу, это действительно настолько важно?
> Столько шума из-за простой системы инициализации. Объясните анонимусу, это действительно
> настолько важно?угу. с этим говном потом кучу лет жить придётся. а инит — таки ключевая штука.
> Столько шума из-за простой системы инициализации. Объясните анонимусу, это действительно
> настолько важно?Systemd — это не система инициализации. Systemd — это комбайн, куда поццеринг пытается свалить всё, что только можно (странно, что он ещё пульсу с ним не объединил). Причём если принцип unix-way гласит "программа должна выполнять одну функцию и выполнять её хорошо", то Поццеринг делает всё по принципу "давайте напихаем в одну сущность как можно больше всего, а там патчами допилим. Как-нибудь. Может быть. Когда-нибудь."
Хотя сам сижу на rpm-based и на systemd, но искренне желаю, чтобы Debian перешёл на upstart. Потому что должны быть альтернативные решения в мире открытого софта! Да здравствует здоровая конкуренция!!!Всё таки, systemd очень жёстко контролируется Redhat'ом. При всём моём уважении к этой конторе с её стороны всё-таки прослеживается тенденция взятия под контроль ключевых технологий Linux. RH постепенно подминает все главные технологии под себя и загоняет их в рамки 2-3 проектов -- Gnome, systemd и wayland. Сейчас они прогрессивные, а в перспективе могут превратиться в монополистов в мире Linux. А вот этого как раз и не надо!
> Хотя сам сижу на rpm-based и на systemd, но искренне желаю, чтобы
> Debian перешёл на upstart. Потому что должны быть альтернативные решения в
> мире открытого софта! Да здравствует здоровая конкуренция!!!Согласен.
А еще лучше, пусть будут обе!
Тем более, что есть http://www.opennet.me/opennews/art.shtml?num=34623
И popularity-contest всем админам повключать, что бы знали что где используется.
Кстати, кто знает в защищенном ли виде popularity-contest данные передает или нет?
http://popcon.debian.org/FAQ===
Q) What are the privacy considerations for popularity-contest ?A) Each popularity-contest host is identified by a random 128bit uuid
(MY_HOSTID in /etc/popularity-contest.conf). This uuid is used to
track submissions issued by the same host. It should be kept secret.
The reports are sent by email or HTTP to the popcon server. The
server automatically extracts the report from the email or HTTP and
stores it in a database for a maximum of 20 days or until the host
sends a new report. This database is readable only by Debian
Developers. The emails are readable only by the server admins.
Every day, the server computes a summary and post it on
<http://popcon.debian.org/all-popcon-results.txt.gz>. This summary
is a merge of all the submissions and does not include uuids.
Known weaknesses of the system:
1) Your submission might be eavesdropped. We evaluate the possibility
to use public-key cryptography to protect the submission while in
transit.
2) Someone who knows that you are very likely to use a particular package
reported by only one person (e.g. you are the maintainer) might infer you
are not at home when the package is not reported anymore. However this is
only a problem if you are gone for more than two weeks if the computer is
shut-down and 23 days if it is let idle.
3) Unofficial and local packages are reported. This can be an issue
due to 2) above, especially for custom-build kernel packages.
We are evaluating how far we can alleviate this problem.
===
> http://popcon.debian.org/FAQСпс.
Примерно где то так и представлял.
Пусть "разные" люди знают, что мы используем. Может им пригодится, для чего нибудь хорошего!
Ведь эта вещь в основном нужна для определения наполнения 1-го CD диска (где то слышал).
Так что безопасность на серверах особо не затронет (так как на серверах ее обычно не включаю).
В плане "монолит" vs "модульность" однозначно выигрывает upstart, поэтому ДАЖЕ при наличии недостатков в последнем, разумнее бросить силы на их устранение, чем опять бессмысленно перелопачивать "несовместимые" системы под systemd. Историй с "монолитом" мы уже накушались, спасибо Трольвадсу.Мне кажется, для более конструктивного спора нужно выписать главные задачи инициализатора (как абстрактной программы) и затем смотреть, какой из нынешних к нему ближе и в какую сторону его можно допилить. Да чо там, можно и новый написать! :) Но всегда нужно помнить, сегодня это "прога1", завтра это "прога2" - нужно старательно поддерживать взаимозаменяемость. Дистрозависимые вещи сразу в топку.
Линус создал может и некрасивое, но зато работоспособное и очень эффективно использующее системные ресурсы ядро. А Minix, Hudrd и некоторые другие красивые академические подделия до сих пор не юзабельны. Лучше дистрозависимое, но эффективное решение, чем красивый кроссплатформенный велосипед, который при этом работает крайне медленно, и не эффективно.
Смешно.Леня создал полуработающее, глючащее, падающее в сегфолт НЕХ и это сравнивается с УЖЕ работающим нормально апстартом :)
Ах да... Про то... что апстарт УЖЕ давно хорошо работает - к RH-6
Вы хотя-бы пользуетесь дистрибутивом с systemd? Если бы пользовались, знали бы что systemd не падает. И не глючит. Видно, что вы ничего кроме бубунты в своей жизни не видели.
Вы читать умеете, что вам пишут? :)https://bugzilla.redhat.com/buglist.cgi?quicksearch=Componen...
7 bugs found
https://bugzilla.redhat.com/buglist.cgi?quicksearch=Componen...
269 bugs found:)
Ах, да...
Конечно можно сказать, что системд это комбайн и так сравнивать не честно, бла-бла-бла
Или как любят системд-филы - на моем локалхосте ошибок нет :)))
> Вы читать умеете, что вам пишут? :)
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Componen...
> 7 bugs found
> https://bugzilla.redhat.com/buglist.cgi?quicksearch=Componen...
> 269 bugs found
> :)
> Ах, да...
> Конечно можно сказать, что системд это комбайн и так сравнивать не честно,
> бла-бла-бла
> Или как любят системд-филы - на моем локалхосте ошибок нет :)))А вы не думали, что systemd банально имеет более большую кодовую базу. И что часть данных багов относится к udev и некоторым другим подсистемам, которые напрямую не связаны с инициализацией? Да и кто сказал, что в upstart меньше багов? Может их просто искать некому? И баги upstart, как неуловимый Джо, просто никому не нужны(кроме Canonical)?
> баги upstart, как неуловимый Джо, просто никому не нужны(кроме Canonical)?Напоминаю, что upstart является также частью RHEL.
>> баги upstart, как неуловимый Джо, просто никому не нужны(кроме Canonical)?
> Напоминаю, что upstart является также частью RHEL.И зачем он дебиану?
Пусть красношапка и мучается с этим велосипедом :)
Или им бетатестеры нужны чтоб им это тестили?
в смысле зачем им дергаться на апстарт или системд?
>>> баги upstart, как неуловимый Джо, просто никому не нужны(кроме Canonical)?
>> Напоминаю, что upstart является также частью RHEL.
> И зачем он дебиану?В принципе, что-нибудь-действительно-лучше-чем-sysvinit - категорически приветствуется. systemd/upstart/runit/openrc/тъмаих - возникли не на пустом месте...
Как-бы трудозатраты и проблемы при впиливании "нового-прогрессивного" не превысили на порядки трудозатраты на поддержку "проверенного старого".
Все же используют за стабильность и здоровую консервативность...А то, не буду говорить на каком дистрибутиве, когда кроме кучи проблем и непоняток, оказалось, что еще на некоторых конфигурациях железа получается и последний довод системдфилов не работает - пользователи жалуются, что скорость загрузки с системд заметно меньше чем с sysvinit - уж совсем как-то с недоумением смотришь - а нафига нужно было такие титанические усилия для перехода тратить... Хотя поттерингоподелка максимально осложняет жизнь всем, кто использует альтернативные решения....
:)Фанатики так предсказуемы :)
Ну удаче Красношапке... Ведь в глючном апстарте РХ-6 целых 7 багов, а в божественном системд всего 269 :)
удачи, пардон...
>[оверквотинг удален]
>> :)
>> Ах, да...
>> Конечно можно сказать, что системд это комбайн и так сравнивать не честно,
>> бла-бла-бла
>> Или как любят системд-филы - на моем локалхосте ошибок нет :)))
> А вы не думали, что systemd банально имеет более большую кодовую базу.
> И что часть данных багов относится к udev и некоторым другим
> подсистемам, которые напрямую не связаны с инициализацией? Да и кто сказал,
> что в upstart меньше багов? Может их просто искать некому? И
> баги upstart, как неуловимый Джо, просто никому не нужны(кроме Canonical)?Дайте слово тупому, особенно в кодовой базе systemd ;)
Но, масло масляное потому, что масло масляное! Супер!!!
udev который год нормально работает! Чо, с копипастить NIH не позволяет?
А если о людях, Лннарт молодец, дело делает, респект!
> А если о людях, Лннарт молодец, дело делает, респект!Вот именно, что пока неосиляторы злопыхательствуют, Леннарт дело делает. Именно благодаря таким людям как он, Linux развивается, становится самобытной ОС, а не ещё одной Unix-like ОС.
> Вот именно, что пока неосиляторы злопыхательствуют, Леннарт дело делает.да это-то мы знаем: лёня наделает — остальные за ним подтирают.
> Именно благодаря
> таким людям как он, Linux развивается, становится самобытной ОС, а не
> ещё одной Unix-like ОС.купи себе мак и уйди уже на Офигенную Самобытную ОС.
> Вы хотя-бы пользуетесь дистрибутивом с systemd? Если бы пользовались,
> знали бы что systemd не падает.Врать хватит, а?
http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg
> И не глючит.
Да-да, конечно (ц)
206+ у меня тормозит выключение livecd, уделяя непрошеное пристальное внимание юзерской сессии. Отваливается по таймауту где-то через минуту. Как это предлагается отлаживать -- ума не приложу.
Если всё так плохо, то почему у меня Fedora 20 работает как часы?
> Если всё так плохо, то почему у меня Fedora 20 работает как часы?Потому что Ваше использование systemd не подпадает под "шаг влево/шаг вправо", видимо.
Ссылку на fd.o-шный багтрекер уже давали, а вот на только systemd (без субпакетов) только на F20 -- 51 NEW, 1 ASSIGNED: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...
Есть некоторая надежда, что где-нибудь к RHEL7.1 это недоразумение чуточку приведут в чувство, но за диверсии и сознательную ложь предыдущих двух лет апстрим когда-то ответит.
> 206+ у меня тормозит выключение livecd, уделяя непрошеное пристальное внимание юзерской
> сессии. Отваливается по таймауту где-то через минуту. Как это
> предлагается отлаживать -- ума не приложу.Ну как... Известно как:
https://wiki.debian.org/Debate/initsystem/systemd#Various_ot...
"Systemd makes it easy to debug services, without the need to resort to a debugger" (ц)А мне намедни мейнтейнер сего опуса упрекнул в недостатке профессионализма (политкорректно выражаясь), когда я ему приводил кучу более очевидных (включая буквальные сегфолты из багтрекера systemd) причин для использования gdb при отладке этого C-глюкодрома. Намекая тем самым на нетривиальность процесса...
Глядя правде в глаза: upstart штука слабенькая, до возможностей systemd не дотягивает. Вендорозависимость обоих проектов одинакова. Systemd is linux-only, но kFreeBSD и GNU/Hurd отличаются не только ядром, но и ненулевым количеством юзерспейса. Ну будет на одно различие больше.
> Глядя правде в глаза: upstart штука слабенькая, до возможностей systemd не дотягивает.В смысле? Еще не содержит OpenOffice?
> но kFreeBSD и GNU/Hurd
> отличаются не только ядром, но и ненулевым количеством юзерспейса.И там и там - userland GNU. Естественно, какие-то специфичные для ядра утилиты (типа ufsutils) - имеются.
Есть ещё третий вариант - оставаться на sysvinit
sysvinit ведь работает - в т.ч. в стабильном Дебиане (поправьте, если ошибаюсь).
Почему мэйнтейнеры хотят от него отказаться?
Так ли это необходимо?
Может, его просто надо обновить?
> sysvinit ведь работает - в т.ч. в стабильном Дебиане (поправьте, если ошибаюсь).Работает, но как?
> Почему мэйнтейнеры хотят от него отказаться?sysvinit - старое УГ, не поддерживающее параллельную загрузку сервисов, и учёт зависимостей. При агрессивном распараллеливании без учёта зависимостей стартующих сервисов начинает такое твориться, что лучше сразу от распараллеливания отказаться.
> Так ли это необходимо?Если вы хотите, что-бы ваша ОС загружалась быстро, как восьмой оффтопик - то да, необходимо. Если вас устравивает, что-бы ОС грузилась по несколько минут - можете оставаться на sysvinit.
> Может, его просто надо обновить?Сама архитектура sysvinit убога. Тут никакие костыли не помогут. Данная система создавалась в эпоху одноядерных и однопроцессорных ПК. Тогда строго последовательная загрузка сервисов с runlevels казалась хорошим решением. Проблему инициализации решили красиво и просто, в духе философии Unix. Но с появлением многопроцессорных систем, а особенно с массовым распространением многоядерных процессоров, sysvinit стал камнем преткновения. Очень уж медленно из-за него загружалась система. Вы видно не застали той эпохи. В то время как Windows и MacOS X грузились быстро, Linux(до появления upstart) грузился крайне медленно. Вы достаньте какой-нибудь дистрибутив Linux начала двухтысячных - сильно удивитесь его неторопливой загрузке(особенно на железе той эпохе, в VirtualBox на актуальном железе всё ещё не так плохо)...
>> sysvinit ведь работает - в т.ч. в стабильном Дебиане (поправьте, если ошибаюсь).
> Работает, но как?Нормально.
>> Почему мэйнтейнеры хотят от него отказаться?
> sysvinit - старое УГ, не поддерживающее параллельную загрузку сервисов, и учёт зависимостей.Выпей яду, а? Какого черта ты пишешь о Debian, если понятия не имеешь что и как там работает. Есть там и "параллельная загрузка" и "зависимости". И дураков заметно меньше...
> с массовым распространением многоядерных процессоров, sysvinit стал камнем преткновения.
А по-моему - как обычно, некомпетентные идиоты...
> Очень уж медленно из-за него загружалась система.
Ох, бяда... Школие добралось до линукса.
http://www.youtube.com/watch?v=zvYqbM33QQ8
Уважаемый, стандартный sysvinit не имеет параллельной загрузки. В Debian изобрели костыль для того, что-бы обеспечить данную фичу. Не верите? Почитайте зачем в Debian засунули insserv. Ну и про то, каким уродливым методом обеспечили учёт зависимостей(нужные зависимости прописывают в комментарии(получается такая своеобразная аннотация) init-скрипта, написанного по стандарту(сюрьприз) LSB(на баше, конечно-же). Более уродливого решения в жизни не видел. И да, insserv это не sysvinit. Можно сказать, что в Debian 6 и Debian 7 используется своя, ни на что не похожая система инициализации, обратно совместимая с systemv init. Кстати Debian я юзал тогда, когда вы ещё пешком под стол ходили. Так-что про шлололо вы зря шутить изволили.
> стандартный sysvinit не имеет параллельной загрузкиНу я понимаю зачем это в RH-7 - судя по статистике они решили теперь переключиться на пиление ОСи для планшетов, а дебиану то это зачем?
Debian 32.8%
Ubuntu 26.9%
CentOS 25.1%
Red Hat 8.3%
Fedora 2.4%
http://w3techs.com/technologies/history_details/os-linux/all/y
> Уважаемый, стандартный sysvinit не имеет параллельной загрузки.Речь о Debian.
> Ну и про то, каким уродливым методом обеспечили
> учёт зависимостей(нужные зависимости прописывают в комментарии(получается такая своеобразная
> аннотация) init-скрипта, написанного по стандарту(сюрьприз) LSB(на баше, конечно-же).Это "уродливость" из-за того, что в Debian соблюдают стандарты. И да, нет там никакого "баша", "юзалшик".
> Кстати Debian я юзал тогда, когда вы ещё пешком под стол ходили.Тебе просто по манере речь - существенно больше 20-ти не дашь, а уж про то, чтобы ты Debian 10+ лет использовал...
>Речь о Debian.Вот именно, речь о Debian. В котором к уродливому sysvinit прикрутили кривой костыль для обеспечения возможности параллельной загрузки.
> Это "уродливость" из-за того, что в Debian соблюдают стандарты. И да,
> нет там никакого "баша", "юзалшик".Выполните команду
cat /lib/lsb/init-functions
в терминале, пожалуйста. И узрите обыкновенный shell-скрипт, который выполняется при помощи (вот сюрприз-то!) Bourne shell или Bourne Again Shell(или любой другой совместимой с Bourne Shell оболочки). А ведь данный файл инклудится практически во все стартовые скрипты, написанные по стандарту LSB.
> Тебе просто по манере речь - существенно больше 20-ти не дашь, а
> уж про то, чтобы ты Debian 10+ лет использовал...Что конкретно не так с моей речью? То, что она вам не нравится - ваша личная проблема. 10+ лет назад я не юзал Debian(где-то 9 лет назад я юзал Gentoo и Knoppix), да и сейчас юзаю только периодически. По рабочей необходимости. Не люблю я Debian. Мне Centos и Fedora ближе. Когда-то у меня был RedHat - это был достойный дистрибутив. А Debian - вроде всем хорош, но у меня не приживается. Пресный он какой-то.
И да, я ещё аниме и некоторые мультики смотрю, несмотря на то, что родился в первой половине 80-х годов 20 века. И что, вы теперь ещё и над этим стебаться будете? Инфантильность - не повод для стёба.
>>Речь о Debian.
> Вот именно, речь о Debian. В котором к уродливому sysvinit прикрутили кривой
> костыль для обеспечения возможности параллельной загрузки.В котором все это есть. А об уродливости пусть судят разработчики Debian, а не форумная школота.
Что уродливого в данной конкретной реализации стандарта?
>> Это "уродливость" из-за того, что в Debian соблюдают стандарты. И да,
>> нет там никакого "баша", "юзалшик".
> Выполните команду
> cat /lib/lsb/init-functions
> в терминале, пожалуйста. И узрите обыкновенный shell-скрипт, который выполняется при помощи
> (вот сюрприз-то!) Bourne shell или Bourne Again Shell(или любой другой совместимой
> с Bourne Shell оболочки).Я вижу обычный POSIX-shell скрипт (но никак не bash). Это только явно не отмечено соответствующим sha-bang'ом в первой строчке. Но его ты можешь узреть в любом скрипте, что включает этот файл:
$ head -1 /etc/init.d/atd
#! /bin/sh> 10+ лет назад я не юзал Debian
Шош-ты тогда пиписьками меряться удумал, малыш?
> Я вижу обычный POSIX-shell скрипт (но никак не bash). Это только
> явно не отмечено соответствующим sha-bang'ом в первой строчке. Но его
> ты можешь узреть в любом скрипте, что включает этот файл:
> $ head -1 /etc/init.d/atd
> #! /bin/shДа вкурсе я, что скрипты запускаются Bourne Shell, а не Bash. В initrd мало кто добавляет bash, для сценариев инициализации хватает старичка sh.
> Шош-ты тогда пиписьками меряться удумал, малыш?
Расскажи-ка дяденька, что ты использовал 10 лет назад. Могу поспорить, что оффтопик. А на Linux перешёл год-два назад, да и то случайно. Поэтому не застал тормозов мерзкого sysvinit. И не собирал ядро ручками(после наложения необходимых патчей) для того, что-бы заработало что-то из периферии твоего ПК. Не тебя меня учить, лучше сам учи матчасть. Или сходи на lor, потроль таких-же юных подаванов, как сам.
>> Я вижу обычный POSIX-shell скрипт (но никак не bash). Это только
>> явно не отмечено соответствующим sha-bang'ом в первой строчке. Но его
>> ты можешь узреть в любом скрипте, что включает этот файл:
>> $ head -1 /etc/init.d/atd
>> #! /bin/sh
> Да вкурсе я, что скрипты запускаются Bourne Shell, а не Bash.POSIX sh, а не Bourne Shell, дубина. Вообще, если б был в курсе, не писал бы фраз вида "на баше, конечно-же".
> Расскажи-ка дяденька, что ты использовал 10 лет назад. Могу поспорить, что оффтопик.
Проспорил.
> POSIX sh, а не Bourne Shell, дубина. Вообще, если б был
> в курсе, не писал бы фраз вида "на баше, конечно-же".POSIX sh, это стандартизированное подмножество возможностей оболочки. У которого есть много реализаций. В частности при загрузке чаще всего используется ash. Но поверьте, если вы замените её любой другой реализацией, ваши скрипты сработают точно так-же. А основой для POSIX Shell был как раз Bourne Shell. На не важны конкретные фичи тех или иных оболочек. Скрипты для них я всё равно буду называть баш-скриптами. Просто потому, что я использую bash. И мне всё равно, как их называют другие. Не всё копировальное оборудование производит фирма Xerox. Но в обиходе подобная техника всегда называется одинаково - ксерокс. Так и со скриптами. Я же не указывал, какое именно подмножество фич оболочки используется в данных скриптах. Мне это и не важно, честно говоря.
> Проспорил.
Угадал, а не проспорил. Так будет вернее.
Потому что майнтейнерам надоело писать инит-скрипты методом копипасты для каждого демона и типичные задачи они хотят видеть автоматизированными, причем, чтобы в результате был конфиг, а не еще один тьюринг-полный скриптовый язык.
а) отучаемся говорить за всю сеть;
б) любой конфиг стремится превратиться в turing complete; есть мнение, что проще не заниматься онанизмом, а взять уже готовый sh (в котором, кстати, нет приказа под страхом смерти использовать всякие условия и циклы).
> Потому что майнтейнерам надоело писать инит-скрипты методом копипасты для каждого демонаОх, дурилка, каждый школьник теперь за мейнтейнеров Debian готов распинаться. Уж если это настолько суровая проблема - отчего с копипастой не разобрались ранее? Свести типовой конфиг сервиса (а-ля /etc/init.d/skeleton) к паре строчек - дело нехитрое.
Блин.. уже надоело читать. Только одно набрасывание г..на на вентилятор.
Если всем видны недостатки и того и другого, почему никто не возьмется за написание true unix-way системы инициализации?
> Если всем видны недостатки и того и другого, почему никто не возьмется
> за написание true unix-way системы инициализации?потому что их есть уже, и они работают. правильных путей — удивись — много. как и неправильных. «и единою волей сковать» — это в m$ или огрызок.
но да: системды — путь неправильный. атака бегемотов-мутантов.
> почему никто не возьмется
> за написание true unix-way системы инициализации?Так взялись же уже: https://github.com/OpenRC/openrc
> ... догнать systemd по функциональности (например, перевёрнутая модель запуска зависимостей (вместо запуска всех требуемых зависимостей при старте заданного сервиса, запуск службы в Upstart осуществляется при поступлении события о готовности к работе зависимостей)Это как? Как Петя может ехать на автомобиле, если Вася не принес бензин? (В Пети не дизель и не электромобиль)
IMHO: Уж лучше пользоваться Upstart, нежели портом launchd который сделал писака pulseaudio
Ох, угораздило же под Рождество засунуть нос в новогоднюю тему, касающуюся systemd...Пожелаю-ка лучше всем присутствующим в новом году осмысленной, полезной, продуктивной и радостной работы, крепкого здоровья, разумных вариантов и достойных решений. Ну и поменьше лживой пропаганды, а побольше мира.
Upd:Кажется, Ian склоняется теперь к поддержке нескольких инитов:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#3180
