Что вы думаете об этой фантазии?

А, вы в том смысле, что используете старые версии софта

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

а что не так с раскладкой?

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

Попытки внедрить более оптимальную раскладку есть (https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B0%D0%B2%D0%B8%D0%B0%D1%82%D1%83%D1%80%D0%B0_%D0%94%D0%B2%D0%BE%D1%80%D0%B0%D0%BA%D0%B0) но распространены не слишком широко.

Не понял вашу мысль.

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

И претензии к нынешнему популярному в линуксе bash - именно по второму пункту - скриптам.

А что с ними не так?

Если посмотреть на язык bash именно как на язык программирования - то «не так» там много. Вот только малая часть проблем: https://habr.com/ru/companies/vk/articles/311762/ (в комментариях к статье тоже много интересного)

Например в новых версиях CUPS поддержку моего МФУ выкинули просто потому что.

Засада. Вроде тоже такое с купсом и древним МФУ херокс уже проходили, но это не точно.

может «полететь» ФС

От повреждения ФС надо защищаться специально предназначенным для этого средством - бэкапами. Да, в древние времена это было дорого из-за цены носителей. Сейчас дешево.

лет 10-15 назад это было не редкостью

А лет тридцать назад при разработке под MS DOS компьютер мог виснуть наглухо и требовать перезагрузки по десятку раз за день. Сомневаюсь что для современных разработчиков такое поведение компа было бы приемлимо. Я кстати с вами не соглашусь - если не увлекаться всякими экзотическими файловыми системами то я не видел рассыпавшейся без аппаратных причин ФС уже лет так двадцать.

CUPS же вроде открытый софт? Вытащить поддержку нужного МФУ из старой версии,оформить в виде патча,послать авторам. Вполне может быть что они что-то в своем api поменяли и им было просто лень портировать поддержку малоиспользуемых устройств. Но чтобы такое провернуть - нужен человек, имеющий репутацию в сообществе, связи с разработчиками, и в совершенстве владеющий английским.

Я кстати с вами не соглашусь - если не увлекаться всякими экзотическими файловыми системами то я не видел рассыпавшейся без аппаратных причин ФС уже лет так двадцать.

10 лет назад у меня рассыпалась в хлам XFS(вроде не такая и экзотика) от обычного ресета при зависшей от 12309 тачке. После этого от этой ФС стараюсь держаться подальше.

XFS(вроде не такая и экзотика)

Вот именно что экзотика. О чем я и говорил. Я 28 лет пользуюсь ext[234] и серьезные рассыпания были только по причине аппаратных неисправностей. Причем именно неисправностей,а не просто внезапного отключения питания.

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

А вот если на одном - то на самом деле никакой «отдельности» нет.

Есть.

Любой сбой с записью не по тому номеру сектора - приведет к повреждению «отдельно лежащих» данных.

Зависит от того, что это за сектор, этих «отдельно лежащих» может оказаться и дофига.

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

Та ладно... В «современных» оно вроде стало сложнее(как минимум если есть realloc то уже возможны проблемы), но в былые годы перетыкание платы сгоревшей электроники с аналогичного харда вполне спасало... и больше одного раза спасало.

Так что если мы хотим озаботиться повышением надежности то для этого надо использовать доступные сейчас адекватные средства(например raid с избыточностью)

Ну рэйд рэйду рознь, может оказаться, что raid здорово понизит вам надежность, намек на сгоревший контроллер.

Ну вот в том же UNIX-Haters Handbook и на Хабре жалобы, что много всего не очевидно в UNIX, много костылей. Получается, нужно сделать систему более логичной, целостной и без костылей.

И сразу после того как вы её сделаете, вы начнете добавлять костыли :)

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

Причина проста, невозможно предусмотреть всего.

VLC плеер достаточно десктопный?

И даже там - сколько процентов ассемблера в исходниках?

А вы быстро переобуваетесь, изначально вы написали:

Также как уже избавились от ассемблера в десктопном софте.

----

Первый официальный стандарт языка Ada - именно 83 год.

Стандарт да, а ЯП чутка раньше :)

но в былые годы перетыкание платы сгоревшей электроники с аналогичного харда вполне спасало…

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

может оказаться, что raid здорово понизит вам надежность, намек на сгоревший контроллер.

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

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

изначально вы написали:

Также как уже избавились от ассемблера в десктопном софте.

Просто я застал времена когда на ассемблере бывал написан вполне себе прикладной софт. Например видел такой складской учет для спортивного магазина году в 92. Была задача заставить его приемлимо работать на 8088 процессоре с частотой 8 МГц и 512М памяти. В качестве примера общеизвестного софта вспомню Volkov Commander под MS DOS. Это именно что полностью на асме написанный софт с полноэкранным пользовательским интерфейсом. Сравните с небольшими ассемблерными вставками в VLC - вот это я и называю «избавились от ассемблера». К тому же VLC - сам по себе проект весьма старый,ему четверть века уже. Не удивительно что там есть «ассемблерное наследие» с тех времен когда оно еще объективно было необходимо.

Попытки внедрить более оптимальную раскладку есть (https://ru.wikipedia.org/wiki/Клавиатура_Дворака) но распространены не слишком широко.

Спасибо! Узнал много нового про раскладку дворак.

Понял. Полностью согласен! Случаев когда автор[ы] по той или иной причине забивают на проект больше одного, но его подхватывают другие и софт продолжает жить. В случаях с закрытыми проектами приходится искать альтернативы и не такая уж и редкость когда оказывается, что альтернативы (в единственном числе) которая выполняет нужные вам функции просто не существует, в результате приходится использовать больше одной софтины.

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

Скорее нет, чем да. Я про то, что обьем резервируемого тоже вырос.
1. Личный пример. В былые годы с ноута я бэкапил избранные каталоги, сейчас меня не парит бэкапить его целиком, но и места это занимает соответственно больше.
2. В связи с удешевлением накопителей их качество тоже упало, поэтому кол-во копий тоже увеличилось.

Просто я застал времена когда на ассемблере бывал написан вполне себе прикладной софт. Например видел такой складской учет для спортивного магазина году в 92.

В 92-ом это круто! Оно и в 82-ом круто бы смотрелось.

Была задача заставить его приемлимо работать на 8088 процессоре с частотой 8 МГц и 512М памяти.

С учетом характеристик предполагаю что речи о сетевом варианте не идет, а с учетом года ИМХО это какое-то извращение.

В качестве примера общеизвестного софта вспомню Volkov Commander под MS DOS.

Да, это годная вещь и как раз асм там был очень в тему, малый размер vc был одной из его фич.

Я 28 лет пользуюсь ext[234] и серьезные рассыпания были только по причине аппаратных неисправностей. Причем именно неисправностей,а не просто внезапного отключения питания.

+1

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

«Зависит от...» или «Не всегда».

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

Нет.

Автор - лоб!

ОП - лоб чисто за компанию!

Что вы думаете об этой фантазии?

Наркотики это плохо, п’нятненько?

Причина проста, невозможно предусмотреть всего.

В линуксе вообще нихрена не предусмотрено, по причине базарной разработки и херак-херак и в продакшн.

Иные бзди и то более продуманные, даже не более, а на порядки. Я уж не говорю про винду.

Потому что сейчас нет задач стенографировать речи в реальном времени и «оптимальная раскладка» не нужна?

Потому что сейчас нет задач стенографировать речи в реальном времени и «оптимальная раскладка» не нужна?

Еще скажи посты на ЛОР строчить не нужно!

Спасибо! Узнал много нового про раскладку дворак.

anc у нас тут даже живые пользующиеся есть, если правильно помню)

Что вы думаете об этой фантазии?

Честно пытался осилить, но не смог. Глаза вытекают. КГ/АМ эталонное

И претензии к нынешнему популярному в линуксе bash - именно по второму пункту - скриптам.
А что с ними не так?

Я аж поперхнулся. С моей точки зрения, всё.

Можно начать с основ:

Синтаксис условий в BASH скриптах - главные особенности

А причём тут именно онтопик?

Можно начать с основ:
Синтаксис условий в BASH скриптах - главные особенности

И что именно я там должен увидеть?

И что именно я там должен увидеть?

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

Ну вы бы хоть что-то конкретное привели.

Автор этого дерьма, которое ты поленился пересказать, чем потратил 7 минут моего времени - просто ниасилятор с синдромом утенка.

Обвинять его в этом нельзя.

Но пишет он ерунду от начала и до конца.

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

Ну сделает этот дурак новую современную операционную систему, где диски будут не C:/ или /dev/sda1, а какой-нибудь /disk1. Ну пройдет некоторое время. И уже другой кретин будет спрашивать, а че это за говенная система, где диск до сих пор называется /disk1?

Операционные системы, за некоторым (уже неживым) исключением, развиваются по обыкновенным законам эволюции\естественного отбора. Если какая-то технология есть в ОС - значит на то есть причины, равно как и если что-то убрали из ОС - значит оно там уже не нужно.

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

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

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