А напишу-ка я флеймогонный пост.
На тему того, что свободный софт перестает быть свободным по чисто техническим ограничениям, я уже
писал. И что в этом в частности виноват
злобный предатель де Иказа, хотя далеко не только он - тоже.
А теперь о том - что делать. Понятно, что прочитав все что ниже, вы скажете что это проект неподъемный. Ну так четверть века назад Столлману то же самое говорили. А у него - получилось.
Итак, переходим к делу. Я утверждаю что проект GNU как таковой - исчерпал себя. Он утонул в собственной сложности. Когда исходник
hello world занимает под 200 строк, не считая вспомогательных библиотек для обеспечения переносимости, требует 10000-строчного скрипта для конфигурирования, а весь дистрибутив hello world - 400 килобайтный архив - так жить нельзя. О какой свободе модификации может идти речь, когда для того, чтобы разобраться как программа выводит одну строчку на экран, требуется читать две сотни строк, а для того чтобы разобраться, как это скомпилировать - несколько десятков тысяч?
Сравните с пятью строчками и однострочным Makefile у Кернигана и Ритчи.
Нет, бывает и хуже. Почитавши некоторые исходники OpenSolaris, я понял что Столлман и его последователи поначалу многое сделали для достижения удобопонятности софта. Но потом пришло поколение де-Иказ и Дрепперов.
В общем, похоже как в том позднесоветском анекдоте про Ленина - надо выезжать в Женеву и начинать все с начала.
Пытаться создать новый проект и еще раз реимплементировать POSIX userland. Начиная с libc. Впрочем, тут ембедщики поработали, и можно попробовать взять за основу uclibc.
Естественно, нужно сразу закладываться на то, что в итоге должна получиться система с GUI. Заменять X11 на 8
1/
2 или какой Оберон я пока мысленно не готов. Опять же сетевая прозрачность - штука полезная.
Поэтому понятие сессии нужно сразу закладывать такое, какое сложилось к концу первого десятилетия XXI века в десктопных системах. Так что сессионная шина сообщений (да и системная) нужна. Впрочем проект
человекопонятной замены D-Bus я уже публиковал.
Возможно, начинать новый проект надо не с yet another реимплементации coreutils (хотя до этого дело неизбежно дойдет - я не зря начал с описания GNU hello - это наиболее концентрированная демонстрация всех пороков командно-строчных утилит GNU), а с чего-нибудь типа браузера. Поскольку с браузерами положение сейчас наиболее нетерпимое.
Тем более, если удастся разобрать браузер на кучку компонентов, работающих как отдельные процессы, общающихся между собой по удобопонятным протоколам и обрабатывающих ошибки (вплоть до падения в кору) друг друга без ущерба для user experience, это продемонстрирует, что можно делать сложные вещи простыми, понятными и удобными для модификации.
Остальное будет проще. Только xlib придется повычистить от вызвов abort(). Ибо не дело это - ронять приложение, в которое может пара гигабайт ценных несохраненных данных загружено только потому, что потеряна связь с дисплеем (или даже не потеряна, а просто со шрифтами фигня какая-то).
Собственно, основные принципы, которым должен следовать данный проект, проистекают из статьи Столлмана
Opening the software toolbox про которые большая часть opensource программистов успешно забыли.
1. Каждая компонента делает только одну вещь, но делает её хорошо
2. Должно быть легко понять, как вызвать компоненту, чтобы она сделала то, что тебе нужно. Т.е. библиотека с развесистыми API имеет право на существование в исключительных случаях. В остальных - отдельный процесс, общающийся с другими с помощью легко анализируемого протокола межпроцессного взаимодействия - параметры командной строки, сообщения по сессионной/системной шине, имеющие тот же синтаксис командной строки, данные в очевидно понятном формате по пайпу, shared pixmap etc.
3. Если где-то мы предусматриваем не совсем очевидный формат (типа той же shared pixmap) то сначала мы делаем инструмент, позволяющий этот формат посмотреть, и только потом - компоненты
которые делают с этим что-то осмысленное.
4. Любые тулзы автоматической генерации кода (типа скриптов конфигурирования) должны генерировать код, в первую очередь понятный для человека.
5. Никаких врапперов вокруг компилятора, вроде libtool. Лучше отказаться от поддержки нескольких экзотических платформ, или написать для них отдельный makefile, чем оставить админов и программистов всех остальных платформ наедине с необъятными простынями неудобочитаемого кода с пятью уровнями include. Упрощение жизни сборщика ценой усложнения жизни разработчика - это обмен essential liberty на temporal safety. Тот же сборщик вас потом проклянет, когда выяснится что вы не все предусмотрели и ему надо что-то подкрутить. Кстати, возможно от make стоит сразу отказаться, заменив его на какой-нибудь
bras.
В общем, система должна быть сдизайнена так, чтобы оставаться свободной, даже если она лицензируется по BSD-лиценизии и половина компонент у вас без исходников. В случае необходимости что-то подкрутить должна оставаться возможность либо сделать враппер вокруг компоненты, либо встроить переходник между двумя закрытыми компонентами.