Двач.hk не отвечает.
Вы видите копию треда, сохраненную 28 октября в 03:07.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
ksnip20230906-211532.png4 Кб, 249x303
Почему в 2023м из-за того что по ошибке придумали хранить файлы в "папках" до сих пор нельзя чтобы о Linux: Firefox based 3353711 В конец треда | Веб
Почему в 2023м из-за того что по ошибке придумали хранить файлы в "папках" до сих пор нельзя чтобы одна и та же папка лежала в нескольких папках одновременно?
Чё за тупизна? Из-за этого ведь и приходися пакетный менеджер использовать чтобы он все пакеты топологически отсортированными держал у себя, но это костыль.
Где есть форум где сидят разрабы линукса чтобы им написать об этом и приступить к работе?
Windows 10: Chromium based 2 3353714
Tmsu Tagsistant TagFS Dantalian Supertag обычныессылки

Tmsu - не умеет группировать тэги, чтоб по запросу linux выдавало и arch и deb. Умеет какая-то другая но там были свои недостатки.
Linux: Firefox based 3 3353739
>>353714

>Теги вместо дирректорий


Ну и зачем? Теги это мусор.
Есть же классические дирректории что мешает двум и более предкам-папкам ссылаться на одного и того же потомка-папку?
Приведённая тобой система использует и дирректории и теги, йобаный пиздец. Папка это же уже сементический контекст который может ссылаться куда угодно, по крайней мере на уровне диска. Я после момента с дирректориями перестал читать хабр на тему Tagsistant. Почему папку просто не считать нодой графа и размещать данные в вершинах? Тут и аппаратно просто реализуется. Нахуя ещё и о ужас контекстный поиск вхуячивать в архитектуру файловой системы?
Linux: Firefox based 4 3353755
>>353714
И как ты собрался использовать теги программами?
Это типа только как база данных для человека чтоли? Пфффффф, это не серьёзно.

То что я предложил можно закостылить софтлинками, но костыли я презираю. Я имел ввиду просто чтобы все ссылки были жёсткими только и всего. В чём проблема так сделать? И программы и где угодно можно будет использовать. А ещё повторюсь что теги это мусор, они не работали вообще никогда, всем похуй на них. Хорошая вещь семантическая сеть, но это для веба больше подходит. В 2023м Теги какието ебать.
Linux: Firefox based 5 3353767
>>353714
Ещё Tagasistant использует sql ебать ебать, нет стоп. Это не фундаментальное решение. Нам нужна ромбическая топологически отсортированная структура папок представляющая собой отсортированный бесконтурный(без циклов) граф, и ВСЁ. Для того чтобы этой структурой мог пользоваться человек и программы. А всякие сложные контексты всегда можно создать папкой(нодой в данном случае). Все программы в своём загоне и файлы тоже раскиданы по нодам-контекстам, двух зайцев одним выстрелом. И пакетный менеджер уже не так нужен, так как программа сама знает на что ссылаться и чему пренадлежать.
Где найти обсуждения на эту тему или где продуктивнее всего эту тему поднять?
Windows 8: Firefox based 6 3353878
>>353711 (OP)

>Почему в 2023м из-за того что по ошибке придумали хранить файлы в "папках" до сих пор нельзя чтобы одна и та же папка лежала в нескольких папках одновременно?


Мультипользовательский режим и права. Ты ведь знаешь, что директория - это тоже файл? Всё итак лежит в одном файле - все файлы. Но разнесение в дерево нужно для решения проблемы доступа к файлу или файлам, и изменения файлов во время работы с ними.
/thread
Windows 7: Firefox based 7 3353879
>>353711 (OP)

> Linux: Firefox based


> в симлинки не смог

Windows 10: New Opera 8 3353966
>>353711 (OP)
линки на файлы и папки есть даже в винде, не говоря о лине.
Linux: Firefox based 9 3354045
>>353711 (OP)
Ты увидел лишь вершину айсберга - древовидную иерархию каталогов, но проглядел истинную проблему: все мейнстримовые ФС в 2023 всё ещё блочные. Но в 99 % случаев тебе не нужен блочный доступ. Ты считываешь GiantBoobs-67.jpg или ОчтётПетровичаб2009.doc разом, как целый объект, блочный адресный доступ нужен только для узкоспециализированного софта типа БД. Мы тащим блочное легаси, превозмогаем боль в сетевых и распределённых фс, пытаясь имитировать блоки и там.
В объектной фс ты не связан по рукам и ногам иерархией каталогов, ты без всяких костылей можешь поверх неё реализовать и графовую структуру, и структуру по тэгам/метаданным. Осталось лишь заставить корпоратов смасштабировать их до домашнего железа.
Windows 10: Chromium based 10 3354092
>>354045
Есть прототипы объектных ФС?
Linux: Firefox based 11 3354119
>>353878

>Мультипользовательский режим и права.


Абсолютно нет, потому что в бесконтурном графе права доступа реализуются ещё легче, у каждого пользователя своя подструктура общей структуры, ведь мы можем делать сколько угодно копий одной и той же папки, не размножая файлы в ней, просто для каждого пользователя она будет иметь разный набор из этой папки понимаешь? Каждый сидит в своём загончике, у которого нету просто адресного пространства для других загончиков, ведь "папка" это файл с ссылками на файлы и другие ссылки, транслирующиеся в номера на линейном массиве диска с доступом за О(1). У тебя права доступа уже считай интегрированы в структуру, просто каждый пользователь имеет свою точку входа.
Linux: Firefox based 12 3354123
>>354045
Возможно нужно смотреть ещё дальше, я обдумывал это. А в каком месте блочные файловые системы "блочные"? То что файлы раскиданы по папкам или что? Я так и не понял.
Но если смотреть ещё дальше то для удовлетворения сетевой распределённости система вообще должна быть в виде семантической сети/гиперсети(гиперграф - файловая система содержащая файловые системы или структуру файловых систем).
Я так понял в объектной сети всё хранится на линейном массиве, а структура контекстов хранится где-то в другом месте, или в нём же но по ключевому стандартному адресу?
Чем плохи блоки и опиши пожалуйста что могут объекты на иллюстративном примере чего не могут блочные.
Linux: Firefox based 13 3354132
>>354119
Да собственно это я и имею ввиду. Топологически отсортированный бесконтурный граф с нескольким корневыми каталогами для каждого пользователя. Таким образом это ориентированная сеть у которой есть множество входов и выходов в виде файлов или пустых папок.
Linux: Firefox based 14 3354137
>>353879
>>353966
Это костыли. Хоть и рабочие. Программы могут обходить их аналогично папкам. Но нужно всякий раз учитывать какая это ссылка, что геморно как для пользователя, управляющего хранением файлов так и для написания программ.
Linux: Firefox based 15 3354138
>>353711 (OP)
inb4 что в бумажная папка не может быть вложена в несколько папок...
Android: Mobile Safari 16 3354146
>>353711 (OP)
Монтирование для кого придумали?
Linux: Firefox based 17 3354164
>>354137
Да а ещё мягкие ссылки не защищены от ЦИКЛИЧНОСТИ.
Ты можешь в папке создать ссылку на предка и пиздец при попытке обхода. Создашь гденибудь цикл и ебись потом. СИстема должна проверять отсутствие циклов.
Так что шахимат симлинки и мягкие ссылки НЕ ВЫХОД из ситуации.
Linux: Firefox based 18 3354167
>>354146
Что монтирование то блядь? Куда нахуй? Вытащи хуй изо рта блядь когда людям пишешь. И пойми суть вопроса прежде чем высираться случайными предложениями.
Linux: Firefox based 19 3356309
>>354045
Поясни пожалуйста что такое "блочная" ФС и как выглядит "неблочная". В чём проявляется блочность. У нас в любой файловой системе есть терминальная сущность(неописываемая ФС) это контент. Какая ещё может быть философия хранения данных кроме как ни по папкам(контекстам)?
Linux: Firefox based 20 3356311
>>354045

>Ты считываешь GiantBoobs-67.jpg или ОчтётПетровичаб2009.doc разом



Как ты ещё собрался их считывать? Контент это терминальная сущность. Разве нет?

>В объектной фс ты не связан по рукам и ногам иерархией каталогов, ты без всяких костылей можешь поверх неё реализовать и графовую структуру, и структуру по тэгам/метаданным. Осталось лишь заставить корпоратов смасштабировать их до домашнего железа.



Мы и так не связаны ничем, данные на диске разбросаны хаотично и только ссылки придают им порядок. В чём проблема сделать ссылки произвольнее для ромбической структуры и как это помешает реализовать сетевое хранение?
Android: Mobile Safari 21 3356359
>>353711 (OP)
Спермоклоун ебаный.
Даже в твоей прошивке для игор есть симлинки
Windows 8: Firefox based 22 3356368
>>356309
Парень переиграл в сетевые хранилища и предлагает тебе ФС, где нет дерева, а каждый файл, папка (файл), устройство (файл) представлено guid\huid\uid\cid\nid\id и гига-файл с метой в ОЗУ, или свопе носителя, или втором файловом пространстве носителя с отдельной метрикой (или в единой), который пишет все эти файлы и читает их и помнит расположение всех файлов.
В точки зрения домашней системы - это стремно, у нас же не гигантские цоды, где важна выборка и можно держать в памяти терабайт сжатых мета-указателей на файлы, которые РАЗНЕСЕНЫ по куче физических носителей.
Для домашних пользователей нужен параллелизм - у нас уже в носителях стоят арм-ядра, нужно увеличивать их количество и в ФС нужны кучи файловых деревьев с защитой от коллизий. Можно еще учесть, что и в этих армах докидывают ядра NPU, вот нам и нужны сотни тысяч VPU, чтобы микроопить и параллелить процессы, прям как в видяхах.
А еще я шиз и я не пью табы уже джва дня...
Linux: Firefox based 23 3356460
>>356359
Слышь мудила сафаривая, виндоугодная, любящая срать односложными предложениями, с синдромом аспергера наверное, забудь о моих тредах совсем, как после травмы головы, после тебя ещё у других пропадает почемуто желание писать в моих тредах, ты грязь этого раздела.
Linux: Firefox based 24 3356467
>>356368
Спосибо за твоё разъяснение. Я так и почувствовал его недосказанность, явно не намёк на вариативность решения, а скорее наоборот.
Ну да для домашнего компа это хуйня полная как по менеджменту так и по надёжности etc оверхед по тому что не надо и недолив по тому что надо.
Архитектурно нет никаких препятствий запилить в линуксе то что я описал в этом треде, разве что придётся подправить некоторые программы, которые на ромбах могут работать неадекватно. А так большинство алгоритмов с файлами естественным образом "учитывают" ромбичность, вернее инвариантны для дерева и бесконтурного графа.
Android: Mobile Safari 25 3356486
>>356467
Изучи уже саму суть фс, мусорных и иерархичных. Ты с нуля решил начать с конца, и лезешь в гибридинг. Еще раз - все, что на носителе есть - это файл. И как ты выстраиваешь дальше структуру - так и будет называться такой метод компоновки и работы.
Имхо.
Linux: Firefox based 26 3356663
>>356486
Опять ты.

>Изучи уже саму суть фс, мусорных и иерархичных.


Я не увидел возражений посуществу предложенного мной, поэтому не замотивирован. Да и что там изучать? Массив данных с внутренними ссылками, где пустое место это часть массива на которые нету ссылок.

>Ты с нуля решил начать с конца, и лезешь в гибридинг.


Это не является минусом вообще говоря, многие решения являются реализацией взгляда с другой стороны.

>Еще раз - все, что на носителе есть - это файл.


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

Так же в мою пользу говорит тот факт что в ОСах до сих пор поумолчанию в /home лежат папки Картинки Видео Документы Музыка Загрузки и прочая не нужная дичь, может это тоже указывает на некоторую закостенелость. Может и файловую систему не перестраивают из-за недальновидности просто.
Серьёзно кто может пользоваться папками Видео и Документы в 2023м, не хватает ещё папки мп3, лол. Каталогизация по формату файла это архитупость.
Android: Mobile Safari 27 3356671
>>353711 (OP)

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


Ты только что ярлык
Linux: Firefox based 28 3356680
>>356671
Это полумера, потому что ярлык всётаки не жёсткая ссылка и их приходится различать и держать в памяти что есть что при удалении, и ярлыки можно зациклить, чего не должно быть категорически.
Linux: Firefox based 29 3356685
>>356680
Добавлю что на высоких контекстах можно дополнительно пользоваться и ярлыками с зацикливанием и прочим, допуская что существуют такие контексты, например, оба из которых являются вложением друг друга, но нужно не забывать что папки находятся на железе и учитывать работу программ с папками. А для личного пользования можно городить всё что душе угодно.
Linux: Firefox based 30 3356700
>>356671

>Google Android: Mobile Safari



Как ты заебал, когда тебя уже поезд нахуй в наушниках переедет
Android: Mobile Safari 31 3358756
>>353711 (OP)
Симлинки
Linux: Firefox based 32 3359203
>>358756
Подохни от рака, мразь говноедская.
Linux: Неизвестно 33 3359211
>>359203
Лол, ты так с односложного рвешься, что он уже лопается. Предложи еще раз его забанить, может реально его придавят тапком на денек.
sage Windows 10: Firefox based 34 3359212
— Доктор, вот у меня почему‑то раны вокруг рта…
— М‑м, кажется, Вы едите с ножа, не пользуетесь вилкой и ложкой.
— Да? Да, это так. Но ложкой мне неудобно.
— Тогда вот Вам йод.
Android: Mobile Safari 35 3359258
>>359203
Весна уже прошла, откуда обострение?
Windows 7: Firefox based 36 3359829
>>353711 (OP)
помню писал диплом как раз на эту тему. под виндой такого не бло, под прыщами что то было.
Windows XP: Firefox based 37 3360319
>>354164

> ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ


> сложная структура позволяет делать ссылки


> НЕ ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ


Ну ты выбери.
Linux: Firefox based 38 3361995
>>360319
Чел там нет никакого противоречия, а вполне конкретная реализацая структуры ссылок в виде бесконтурного графа, который топологически отсортирован при отображении в браузере файлов.

>> ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ


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

>> НЕ ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ


Она сложна ровно на столько на сколько нужно не включает в себя циклы, потому что может и существуют циклические вложения контекстов, но я такое пока не представляю, а во вторых структура должна поддерживать обход программами по нодам(папкам), и если запиливать поддержку циклов тогда ещё много чего можно понапридумывать, непонятно зачем.

>> сложная структура позволяет делать ссылки


Ссылки в любом случае есть на низком уровне.
То что предлагает анон с мягкими ссылками я уже писал не фундаментально и будет приводить к глюкам. В случае бесконтурного графа глюков не будет совсем. Усложнится правда интерфейс, просто вместо выбора жесткой ссылки и мягкой все будут жёсткими и нужно будет указывать при копировании файла, размножить его экземпляр или же просто сделать на него "ссылку" но в другой папке или в этой же.
Windows XP: Firefox based 39 3362169
>>361995
Там должно было быть про циклы, но уже не важно.

Ты, как и многие, путаешь связи между объектами, использующие разные признаки, в том числе и связанные с техническим устройством системы, и смысловую иерархию, в которую они выстраиваются (в другом измерении). Первое не предусматривает и не задаёт второго.

Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях. Компьютер не может тебе помешать поместить свои документы в каталог «Барнаул, Алтайский край». С другой стороны, даже у владельцев файлопомоек в голове появляется некая иерархия взаимосвязей, позволяющая находить, где что лежит.

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

Кроме того, представлений файлов на практике тоже больше одного. Можно не помнить, на каком диске лежит фильм, если находишь его в общем списке торрент-клиента. Можно добавить все места хранения фото в менеджер картинок (или музыку — в проигрыватель) и пользоваться их проекциями, не думая о физическом расположении или формате.

В общем, сущности могут располагаться в файловой системе, в базе данных, на листочке в виде подписанных овальчиков. А вот иерархия сложнее, расположена в голове и только проецируется куда-то.
Android: Mobile Safari 40 3362899
>>356368

> и гига-файл с метой в ОЗУ, или свопе носителя, или втором файловом пространстве носителя с отдельной метрикой (или в единой), который пишет все эти файлы и читает их и помнит расположение всех файлов.


Так в NTFS ведь есть такой файл, на его использовании основана работа Everything
Windows 10: Яндекс браузер 41 3364042
>>353711 (OP)
орнул с зумера
Android: Mobile Safari 42 3364259
Нинужно. Всё равно что к молотку железный хуй приделать просто так.

Это будет полезно в 1 случае на 1000, зато меня будет бесить что у в куче "папок" внутри одни и те же подпапки.
Android: Mobile Safari 43 3364642
>>361995

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


Я профан, но уверен, что ваша дрочь никому не нужна. Будущее за контекстным поиском, когда все файлы лежат в одной помойке, а поиск осуществляется по содержимому.
С фотографиями и изображениями это уже работает отлично, а для текстовых файлов решения активно разрабатываются.
Windows XP: Firefox based 44 3364662
>>364642
Такая точка зрения встречается повсеместно, но это не делает её менее глупой. Основана она на стереотипных малограмотных рассуждениях журналистов и обещаниях пресс-релизов (откуда постоянно возникает будущее время). Переформулировать её очень просто: «Проблему решать мы не будем, мы подождём, пока её решит кто-то за нас».

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

Даже профессионального использования не надо. Не далее как вчера обычный пользователь смартфона меня спрашивал, как найти очень интересный ролик, который знакомые пересылали в Whatsapp неизвестное количество месяцев назад, а говорилось там о… Как, как? Да никак.
Android: Mobile Safari 45 3364731
>>364662

> Переформулировать её очень просто: «Проблему решать мы не будем, мы подождём, пока её решит кто-то за нас».


Так у тебя и проблема то какая-то смешная. Та что в оп-посте решена лет 50 назад, а та что в моем посте решается в данную секунду лучшими умами человечества.
Но ты правильно говоришь, я не буду решать проблему блять поиска файлов по контенту. Я тебе больше скажу - ты тоже не будешь. Ждём пока решат за нас.

> Допустим, у нас есть куча сканов чертежей. Как «отлично работающий» менеджер изображений, умеющий «найти лица на фото», нам поможет разобраться с этой «помойкой»?


Довольно просто. Двумерный чертеж от изображения мало чем отличается. Я почти уверен, что уже сейчас можно получить описание детали, имея фотографию чертежа.
На крайний случай у чертежей должна быть табличка с метадатой в уголке, которая тоже должна участвовать в поиске.
Windows XP: Firefox based 46 3364755
>>364731
Нет, ты подменил сложную работу по организации иерархии, которая происходит в голове, каким-то максимально размытым «поиском файлов по контенту», а затем приписал это мне. Технические инструменты тут вторичны, и должны соответствовать задаче.

Твоя вера в то, что сейчас «лучшие умы человечества» что-то «решают» основывается всего лишь на медийном шлаке. Иначе говоря, ты повторяешь чужие глупости с умным видом.
Android: Mobile Safari 47 3364759
>>364755

> Нет, ты подменил сложную работу по организации иерархии, которая происходит в голове, каким-то максимально размытым «поиском файлов по контенту»


Нет, вполне конкретным "поиском по контенту", который уже хуй знает сколько лет на рынке и зарекомендовал себя как ультимативное решение.
Со всех моих устройств все изображения и видео стекаются в одну большую помойку, в которой можно свободно ориентироваться с помощью поисковой строки.
Поиск по контенту текстовых файлов существует ещё дольше. Например популярные поисковые движки этим активно пользуются.
Видео, изображение и текст покрывают 99% потребностей, для остального процента появление решения - вопрос времени.

> Твоя вера в то, что сейчас «лучшие умы человечества» что-то «решают» основывается всего лишь на медийном шлаке.


"Лучшим умам человечества" нужно что-то кушать. Вот и решают чтобы кушать было что. Это называется не вера, а логика.
Windows XP: Firefox based 48 3364760
>>364731
С чертежами твой мозг наконец-то начал работать. Да, мы можем распознать основную надпись (если бумажная копия в приличном виде). Появилось у нас N таких наборов данных. А выше уровнем информация где? Как из этих деталей что-то собрать? Какой чертёж относится к машине, какой — к стене цеха, в котором её собирают, какой — к забору вокруг завода?

Ты сделал примитивный шажочек со своей «табличкой с метадатой в уголке», а уже стоишь наполеоном.
Windows XP: Firefox based 49 3364761
>>364759

> свободно ориентироваться


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

> а мне больше и не надо


Что и требовалось доказать. «Пусть кто-то это делает за меня».
Android: Mobile Safari 50 3364765
>>364760

> Появилось у нас N таких наборов данных. А выше уровнем информация где? Как из этих деталей что-то собрать? Какой чертёж относится к машине, какой — к стене цеха, в котором её собирают, какой — к забору вокруг завода?


Запрос: "чертеж ваз 2109"
Ответ: все чертежи ваз 2109 в системе
Запрос: "чертеж стена"
Ответ: все чертежи стен
Запрос: "забор"
Ответ: чертежи заборов
Что ты хочешь то?

>>364761

> Какое «свободно», когда ты можешь пользоваться только тем, что дали?


Ты дурак? Ну сейчас у тебя есть иерархическая система, ты чувствуешь себя свободным?
Да и вообще, свобода в твоем понимании вторична. Я не буду пользоваться отверткой вместо шуруповерта только потому что отверткой можно на барабане играть. Главное - получить нужный результат как можно быстрее и как можно качественнее.

> Что и требовалось доказать. «Пусть кто-то это делает за меня».


Абстрактный гринтекст абстрактно подтверждает абстрактное суждение. Очень удобно.
Android: Mobile Safari 51 3364767
>>364760
>>364761
У тебя какое-то острое неприятие технологий. Тебя в детстве растлили тостером?

Зачем мне знать, где в системе находится отчёт за прошлые года по корректному продукту если я могу запросить "морковь отчёт 2018" и получить релевантные результаты?
Android: Mobile Safari 52 3364768
>>364767

> корректному


Конкретному*
быстрофикс
Windows XP: Firefox based 53 3364773
>>364765

>Запрос: "чертеж ваз 2109"


>Ответ: все чертежи ваз 2109 в системе


>Запрос: "чертеж стена"


>Ответ: все чертежи стен


>Запрос: "забор"


>Ответ: чертежи заборов


Ясно, сиди пускай слюни на фоточки и не подходи никогда к станкам и документации.

Как минимум можно было понять, что на чертеже детали автомобиля может вообще не встречаться название автомобиля (в том числе потому, что она была спроектирована ещё до его создания).
Android: Mobile Safari 54 3364777
>>364773

> Как минимум можно было понять, что на чертеже детали автомобиля может вообще не встречаться название автомобиля (в том числе потому, что она была спроектирована ещё до его создания).


Ну и ладно, пускай не встречается. Зато в документации автомобиля встречается название всех деталей, из которых он состоит, поиск все равно выдаст верный результат. Это буквально удобнее и быстрее. Тебе придется этим пользоваться.
Linux: Firefox based 55 3365376
>>364259
Этот момент я продумал и файловый менеджер должен состоять из папочного графического браузера, чтобы можно было человеку обойти папки по маршруту и окно с файлами.

>>364642
Да ты профан. Потому что контекстная зависимость очень существенна в программах, тебе может понадобиться один и тот же ресурс разными программами и разные ресурсы могут включаться в одну и ту же программу, в дерево ты никак этот зоопарк не засунешь, именно поэтому большинство пакетов имеют настолько ЕБАНУТЕЙШУЮ контекстную зависимость, требуют makefilы с компоновщиком, также пакетный менеджер - костыль по этой же причине и не нужен. Даже в Си++ есть поддержка ромбического наследования классов потому что ты никогда не знаешь что тебе понадобится и с какого "этажа", лерево это ущербная структура говна, из-за которой нету утилитарного порядка для технического уровня хотябы.
Android: Mobile Safari 56 3365414
>>365376
Файловая система не меняется, меняется интерфейс взаимодействия пользователя с ней.
Linux: Firefox based 57 3365427
>>365414
Ну так я об этом и говорю, что на уровне файловой системы ничего не поменяется если сделать бесконтурный граф вместо дерева, и браузер красивый к нему, где атлас из нод с названиями и окошко с содержимым ноды.
Linux: Firefox based 58 3366412
>>364765
Все сущности в мире хорошо укладываются в иерархию (не древовидную) контекстов, которые могут пересекаться и перекрываться произвольно и существуют они в любом случае умозрительно, категоризация узлов машины чисто ситуативная интерпретация значимости и другим может быть задана в совершенно другом виде ну это в теории. Теперь что касается самих программ то там всё однозначно и железно, программы ссылаются на другие в произвольном порядке и поэтому папки так же должны естественно поддерживать и иллюстрировать эту произвольность, и в программах ты не задашь семантический поиск, потому что программа должна чётко находиться в каталоге и других вариантов нет. Поэтому проблема фундаментальна и попытки сослаться на супертехнологии по сути уход от этой проблемы. Компьютер в любом случае утилитарный(всмысле не терминальный) инструмент и надо всегда это учитывать при использовании а не то что компьютер автоматизирует всё на свете и даже не надо будет жить и умирать.
Android: Mobile Safari 59 3366423
>>366412
Не виляй жопой. Изначально я ответил на пост.
>>361995

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


И в разговоре о пользовательских файлах очевидны преимущества каталогизации и поиска по контексту.
Linux: Firefox based 60 3366429
>>366423

>Не виляй жопой. Изначально я ответил на пост.


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

>И в разговоре о пользовательских файлах очевидны преимущества каталогизации и поиска по контексту.


Неочевидны. У тебя не тысячи триллионов папок на компе создаваемых автоматически. Контекстный поиск подразумевает и полностью автоматизированное контекстное управление создание значимых папок, опционально удаление незначимых, ты городишь хуйню на ровном месте изначально невыполнимую за разумные сроки. Хранение файлов НЕЛЬЗЯ автоматизировать ВООБЩЕ НИКАК это чисто умозрительная хрень, это всёравно что пытатться автоматизировать жизнь, тоесть никогда.
Linux: Firefox based 61 3366432
>>366429
Для сетевого хранилища гдето в говнооблаке ещё можно сделать подобное, но вопервых частично уже такое есть и я бы тогда поднял вопрос именно об этом, но экономия пространства не основная проблема, основная это связность лучше 1 большой файл чем триллион маленьких в дереве папок например. Путь к файлу это тоже информация, и лучше чтобы она была удобной, а не хуйпоймикакая базаданных.
Linux: Firefox based 62 3366433
>>366432
>>366423
Проебался с номером но не суть.
Android: Mobile Safari 63 3366436
>>366429

> Ты предложил технологический оверхед...


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

> Хранение файлов НЕЛЬЗЯ автоматизировать ВООБЩЕ НИКАК это чисто умозрительная хрень, это всёравно что пытатться автоматизировать жизнь, тоесть никогда.


Уже.
>>366432
Ты не прав

Меня не ебет где файл лежит, если я могу в любой момент получить к нему быстрый доступ
Linux: Firefox based 64 3366456
>>366436

>Я предложил решение, позволяющее получить результат быстрее и удобнее чем папочки с ярлычками.


Нет.

>Уже.


Учёный изнасиловал журналиста опять.

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


Чел ты занимаешься абстрактным флеймом. Программам похуй на что похуй тебе, они работают с переменными а не с твоими хотелками. А организовать файлы на компе можно и вручную главное, чтобы файлменеджер был поинтерактивнее и пографонистее, что позволит раскидывать и искать файлы просто двигая тазом как ты хочешь, но видишь решение не в той плоскости совсем.
Android: Mobile Safari 65 3366470
>>366456

> Программам похуй на что похуй тебе, они работают с переменными а не с твоими хотелками.


Поконкретней можно пожалуйста? Ну вот существует программа в некоторой директории. Условный компас. В чем проблема по твоему мнению заключается?
Я топлю за то, чтобы когда в компасе нажимаешь кнопку "открыть файл" не приходилось вручную искать путь до файла в проводнике. То есть ты пишешь "чертеж вибратор длинный", выбираешь файл из подходящих под запрос и его открываешь.
Проводник в это время ищет по индексированным файлам и путь выбранного файла предоставляет компасу.
Компас же в свою очередь при создании нового файла кидает его куда-то в свою директорию или в документы (в общем то и не важно куда), и этот файл потом точно также можно будет найти.
Все остается как прежде, только теперь процесс поиска пути до нужного файла вместо пользователя выполняет проводник с помощью пиздатого поиска.
Теперь пальцем покажи мне блять где находится проблема с переменными. Пускай директории и пути станут внутрисистемным явлением, которые пользователь ни разу в жизни не увидит. В принципе к этому все и идет, если обернуться на смартфоны. Последний раз на телефоне искал файлы по файловой системе руками года три назад.
Android: Mobile Safari 66 3366474
>>366470
При чем добавлю, что гугл делает просто километровые шаги в эту сторону. Их облачный офис как и фотографии уже работают по такому принципу, а это я напоминаю текст, изображения, видео, таблицы и презентации. 99% потребностей мимокрока.
Android: Mobile Safari 67 3366485
>>366470
>>366474
Ну и конечно вводиться подобная система будет не одну пятилетку. Сначала облачный поиск по домашней папке пользователя, потом локальный поиск на мощном железе, самой первой директории полностью из проводника уберет эпл в свой мак оси и так далее.
Linux: Firefox based 68 3366488
>>366470

>Поконкретней можно пожалуйста? Ну вот существует программа в некоторой директории. Условный компас. В чем проблема по твоему мнению заключается?


>Я топлю за то, чтобы когда в компасе нажимаешь кнопку "открыть файл" не приходилось вручную искать путь до файла в проводнике. То есть ты пишешь "чертеж вибратор длинный", выбираешь файл из подходящих под запрос и его открываешь.


>Проводник в это время ищет по индексированным файлам и путь выбранного файла предоставляет компасу.


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


>Все остается как прежде, только теперь процесс поиска пути до нужного файла вместо пользователя выполняет проводник с помощью пиздатого поиска.


Программа просто его не находит, или находит запустив комп на орбиту.

Не важно какие файлы ты хранишь и сколько, они всёрвно должны быть сгруппированы как ни крути, иначе ты просто не спожешь освобождать пространство или доверишь это программе? А какие будут критерии удаления? Фотограффи 20 летней давности и архивы программа удалит за незначимостью твои действия? Схема размещения в любом случае должна быть сбалансированной как "сверху" со стороны человека, так и со стороны железа "снизу". То что ты предлагаешь не подходит
для системы с полным контролем, тоесть домашней пеки.
Уже есть готовая структура технически удовлетворяющая обоим подходам вот и всё.
Ты открываешь компас нажимаешь открыть файл,идёшь в папку "петухиназоне" там куча фотографий копипасты видос, ты выбираешь чертёж петуха. Если ты его закинул куда-то не туда, не в тот контекст, то земля тебе пухом. Все.
В твоём же случае поиск будет производиться из мешанины файлов наличие которых ты вообще не можешь быть уверен, чего ты не учёл.

>Теперь пальцем покажи мне блять где находится проблема с переменными.


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

>>366474
Гугл зарабатывает бабки, без которых их системы просто дорогой обогреватель. Это временные решения на отъебись а не на столетия.
Да изображения так можно искать, но он не свяжет в один контекст песню и фотографию чувака или чертеж петуха который он сделал. Да и вообще всё может пойти не так в любой момент из-за хуй пойми каких причин, нейросети нестабильная машина.
Linux: Firefox based 68 3366488
>>366470

>Поконкретней можно пожалуйста? Ну вот существует программа в некоторой директории. Условный компас. В чем проблема по твоему мнению заключается?


>Я топлю за то, чтобы когда в компасе нажимаешь кнопку "открыть файл" не приходилось вручную искать путь до файла в проводнике. То есть ты пишешь "чертеж вибратор длинный", выбираешь файл из подходящих под запрос и его открываешь.


>Проводник в это время ищет по индексированным файлам и путь выбранного файла предоставляет компасу.


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


>Все остается как прежде, только теперь процесс поиска пути до нужного файла вместо пользователя выполняет проводник с помощью пиздатого поиска.


Программа просто его не находит, или находит запустив комп на орбиту.

Не важно какие файлы ты хранишь и сколько, они всёрвно должны быть сгруппированы как ни крути, иначе ты просто не спожешь освобождать пространство или доверишь это программе? А какие будут критерии удаления? Фотограффи 20 летней давности и архивы программа удалит за незначимостью твои действия? Схема размещения в любом случае должна быть сбалансированной как "сверху" со стороны человека, так и со стороны железа "снизу". То что ты предлагаешь не подходит
для системы с полным контролем, тоесть домашней пеки.
Уже есть готовая структура технически удовлетворяющая обоим подходам вот и всё.
Ты открываешь компас нажимаешь открыть файл,идёшь в папку "петухиназоне" там куча фотографий копипасты видос, ты выбираешь чертёж петуха. Если ты его закинул куда-то не туда, не в тот контекст, то земля тебе пухом. Все.
В твоём же случае поиск будет производиться из мешанины файлов наличие которых ты вообще не можешь быть уверен, чего ты не учёл.

>Теперь пальцем покажи мне блять где находится проблема с переменными.


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

>>366474
Гугл зарабатывает бабки, без которых их системы просто дорогой обогреватель. Это временные решения на отъебись а не на столетия.
Да изображения так можно искать, но он не свяжет в один контекст песню и фотографию чувака или чертеж петуха который он сделал. Да и вообще всё может пойти не так в любой момент из-за хуй пойми каких причин, нейросети нестабильная машина.
Linux: Firefox based 69 3366490
>>366485
Это будет ебейший оверхед по энергопотреблению для какойто бытовой хуйни. Давайте ещё майнерскую сеть запустим для поиска файлов, а чё инновационно ёпта. Ты не забывай для чего нужна цифровая машина. Она не для этого пилилась вообще. То что она используется для удобства небольшой бонус.
Linux: Firefox based 70 3366491
>>366436
лол дегрод хочет магическое хранилище с функцией "найди то не знаю что там незнаю где вот прямо сейчас ты же компьютер в конце концов"
Android: Mobile Safari 71 3366494
>>366488

> Программа просто его не находит


Какая программа? Проводник? Сейчас же поиск работает, просто добавить туда контент.

> Не важно какие файлы ты хранишь и сколько, они всёрвно должны быть сгруппированы как ни крути, иначе ты просто не спожешь освобождать пространство или доверишь это программе?


> А какие будут критерии удаления? Фотограффи 20 летней давности и архивы программа удалит за незначимостью твои действия?


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

> Если ты его закинул куда-то не туда, не в тот контекст, то земля тебе пухом. Все.


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


У - Удобство.

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


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

> Это временные решения на отъебись а не на столетия.


Как и поисковые системы, расскажешь.
>>366490

> Это будет ебейший оверхед по энергопотреблению для какойто бытовой хуйни.


Ну да, ты же 4090 не покупаешь только потому что она электричества жрет слишком много.
Да и глядя на современные arm процы с копеечным энергопотреблением...
>>366488

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


Схуяли? Ты скозал?
>>366491

> лол дегрод хочет магическое хранилище с функцией "найди то не знаю что там незнаю где вот прямо сейчас ты же компьютер в конце концов"


Ну да, как в офисе от Гугла. Так и хочу. Это удобно.
Linux: Firefox based 72 3366497
>>366491
"найди то не знаю что там незнаю где вот прямо сейчас ты же компьютер будь человеком"
лолд
Android: Mobile Safari 73 3366504
>>366497
Ну да, в эту сторону и движутся технологии в 2023 году. Сегодня можно с компьютером разговаривать на человеческом языке и получать человеческий ответ человеческими звуками. В удивительное время мы живем.
Linux: Firefox based 74 3366508
>>366494

>добавить туда контент.


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

>Делаю запрос "большие файлы неиспользуемые больше трех лет" если очень нужно что-то удалить.


Ога и поошибке удаляешь лишнее то что не предвидел удалять.

>Твердый гигабайт сколько сейчас стоит? 5 рублей?


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

>У - Удобство.


Н-Надёжность.>Удобство.

>Да и охуеть, а ты уверен что существует файл в твоей директории?


Конечно уверен я же не долбаёб. Компьютер это инструмент всеголишь. Без человека он бесполезен.

>Как и поисковые системы, расскажешь.


Да с поиском говна уже плохо справляется. Поиск в 2023м ну такое. За семантическими сетями будущее.

>Ну да, ты же 4090 не покупаешь только потому что она электричества жрет слишком много.


>Да и глядя на современные arm процы с копеечным энергопотреблением...


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

>Схуяли? Ты скозал?


Я сделаю специально так чтобы не смогла. Вопросы?

>Ну да, как в офисе от Гугла. Так и хочу. Это удобно.


Не путай корпоративные практики с частными. Хотя если у тебя свой суперкомп то твоё дело.
Linux: Firefox based 74 3366508
>>366494

>добавить туда контент.


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

>Делаю запрос "большие файлы неиспользуемые больше трех лет" если очень нужно что-то удалить.


Ога и поошибке удаляешь лишнее то что не предвидел удалять.

>Твердый гигабайт сколько сейчас стоит? 5 рублей?


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

>У - Удобство.


Н-Надёжность.>Удобство.

>Да и охуеть, а ты уверен что существует файл в твоей директории?


Конечно уверен я же не долбаёб. Компьютер это инструмент всеголишь. Без человека он бесполезен.

>Как и поисковые системы, расскажешь.


Да с поиском говна уже плохо справляется. Поиск в 2023м ну такое. За семантическими сетями будущее.

>Ну да, ты же 4090 не покупаешь только потому что она электричества жрет слишком много.


>Да и глядя на современные arm процы с копеечным энергопотреблением...


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

>Схуяли? Ты скозал?


Я сделаю специально так чтобы не смогла. Вопросы?

>Ну да, как в офисе от Гугла. Так и хочу. Это удобно.


Не путай корпоративные практики с частными. Хотя если у тебя свой суперкомп то твоё дело.
Linux: Firefox based 75 3366512
>>366504
В удивительное в удивительное, ты как в том ролике советском, батарейки(полные чемоданы) от часов не забудь.
Android: Mobile Safari 76 3366515
>>366508

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


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

> Ога и поошибке удаляешь лишнее то что не предвидел удалять.


Ну и сделай запрос точнее, это мелочи и тонкости реализации.

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


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

> Н-Надёжность.>Удобство.


Пока что единственный довод против. Проблема надёжности крайне значительна. Даже интересно как ее решать будут.

> Конечно уверен я же не долбаёб. Компьютер это инструмент всеголишь. Без человека он бесполезен.


Ну значит и я уверен, что в помойке лежит нужный файл, я же не долбоёб.
Linux: Firefox based 77 3366534
>>366515

>В этом и смысл, меньше телодвижений для лучшего результата.


>Ну и сделай запрос точнее, это мелочи и тонкости реализации.


Ясно.

>Я не представляю насколько должен быть большой объем данных чтобы влиять на производительность. Сейчас винда ищет по миллионам индексированных файлов за секунду.



Влияет на поиск человеком если файлы раскиданы несбалансированно триллиардами в одной папкопомойке.

>Пока что единственный довод против. Проблема надёжности крайне значительна. Даже интересно как ее решать будут.


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

>Ну значит и я уверен, что в помойке лежит нужный файл, я же не долбоёб.


Ты не уверен что комп не долбаёб. А я уверен.
Android: Mobile Safari 78 3366585
>>366534

> >В этом и смысл, меньше телодвижений для лучшего результата.


> >Ну и сделай запрос точнее, это мелочи и тонкости реализации.


> Ясно.


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

> Влияет на поиск человеком


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

> файлы раскиданы несбалансированно триллиардами в одной папкопомойке.


Во-первых, с технической точки зрения компьютеру глубоко до пизды на количество файлов в директории.
Во-вторых, индексация была придумана хуй знает сколько лет назад, я даже не против если придётся докупить лишние 8-16-32 гб ОЗУ, чтобы держать в быстром доступе все пути до индексируемых файлов и их контекстное описание до кучи. Это копейки по сравнению с преимуществами.

> Да никак, забьют хуй как и всегда


Ты то точно знаешь, что забьют. Прибыль будут терять, но точно выпустят говно. Потому что идейные пидорасы, верно?
Windows XP: Firefox based 79 3366737
>>366504
Боже, настоящая жертва рекламы. Человек, который верит даже не в богов, а в обещания маркетологов.

То, что твои задачи решаются вводом нескольких слов в Google™, означает не то, что поисковик обладает волшебными качествами, а то, что твои задачи не выходят за рамки предлагаемых решений. Как только упрёшься в ограничения — поймёшь. Образно говоря, людям, которых устраивает радиоприёмник с двумя кнопками, в котором на первой играет Басков, а на второй — Круг, бесполезно объяснять, что можно самостоятельно искать и выбирать музыку, иметь собственный вкус. Сегодняшние популярные сервисы как раз построены на том, чтобы создать иллюзию неограниченных возможностей, предложив человеку тупой телевизор, в который можно втыкать.

Вот тебе для общего образования 600 страниц разборок по поводу муфт в системе, в которой были и схемы, и правила, и инструкции, и наказание за нарушения, и всё равно оказалось, что всё не так, и держалось на здравом смысле работников.
https://www.gov.uk/government/publications/the-nimrod-review
А ты предлагаешь просто тыкать в компьютер и не думая делать то, что он скажет. При этом давно обсуждается, например, что подготовленные пилоты, всего лишь автоматизировавшие некоторые действия, хуже понимают процесс полёта и хуже разбираются с ситуациями, когда что-то идёт не так.
Неизвестно 80 3366747
>>366737
Дай сам пдф, меня кикает.
Linux: Firefox based 81 3366750
>>366585

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


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

>продумывание иерархии


Она возникает почти естественным образом.

>прописывание адекватных названий файлов


Забиваю хуй либо оно уже прописано за меня.

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



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

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

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


Нет ему не до пизды.

>Во-вторых, индексация была придумана хуй знает сколько лет назад, я даже не против если придётся докупить лишние 8-16-32 гб ОЗУ, чтобы держать в быстром доступе все пути до индексируемых файлов и их контекстное описание до кучи. Это копейки по сравнению с преимуществами.



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

>Ты то точно знаешь, что забьют. Прибыль будут терять, но точно выпустят говно. Потому что идейные пидорасы, верно?


Не понял это твоё предложение.
Linux: Firefox based 81 3366750
>>366585

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


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

>продумывание иерархии


Она возникает почти естественным образом.

>прописывание адекватных названий файлов


Забиваю хуй либо оно уже прописано за меня.

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



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

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

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


Нет ему не до пизды.

>Во-вторых, индексация была придумана хуй знает сколько лет назад, я даже не против если придётся докупить лишние 8-16-32 гб ОЗУ, чтобы держать в быстром доступе все пути до индексируемых файлов и их контекстное описание до кучи. Это копейки по сравнению с преимуществами.



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

>Ты то точно знаешь, что забьют. Прибыль будут терять, но точно выпустят говно. Потому что идейные пидорасы, верно?


Не понял это твоё предложение.
Android: Mobile Safari 82 3366764
>>366750

> просто ограничивать себя


Очень просто.

> >продумывание иерархии


> Она возникает почти естественным образом.


> >прописывание адекватных названий файлов


> Забиваю хуй либо оно уже прописано за меня.


И как, удобно?

> Информации будет всегда больше чем возможности её обработать. Этой возможности всегда будет нехватать. Это вообще даже философская проблема уже.


Это ты сказал? Ты собрался всю информацию мира обрабатывать?

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


Да, проще, так еще и синхронизировать между устройствами так удобнее, но это к локальной системе отношения не имеет.

> диск своей машины испольховать только для самого нужного


В семантической сети, да. Русский поиск по директориям все ещё не нужен.

> Нет ему не до пизды.


Компьютеру до пизды, а вот софту, который пытается ими оперировать - нет.
Например, тот же everything показывает все файлы в одном списке и ничего, не зависает.

> Это опять же проблема доступа к своми файлам, если ты можешь их получить только через поиск то не похуй ли где они лежат на диске или в интернете? Если у тебя их триллионы картинок с сойжаками к примеру?


Я пытаюсь донести, что в принципе похуй где они лежат, если я их могу получить. Но мир не идеален и если интернет отвалится должен быть набор данных, доступных локально.
Linux: Firefox based 83 3366777
>>366764

>Очень просто.


>И как, удобно?


Ну да в совоём диске не потеряешься же.

>Это ты сказал? Ты собрался всю информацию мира обрабатывать?


Ну это так как ни крути. Про множество подмножеств что-нибудь слышал? Что оно больше самого множества, вот это аналогично. Так что проще всего если обрабатываться информация будет автоматически с помощью предпочтений человека. А тратить на это видеокарты нерационально.

>Да, проще, так еще и синхронизировать между устройствами так удобнее, но это к локальной системе отношения не имеет.


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

>Компьютеру до пизды, а вот софту, который пытается ими оперировать - нет.


>Например, тот же everything показывает все файлы в одном списке и ничего, не зависает.


Ок, хорошо если так.
Windows XP: Firefox based 84 3366983
>>366747
С чего бы это, обычная ссылка вроде. У Веб-архива с ней проблем нет:

http://web.archive.org/web/20230215000000*/https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/229037/1025.pdf
Windows 7: Firefox based 85 3370022
>>353711 (OP)
Но ведь существуют ссылки, с помощью которых нетрудно сделать так, чтобы одна и та же папка лежала в нескольких папках одновременно.
Windows 7: Firefox based 86 3371143
>>366585

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


В меню Пуск семерки примерно так и было сделано. На первой странице список часто используемых приложений, наводишь курсор на приложение - и справа появляется список последних документов с которыми ты работал через это приложение. У меня эта система довольно быстро формировала список под мою текущую рабочую задачу, и я практически никогда не шарил по дискам в поисках нужного файла, даже забыл что у меня где лежит...
Linux: Firefox based 87 3372821
>>371143
Ты ставишь неверные акценты если считаешь что комп может заменить тебя самого при юзании компа. Это концептуально неверно. Комп по крайней мере классический был и навсегда останется ИНСТРУМЕНТОМ помощником, и попытки сделать из него терминальную(в смысле не утилитарную) сущность заведомо провальная и мёртворождённая идея, комп всегда проекция человеческих идей, но не замена и не синтез их, это к слову к тому почему никогда не взлетят все эти метавселенный и иже с ними. То что тебе помогло меню лишь удачное стчение обстоятельств но такие надстройки можно делать бесконечно с около нулевым приростом удобства. Так что не нужно. Я как программист в рот ебал писать очередное по лишь бы бзерододик мог не думать над цветом дилдака и получил его в выдаче компа.
Linux: Firefox based 88 3372824
>>371143
Да ещё ты не учёл того что для этой "удобной выдачи" ты создаёшь лишнюю сущность в виде функции такой удобной выдачи, а сколько ещё таких критериев удобства можно насоздавать? Думать что будет ИИ делающий выбор за тебя так себе идея.

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


У меня не помойка на диске, а идеальный порядок, ну не совсем из-за ущербности древовидной структуры, что у меня и так всё находится само как нужно.
Linux: Firefox based 89 3383196
>>353711 (OP)
Ага, а для каждого файла общесистемной библиотеки мы храним по две тысячи путей до него. Ядро линукс занимает примерно 800 гб, а при установки каждого дополнительного пакета оно скейлится по экспоненте. Спасибо, не надо.
Linux: Firefox based 90 3383631
>>353711 (OP)

> по ошибке


Древовидная структура, простая и понятная иерархия.

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


Можно, даже больше, можно чтобы несколько версий файла хранились одновременно. Называется CoW файловая система. То что ты хочешь решается дедубликацией, файловая система автоматически заменяет одинаковые файлы на ссылки.

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


Причем тут пакетный менеджер нах

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


Мхех

Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.
Windows 10: Firefox based 91 3383642
>>353711 (OP)
Когда придумали папки, тогда же придумали и ярлыки, попробуй, довен. Есть ещё и симвполческие ссылки, тоже попробуй.
Linux: Firefox based 92 3389807
>>383196

>Ага, а для каждого файла общесистемной библиотеки мы храним по две тысячи путей до него.


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

>Ядро линукс занимает примерно 800 гб, а при установки каждого дополнительного пакета оно скейлится по экспоненте. Спасибо, не надо.


Дальше вытекающий из предыдущего твоего бреда словесный дрищ.

>>383631

>Древовидная структура, простая и понятная иерархия.


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

>Можно, даже больше, можно чтобы несколько версий файла хранились одновременно. Называется CoW файловая система. То что ты хочешь решается дедубликацией, файловая система автоматически заменяет одинаковые файлы на ссылки.


Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.

>Причем тут пакетный менеджер нах


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

>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.


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

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


Не хочу не буду. Объектная нотация не просто так придумана и нужна в том числе программам и должна поддреживаться файловой системой.
Linux: Firefox based 92 3389807
>>383196

>Ага, а для каждого файла общесистемной библиотеки мы храним по две тысячи путей до него.


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

>Ядро линукс занимает примерно 800 гб, а при установки каждого дополнительного пакета оно скейлится по экспоненте. Спасибо, не надо.


Дальше вытекающий из предыдущего твоего бреда словесный дрищ.

>>383631

>Древовидная структура, простая и понятная иерархия.


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

>Можно, даже больше, можно чтобы несколько версий файла хранились одновременно. Называется CoW файловая система. То что ты хочешь решается дедубликацией, файловая система автоматически заменяет одинаковые файлы на ссылки.


Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.

>Причем тут пакетный менеджер нах


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

>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.


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

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


Не хочу не буду. Объектная нотация не просто так придумана и нужна в том числе программам и должна поддреживаться файловой системой.
Android: Mobile Safari 93 3389818
>>389807

> Пути нигде не хранятся, долбаёб тупой


Да иди ты нахуй со своим троллингом
https://unix.stackexchange.com/questions/360745/where-are-file-directory-entries-for-subdirectories-stored
Android: Mobile Safari 94 3389978
>>389807
Если нужно будет обойти все ноды твоей этой хуйни, ты будешь маркером на листочке помечать где ты был, а где нет? Или будешь круги нахуячивать пока электричество не кончится?
Если у тебя изолированная ветка узлов образуется, которая с рутом не связана, ты как ее искать будешь? Или полностью всю ветку будешь удалять?

Ты не подумай мне просто интересно как ты это видишь.
Linux: Firefox based 95 3390118
>>389807

>Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.


Ну вот разберешься, создашь ещё один тред.
Linux: Firefox based 96 3390249
>>389818
Доказательство привёл ты которое, оно неправильное, потому что там задаётся вопрос о том где хранится папка, тоесть ссылка на неё, а папка != путь к папке.

>>389978
Ну алгоритм обхода графа, состояния хранятся о посещённых папках даже при поиске в ширину. Не вижу никакой проблемы, граф то ОРИЕНТИРОВАННЫЙ, там нет циклов, и войдя в одно из начал, ты за конечное число шагов прийдёшь в один из концов.
Топологически отсортированный граф располагает все ноды по "этажам", как формируются эти "этажи" зависит от критерия, но обычто чтото вроде ближайшего старшинства, тоесть если папка принадлежит нескольким папкам с разных этажей то она находится на самом нижнем +1 этаже, к примеру. Обойти такой граф не должно быть чем то сложным. Я думаю пакетный менеджер этим занимается постоянно.

>>390118
Я уже разобрался это не то потому что позволяет только делать один и тот же файл в разных папках, а надо чтобы и одни и те же "папки" тоже могли быть в разных 2папках".
Linux: Firefox based 97 3390253
>>390249

>Доказательство привёл ты которое, оно неправильное, потому что там задаётся вопрос о том где хранится папка, тоесть ссылка на неё, а папка != путь к папке.


То есть я имею ввиду что сама папка есть ссылка, НО в массиве (блин, цилиндр, сектор), а путь к папке, собственно последовательность таких ссылок, если они имеется, именно поэтому если ты проебёшь папку, ты её больше не найдёшь в этом массиве, потому что не будешь знать что и где лежит, а знаешь ты только благодаря структуре файловой системы.
Linux: Firefox based 98 3390264
Концептуально поясню всётаки для треда, я сейчас уточнил, про мягкие и жёсткие ссылки.

У нас есть абстрактно МАССИВ низкоуровневый машинный, где хранится чтото. Файловая система в нашем случае надстройка, которая в данных хранит ссылки на другие данные по МАССИВУ, а не по файловой системе.

Жесткая ссылка это ссылка на инфу в машинном массиве.

Мягкая ссылка это ссылка на инфу внутри файловой системы, а не на машинном массиве, которая уже содержит ссылку на ячейку в машинном массиве. Вот так вот костыльно, тоесть вместо прямого указания "места на парковке", тебя заставляют бегать по другим адресам пока в машине не будет собственно адреса назначения.
Linux: Firefox based 99 3390267
>>390264

>Жесткая ссылка это ссылка на инфу в машинном массиве.


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

Правильнее было бы это назвать низкоуровневой или машинной ссылкой, но пафосные дебилы в любой области любят придумывать ебанутые "метафизические" названия чтобы нихуя не понятно было. Во всех областях так к сожалению.
Linux: Firefox based 100 3390274

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



>Несмотря на возможности, которые предоставляют жесткие ссылки, у них есть ограничения:



их можно создавать только на файлы, но не на каталоги;

жесткую ссылку нельзя создать на файл, находящийся на другом диске.

> их можно создавать только на файлы, но не на каталоги;



Наверное в этом то и проблема скорее всего.

Я только одного не понял. Ссылки на "папки" всегда мягкие чтоли, тогда этот >>353879 >>358756 получается прав, тогда почему не реализовано на программном уровне недопущение циклов и формирование того что я написал выше. Получается проблема проще чем кажется.
Android: Mobile Safari 101 3390275
>>354045
Имхо за 3.14 фс-подобными системами и тонкими клиентами, подключающимися к вычислительным кластерам мелкомягких будущее, хотя хз когда эта дистопия настанет
Linux: Firefox based 102 3390284
>>390275
НИКОГДА. Компьютер, по крайней мере цифровой, был и останется инструментом, как ручка и блокнот одежда и тп. Лучше смени отношение и акценты.
Android: Mobile Safari 103 3390286
>>390284
Так я и не говорю, что это пиздато, лол. Просто в ближайшем будущем мы будем хавать сверчков и арендовать компьютеры может в рашке запилят аналоговнетный аналог этого дерьма через яндекс спустя 10 лет после того, как оно станет популярно в европе, так что запасайся хардаками, аноний
Linux: Firefox based 104 3390287
>>390274

>Ссылки на "папки" всегда мягкие чтоли,


Вообще если это так то это пиздец как тупо, как с аппаратной стороны, так и с человеческо интерфейсной.
Нет ну если прямо так уж нужна надёжность можно создать синхронизированный "виртуальный" каталог с дескрипторами и прочей служебкой, туда же можно закинуть Downloads кстати говоря, концептуально.
Linux: Firefox based 105 3390295
>>390286
Не взлетит, как и соцсети.
Можно запилить распределённую фс на похожем принципе, только машинные адреса на низком уровне будут включать в себя ещё и на других устройствах через сеть.
Linux: Firefox based 106 3390308
А ещё из-за ёбаного дерева папок придумали такое ненужное говно как компоновщик, КОМПОНОВЩИК блеать. Вместо того чтобы компоненты сами собирались по лямбда путям, ты пишешь makefile блядь, где скриптами дублируешь всю ту умозрительную хуйню которая должна была бы содержаться в структуре каталогов/дирректорий пакета. Ну ахуеть невстать. И никто не возмущается продолжая жрать это говно. Наверное иногда человек со стороны полезнее суперпрофи дрочащий одно и то же 50 лет подряд и не замечающий нихуя дальше носа.
Linux: Firefox based 107 3391259
Вобщем нужно привыкнуть к лямбда структуре каталогов/дирректорий как к естественной и понятной, любая карта сайта обычно не древовидная и это почему-то никогда никого не смущало, хоть там и циклы есть, а подобная структура у папок почемуто является чем то манясложным.
С одной стороны комп должен быть дружелюбным для пользователя с другой должен предоставлять выбор среди вариантов которого необязательно все должны пользователя устраивать, тоесть в этом плане неориентируемость на дебилов, потомучто радикально обратное - утопия и вредительство с быдлизмом.
Android: Mobile Safari 108 3391272
>>391259
Ты и не обходишь все ссылки по карте сайта для индексации
Windows 10: Firefox based 109 3391745
>>390275

>за 3.14 фс-подобными системами и тонкими клиентами, подключающимися к вычислительным кластерам мелкомягких будущее


Нахуй такое будущее. Это же даже словом "пиздец" не описать
Linux: Firefox based 110 3394099
>>390275
>>391745
Дежурно обоссываю пидора разводящего флейм с самим собой.
Linux: Firefox based 111 3396422
Куда писать разработчикам линукса чтобы с ними об этом добазариться?
Windows 10: Firefox based 112 3399070
>>394099
Лечись, шизик
Linux: Firefox based 113 3400616
>>383631

>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна.


>Частично признаю что ты прав


И на том спасибо.

>Только недавно федора стала поставлять бтрфс как стандартную фс.


Ещё одно вонючее юзлесс мёртворождённое говно от копров для порносайтов и бугалтерий.
Android: Mobile Safari 114 3400649
Еще в досе такой хуйней страдали.
Создавали папку "мамка админа".
Указывала она на корень.
Приходил админ, жал Ф8
А теперь взял редактор и пошел улучшать ноды своей фс.
Linux: Firefox based 115 3400675
>>400649
В досе хуёсе, это ты сейчас сам придумал? ПОх чё там было лет 40 назад, концепции меняются было бы желание, NIXos же запилили и заебись, если бы там системды и гнома не было можно было бы даже пользоваться этим.

>>400652 (Del)
Так я и вижу что обитатели тут говно хуже некуда, походу нормальные люди здесь незадерживаются а твоя работа выдавливать их отсюда.
Android: Chromium based 116 3400783
>>353711 (OP)

>свойства


>создать ярлык


PROFIT
Android: Mobile Safari 117 3400838
>>353711 (OP)

>Где есть форум где сидят разрабы линукса чтобы им написать об этом и приступить к работе?


Тебе нужны разрабы файловых систем, а вернее новая файловая система. Кто-то должен её разработать. К линуксу и его разрабам это имеет мало отношения, чтобы что-то добавить в Линукс это что-то должно существовать.

Шансов што такую хуйню добавят в существующие фс практически нет.
Linux: Firefox based 118 3401526
>>400783
Васянская smekalochka снова здесь. Только если ты достаточно криворукий, тебе можно.
Ты главное папку с ярлыками на все созданные ярлыки создать не забудь, а то мало ли что пойдёт не так.
Linux: Firefox based 119 3403096
>>400838
Да иди ты нахуй на всякий случай закомплексованное тупое уёбище, я после твоей мозгоебли и издевательств ссу на любой твой высер, комплексы бездарности ёбаной заиграли у тебя суки, сдохни от рака говно ёбаное.
Linux: Firefox based 120 3405640
Говняное жлобское свиноёрылое уёбще может только спорить на ровном месте: "ну и зачем?" "да не взлетиииит" "нет ну это надо 7 кругов ада пройти кококок". Сам за свою жизнь нихуя придумать не смогло поэтому и спорит пятаком своим ебаным. А других нормальных людей тут и нет практически никто не отписался за всё время. Тред можно выкидывать.
Linux: Firefox based 121 3410678
>>353711 (OP)
Да в том же меню "пуск" в KDE уже одна и та же программа находится в нескольких категориях, например стим лежит и в категории "игры" и в категории "интернет", что вполне логично, тоесть проблема эта стоит весьма остро, но сил пока хватило на организацию менюшечек и сайтиков, если дизайнеру повезло быть в курсе про это. В большинстве случаев в интерфейсах лютых пиздец в виде дубляжа одного и того же в нескольких ветках или вообще хаотичная каша из ссылок какая пришлась с недосыпа.
Linux: Firefox based 122 3411760
>>353711 (OP)
ВОт элементарно есть у нас конфиги для каждой программы, значимая категория, было решено скидывать все конфиги в одну деррикторию разнося по сути программу по разным веткам, давая "витруальную" связность между ними с помощью как раз таки программы. Но это тоже костыль по сути, и всёравно нужна возможность добраться в конфиг из дирректории самой программы, а не только дирректории с конфигами. Кароче ёбаный ад из компромиссов с этим деревом ебучим.
Linux: Firefox based 123 3412023
>>353711 (OP)
А так же это позволит сделать КОНТЕЙНЕРИЗАЦИЮ и разграничение прав буквально из коробки, без обходных решений и прочей ебатни. Почему проглядели за столько лет?
изображение.png97 Кб, 277x267
Linux: Firefox based 124 3412037
Linux: Firefox based 125 3412566
>>412023
Да иначе зачем изначально в линуксе все контексты сделали дирректориями, нелогично как-то получается.
Linux: Firefox based 126 3421285
>>383631

>Древовидная структура, простая и понятная иерархия.


Может тебе ещё надо, чтобы на борде нельэя было отвечать на 2 и более поста одним постом?

>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.



Какой же блядь копиум неосилятора.
Windows 10: Chromium based 127 3421515
>>3418097 (OP)
За тобой уже выехали.>>353711 (OP)
Windows 10: Chromium based 128 3421517
>>353711 (OP)
Зумер придумал симлинки
Linux: Firefox based 129 3421583
>>421515
>>421517
Руки об ближайший забор выровняй и голову свою недалёкую за одно.
Linux: Firefox based 130 3422175
>>421517
Нет, зумер придумал рефлинки.
https://btrfs.readthedocs.io/en/latest/Reflink.html
Windows 10: Firefox based 131 3422245
>>422175
Рефлинки детачат от оригинала и включают ков.

>>421517
Симлинки работают между фс, а тут всё в одной.

Заранее скажу, что хардлинкам запрещено линкать директории, что предполагается в схеме опа.

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

В общем, прямо сейчас нет никаких проблем построить систему целиком из симлинков, и проверить, насколько это вообще полезно, не привлекая "разрабов линукса" с "форума", а проблему лупов решать после, если она вообще возникнет.
Linux: Firefox based 132 3422248
>>422245

> включают ков


А ты типа луддит или что?
Linux: Firefox based 133 3422250
>>422245

>Рефлинки детачат от оригинала


Хорошо, хардлинки не детачат от ков, и не требуют включения ков. Пользуйся.
Windows 10: Firefox based 134 3422251
>>422248
Это типа не то, что оп хочет.
Linux: Firefox based 135 3422252
>>422250

> детачат от ков


от оригинала всмысле
Windows 10: Firefox based 136 3422254
>>422250
В посте есть про хардлинки.
Linux: Firefox based 137 3422260
>>422254
Не дочитал пост до конца, сорян. Я уже сам запутался, я уже давал опу ответ про дедупликацию в бтрфс, но он ответил так:

>Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.


Конечно, он хочет откровенную шизу, если кто-нибудь обладает связями в транс сообществе киньте ему инвайт в конфу, авось там его поймут. Вот, например, из недавнего транс-софта выкатили неиерархичный файловый менеджер https://github.com/kra-mo/hyperplane , начало положено.
Windows 10: Firefox based 138 3422264
>>422260

>я уже давал опу ответ


ОП сумасшедший, это понятно, если почитать тред. Но, в целом, техническая задача интересная и вполне себе осуществимая на современных технологиях. Но оп, конечно, хочет, чтобы кто-то её сделал за него.
А я так, мимопроходил, пояснил за *линки.
Linux: Chromium based 139 3422299
>>422264
Выглядит как будто ОП решил натянуть множественное наследование из классов на фс. Забыв что такое наследование это зло ебучее.
Как будто правы ребята что ОП хочет внести контекст определяемый человеком на уровень ФС. При этом каждому новому файлу нужно будет прокликивать из списка в какой контекст он относится? Т.к. никакая нейросеть сходу не определит что вот этот файлик хуета.txt в папке Моё относится к списку продуктов на выходные, которые мне жона скинула, пока я сам зачем то не пропишу тегом например. Ну либо должно отслеживаться всё на уровне перекидывания файлов, контекста и его паттернов взаимодействия и т.д. Крч ебические мощности нужны с зондами вплоть до энцефалограммы носителя. А для каталогизирования под какие то более узкие и определённые задачи давно сделали БД, теги, индексацию и т.д. Херня задача как будто, непрактичная и легко ломаемая именами файлов 1,12, 1111, 123, йцук и сильно завязанная на корректность описания контекста.
другой мимо прочёл по диагонали
Windows 10: Firefox based 140 3422316
>>422299
Мне кажется, ты тоже сумасшедший.
Linux: Firefox based 141 3451954
>>422260

>если кто-нибудь обладает связями в транс сообществе киньте ему инвайт в конфу, авось там его поймут.


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

>Конечно, он хочет откровенную шизу


>Вот, например, из недавнего транс-софта выкатили неиерархичный файловый менеджер https://github.com/kra-mo/hyperplane , начало положено.


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

>>422264

>Но, в целом, техническая задача интересная и вполне себе осуществимая на современных технологиях


Хоть в чём-то согласие.

>Но оп, конечно, хочет, чтобы кто-то её сделал за него.


Да схуяли за меня то? Врядли это когото больше волнуе т чем меня. Нет ну если вот прям щас готово и вышло с апдейтом то я конечно рад.

>>422299

>Выглядит как будто ОП решил натянуть множественное наследование из классов на фс.


Лол ромбичность папок это просто ебический частный микрослучай посравнению с ромбичностью ООП который делается просто сместа, а то что это реализовано даже в ООП хоть и криво ебать какое достижение которое даже я не до конца понимаю как. Это просто стандартные вещички типа ссылок в оперативке только на харде. ПФФ даже сравнивать смешно.

>Забыв что такое наследование это зло ебучее.


Не спорю но как сказано выше это другое.

>ОП хочет внести контекст определяемый человеком на уровень ФС


Ну правильно а что тебе надо чтобы комп тебе попу мыл?

>При этом каждому новому файлу нужно будет прокликивать из списка в какой контекст он относится?


Обычные юзер действия.

>Т.к. никакая нейросеть сходу не определит что вот этот файлик хуета.txt в папке Моё относится к списку продуктов на выходные, которые мне жона скинула, пока я сам зачем то не пропишу тегом например.


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

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


Ты выдумывать всё пытаешься налету. Не нужно граф папок итак содержит всю нужную информацию.

> Крч ебические мощности нужны с зондами вплоть до энцефалограммы носителя.


Не нужны. Как и задачи которые ты для этого ставишь.

> А для каталогизирования под какие то более узкие и определённые задачи давно сделали БД, теги, индексацию и т.д.


Говно архаичное эти БД. Вижу ваку с БД бегу по ебейшему радиусу от неё.

>Херня задача как будто, непрактичная и легко ломаемая именами файлов 1,12, 1111, 123, йцук и сильно завязанная на корректность описания контекста.


Неломаемая. Или имеющая в любом случае меньше минусов чем текущий мусор.

>>422316
Сам ты блядь сумашедший пидор.
Linux: Firefox based 141 3451954
>>422260

>если кто-нибудь обладает связями в транс сообществе киньте ему инвайт в конфу, авось там его поймут.


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

>Конечно, он хочет откровенную шизу


>Вот, например, из недавнего транс-софта выкатили неиерархичный файловый менеджер https://github.com/kra-mo/hyperplane , начало положено.


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

>>422264

>Но, в целом, техническая задача интересная и вполне себе осуществимая на современных технологиях


Хоть в чём-то согласие.

>Но оп, конечно, хочет, чтобы кто-то её сделал за него.


Да схуяли за меня то? Врядли это когото больше волнуе т чем меня. Нет ну если вот прям щас готово и вышло с апдейтом то я конечно рад.

>>422299

>Выглядит как будто ОП решил натянуть множественное наследование из классов на фс.


Лол ромбичность папок это просто ебический частный микрослучай посравнению с ромбичностью ООП который делается просто сместа, а то что это реализовано даже в ООП хоть и криво ебать какое достижение которое даже я не до конца понимаю как. Это просто стандартные вещички типа ссылок в оперативке только на харде. ПФФ даже сравнивать смешно.

>Забыв что такое наследование это зло ебучее.


Не спорю но как сказано выше это другое.

>ОП хочет внести контекст определяемый человеком на уровень ФС


Ну правильно а что тебе надо чтобы комп тебе попу мыл?

>При этом каждому новому файлу нужно будет прокликивать из списка в какой контекст он относится?


Обычные юзер действия.

>Т.к. никакая нейросеть сходу не определит что вот этот файлик хуета.txt в папке Моё относится к списку продуктов на выходные, которые мне жона скинула, пока я сам зачем то не пропишу тегом например.


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

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


Ты выдумывать всё пытаешься налету. Не нужно граф папок итак содержит всю нужную информацию.

> Крч ебические мощности нужны с зондами вплоть до энцефалограммы носителя.


Не нужны. Как и задачи которые ты для этого ставишь.

> А для каталогизирования под какие то более узкие и определённые задачи давно сделали БД, теги, индексацию и т.д.


Говно архаичное эти БД. Вижу ваку с БД бегу по ебейшему радиусу от неё.

>Херня задача как будто, непрактичная и легко ломаемая именами файлов 1,12, 1111, 123, йцук и сильно завязанная на корректность описания контекста.


Неломаемая. Или имеющая в любом случае меньше минусов чем текущий мусор.

>>422316
Сам ты блядь сумашедший пидор.
Android: Mobile Safari 142 3474644
>>353711 (OP)

> до сих пор нельзя чтобы одна и та же папка лежала в нескольких папках одновременно?



Создай один реальный экземпляр и накидай на него симлинков, например. В /run и /proc это можно наблюдать почти в любом дистре. Там даже пижже - симлинки ещё и циклятся и перебирая такую папку тупым поиском исчерпаешь память.
Windows 10: Chromium based 143 3477580
>>353711 (OP)
Два чая адеквату
Linux: Firefox based 144 3484003
>>362169

>Ты, как и многие, путаешь связи между объектами, использующие разные признаки, в том числе и связанные с техническим устройством системы, и смысловую иерархию, в которую они выстраиваются (в другом измерении). Первое не предусматривает и не задаёт второго.


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

>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях


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

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


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

>Кроме того, представлений файлов на практике тоже больше одного. Можно не помнить, на каком диске лежит фильм, если находишь его в общем списке торрент-клиента. Можно добавить все места хранения фото в менеджер картинок (или музыку — в проигрыватель) и пользоваться их проекциями, не думая о физическом расположении или формате.


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

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


Ясен что иерархия в голове но это никак не противоречит с тем что эта иерархия выражена в папках-нодах. А бвзы данных это архаика.
Linux: Firefox based 144 3484003
>>362169

>Ты, как и многие, путаешь связи между объектами, использующие разные признаки, в том числе и связанные с техническим устройством системы, и смысловую иерархию, в которую они выстраиваются (в другом измерении). Первое не предусматривает и не задаёт второго.


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

>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях


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

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


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

>Кроме того, представлений файлов на практике тоже больше одного. Можно не помнить, на каком диске лежит фильм, если находишь его в общем списке торрент-клиента. Можно добавить все места хранения фото в менеджер картинок (или музыку — в проигрыватель) и пользоваться их проекциями, не думая о физическом расположении или формате.


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

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


Ясен что иерархия в голове но это никак не противоречит с тем что эта иерархия выражена в папках-нодах. А бвзы данных это архаика.
Linux: Firefox based 145 3484005
>>362169

>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях. Компьютер не может тебе помешать поместить свои документы в каталог «Барнаул, Алтайский край». С другой стороны, даже у владельцев файлопомоек в голове появляется некая иерархия взаимосвязей, позволяющая находить, где что лежит.


Папки должны отображать человеческий смысл прежде всего приоритетно! Но тебе ничто не мешает создать паппку МП3 со ссылками на все файлы МП3 на твоём диске раз уж тебе так надо.
Linux: Firefox based 146 3484009
Моя предлагаемая структура бесконтурного орграфа не является ебать какой гиперструктурой на категориях, даже она содержить дохуя прагматичных упрощений. Например что папка может либо существовать либо нет, и других состаяний не существует. При желании можно копнуть и дальше и дальше, но я понимаю что продуктивность тут будет ниже чем переусложнённость. ЭТо примерно как с синтаксисами языков программирования заёбываться ими можно бесконечно не занимиясь программированием вообще, только нахуй это не нужно.
Linux: Firefox based 147 3484772
>>474644

>В /run и /proc это можно наблюдать почти в любом дистре. Там даже пижже - симлинки ещё и циклятся и перебирая такую папку тупым поиском исчерпаешь память.



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

Я уверен с ромбичностью ещё и от ебейшго числа конфликтов ПО можно избавиться. Ну и циклить нихуя не надо.
Linux: Firefox based 148 3484777
>>484003

>без циклов разумеется виду прагматичного учёта ограниченности железа.


Хотя если сильно чешется то циклы можно и легитимизировать при условии что все элементы ноды цикла лежат в одной общей старшей ноде, прагматичная страховка для обхода. Только лучше не надо.
Linux: Firefox based 149 3484786
>>362169

>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях.


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

>>484777
Нет я даже готов смириться с циклами но сделанными по правилам чем с тем пиздецом что творится сейчас. Да скорее всего циклы таки понадобятся в редких исключительных ситуациях. Но не произвольные.
Windows 10: Firefox based 150 3486201
Вы год обсуждаете какую-то хуйню, но до сих пор так и не прояснили 3 основных момента:

1) каким образом ОП хочет использовать, что одна и таже папка лежит в разных папках?

2) почему ОП на протяжении всего треда игнорирует посты о ярлыках и ссылках? ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?

3) каким образом эта самая "одна и таже папка" по мнению ОПа должна попадать в эти самые "разные папки"? Как-то автоматом или что? Чем это вообще отличается от того, что я прямо сейчас скопировал папку у другую папку, или просто создал ярлык на папку?
Linux: Firefox based 151 3486678
>>486201

>1) каким образом ОП хочет использовать, что одна и таже папка лежит в разных папках?


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

>2) почему ОП на протяжении всего треда игнорирует посты о ярлыках и ссылках? ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?


Кто игнорирует ёпт? Я не игнорирую а нахуй шлю это говно.

>3) каким образом эта самая "одна и таже папка" по мнению ОПа должна попадать в эти самые "разные папки"? Как-то автоматом или что? Чем это вообще отличается от того, что я прямо сейчас скопировал папку у другую папку, или просто создал ярлык на папку?


Каким образом? Начиная с нижнего уровня оно ссылками так же организовано просто и без задней мысли. Ты лучше подумай и скажи нахуя нужны мягкие ссылки.
Linux: Firefox based 152 3486689
>>486201

>ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?


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

Да и хорошо подумай над тем зачем вообще нужны откуда высрались мягкие ссылки и почему мне нужно вообще их различать за какимто хуем почему мне должно быть не похуй.
BSD: Firefox based 153 3486705
>>353711 (OP)
Вообще-то может. На винде может и уж тем более на Линуксе. Используй симлинки епта. Всё давно придумано и не нужно ничего дополнительно устанавливать.
BSD: Firefox based 154 3486710
>>364767

>Зачем мне знать, где в системе находится отчёт за прошлые года по корректному продукту если я могу запросить "морковь отчёт 2018" и получить релевантные результаты?


Это сработает только пока пользовать нормально дает имена файлам, чтобы потом их было можно вот так найти.
Linux: Firefox based 155 3486725
>>486705
А дерево папок тогда нахуя? Для красоты или чё? Или несудьба изначально было сделать систему гибче по дизайну. Нахуй не нужны твои симлинки потому что их как раз потом придётся различать ещё и вручную а автоматическая система сделал и забыл ёпта. Не нужно обмазываться говном пожалуйста. Да и все объеты имеют объектную нотацию это база.

>>486710

>Это сработает только пока пользовать нормально дает имена файлам, чтобы потом их было можно вот так найти.


Ну так если пользователь криворучка ето его проблемы, можно кинуть ему ситуативный костыль как кость собаке чтобы за пределы загона не убегал и нормальные здоровые люди могли м здоровый менеджмент объектов.
Linux: Firefox based 156 3486735
>>486705
Нахуя нужны симлинки нахуй, точнее нахуя вот мне различать вообще мягкая ссылка или жёсткая? Нахуя мне это надо? Мне чё заняться чтоли блядь нечем потвоему? А пакеты программ мне чё блядь тоже симлинками предлагаешь внутри связывать? Это говно а не решение. Ось должна в объектную нотацию ИЗКОРОБКИ блядь и никак иначе. Я смотрел даже какие утилиты при этом сломаются и их кстати не так уж и много. Ну монтирование придётся переделать а всё остальное как будто под это задумывалось изначально только чёто проебланили гдето на какомто этапе.
Android: Firefox based 157 3486742
>>486689

>зачем вообще нужны откуда высрались мягкие ссылки и почему мне нужно вообще их различать за какимто хуем почему мне должно быть не похуй



>>353711 (OP)

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



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

А с фотками и музыкой это делается через всякие коллекции и галереи, которые сейчас в любом плеере и просмотрщике есть. Там как раз можешь как угодно группировать и сортировать один и тоже файл, включать его в сколько угодно плейлистов и альбомов.
Linux: Firefox based 158 3486764
>>486742

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



Получится, всё получится. Как раз в этом случае безопасность организовать даже проще и она будет даже менее костыльной чем в случае текущем, потому что можно будет организовать целые области видимости кому и кого надо. В случае что ты описал просто берётся функция eto_drugoe_ponimat_nado_smotrii_ne_pereputai которая как раз КОПИРУЕТ файл создавая его дополнительый экхемпляр в другом загоне и никто их не перепутает всё заебись. А если ещё серьёзнее то просто к функции копировать и вырезать надо добавить функцию связать, чтобы прокинуть жёсткую ссылку без копирования файла или папки.

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



Нет всякие копрогалереи это говно ебаное для колхозников. И там как раз НЕЛЬЗЯ как угодно группировать из-за привязки к формату файла, архаика ебучая.
Овт смотри могу объяснить на пальцах. Есть у меня скажем знакомый, и на компе у меня есть папка с его именем, там лежат его фотки голосовухи и прочее, есть у него баба, папку с бабой можно считать подконтекстом моего кореша ибо нахуй она мне сдалась выше по контексту, ок создал подпапку баба кореша в папке кореш, у них родился наёбыш, папку с наёбышем проде надо кинуть в папку с бабой но и в пвпку с корешем. А ещё кореш сделал днк анализ что наёбыш его и прислал мне документ в формате пдф этот документ связывает кореша и его наёбыша поэтому принадлежит корневой папке кореша и подпапке наёбыша. Но тут ещё мякотка в том что документ о днк родстве является связующим для обоиз контекстов, а связующий может находиться как ниже так и выше по топологии контекстов. Тоесть ромбическую структуру можно ОТЗЕРАКЛИТЬ и смотрель задом наперёд а с деревом так нельзя, ну как бы можно но тогда это будет просто астнономическое количество ВСЕХ папок с подпапками до корня вот.
Linux: Firefox based 158 3486764
>>486742

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



Получится, всё получится. Как раз в этом случае безопасность организовать даже проще и она будет даже менее костыльной чем в случае текущем, потому что можно будет организовать целые области видимости кому и кого надо. В случае что ты описал просто берётся функция eto_drugoe_ponimat_nado_smotrii_ne_pereputai которая как раз КОПИРУЕТ файл создавая его дополнительый экхемпляр в другом загоне и никто их не перепутает всё заебись. А если ещё серьёзнее то просто к функции копировать и вырезать надо добавить функцию связать, чтобы прокинуть жёсткую ссылку без копирования файла или папки.

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



Нет всякие копрогалереи это говно ебаное для колхозников. И там как раз НЕЛЬЗЯ как угодно группировать из-за привязки к формату файла, архаика ебучая.
Овт смотри могу объяснить на пальцах. Есть у меня скажем знакомый, и на компе у меня есть папка с его именем, там лежат его фотки голосовухи и прочее, есть у него баба, папку с бабой можно считать подконтекстом моего кореша ибо нахуй она мне сдалась выше по контексту, ок создал подпапку баба кореша в папке кореш, у них родился наёбыш, папку с наёбышем проде надо кинуть в папку с бабой но и в пвпку с корешем. А ещё кореш сделал днк анализ что наёбыш его и прислал мне документ в формате пдф этот документ связывает кореша и его наёбыша поэтому принадлежит корневой папке кореша и подпапке наёбыша. Но тут ещё мякотка в том что документ о днк родстве является связующим для обоиз контекстов, а связующий может находиться как ниже так и выше по топологии контекстов. Тоесть ромбическую структуру можно ОТЗЕРАКЛИТЬ и смотрель задом наперёд а с деревом так нельзя, ну как бы можно но тогда это будет просто астнономическое количество ВСЕХ папок с подпапками до корня вот.
Linux: Firefox based 159 3486769
>>486764
Но так же у моего кореша есть питомец который мне очень понравился и похоже который любит меня больше чем хозяев, папку с питомцем я кладу в подпапку всех членов семьи кореша а так же в контекст выше на равне с корешем, очень мне нравится это животное например, ну пусть это гекон будет какойнибудь например.
BSD: Firefox based 160 3486791
>>486735

>А пакеты программ мне чё блядь тоже симлинками предлагаешь внутри связывать?


Ага. Это ведь работает. Например, можно папку из родной Program Files с диска C перекинуть куда-то ещё на другой диск, а обратно на С в Program Files вместо самой папки вернуть симлинк на папку и это будет работать. Будто никто ничего никуда и не перемещал вовсе. ну ещё ярлык в меню пуск надо будет поправить.
BSD: Firefox based 161 3486792
>>486725

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


Ну так напиши скрипты, автоматизируй епта. Добавь задания на запусмк в роднйо планировщик задач винды или в Cron на Linux/FreeBSD и дело-то. Мыслишь ограниченно в натуре как виндузятник.
Windows 10: Chromium based 162 3486808
>>486764
Проблема любой структуры кроме древовидной в том, что ты забудешь о ее элементах уже через несколько месяцев.
Дерево же будет оставаться с тобой неизменным годами, дисциплинировать твой ум, и будет обрастать ответвлениями. И если наебыш для тебе через много лет станет важнее, чем его родичи, то дерево не надо менять, а достаточно продлевать его не меняя принципов построения. С ромбом или облаком ты получаешь мешанину и в мыслях и в файлах.
А для удобства доступа просто накидываешь ссылки на нужные элементы дерева в отдельные папки.
В этом суть прямых связей и ассоциативных.
Облако это грязная мешанина ассоциативных и прямых связей, которую ты заебешься перестраивать каждый год.
А правильно построенное дерево на прямых связях типа: род/вид, часть/целое и дополненное перекрестными линками - это практически вечная структура.
Linux: Firefox based 163 3497077
>>486791

>ну ещё ярлык в меню пуск надо будет поправить.


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

>>486792

>Ну так напиши скрипты, автоматизируй епта. Добавь задания на запусмк в роднйо планировщик задач винды или в Cron на Linux/FreeBSD и дело-то. Мыслишь ограниченно в натуре как виндузятник.


Мне так придётся только написанием скриптов и заниматься.

>>486808

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


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

>Дерево же будет оставаться с тобой неизменным годами, дисциплинировать твой ум,


Это дисциплинирование ануса а не ума.

>и будет обрастать ответвлениями


>то дерево не надо менять, а достаточно продлевать его не меняя принципов построения.



Ога, знаю как оно будет обрастать, получится хуйня уровня:
/program/media/video
/program/
.program/messages/images
/program/messages/videos
/program/videos/messages
/images/videos/program
/чуета/видео/долбоебизм
/долбоебизм/говноедство/картинки
И такая сортировка файлов практически в любой проограмме какую не глянь. Открываешь пак игры и всё хранится по ебанутому модельки отдельно анимации отдельно, текстуры отдельно, нет ну зачем так париться хранили бы тогда всё в одном каталоге и всё ёбанарот только жизнь усложняют себе причём. Лучше вообще не иметь структуры чем говно вместо неё.

>А для удобства доступа просто накидываешь ссылки на нужные элементы дерева в отдельные папки.


Тут не в удобстве дело, а в том что в структуре отражена ключевая информация об объекте, а не колхоз долбаёба.

>В этом суть прямых связей и ассоциативных.


Чего блядь? Тут нет никакой разницы вообще. Это лишняя классификация, ненужная выкинь её.

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


Сам придумал сам добавил ещё один потешный тезис. Какой молодец.

>А правильно построенное дерево на прямых связях типа: род/вид, часть/целое и дополненное перекрестными линками - это практически вечная структура.


Безосновательное утверждение того что с ромбом это не так.

Я думаю ты не понял одну вещь, что IT обросло с кучей исторических артефактов сделанный в духе времени по ситуации но совершенно нерационально и неэффективно, вроде клавиатур до сих пор выпускаемых в такой компоновке как будто это печатная машинка, но печатных машинок уже давно нет в ходу и бумага уже сокращается а тут приходится гнуть пальцы в 2024м чтобы косплеить машинистку начала середины 20 века когда компов ещё не было, вот это умно ебать "вечная структура". И так же с файловой системой когда они только появлились "компьютерщики" решили что раз уж диск периферической устройство то каталог это интерфейс а потому должен иметь "упрощённую" структуру дерева ну чтобы бугалтерши не взвыли, но это был проёб и ты это упускаешь.
Linux: Firefox based 163 3497077
>>486791

>ну ещё ярлык в меню пуск надо будет поправить.


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

>>486792

>Ну так напиши скрипты, автоматизируй епта. Добавь задания на запусмк в роднйо планировщик задач винды или в Cron на Linux/FreeBSD и дело-то. Мыслишь ограниченно в натуре как виндузятник.


Мне так придётся только написанием скриптов и заниматься.

>>486808

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


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

>Дерево же будет оставаться с тобой неизменным годами, дисциплинировать твой ум,


Это дисциплинирование ануса а не ума.

>и будет обрастать ответвлениями


>то дерево не надо менять, а достаточно продлевать его не меняя принципов построения.



Ога, знаю как оно будет обрастать, получится хуйня уровня:
/program/media/video
/program/
.program/messages/images
/program/messages/videos
/program/videos/messages
/images/videos/program
/чуета/видео/долбоебизм
/долбоебизм/говноедство/картинки
И такая сортировка файлов практически в любой проограмме какую не глянь. Открываешь пак игры и всё хранится по ебанутому модельки отдельно анимации отдельно, текстуры отдельно, нет ну зачем так париться хранили бы тогда всё в одном каталоге и всё ёбанарот только жизнь усложняют себе причём. Лучше вообще не иметь структуры чем говно вместо неё.

>А для удобства доступа просто накидываешь ссылки на нужные элементы дерева в отдельные папки.


Тут не в удобстве дело, а в том что в структуре отражена ключевая информация об объекте, а не колхоз долбаёба.

>В этом суть прямых связей и ассоциативных.


Чего блядь? Тут нет никакой разницы вообще. Это лишняя классификация, ненужная выкинь её.

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


Сам придумал сам добавил ещё один потешный тезис. Какой молодец.

>А правильно построенное дерево на прямых связях типа: род/вид, часть/целое и дополненное перекрестными линками - это практически вечная структура.


Безосновательное утверждение того что с ромбом это не так.

Я думаю ты не понял одну вещь, что IT обросло с кучей исторических артефактов сделанный в духе времени по ситуации но совершенно нерационально и неэффективно, вроде клавиатур до сих пор выпускаемых в такой компоновке как будто это печатная машинка, но печатных машинок уже давно нет в ходу и бумага уже сокращается а тут приходится гнуть пальцы в 2024м чтобы косплеить машинистку начала середины 20 века когда компов ещё не было, вот это умно ебать "вечная структура". И так же с файловой системой когда они только появлились "компьютерщики" решили что раз уж диск периферической устройство то каталог это интерфейс а потому должен иметь "упрощённую" структуру дерева ну чтобы бугалтерши не взвыли, но это был проёб и ты это упускаешь.
Linux: Firefox based 164 3497082
Я так же считаю что в интересах технической консистентности папки могут содержать системные циклы, но в пользователю это я думаю ни к чему.
Linux: Firefox based 165 3497086
А стоит ли говорить что даже сеть на самом фундаментальном уровне нихуя не древовидная, то нахуя тогда папки имеют древовидную структуру вообще тупизм какойто. Информация должна быть структурирована, без структуры инфа это просто мусор. А структуры нет и данных всё больше если не привести к порядку это всё сейчас то потом может стать поздно.
Linux: Firefox based 166 3497128
>>497086
Ведь сеть это же интерфейс какойто там периферический. Или не периферический и не интерфейс, а хардкод? Или зависит от ситуации? Ой а давайте для каждой ситуации отдельную ветку дерева создадим удобно же. И для каждого возможного обхода графа тоже по ветке дерева охуеть как удобно ну.
Linux: Firefox based 167 3497398
>>353711 (OP)

>ррряяя то костыль, это костыль


>что в его понимании не костыль внятно объяснить не может

BSD: Firefox based 168 3498734
>>497077

>Мне так придётся только написанием скриптов и заниматься.


А что ещё на Линухк делать-то? В игоры что ли играться?
Linux: Firefox based 169 3502273
>>498734
Если раскрыть мысль точнее, я имел ввиду что, заниматься написанием скриптов для того что итак должно привычно работать само, когда можно писать скрипты для того чтобы модифицировать и кастомизировать уже привычное, что есть большая разница.

Да смена базы. Ярлыки ненужны не из-за циклов, а из-за необходимости в ненужном различии мягких и жёстких ссылок, спасибо за внимание.
Linux: Firefox based 170 3506897
Так как сделать то что я задумал?
Linux: Firefox based 171 3508531
>>506897
Да хули тут искать ответов. Весь софтач давча это почти одни пидоры биомусор кароче. Пидорам софт не положен вот они и бесятся. Мало зиблокировали им халявы.
Apple GayiPhone: Safari 172 3512066
Красавица!
Windows 10: Chromium based 173 3515279
>>412566

>Да иначе зачем изначально в линуксе все контексты сделали дирректориями, нелогично как-то получается


Кал нинужон.
Linux: Firefox based 174 3515852
>>515279
Ну так не ешь.
Android: Mobile Safari 175 3516219
Такс, есть для винды какой-то способ дедупликации? Скопировал с телефона фото/видео так как оно на нем лежало + ещё раз отсортировал по папка.
Linux: Firefox based 176 3516596
>>516219
Да есть. Написать майкам пожалание перевести всё на новую ФС где будет разрешена схема папок предложенная мной, других способов нет, кроме ебли с ярлыками что тут предлагали.
Android: Mobile Safari 177 3516725
>>516596
Если немного погуглить то дедупликация таки есть. Но неизвестно к каким проблемам приведет включение.
Linux: Firefox based 178 3517117
>>516725
Так мне лично не нужна дедупликация. Проблема которую я хочу решить не состоит в экономии места, а состоит в экономии информации о файлах, повышении связности. Ведь каша из файлов это даже ещё хуже чем просто забитый винт.
Linux: Firefox based 179 3519165
>>517117
Шиз, у тебя всегда есть сосноль и возможность типа feh ~/Photo/porno/Pamela Anderson nude.jpg
Android: Mobile Safari 180 3519526
>>519165
Что за пердоговно?
image.png213 Кб, 900x1200
Windows 10: Chromium based 181 3549955
Пусть тред живёт
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 28 октября в 03:07.

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

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /s/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски