LINUX.ORG.RU

Разработчик из команды Gentoo выступил с критикой systemd

 ,


10

4

Большую бурю споров вызвала сегодняшняя запись в блоге одного из участников команды Gentoo Linux Патрика Лойера. В ней он с критикой прошёлся по systemd, её концепции и разработчиках.

Ниже привожу свой перевод его публикации.

Пропагандистам Systemd: это отстой!

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

Поэтому мне хочется разобрать все по полочкам.

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

Без понятия, что это значит, наверное они хотели сказать «нам лень».

Я уверен, что ребята из Ubuntu даже близко не понимают сложности этой проблемы.

Забавное косвенное оскорбление, но CGroups *не* сложные. Я убежден, что понимаю их общую концепцию, сегодня днем я уже успел написать начальную поддержку OpenRC.

Разумеется, Control groups лежат в основе того, что требуется от современных серверов.

... что? Нет. Сервер должен служить (и защищать? постойте, не тот девиз). CGroups - просто еще одна технология, которую будут игнорировать сисадмины. В ней нет никакой магии, она не сложнее работы с ulimit.

API, предлагаемый systemd, очень systemd-специфичный.

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

Ясно, что сейчас большая часть экосистемы Linux уже использует API systemd...

Помню эту штуку... возьми, расширь... смысл? Возможно имеет смысл создать стандартные API и использовать их где угодно вместо того, чтобы применять прибитые гвоздями хаки с DSL вследствие плохой архитектуры.

В принципе демон D-Bus уже реализован внутри самой systemd (и в ядре), и логика работы не уже может обходиться без него. Фактически при переходе на systemd логика работы распределится на несколько демонов, которые для активации должны быть описаны в юнит-файлах .busname и .service, а не в старых конфигурационных файлах.

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

Теперь один из самых сложных компонентов - перегруппировка сервисов, преобразование старых dbus1 сообщений в kdbus GVariant, преобразование их обратно в сокет-сервис systemd, и это из sysetmd не вырвать даже с корнями.

Нет, с такого суждения начинать нельзя. Кто-то задастся вопросом: а почему форматы сообщений kdbus и dbus отличаются, когда одна система есть замена другой? И только то, что это часть sysetmd и она никак не документирована, еще не означает, что ее нельзя аккуратно вырезать и заставить работать отдельно или написать с нуля как самостоятельный инструмент. Игнорирование (или непрофессионализм?) в приведении этого утверждения заставило меня вспомнить пользователей windows, которые ругают Linux потому, что в нем нет красивых GUI...

Разумеется, logind - один из тех компонентов systemd, в документации которого мы явно указали, что его никак нельзя убрать.

Если вы так написали, еще не значит, что так оно и есть. Но это отличная попытка пресечь дискуссию заявив, что альтернатив нет, нам так нравится и вообще заткнитесь, как говорят политики. logind это не программа, поэтому у нее нет описания архитектуры или корректной документации, что она делает. Это просто API, зашитый в systemd так сильно, что понять его - большая головная боль. Единственное, что сдерживает меня от написания подобного инструмента с такой же функциональностью, это то, что понятия не имею, что он должен *делать*... Для меня нет никакого удовольствия читать код всей systemd, чтобы это выяснить. Но, исходя из того, что я знаю сейчас, в реализации ее нет ничего особенного.

Спустя несколько месяцев после того, как это сделали в Canonical, все снова cломалось, как мы и ожидали: сейчас logind использует новые API для работы с CGroups.

«Когда ломаешь вещи, они ломаются»... Единственная причина того, что ничего не работает это... отсутствие документации и ломающие изменения. И такие нелогичные высказывания сами тому подтверждение.

...связывающий слой в юзерспейсе Linux в настоящее время разрабатывается как большая часть systemd.

«Мы теперь даже не прикидываемся, что понимаем философию Unix.» Репозиторий systemd - скорее помойка, чем что-то еще, его нужно разделить (на подмодули), чтобы независимые компоненты были независимыми. НЕТ никакого смысле держать в одном репозитории udev, hwdb или еще десяток несвязанных друг с другом вещей.

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

Учтите, что logind, kdbus или CGroups - это новая технология, мы ничего не поломали, просто написав их. Следовательно нет никакой регрессии, мы просто добавили новые компоненты, которые, по нашему мнению, будут крайне интересны пользователям.

CGroups - «старая» штука, новое - это просто заставлять всех использовать их по-другому. Это противоречит документам по разработке systemd, которые теперь считаются неверными после того, как были Единственной Верой для нас в течение нескольких лет. Сложно понять, что сегодня в меню, когда оно меняется так часто...

И может быть, если кто-то нормально напишет, что должен делать LoginD (а не просто даст дамп API, который никому ни о чем не говорит, чукча не читатель!), мы смогли бы выполнить правильную реализацию где угодно и не заставлять людей ломать свои системы, чтобы наконец logind делал то, что должен делать. Свинпаук, свинпаук делает то, что он делает [прим. ссылка на «Симпсоны в кино»]

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

... простой? По-моему это слово означает не то, что вы думаете! (Не для 200 тысяч строк кода для того, что можно быть написать и в 35 тысячах.)

Я просто надеюсь, что вы делаете это, зная, что это всерьез и надолго.

Итак, подведу итог. Никто не сможет реализовать то, что делает systemd, и поэтому вы вынуждены ее использовать. Это так прекрасно, что не стоит даже пытаться искать что-то еще!

Простое чтение этой пропаганды очень меня расстроило своим уровнем лжи и запутывания, не понимаю, как у нас может получиться нормальная дискуссия с ними. Все доводы либо логически противоречивы («Никто не может написать logind без использования logind») или ошибочны («Cgroups лежат в основе того, что требуется от современных серверов»).

В то же время все, кто с ними не согласен - старообрядцы... или неграмотные... или кто угодно. В любом случае, ВЫ КОЗЛЫ и я победил в споре! или что-то такое.

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

>>> Подробности

★★★★★

Проверено: JB ()
Последнее исправление: Dendy (всего исправлений: 3)

Ответ на: комментарий от Tribunal

Не смотрел на upstart

Я все-таки надеюсь, что выберут upstart

Аналитики с лора - такие аналитики.

anonymous
()
Ответ на: комментарий от Tribunal

Там нужен почти полный рефакторинг кода.

При сексе с Поттерингом главное использовать резиновое изделие №1, а то потом по КВД бегать устанешь.)

Это eselect, wrappers и прочие формализующие API. Не знаю, насколько это применимо к КДЕ, а также зачем там весь код перелопачивать, но, учитывая неоднозначность оценок systemd, какой-нибудь lib-kde-systemd так и проситься (в теории). На практике это может немного снизить производительность, потребует разработки нового слоя абстракции. Зато потом будет возможность быстро и легко менять API к systemd... что дорогого стоит.

Удачи! (У меня гента, опенрц и гном2:)))

anonymous
()
Ответ на: комментарий от Tribunal

Проблема с Upstart, как и со всем исходящим из Дома Каноникал (отсылка к Дюне :]), это специфическая CLA.

Фактически, если Debian выберит Upstart и захочет что что-то адаптировать, доработать итд, то они будут обязаны подписать CLA. Что в свою очередь передает все права на эти наработки в Canonical, и разрешает им релизить и эти модификации под любыми другими лицензиями.

А проприетарщину они (Canonical) любят.

anonymous
()
Ответ на: комментарий от Ager

умный (грёбаный) системд _МОНТИРУЕТ_ОБА ПАРТИШЕНА_

Ну, звучит странно, конечно, если это был не autofs. При отмонтировании с umount юнит переходит в состояние failed, и без рестарта таргета не знаю как может такое выйти. Вот если бы это был сменный носитель и был udisks - тогда легко. Он такое любит

vasily_pupkin ★★★★★
()
Ответ на: комментарий от anonymous

Аналитики с лора - такие аналитики.

Просто выбор стоит: upstart, systemd, OpenRC или какая-то смесь. 3 разработчика upstart входят в TC Debian. Что тут не понятного. И я не смотрел на код upstart, как он работает - я прекрасно знаю. Но я видел код systemd - хуже написать сложно. Реально сложно.

Tribunal
()
Ответ на: комментарий от anonymous

если так посмотреть.то линукс вообще может скоро стать проприоритарным,как только не станет Линуса и Столлмана .

erzent ☆☆
()
Ответ на: комментарий от Ivan_qrt

ну вот собственно, как описано в fstab, так и смонтировалось «внезапно» :(

100% уверенности нет, но systemd так не поступает.

Мне остается только пожать плечами. «я ничего не делал. оно само» (C)
Случилось это примерно пол-года назад. Из подробностей помню только секас с восстановлением инфы, к счастью - без потерь.
Просто, кроме как на системд грешить не на кого.

Ager
()
Ответ на: комментарий от kamyrros

starting 12.3 you cannot go back to sysvinit for a number of reasons

Вот поэтому я и закончил общение с сусе на уровне 12.1 где-то. Потестил (на серверах, а не на десктопах) системд, посмотрел (с интересом) как после рестарта умер смертью храбрых нагруженный запросами под жвак nginx, почитал «откровения святого Поттеринга» в его личном блоге, и решил мы с этим «святым» категорически не совпадем.

С тех пор я на генте и очень-очень жалею... Жалею о том, что не свел знакомство с гентой чутка раньше.

По сабжу: с cgroup вопрос интересный, а вот насчет остального - поддерживаю автора на 100%

k0valenk0_igor ★★★
()
Ответ на: комментарий от vasily_pupkin

...в зависимости от инита...
1. /etc/hostname может игнорироваться
2. /etc/rc.local может не запускаться

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

Shadow ★★★★★
()
Ответ на: комментарий от anonymous

Это eselect, wrappers и прочие формализующие API. Не знаю, насколько это применимо к КДЕ, а также зачем там весь код перелопачивать, но, учитывая неоднозначность оценок systemd, какой-нибудь lib-kde-systemd так и проситься (в теории). На практике это может немного снизить производительность, потребует разработки нового слоя абстракции. Зато потом будет возможность быстро и легко менять API к systemd... что дорогого стоит.

Я трогать поделие Поттеринга не собираюсь - у меня с Pisi Linux полно забот. Но приходится глазеть на него, чтоб знать, чего отвечать фанбоям и что можно в качестве важного аргумента представить Аарону Сейго и Мартину с непроизносимой фамилией (разработчику KWin). Они-то разработчики повыше уровнем будут. Хотя плазма таки еще падает. Но уже очень редко.

Tribunal
()
Ответ на: комментарий от vasily_pupkin

уже отвечал Ivan_qrt добавлю: вот фрагмент fstab и это обычный HDD

LABEL=distr     /distr          ext2            defaults                0 2
LABEL=virtm     /virtm          ext2            defaults                0 2
Ager
()

Насчёт SuSE - я в конце девяностых пытался им пользоваться. Сначала казался офигенным, удобным и т.п. Потом я посмотрел на то, КАК они сочетали SystemV init скрипты и свои конфиги, и больше я SuSE не пользовался. RedHat, что характерно, init скрипты и конфиги всегда писали очень читаемо. Т.е. я вполне допускаю, что в традициях SuSE не осиливать init для админов, а делать «blackbox». Печально, что теперь в RedHat всё сложно. С другой стороны, RedHat первые когда-то перешли на glibc2 - и тогда это было более серьёзным шоком, чем замена init на топик.

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от beresk_let

Не брат я тебе, морда столлманутая!

Ну морды у нас у всех (на аватах).... мдя... А по поводу «прогиба» - мысль сугубо верная - не прогнемся! Но пасаран!

k0valenk0_igor ★★★
()
Ответ на: комментарий от k0valenk0_igor

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

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

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

Проблема с Upstart, как и со всем исходящим из Дома Каноникал (отсылка к Дюне :]), это специфическая CLA.

Фактически, если Debian выберит Upstart и захочет что что-то адаптировать, доработать итд, то они будут обязаны подписать CLA. Что в свою очередь передает все права на эти наработки в Canonical, и разрешает им релизить и эти модификации под любыми другими лицензиями.

А проприетарщину они (Canonical) любят.

CLA - главный аргумент противников upstart. Я думаю, Марк не тупой и сумеет договориться, если надо. В его интересах свободный upstart. Работал же он в Fedora и RHEL6.

Tribunal
()
Ответ на: комментарий от Ager

Я понимаю что у вас в 91м году не было noauto, вопрос в том - зачем вы всех остальных призываете не использовать достижения 2013го года?

anonymous
()
Ответ на: комментарий от anonymous

Разупорись и перечитай ссылку ещё раз. Там вполне человеческим языком объясняют зачем это нужно.

Для этого нужно ВО-ПЕРВЫХ иметь 6 ядер - 4ре на процессы, 1 на ИО, 1 на супервизор ибн системд.

Читал я тупых анонимусов, но ты точно в первой десятке.

anonymous
()
Ответ на: комментарий от vasily_pupkin

про внезапное монтирование уже написал.
перенос некоторых конфигурационных файлов из /etc/ в /usr/bla-bla - зачем?

я понимаю, что это было удобно _лично_ для меня - бэкап /etc/* с сервера - 95% гарантия восстановления сервака после сбоя.

Но в любом случае не пропадает ощущение «изменить что-бы было не как у всех»

Что-то ещё просто лень вспоминать. Давайте пойдем от обратного - а напишите мне про все «плюсы» системд, которые сделают мою жизнь более спокойной и комфортной :)

Ager
()
Ответ на: комментарий от Tribunal

Вот все бы это в конференцию Debian (TC). Там есть несколько системде-фанбоев, надо их фактами задавить.

Незабудь записать видео. Увидеть как над вами ржёт половина участников будет интересно.

anonymous
()
Ответ на: комментарий от anonymous

Я понимаю что у вас в 91м году не было noauto, вопрос в том - зачем вы всех остальных призываете не использовать достижения 2013го года?

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

anonymous
()
Ответ на: комментарий от anonymous

Нееет :) Я никого ни к чему не призываю.
Я просто констатирую факт, что некоторые отдельно взятые «достижения 2013го года» немножечко глючат...

Ager
()
Ответ на: комментарий от Ager

перенос некоторых конфигурационных файлов из /etc/ в /usr/bla-bla - зачем?

Каких? В /usr/бла-бла идет дефолт, его нет смысла бекапить

Давайте пойдем от обратного - а напишите мне про все «плюсы» системд, которые сделают мою жизнь более спокойной и комфортной :)

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Lothlorien

В embedded тот же, что и на x86?

А почему нет-то? Только не говори «жЫрный», пожалуйста.
Перестанут хоть 4-метровые флэшки в говнороутеры пихать.

pekmop1024 ★★★★★
()
Ответ на: комментарий от anonymous

Незабудь записать видео. Увидеть как над вами ржёт половина участников будет интересно.

Толсто. Скорее всего выберут все-таки upstart, 3 из 7, кажется, участников TC, как никак. Хотя все может измениться, Поцтеринг с хомячками-фанатами развернули компанию.

Всем: если интересно, следить тут: Тыц

Tribunal
()
Ответ на: комментарий от aes_ultimum

Да никакое. У меня нет таких знаний, чтобы тестировать системы инициализации.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от wintrolls

переключалка не работала либо работала лишь по тычку мышей на значке в трее.

Они над Вами издеваются.

AlexM ★★★★★
()
Ответ на: комментарий от vasily_pupkin

не хочется уподоблятся людям, которые «не читал, но осуждаю» но ....

в этих наших интернетах ходят слухи, что багзилла «про системд» и так завалена багрепортами, которые «не будем говорить кем» напрочь игнорируются :(

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

но это только слухи... «мопед не мой» (C)

Ager
()
Ответ на: комментарий от Ager

в этих наших интернетах ходят слухи, что багзилла «про системд» и так завалена багрепортами, которые «не будем говорить кем» напрочь игнорируются :(

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

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

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

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Торвальдсу бы стать более открытым и ходящим на телевидение,и каждое новое ядро представлять на BBC и CNN как делал со своими девайсами Джобс.

erzent ☆☆
()
Ответ на: комментарий от vasily_pupkin

Каких? В /usr/бла-бла идет дефолт, его нет смысла бекапить

Конечно согласен. Но вот уже несколько раз встречал баги про то, что изменённые настройки из /etc или игнорируются или выполняются (внезапно) _перед_ дефолтовыми из /usr/bla-bla (ну то есть они затираются дефолтовыми)

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

Я искренне за Вас рад. Я честно стараюсь спокойно воспринимать «нововведения». Я прекрасно понимаю, что программ без ошибок не бывает, и нужно просто подождать, пока всё устаканится. Но, к сожалению, иногда эмоции берут верх, когда читаешь некоторые новости об очень спорных «нововведениях».

Ager
()
Ответ на: комментарий от pekmop1024

жЫрный не буду ;) но отмечу, что IMHO в embedded от системы инициализации требуется а) меньший функционал; б) стабильность; в) простота в смысле "...looking for ways to break up program systems into small, straightforward cooperating pieces".

А потом, про 4 метра, если их хватает, зачем пихать больше?

Lothlorien ★★★
()
Ответ на: комментарий от anonymous

«Оно само, я ничего не трогал». Ну если так то баг-то занес, воспроизвести сможешь?

anonymous
()
Ответ на: комментарий от Lothlorien

..looking for ways to break up program systems into small, straightforward cooperating pieces"

Там, где _действительно_ мало ресурсов, но почему-то linux, речь об этом не идет. Там обычно do-all №1 и №2.

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

Но если функционал девайса расширяется, в изделии навроде systemd может появится смысл

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Lothlorien

В embedded есть busybox, ему там хорошо.
Но я бы не отказался от systemd или подобного «умного» инита, ибо старт роутера на AR7161 занимает, например, около минуты - причем исключительно из-за того, что инит не умеет параллелиться.

про 4 метра, если их хватает, зачем пихать больше?

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

Проприетарные поделки, которые ты пишешь, тоже будут тащить с собой патченый systemd?

tailgunner ★★★★★
()
Ответ на: комментарий от init_6

Вы никак не поймете, свалка в линуксе это не свалка а набор костылей призванный унифицировать железячный зоопарк в котором приходится запускаться. Зоопарк этот во-первых постоянно меняется а во-вторых плохо документирован. Нет никакой возможности воздействовать на производителей, многие не только не сотрудничают но даже пытаются препятствовать поддержке своих продуктов. Звучит абсурдно но это факт. Все приходится пилить в спешке поскольку поддержка серверов у которых наступил end of life мало кому нужна. Приходится жертвовать стабильностью иначе будет как с BSD. И напоследок, Линус не бросил свое детище на версии 1.0 а возглавляет проект уже 20 лет как.

A-234 ★★★★★
()
Ответ на: комментарий от tailgunner

Патченый системде нужен лично для моих извращенных локалхостовых потребностей

vasily_pupkin ★★★★★
()
Ответ на: комментарий от reprimand

потому что d не dimension а daemon

Это я понял :)

но шутку оценил, спасибо =)

Всегда пожалуйста.

andreyu ★★★★★
()
Ответ на: комментарий от AlexM

Они над Вами издеваются.

И над моим компьютером тоже?

wintrolls ☆☆
()
Ответ на: комментарий от LongLiveUbuntu

хвастаешься тем, что у тебя что-то короткое? Запомни, главное - толщина)

У Фрэйда хорошо данная тема раскрыта :), Те кто обычно ничего не может (ни в Linux ни в жиздни) покупают себе самые большие машины и т.д. и т.п :)))

aeX1pu2b
()
Ответ на: комментарий от pekmop1024

А почему нет-то? Только не говори «жЫрный», пожалуйста.

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

anonymous
()
Ответ на: комментарий от anonymous

Раньше телефоны спокойно жили под неделю

Ведроиды и сейчас живут так. Причем вполне себе топовые.
Проблема не в ведроидах, а в руках: ведроид можно засрать так, что он за полдня батарейку спустит, а тупозвонилку - нельзя. Ну так это не ведроида проблема. А если его еще и юзать как тупозвонилку, спокойно будет жить 5-7 дней, или 2-3 в режиме смартфона.

pekmop1024 ★★★★★
()
Ответ на: комментарий от anonymous

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

Чел, жжот в тему, ссылку взял с форума арча :))

aeX1pu2b
()
Ответ на: комментарий от anonymous

А стандарты де юре - это видимо не путь к единому дистрибутиву?

нет.
Например, если-бы в MacOS, iOS, Android и каждом из остальных дистрибутивов Linux вместо OpenGL было своё 3D API - для разработчиков и пользователей программ с 3D графикой Windows была бы единственной ОС.

Стандарты защищают многообразие, а диалектика рулит.

Anonymous ★★★★★
()
Ответ на: комментарий от Lothlorien

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

До systemd init скрипты допиливались под каждый дистрибутив, как правило - мейнтейнером пакета. 15 лет это работало, не спорю - но всё таки systemd не ломает стандарты, а создаёт с нуля там, где раньше их, толком, не было.

Anonymous ★★★★★
()
Ответ на: комментарий от DR_SL

Здесь война между Canonical и RedHat

Debian десятилетиями был и остаётся куда более серьёзным конкурентом RHEL - и жили вполне мирно. И обвинений, в том что Линус специально пихает баги в ядро, _которое использует RHEL_, чтобы навредить Debianу - я что-то не слышал.

Чем-то мне это напоминает позицию т.н. ватников, которые тоже уверены, что всё, что делают 8 миллиардов человек за рубежом, будь то новые торговые соглашения, постройка коллайдера или выпуск аниме с понями - они делают исключительно чтоб навредить России - потому, что «ну а зачем же ещё?».

Anonymous ★★★★★
()
Последнее исправление: Anonymous (всего исправлений: 1)
Ответ на: комментарий от Anonymous

Debian десятилетиями был и остаётся куда более серьёзным конкурентом RHEL - и жили вполне мирно

Они жили (и живут) в разных нишах.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Они жили (и живут) в разных нишах.

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

aeX1pu2b
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.