LINUX.ORG.RU
ФорумTalks

Почему Линукс устарел?

 


0

0

Начнем с самого святого — ядра. Оно монолитное, этим все сказано. Для встраиваемой техники это, безусловно, может быть полезным, но для ПК это выливается в отсутствие гибкости и стабильности. Если в монолитном ядре произойдет сбой — конец. Ядра же с современными архитектурами умеют просто выгрузить сбойный модуль и спокойно продолжить работу.

Далее, в чисто монолитном ядре не предусмотрена подгрузка и выгрузка модулей, что вынуждает перекомпилировать его каждый раз при изменении состава оборудования, откуда и растет мем «конпеляция ведра». Естественно, это не удобно, и разработчики Линукса пошли на шаг, превративший ядро в полный НЁХ: они с помощью костылей добавили подобный функционал. Что вышло? Мы имеем все преимущества и недостатки модульной архитектуры одновременно с недостатками монолитной. А почему у монолита не осталось преимуществ? Они все были нивелированы переходом к модульности. И все равно, как ни странно, все сходятся во мнении, что ядро Линукса по прежнему монолитное со всеми его «достоинствами».

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

Безусловно, после этих слов им можно верить. А ведь Эндрю Таненбаум предупреждал Торвальдса, что ОС с монолитной архитектурой ядра будет гигантским скачком в прошлый век. Едем дальше. Что у нас? О, это же концепции UNIX, положенные в основы Линукса. Ни у кого после этого не повернется язык сказать, что ЛИнукс — современная ОС.

Убогий «всё есть файл», когда придумали более совершенный «всё есть объект»,текстовый ввод-вывод(понимаете, какой это ****?),настройка ОС текстовыми файлами и упор на консольные приложения.

О последнем подробнее. Множество линуксоидов считают консоль удобным интерфейсом(ага, в 21 веке то), но основные приводимые доводы оказываются надуманными от невозможности это доказать не на чувственном уровне. Основные причины любви стоит выделить две: 1)Консоль — главная часть хакерского стереотипа, а поскольку хакером сегодня быть круто и модно, то на бессознательном уровне вырабатывается любовь к черному окну, зелененьким буковкам и непонятным для непосвященных действиям. 2) Мнение, что если разработчики делают консольных программ больше, чем графических, то это круто и должно быть удобно, вот не знаю, но ведь это всё не зря… По правде, это сказывается неоднородность самого Линукса. Пользователю, может, удобно иметь кучу нескучных обоин и DE, но для разработчика просто ад делать свою программу одновременно рабочей для KDE, GNOME и прочих сред. Поэтому он выбирает то, что работает во всех Линуксах одинаково — консоль. Вот и весь секрет: разрабатывать консольные приложения удобно, но это не значит, что их удобно использовать. А всё остальное высосано из пальца. Иксы. Старая вещь, появившаяся еще до рождения Линукса. Гордость каждого линуксоида. И это притом, что их сейчас мечтают заменить чем-то менее прогнившим и более быстрым, но все никак не могут. Вообще, об этом звере из деревянных шестеренок на костылево-скипидарном приводе стоит писать отдельную статью. Пользователи последней убунты сами могут почувствовать, насколько быстрые иксы, запустив htop и поседев от ужаса, наблюдая за показателями ЦП в полном бездействии. Может, вам пофиг, а если у меня ноутбук? Жалко батарейку.

Снова едем дальше. Вы никогда не думали, почему пользоваетей Линукса так мало и почему они с ужасом оббегают Линукс стороной? А потому что не всех устраивает качество и количество софта на него. А почему? А потому что разработчики с ужасом оббегают Линукс стороной. А почему? Вот мы и подошли к главному. Нет, проблемы, описанные выше играют свою роль, но есть что-то по мощнее. Скажите, удобно ли разработчику поддерживать свой продукт для 300+ несовместимых дистрибутивов? А еще на каждом может быть по 10 вариаций DE, получая уже 300*10. А разные наборы разных версий библиотек? Dependency hell? Тоже. Последнее вообще стало отдельным мемом

Отсюда приходим к дальнейшим проблемам: Линукс не только устаревает, но еще и отстает. Хороший пример — недавнее добавление поддержки PCI-E 2.0, в 2012 году,когда все нормальные люди пользовались этим уже в 2008. А ведь во всю бушует PCI-E 3.0 и анонсирован 4.0. Правильно, зачем нам скорость в 16 GT/s, когда есть 5 GT/s? И такое повсюду: когда у всех что-то считается устаревшим, в Линуксе оно только появляется. Никому не хочется писать нормальный софт, потому что и писать то нормально не выйдет, что уж там работать ему, в итоге это ложится на плечи самым упоротым энтузиастам.

★★★

Последнее исправление: hakavlad (всего исправлений: 2)

Таненбаум 30 лет назад это писал.

hateWin ★☆
()
Ответ на: комментарий от crutch_master

Что такое «объект»? Структура? Экземпляр класса ООП?

https://en.wikipedia.org/wiki/Object_(computer_science)

Изменение структуры выхлопа в новой версии не рассыпет твои костыли, расставленные вокруг?

Одно дело поправить метод/поле, другое – найти причину того из-за чего перестала отрабатывать sed/awk дрисня из-за каких-нибудь изменений в дизайне выхлопа вроде использования табуляций, стилевых правок или перемещения полей/колонок.

Делаешь пакет, который будет заварачивать выхлоп системных утилит в json, мейнтейнишь, делаешь алиасы, …, profit! Но почему никто этого еще не сделал?? В чём же подвох?

Вообще-то сделали. Во FreeBSD, man libxo:

https://wiki.freebsd.org/LibXo

И сделали не описанной тобой корявой херотой под капотом содержащей всю ту же sed/awk-дрисню, а нормальным использованием библиотеки внутри структур системных утилит.

В Linux, кстати, возможно скоро притянут тоже: https://aur.archlinux.org/packages/libxo

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от wandrien

Это либа какая-то. Куда её прикручивать, coreutils перекраивать?

Да, во FreeBSD и перекраивают.

https://github.com/freebsd/freebsd-src/blob/main/bin/ps/ps.c#L78
https://github.com/freebsd/freebsd-src/blob/main/bin/ps/ps.c#L244

Другого нормального способа и не существует. Никто в здравом уме не будет мейнтейнить постоянно рассыпающийся набор sed/awk-шлака для популярных консольных утилит.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

In computer science, an object can be a variable, a data structure, a function, or a method, and as such, is a value in memory referenced by an identifier.

По такому расплывчатому определению объеком может быть что угодно, в т.ч. строка текста с разделителями - это тоже объект. Я всё таки спрашивал про ваши с ТСом фантазии.

Одно дело поправить метод/поле

А если у тебя вложенная структура, которую поломают? Ты просто поел говна с текстом и идеализируешь какие-то там объекты, которые сам же не можешь определить. Нет, дорогой, не надо тут мне рассматривать вариант херовое A против качественного B. Если у тебя в тексте выдают говно, объекты должны быть точно такими же говёными, а не какими то там идеальными и удобными. Так-то и текст можно сделать в tsv, который будет парситься без проблем.

Вообще-то сделали.
В Linux, кстати, возможно скоро притянут тоже

Может притянут. Еще лет через 5.

crutch_master ★★★★★
()
Ответ на: комментарий от wandrien

Это очень зря. dll hell ничему не учит.

Объясни, каким образом там он возникнет?

Нужны утилиты с новыми именами.

Они и появляются, например вот: https://github.com/BurntSushi/ripgrep

$ rg Comix
ChangeLog
433:  + Added preliminary H counter emulation. Comix Zone and Sonic 3D Blast

$ rg Comix --json
{"type":"begin","data":{"path":{"text":"ChangeLog"}}}
{"type":"match","data":{"path":{"text":"ChangeLog"},"lines":{"text":"  + Added preliminary H counter emulation. Comix Zone and Sonic 3D Blast\n"},"line_number":433,"absolute_offset":21623,"submatches":[{"match":{"text":"Comix"},"start":43,"end":48}]}}
{"type":"end","data":{"path":{"text":"ChangeLog"},"binary_offset":null,"stats":{"elapsed":{"secs":0,"nanos":76593,"human":"0.000077s"},"searches":1,"searches_with_match":1,"bytes_searched":24237,"bytes_printed":306,"matched_lines":1,"matches":1}}}
{"data":{"elapsed_total":{"human":"0.012061s","nanos":12060583,"secs":0},"stats":{"bytes_printed":306,"bytes_searched":24237,"elapsed":{"human":"0.000077s","nanos":76593,"secs":0},"matched_lines":1,"matches":1,"searches":1,"searches_with_match":1}},"type":"summary"}

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

EXL ★★★★★
()
Ответ на: комментарий от EXL

Другого нормального способа и не существует.

Нормальный способ - форматирование выхлопа самими утилитами.

а нормальным использованием библиотеки внутри структур системных утилит.

Это такая же херня сбоку, которую надо поддерживать, чтобы она работала с новой версией coreutils.

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

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Ты просто поел говна с текстом и идеализируешь какие-то там объекты, которые сам же не можешь определить. Нет, дорогой, не надо тут мне рассматривать вариант херовое A против качественного B. Если у тебя в тексте выдают говно, объекты должны быть точно такими же говёными, а не какими то там идеальными и удобными. Так-то и текст можно сделать в tsv, который будет парситься без проблем.

+1

Всё верно.

Разрабы 20 лет говна навешивали, а теперь как возьмут и исправятся из-за одной либы. Ага, щас. Вот либы-то им и не хватало.

wandrien ★★
()
Ответ на: комментарий от EXL

Стандартизация не только текстового выхлопа

Тут плюс, но это не json объект, который будет срать названиями полей и тормозить и без того тормозную текстоту. Я молчу про обход вложенных структур и прочего мракобесия. Пишешь свой говнокод ты один раз, а работает оно потом годами.

но и тех же общеупотребимых параметров консольных

Про технический долг слышал?

crutch_master ★★★★★
()
Ответ на: комментарий от wandrien

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

Но это должен быть не жсон.

fernandos ★★★
()
Ответ на: комментарий от EXL

Объясни, каким образом там он возникнет?

У тебя есть фряха со своим libxo, у тебя есть какой-нибудь условный busybox со своим отдельным велосипедом, и у тебя есть coreutils, в которые никто libxo запилить не успел, зато как обычно у них свой собственный набор особых ни с чем несовместимых флагов. А еще есть утилиты в Darwin…

Угадай, что будет делать разработчик клиентского кода? Использовать определение из POSIX и страдать.

Новые интерфейсы должны иметь новые имена, чтобы их можно было поставить в систему независимо друг от друга. И чтобы разработчик клиентского кода мог внятно написать в документации: «для работы требуется поставить XYZ с сайта ABC». А пользователь мог это поставить без плясок с бубном в chroot, контейнере и хер знает чем.

А не вот это говно, когда make в BSD и make в Linux — полностью разные программы, у которых совместимость только на уровне примитивного API из 1989-го года. (и то не факт)

wandrien ★★
()
Ответ на: комментарий от crutch_master

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

Вот только этого в мирке GNU-утилит нет. Нет ни общепринятого формата выхлопа, ни общепринятых разделителей, которые бы использовали разработчики в своих консольных утилитах.

просто поел говна с текстом

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

и идеализируешь какие-то там объекты

Я за стандартизацию. А что там будет под капотом, объекты, структуры или вообще AST-представление: https://baat.z-lab.me/~exl_lab/screens/lisp_shell.png – мне до лешего. Ты просто увидел где «объёкт» и начал исходить на словесный понос.

EXL ★★★★★
()
Ответ на: комментарий от wandrien

Почему-то bash не обломался называть bash, не претендуя на то, чтобы заменить собой POSIX-овое определение sh.

O RLY?

ll -l `which sh`
lrwxrwxrwx. 1 root root 4 Jul 27  2020 /usr/bin/sh -> bash
EXL ★★★★★
()
Ответ на: комментарий от EXL

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

Сначит нужно делать новые базовые утилиты. Хватит насиловать cp и ls.

wandrien ★★
()

Консоль удобна не количеством программ, а их взаимодействием. Принцип «не хочешь работать с программой сам, используй другую программу» во все края.

Miguel ★★★★★
()
Ответ на: комментарий от EXL

Я за стандартизацию.

Так с этим никто не спорит.

А что там будет под капотом...мне до лешего

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

Ты просто увидел где «объёкт» и начал исходить на словесный понос.

Так это вы хотите «объект», но не можете определиться с тем, что хотите.

crutch_master ★★★★★
()
Ответ на: комментарий от fsb4000

Я сейчас материться начну. Ноутбук шёл с Windows 8, lenovo g505s, Windows 10 обновляет драйвера автоматический которые первое не работают от слова совсем, второе вылетает синий экран при запуске видео проигрывателя или браузера даже после установки рабочих дров. Ни один из способов заблокировать обновление драйверов не работает, пол года бился с этой проблемой, или отключай обновления вообще или страдай. Помогает только установка Windows 10 LTSC, там драйвер не обновляется. Это из последнего на одном только ноутбуке. На ПК с i5 3550 постоянно вылетал синий экран вообще рандомно, и как раз после установки каких то обновлений, поскольку чистая установка Windows 10 и до установки обновлений синего экрана нет. Кушайте сами, спасибо.

unixnik ★★★★★
()
Последнее исправление: unixnik (всего исправлений: 2)
Ответ на: комментарий от EXL

Мять, в cp даже содержимое одного каталога в другой нормально не скопируешь.

Интернет-разум для этого вообще советует использовать tar. Спасибо.

Короче, реально хватит их насиловать. Это наследие из 70-х для запуска старого софта.

Пишите новые!

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Наткнулся, что гнушники почему-то не хотят делать нормальный выхлоп в ls. Я хз, почему никто не озаботился до сих пор, если «всем» так нужно парсить выхлоп coreutils. Ощущение, что им дали свободу, а они сидят и жрут с лопаты.

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Нормальный способ - форматирование выхлопа самими утилитами.

По стандарту. А лучше двум – для последующего парсинга и для чтения человеком. А их нет. Системные утилиты формируют выхлоп кто во что горазд, а потом как ты правильно выразился прикладные разработчики «едят говно» теребонькая awk, sed, grep и др. чтобы получить доступ к нужной им информации.

Это такая же херня сбоку, которую надо поддерживать, чтобы она работала с новой версией coreutils.

Нет, ибо libxo внедряемый в проект в ответе за формирование выхлопа всех мастей, как текстового читаемоего, так и json/xml/html.

json объект, который будет срать названиями полей и тормозить и без того тормозную текстоту.

Это просто смешно на фоне чудовищно медленного парсинга текста регулярками на фоне перекидывания его по пайпам в цепочке вызовов утилит, как ты правильно выразился, для «поедания говна».

Про технический долг слышал?

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от unixnik

пол года бился с этой проблемой

Кушайте сами, спасибо.

Писал lenovo? Или Microsoft? Кому вообще баг репорты отправлял? Или как истинный лоровец только по форумам рассказывал?

fsb4000 ★★★★★
()

Оно монолитное, этим все сказано.

неправда, модульное)
садись, кол.
перепиши сочинение.

darkenshvein ★★★★★
()

Далее, в чисто монолитном ядре не предусмотрена подгрузка и выгрузка модулей, что вынуждает перекомпилировать его каждый раз при изменении состава оборудования, откуда и растет мем «конпеляция ведра»

модераторы, спилите у него обе звезды за грубое незнание матчасти!

darkenshvein ★★★★★
()
Ответ на: комментарий от fernandos

Но это должен быть не жсон.

И именно поэтому лучший архитектурный подход, чтобы утилита отдавала объект или AST-представление, во внешнюю библиотеку, которая бы уже генерировала предпочтительный для тебя выхлоп – JSON, XML, HTML, YAML, обычное визуальное текстовое представление и др.

Именно по этому принципу libxo из FreeBSD, сделанный Juniper Networks и работает.

И на него переписывают системные утилиты с захардкоженного выхлопа.

EXL ★★★★★
()
Ответ на: комментарий от crutch_master

Есть как минимум требование к возможности потоковой обработки выхлопа.

Визуальный текстовый вывод в системных утилитах FreeBSD (которые начали базироваться на libxo) никто не отменяет, так что теребонькающие awk/sed/grep будут продолжать теребонькать как ни в чём не бывало, оно лишь добавляет удобные и стандартизированные представления, на которые можно опираться при написании парсеров вместо утилит для «поедания кала».

Так это вы хотите «объект», но не можете определиться с тем, что хотите.

У тебя какая-то нездоровая фикция на этой сущности.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Это просто смешно на фоне чудовищно медленного парсинга текста регулярками на фоне перекидывания его по пайпам в цепочке

Так передача в пайпах по цепочке никуда не денется, а так тебе еще и придётся парсить json структуру (теми же регулярками, например, лол), раскладывать её по полям и валидировать (если не лол), что конечно же будет намного быстрее. Ты реально, как будто поел говна и тебе кажется, что другое говно вкуснее.

Технический долг в отсутствии стандартизации GNU и др. консольных утилит успешно переложен на прикладных программистов

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

К тому же всё это бла-бла-бла не конструктивно. Конструктивно - выделение технических требований, но на ЛОРе этого не дождешься. Тут как прищимит, то все орут «ололо говно, зделайте объекты как в венде», а как доходит до конкретики, так вся конструктивность скатывается до «зделайте как-нибудь, чтобы *МНЕ* было хорошо и *Я* одобрил». Я уже не говорю, про какие-то действия. Страх проявить инициативу подсознателен и пройдёт, видимо, только со сменой пары поколений, но это не точно. А пока все недовольные будут орать «зделайте мне быстра» и кидать говном с сторону какого-нибудь там царя.

crutch_master ★★★★★
()
Ответ на: комментарий от wandrien

Ты насмотревшись на Gnome и KDE еще не понял, чего стоит вся эта стандартизация?

Пример FreeBSD, Solaris и AIX – начало стандартизации консольных утилит. Пример Haiku – начало стандартизации системного GUI.

Может когда-то и до Linux доберуться хорошие практики, кто знает.

EXL ★★★★★
()
Ответ на: комментарий от EXL

У тебя какая-то нездоровая фикция на этой сущности.

У меня нездоровая фикция на невнятных требованиях и надрачивании на карго-культ.

crutch_master ★★★★★
()
Ответ на: комментарий от EXL

Пример FreeBSD, Solaris и AIX – начало стандартизации консольных утилит. Пример Haiku – начало стандартизации системного GUI.

xkcd://standards

wandrien ★★
()
Ответ на: комментарий от EXL

Может когда-то и до Linux доберуться хорошие практики, кто знает.

Если только сидеть и гунтеть на ЛОРе ничего точно никуда не доберётся.

crutch_master ★★★★★
()

и при этом ТС активно атаковал форум новостями о своем демоне, решающем 12309 на Linux. я че-то не понимаю, какое впечатление о себе ТС хочет создать.

тред вообще бессмысленный. все это мы уже давно знаем. но куда интереснее вместо таких тредов читать

Haiku, Inc. проспонсировала приобретение RISC-V материнских плат для портирования системы Haiku

там hybrid ядро. вперед.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 2)
Ответ на: комментарий от EXL

Визуальный текстовый вывод в системных утилитах FreeBSD (которые начали базироваться на libxo) никто не отменяет, так что теребонькающие awk/sed/grep будут продолжать теребонькать как ни в чём не бывало, оно лишь добавляет удобные и стандартизированные представления, на которые можно опираться при написании парсеров вместо утилит для «поедания кала».

А что делать тем, кто написал свой скрипт с молодежным JSON под FreeBSD, а потом оказалось, что ни под одной Linux- и Darwin-системой это говно не работает?

Идти на поклон к теребонькающим grep, чтобы научили тайному знанию?

wandrien ★★
()
Ответ на: комментарий от EXL

Rust

Начали с говна, молодцы.

https://github.com/uutils/coreutils#utilities

Кого, #####, они там «пишут»? Реально тут слово cargo в ридми выглядит не как название пакетного менеджера, а точное описание творящегося ада. Они переписывают coreutils! на Rust! для обеспечения полной совместимости! со старыми именами утилит!

Можно я сразу в окно, я не могу больше смотреть на эту идиотию.

wandrien ★★
()
Ответ на: комментарий от wandrien

а потом оказалось, что ни под одной Linux- и Darwin-системой это говно не работает?

Учитывая различия BSD- и GNU-утилит, вроде того примера с make который ты упомянул, и если добавить сюда ещё обязательный порядок ключей и пр. особенности, возникает вопрос: а оно вообще когда-либо нормально работало?

Так что не велика потеря.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Учитывая различия BSD- и GNU-утилит, вроде того примера с make который ты упомянул, и если добавить сюда ещё обязательный порядок ключей и пр. особенности, возникает вопрос: а оно вообще когда-либо нормально работало? Так что не велика потеря.

Ну и смысл тогда о какой-то стандартизации сопли мотать?

Вот так и пишут, делая костыли с export MAKE=gmake или подменяя на лету имя команды через подстановку в PATH временного каталога, лечащего пространство имён.

А на разработчиков прикладного кода всем положить, весь технических долг переложен на них. И тебе тоже положить.

wandrien ★★
()
Ответ на: комментарий от wandrien

Начали с говна, молодцы.

Кстати, если кому надо говна объектов, то можно замутить ос на основе js, там будет интерпретатор, объекты, выхлоп утилит будет в нормальном виде, системд тоже заменим, нахер он нужен. Да можно тупо ноду поставить, получится node/linux без сустемд все дела. EXL только первый меня съест живьём вместе с нодой и всем дерьмом.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 2)
Ответ на: комментарий от EXL

Жостко, конечно. Я всё еще под впечатлением.

Разработка новых утилит означает разработку нового клиентского API. Разработайте новый лексикон, на котором ту же мысль можно выразить в 4 раза проще и короче, если вас не устраивает старый.

Нахрена вы переписываете API 70-го года просто на новую реализацию???!

wandrien ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.