Пакеты, использующие System V init, будут удалены из Fedora 24

2) Задержка для всяких там smb в fstab

Параметра _netdev не хватает?

Ну так и в sysV-инсталляциях все работало. Зачем чинить несломавшееся?

Ты пытаешься сравнить свободное программное обеспечение с проприетарным?

Вендорлок systemd - это как раз привет из проприетарного мира. С точки зрения оценки работы софта, то тут личные взгляды больше влияют чем свободное/проприетарное. Мне не сложно отослать багрепорт для хорошей сделанной с душой платной программы, но вот для некоторого глючного и уродливо сделанного открытого софта - проще удалить его на...совсем.

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

Если есть время и вдохновение - можно даже патч прислать :)

Там было демократичное голосование и публичное обсуждение. Тебе не нравится демократия?

Это когда десять идиотов решают как жить одному умному? Нет, в таком виде демократия это профанация системы принятия решений. Решения должны принимать подготовленные, профессиональные и ответственные люди, прошедшие ценз, а не юные фанатики.

Нет. Просто dnf'ы с yum'ами не умеют в нормальный менеджмент пакетов, переписывая все конфиги подряд, не спрашивая.

Чем слака настраивается? Ансибл или там чеф с паппетом?

Slackware, CRUX, Gentoo, LFS (последний - с оговорками).

Руками. Эти проги знать не знают кучу всего :)

https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html

Вендорлок systemd - это как раз привет из проприетарного мира. С точки зрения оценки работы софта, то тут личные взгляды больше влияют чем свободное/проприетарное. Мне не сложно отослать багрепорт для хорошей сделанной с душой платной программы, но вот для некоторого глючного и уродливо сделанного открытого софта - проще удалить его на...совсем.

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

И да, ты можешь удалить его совсем, и выбрать дистрибутив без него. Только потом глупо и неэтично ныть о недостатках софта, который тебе не понравился, если ты не делал баг-репорты и вообще никак не связывался с разработчиками. Другое дело, когда ты кардинально против принципиальных решений разработчиков. И когда у тебя есть аргументы.

Это когда десять идиотов решают как жить одному умному?

Это ты так девелоперов дебиана обозвал идиотами? Игнорируя то, что была публичная дискуссия, аргументы которые в ссылке выше? В любом случае, проигравшее несогласное меньшинство пошло пилить свой Devuan, слава Free Software.

ну линукс по-моему достаточно гибкий и настраиваемый. сложный конечно но в плане адекватности архитектуры все еще дергает всякие системд и аппармор, не говоря уже о NT

Ubuntu-то не собирается втюхивать Systemd даже в 16.04, есть еще 14.04, 12.04...

Эмм. В 15.04 уже давно было.

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

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

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

Хахаха! Смотрите на него! Неосилятор который не может выучить новую технологию! Луддит! Ретроград! Чертов консерватор!

с*ка, аж бесит! дайте кирпич, я ему въ**у.

На офф-топике тоже багрепорты слать?

Ты пытаешься сравнить свободное программное обеспечение с проприетарным?

в части багрепортов нерелевантно. И в проприетарь, и в системд на часть багрепортов кладут NOTABUG.

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

Дотнет тоже свободен. Не всем охота ввязываться в это болото.

Пакеты, использующие System V init, будут удалены из Fedora 24

а пользователи, использующие System V init, будут расстреляны.

этот _netdev не работает по факту, толи он только для NFS, толи еще что - не помню

стоило бы поучиться аргументации у этих ребят https://wiki.debian.org/Debate/initsystem/ (а конкретнее https://wiki.debian.org/Debate/initsystem/systemd)

А давайте ради интереса откроем страницы других инитов, участвовавших в тех дебатах и почитаем про FUD со стороны поттера и ко.

upstart (https://wiki.debian.org/Debate/initsystem/upstart), секция «Rebuttals»:

* The systemd position statement incorrectly identifies Ubuntu bug #406397 as a fundamental design issue due to the use of ptrace. This is a longstanding bug, but it is not fundamental to the use of ptrace. It would be a good idea to obsolete the use of ptrace in the future for its own sake, but this bug exists primarily because upstart provides more granular definitions of service readiness that are not available in systemd.
* The systemd position statement claims that the Upstart dependency tree is «upside down» by starting services when their dependencies are ready, instead of starting the service's dependencies when the service should be started. This ignores the reality that a Linux system is fundamentally event-driven. It is meaningless to suggest that all the dependencies should be auto-started, when some of these dependencies will be tied to hardware events that the init system does not control. This merely repeats the existing flaws with sysvinit.

и так далее, ещё 7 пунктов откровенного подлога и очковтирательства.

openrc (https://wiki.debian.org/Debate/initsystem/openrc), секция «Rebuttals»:

* From the Systemd page: «one of the primary improvement of OpenRC over the sysinit is cgroups» - it's wrong, cgroups are just a minor feature that can extend some use-cases, however pros on this page describes much more features that come with OpenRC (to not duplicate them here). Systemd authors and supporters are trying to let everyone believe that cgroups is the best thing invented since sliced bread, and that it is very complex, which isn't truth.
* From the Systemd page: «The primary selling point of OpenRC is that it is portable. Otherwise, it is merely a sysvinit on steroids.». Well, again, that's not truth, OpenRC does a lot more than just this, this shows very little understanding and investigation from the author of these words.

И так далее, ещё 5 пунктов.

Вас не удивляет, что сразу 2 разных команды разработчиков сподобились написать такие секции?

Поделка поттеринга пропихивалась любыми методами, вплоть до давления на членов CTTE, «внезапных» переносов сроков голосования и многократного назначения повторного голосования.

Тоже неправильно. Вообще, yum и dnf тут, можно сказать, не при чём. Если rpm-пакет собран как нужно, и конфиги отмечены как %config, то они не будут перезаписываться - будет создаваться новый конфиг с расширением .rpmnew

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

Говна уже наелись от редхата в виде системд. Закапывайте уже.

Как «эти проги» могут не знать кучу всего, когда плейбуки/рецепты ты сам пишешь?

Если действительно чего-то не хватает, то можно отправить фичреквест или даже патч.

Вообще я у Stanson пытался узнать, что у него за продакшен такой на слаке. Просто складывается ощущение, что у него максимум серверов 10 в которые он лазает руками и читает от нечего делать sysv init скрипты.

Или это просто в вашей федоре при обновлении пакета затираются ещё и конфиги со скриптами?

Все, что в rpm-спеке помечено как %config, сохраняется, прочее перезаписывается. Кому и для чего нужно считать скрипты конфигами?

Просто dnf'ы с yum'ами не умеют в нормальный менеджмент пакетов, переписывая все конфиги подряд, не спрашивая.

4.2

Ты не поверишь, у них не было и нет инитскриптов.

Просто это не задача, а баг.

Просто это не задача, а баг.

Какой баг, позвольте осведомиться?

Смотря что понимать под надёжностью.

Это когда после падения init система продолжает работать, а не уходит в kernel panic, как это происходит с systemd.

p.s. Да, встречал самолично. Да, на реально работающей системе. Нет, это был далеко не локалхост.

скажите вы сторонник systemd или противник?

Ахаха)) да, неоднозначно получилось. Я подхватил ваш фарс :)

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

проигравшее несогласное меньшинство пошло пилить свой Devuan, слава Free Software.

Кстати, как там у них дела? А то деньги они собирали, а теперь от них ни слуху ни духу. Даже БСД решили пилить свой функциональный аналог systemd (и чем чёрт не шутит - получится лучше, может его и возьмут все на вооружение как взяли systemd вместо upstart'а).

получится лучше

да у любого слепого, глухого и тупого получиться лучше чем у поттера!

стандарт де-факто

Прям как венда.

Проектирования. На пальцах, на примере nfs: по принципу s-d, надо дождаться поднятия линка, чтобы смонтировать шару. По принципу сисадминов прошлого, надо правильно настроить автомаунт и привязать к локальной фс.

уходит в kernel panic, как это происходит с systemd

4.2, дальше не читал.

дальше не читал

Ты бы мудила даже если бы читал то не понял бы

В данном случае виновато ядро. Приложения пользователя (в том числе система инициализации) не должны вырубать ядро

да у любого слепого, глухого и тупого получиться лучше чем у поттера!

Не очень понимаю как слепота и глухота должны влиять на качество написанного кода, а касательно тупизны - если ещё никто не написал замену, то получается что в опенсорс комьюнити всё очень, очень плохо.

>> стандарт де-факто

Прям как венда.

А так же как Xorg, Udev, grub, вся обвязка GNU, которая прилепляется к ядру линукса и, собственно само ядро, а так же апач и ещё тонна различного софта. По существу-то что сказать хотел?

На пальцах, на примере nfs: […]

А без пальцев и nfs'ов, как будешь настраивать автомаунт (и причем он здесь вообще), если хочется сделать так, чтобы некоторый демон не запускался при отсутствии некоторой точки монтирования? Монтирования может не произойти из-за выхода носителя из строя, например.

А еще есть сферические кони в вакууме. Для нештатной ситуации нафига штатный обработчик? Хотя, красивый лог вместо ошибок в консоль красив, не спорю. меня на сохо роутере трансмишн все равно запускается при не смонтированном диске. Не понимаю, какой профит его не запускать (особенно, если основной способ мониторинга его - это подключение к нему)

Чем слака настраивается? Ансибл или там чеф с паппетом?

Вот ведь, админы локалхоста :)

Нет, решения подобные ансиблу и прочим не используются. PXE, iSCSI и прочее - наше всё. Это гораздо удобнее, когда речь идёт о чём-то большем, чем пара-тройка локалхостов.

А еще есть сферические кони в вакууме.

О которых ты зачем-то пытался рассказывать.

Для нештатной ситуации нафига штатный обработчик?

Встречный вопрос — а как реагировать на нештатные ситуации?

Кому и для чего нужно считать скрипты конфигами?

Очевидно, тупорылым вендузятникам, которые ссуться шелл-скрипта как огня и ничего больше вендоINI понять не способны. :)

Блин, даже в слаке скрипты никогда не затираются при обновлении.

PXE, iSCSI и прочее - наше всё.

Причем тут это вообще? Ты отличаешь систему конфигурирования операционной системы от загрузки по сети и от блочного устройства по сети? Ну, загрузился ты по PXE с диском по iSCSI, дальше-то что ты будешь делать? Например, она должна выступать одной из нод в балансере. Туда надо притащить haproxy+nginx с нормальными конфигами.

Мне интересно, как у тебя настраивается свеженалитая слака. У нас, например, постоянно новые машинки льются. Все на Debian 8 с вшитым ansible-pull.

Вот ведь, админы локалхоста :)

Ну, вот тебе скрин из заббикса http://storage4.static.itmages.ru/i/15/1103/h_1446541998_1321246_63878fdaa3.png

Может еще и учиву показать?

в опенсорс комьюнити всё очень, очень плохо

Да все очень, очень плохо мы это видим на примере systemd когда воинственные олигофрены ломают то что работало. Напишут в BSD замену мы только спасибо скажем!

Ты отличаешь систему конфигурирования операционной системы от загрузки по сети и от блочного устройства по сети?

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

Например, она должна выступать одной из нод в балансере. Туда надо притащить haproxy+nginx с нормальными конфигами.

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

Ну, вот тебе скрин из заббикса

И что? О чём это должно говорить? О том, что решение для локалхостов можно как-то масштабировать?

ЗЫ: Интересно, а вот эта пакость, которые яжеадминанепрограммист - это тоже с венды лезет?

Чинить же. Остальное уже поздно. Работает-не работает - таки бинарное состояние.

Пофиг откуда эти уродцы лезут, главное что они тупые пеньки с завышенным ЧСВ поэтому хотят все ломать. Вот этим вызовам нужно как то научиться противостоять.

О том, что решение для локалхостов можно как-то масштабировать?

Ansible/Chef/Puppet/SaltStack e.t.c решения для локалхостов? Ты еба^W с ума сошел?

У меня нет такой задачи.

Расскажи про свои кейсы, пожалуйста. Пока от тебя не слышно нормального.

Это ты не понимаешь, что одинаковые машины можно грузить с одного диска.

Для настройки /etc/ что делается? Или в /etc монтируется для каждой машинки отдельный диск?