GNU/Linux -> Systemd/Linux

Всем плевать. Это лишь договорённости, и главное, чтобы люди друг друга понимали, а называть можно хоть «Linux/GNU/SystemD’эшечка».

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

Не было бы более корректным (по крайней мере debian-подобные дистры) называть systemd/linux?

В debian можно использовать другие системы инициализации

Ты опять ацетон употребил?

systemd/linux <—имело бы смысл— sysv/linux, а не gnu/linux.

А у меня в профиле написано: «Юзаю artix/s6.»

...Беларусь или Белоруссия...

Вопросы этики и языкознания? Татария или Татарстан? Башкирия или Башкортостан? ИМХО «Республика Беларусь» - официальное название, а «Белоруссия» - это по-русски.

Но для себя я решил обходить этот и подобные вопросы, ведь не знаешь точно, на кого нарвёшься.

Что от этого изменится? Ну пусть для идеологически подкованных будут и гну и негну.

ведь все эти микроутилитки, когда-то лежащие в основе системы, более несущественны и несостоятельны в сравнении с системой инициализации

Так ты эта… Уже стёр всё ГНУшное со своего компа? А с компов всех разрабов твоего дистра и репозиториев?

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

А когда перестанет хватать, добавим «больше не гну», «ещё не гну» и «уже согнул».

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

А что сейчас? Сейчас из GNU используется лишь малая толика системных утилит. Если взять типичного современного кодера, который профессионально (с целью заработка) пользуется Linux-дистрибутивами и при этом не луддитит и рукоблудит, то что будет у него на тачке?

Если брать тот же Shell, то в большинстве случаев у программистов это будет экономящий время «Z shell» (zsh), вместо куцого и неудобного GNU Bash.

Если init то systemd, runit, OpenRC, но никак не помойный SysVInit с коллекцией Bash-лапши от GNU.

Если компилятор, то более удобный, быстрый и человечный Clang/LLVM вместо GNU Compiler Collection.

Если консольный текстовый редактор для правки конфигов, то vim или micro или mcedit вместо наркоманского и убогого GNU nano который сразу все сносят.

Если грепалка, то это будет быстрый и крутой ripgrep который затыкает GNU grep по скорости и всяким плюшкам.

Если сборка, то более быстрый ninja вместо GNU make.

GNU Autotools? => CMake, Meson во все поля

Ну и, спрашивается, почему дистрибутив Linux в 2024 году должен называться GNU/Linux??? Да ещё и с GNU на первом месте?! Я вот даже не знаю что там сейчас из GNU осталось в пользовании… разве что binutils?

Так что кладите хер на тех кто просит вас называть Linux-дистрибутивы именно GNU/Linux-дистрибутивами. Если бы разработчики GNU меньше занимались пропагандой и больше писали кода, может быть это и было справедливо, но не сейчас, в 2024, когда их GNU-окружение вообще не является доминирующим внутри Linux-дистрибутива.

Я вот даже не знаю что там сейчас из GNU осталось ли у меня в пользовании…

glibc, конечно же. К дистрибутивам с musl термин GNU/Linux обычно как раз не применяют.

Да, у glibc всё ещё критическая масса, но есть и альтернативы.

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

Тут дело не в гордости. Термин GNU/Linux иногда (довольно редко, когда нет умолчания) бывает полезен именно в плане совместимости с системой. Например, какая-нибудь проприетарная, или свободная уже скомпиллированная программа чаще всего выпускается конкретно для GNU/Linux x86_64. И на большинстве таковых систем она запустится, именно из-за glibc. Если же это Android на ядре Linux, или даже дистрибутив Linux с musl, то уже не запустится. Возможно также, что часть скриптов не запустится, если в системе нет /bin/bash или конкретно гнутого grep. Вот оно всё вот это вот GNU/Linux и заялвенная совместимость с ним. Для таких случаев оно полезно. В подавляющем большинстве остальных, а всяких идеологических в особенности, спорить о том, как правильно говорить — неимоверная глупость и бесполезная трата сил.

чаще всего выпускается конкретно для GNU/Linux x86_64

Я вот кстати всё больше и больше замечаю, что софт (особенно серверный, всякие back-end’ы) разрабатывают на Linux-дистрибутивах с glibc, а запускают в прод на докерном Alpine c musl.

Интересно, есть ли в таком подходе изъян в виде кучки трудноуловимых багов из-за смены libc, или оно +/- одинаково? Всё-таки libc и её вызовы более чем стандартизованы. И если не пользовать гнутыми нестандартными расширениями, всё должно быть гладко.

В musl только одна локаль, насколько я помню. UTF-8 вроде. То есть ограничения в локали как минимум

Вот же сколько ты глупостей понаписал.

zsh вместо bash

такое только у хипстеров

не sysvinit

sysvinit никогда не был GNU, так то полностью мимо

clang вместо gcc

Шланг не нужен.

не nano

Только вот mcedit тоже GNU. А nano никто вроде не позиционировал как официальный gnu-редактор.

ripgrep

Думаю 99% юзеров ни разу его не видело. В том числе я.

ninja, cmake, autotools

Вся эта чушь тащится по зависимостям к сборке чего-то нужного, подавляющее большинство никогда по собственной инициативе ничего из этого не тащили себе в систему. А вот make есть почти везде где что-то компилируется. В том числе он нужен для работы cmake. Правда make не обязательно GNU, ну да ладно.

Я вот даже не знаю что там сейчас из GNU

Хотя бы /bin/echo да и много чего ещё.

Пока ещё можно. Поскольку системда — дефолт для новых установок, и для смены её на другой инит требуется отдельные пляски с бубном (нет, просто apt install sysvinit-core недостаточно), то через N релизов прочие иниты будут выкинуты из очередного релиза с мотивацией «low popcon count» (уж не говоря о том, что любой мейнтейнер в любой момент может придумать из головы какой-нибудь Release Critical баг и выкинуть пакет на этом основании, как минимум один такой прецедент мне известен).

С твом луддизмом пора бы уже на дос пересесть и в борланде софт разрабатывать

Что ты флудишь? Где ты там луддизм усмотрел? Луддизм скорее у zsh-юзеров, которые до сих пор шелл как основную рабочую среду пытаются использовать. А в качестве строки для разового ввода команды всё равно какой он, поэтому все эти недефолтные шеллы малонужны.

Я называл и продолжаю назвать – Linux. Хотя бы потому что мне это просто удобней.

Кхм, а какая альтернатива? Тормозящий повершелл?

Какой ещё повершелл, ты о чём? Парсить и запускать команды умеет баш, больше ничего не нужно. Скрипты пишут либо на posix shell либо на других языках (пхп питон ну или перл если ты извращенец).

А в качестве «основной рабочей среды» используют интерактивные файловые менеджеры. Либо emacs и прочие IDE иногда.

полный набор вишфул-булшит бинго

С твом луддизмом пора бы уже на дос пересесть и в борланде софт разрабатывать

любишь изменения ради изменений? тебе нужен срочный апгрейд колена :)

есть дистрибутив без GNU-кода?🤡🤡🤡

А в качестве «основной рабочей среды» используют интерактивные файловые менеджеры.

Что это такое и с чем это едят? xD

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

Ну shell понятно, он команды исполняет. А mc тут лишний.

Я так в винде с FAR сидел, кстати. cmd.exe слишком убог, через эксплорер мышетыкать — вообще не вариант. А с FAR было терпимо. Вот у него, походу, и под никсами так же, только с mc, несмотря на доступность шелла.

Не было бы более корректным

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

Systemd – не организация, организация называется Red Hat. Поэтому название Red Hat/Linux вполне будет уместным.

Если бы разработчики GNU меньше занимались пропагандой и больше писали кода, может быть это и было справедливо

Так они и писали больше кода. Только больше – не значит лучше. Например, как вот здесь.

Не открывается твоя ссылка. Но на словах «больше кода» я сразу представил libtool.

Если брать тот же Shell, то в большинстве случаев у программистов это будет экономящий время «Z shell» (zsh), вместо куцого и неудобного GNU Bash.

Это какой-то статистикой определено или по принципу «у меня так - значит у большинства так»?

Поэтому название Red Hat/Linux вполне будет уместным.

На слэше можно сэкономить, итого получается «Red Hat Linux». Стоп… Но он же и так уже сто лет в обед Red Hat Linux, так что ничего нового. Расходимся.

vpn включи, я не знаю. Там сравнение нормального /bin/cat на 50 строк и гнутого, в котором почти 1000.

Если б у mc своя история команд была

Alt-h, Alt-p, Alt-n

А что сейчас? Сейчас из GNU используется лишь малая толика системных утилит.

Угу, всего-то только glibc, gcc, binutils, libtool.

Но на словах «больше кода» я сразу представил libtool.

Мне в принципе при этих словах сразу GNU на ум приходит. У них… Свой самобытный неповторимый узнаваемый стиль в этом плане.

gcc, binutils, libtool.

Система разработки программ для ЭВМ

только нормальный Линуксодистр ты без них не соберёшь.

Ух ты, я и не знал. Осталось нормальный перехват всего что с ctrl-o сделать.

В нормальном /bin/cat 5 строк.

Покажи же их!

В openbsd’шном примерно 200, если не считать комменты.

https://github.com/openbsd/src/blob/master/bin/cat/cat.c

А вот гнутый: https://github.com/coreutils/coreutils/blob/master/src/cat.c

Я вот с этого лолирую.

true здорового человека:

vadim@aquila:~$ true --help
vadim@aquila:~$ true --version

true курильщика:

vadim@aquila:~$ /bin/true --help
Использование: /bin/true [ игнорируемые аргументы командной строки ]
       или:    /bin/true ПАРАМЕТР
Завершает работу с кодом состояния, означающем успешное выполнение.

      --help     показать эту справку и выйти
      --version  показать информацию о версии и выйти

Your shell may have its own version of true, which usually supersedes
the version described here.  Please refer to your shell's documentation
for details about the options it supports.

Страница справки по GNU coreutils: <https://www.gnu.org/software/coreutils/>
Об ошибках в переводе сообщений сообщайте по адресу <https://translationproject.org/team/ru.html>
Полная документация: <https://www.gnu.org/software/coreutils/true>
или доступная локально: info '(coreutils) true invocation'
vadim@aquila:~$ /bin/true --version
true (GNU coreutils) 9.5
Copyright (C) 2024 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версии 3 или новее <https://gnu.org/licenses/gpl.html>.
Это свободное ПО: вы можете изменять и распространять его.
Нет НИКАКИХ ГАРАНТИЙ в пределах действующего законодательства.

Автор программы — Джим Мейеринг (Jim Meyering).

Реально эта срань инициализирует gettext чтобы показать переведённый текст))

А, ну и классика:

$ /bin/true --help >/dev/full
/bin/true: ошибка записи: На устройстве не осталось свободного места
Status: 1

Эй! Это моя шутка! Это я обычно ржу с того, что гнутый /bin/true может сделать false.

Угу, всего-то только glibc, gcc, binutils, libtool.

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

В остальном, гнутый тулинг – тоже полнейшая сраная залупа. Я не удивлён, что гнутые всё просрали, потому что с таким-то подходом иначе и выйти не могло. Libc, которую нельзя слинковать статически, это просто какой-то нонсенс!

libc, который нельзя слинковать статически.

libc, у которого мануал по сборке выглядит как книга аркан-магии.

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

Ассемблер с человеконечитаемым синтаксисом.

Ассемблер с человеконечитаемым синтаксисом.

Вот не надо, тут гнутые не виноваты, это AT&T. GAS умеет интелловский синтаксис очень давно уже.