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

Так передача в пайпах по цепочке никуда не денется, а так тебе еще и придётся парсить json структуру

Утилит для этого целая куча, а ещё со стандартизированным выхлопом в JSON/XML/YAML ты сможешь без особых проблем манипулировать данными утилиты из твоего любимого языка программирования.

Никто их старается не трогать

Угумс. Даже такое старое говно как GNU make трогают, пару раз из-за новой версии утилиты make у меня не собиралось старое ядро. То что уж говорить о тех утилитах, которые выхлопывают какую-либо статистику.

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

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

во как! а я даже об этом и не слышал! забавно. для нужда мониторинга и взадимодействия с GUI всяких роутеров. интересно, хоть по большому счету в мирной жизни не нужно. ведь еще вопрос, чем парсить json из cli. и справедливости ради число converted утилит не сравнимо с набором coreutils. я насчитал 2-3 в /bin и /sbin и в районе 10 в /usr/bin/

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

Конечно AMD, кто же ещё. Ноутбук lenovo, видеокарта AMD, обновляет Microsoft а посылать будут на хер, Каму баг репорты писать?

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

Можно просто qjs запустить. Там весь интерпретатор в сборе занимает 1 метр и зависит только от libc. Но чо-т мешает запускать команды системы из qjs…

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

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

Следует отличать «надсистемную» стандартизацию и стандартизацию в пределах Linux-дистрибутивов, в пределах FreeBSD и т. д.

Речь-то о второй.

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

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

Так я на своём любимом ЯП могу и так достать то, что мне надо без использования системных утилит.

Угумс

Ну так я говорю, «стараются не трогать», а не «не трогают».

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

Следует отличать «надсистемную» стандартизацию и стандартизацию в пределах Linux-дистрибутивов, в пределах FreeBSD и т. д.

Я не понимаю, что такое «система» в данном случае. Есть ядро и модули к нему, никакой другой системы сверх того в линуксе нет.

Мы говорим о командах в PATH, это никакая не система, команды тупо ставятся пакетным менеджером какие угодно.

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

ведь еще вопрос, чем парсить json из cli.

Почему обязательно CLI? Ты можешь ведь написать утилиту на том же Python и удобно распарсить себе нужные данные, не обмазываясь калом регулярок. Можешь в Web-прокинуть, будет своеобразный «backend», а «frontend» пусть отдаёт тебе всё красиво и т. д.

для нужд мониторинга и взадимодействия с GUI всяких роутеров

Да, скорее всего Juniper для этих целей всё это и замутил.

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

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

На Python я могу сразу libc-шное API дергать, зачем мне обертки с JSON-калом?

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

Не видел синих экранов на Windows 10

Откуда вы такие берётесь? У меня через раз винда падает, когда я фотоаппарат Сони шнурком подключаю. До этого был J1800 - там винда тупо в результате обновления уходила в синий экран смерти, пока я обновления не отключил.

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

Так для этого надо что-то удолить! =)

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

Можно просто qjs запустить. Там весь интерпретатор в сборе занимает 1 метр и зависит только от libc

Я думаю он будет всё жирнее, чем баш. Хотя...

Но чо-т мешает запускать команды системы из qjs

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

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

На Python я могу сразу libc-шное API дергать, зачем мне обертки с JSON-калом?

Не всё то, что генерируется системными утилитами во FreeBSD или Linux, можно малой кровью дёрнуть через libc.

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

Не всё то, что генерируется системными утилитами во FreeBSD можно малой кровью дёрнуть через libc.

Короче, костыли.

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

Так я на своём любимом ЯП могу и так достать то, что мне надо без использования системных утилит.

Достать инфу какого-нибудь lshw или dmidecode куда проще через их вызов.

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

Ну так стабильного системного API не завезли, что поделать.

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

jq

не стандарт. нет в базовом наборе. проще на python.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)

Не консоль, а мышевозение по экрану нужно в относительно небольшом проценте случаев: GIS, CAD, 3D, Image Processing. Остальные задачи наотличненько автоматизируются через консоль.

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

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

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

утилиту на том же Python и удобно распарсить себе нужные данные

да, я даже выше об этом написал. но я имею ввиду другое. я повседневно сижу в cli. если бы у меня был простой способ использовать возможности xo, даже без скриптов на python - это было бы удобно. стандартная парсилка стандартного формата.

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

ЧСХ, lshw уже умеет в json без всяких libxo.

Да, как раз потому что его вызов из «твоего любимого языка» и последующий парсинг данных реализовать куда проще чем пытаться написать всё самостоятельно или парсить текстовый выхлоп lshw калом из регулярок. Была необходимость и сделали, чтобы было удобнее пользователям и прикладным разработчикам.

Ну то есть кто хотел, давно сделал.

Кроме GNU’тых. В ps и ls JSON-выхлоп лично мне был бы очень полезным.

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

В ps и ls JSON-выхлоп лично мне был бы очень полезным.

Вывод ls стандартизирован в POSIX.

Хватит страдать ерундой, пишите свой собственный xo-ls.

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

Хватит страдать ерундой, пишите свой собственный xo-ls.

Подход с внедрением libxo в эти утилиты как во FreeBSD считаю более рациональным.

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

Подход с внедрением libxo в эти утилиты как во FreeBSD считаю более рациональным.

Ломать API — это очень рационально, да.

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

Если нету какой-нибудь либы типа node-lshw.

А теперь представь, что ты разработчик этой либы. Что для тебя будет удобнее – роняя кал собирать текстовые выхлопы и парсить их кривыми регулярками или же воспользоваться JSON, который порождает выхлоп lshw -json.

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

Ломать API — это очень рационально, да.

А где оно сломано? Ведь по умолчанию утилиты плюют в тебя визуальным «мусорным» выхлопом слабо подходящим для парсинга, как обычно.

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

А где оно сломано?

Один умник написал свой скрипт закладываясь на флаги GNU coreutils, другой — на флаги BSD utils. Где сломано API?

В обоих.

API сломалось в тот момент, когда для вызова нового массива функций кто-то решил использовать старое имя.

Именно поэтому за башизмы в файле, который начинается строкой #!/bin/sh — бьют по рукам, больно.

А тут ты хочешь внедрить новые «башизмы» сразу по гланды.

Если до сих пор непонятно, что башизмы должны вызываться через интерфейс /bin/bash, а через интерфейс /bin/sh — не должны, то я хз.

Это основа проектирования чего угодно.

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

Они отправят к Lenovo, а Lenovo скажут что этот продукт уже не поддерживается и отправит обратно к ним, круг замкнулся. Я знаю, я уже сталкивался с нерабочим USB 3.0 в Windows 8, только там просто отправляли друг к другу, хотя я покупал коробочную версию Windows 8 Pro почти за 10000 рублей. Всё это чушь, не работает? Твои проблемы. Нравится Windows? Да пожалуйста, мне проще от неё отказаться чем с ней пердолиться.

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

А тут ты хочешь внедрить новые «башизмы» сразу по гланды.

Одно дело внедрять их без совместимости «вниз», по примеру Python 2 <=> Python 3, другое дело – с обратной совместимостью.

С таким же успехом можно жаловаться на Bash-скрипты, которые используют новые флаги утилит. Вот, например, в grep добавили недавно какие-то флажки. Что теперь, низзя использовать удобные флажки и начинать страдать?

И да, что-то не видно воплей пользователей в тусовке FreeBSD после внедрения этого libxo по типу:

«О, нет! Разработчики теперь не хотят парсить текстовый выхлоп через каловые массы sed/awk/grep, а используют новомодный libxo, всё пропало! Их скрипты теперь не работают на моём старом говне мамонта с FreeBSD 4. Как же так?! Сдавать мой новый сервер на Pentium Pro в музей, а самому отправляться в дурку?!?!»

Напротив, все только рады.

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

Относительно чего Линукс устарел?

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

И да, что-то не видно воплей пользователей в тусовке FreeBSD после внедрения этого libxo по типу:

да, грамотно сделано. хоть, может, и не в том объеме.

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

Вот, например, в grep добавили недавно какие-то флажки. Что теперь, низзя использовать удобные флажки и начинать страдать?

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

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

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

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

Что для тебя будет удобнее – роняя кал собирать текстовые выхлопы и парсить их кривыми регулярками или же воспользоваться JSON, который порождает выхлоп lshw -json

Мне было бы удобнее реализовать lshw через вызовы системных библиотек.

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

Пацанам надо в обратную совместимость, чтоб не развалилось всё то, что было написано за эти 50 лет. Иначе их замена на православном расте мало кому нужна будет

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

Я думаю, они затрахаются её обеспечивать, а результат будет тот же.

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

Один умник написал свой скрипт закладываясь на флаги GNU coreutils, другой — на флаги BSD utils. Где сломано API?

нигде, у них разное API.

API сломалось в тот момент, когда для вызова нового массива функций кто-то решил использовать старое имя.

с чего это?
если поменять поведение флага - это да, поломать API.
а если добавить новый флаг - это расширение API.

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

То, что написано за 50 лет, запускайте вместе с теми утилитами, которые эти 50 лет и писали.

«Мы перепишем всё на Хруст, даже небо, даже Аллаха!»

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

выхлоп через libxo

Да нормальный, я ничего не говорю. Просто в gnu их не примут, нужен будет coreutils сбоку, который никому не будет нужен еще лет 15, да и выхлоп ls парсить в json не такая уж большая необходимость. Проблема высосана из пальца по большей части.

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