Подготовка к 40-летию проекта GNU

GCC (GNU Compiler Collection)

Не нужно, есть LLVM/Clang.

GNU Make

Не нужно, Есть Ninja поверх CMake/Meson.

Glibc

Не нужно. Есть Musl libc.

GNU Net (бета) — анонимная компьютерная оверлейная сеть;

Не нужно. Что это вообще?

GNU Autotools

Не нужно x9000. Есть CMake/Meson/Jam/GN/… .

GNU Emacs

Не нужно. Есть простые редакторы (Kate и т.п.) и нормальные IDE (Qt Creator и т.п.).

Вывод: большая часть GNU не нужно.

... ядро GNU/Hurd (не доделано).

Символично.

Glibc — стандартная библиотека языка Си;

каждый раз как первый ору с фанатиков. нет там большой Г. какие же вы наркоманы

Не нужно, Есть Ninja поверх CMake/Meson.

Автомобиль не нужно, есть ноги.

Газ не нужно, есть дрова.

Лампочка не нужно, есть солнышко родимое.

Магазины не нужно, есть земля-матушка.

Дело в том, что Капитан Очевидность говорит, что было бы ядро идеальным - оно бы использовалось повсеместно.

Ненастоящий какой-то капитан. Дохрена примеров, когда годные решения (годные не значит идеальные, идеала вообще нет) закапывались в угоду порешавшему рыночку. OS/2, PalmOS, BeOS.

Glibc

Не нужно. Есть Musl libc.

Слишком толсто.

Антилопе гну 40 лет
Как быстро время летит

каждый раз как первый ору с фанатиков. нет там большой Г. какие же вы наркоманы

Подумай о своём психическом здоровье, если ты внезапно орёшь в голосину, когда видишь в текстах Glibc вместо glibc, QT вместо Qt, Systemd вместо systemd и др.

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

Не нужно, есть LLVM/Clang.

Но ведь Haiku всё ещё собирается GCC…

https://github.com/haiku/haiku/blob/master/ReadMe.Compiling.md#required-software

А отладчик GDB из проекта GNU всё ещё важен для Linux.

Подумай о своём психическом здоровье, если ты внезапно орёшь в голосину

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

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

Но ведь Haiku всё ещё собирается GCC…

Недоработка, требующая исправления. У меня однажды получалось собирать саму систему с помощью Clang/LLD: https://discuss.haiku-os.org/t/why-mergeobjectfromobjects1-rule-is-needed/9326/21.

А отладчик GDB из проекта GNU всё ещё важен для Linux.

В составе проекта LLVM есть отладчик LLDB.

Ненастоящий какой-то капитан. Дохрена примеров, когда годные решения (годные не значит идеальные, идеала вообще нет) закапывались в угоду порешавшему рыночку. OS/2, PalmOS, BeOS.

Это и значит что не годные.

Про годность легко судить, сидя на современной ОС, на современном оборудовании, тряся стариной.

А добро пожаловать в 90-е, когда ты должен был быть знатоком прерываний, областей памяти, и прочей безусловно важной хрени, чтобы настроить работу звуковухи через референсный драйвер (если он был, лол) в OS/2, в то время когда твой сосед на своей J3QQ4 просто втыкал звуковуху и вставлял дискету.

Никогда не видел тв-тюнеров с надписью designed for OS/2, зато видел их полно для винды.

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

Это кстати одна из причин по которой FreeBSD сегодня около плинтуса. Никому не нужна система, где поддержка технологии (например WiFi ac) появляется через несколько лет после ее внедрения.

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

cmake не самодостаточен, его надо собирать, а собирать его весьма долго, да мало того, он даже компиляцию производить не может, зачем-то требуя make или ninja. Излишнее переусложнение.
Даже autotools при всех его недостатках (он объективно говно) запускается на системе с одним только shell и говорит что делать.
meson - долбанное клоунство с непонятными зависимостями, если и делать систему сборки на питухоне, пусть это будет лучше waf.
на ninja кто-нибудь мейкфайлы писал? зачем вообще эти все костыли?
Был бы толк в генераторах для make/ninja если бы оно могло работать на относительных путях - т.е сгенерировал makefile, забандлил вместе со всеми библиотеками и перетащил его на билдноду, прописав пути к компиляторах. Но этого нет - в эту херню пишутся абсолютные пути делая весь процесс генерации совершенно бессмысленным.
Так что cmake и meson - действительно ненужно вместе с gmake и ninja
musl - clown libc который даже нельзя задетектить макроснёй нормально, притащил в себя все недостатки glibc, да ещё и жырнее

lldb уже может выводя массивы не делать newline под каждый элемент?

на ninja кто-нибудь мейкфайлы писал?

Для этого есть gn от Google. Экспериментально используется в llvm-project.

от google

Но зачем?

cmake не самодостаточен, его надо собирать, а собирать его весьма долго, да мало того, он даже компиляцию производить не может, зачем-то требуя make или ninja. Излишнее переусложнение.

Если нужна самодостаточность, то можете взять систему сборки Muon совместимую с Meson. Для сборки самого Muon не требуется ничего кроме компилятора C99. Даже без Make можно обойтись.

А вот для Autotools требуется жирный Perl (который кстати тоже не нужен). Так что место этому копролиту на свалке истории. Он уступает сковеменным решениям по всем показателям включая портируемости и числу зависимостей.

Наверное потому, что и Ninja родом оттуда. :)

Но я за tup, жаль, что мало где используется.

Muon совместимую с Meson

Не будет он полностью совместимым.

Выпуск системы сборки SCons 4.5.1 (комментарий)

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

А вот для Autotools требуется жирный Perl

Для autogen.sh - да, для работы configure - нет.
Я не спорю что autotools - никому не нужный мамонт, но в нём хотя бы смысл в генерации мейкфайлов есть. Это было важно когда диски были маленькими и сеть медленной - чтобы на сборочную машину закинуть только сорцы и configure, а оно дальше само, а на локальной генерировать этот configure. В cmake он потерян, хотя сама генерация осталась зачем-то.
А так - да, есть куча других хороших систем сборки, но cmake и meson не понятно к чему вообще. Это какая-то попытка заменить автотулз чем-то похожим, но менее убогим.

тормозилла просто привязалась к определённой версии

Я не спорю, что технически autotools – шлак.

Но я люблю проекты, которые его используют, потому что с ним просто работать.

./configure && make

Работает всегда и везде.

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

Да, проерять наличие библиотеки, например, через попытку скомпилировать программу выглядят устаревше. Но я ничего более простого и понятного чем Autotools не видел. Ну разве что голый Makefile.

Для autogen.sh - да, для работы configure - нет.

Зачем нужен configure без autogen.sh? Если вы собираетесь разрабатывать софт, то вам скорее всего понадобится вносить изменения в файлы сборки, а значит понадобится вызывать autogen.sh. А если вы не разработчик и просто хотите пользоваться готовым софтом, то разумнее взять готовый бинарный пакет. Класть configure в архивы с исходниками выглядит совершенной глупостью.

В cmake он потерян, хотя сама генерация осталась зачем-то. А так - да, есть куча других хороших систем сборки, но cmake и meson не понятно к чему вообще.

Разделение на генератор (cmake, meson, gn) и собственно программу сборки (make, ninja) вполне разумно потому что позволяет каждой программе хорошо решать задачу и не изобретать велосипед с реализацией логики сборки для каждого языка описания сборки.

В cmake он потерян, хотя сама генерация осталась зачем-то.

Генерация нужна в том числе для ускорения процесса сбоки. Сборка с помощью специализированного языка будет быстрее чем с высокоуровневым языком сборки предназначенным для написания человеком.

Разделение на генератор (cmake, meson, gn) и собственно программу сборки (make, ninja)

premake5 для этого хорош и прост. Но генерировать ninja до сих пор не умеет.

Совпадение? :)

waf
Требует только питухон (даже со вторым работает), не нужен даже make
Умеет проверять библиотеки и флаги компиляции через запуск компиляции так же надёжно, но в отличие от автотулза умеет делать это параллельно
Проверяет актуальность объектников не по времени, а по чексумме, так что в отличие от make не сломается на системах с кривым временем, а так же не повторяет следующий этап сборки если результат предыдущего не изменился - не придётся запускать линковщик если пересобранный объектник оказался таким же.
Единственная проблема с которой сталкиваться - нежелание виндузятников использовать waf из-за необходимости ставить питухон, но и автотулзы у них без стороннего софта не заработают, так что перед автотулзом тут полное преимущество

если я хочу скомпилить софт, а не разрабатывать его, очевидно. Предположим что бинарного пакета нет.
Опять же в современных системах сомнительное преимущество, но оно хотя бы есть и генерация опять же обоснована в оличие от cmake.
Про скорость высокоуровневого языка - бред. waf на питоне и в нём сборка тормозит? Разве что на эльбрусе, но это свзяано с крайне медленной реализацией питухона под него, так же могли упереться и в медленный ninja

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

Зачем? Что за извращение?

Предположим что бинарного пакета нет.

Очень маловероятно. Это должно быть что-то совсем редкое и никому не нужное.

в швейцарском Биле (Biel/Bienne)

rue de la Source переименовать в rue de la Open-Source :)

Зачем? Что за извращение?

А вот хочу перекомпилировать с -O3 -march=native.

И со многими утилитами так и делаю.

А вот хочу перекомпилировать с -O3 -march=native.

Практическая польза околонулевая.

Смотря для чего. Для утилит компрессии прирост производительности довольно значительный. Например, для zstd:

$ zstd -b9

9#Synthetic 50% : 10000000 -> 3355994 (x2.980), 53.2 MB/s, 1105.3 MB/s

$ zstd-O3-native -b9

9#Synthetic 50% : 10000000 -> 3355994 (x2.980), 55.1 MB/s, 1232.7 MB/s

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

Вывод: большая часть GNU не нужно.

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

Не нужно, есть LLVM/Clang.

Здесь не оценивается нужность или ненужность per se, а празднуется юбилей. Роль GNU в истории ПО гигантская. Без свободного сишного компилятора не было бы ни Линукс, ни свободных BSD. И никакого лулвээм тогда не было, когда GNU уже историю творил.

Справедливости ради подавляющее большинство дистрибутивов собирается GCC, а не LLVM.

Без свободного сишного компилятора

Был же PCC (Portable C Compiler). Роль GNU сильно преувеличена.

ядро GNU/Hurd (не доделано)

Кмк его не доделают уже никогда.

Ты сам-то по своей ссылке ходил?

Debian GNU/kFreeBSD не является официально поддерживаемой архитектурой. Этот перенос был выпущен в составе Debian 6.0 (Squeeze) и 7.0 (Wheezy) как технологическая проба и первый отличный от Linux перенос. С Debian 8 (Jessie) он более не входит в число официальных выпусков.

Jessie, на минуточку, релизнули 8 лет назад.

Прав хватит. Но в некоторых дистрах /sbin, /usr/sbin отсутствуют в PATH юзера, поэтому получишь ENOENT

Да, вероятно.

Однако на сайте GNU сказано, что что-то там пытаются ковыряться. Понятное дело, что это ни в коей мере не может сравниться с Linux, но все же.

https://www.gnu.org/software/hurd/hurd.html

Чем тебе так не нравится GCC?

На фиг он?

make был в *NIX, make есть в *NIX и make будет в *NIX, вопреки всем продвигателям сомнительных программных решений.

Для истории не важно, что было бы, если бы. В параллельной реальности разрешаю праздновать юбилей GNU с PCC на борту вместо GCC.

Ну и не только в *nix, на винде он тоже иногда используется (правда не gmake, а nmake)

Во-первых GCC это не только gcc.

Во-вторых GCC оптимизирующий бэкенд компиляторов.

В-третьих роль GNU не преувеличена. Даже если не рассматривать социальную часть (лицензию GPL), что, кстати, крайне неверно, то реализация различных программ из проекта GNU позволила создать полностью свободную ОС. Если бы RMS кинулся писать не Hurd, а монолитное ядро, то он бы решил проблему раз и навсегда, и никакой «эмулятор терминала» Линуса Торвальдса был бы на фиг не нужен.

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

GNU написал не одно ядро, он написал компилятор, интерпретатор командной среды, зоопарк библиотек, текстовый редактор, кучу прикладного софта, в общем сделал несопоставимый объем работы в сравнении с тем, что сделал Линус к выходу первых версий Linux.

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

Если бы RMS кинулся писать не Hurd, а монолитное ядро, то он бы решил проблему раз и навсегда, и никакой «эмулятор терминала» Линуса Торвальдса был бы на фиг не нужен.

Была бы вместо Линукса BSD и всем бы было даже лучше.

А что такого, что он использует autotools? Он же их не навязывает проектам, которые его используют. А по багам - не субъективно ли?

Возьми любой не самый свежий дебиан. Или какой-нибудь sailfish os или ещё что-то не очень хорошо обновляющееся. Или Linux4Tegra. Там это везде да рядом. Софтины свежей нет, пытаешься собрать, а у них там meson или cmake. Ставишь cmake, а он древней версии и уже требуется новее. В итоге либо потратишь полчаса-час на сборку системы сборки, либо переделываешь билдскрипты под старую. Я вот буквально недавно таким занимался т.к кому-то понадобился билд под 8 дебиан.