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)
Ответ на: комментарий от hakavlad

Я не сказал «пробелы», я сказал «пробельные символы» - это не только пробелы и табуляции.

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

Ну давай, расскажи мне

Меняется версия ядра. Меняются структуры, с которыми работает GetCPUSpeed. Ты бежишь всё пересобирать. GetCPUSpeed на определённой модели порца начинает выдавать не то, что надо, а какие-то другие частоты. Ты опять бежишь пересобирать. У sysctlbyname поменялось то самое «name». Ну ты понял? Или опять нет?

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

Успокойся, другие ОС и ядра не используют лозунг «stable api nonsense», поэтому на GetCPUSpeed(), sysctlbyname(), GetCPUSpeedHz() можно смело положиться в отличие от текста. Что собственно прикладные программисты и делают вместо написания корявых парсеров.

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

другие ОС и ядра не используют лозунг «stable api nonsense»

Так выходит, что дело не в тексте, а в стабильности того, что из версии в версию туда складывают, не так ли?

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

Так выходит, что дело не в тексте, а в стабильности того, что из версии в версию туда складывают, не так ли?

Нет, не так. Использование подхода «текст универсальный интерфейс» в контексте прикладной разработки на самых популярных компилируемых языках – неудобно, небезопасно, медленно, времязатратно, в сравнении с API существующих решений этой задачи в других OS.

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

Нет, не так.

Но ты только что сказал, что

не используют лозунг «stable api nonsense»
поэтому на GetCPUSpeed(), sysctlbyname(), GetCPUSpeedHz() можно смело положиться

Значит, дело не в тексте как таковом и если бы текстовый выхлоп, выдавал только число и не ломал его между релизами, тоже можно было положиться.
Фиксируем переобувание или будут еще возражения? XD
Остальное - не цитирую, чтобы ты опять не перевёл тему.

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

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

Любой текст предполагает собой открытие файла на чтение, парсинг значений (каким бы простым не был формат), закрытие файла.

В контексте прикладной разработки на самых популярных компилируемых языках – это неудобно, небезопасно, медленно, времязатратно, в сравнении с вызовом функций API существующих решений этой задачи в других OS.

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

Любой текст предполагает собой открытие файла на чтение, парсинг значений (каким бы простым не был формат)

С бинарного формата, например, м?

В контексте прикладной разработки на самых популярных компилируемых языках – это неудобно, небезопасно, медленно

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

неудобно

Не удобно кому? Тебе на сишечке? В скриптухе удобнее присобачивать вызов либы твоей ос, чем прочитать файл? У тебя там кто-то орёт про стабильный апи - пошли его нахер, Линус тоже матерился, чтобы не ломали ему юзерспейс. Стабильное апи есть, только пока у вас там 3.5 человек разрабочиков. Когда все начнёт бурно развиваться очень удобно будет всё пересобирать под новое ядро.

небезопасно

Если тебя похакают аж через кусок фс, которую держит ядро, меньше всего тебе надо переживать о том, что вот через апи бы не похакали. Если ты настолько жопорукий кодер, что не можешь распарсить key : value с цифрами не отстрелив себе конечности, то тоже всё печально конечно, но в таком случае тебя ничто не спасёт.

медленно

Будем байтодрочить и считать, насколько бы быстрее одни сисколы вернули long (который также можно прочитать из файла), чем другие сискол(ы) вернут содержимое файла из виртуальной фс ядра + парсиг строки, для разовой операции? Если еще не забыл твоё апи тоже не обязано быть розовым и передавать всегда long вместо char*, лул. Но можешь конечно еще раз херануть сальтуху и запеть, что у тебя api красивое и stable, а в случае фс оно не может быть stable ни в коем случае и дальше начинать приседать и доказывать.

В контексте прикладной разработки на самых популярных компилируемых языках

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

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

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

Что там происходит в твоём гипотетическом манямирке, где API проектируют такие как ты – мне абсолютно не интересно.

Реальная ситуация такова, теоретик: API во FreeBSD, macOS, Windows для этой задачи максимально стабилен и прост, в отличие от текстового выхлопа в Linux, у которого постоянно правится форматирование (из-за чего разваливаются скрипты и наколенные парсеры), кроме того даже предлагаются альтернативы вроде /sys/ в которых уже использутся подход «блин у нас с /proc/ какая-то херня получилась, давайте в этот раз нормальнее сделаем». И это даже не говоря о том, что вместо простейшего вызова функции программист тратит свой драгоценнейший ресурс – время и концентрацию на целевой задаче на написание велосипедного парсера.

Тебе на сишечке?

Ядро на сишечке и самый релевантный софт в этом мире написан на компилируемых языках. И в контексте прикладной разработки на самых популярных компилируемых языках – концепции «всё есть файл» вкупе с «текст – универсальный интерфейс» неудобные, небезопасные, медленные и времязатратные, в сравнении с вызовом функций API существующих решений этой задачи в других OS.

ты настолько жопорукий кодер, что не можешь распарсить key : value с цифрами не отстрелив себе конечности

Других кодеров, пишущих библиотеки вроде libcpuid у нас нет.

Будем байтодрочить и считать, насколько бы быстрее одни сисколы вернули long (который также можно прочитать из файла), чем другие сискол(ы) вернут содержимое файла из виртуальной фс ядра + парсиг строки, для разовой операции?

С хера ли она разовая? А если задача состоит в мониторинге параметров системы с высокой точностью по времени? Угадай насколько вариант с открытием файла и парсингом строки кривым парсером (других похоже прикладные разработчики не пишут) будет сосать в сравнении с простейшим вызовом функции API.

Ладно, раз ты не против фиксируем переобувание с манявром,

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

EXL ★★★★★
()
Скажите, удобно ли разработчику поддерживать свой продукт для 300+ несовместимых дистрибутивов? А еще на каждом может быть по 10 вариаций DE, получая уже 300*10.

Вот такая же история и в web разработке(говорю про фронт), а потом все винят JS и то что фронты это веб макаки…

И всем пофиг, что веб стал таким жирным, потому что уже есть 100500 браузеров и 100500 разных экранов: ноуты, планшеты, смартфон о и как же без широкоформатных экранов….

И все хотят чтобы сайт был кроссбраузерным и отображался везде одинаково красиво….

ИМХО. в будущем мир программирования ждет большая попа… и «640 КБ ОЗУ точно не хватит».

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

Windows для этой задачи максимально стабилен и прост

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

Реальная ситуация такова

Она может быть такова ровно до той поры, пока не придёт пацан с подворотами и всё тебе не испоганет.

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

Ты всё упорно тупишь и не можешь понять разницы между стабильное А и не стабильное Б. У тебя почему-то это намертво привязано к сущности. Это как если бы ты ел исключительно гнилые яблоки и вещал бы, что редька свежая, вкусная, а все эти ваши яблоки - сплошная гниль.

С хера ли она разовая? А если задача состоит в мониторинге параметров системы с высокой точностью по времени?

Если надо с действительно высокой точностью, то лог придётся писать ядру. А так - не великая разница.

Ты хотел «помазать говном» мои аргументы

У тебя нет аргументов. Даже тезисов нет. У тебя устойчивое когнитивное искажение и кидание говном во всех, кто против.

crutch_master ★★★★★
()
14 марта 2022 г.
Ответ на: комментарий от unixnik

Зачем вообще на G505S ставить винду, если этот ноут создан для опенсорса: даже опенсорсным БИОСом coreboot поддерживается...

SakuraKun ★★★★★
()

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


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

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

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

darkenshvein ★★★★★
()

Газету не читал, но осуждаю. Линукс устаревает недостаточно быстро! Мне из-за этого даже на фряху пришлось перейти.:(

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