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

Делать его особо универсальным совершенно не обязательно - а точнее наоборот, это будет довольно грязный протокол изменяющийся от версии к версии, и естественно с «расширениями» (или еще как) для разных типов обработчиков.

Я чего-то не понимаю, или таким же образом написана основная масса сложного софта, включая венду, но юниксвеем это там не называют?

Я чего-то не понимаю, или таким же образом написана основная масса сложного софта, включая венду, но юниксвеем это там не называют?

В винде настолько серьезная интеграция между кубиками что оно получается чистым монолитом - и никаких простых внутренних протоколов там нет, там com/dcom и массированный вызов api друг у друга. Собственно то же самое у другого сложного софта.

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

kernel dominated this thread

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

Открыть файл текстовым редактором и посмотреть заголовок, не?

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

Лучше их вообще не делать. Скрытые файлы не нужны. А то потом начнут появляться всякие левые аттрибуты типа «системный» или «только для чтения».

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

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

Скрытые файлы не нужны.

То есть ты предпочтешь в хомяке видеть кроме своих файлов всякий мусор?

А то потом начнут появляться всякие левые аттрибуты типа «системный»

Аналог расширенного атрибута i

«только для чтения».

То же, что и убрать «read»

Скрытые файлы не нужны.

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

ты же не хочешь видеть помойку из файлов, в которой только один-два имеют значения?

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

1. FS is data base. 2. C++ object model (C99 software prevails). 3. multithreading outside of kernel. 4. High-level vacuum. Python/etc are not system wise. Bash is both system aware and high level.

Нужен его хэш (для программ)

А если в системе пару миллионов файлов и произошла коллизия?

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

Есть hard links, есть soft links. Зачем тэги?

Есть hard links, есть soft links. Зачем тэги?

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

Увеличь длину хэша.

Сравни удаление файла в обоих случаях.

1. Допустим, есть ФС с поддержкой тэгов. Какой-то фильм обозначен тэгами «Триллер» и «Драма».

2. Допустим, есть обычная ФС. Какой-то фильм мы положили в /home/Movies/Триллеры/Название_фильма и создали его хардлинк в /home/Movies/Драмы/Название_фильма.

Допустим, в Nautilus/Thunar встроили удобный инструмент для создания, удаления хардлинка, управления такими хардлинками (хотя можно и прогой ln).

Почему второй вариант не может заменить первый?

И это 100% надежное решение?

Вводишь в поиск «триллер» и получаешь фильм? Хрен там, получаешь каталог, в котором этот фильм ещё нужно найти, лол.

100% гарантии не бывает в природе.

какая разница с тегами, если триллеров больше, чем 1?

ну и нафига это на уровне ФС, а не semantic desktop?

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

ну и нафига это на уровне ФС, а не semantic desktop?

Чтобы работало независимо от DE.

интерфейс к «semantic desktop» не может быть DE независимым?

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

год не катит, он может быть в имени файла/структуре каталогов, а вот актеры - да, но имхо это странный юзкейс.

интерфейс к «semantic desktop» не может быть DE независимым?

Может, всё может быть.

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

Угу, и будешь ты копаться в ворохе каталогов.

имхо это странный юзкейс

Обычный юзкейс.

Обычный юзкейс.

для меня более чем странный.

Угу, и будешь ты копаться в ворохе каталогов.

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

удаления хардлинка

Это штатно делается программой rm. Каждое имя файла — хардлинк к айноду. Айнод удаляется когда счётчик хардлинков = 0. Штатных способов получить все имена файла по айноду нет, они тупо нигде не хранятся. Остаётся обойти всё дерево (то есть прочитать содержимое каждого каталога в ФС, что и делает find -samefile) в поисках имён файлов, привязанных к тому же айноду. Дело происходит на ФС, забитой файлами, скорость перебора можешь прикинуть сам. Никакой прикладной софт ничего не ускорит, разве что хранить индекс всех директорий.

Ну а что, SSD сегодня дешёвые.