Gentoo могла стать монополистом на рынке дистрибутивов. Но не стала. И
не станет. По причине того, что в дистрибутиве gentoo заложена
идеология, которая с момента основания не эволюционирует. А по
принципам мироздания — всё, что не эволюционирует имеет вектор
направленности на смерть. Это может кому-то не нравится, но можно
сколь угодно долго отрицать то, что трава зеленая и от этого она
зеленой быть не перестанет
При этом управленческий состав дистрибутива Gentoo не имеет желания
разобраться в происходящем и в виду этого, никаких шагов по
трансформации дистрибутива не происходит. И очень жаль!
Для начала, стоило бы разобраться в причине популярности дистрибутива
Gentoo(2005-2010 год) и дальнейшем спаде популярности и неминуемой
смерти дистрибутива в течении последующих 10 лет.
Причина популярности в 2005-2010 годах заключалась в том, что:
1. бинарные дистрибутивы, несмотря на их количество, не предоставляли
пользователю актуальных версий пакетов программного обеспечения в
стабильной ветке. Ветки тестинг и анстейбл не предоставляли
пользователю стабильную работу, с периодичной регулярностью приводящих
рабочую станцию в неработоспособное состояние. Далее дистрибутив
debian пересмотрел свою позицию и стабилизировал версии пакетов, на
которых пользователь смог работать(имеется ввиду контекст девелоп
студио и десктоп). И стал популярен. Именно по этой причине.
2. дистрибутив Gentoo имплементировал инновационную технологию
USE-флагов, которая не реализована в полной мере в других
дистрибутивах. Частично она реализована в NixOS. Эта технология
позволяла пользователю менять функциональный интерфейс ОС.
Управленческий состав Gentoo до сих пор считает, что причиной
популярности была идеология «сборка программного обеспечения из
исходных текстов». Это не так. Конечному пользователю нужна гибкость в
плане функционального интерфейса. И только. Пользователь за эту
возможность готов даже ждать, пока пакеты соберутся из исходных
текстов.
Отстуствие эволюционирования дистрибутива Gentoo привело к появлению
дистрибутивов, которые пытаются эту гибкость пользователю
предоставлять. В разных контекстах, даже самых невероятных. Вопиющий
пример — это появление дистрибутива NixOS, который пытается
предоставить пользователям следующие возможности:
1. возможность использования нескольких версий программного обеспечения
2. возможность фиксирования состояния
3. декларативная настройка операционной системы
4. возможность изменения функционального интерфейса ОС(аналог USE-флагов)
Каждый из этих пуктов в этом дистрибутиве реализован. При этом
фиксация на 1, 2 пункте привела к многочисленным трудностям в
использовании этого дистрибутива. 3 пукнт переусложнён и имеет
тенденцию к дальнейшему переусложнению и уже привел к тому, что этот
дистрибутив потерял универсальность. Самый простой пример:
попытайтесь сделать chroot из установочного образа NixOS в другой
дистрибутив
Итак, Gentoo предоставила инновационный интерфейс USE-флагов, который
позволяет менять функциональный интерфейс операционной
системы. Основной недостаток реализации — время сборки из исходных
текстов. Вопрос: является ли сборка из исходных текстов единственно
возможной в вопросе реализации предоставления возможности изменения
функционального интерфейса? Мой ответ: НЕТ. Такую возможность можно
реализовать не применяя сборку из исходных текстов. На этом пути конечно же
есть проблемы. Но для того, чтобы их решать(а решить их в конечном итоге можно,
на практическом уровне дистрибутив NixOS это показал) лежит исключительно в
плоскости трансформации идеологии управленческого состава дистрибутива Gentoo
Множество раз на просторах рунета(и не только), пользователями
поднимался вопрос бинарных кешей пакетов. Ответ всегда один: это
невозможно сделать, по причине того, что у каждой рабочей станции
процессор со своим набором CFLAGS и что пакет, который собран с одним
набором CFLAGS не обязательно будет работоспособным на другой рабочей
станции с другим набором CFLAGS. И ввиду этого технически невозможно
реализовать бинарный кеш пакетов, которые бы работали на других
рабочих станциях даже в пределах одной архитектуры(допустим
AMD64). Это утверждение верно, но пути решения есть:
1. использование GENERIC CFLAGS
2. сегментирование бинарных кешей по CFLAGS
И первый и второй пукнт есть возможность реализовать. Желания у
управленческого состава дистрибутива Gentoo нет. Что ожидает дистрибутив Gentoo,
если у него появлятся бинарные кеши пакетов? Он обречен. На успех.
Я мечтаю, чтобы управленческий состав дистрибутива Gentoo пересмотрел свою
идеологию и принял стратегическое решение по вектору направленности этого замечательного дистрибутива и стал по-настоящему инновационным в мире дистрибутивов
Автор: Сергей
