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

Ага, а на входе у этого jq такое же заклинание как и регулярка у grep. Поменяли шило на мыло

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

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

У них одинаковое API, оно в POSIX описано. Хотите использовать дополнительные флаги, назовите свой ls — fbsd-ls — и вперёд.

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

Microsoft way — писать расширения к чужим стандартам. К сожалению, настолько глубоко вошел в культуру, что теперь лепят вообще все подряд.

Расширять API может только тот, кто отвечает за него. За API ls кто отвечает, GNU? Или команда FreeBSD? Никто из них. За него отвечает The Open Group, или как она теперь называется.

Мне как прикладному программисту как настроиться на ваш «расширенный» API, продетктировать его и отличить от другого несовместимого «расширенного» API, если у него нет никакого имени для вызова? Зачем вы хотите паразитировать на чужих именах утилит?

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

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

Просто в gnu их не примут, нужен будет coreutils сбоку, который никому не будет нужен еще лет 15

тут я не понял

выхлоп ls парсить в json не такая уж большая необходимость

не только лишь ls, подозреваю, что в системах мониторинга каждый лепит дичайший мрак

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

Ну про поддержку разных DE как то спорно, ведь есть кроссплатформенный qt или тот-же AWT или SWING в java

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

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

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

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

Вот только… их нет! https://www.youtube.com/watch?v=1fxtACiBVgo :^)

И тебе уже придётся ковыряться в кале бесформатных текстовых файлов валяющихся в /proc/, /sys/ и др. директориях, ковырять их регулярками или самописными костыльными парсерами, в общем дублировать всю ту работу, которую уже сделали разработчики lshw:

https://github.com/lyonel/lshw/blob/fdab06ac0b190ea0aa02cd468f904ed69ce0d9f1/src/core/ide.cc#L4-L7
https://github.com/lyonel/lshw/blob/fdab06ac0b190ea0aa02cd468f904ed69ce0d9f1/src/core/cpufreq.cc#L4

И когда ты накушаешься этого дерьмеца, ты вспомнишь сабжевую дискуссию и изменишь своё мнение.

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

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

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

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

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

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

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

Не в том месте внедряете.

Устанавливайте GNU grep в систему как gnu-grep — и хоть завнедряйтесь.

Я тебя тоже хочу спросить: что за тяга паразитировать на чужих именах команд?

Это что, было родовое проклятие GNU, которая с рождения ставила задачу скопировать чужие API?

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

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

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

Я тебя тоже хочу спросить: что за тяга паразитировать на чужих именах команд?

Ну вот не совсем паразитирование, например, https://github.com/BurntSushi/ripgrep, команда называется вообще rg. Да и работает этот греп куда быстрее того, что идёт в комплекте GNU, функциональность всякую крутую имеет, тот же выхлоп в JSON обсуждаемый тут.

Это что, было родовое проклятие GNU, которая с рождения ставила задачу скопировать чужие API?

Именно так, GNU – сам копия. Всё это, то что мы наблюдаем – GNU, эти расто-попытки и пр. – всё это отголоски улучшения существующих концепций из давно мёртвого оригинального UNIX’а. И если в 1970-ых не существовало общепринятых форматов удобных для последующего написания парсеров и API, то это не значит что так должно быть всегда.

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

Именно так, GNU – сам копия.

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

Почему при использовании bash в качестве системной оболочки, хватает ума понять, что sh должно быть симлинком на bash, а при использовании GNU grep в качестве системной реализации grep не хватает ума понять, что grep должен быть симлинком на gnu-grep?

Интерфейс и реализацию когда программисты научатся не путать?

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

При чем тут парсеры, я тебе про API, ты мне про парсеры.

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

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

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

Но раз Linux «напофиг» кладёт в /sys/ и /proc/ файлики с рандомным форматированием, раз Linux-дистрибутивы не предоставляют никаких вменяемых библиотек для получения системной информации, а вместо этого читают эти файлики и парсят их snprintf’ами, то с какого перепугу автор lshw должен как-то там напрягаться и оборачивать своё творение в библиотеку? Он всё сделал по их лекалам, ответственность-то переложена. Хоть выхлоп JSON и XML прикрутил и на том ему спасибо, а то бы прикладные разработчики используя уже lshw в своих поделках ковырялись бы со snprintf’ами, как он, но уже в выхлопе lshw.

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

А ведь Эндрю Таненбаум предупреждал

Да кто бы говорил, у него до третьей версии драйвера тоже в пространстве ядра крутятся в виде системных заданий. Гибкости ноль: добавил SB, так перекомпилируй ведро целиком, потому что меняется .h файл. А это минут 30 на 286 проце. Долго!

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

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

Они и развивали, вот только решили внедрять расширяющую функциональность в уже ими скопированную. Почему они так решили сделать? Наверное, чтобы не дублировать код и не дублировать кучу утилит внутри /bin? В конце-концов могли бы некий compat-режим организовать, в том случае если по симлинку sh запускается исполняемый файл.

При чем тут парсеры, я тебе про API, ты мне про парсеры.

Так в контексте Shell/Bash – API и парсеры неразрывно связанные вещи.

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

Они и развивали, вот только решили внедрять расширяющую функциональность в уже ими скопированную. Почему они так решили сделать? Наверное, чтобы не дублировать код и не дублировать кучу утилит внутри /bin?

В каком месте bash «дублирует код» для sh. Блин, серьёзно, что ты несешь?!

внедрять расширяющую функциональность

У функциональности должно быть имя. Не ощущаешь внутренних позывов переименовать rsync в cp? Я думаю, и автор rsync-а тоже не ощущал.

А xo-ls почему должен называться ls??

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

Как мне в параллельной реальности поставить в систему rsync, если в том мире никакого rsync нет в природе, потому что автор назвал его cp??

Вот ты то же самое хочешь сделать.

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

В каком месте bash «дублирует код» для sh. Блин, серьёзно, что ты несешь?!

Я про UNIX original grep и GNU grep. UNIX original make и GNU make. Ты несколько зациклился на bash/sh.

А xo-ls почему должен называться ls??

Точно по той же самой причине почему gnu-ls называется ls.

Программистам и пользователям удобно, когда вызывая эти команды в различных окружениях они получают какой-то ожидаемый результат. С оговорками, но всё же. Ну а если результат хочется сделать лучше то они изучают флаги и видят уже BSD, Darwin, GNU-специфику.

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

Вот ты то же самое хочешь сделать.

Единственное, чего я хочу в этом треде – стандартизации, которая позволит выкинуть на помойку sed/awk/grep из тех мест, куда можно внедрить нормальный, а не ломающийся «парсинг» на соплях и клее.

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

Я про UNIX original grep и GNU grep. UNIX original make и GNU make. Ты несколько зациклился на bash/sh.

Я зациклился на том, что сделано правильно, в противоположность тому, что сделано через жопу.

Если что-то реализует классический юниксовый make (который нихрена не умеет, но для 80-х сойдёт), это не означает что это нечто им является или реализует только его.

То есть в смысле логического отношения is-a может и является, но по существу — нет.

Как мне без костылей в одной системе собрать два разных исходника, один из которых использует GNU make, а другой — BSD make??

Вот у меня тут есть:

$ pacman -Qi bmake
Название             : bmake
Версия               : 20210314-1
Описание             : Portable version of the NetBSD make build tool
Архитектура          : x86_64
URL                  : http://www.crufty.net/help/sjg/bmake.html
Лицензии             : BSD
Группы               : Нет
Предоставляет        : Нет
Зависит от           : python
Доп. зависимости     : Нет
Требуется            : Нет
Опционально для      : Нет
Конфликтует с        : Нет
Заменяет             : Нет
Установленный размер : 515,62 KiB
Сборщик              : Ivy Foster <iff@archlinux.org>
Дата сборки          : Чт 08 апр 2021 03:32:20
Дата установки       : Чт 20 мая 2021 12:33:32
Причина установки    : Явно установлен
Установочный скрипт  : No
Проверен             : SHA-256

То есть понимаешь: в одной ОС у меня программы называются make и gmake, а в другой они же — bmake и make. А если ты хочешь выполнить gmake, то извини:

$ gmake
bash: gmake: команда не найдена

А давай в одной ОС функции будут называться malloc() и calloc(), а в другой первая будет называться сalloc(), а вторая — zalloc(). А? Как тебе такое? Нравится?

А — архитектура.

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

Так а какое решение этой проблемы ты видишь? Такое?

$ ls -l /usr/bin

lrwxrwxrwx. 1 root root           7 Apr 23  2021  ls -> gls
lrwxrwxrwx. 1 root root           7 Apr 23  2021  make -> gmake
lrwxrwxrwx. 1 root root           7 Apr 23  2021  ps -> gps
lrwxrwxrwx. 1 root root           7 Apr 23  2021  cat -> gcat
lrwxrwxrwx. 1 root root           7 Apr 23  2021  cp -> gcp
lrwxrwxrwx. 1 root root           7 Apr 23  2021  mv -> gmv
-rwxr-xr-x. 1 root root       42869 Apr 23 21:08  gls
-rwxr-xr-x. 1 root root       42869 Apr 23 21:08  gmake
-rwxr-xr-x. 1 root root       42869 Apr 23 21:08  gps
-rwxr-xr-x. 1 root root       42869 Apr 23 21:08  gcat
-rwxr-xr-x. 1 root root       42869 Apr 23 21:08  gcp
-rwxr-xr-x. 1 root root       42869 Apr 23 21:08  gmv
EXL ★★★★★
()
Ответ на: комментарий от EXL

Такое?

Такое. Или хардлинком.

А есть еще версии:

$ ls -1 /usr/bin/automake*
/usr/bin/automake
/usr/bin/automake-1.11
/usr/bin/automake-1.15
/usr/bin/automake-1.16
wandrien ★★
()
Ответ на: комментарий от EXL

Я бы на месте GNU сразу отделил области ответственности «вот эмуляция UNIX-совместимого API, а вот наше собственное». Это же совсем разные вещи. За определение UNIX-совместимого API отвечает за The Open Group, а за определение своего собственного API они ни перед кем отчета держать не должны и никому следовать не должны.

Ну видимо пока Поттеринг не решил делать systemd OS, никому в голову не приходило, что Linux IS NOT Unix.

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

Такое. Или хардлинком.

А должно ли менятся поведение программы, когда она запускается по симлинку от того, когда запускается явно? Пример – тот же бинарь busybox знает по какому именно симлинку его вызвали и запускает соответствующий код.

Например, таким образом мог бы выставляться «compat»-режим совместимости с поведением оригинального UNIX. Как тот же vim запускается в режиме совместимости по vi в некоторых дистрах.

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

А должно ли менятся поведение программы, когда она запускается по симлинку от того, когда запускается явно?

Ну это уж как ты сам хочешь. Главное, чтобы оно под каждым именем соответствовало поведению согласно спецификации поведения для данного имени.

busybox вообще бомба, вот его и можно было бы оставить для совместимости с POSIX. Но так как coreutils накрутили 100500 лишних флагов на старых именах, и куча софта на них завязалась, то теперь core-crap с линуксом надолго.

wandrien ★★
()

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

Замечу лайвхак вуасяно-детект - если текст не претендует на технический, например, когда начинается с «Начнем с самого святого» и при этом по тексту видно много фамилий, аббревиатур и каких-то цифр - это очередной бред человека, который ничего не смыслит в том, что он пишет.

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

Главное, чтобы оно под каждым именем соответствовало поведению согласно спецификации поведения для данного имени.

Во всех этих концепциях слабое место – прикладной программист и пользователь.

К примеру, если ls будет корректно отвечать на новые ключи gls, то скриптописцы быстренько наплодят скриптцов с использованием команды ls и новыми ключами, вместо gls, которые при запуске будут превращаться в тыкву на других или просто старых платформах. А если будет давать отлуп, то будут писать всегда gls даже в тех случаях, когда скрипт мог бы быть платформонезависимым и задача решалась бы вызовом «чистого» ls.

В общем, в идеальноми мире со стандартизацией и каким-нибудь lint’ом твой вариант бы действительно работал и разграничивал бы эти проблемы несовместимости BSD/GNU утилит, но как видишь каждый привык тянуть одеяло на себя.

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

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

В слаке вот совсем недавно это исправили.

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

К примеру, если ls будет корректно отвечать на новые ключи gls

Я бы не отвечал. Ибо нехрен. google://Ulrich+Drepper+memcpy

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

Ну и ладно.

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

набирает три страницы комментов, потому, что очень скучный ресурс стал.

Да, мы тут все говорим с давным-давно протухшей копипастой, которую притащил ТС:

https://otvet.mail.ru/question/189409778

По давнему русскому обычаю.

Иди своей дорогой, сталкер.

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

упор на консольные приложения.

Консольные приложения есть в Windows

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

Кстати, ковырялся тут недавно в такой шутке, как ProDOS там команды не похожи ни на CP/M и DOS, ни на UNIX-like оболочки.

Например, местный аналог ls -l или dir в ProDOS, внезапно cat, видимо от слова «сatalog». Аналог cdprefix и т. д. После UNIX’овых привычек очень неудобно, но к счастью есть система alias’ов, которые можно накидать в «LOGIN»-файлик, аналог autoexec.bat или .bashrc.

А ещё там разделитель пути – :, а не \ или /, ну и в текстовых файлах для перевода строк используется чисто CR, не CR LF или чисто LF.

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

Я уверен, что «Подход «всё есть объект»» в ОС общего назначения отвечающей современным требованиям и при этом с открытыми исходниками и кучей малознакомых контрибьюторов в 99.9999% невозможна в самоподдерживающемся состоянии без переизобретения подхода к разработке или вливанием огромного числа ресурсов.

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

Можно посмотреть историю самого широко употребляемого протокола с передачей объектов (REST). Там огромная куча проблем которая вынудила придумать GraphQL, у которого тоже куча проблем. Сейчас мы уже видим как дробление на модули которые общаются объектами привело к появлению невероятно сложных систем обеспечения, вроде кубернетиса, где десятки, сотни модулей переплетены самыми причудливыми способами и передают самые причудливые сообщения друг другу. Вся это ужасающая конструкция обычно живёт до тех пор, пока идейные вдохновители и ключевые разработчики не уволились, после чего проще туда не лезть и окуклить этот сложный механизм.

Я не вижу примеров из реальной жизни, где подобные сложные системы могли бы разрабатываться в текущих реалиях в самоподдерживающемся состоянии после ухода ключевых фигур. Это просто сложно и нет опыта как тащить протоколы и объекты 20-30 лет в проекте. Вообще мало у кого есть опыт работы с проектами которым больше 5 лет, как эти люди будут проектировать сложные системы с расчётом на жизненный цикл в десятилетия? Оч херово, вот как.

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

Подход «всё есть файл» тоже откровенно говоря хреново работает и не особо оправдал себя. Подход «всё есть текст» – тоже. Как и подход «всё есть URL» в каком-нибудь Redox.

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

Для удобства использования нужна специализация. Удобно для последующего парсинга использовать объекты или AST? Так используем их, а не ковыряемся с дерьмом из лапши регулярок и sed/awk магии для получения примитивных данных. Удобно для восприятия человеком информации использовать простой текст? Используем его. Удобно отражать память на файл или файл на память – используем без проблем. Удобно в прикладных программах использовать функции библиотеки вместо какой-то дичи со чтением нестандартизированных файлов в /proc/ и /sys/? Так предоставьте же нормальное и удобное для этого случая API, вместо подхода «всё есть файл».

Бездумное следование UNIX-Way, KISS, WYSIWYG и прочим догмам с красивыми аббревиатурами порождает лишь неудобство использования.

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

А ещё там разделитель пути – :, а не \ или /, ну и в текстовых файлах для перевода строк используется чисто CR, не CR LF или чисто LF.

Помню такое. А вот с командами дело не имел.

Еще https://ru.wikipedia.org/wiki/AmigaOS вспоминается с её схемой DEVICE:Dir/File.

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

любой подход начинающийся со слов «всё есть» изначально предрекает какие-то ограничения использования

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

Может где-то у эрланга есть удачные примеры, но это достаточно нишевое применение, чтобы судить и это можно сказать language-specific штуки.

Language-agnostic протокол с возможностью гибкого согласования между сторонами, да чтобы ещё и мог передавать сообщения в како-то среде, без необходимости патчить уязвимости выпуском следующей версии или протокола поверх протокола - это за гранью наших текущих когнитивных возможностей. И если мы можем оглянуться назад и увидеть, что каждый раз не самые глупые люди на планете и в немалом таком количестве обсираются в имплементации самых разных концепций, от «всё есть X», до «реактивных клауд перформенс бинарных и состоящих из десятка базвордов» где все эти классные протоколы просто не проходят проверку временем - может дело в чём-то другом?

Они так же обосруться и с объектами. Да с чем угодно. Может быть человек уже доказал, что не может делать удачные протоколы для общения ПО между собой и пора бросить придумывать серебряную пулю и привыкнуть неудобно жрать говно?

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

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

Или наоборот, такого рода стабильность - когда часть системы грохнулась, но не грохнула всю систему - может быть нафиг не нужна на десктопе. Игрун в каунтерстрайк, если что, просто нажмет кнопочку «Reset».

Убогий «всё есть файл», когда придумали более совершенный «всё есть объект»

Файл можно считать об’ектом, а системные вызовы - методами. Проблема в том, что «всё есть файл» в UNIX не соблюдается в достаточной степени. Самый яркий пример - сетевой В/В.

Множество линуксоидов считают консоль удобным интерфейсом(ага, в 21 веке то) […]

ты написал чушь. Потому что GUI не является более прогрессивным инструментом для всех задач. И даже в самой раздесктопной ОС виндоус есть cmd.exe и PowerShell.

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

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

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

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

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

Троллинг – это хорошо, но не настолько ж тупорылый

Тролль с нами, тролль лучше нас.

hakavlad ★★★
() автор топика

Ты (почти) всё перепутал

Оно монолитное

Знаешь первое правило микросервисования: «do not!»? Ядро такая же программа. монолитность имеет свои преимущества, и это не связано со старостью, альтернативы почти такие же старые.

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

Я бы посмотрел на резуьтат исправления человеком не разбирающемся. хотя нет, и так хватает.

вболее совершенный "всё есть объект

Должно быть либо «менее» либо «сообщение»

текстовый ввод-вывод

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

консольные приложения

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

Если ты про «командные» – тоже мимо, в #$%е мсворды с ёкселями командную строку завезли. Скажешь, из садистских побуждений?

Или ты про «текстовые» – тоже смотрим тенденции, картинки большей частью используются для 3х задач: заставить тебя покупать всячину, вводить инфу в классификатор или корелятор в твоём черепе, или для угадывания чего же тебе от компа нужно. Первое ненужно. Второе роботы уже понемногу научаются, и когда это происходит человеки предпочитают текстовый результат. Третье нужно тем, кто не знает чего хочет, или не умеет обьяснять, а это означает неэффективного человека, а это не очень нужно(хотя тут могут быть варианты). Итого, польза графики маргинальная.

Нутыпонял.

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

При наличии в нём подобных высеров:

Множество линуксоидов считают консоль удобным интерфейсом (ага, в 21 веке то)

Вообще любой текст будет более качественным.

В консоли слишком многое делается быстрее, и есть возможность всё необходимое заскоиптовать. Уж всяко проще нажать Ctrl+R и ввести пару буков, чем надрачивать секунд по 20 у гуях, чтобы сделать то же самое. Если это вообще возможно сделать в гуях. Тем более, что гуи — это зачастую куча бессмысленного кодая не привносящего никакой новой функционалтности. Если ты даже этого не понимаешь, то хз чего ты понимаешь в принципе.

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