google://site:linux.org.ru+ненужно

Неплохо было бы ещё приводить аргументацию. Особенно её не хватает ко второму пункту в вашем списке.
От себя:
3) Скрытие файлов не по атрибуту, а по имени.

Расширения имен файлов не нужны.ОС сама может определить тип файла

Не сможет. Например файл с исходным кодом: хрен по нему поймешь что за язык (С и С++ вообще выглядеть могут одинаково, неся разную семантику). Иногда определять тип «дорого»: например odt/odp это по сути просто архив, тоесть необходимо а) определить что это архив б) определить что то, что в этом архиве находится похоже на odt.

Расширения имен файлов не нужны. ОС сама может определить тип файла по содержимому.

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

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

А иконки на что?

4) Множество разрозненных конфигурационных файлов вместо единого реестра.

Не сможет. Например файл с исходным кодом: хрен по нему поймешь что за язык (С и С++ вообще выглядеть могут одинаково, неся разную семантику).

's/не нужны/не обязательны/'

Так лучше?

Некоторые абстракции и обобщения. Сетевая прозрачность вэйиксов тому пример.

1) Множество мелких утилит, каждая из которых выполняет свою функцию идеально, и потом их можно комбинировать (обыв. «unix-way») - это хорошо.

И что ж тут спорного? Разве кто-то кроме не выучивших уроки поттерингофанатов с этим не согласен?

Так лучше?

А смысл их убирать если полностью убрать их нельзя? Они и так не обязательны, и исполнимые файлы часто без расширений, а контет определяется по #!/. А вот как без расширения решать проблему файлов, для открытия которых нужно искать программу: что мне в гугл вбивать для поиска подходящей программы? Вобщем проблема очень широкая, и просто сказать «расширения не нужны» бессмысленно без раскрытия подробностей.

Ну вот, например, сначала думаешь, что 'всё есть файл'. А потом замечаешь, что нихрена подобного и близко нет!

Конфиги в ~/ а не в ~/.config. Но это постепенно решается, слава Богу.

В текстовых интерфейсах иконок нет.

А смысл их убирать если полностью убрать их нельзя?

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

В текстовых интерфейсах иконок нет.

Там есть цвета.

Что-то я не понял, это согласие или не согласие, потому как с вышеперечисленными пунктами 1-4 я полностью согласен и считаю их достоинством. Еще к достоинствам допишу:
+5) Хранение и обмен информации в текстовом виде, за исключением нужд критических для скорости и объема (такие как БД). Аргумент - возможность работать с данными любой программы с помощью разных программ (текстовых редакторов и снифферов) и отсутствие необходимости писать специализированные, как правило убогие утилиты.
+6) Профилирование программы для конкретной платформы на этапе компиляции. Или - нормальная установка программы подразумевает конфиг ( ./configure ) и компиляцию, что позволит программе задействовать присутствующие библиотеки и выбросить поддержку того, что не нужно, или того, что нет. Аргумент - уменьшение объема софта, за счет 1) исключения ненужных участков кода и 2) отсутствие необходимости тащить конкретные библиотеки, иногда конкретных версий, когда аналогичные уже есть в системе.
+7) Четкая иерархия фс
+8) Практичные атрибуты файлов
...

Из недостатков - плохие названия каталогов фс; почему /etc, но ~/.config? Почему /usr?

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

Ну вот, например, сначала думаешь, что 'всё есть файл'. А потом замечаешь, что нихрена подобного и близко нет!

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

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

Нет, не разумно. Это придется считать начало каждого файла, что понять что он есть такое. А если это делать через имя/расширение/метаданные, то достаточно будет считать содержимое каталога. Накладные расходы слишком большие.

1 - это действительно хорошо. Позволяет автоматизировать все мыслимые и немыслимые процессы. А вот systemd-way - говно по определению. Говно на говне и говном погоняется.

Чуваки, а мы тут про линупс

или про юнипс в целом?

А что там не файл, кроме сетевых интерфейсов? И да, кто-нибудь знает почему сетевые и-фейсы не файлы?

Да, вторая очень спорная.

3) initrd - костылище. Точнее он мог быть спроектирован проще. А так целую систему запихнули

4) fork()/exec(). Сейчас конечно оптимизированы, но все же задумка странная. Но тут я признаю, может я не понимаю какой-то важный нюанс, буду признателен за ликбез. На данный момент мне кажется странный клонировать процесс.

5) lock files. Они не чистятся автоматически. Может можно повесить обработчик, но по факту они нифига не чистятся в существующем софте если что-то пошло не так.

4) Множество разрозненных конфигурационных файлов вместо единого реестра.

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

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

Не сможет. Например файл с исходным кодом: хрен по нему поймешь что за язык

а нафига? важно, что он текстовый. Синтаксис подбирает редактор/IDE, а не ОС

Хранение и обмен информации в текстовом виде

Текстовый режим хорош, да ладно вам (text, JSON, XML, YAML). Кроме того когда есть серьзные причины делать бинарь. И Unix-way так и говорит «кроме случаев когда явно лучше бинарь». Отстрел ног никто не рекламирует.

Четкая иерархия фс

Она загадочная да, но PATH короткий при все тех тысячах утилит

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

Это гадание на кофейной гуще. Расширения, конечно, не нужны. Нужно в качестве метаинформации хранить полноценный тип файла. Тогда без каких-либо сторонних данных и предположений можно будет узнать, чем открываются те или иные данные, чего бы в файле не было написано. И отпадёт необходимость в флаге eXecutable, например.

Текстовый режим хорош, да ладно вам

Он просто замечателен.

Она загадочная да

Она достаточно четкая. ПоRTFM'ь.

P. S. Хоть бы аргументировал, что ли.

0) Linux — это круто.

GPLv3

Накладные расходы слишком большие.

Юзкейсом, в котором заметна потеря производительности, не поделитесь?

Гномовый реестр ничем не отличается от раскиданных инишек, только в нем эти самые инишки на xml и положены в одну директорию

У нас есть Unix-way - все перемешать в борщ, или Windows-way - взять папку /opt или Program Files и положить туда софт. Первое требует пакетного менеджера, второе не очень дружит с разделяемыми компонентами. Это вообщем проистекает из культуры закрытости vs открытости.

Но что такое /var/lib? Разделение на */bin и */sbin тоже вроде не похоже на обязательное. */local папки кажутся не очень необходимыми кроме очень особенных конфигураций. /sys vs /proc? /media vs /mnt

Причины всему этому есть, но очень какие-то частные

Там киллер фича - нотификации с дефолтные схемы.

И что ж тут спорного? Разве кто-то кроме не выучивших уроки поттерингофанатов с этим не согласен?

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

COOLEXPLOIT.PNG, который на самом деле скрипт на питоне + устройства, откуда всё читается как +x (DVD?). Разумно, да :}

1 - это действительно хорошо. Позволяет автоматизировать все мыслимые и немыслимые процессы.

На деле нет. Есть тонна вещей, которые не скормить этим вашим утилитам. Есть оверхэд от всех этих форков (см. autotools).

3) Скрытие файлов не по атрибуту, а по имени.

Это правильное решение.

        ALSA_LIB_VERSION=`grep VERSION_STR /usr/include/alsa/version.h 2>/dev/null|awk {'print $3'}|sed 's/"//g'`

        if [ -z "$ALSA_LIB_VERSION" ]; then
                if [ -f /etc/lsb-release ]; then
                        . /etc/lsb-release
                        case "$DISTRIB_ID" in
                                Ubuntu)
                                        if which dpkg > /dev/null ; then
                                                ALSA_LIB_VERSION=`dpkg -l libasound2 | tail -1 | awk '{print $3}' | cut -f 1 -d -`
                                        fi

                                        if [ "$ALSA_LIB_VERSION" = "<none>" ]; then
                                                ALSA_LIB_VERSION=""
                                        fi

Не тошнит?

А это не проблема множества мелких утилит, это проблема шелл скриптинга :}

Возможно вы правы. Ну утилиты превращаются в функции, шелл превращается во что-то нормальное - профит.

О, тред перешёл в обсуждение FHS, это хорошо.

Первое требует пакетного менеджера

Или не требует. По крайней мере, для установки программ. В Линуксе, помимо пакетных менеджеров, есть .bin'ы, скрипты и прочие make install'ы, а в винде - setup.exe. Вот только без ПМ в линуксоподобной иерархии затруднительно обновлять/удалять пакеты. Но и это можно решить: в винде у практически каждой программы в её каталоге лежит файлик unistall.exe, в Линуксе точно так же можно было определить стандартом каталоги /rem, /usr/rem, /upd, /usr/upd, в которых лежали бы бинарники для удаления и обновления пакетов соответственно.

Но что такое /var/lib

Судя по всему, это такой «выручай-каталог», в который пихают всё подряд.

Разделение на */bin и */sbin тоже вроде не похоже на обязательное

Логично было бы разделить на /bin и /usr/bin, этого было бы достаточно.

/sys vs /proc? /media vs /mnt

Издержки постоянного обновления стандартов.

Шелл превращается, превращается шелл.. в элегантный systemd. Простите, маленькая техническая неувязка.

Разделение на */bin и */sbin тоже вроде не похоже на обязательное. */local папки кажутся не очень необходимыми кроме очень особенных конфигураций.

плюсую. интересно, почему бздуны так любят */local

устройства, откуда всё читается как +x

Такому уже ничто не поможет.

Это правильное решение.

Обоснуйте.

X нужен как раз. По крайней мере можно разрешить выполнение файла только определенной группе лиц. Не забываем, что юникс проектировался как (очень) многопользовательская ОС

2) Расширения имен файлов не нужны. ОС сама может определить тип файла по содержимому.

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

В идеале имя файла должно содержать только его имя и больше никакой ненужной информации.

Единственная проблема — нет соглашения по определению типа файла, как например для скриптов.

Разделение на системное и пользовательское ПО. Просто они не осилили /usr