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

Приходится использовать спецсофт.

Да,еще один юзкейс на лицо.. На что пал выбор? С тегами и полнотекстовым поиском по pdf-ам бы..

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

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

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

мое желание касается не интерфейса командной строки с точки зрения пользователя (они везде одинаковые, разве что у апта какие-то задвиги с разделением на apt-cache и apt-get). Оно касается именно формата описания пакетов и поддержания жини этого пакета. Особенно актуально для арчи, в которой установить пакет - самое меньшее дело, надо еще и удержать его в жизнеспособном состоянии в ходе роллинга.

Тут любая программа пытается стать операционной системой - то есть вполне возможен случай когда ОС внутри ОС внутри ОС

А это следствие того, что их создателей мало в детстве ремнем пороли.

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

Теги замечательно работают для поиска, а что если мне неизвестно какие фотки с отпуска я ищу? Сейчас у меня есть:

Фотки/Отпуск 2012/Париж/Башня/

назначь альбому тег Фотки-Отпуск2012-Париж-Башня

Мне сложно аргументы предоставить на сферического воображаемого ...

М'окау. Представьте ваши аргументы. Мои аргументы были простые - явапрограммисты ( и теми более школьники-птушники) существуют в специфических условиях. Они никогда не были инженерами-админами -техниками глубже «нажать 2.5 кнопки».

И им непонятно почему путь /home/vasya/xxx в стописот раз лучше c:\ауаацуац ца цпацк п\ па цку\Мои Документы\ (или как там оно в венде), почему cp лучше «моя супер крутая копировальная прога» (ведь это так проще запомнить1111), или аналогичных тегов для всего.

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

с тегами это делается в пару кликов

а чтобы тэги там появились, нужно для каждой чертовой фоточки из тысячи (или сколько там сейчас помещается на флешку?) нужно эти тэги приписать. Короче, картина маслом: приходишь вечером усталый домой с полной флешкой фоток, и... общаешься с женой? нежишься в ванной? гуляешь собаку? Ничерта подобного, до двух ночи сидишь и расставляешь тэги! Только хардкор, только наноинновации!

На что пал выбор?

пока использовал mendeley но на практике он оказался зондом вроде айтунца - хрен кому постороннему инфу сольешь. Так что в поиске.

С тегами и полнотекстовым поиском по pdf-ам бы..

А вот невозможность централизованного поиска - еще один недостаток подобных каталогизаторов. По pdfкам ищешь отдельно, по фс отдельно, по odt тоже отдельно и тд. Даже если веб-страничку сохранить и то через пару лет хрен найдешь.

Ага, только вот эти теги все-равно (imo) имеют вторичную природу по отношению к дереву директорий и менам файлов, т.к. задача «покажи мне что творится с фотографиями по отпуску» более естественна и распространена, чем «выбери мне те фотографии, где маня есть, васи нет, дело было в прошлом году в деревне маниловке» и подобные вариации. А если это надо - импользуйте менеджер фотографий, итого: 1. Иерархия директорий и имена файлов как универсальный инструмент
2. Фото-менеджеры для фотографий
3. Медиа-плееры для аудио и видео коллекций
4. ? для набора статей и документов

Кстати, а не занимается ли непомук и комплекс кде-софта тем, что плавно стирает эти грани? Только вот иерархия каталогов по-прежнему первична и универсальна.

Не хватает что-то типа, казалось бы, UNIX-way (из-за echo, cat, открытый сокет - файл, доступный пользователю отовсюду, включая bash):

Так в bash же есть /dev/tcp, на который башем же получается дескриптор и который можно читать/писать всеми вашими echo, cat и т.д. Сделано, наверно, ради юниксвея. Хотя я бы предпочёл встраивание echo/cat/whatever в сам баш для более прозрачной работы с тем же /dev/tcp, а заодно лёгкую переработку языка шелла с добавлением типов (серьёзно, сейчас же не восьмидесятые).

У меня - постоянно. Начиная с порядка пары тысяч научных статей в pdf задача сортировки их в иерархию становится неразрешимой. Приходится использовать спецсофт.

А тут еще и добавляется задача контроля версий

Проблема в том что твои задачи довольно специфичны. И по факту решаются написанием IDE только «для ученого». Где будет то что ты описал, плюс интеграция с соотвествующими научными сервисами. Количество которых неплохо было бы тоже на порядок увеличить.

А пихать твои теги в файлуху - это фейл.

На оффтопике, кажется, адоб умеет поиск по pdf-кам из директории (рекурсивно). А по odt/pdf/html не подойдет ли стратегия «редактируемого мало, поиск не нужен» и «нередактируемое конвертируется в pdf на входе».

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

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

Во-вторых, покажи мне, как ты перезапустишь утилиту в середине конвеера.

В-третьих, даже простейшие утилиты сейчас огромны.

А вот невозможность централизованного поиска - еще один недостаток подобных каталогизаторов. По pdfкам ищешь отдельно, по фс отдельно, по odt тоже отдельно и тд. Даже если веб-страничку сохранить и то через пару лет хрен найдешь.

Тебе нужен не централизованный поиск вообще, а поиск по «научной информации» вне зависимости от источника.

Новая линза для ubuntu - со ссылками на платные статьи с ieee o_O

На деле теги должны сосуществовать с именами ибо полный пусть к файлу по сути есть «набор основных тегов с приоритетами».

плюсую

явапрограммисты. Они никогда не были инженерами-админами -техниками

Где вы таких видели?

И им непонятно почему путь /home/vasya/xxx в стописот раз лучше c:\ауаацуац ца цпацк п\ па цку\Мои Документы\ (или как там оно в венде), почему cp лучше «моя супер крутая копировальная прога» (ведь это так проще запомнить1111), или аналогичных тегов для всего.

По моему это понятно всем.

А вот невозможность централизованного поиска - еще один недостаток подобных каталогизаторов. По pdfкам ищешь отдельно, по фс отдельно, по odt тоже отдельно и тд. Даже если веб-страничку сохранить и то через пару лет хрен найдешь.

spotlight что ли?

Ты только расписался в незнании /proc. В линуксе таки все - файл.

Простите, мне кажется у Вас несколько опечаток. Правильно было бы бы так:

«Ты только расписался в незнании. /proc в линуксе таки - фэйл.»

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

Это разные парадингмы, да. Точно так же и библиотеки нельзя заменить демонами, без костылей.

Во-вторых, покажи мне, как ты перезапустишь утилиту в середине конвеера.

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

В-третьих, даже простейшие утилиты сейчас огромны.

Время такое :D

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

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

И им непонятно почему путь /home/vasya/xxx в стописот раз лучше c:\ауаацуац ца цпацк п\ па цку\Мои Документы\

Этот же путь мышкой выглядит так: «Пуск->Мой компьютер->Мои Документы». Если все делаешь мышкой - вроде ничем не хуже /home/vasya/xxx. Вместо cp можно юзать кнопку «скопировать» в то талкоммандере. Т.е. я-то юзаю cp, но один хороший человек (красный диплом мехмата, научная степень, карьера от кодера до CTO) кодит на венде под дотнетом, жмякает кнопочки, и получается это у него в разы лучше, чем у всего соседнего коллектива «тру-юниксоидов» вместе взятых.

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

Ты всерьёз считаешь, что bash/posix sh лучше мощношелла? При том, что на нём практически невозможно прямо писать (каждая утилита может выдать мусор, НИКТО не проверяет их тупо потому, что на шелле это абсолютный мазохизм).

Кстати, да. Добавлю bash в список.

В OpenGL всё в одном файле, да. Насчёт неиспользуемых параметров — в winapi оно есть, а в libGL и libclang с этим успешно борются. В libclang можно передавать опции так же, как они передаются в командной строке для gcc и clang: некоторые методы просто принимают массив строк.

В libGL ещё интереснее: там замена некоторых параметров на NULL может кардинально изменить поведение функции: функция, появившаяся ещё в OpenGL 1.4 и не рассчитанная на передачу NULL, может обеспечить новую фичу из OpenGL 3.3, если в неё всё-таки передан NULL (а перед этим с помощью парочки вызовов из OpenGL 3.0 проинициализирован и забинден, скажем, буфер глубины).

proc в линуксе таки - фэйл

Расскажи мне, отче, а как тогда узнавать всю информацию о процессе, статах ядра и прочих вещах в той же фре или (обоже) оффтопике?

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

всю информацию о процессе ... (обоже) оффтопике?

Process Explorer :)

Скрипто-угодно _всю_ инфу не получить никак. Есть хаки типа вот такого: http://www.codeproject.com/Articles/25647/Read-Environment-Strings-of-Remote-... Еще можно заюзать черную дотнетную магию, но там совсем туши свет

если мне неизвестно какие фотки с отпуска я ищу?

Ты, наверное, имеешь в виду «не знаю, по какому тэгу искать»?

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

Что касается вывода существующих тегов: это можно сделать в более удобной форме, чем древовидная иерархия.

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

пытается, но тормозит как черте что. но есть и рабочие альтернативы.
вообщем, я согласен на фс + поисковик

Окей.

Ага, давайте для решения элементарных задач нагородим сотни ненужностей

Ещё вопрос, что большая ненужность. Ты так защищаешь иерархичные Фс просто потому, что привык к ним.

полный пусть к файлу по сути есть «набор основных тегов с приоритетами»

Нет, это не есть набор тегов конечного файла, это теги каталогов.

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

Тебе так кажется.

Могу переформулировать мысль: недостаток подхода «только теги» в том, что в действительности разные теги имеют разную ценность, более того, сами теги должны как минимум группироваться (места, персоналии, времена и т.д) (теги тегам? oh shi~!) для того, что бы не полчать помойку в случае, если не знаешь, какой тег тебе нужен, а просто хочешь ответить на вопрос «что творится у меня в документах/фотографиях/музыке»?

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

fhs последнее время куда-то не туда несет. зачем всякие /bin, /lib, /sbin пытаться заносить в /usr и то-же время выдергивать /run и т.д. из /var в корень

Тебе нужен не централизованный поиск вообще, а поиск по «научной информации» вне зависимости от источника.

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

то-же время выдергивать /run и т.д. из /var в корень

Могу предположить что папка /run может понадобиться когда /var еще не примонтирован. Но я не слышал о конкретном таком случае.

spotlight что ли?

шел бы ты отсюда, маковод.

сами теги должны как минимум группироваться (места, персоналии, времена и т.д) (теги тегам? oh shi~!)

Да блин, отстранись уже от иерархического шаблона.

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

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

а) Исчезает надобность в блужданиях по иерархии ФС

б) В иерархических ФС невозможно детализировать один файл/каталог сразу по нескольким свойствам его содержимого без дублирования файла/каталога или использования сторонних костылей. Т.е. если тебе нужно будет иметь один файл в каталогах «отпуск» и «Вася», тебе придётся его либо дублировать и там и тут, либо делать хардлинки, что не очень-то удобно, особенно принимая во внимание невозможность сделать хардлинк каталога.

А что мешает совместить оба варианта? Так, например, можно запустить индексирующий файловый сервер, а затем пойти в $home/tags/tag1/tag2/tag3/ и получить требуемое.

А что мешает совместить оба варианта?

Это можно, но зачем?

дерево же частный случай тэгов, ты сегодня такой кэп)

по дереву быстро искать, если специальным образом структурировать инфу. Быстрее, чем по непомерному списку тэгов. Разве что между тэгами ввести полноценные отношения («частное», «общее», «один к одному», «один ко многим», «использует», «используется», итп), чтобы потом можно было искать по паттерну...

дерево же частный случай тэгов, ты сегодня такой кэп)

Это вообще не теги. Ни разу. Даже близко.

по дереву быстро искать, если специальным образом структурировать инфу. Быстрее, чем по непомерному списку тэгов

Безосновательное утверждение.

Вот тебе два юзкейса: поиск без знания точного тега/запроса/имени каталога, анализ того, что имеет место в определенной области.

В случае ФС для поиска имеем «блуждание по ФС». Что фотография из отпуска, мне известно, затем, если у меня все сложено по городам мне надо выбрать город, затем событие, затем я вижу список (небольшой) файлов.

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

А что в случае с тэгами?

В случае поиска, мы вводим тег «отпуск» и видим.... либо 100500 дат (читай уникальных имен файлов), либо пару десятков тегов вида «Маша», «Париж», «Вечеринка в клубе», «Василий», «Лондон» - и все это в одной большой куче.

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

Итого - в случае ФС пути решения (хоть и не идеальны), но более оптимальны.

Расскажи мне, отче, а как тогда узнавать всю информацию о процессе, статах ядра и прочих вещах в той же фре или (обоже) оффтопике?

Нет, я лучше расскажу как правильно - через ioctl в /dev

«вся информация о процессе, статах ядра и прочих вещах» - это информация, которую каждой программе показывать даже вредно. Это огромная дыра в безопасности.

В Windows, кстати, не так уж и плохо эти вещи реализованы.

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

Конечно, ужасная. Только вот как показывает практика, на других ОС и без него жопа с безопасностью, а вот в случае администрирования и разработки - proc нереально удобен.

В Windows, кстати, не так уж и плохо эти вещи реализованы.

Как?

В случае ФС для поиска имеем «блуждание по ФС». Что фотография из отпуска, мне известно, затем, если у меня все сложено по городам мне надо выбрать город, затем событие, затем я вижу список (небольшой) файлов.

Итого: ты знаешь, что нужно фото из отпуска, знаешь, какой город нужно выбрать, знаешь, какое событие нужно искать.

Ну и в чём проблема?

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

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

Тут семантическая сеть тегов очень помогла бы.

Ящитаю, что баш - убог, а шелл со своими задачами справляется. Сам использую для интерактивной работы tcsh, для автоматизации sh.

Итого: ты знаешь, что нужно фото из отпуска, знаешь, какой город нужно выбрать, знаешь, какое событие нужно искать.

Прочитай еще раз - я не знаю, я выбираю. А иерархия позволяет выбирать из город из списка городов и событие из списка событий, а не по куче гулять.

Тут семантическая сеть тегов очень помогла бы.

Я тебе конкретные примеры, а ты мне «бы».

Нет у тебя аргументов, так что... ну ты понял :3

а вот в случае администрирования и разработки - proc нереально удобен.

Удобен, но цена за удобство - безопасность.

Как?

Через Component Object Model.