список спорных идей linux

Про /sys и /proc - согласен. Про /media и /mnt - тоже. В /bin лежат бинарники для всех пользователей, в /sbin - для суперпользователя. В /usr/local удобно складывать программы, которые сам собрал из исходников - так они ничего не затрут, не будут мешать тому, что разложил пакетный менеджер.

Пакетный менеджер - это универсальный инсталлятор/деинсталлятор. В Винде попытались к этому приблизиться (всякими *.cab и uninstall.*) , но в итоге каждый софт пишет своb инсталляторы/деинсталляторы, которые выглядят по-раному, глючат по-разному и все равно оставляют мусор в системе. И там фиг разберешь куда ставится программа: C:\Program Files\, C:\Program Files\Common Files\, C:\Documents and Settings, C:\ProgramData, C:\Users\All Users, C:\Users\Public, C:\Users\User\AppData, C:\Windows\* ..., да еще в реестр насрет.

В идеале имя файла вообще не нужно. Нужен его хэш (для программ) и теги (для человека).

плюсую этот архаизм

Можно же иметь и то и другое, не?

Не забываем, что юникс проектировался как (очень) многопользовательская ОС

Ты это всерьёз? UNIX возник как однопользовательская пародия на мейнфреймовую ОС, способная запускаться на слабом железе. Потом к ней добавили поддержку многоюзеровости, но оно по-прежнему было заточено на слабое железо. А (очень) многопользовательские ОС никогда не были похожими на UNIX.

Линуксе точно так же можно было определить стандартом каталоги /rem, /usr/rem, /upd, /usr/upd, в которых лежали бы бинарники для удаления и обновления пакетов соответственно.

Нет, это очень стремно. Например в Gentoo все ставится в специальную папку, потом portage смотрит что было добавлено и именно этот список по факту удаляет. И нет зависимости на кривой uninstaller. Windows - пример модели о которой вы говорите и программы удаления таки кривые.

Ничего, что нет надёжного способа определить тип файла по содержимому? libmagic достаточно часто промахивается, например. А ещё невозможно определить кодировку текстового файла.

В идеале имя файла вообще не нужно. Нужен его хэш (для программ) и теги (для человека).

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

По крайней мере можно разрешить выполнение файла только определенной группе лиц.

Так ведь в линухах, по факту, это всё равно не работает. Скриптоту, если она неисполняемая можно скормить её интерпретатору, а неисполняемый бинарник скормить в /lib/ld-linux.so.*.

Нет, это очень стремно

Чем стрёмно?

Например в Gentoo все ставится в специальную папку, потом portage смотрит что было добавлено и именно этот список по факту удаляет

Я ничего не понял.

Windows - пример модели о которой вы говорите и программы удаления таки кривые.

Они кривые потому что их такими пишут.

В Линуксах, кстати, тоже нередки ситуации, когда после удаления пакетным менеджером от пакета остаются файлы.

Ну мы и имеем верно. Но куча фанатиков считает шелл - нормальным ЯП. В итоге у нас куча говноскриптов.

Ничего, что нет надёжного способа определить тип файла по содержимому?

А по расширению - это такой дофига надёжный способ, что просто сил нет, ага.

в винде у практически каждой программы в её каталоге лежит файлик unistall.exe, в Линуксе точно так же можно было определить стандартом каталоги /rem, /usr/rem, /upd, /usr/upd, в которых лежали бы бинарники для удаления и обновления пакетов соответственно

Изверг…

Я ничего не понял.

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

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

Да не вопрос.

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

Или так: сравни скорость `ls -l` и чего-нибудь типа `find -type f -exec file '{}' ';' ` (пишу по памяти).

Да, перед экспериментами не забывай делать `sync;echo 3 > /proc/sys/vm/drop_caches ` для чистоты, так сказать.

Ты первый :} Для меня — просто и всё в одном месте, удобно.

/media и /mnt нужны. Один автоматический привод, а другой — ручной.

Есть текстовый файл с UTF-8. file считает, что это досовый COM-файл. Мои действия в случае, если софт полагается на расширения, очевидны: сказать, что это .txt. Что делать, если софт расширения игнорирует?

имя наряду с тегами тоже должно остаться

Зачем? Имена файлов в нынешнем виде - это очень хреновый компромисс.

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

Если есть хэш и теги, имя файла просто становится ненужным.

Ничего, что нет надёжного способа определить тип файла по содержимому? libmagic достаточно часто промахивается, например. А ещё невозможно определить кодировку текстового файла.

Собсно я про это говорил (про отсутствие соглашения). А если говорить о надёжности, то по расширению — в принципе ненадёжный способ, т.к. его устанавливает человек. Некоторые так даже пытаются защищать файлы — просто сносят расширение, и надеются, что никто не догадается как файл открыть.

Кодировку по расширению так же не определить (сейчас оно используется только для связи «расширение — программа»), а вот по содержимому можно выделить набор признаков, чтобы определить кодировку, даже недавно по сети гуляла специальная диаграмма :)

Да и тот же kwrite обычно кодировку угадывает.

Вот их то и надо бы… упразднить.

И что же ты хотел сказать? Что ПМ априори ровнее простого инсталлера? Совсем не очевидно.

Он подконтрольный пользователю, в отличие от эвристики.

Берешь любой файловый менеджер с функцией показа мета-данных

Так, а при чём тут метаданные? В линуксе тип файла определяется по содержимому, и происходит это быстро.

Для меня — просто и всё в одном месте

А с атрибутом - сложно и в разных местах, что ли?

В открытой культуре ничего не упразняется так просто. Когда надо делать дело, то все норм обычно. У нас давно все пишется на каком-то Python, Perl, Groovy (это если нужно что-то Java-related, например JDBC, но запускается медленно)

Я считаю, что шелл - прекрасное средство для комбинирования уже существующих программ.

/media и /mnt нужны. Один автоматический привод, а другой — ручной.

Зачем разделять? Почему нельзя в одном сделать?

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

Некоторые так даже пытаются защищать файлы — просто сносят расширение, и надеются, что никто не догадается как файл открыть.

Можно без маразма? Некоторые выключают ПК рубильником, ОС не обязана иметь защиту против этого.

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

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

Любой софт, полагающийся на неё, ущербен по определению.

Да.

Баш, то есть.

Мои действия в случае, если софт полагается на расширения, очевидны: идти курить бамбук

FIXED. Потому что, если там не текст, то вы никогда не узнаете, чем это открывать.

Что делать, если софт расширения игнорирует?

Текстовый редактор -> Open with, не?

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

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

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

А вот, например, ls со всеми его способами сортировки и выводимой информацией это 1 или ближе к systemd-way?

Он подконтрольный пользователю, в отличие от эвристики.

Про MIME вы не слышали, да?

Ну я это и хотел сказать

Ну а я говорю, что это ещё обосновать надо.

Инсталлер работает по алгоритму

Довольно простому, между прочим.

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

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

Так, а при чём тут метаданные?

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

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

В каком Линуксе: в консоли, Dolphin, Nautilus или mc?

Да.

Разверните.

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

у двух файлов может быть одинаковый набор тэгов

Ничего плохого.

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

Если один из файлов чем-то выделяется из остальных - ему дают ещё один тег.

Почему /usr?

Потому что Unix System Resources.

ODT это ZIP или что-то другое? Про MIME ты слышал, да, только это тебе не поможет, мой йуный друг. Причём у текстовых файлов, например, никаких магических чисел нет.

В каком Линуксе: в консоли, Dolphin, Nautilus или mc?

Разве не в любом?

В первом случае я один раз кастую тот же file

Какой ещё file? Мы же тут типы по расширению определяем, не?

Ну вот есть инсталлятор .run. Он внезапно прилетел в какую-то Charka и офигел от неожиданых папок. Потом еще из-за бага например не удалил пару файлов.

Пакетным менеджер все знает о дистре. Он позволит пакету сделать expand в chroot, а потом чисто встроит этот образ в систему, чисто его уберет. У него ведь будет банальный список всех файлов, которые он создал, автоматически сгенерированый. Не факт что приложения деинсталляция сработает так чисто

Жмакаю «показать всё, что скрыто» и тут они все рядом, можно ими оперировать не отходя от кассы. Причём и остальные остаются доступны. Не хочу скрытые файлы обработать? Скипаю без каких-то лишних вызовов.

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

Чего? mount / umount - он одинаков, что при автоматическом монтировании, что при ручном.

ошибка в автоматике

Если я буду бояться ошибки в автоматике, я вообще отключу эту автоматику.

А ещё невозможно определить кодировку текстового файла.

iMac-xtraeft:Downloads xtra$ file live-5f6cdbdb.txt
live-5f6cdbdb.txt: UTF-8 Unicode text, with very long lines