Столлман и systemd

С open source всегда есть возможность вести свой форк со своими изменениями, если это действительно нужно.

ха-ха-ха, можно в смысле разрешения, а не реальной возможности.

Т упрлс?

а не реальной возможности

Что еще за реальная возможность и почему ее нет?

потому, что у тебя не будет десятка разработчиков работающих фултайм. Systemd показывает прекрасный вариант vendor-lock в среде OpenSource, у других игроков нету финансовой возможности поддерживать форк, а у RH есть все возможности, чтобы сделать невозможным форк без развистия.

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

Никто не запрещает мерджить из апстрима. См. ffmpeg vs libav.

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

coreutils показывает прекрасный вариант vendor-lock в среде OpenSource

OpenOffice показывает прекрасный вариант vendor-lock в среде OpenSource

Xorg показывает прекрасный вариант vendor-lock в среде OpenSource

Mesa показывает прекрасный вариант vendor-lock в среде OpenSource

И, что хуже всего,

Linux показывает прекрасный вариант vendor-lock в среде OpenSource

А если твоя точка зрения как потребителя не совпадает с точкой зрения разработчика?

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

пожалуйста пройдите с аналогиями куда-нибудь в другое место. Здесь технический ресурс (когда-то был).

Хорошо, обойдёмся без аналогий.

Чем ситуация с X.org/Mesa/Linux (де-факто стандарт) отличается от ситуации с systemd (хочет быть де-факто стандартом)?

coreutils показывает прекрасный вариант vendor-lock в среде OpenSource

Есть BSD coreutils и получше.

OpenOffice показывает прекрасный вариант vendor-lock в среде OpenSource

Abiword + Gnumeric, Apache OpenOffice, LibreOffice

Xorg показывает прекрасный вариант vendor-lock в среде OpenSource

Mir, XFree86

Linux показывает прекрасный вариант vendor-lock в среде OpenSource

BSD, OpenIndiana.

Все упомянутые альтернативы похожи в следующем: их использует пять процентов от одного процента. Следовательно, не аргумент.

Потому что с тем же успехом можно заявить как-то так:

Systemd показывает прекрасный вариант vendor-lock в среде OpenSource

busybox init же!

да ничем особо, оно, к сожалению, и станет стандартом. (я не хочу вдаваться в споры по поводу отношения к контрибьюторам). Тут какая фишка, в systemd могут поменять и поменяю внутреннюю реализацию если появится конкурент, в итоге конкуренту придётся гнаться за совместимостью, xorg, mesa и linux в такие игры не играли. А вот если бы bsd, и unix меняли бы user-space API по прихоти левой пятки, linux бы мы врятли увидели.

Валидный аргумент, но

могут поменять и поменяю внутреннюю реализацию если появится конкурент

А почему, собственно? Были прецеденты? Как-то необоснованно звучит.

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

На самом деле логичная стратегия.

systemd-v205 я помню. Но разве там не от ядра исходила инициатива?

(Интересно, конечно, но слухи есть слухи.)

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

Моё личное, а потому, не сильно обоснованное, подозрение заключается в том, что если сервис не сильно полагается на цгруппы, и не делает больших ограничений (как напр. openrc), то и старый подход работал. В вразумительном опровержении или подтверждении данного мнения я заинтересован.

потому, что у тебя не будет десятка разработчиков работающих фултайм

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

у других игроков нету финансовой возможности поддерживать форк, а у RH есть все возможности

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

Наверняка, в случае каких-либо проблем с systemd в своих системах компании вроде Oracle или IBM смогут и форкнуть и переписать все что им нужно, даже если RedHat не захочет содействовать.

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

Если я понимаю происходящее объективно, то мейнтейнер cgroups в ядре (Tejun Heo) сказал «реализация дерьмо, надо переделывать».

Дерьмо заключалось конкретно в том, что можно было создавать несколько независимых друг от друга иерархий. Ну и в итоге это было объявлено как strongly deprecated. Поскольку новую реализацию надо делать не «абы как», а под конкретные пожелания, эти самые пожелания были взяты у первого заявившего о них проекта, то есть systemd.

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

И действительно. Что ж, и такое бывает - не всё всегда можно надёжно сделать, и тем более не с первого раза.

Я почему-то доверяю разработчикам ядра :)

(http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linu...)

читал уже, там вода сплошная к сожалению :/

Что еще за «вендорлок» в open source?

Это когда ядро можно собрать нормально только gcc, а код в самом gcc понятен только самим ГНУтым.

Проснулся от зимней спячки?)

ядро можно собрать нормально только gcc

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

код в самом gcc понятен только самим ГНУтым

Если действительно нужно, то разобраться в коде gcc может любой квалифицированный специалист. «ГНУтые» ничего не скрывают и распространяют gcc в форме предпочтительной для внесения изменений, т.е. в исходниках.

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

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

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

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

Говори за себя :)
Разобраться можно во всём. Со временем.