Вот нафоткал ты 100500 фоточек. Будешь тегировать сразу при фотографировании или как?

А как ты обычно делаешь? Подключаешь фотик к компу и скидываешь всё нафотканное в каталог, например, «Отпуск». Ну и с тегами так же: даёшь всему скинутому тег «отпуск» и готово.

Так имена же не нужны, не?

Не нужны.

Придумывать — нужно, но только 1, а не 100500

Даже для 100500-от файлов?

Точно Unix.

http://www.youtube.com/watch?v=tc4ROCJYbm0

Ну как же, шрёдинские стандарты. Они как бы есть, но их как бы и нет, потому что на самом деле это филиал Гнома.

Там, хотя бы, есть иерархия

Сомнительное удовольствие - прыгать по иерархии. Мне куда проще и приятнее вести в строку запроса ключевое слово и получить результаты.

Во фре же вроде /usr/home или /usr/local/home

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

Это бесспорно хорошая идея. Реестр глобальный и потому работает медленее с ростом количества данных, плюс бегать по нему кто угодно может. А отдельные конфигурационные файлы позволяют запилить удобнейший API вроде NSUserDefaults и QSettings, который выдаёт программе только её собственные настройки.

Ну кроме того неоспоримого факта что Гном - главный DE... ;)

Все же в чем? Тулкиты? Привязка к пакетам?

даёшь всему скинутому тег «отпуск» и готово.

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

Даже для 100500-от файлов?

1×100500 vs 100500×100500.

Это всего лишь страх перед кривой реализацией, развившийся из-за общения с виндой.

Оно как минимум спорное.

From: Rob Pike <robpike@gma...> Subject: Q: moving directories? hard links? Date: Sat, 16 Apr 2011 11:56:46 -0700

On Sat, Apr 16, 2011 at 11:17 AM, Skip Tavakkolian wrote:

Linux has slowly become Windows-lite

Except for the lite part.

-rob

Гном не может быть главным DE, он же умер…

Все же в чем?

Я вообще-то не шучу там выше :}

Быдлокодинг, что я могу сказать.

Избавь меня от своих фантазий, ок?

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

Я в самом начале сказал, что МНЕ, КАК ПОЛЬЗОВАТЕЛЮ файловая ирерахия НЕ НУЖНА.

Все с тобой ясно. Тебе достаточно «Pictures», «Music» и «Documents» )))

Мне куда проще и приятнее вести в строку запроса ключевое слово и получить результаты.

find / -name $name

Энджой.

Это пародия на то, что мне нужно.

Это пародия на то, что мне нужно.

Это иллюстрация того, что поиск - не панацея.

Присоединюсь к срачу про типы файлов. Думаю, самое правильное решение чтобы тип файла был отдельным атрибутом, не пересекающимся с именем. Почти как в макоси до 10-й версии, но произвольной длины (там было только 4 символа). Кстати говоря, очень жаль что это не стало стандартом, даже 4 символа это лучше чем в винде и в линуксе сейчас.
Описание типа должно быть по принципу от общего к частному, что-то типа MIME. Сначала описывается контейнер (если есть), потом содержимое, потом свойства. Отдельно отмечается что это, как неделимое целое, т.е. что это с т.з. пользователя.
Например, для документа OO Writer:

zip/xml/utf-8
OpenOffice Writer document

Смысл в том, что так легче искать чем открывать, а файловым менеджерам проще определять что внутри и что из этого можно достать.
Файловый менеджер может и не знать что такое OpenOffice, но при этом может осуществлять полнотекстовый поиск по таким файлам.
Конечно формат нужно продумать, но, суть примерно такая.

тип файла был отдельным атрибутом, не пересекающимся с именем

user_xattr. Там на fdo (ха-ха, да) есть стандартное поле для такого действа. Правда почти всем на него пофиг (модуль апача может читать, AFAIR).

Да, конечно, как и расширение, это можно «подделать». Но и с определением по содержимому тоже можно обмануть систему:
cat secret.zip >> flowers.jpg

Панацеями пусть эльфы занимаются.

иксы уже упоминали?

Файловый менеджер может и не знать что такое OpenOffice, но при этом может осуществлять полнотекстовый поиск по таким файлам.

И по запросу ubuntu радостно выдать тонну openoffice-документов, в которых используется шрифт семейства ubuntu. Нет, без знания внутренней семантики никак.

срачу про типы файлов

tar'осрач никому не интересен?

При использовании кучи утилит в целях автоматизаци код получается хуже php, при малейших изменениях перестаёт работать. Можно ещё вспомнить про

rm -rf /usr /lib/nvidia-current/xorg/xorg

И ещё часто не хватает выделения функциональности сложной утилиты в библиотеку. libpython и libclang — это хорошо, а за нелюбовь баша к ! и @ и отказ экранировать их православным бекслешем хочется баш расстрелять. Можно ещё пройтись по лженаучной идиоме «всё есть файл», из-за которой любая программа есть сложный и глючный парсер: достаточно вспомнить, что при маленьком изменении user agent в Firefox некоторые сайты сразу же перестали работать, а частые изменения в структуре sysfs/procfs не дают уважающей себя десктопной программе безгеморройно запросить информацию о запущенных процессах. Суть в том, что наличие юниксвейной утилиты мешает людям осознать пользу разделяемой библиотеки.

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

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

И по запросу ubuntu радостно выдать тонну openoffice-документов, в которых используется шрифт семейства ubuntu.

zip/xml/utf-8
OpenOffice Writer document

Тут не зря написано xml. Шрифт это атрибут тэга. Поэтому файловый менеджер не будет так делать. Но, конечно все зависит от ФМ, всегда можно сделать через попу.

частые изменения в структуре sysfs/procfs

...ничем не хуже частых изменений в API библиотеки.

хочется баш расстрелять

Ты мыслишь в правильном направлении, камрад. Два rc тебе.

Но и это можно решить: в винде у практически каждой программы в её каталоге лежит файлик unistall.exe,

Решение так себе, эти деинсталляторы не всегда корректно работают. Прошедшей осенью видел на хабрахабре нытьё про то, что уважаемый BlackBerry SDK от уважаемой Research in Motion при установке в папку $HOME на маке удаляет эту самую $HOME в случае деинсталляции.

В остальном я целиком с вами согласен.

...ничем не хуже частых изменений в API библиотеки.

Ничем. Вот только в библиотеках можно и не менять API, просто добавляя новые вызовы, как это делают в OpenGL. При изменении формата файла в sysfs/procfs (даже при добавлении данных в конец) часть парсеров в программах уже может сломаться.

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

Поэтому ZIP-архивы у тебя будут открываться в OpenOffice, или наоборот - документы ODT в архиваторе. Ну а чо, круто же.

Вы немного опоздали к дискуссии. ☺

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

при установке в папку $HOME на маке удаляет эту самую $HOME в случае деинсталляции.

ну хоть при деинсталляции, а не установке, как некоторые :)

просто не сильно нужно

Это пока не сильно нужно. И снова обычная проблема: пока линуксоиды кричат «ненужно», всякие Венды и Макосы внедрят тего-ориентированную ФС, юзеры быстро привыкнут (потому что к хорошему привыкают быстро), а Линукс опять в отстающих, зато бородатые консерваторы счастливы, что их привычки не поменяются, да.

...ничем не хуже частых изменений в API библиотеки.

Намного хуже. Изменения API сломают программы. Изменения в файлах + ad hoc парсеры дадут непредсказуемые результаты.

список спорных идей linux
1) Множество мелких утилит
2) Расширения имен файлов не нужны.

- Да вы батенька, наверное вендузятник.
- А как вы догадались???
- Парашют за спиной ^W^W^W В 21 веке расширения имен файлов поминаете.

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

на мой взгляд упор на этот тупак не даёт линуксу развиваться, вот.

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

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

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

1) всё правильно.
2) нет, это опять юникс вей - тебе предложили механизм, используй как хочешь, иными словами никто не заперещает добавлять к имени файла расширение. и оно даже не обязано быть таким как в досе, из трёх букв.
3) атрибуты в имени файла - стремление к простоте. зачем обязывать разработчиков фс делать атрибуты отдельным полем в фс, если их можно засунуть в имя? с другой сторы это не сильно удобочитаемо, зато проще в реализации. думаю это хорошо.

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

Telepathy?

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

адиум/пидгин + libpurple?

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

да, это пример того как оно могло бы работать. на мой взгляд.

Они там пихают всё-всё-всё в один файл что ли?
Это уже походит на WinAPI: функции о десяти параметрах, большинство из которых обязательно будут NULL.

а есть там что-то кроме телепати? из гуя?

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

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

Не тошнит?

От этого тошнит исключительно вендузятников :D

Не понял вопроса.

всякие Венды

из под семё^W восмёрочки пишешь? :)

тего-ориентированные фс не нужны, ибо костыли. нужна реляционная субд. именно это то, что нужно. и делать её надо в ядре, вместо vfs.

Плюсую, по мне так всё очень прозрачно.

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

все кто делают make; make install любят */local.