Tmsu Tagsistant TagFS Dantalian Supertag обычныессылки
Tmsu - не умеет группировать тэги, чтоб по запросу linux выдавало и arch и deb. Умеет какая-то другая но там были свои недостатки.
Tmsu - не умеет группировать тэги, чтоб по запросу linux выдавало и arch и deb. Умеет какая-то другая но там были свои недостатки.
>Теги вместо дирректорий
Ну и зачем? Теги это мусор.
Есть же классические дирректории что мешает двум и более предкам-папкам ссылаться на одного и того же потомка-папку?
Приведённая тобой система использует и дирректории и теги, йобаный пиздец. Папка это же уже сементический контекст который может ссылаться куда угодно, по крайней мере на уровне диска. Я после момента с дирректориями перестал читать хабр на тему Tagsistant. Почему папку просто не считать нодой графа и размещать данные в вершинах? Тут и аппаратно просто реализуется. Нахуя ещё и о ужас контекстный поиск вхуячивать в архитектуру файловой системы?
И как ты собрался использовать теги программами?
Это типа только как база данных для человека чтоли? Пфффффф, это не серьёзно.
То что я предложил можно закостылить софтлинками, но костыли я презираю. Я имел ввиду просто чтобы все ссылки были жёсткими только и всего. В чём проблема так сделать? И программы и где угодно можно будет использовать. А ещё повторюсь что теги это мусор, они не работали вообще никогда, всем похуй на них. Хорошая вещь семантическая сеть, но это для веба больше подходит. В 2023м Теги какието ебать.
Ещё Tagasistant использует sql ебать ебать, нет стоп. Это не фундаментальное решение. Нам нужна ромбическая топологически отсортированная структура папок представляющая собой отсортированный бесконтурный(без циклов) граф, и ВСЁ. Для того чтобы этой структурой мог пользоваться человек и программы. А всякие сложные контексты всегда можно создать папкой(нодой в данном случае). Все программы в своём загоне и файлы тоже раскиданы по нодам-контекстам, двух зайцев одним выстрелом. И пакетный менеджер уже не так нужен, так как программа сама знает на что ссылаться и чему пренадлежать.
Где найти обсуждения на эту тему или где продуктивнее всего эту тему поднять?
>Почему в 2023м из-за того что по ошибке придумали хранить файлы в "папках" до сих пор нельзя чтобы одна и та же папка лежала в нескольких папках одновременно?
Мультипользовательский режим и права. Ты ведь знаешь, что директория - это тоже файл? Всё итак лежит в одном файле - все файлы. Но разнесение в дерево нужно для решения проблемы доступа к файлу или файлам, и изменения файлов во время работы с ними.
/thread
> Linux: Firefox based
> в симлинки не смог
линки на файлы и папки есть даже в винде, не говоря о лине.
Ты увидел лишь вершину айсберга - древовидную иерархию каталогов, но проглядел истинную проблему: все мейнстримовые ФС в 2023 всё ещё блочные. Но в 99 % случаев тебе не нужен блочный доступ. Ты считываешь GiantBoobs-67.jpg или ОчтётПетровичаб2009.doc разом, как целый объект, блочный адресный доступ нужен только для узкоспециализированного софта типа БД. Мы тащим блочное легаси, превозмогаем боль в сетевых и распределённых фс, пытаясь имитировать блоки и там.
В объектной фс ты не связан по рукам и ногам иерархией каталогов, ты без всяких костылей можешь поверх неё реализовать и графовую структуру, и структуру по тэгам/метаданным. Осталось лишь заставить корпоратов смасштабировать их до домашнего железа.
Есть прототипы объектных ФС?
>Мультипользовательский режим и права.
Абсолютно нет, потому что в бесконтурном графе права доступа реализуются ещё легче, у каждого пользователя своя подструктура общей структуры, ведь мы можем делать сколько угодно копий одной и той же папки, не размножая файлы в ней, просто для каждого пользователя она будет иметь разный набор из этой папки понимаешь? Каждый сидит в своём загончике, у которого нету просто адресного пространства для других загончиков, ведь "папка" это файл с ссылками на файлы и другие ссылки, транслирующиеся в номера на линейном массиве диска с доступом за О(1). У тебя права доступа уже считай интегрированы в структуру, просто каждый пользователь имеет свою точку входа.
Возможно нужно смотреть ещё дальше, я обдумывал это. А в каком месте блочные файловые системы "блочные"? То что файлы раскиданы по папкам или что? Я так и не понял.
Но если смотреть ещё дальше то для удовлетворения сетевой распределённости система вообще должна быть в виде семантической сети/гиперсети(гиперграф - файловая система содержащая файловые системы или структуру файловых систем).
Я так понял в объектной сети всё хранится на линейном массиве, а структура контекстов хранится где-то в другом месте, или в нём же но по ключевому стандартному адресу?
Чем плохи блоки и опиши пожалуйста что могут объекты на иллюстративном примере чего не могут блочные.
Да собственно это я и имею ввиду. Топологически отсортированный бесконтурный граф с нескольким корневыми каталогами для каждого пользователя. Таким образом это ориентированная сеть у которой есть множество входов и выходов в виде файлов или пустых папок.
Это костыли. Хоть и рабочие. Программы могут обходить их аналогично папкам. Но нужно всякий раз учитывать какая это ссылка, что геморно как для пользователя, управляющего хранением файлов так и для написания программ.
inb4 что в бумажная папка не может быть вложена в несколько папок...
Монтирование для кого придумали?
Да а ещё мягкие ссылки не защищены от ЦИКЛИЧНОСТИ.
Ты можешь в папке создать ссылку на предка и пиздец при попытке обхода. Создашь гденибудь цикл и ебись потом. СИстема должна проверять отсутствие циклов.
Так что шахимат симлинки и мягкие ссылки НЕ ВЫХОД из ситуации.
Что монтирование то блядь? Куда нахуй? Вытащи хуй изо рта блядь когда людям пишешь. И пойми суть вопроса прежде чем высираться случайными предложениями.
Поясни пожалуйста что такое "блочная" ФС и как выглядит "неблочная". В чём проявляется блочность. У нас в любой файловой системе есть терминальная сущность(неописываемая ФС) это контент. Какая ещё может быть философия хранения данных кроме как ни по папкам(контекстам)?
>Ты считываешь GiantBoobs-67.jpg или ОчтётПетровичаб2009.doc разом
Как ты ещё собрался их считывать? Контент это терминальная сущность. Разве нет?
>В объектной фс ты не связан по рукам и ногам иерархией каталогов, ты без всяких костылей можешь поверх неё реализовать и графовую структуру, и структуру по тэгам/метаданным. Осталось лишь заставить корпоратов смасштабировать их до домашнего железа.
Мы и так не связаны ничем, данные на диске разбросаны хаотично и только ссылки придают им порядок. В чём проблема сделать ссылки произвольнее для ромбической структуры и как это помешает реализовать сетевое хранение?
Спермоклоун ебаный.
Даже в твоей прошивке для игор есть симлинки
Парень переиграл в сетевые хранилища и предлагает тебе ФС, где нет дерева, а каждый файл, папка (файл), устройство (файл) представлено guid\huid\uid\cid\nid\id и гига-файл с метой в ОЗУ, или свопе носителя, или втором файловом пространстве носителя с отдельной метрикой (или в единой), который пишет все эти файлы и читает их и помнит расположение всех файлов.
В точки зрения домашней системы - это стремно, у нас же не гигантские цоды, где важна выборка и можно держать в памяти терабайт сжатых мета-указателей на файлы, которые РАЗНЕСЕНЫ по куче физических носителей.
Для домашних пользователей нужен параллелизм - у нас уже в носителях стоят арм-ядра, нужно увеличивать их количество и в ФС нужны кучи файловых деревьев с защитой от коллизий. Можно еще учесть, что и в этих армах докидывают ядра NPU, вот нам и нужны сотни тысяч VPU, чтобы микроопить и параллелить процессы, прям как в видяхах.
А еще я шиз и я не пью табы уже джва дня...
Слышь мудила сафаривая, виндоугодная, любящая срать односложными предложениями, с синдромом аспергера наверное, забудь о моих тредах совсем, как после травмы головы, после тебя ещё у других пропадает почемуто желание писать в моих тредах, ты грязь этого раздела.
Спосибо за твоё разъяснение. Я так и почувствовал его недосказанность, явно не намёк на вариативность решения, а скорее наоборот.
Ну да для домашнего компа это хуйня полная как по менеджменту так и по надёжности etc оверхед по тому что не надо и недолив по тому что надо.
Архитектурно нет никаких препятствий запилить в линуксе то что я описал в этом треде, разве что придётся подправить некоторые программы, которые на ромбах могут работать неадекватно. А так большинство алгоритмов с файлами естественным образом "учитывают" ромбичность, вернее инвариантны для дерева и бесконтурного графа.
Изучи уже саму суть фс, мусорных и иерархичных. Ты с нуля решил начать с конца, и лезешь в гибридинг. Еще раз - все, что на носителе есть - это файл. И как ты выстраиваешь дальше структуру - так и будет называться такой метод компоновки и работы.
Имхо.
Опять ты.
>Изучи уже саму суть фс, мусорных и иерархичных.
Я не увидел возражений посуществу предложенного мной, поэтому не замотивирован. Да и что там изучать? Массив данных с внутренними ссылками, где пустое место это часть массива на которые нету ссылок.
>Ты с нуля решил начать с конца, и лезешь в гибридинг.
Это не является минусом вообще говоря, многие решения являются реализацией взгляда с другой стороны.
>Еще раз - все, что на носителе есть - это файл.
Снизу вверх ещё может быть, но сверху вниз никогда, потому что у тебя множество контента всегда.
Так же в мою пользу говорит тот факт что в ОСах до сих пор поумолчанию в /home лежат папки Картинки Видео Документы Музыка Загрузки и прочая не нужная дичь, может это тоже указывает на некоторую закостенелость. Может и файловую систему не перестраивают из-за недальновидности просто.
Серьёзно кто может пользоваться папками Видео и Документы в 2023м, не хватает ещё папки мп3, лол. Каталогизация по формату файла это архитупость.
>нельзя чтобы одна и та же папка лежала в нескольких папках одновременно
Ты только что ярлык
Это полумера, потому что ярлык всётаки не жёсткая ссылка и их приходится различать и держать в памяти что есть что при удалении, и ярлыки можно зациклить, чего не должно быть категорически.
Добавлю что на высоких контекстах можно дополнительно пользоваться и ярлыками с зацикливанием и прочим, допуская что существуют такие контексты, например, оба из которых являются вложением друг друга, но нужно не забывать что папки находятся на железе и учитывать работу программ с папками. А для личного пользования можно городить всё что душе угодно.
>Google Android: Mobile Safari
Как ты заебал, когда тебя уже поезд нахуй в наушниках переедет
Симлинки
Подохни от рака, мразь говноедская.
Лол, ты так с односложного рвешься, что он уже лопается. Предложи еще раз его забанить, может реально его придавят тапком на денек.
— Доктор, вот у меня почему‑то раны вокруг рта…
— М‑м, кажется, Вы едите с ножа, не пользуетесь вилкой и ложкой.
— Да? Да, это так. Но ложкой мне неудобно.
— Тогда вот Вам йод.
— М‑м, кажется, Вы едите с ножа, не пользуетесь вилкой и ложкой.
— Да? Да, это так. Но ложкой мне неудобно.
— Тогда вот Вам йод.
Весна уже прошла, откуда обострение?
помню писал диплом как раз на эту тему. под виндой такого не бло, под прыщами что то было.
> ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ
> сложная структура позволяет делать ссылки
> НЕ ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ
Ну ты выбери.
Чел там нет никакого противоречия, а вполне конкретная реализацая структуры ссылок в виде бесконтурного графа, который топологически отсортирован при отображении в браузере файлов.
>> ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ
Да эта структура сложнее но и одновременно удобнее и универсальнее ущербного дерева, вот допустим у тебя есть папка с пейзажами и папка математикой, и допустим ты насобирал фоток из летней математической школы на природе. Логично что папка с фотками оттуда должна лежать и в математике и в пейзажах потому что принадлежит обоим контекстам сразу. Дерево не позволяет это сделать это фундаментальная проблема а не у меня неудачный пример.
>> НЕ ХОЧУ БОЛЕЕ СЛОЖНУЮ СТРУКТУРУ
Она сложна ровно на столько на сколько нужно не включает в себя циклы, потому что может и существуют циклические вложения контекстов, но я такое пока не представляю, а во вторых структура должна поддерживать обход программами по нодам(папкам), и если запиливать поддержку циклов тогда ещё много чего можно понапридумывать, непонятно зачем.
>> сложная структура позволяет делать ссылки
Ссылки в любом случае есть на низком уровне.
То что предлагает анон с мягкими ссылками я уже писал не фундаментально и будет приводить к глюкам. В случае бесконтурного графа глюков не будет совсем. Усложнится правда интерфейс, просто вместо выбора жесткой ссылки и мягкой все будут жёсткими и нужно будет указывать при копировании файла, размножить его экземпляр или же просто сделать на него "ссылку" но в другой папке или в этой же.
Там должно было быть про циклы, но уже не важно.
Ты, как и многие, путаешь связи между объектами, использующие разные признаки, в том числе и связанные с техническим устройством системы, и смысловую иерархию, в которую они выстраиваются (в другом измерении). Первое не предусматривает и не задаёт второго.
Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях. Компьютер не может тебе помешать поместить свои документы в каталог «Барнаул, Алтайский край». С другой стороны, даже у владельцев файлопомоек в голове появляется некая иерархия взаимосвязей, позволяющая находить, где что лежит.
Файловое дерево на самом деле не единственная присутствующая иерархия. Например, люди на автомате пользуются типами файлов или датами и не пытаются использовать видео в качестве фото (если они хоть что-то понимают). Нарушения здесь более трудоёмки (например, можно копировать скриншоты текста вместо копирования самого текст). Имена файлов тоже содержат значимые признаки.
Кроме того, представлений файлов на практике тоже больше одного. Можно не помнить, на каком диске лежит фильм, если находишь его в общем списке торрент-клиента. Можно добавить все места хранения фото в менеджер картинок (или музыку — в проигрыватель) и пользоваться их проекциями, не думая о физическом расположении или формате.
В общем, сущности могут располагаться в файловой системе, в базе данных, на листочке в виде подписанных овальчиков. А вот иерархия сложнее, расположена в голове и только проецируется куда-то.
> и гига-файл с метой в ОЗУ, или свопе носителя, или втором файловом пространстве носителя с отдельной метрикой (или в единой), который пишет все эти файлы и читает их и помнит расположение всех файлов.
Так в NTFS ведь есть такой файл, на его использовании основана работа Everything
орнул с зумера
Нинужно. Всё равно что к молотку железный хуй приделать просто так.
Это будет полезно в 1 случае на 1000, зато меня будет бесить что у в куче "папок" внутри одни и те же подпапки.
Это будет полезно в 1 случае на 1000, зато меня будет бесить что у в куче "папок" внутри одни и те же подпапки.
> папка с пейзажами и папка математикой, и допустим ты насобирал фоток из летней математической школы на природе
Я профан, но уверен, что ваша дрочь никому не нужна. Будущее за контекстным поиском, когда все файлы лежат в одной помойке, а поиск осуществляется по содержимому.
С фотографиями и изображениями это уже работает отлично, а для текстовых файлов решения активно разрабатываются.
Такая точка зрения встречается повсеместно, но это не делает её менее глупой. Основана она на стереотипных малограмотных рассуждениях журналистов и обещаниях пресс-релизов (откуда постоянно возникает будущее время). Переформулировать её очень просто: «Проблему решать мы не будем, мы подождём, пока её решит кто-то за нас».
Нетрудно понять, что в предложенном варианте волшебный компьютер, какими бы качествами его ни наделяли зазывалы новых технологий, не организует информацию так, как надо человеку. Это человеку предлагается пользоваться тем, что есть, и не перечить тем, кто знает, как лучше. Допустим, у нас есть куча сканов чертежей. Как «отлично работающий» менеджер изображений, умеющий «найти лица на фото», нам поможет разобраться с этой «помойкой»? Ты по одной фигулечке, которую показали в лучшем виде, делаешь вывод, что все остальные фигулечки сами придут. По-моему, в этом и есть смысл рекламы.
Даже профессионального использования не надо. Не далее как вчера обычный пользователь смартфона меня спрашивал, как найти очень интересный ролик, который знакомые пересылали в Whatsapp неизвестное количество месяцев назад, а говорилось там о… Как, как? Да никак.
> Переформулировать её очень просто: «Проблему решать мы не будем, мы подождём, пока её решит кто-то за нас».
Так у тебя и проблема то какая-то смешная. Та что в оп-посте решена лет 50 назад, а та что в моем посте решается в данную секунду лучшими умами человечества.
Но ты правильно говоришь, я не буду решать проблему блять поиска файлов по контенту. Я тебе больше скажу - ты тоже не будешь. Ждём пока решат за нас.
> Допустим, у нас есть куча сканов чертежей. Как «отлично работающий» менеджер изображений, умеющий «найти лица на фото», нам поможет разобраться с этой «помойкой»?
Довольно просто. Двумерный чертеж от изображения мало чем отличается. Я почти уверен, что уже сейчас можно получить описание детали, имея фотографию чертежа.
На крайний случай у чертежей должна быть табличка с метадатой в уголке, которая тоже должна участвовать в поиске.
Нет, ты подменил сложную работу по организации иерархии, которая происходит в голове, каким-то максимально размытым «поиском файлов по контенту», а затем приписал это мне. Технические инструменты тут вторичны, и должны соответствовать задаче.
Твоя вера в то, что сейчас «лучшие умы человечества» что-то «решают» основывается всего лишь на медийном шлаке. Иначе говоря, ты повторяешь чужие глупости с умным видом.
> Нет, ты подменил сложную работу по организации иерархии, которая происходит в голове, каким-то максимально размытым «поиском файлов по контенту»
Нет, вполне конкретным "поиском по контенту", который уже хуй знает сколько лет на рынке и зарекомендовал себя как ультимативное решение.
Со всех моих устройств все изображения и видео стекаются в одну большую помойку, в которой можно свободно ориентироваться с помощью поисковой строки.
Поиск по контенту текстовых файлов существует ещё дольше. Например популярные поисковые движки этим активно пользуются.
Видео, изображение и текст покрывают 99% потребностей, для остального процента появление решения - вопрос времени.
> Твоя вера в то, что сейчас «лучшие умы человечества» что-то «решают» основывается всего лишь на медийном шлаке.
"Лучшим умам человечества" нужно что-то кушать. Вот и решают чтобы кушать было что. Это называется не вера, а логика.
С чертежами твой мозг наконец-то начал работать. Да, мы можем распознать основную надпись (если бумажная копия в приличном виде). Появилось у нас N таких наборов данных. А выше уровнем информация где? Как из этих деталей что-то собрать? Какой чертёж относится к машине, какой — к стене цеха, в котором её собирают, какой — к забору вокруг завода?
Ты сделал примитивный шажочек со своей «табличкой с метадатой в уголке», а уже стоишь наполеоном.
> свободно ориентироваться
Какое «свободно», когда ты можешь пользоваться только тем, что дали? У тебя реально «свободой» в голове названа рабская зависимость от большого дяди, а функциональностью считается её отсутствие.
> а мне больше и не надо
Что и требовалось доказать. «Пусть кто-то это делает за меня».
> Появилось у нас N таких наборов данных. А выше уровнем информация где? Как из этих деталей что-то собрать? Какой чертёж относится к машине, какой — к стене цеха, в котором её собирают, какой — к забору вокруг завода?
Запрос: "чертеж ваз 2109"
Ответ: все чертежи ваз 2109 в системе
Запрос: "чертеж стена"
Ответ: все чертежи стен
Запрос: "забор"
Ответ: чертежи заборов
Что ты хочешь то?
> Какое «свободно», когда ты можешь пользоваться только тем, что дали?
Ты дурак? Ну сейчас у тебя есть иерархическая система, ты чувствуешь себя свободным?
Да и вообще, свобода в твоем понимании вторична. Я не буду пользоваться отверткой вместо шуруповерта только потому что отверткой можно на барабане играть. Главное - получить нужный результат как можно быстрее и как можно качественнее.
> Что и требовалось доказать. «Пусть кто-то это делает за меня».
Абстрактный гринтекст абстрактно подтверждает абстрактное суждение. Очень удобно.
У тебя какое-то острое неприятие технологий. Тебя в детстве растлили тостером?
Зачем мне знать, где в системе находится отчёт за прошлые года по корректному продукту если я могу запросить "морковь отчёт 2018" и получить релевантные результаты?
> корректному
Конкретному*
быстрофикс
>Запрос: "чертеж ваз 2109"
>Ответ: все чертежи ваз 2109 в системе
>Запрос: "чертеж стена"
>Ответ: все чертежи стен
>Запрос: "забор"
>Ответ: чертежи заборов
Ясно, сиди пускай слюни на фоточки и не подходи никогда к станкам и документации.
Как минимум можно было понять, что на чертеже детали автомобиля может вообще не встречаться название автомобиля (в том числе потому, что она была спроектирована ещё до его создания).
> Как минимум можно было понять, что на чертеже детали автомобиля может вообще не встречаться название автомобиля (в том числе потому, что она была спроектирована ещё до его создания).
Ну и ладно, пускай не встречается. Зато в документации автомобиля встречается название всех деталей, из которых он состоит, поиск все равно выдаст верный результат. Это буквально удобнее и быстрее. Тебе придется этим пользоваться.
Этот момент я продумал и файловый менеджер должен состоять из папочного графического браузера, чтобы можно было человеку обойти папки по маршруту и окно с файлами.
Да ты профан. Потому что контекстная зависимость очень существенна в программах, тебе может понадобиться один и тот же ресурс разными программами и разные ресурсы могут включаться в одну и ту же программу, в дерево ты никак этот зоопарк не засунешь, именно поэтому большинство пакетов имеют настолько ЕБАНУТЕЙШУЮ контекстную зависимость, требуют makefilы с компоновщиком, также пакетный менеджер - костыль по этой же причине и не нужен. Даже в Си++ есть поддержка ромбического наследования классов потому что ты никогда не знаешь что тебе понадобится и с какого "этажа", лерево это ущербная структура говна, из-за которой нету утилитарного порядка для технического уровня хотябы.
Файловая система не меняется, меняется интерфейс взаимодействия пользователя с ней.
Ну так я об этом и говорю, что на уровне файловой системы ничего не поменяется если сделать бесконтурный граф вместо дерева, и браузер красивый к нему, где атлас из нод с названиями и окошко с содержимым ноды.
Все сущности в мире хорошо укладываются в иерархию (не древовидную) контекстов, которые могут пересекаться и перекрываться произвольно и существуют они в любом случае умозрительно, категоризация узлов машины чисто ситуативная интерпретация значимости и другим может быть задана в совершенно другом виде ну это в теории. Теперь что касается самих программ то там всё однозначно и железно, программы ссылаются на другие в произвольном порядке и поэтому папки так же должны естественно поддерживать и иллюстрировать эту произвольность, и в программах ты не задашь семантический поиск, потому что программа должна чётко находиться в каталоге и других вариантов нет. Поэтому проблема фундаментальна и попытки сослаться на супертехнологии по сути уход от этой проблемы. Компьютер в любом случае утилитарный(всмысле не терминальный) инструмент и надо всегда это учитывать при использовании а не то что компьютер автоматизирует всё на свете и даже не надо будет жить и умирать.
Не виляй жопой. Изначально я ответил на пост.
> допустим у тебя есть папка с пейзажами и папка математикой, и допустим ты насобирал фоток из летней математической школы на природе. Логично что папка с фотками оттуда должна лежать и в математике и в пейзажах потому что принадлежит обоим контекстам сразу.
И в разговоре о пользовательских файлах очевидны преимущества каталогизации и поиска по контексту.
>Не виляй жопой. Изначально я ответил на пост.
Ты предложил технологический оверхед из говна вместо фундаментального алгоритмического решения работающего внезависимости от погоды.
>И в разговоре о пользовательских файлах очевидны преимущества каталогизации и поиска по контексту.
Неочевидны. У тебя не тысячи триллионов папок на компе создаваемых автоматически. Контекстный поиск подразумевает и полностью автоматизированное контекстное управление создание значимых папок, опционально удаление незначимых, ты городишь хуйню на ровном месте изначально невыполнимую за разумные сроки. Хранение файлов НЕЛЬЗЯ автоматизировать ВООБЩЕ НИКАК это чисто умозрительная хрень, это всёравно что пытатться автоматизировать жизнь, тоесть никогда.
Для сетевого хранилища гдето в говнооблаке ещё можно сделать подобное, но вопервых частично уже такое есть и я бы тогда поднял вопрос именно об этом, но экономия пространства не основная проблема, основная это связность лучше 1 большой файл чем триллион маленьких в дереве папок например. Путь к файлу это тоже информация, и лучше чтобы она была удобной, а не хуйпоймикакая базаданных.
Проебался с номером но не суть.
> Ты предложил технологический оверхед...
Я предложил решение, позволяющее получить результат быстрее и удобнее чем папочки с ярлычками.
> Хранение файлов НЕЛЬЗЯ автоматизировать ВООБЩЕ НИКАК это чисто умозрительная хрень, это всёравно что пытатться автоматизировать жизнь, тоесть никогда.
Уже.
Ты не прав
Меня не ебет где файл лежит, если я могу в любой момент получить к нему быстрый доступ
>Я предложил решение, позволяющее получить результат быстрее и удобнее чем папочки с ярлычками.
Нет.
>Уже.
Учёный изнасиловал журналиста опять.
>Меня не ебет где файл лежит, если я могу в любой момент получить к нему быстрый доступ
Чел ты занимаешься абстрактным флеймом. Программам похуй на что похуй тебе, они работают с переменными а не с твоими хотелками. А организовать файлы на компе можно и вручную главное, чтобы файлменеджер был поинтерактивнее и пографонистее, что позволит раскидывать и искать файлы просто двигая тазом как ты хочешь, но видишь решение не в той плоскости совсем.
> Программам похуй на что похуй тебе, они работают с переменными а не с твоими хотелками.
Поконкретней можно пожалуйста? Ну вот существует программа в некоторой директории. Условный компас. В чем проблема по твоему мнению заключается?
Я топлю за то, чтобы когда в компасе нажимаешь кнопку "открыть файл" не приходилось вручную искать путь до файла в проводнике. То есть ты пишешь "чертеж вибратор длинный", выбираешь файл из подходящих под запрос и его открываешь.
Проводник в это время ищет по индексированным файлам и путь выбранного файла предоставляет компасу.
Компас же в свою очередь при создании нового файла кидает его куда-то в свою директорию или в документы (в общем то и не важно куда), и этот файл потом точно также можно будет найти.
Все остается как прежде, только теперь процесс поиска пути до нужного файла вместо пользователя выполняет проводник с помощью пиздатого поиска.
Теперь пальцем покажи мне блять где находится проблема с переменными. Пускай директории и пути станут внутрисистемным явлением, которые пользователь ни разу в жизни не увидит. В принципе к этому все и идет, если обернуться на смартфоны. Последний раз на телефоне искал файлы по файловой системе руками года три назад.
При чем добавлю, что гугл делает просто километровые шаги в эту сторону. Их облачный офис как и фотографии уже работают по такому принципу, а это я напоминаю текст, изображения, видео, таблицы и презентации. 99% потребностей мимокрока.
Ну и конечно вводиться подобная система будет не одну пятилетку. Сначала облачный поиск по домашней папке пользователя, потом локальный поиск на мощном железе, самой первой директории полностью из проводника уберет эпл в свой мак оси и так далее.
>Поконкретней можно пожалуйста? Ну вот существует программа в некоторой директории. Условный компас. В чем проблема по твоему мнению заключается?
>Я топлю за то, чтобы когда в компасе нажимаешь кнопку "открыть файл" не приходилось вручную искать путь до файла в проводнике. То есть ты пишешь "чертеж вибратор длинный", выбираешь файл из подходящих под запрос и его открываешь.
>Проводник в это время ищет по индексированным файлам и путь выбранного файла предоставляет компасу.
>Компас же в свою очередь при создании нового файла кидает его куда-то в свою директорию или в документы (в общем то и не важно куда), и этот файл потом точно также можно будет найти.
>Все остается как прежде, только теперь процесс поиска пути до нужного файла вместо пользователя выполняет проводник с помощью пиздатого поиска.
Программа просто его не находит, или находит запустив комп на орбиту.
Не важно какие файлы ты хранишь и сколько, они всёрвно должны быть сгруппированы как ни крути, иначе ты просто не спожешь освобождать пространство или доверишь это программе? А какие будут критерии удаления? Фотограффи 20 летней давности и архивы программа удалит за незначимостью твои действия? Схема размещения в любом случае должна быть сбалансированной как "сверху" со стороны человека, так и со стороны железа "снизу". То что ты предлагаешь не подходит
для системы с полным контролем, тоесть домашней пеки.
Уже есть готовая структура технически удовлетворяющая обоим подходам вот и всё.
Ты открываешь компас нажимаешь открыть файл,идёшь в папку "петухиназоне" там куча фотографий копипасты видос, ты выбираешь чертёж петуха. Если ты его закинул куда-то не туда, не в тот контекст, то земля тебе пухом. Все.
В твоём же случае поиск будет производиться из мешанины файлов наличие которых ты вообще не можешь быть уверен, чего ты не учёл.
>Теперь пальцем покажи мне блять где находится проблема с переменными.
С ними никакой проблемы как раз нету, просто нужно вовремя адекватно раскидывать файлы по контекстам, за тебя это никто не сделает. В итоге у тебя в каждом контексте не так уж много файлов, а сам атлас контекстов(папок) открывается в графике файлменеджера. Я могу создать любой контекст вообще и ни одна программа вообще не будет ебать что искать совсем.
Гугл зарабатывает бабки, без которых их системы просто дорогой обогреватель. Это временные решения на отъебись а не на столетия.
Да изображения так можно искать, но он не свяжет в один контекст песню и фотографию чувака или чертеж петуха который он сделал. Да и вообще всё может пойти не так в любой момент из-за хуй пойми каких причин, нейросети нестабильная машина.
Это будет ебейший оверхед по энергопотреблению для какойто бытовой хуйни. Давайте ещё майнерскую сеть запустим для поиска файлов, а чё инновационно ёпта. Ты не забывай для чего нужна цифровая машина. Она не для этого пилилась вообще. То что она используется для удобства небольшой бонус.
лол дегрод хочет магическое хранилище с функцией "найди то не знаю что там незнаю где вот прямо сейчас ты же компьютер в конце концов"
> Программа просто его не находит
Какая программа? Проводник? Сейчас же поиск работает, просто добавить туда контент.
> Не важно какие файлы ты хранишь и сколько, они всёрвно должны быть сгруппированы как ни крути, иначе ты просто не спожешь освобождать пространство или доверишь это программе?
> А какие будут критерии удаления? Фотограффи 20 летней давности и архивы программа удалит за незначимостью твои действия?
Делаю запрос "большие файлы неиспользуемые больше трех лет" если очень нужно что-то удалить.
Но я буквально чищу только папку загрузок раз в несколько месяцев, все остальное лежит в архиве. Твердый гигабайт сколько сейчас стоит? 5 рублей?
> Если ты его закинул куда-то не туда, не в тот контекст, то земля тебе пухом. Все.
> С ними никакой проблемы как раз нету, просто нужно вовремя адекватно раскидывать файлы по контекстам, за тебя это никто не сделает.
У - Удобство.
> В твоём же случае поиск будет производиться из мешанины файлов наличие которых ты вообще не можешь быть уверен, чего ты не учёл.
"Нет релевантных результатов, возможно вы имели в виду..."
Да и охуеть, а ты уверен что существует файл в твоей директории? Как ты это проверишь, откроешь директорию "чертежи дилдаков"? Так и вбей в поиск "чертежи дилдаков", и глянь есть файл или нет.
> Это временные решения на отъебись а не на столетия.
Как и поисковые системы, расскажешь.
> Это будет ебейший оверхед по энергопотреблению для какойто бытовой хуйни.
Ну да, ты же 4090 не покупаешь только потому что она электричества жрет слишком много.
Да и глядя на современные arm процы с копеечным энергопотреблением...
> Да изображения так можно искать, но он не свяжет в один контекст песню и фотографию чувака или чертеж петуха который он сделал.
Схуяли? Ты скозал?
> лол дегрод хочет магическое хранилище с функцией "найди то не знаю что там незнаю где вот прямо сейчас ты же компьютер в конце концов"
Ну да, как в офисе от Гугла. Так и хочу. Это удобно.
"найди то не знаю что там незнаю где вот прямо сейчас ты же компьютер будь человеком"
лолд
Ну да, в эту сторону и движутся технологии в 2023 году. Сегодня можно с компьютером разговаривать на человеческом языке и получать человеческий ответ человеческими звуками. В удивительное время мы живем.
>добавить туда контент.
добавить проще в папку, вернее чуть сложнее из-за выбора контекста куда этот контент кинуть, но и поиск дрочить не нужно.
>Делаю запрос "большие файлы неиспользуемые больше трех лет" если очень нужно что-то удалить.
Ога и поошибке удаляешь лишнее то что не предвидел удалять.
>Твердый гигабайт сколько сейчас стоит? 5 рублей?
Дело совсем не в Гигабайтах, совершенно похуй на них а дело в количестве файлов и скоростью доступа к ним и вообще со всяким взаимодействием с ними.
>У - Удобство.
Н-Надёжность.>Удобство.
>Да и охуеть, а ты уверен что существует файл в твоей директории?
Конечно уверен я же не долбаёб. Компьютер это инструмент всеголишь. Без человека он бесполезен.
>Как и поисковые системы, расскажешь.
Да с поиском говна уже плохо справляется. Поиск в 2023м ну такое. За семантическими сетями будущее.
>Ну да, ты же 4090 не покупаешь только потому что она электричества жрет слишком много.
>Да и глядя на современные arm процы с копеечным энергопотреблением...
Я лучше поиграю на 4090, чем буду нагружать видяху говнопоиском, с чем мой мозг тоже справляется.
>Схуяли? Ты скозал?
Я сделаю специально так чтобы не смогла. Вопросы?
>Ну да, как в офисе от Гугла. Так и хочу. Это удобно.
Не путай корпоративные практики с частными. Хотя если у тебя свой суперкомп то твоё дело.
В удивительное в удивительное, ты как в том ролике советском, батарейки(полные чемоданы) от часов не забудь.
> чуть сложнее из-за выбора контекста куда этот контент кинуть, но и поиск дрочить не нужно.
В этом и смысл, меньше телодвижений для лучшего результата.
> Ога и поошибке удаляешь лишнее то что не предвидел удалять.
Ну и сделай запрос точнее, это мелочи и тонкости реализации.
> Дело совсем не в Гигабайтах, совершенно похуй на них а дело в количестве файлов и скоростью доступа к ним и вообще со всяким взаимодействием с ними.
Я не представляю насколько должен быть большой объем данных чтобы влиять на производительность. Сейчас винда ищет по миллионам индексированных файлов за секунду.
> Н-Надёжность.>Удобство.
Пока что единственный довод против. Проблема надёжности крайне значительна. Даже интересно как ее решать будут.
> Конечно уверен я же не долбаёб. Компьютер это инструмент всеголишь. Без человека он бесполезен.
Ну значит и я уверен, что в помойке лежит нужный файл, я же не долбоёб.
>В этом и смысл, меньше телодвижений для лучшего результата.
>Ну и сделай запрос точнее, это мелочи и тонкости реализации.
Ясно.
>Я не представляю насколько должен быть большой объем данных чтобы влиять на производительность. Сейчас винда ищет по миллионам индексированных файлов за секунду.
Влияет на поиск человеком если файлы раскиданы несбалансированно триллиардами в одной папкопомойке.
>Пока что единственный довод против. Проблема надёжности крайне значительна. Даже интересно как ее решать будут.
Да никак, забьют хуй как и всегда, придумав прагматичное решение в виде "категории хранения" или чего то в этом духе будет rolling release хранилище для всякого говна типа мемчиков видосов с алкашнёй порнухой копипастами и тд, проебалось что-то да и хуй с ним, новое придёт, сохранять на домашний комп надо было, в тырнэте каждый день как последний, извольте.
>Ну значит и я уверен, что в помойке лежит нужный файл, я же не долбоёб.
Ты не уверен что комп не долбаёб. А я уверен.
> >В этом и смысл, меньше телодвижений для лучшего результата.
> >Ну и сделай запрос точнее, это мелочи и тонкости реализации.
> Ясно.
Это все ещё удобнее и быстрее, чем думать в какой каталог положить файл, а потом спустя год вспоминать в каком каталоге он лежит.
А если учитывать затрачиваемые силы и время на продумывание иерархии, на создание системы ссылок, на поддержание порядка (ты ведь не можешь моментально сохранить документ на рабочий стол, тебе нужно прописывать пусть), на прописывание адекватных названий файлов, на настройку синхронизации файлов и т.д и т.п.
Нет, спасибо, я деньги за эвм отдаю чтобы упрощать себе работу, а не усложнять.
> Влияет на поиск человеком
Поиск осуществляется не человеком, а проводником. В идеале компьютер должен предлагать файлы в зависимости от ситуации и без поиска (если у тебя рабочий день по расписанию - в проводнике выводится список файлов по текущей рабочей задаче), но учитывая как ты копротивляешься обычному поиску, от такой концепции у тебя вообще пердак оторвет.
> файлы раскиданы несбалансированно триллиардами в одной папкопомойке.
Во-первых, с технической точки зрения компьютеру глубоко до пизды на количество файлов в директории.
Во-вторых, индексация была придумана хуй знает сколько лет назад, я даже не против если придётся докупить лишние 8-16-32 гб ОЗУ, чтобы держать в быстром доступе все пути до индексируемых файлов и их контекстное описание до кучи. Это копейки по сравнению с преимуществами.
> Да никак, забьют хуй как и всегда
Ты то точно знаешь, что забьют. Прибыль будут терять, но точно выпустят говно. Потому что идейные пидорасы, верно?
Боже, настоящая жертва рекламы. Человек, который верит даже не в богов, а в обещания маркетологов.
То, что твои задачи решаются вводом нескольких слов в Google™, означает не то, что поисковик обладает волшебными качествами, а то, что твои задачи не выходят за рамки предлагаемых решений. Как только упрёшься в ограничения — поймёшь. Образно говоря, людям, которых устраивает радиоприёмник с двумя кнопками, в котором на первой играет Басков, а на второй — Круг, бесполезно объяснять, что можно самостоятельно искать и выбирать музыку, иметь собственный вкус. Сегодняшние популярные сервисы как раз построены на том, чтобы создать иллюзию неограниченных возможностей, предложив человеку тупой телевизор, в который можно втыкать.
Вот тебе для общего образования 600 страниц разборок по поводу муфт в системе, в которой были и схемы, и правила, и инструкции, и наказание за нарушения, и всё равно оказалось, что всё не так, и держалось на здравом смысле работников.
https://www.gov.uk/government/publications/the-nimrod-review
А ты предлагаешь просто тыкать в компьютер и не думая делать то, что он скажет. При этом давно обсуждается, например, что подготовленные пилоты, всего лишь автоматизировавшие некоторые действия, хуже понимают процесс полёта и хуже разбираются с ситуациями, когда что-то идёт не так.
Дай сам пдф, меня кикает.
>Это все ещё удобнее и быстрее, чем думать в какой каталог положить файл, а потом спустя год вспоминать в каком каталоге он лежит.
Ну мне приходится не то чтобы долго думать куда кинуть файл, сколько просто ограничивать себя в хранении всякого хлама.
>продумывание иерархии
Она возникает почти естественным образом.
>прописывание адекватных названий файлов
Забиваю хуй либо оно уже прописано за меня.
>Поиск осуществляется не человеком, а проводником. В идеале компьютер должен предлагать файлы в зависимости от ситуации и без поиска (если у тебя рабочий день по расписанию - в проводнике выводится список файлов по текущей рабочей задаче), но учитывая как ты копротивляешься обычному поиску, от такой концепции у тебя вообще пердак оторвет.
Если бы на марсе росли грибы... Информации будет всегда больше чем возможности её обработать. Этой возможности всегда будет нехватать. Это вообще даже философская проблема уже.
Допустим у меня есть папка с сойжаками и я хочу её отсортировать по постироничности и кринжовости. или ещё по хуй пойми какому умозрительному качеству. Да автоматический семантический поиск и разметка был бы тут кстати в самый раз. Но если для тебя сортировка и доступ к файлам на собственном диске недоступен так же как к файлам в интернете, а только через поиск, то не проще ли все такие вещи хранить в тырнете в семантической сети с автометаданными, которая как раз НЕ энергозатратна вотличие от нейросети для анализа помойки, это по сути журналируемая ФС. Где люди сами выполняют роль квазинейросети, а комп просто за них всё прокликивает дополнительно как нужно, а диск своей машины испольховать только для самого нужного. В любом случае машина не должна заменять человека а скилы быть выше определённого порога чтобы не захламляться.
>Во-первых, с технической точки зрения компьютеру глубоко до пизды на количество файлов в директории.
Нет ему не до пизды.
>Во-вторых, индексация была придумана хуй знает сколько лет назад, я даже не против если придётся докупить лишние 8-16-32 гб ОЗУ, чтобы держать в быстром доступе все пути до индексируемых файлов и их контекстное описание до кучи. Это копейки по сравнению с преимуществами.
Это опять же проблема доступа к своми файлам, если ты можешь их получить только через поиск то не похуй ли где они лежат на диске или в интернете? Если у тебя их триллионы картинок с сойжаками к примеру?
>Ты то точно знаешь, что забьют. Прибыль будут терять, но точно выпустят говно. Потому что идейные пидорасы, верно?
Не понял это твоё предложение.
> просто ограничивать себя
Очень просто.
> >продумывание иерархии
> Она возникает почти естественным образом.
> >прописывание адекватных названий файлов
> Забиваю хуй либо оно уже прописано за меня.
И как, удобно?
> Информации будет всегда больше чем возможности её обработать. Этой возможности всегда будет нехватать. Это вообще даже философская проблема уже.
Это ты сказал? Ты собрался всю информацию мира обрабатывать?
> Но если для тебя сортировка и доступ к файлам на собственном диске недоступен так же как к файлам в интернете, а только через поиск, то не проще ли все такие вещи хранить в тырнете в семантической сети с автометаданными, которая как раз НЕ энергозатратна вотличие от нейросети для анализа помойки, это по сути журналируемая ФС.
Да, проще, так еще и синхронизировать между устройствами так удобнее, но это к локальной системе отношения не имеет.
> диск своей машины испольховать только для самого нужного
В семантической сети, да. Русский поиск по директориям все ещё не нужен.
> Нет ему не до пизды.
Компьютеру до пизды, а вот софту, который пытается ими оперировать - нет.
Например, тот же everything показывает все файлы в одном списке и ничего, не зависает.
> Это опять же проблема доступа к своми файлам, если ты можешь их получить только через поиск то не похуй ли где они лежат на диске или в интернете? Если у тебя их триллионы картинок с сойжаками к примеру?
Я пытаюсь донести, что в принципе похуй где они лежат, если я их могу получить. Но мир не идеален и если интернет отвалится должен быть набор данных, доступных локально.
>Очень просто.
>И как, удобно?
Ну да в совоём диске не потеряешься же.
>Это ты сказал? Ты собрался всю информацию мира обрабатывать?
Ну это так как ни крути. Про множество подмножеств что-нибудь слышал? Что оно больше самого множества, вот это аналогично. Так что проще всего если обрабатываться информация будет автоматически с помощью предпочтений человека. А тратить на это видеокарты нерационально.
>Да, проще, так еще и синхронизировать между устройствами так удобнее, но это к локальной системе отношения не имеет.
С одной стороны да, с другой у дохуищи людей одни и те же данные которые можно было бы хранить оптимальнее, тоесть часть диска можно вполне отдать под такую сеть.
>Компьютеру до пизды, а вот софту, который пытается ими оперировать - нет.
>Например, тот же everything показывает все файлы в одном списке и ничего, не зависает.
Ок, хорошо если так.
С чего бы это, обычная ссылка вроде. У Веб-архива с ней проблем нет:
http://web.archive.org/web/20230215000000*/https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/229037/1025.pdf
Но ведь существуют ссылки, с помощью которых нетрудно сделать так, чтобы одна и та же папка лежала в нескольких папках одновременно.
> В идеале компьютер должен предлагать файлы в зависимости от ситуации и без поиска (если у тебя рабочий день по расписанию - в проводнике выводится список файлов по текущей рабочей задаче)
В меню Пуск семерки примерно так и было сделано. На первой странице список часто используемых приложений, наводишь курсор на приложение - и справа появляется список последних документов с которыми ты работал через это приложение. У меня эта система довольно быстро формировала список под мою текущую рабочую задачу, и я практически никогда не шарил по дискам в поисках нужного файла, даже забыл что у меня где лежит...
Ты ставишь неверные акценты если считаешь что комп может заменить тебя самого при юзании компа. Это концептуально неверно. Комп по крайней мере классический был и навсегда останется ИНСТРУМЕНТОМ помощником, и попытки сделать из него терминальную(в смысле не утилитарную) сущность заведомо провальная и мёртворождённая идея, комп всегда проекция человеческих идей, но не замена и не синтез их, это к слову к тому почему никогда не взлетят все эти метавселенный и иже с ними. То что тебе помогло меню лишь удачное стчение обстоятельств но такие надстройки можно делать бесконечно с около нулевым приростом удобства. Так что не нужно. Я как программист в рот ебал писать очередное по лишь бы бзерододик мог не думать над цветом дилдака и получил его в выдаче компа.
Да ещё ты не учёл того что для этой "удобной выдачи" ты создаёшь лишнюю сущность в виде функции такой удобной выдачи, а сколько ещё таких критериев удобства можно насоздавать? Думать что будет ИИ делающий выбор за тебя так себе идея.
>справа появляется список последних документов с которыми ты работал через это приложение. У меня эта система довольно быстро формировала список под мою текущую рабочую задачу, и я практически никогда не шарил по дискам в поисках нужного файла, даже забыл что у меня где лежит...
У меня не помойка на диске, а идеальный порядок, ну не совсем из-за ущербности древовидной структуры, что у меня и так всё находится само как нужно.
Ага, а для каждого файла общесистемной библиотеки мы храним по две тысячи путей до него. Ядро линукс занимает примерно 800 гб, а при установки каждого дополнительного пакета оно скейлится по экспоненте. Спасибо, не надо.
> по ошибке
Древовидная структура, простая и понятная иерархия.
>нельзя чтобы одна и та же папка лежала в нескольких папках одновременно
Можно, даже больше, можно чтобы несколько версий файла хранились одновременно. Называется CoW файловая система. То что ты хочешь решается дедубликацией, файловая система автоматически заменяет одинаковые файлы на ссылки.
>Из-за этого ведь и приходися пакетный менеджер использовать чтобы он все пакеты топологически отсортированными держал у себя, но это костыль.
Причем тут пакетный менеджер нах
>Где есть форум где сидят разрабы линукса
Мхех
Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.
Когда придумали папки, тогда же придумали и ярлыки, попробуй, довен. Есть ещё и симвполческие ссылки, тоже попробуй.
>Ага, а для каждого файла общесистемной библиотеки мы храним по две тысячи путей до него.
Пути нигде не хранятся, долбаёб тупой, если только не конкретное назначение да и не все пути, которыми можно прийти к файлу нужны.
>Ядро линукс занимает примерно 800 гб, а при установки каждого дополнительного пакета оно скейлится по экспоненте. Спасибо, не надо.
Дальше вытекающий из предыдущего твоего бреда словесный дрищ.
>Древовидная структура, простая и понятная иерархия.
Не ну а чё давайте и дорожную сеть в странах и везде вообще сделаем древовидной, понятно же хули. Даже маршрутизация мирового интернета между странами не древовидная.
>Можно, даже больше, можно чтобы несколько версий файла хранились одновременно. Называется CoW файловая система. То что ты хочешь решается дедубликацией, файловая система автоматически заменяет одинаковые файлы на ссылки.
Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.
>Причем тут пакетный менеджер нах
Притом что ему приходится хранить виртуальные каталоги зависимостей программ искусственно внутри себя когда это можно сделать естественно и без костылей.
>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.
Она нужна, но будут большие проблемы при перелопачивании всего существующего бардака в нормальный вид, поэтому такой копиум что не сильно то надо дескать. Но ты чувствуешь жопой что надо и придётся и чем раньше тем меньше будет ебли по экспоненте. Сейчас впринципе покачто можно сказать софта то и нет под линуксом, сделать уборку ничего не стоит. Собственно из-за древовидной структуры софта то и нет, проблема помогает сама себе, лол. Мы живём как алкаши в бардаке где куча бутылок и приходится спать в одежде на кровати, не надо так.
>Когда придумали папки, тогда же придумали и ярлыки, попробуй, довен. Есть ещё и симвполческие ссылки, тоже попробуй.
Не хочу не буду. Объектная нотация не просто так придумана и нужна в том числе программам и должна поддреживаться файловой системой.
> Пути нигде не хранятся, долбаёб тупой
Да иди ты нахуй со своим троллингом
https://unix.stackexchange.com/questions/360745/where-are-file-directory-entries-for-subdirectories-stored
Если нужно будет обойти все ноды твоей этой хуйни, ты будешь маркером на листочке помечать где ты был, а где нет? Или будешь круги нахуячивать пока электричество не кончится?
Если у тебя изолированная ветка узлов образуется, которая с рутом не связана, ты как ее искать будешь? Или полностью всю ветку будешь удалять?
Ты не подумай мне просто интересно как ты это видишь.
>Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.
Ну вот разберешься, создашь ещё один тред.
Доказательство привёл ты которое, оно неправильное, потому что там задаётся вопрос о том где хранится папка, тоесть ссылка на неё, а папка != путь к папке.
Ну алгоритм обхода графа, состояния хранятся о посещённых папках даже при поиске в ширину. Не вижу никакой проблемы, граф то ОРИЕНТИРОВАННЫЙ, там нет циклов, и войдя в одно из начал, ты за конечное число шагов прийдёшь в один из концов.
Топологически отсортированный граф располагает все ноды по "этажам", как формируются эти "этажи" зависит от критерия, но обычто чтото вроде ближайшего старшинства, тоесть если папка принадлежит нескольким папкам с разных этажей то она находится на самом нижнем +1 этаже, к примеру. Обойти такой граф не должно быть чем то сложным. Я думаю пакетный менеджер этим занимается постоянно.
Я уже разобрался это не то потому что позволяет только делать один и тот же файл в разных папках, а надо чтобы и одни и те же "папки" тоже могли быть в разных 2папках".
>Доказательство привёл ты которое, оно неправильное, потому что там задаётся вопрос о том где хранится папка, тоесть ссылка на неё, а папка != путь к папке.
То есть я имею ввиду что сама папка есть ссылка, НО в массиве (блин, цилиндр, сектор), а путь к папке, собственно последовательность таких ссылок, если они имеется, именно поэтому если ты проебёшь папку, ты её больше не найдёшь в этом массиве, потому что не будешь знать что и где лежит, а знаешь ты только благодаря структуре файловой системы.
Концептуально поясню всётаки для треда, я сейчас уточнил, про мягкие и жёсткие ссылки.
У нас есть абстрактно МАССИВ низкоуровневый машинный, где хранится чтото. Файловая система в нашем случае надстройка, которая в данных хранит ссылки на другие данные по МАССИВУ, а не по файловой системе.
Жесткая ссылка это ссылка на инфу в машинном массиве.
Мягкая ссылка это ссылка на инфу внутри файловой системы, а не на машинном массиве, которая уже содержит ссылку на ячейку в машинном массиве. Вот так вот костыльно, тоесть вместо прямого указания "места на парковке", тебя заставляют бегать по другим адресам пока в машине не будет собственно адреса назначения.
У нас есть абстрактно МАССИВ низкоуровневый машинный, где хранится чтото. Файловая система в нашем случае надстройка, которая в данных хранит ссылки на другие данные по МАССИВУ, а не по файловой системе.
Жесткая ссылка это ссылка на инфу в машинном массиве.
Мягкая ссылка это ссылка на инфу внутри файловой системы, а не на машинном массиве, которая уже содержит ссылку на ячейку в машинном массиве. Вот так вот костыльно, тоесть вместо прямого указания "места на парковке", тебя заставляют бегать по другим адресам пока в машине не будет собственно адреса назначения.
>Жесткая ссылка это ссылка на инфу в машинном массиве.
Минуя уже файловую систему и какбы выходя за пределы, отказываясь от её функции.
Правильнее было бы это назвать низкоуровневой или машинной ссылкой, но пафосные дебилы в любой области любят придумывать ебанутые "метафизические" названия чтобы нихуя не понятно было. Во всех областях так к сожалению.
>Следствием механизма жестких ссылок Linux является то, что удаление жесткой ссылки на файл не приводит к удалению самого файла из системы при наличии у этого файла других жестких ссылок (имен файла). И это понятно, так как все жесткие ссылки равны между собой, независимо от времени создания, местонахождения в структуре каталогов.
>Несмотря на возможности, которые предоставляют жесткие ссылки, у них есть ограничения:
их можно создавать только на файлы, но не на каталоги;
жесткую ссылку нельзя создать на файл, находящийся на другом диске.
> их можно создавать только на файлы, но не на каталоги;
Наверное в этом то и проблема скорее всего.
Я только одного не понял. Ссылки на "папки" всегда мягкие чтоли, тогда этот получается прав, тогда почему не реализовано на программном уровне недопущение циклов и формирование того что я написал выше. Получается проблема проще чем кажется.
>Несмотря на возможности, которые предоставляют жесткие ссылки, у них есть ограничения:
их можно создавать только на файлы, но не на каталоги;
жесткую ссылку нельзя создать на файл, находящийся на другом диске.
> их можно создавать только на файлы, но не на каталоги;
Наверное в этом то и проблема скорее всего.
Я только одного не понял. Ссылки на "папки" всегда мягкие чтоли, тогда этот получается прав, тогда почему не реализовано на программном уровне недопущение циклов и формирование того что я написал выше. Получается проблема проще чем кажется.
Имхо за 3.14 фс-подобными системами и тонкими клиентами, подключающимися к вычислительным кластерам мелкомягких будущее, хотя хз когда эта дистопия настанет
НИКОГДА. Компьютер, по крайней мере цифровой, был и останется инструментом, как ручка и блокнот одежда и тп. Лучше смени отношение и акценты.
Так я и не говорю, что это пиздато, лол. Просто в ближайшем будущем мы будем хавать сверчков и арендовать компьютеры может в рашке запилят аналоговнетный аналог этого дерьма через яндекс спустя 10 лет после того, как оно станет популярно в европе, так что запасайся хардаками, аноний
>Ссылки на "папки" всегда мягкие чтоли,
Вообще если это так то это пиздец как тупо, как с аппаратной стороны, так и с человеческо интерфейсной.
Нет ну если прямо так уж нужна надёжность можно создать синхронизированный "виртуальный" каталог с дескрипторами и прочей служебкой, туда же можно закинуть Downloads кстати говоря, концептуально.
Не взлетит, как и соцсети.
Можно запилить распределённую фс на похожем принципе, только машинные адреса на низком уровне будут включать в себя ещё и на других устройствах через сеть.
А ещё из-за ёбаного дерева папок придумали такое ненужное говно как компоновщик, КОМПОНОВЩИК блеать. Вместо того чтобы компоненты сами собирались по лямбда путям, ты пишешь makefile блядь, где скриптами дублируешь всю ту умозрительную хуйню которая должна была бы содержаться в структуре каталогов/дирректорий пакета. Ну ахуеть невстать. И никто не возмущается продолжая жрать это говно. Наверное иногда человек со стороны полезнее суперпрофи дрочащий одно и то же 50 лет подряд и не замечающий нихуя дальше носа.
Вобщем нужно привыкнуть к лямбда структуре каталогов/дирректорий как к естественной и понятной, любая карта сайта обычно не древовидная и это почему-то никогда никого не смущало, хоть там и циклы есть, а подобная структура у папок почемуто является чем то манясложным.
С одной стороны комп должен быть дружелюбным для пользователя с другой должен предоставлять выбор среди вариантов которого необязательно все должны пользователя устраивать, тоесть в этом плане неориентируемость на дебилов, потомучто радикально обратное - утопия и вредительство с быдлизмом.
С одной стороны комп должен быть дружелюбным для пользователя с другой должен предоставлять выбор среди вариантов которого необязательно все должны пользователя устраивать, тоесть в этом плане неориентируемость на дебилов, потомучто радикально обратное - утопия и вредительство с быдлизмом.
Ты и не обходишь все ссылки по карте сайта для индексации
>за 3.14 фс-подобными системами и тонкими клиентами, подключающимися к вычислительным кластерам мелкомягких будущее
Нахуй такое будущее. Это же даже словом "пиздец" не описать
Дежурно обоссываю пидора разводящего флейм с самим собой.
Куда писать разработчикам линукса чтобы с ними об этом добазариться?
Лечись, шизик
>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна.
>Частично признаю что ты прав
И на том спасибо.
>Только недавно федора стала поставлять бтрфс как стандартную фс.
Ещё одно вонючее юзлесс мёртворождённое говно от копров для порносайтов и бугалтерий.
Еще в досе такой хуйней страдали.
Создавали папку "мамка админа".
Указывала она на корень.
Приходил админ, жал Ф8
А теперь взял редактор и пошел улучшать ноды своей фс.
Создавали папку "мамка админа".
Указывала она на корень.
Приходил админ, жал Ф8
А теперь взял редактор и пошел улучшать ноды своей фс.
В досе хуёсе, это ты сейчас сам придумал? ПОх чё там было лет 40 назад, концепции меняются было бы желание, NIXos же запилили и заебись, если бы там системды и гнома не было можно было бы даже пользоваться этим.
Так я и вижу что обитатели тут говно хуже некуда, походу нормальные люди здесь незадерживаются а твоя работа выдавливать их отсюда.
>свойства
>создать ярлык
PROFIT
>Где есть форум где сидят разрабы линукса чтобы им написать об этом и приступить к работе?
Тебе нужны разрабы файловых систем, а вернее новая файловая система. Кто-то должен её разработать. К линуксу и его разрабам это имеет мало отношения, чтобы что-то добавить в Линукс это что-то должно существовать.
Шансов што такую хуйню добавят в существующие фс практически нет.
Васянская smekalochka снова здесь. Только если ты достаточно криворукий, тебе можно.
Ты главное папку с ярлыками на все созданные ярлыки создать не забудь, а то мало ли что пойдёт не так.
Да иди ты нахуй на всякий случай закомплексованное тупое уёбище, я после твоей мозгоебли и издевательств ссу на любой твой высер, комплексы бездарности ёбаной заиграли у тебя суки, сдохни от рака говно ёбаное.
Говняное жлобское свиноёрылое уёбще может только спорить на ровном месте: "ну и зачем?" "да не взлетиииит" "нет ну это надо 7 кругов ада пройти кококок". Сам за свою жизнь нихуя придумать не смогло поэтому и спорит пятаком своим ебаным. А других нормальных людей тут и нет практически никто не отписался за всё время. Тред можно выкидывать.
Да в том же меню "пуск" в KDE уже одна и та же программа находится в нескольких категориях, например стим лежит и в категории "игры" и в категории "интернет", что вполне логично, тоесть проблема эта стоит весьма остро, но сил пока хватило на организацию менюшечек и сайтиков, если дизайнеру повезло быть в курсе про это. В большинстве случаев в интерфейсах лютых пиздец в виде дубляжа одного и того же в нескольких ветках или вообще хаотичная каша из ссылок какая пришлась с недосыпа.
ВОт элементарно есть у нас конфиги для каждой программы, значимая категория, было решено скидывать все конфиги в одну деррикторию разнося по сути программу по разным веткам, давая "витруальную" связность между ними с помощью как раз таки программы. Но это тоже костыль по сути, и всёравно нужна возможность добраться в конфиг из дирректории самой программы, а не только дирректории с конфигами. Кароче ёбаный ад из компромиссов с этим деревом ебучим.
А так же это позволит сделать КОНТЕЙНЕРИЗАЦИЮ и разграничение прав буквально из коробки, без обходных решений и прочей ебатни. Почему проглядели за столько лет?
Да иначе зачем изначально в линуксе все контексты сделали дирректориями, нелогично как-то получается.
>Древовидная структура, простая и понятная иерархия.
Может тебе ещё надо, чтобы на борде нельэя было отвечать на 2 и более поста одним постом?
>Короче, эта вся мишура по большому счету не нужна никому. Да, жизнь стала бы проще, но не так сильно, чтобы с ней заморачиваться. Поэтому она непопулярна. Только недавно федора стала поставлять бтрфс как стандартную фс.
Какой же блядь копиум неосилятора.
За тобой уже выехали.
Зумер придумал симлинки
Руки об ближайший забор выровняй и голову свою недалёкую за одно.
Рефлинки детачат от оригинала и включают ков.
Симлинки работают между фс, а тут всё в одной.
Заранее скажу, что хардлинкам запрещено линкать директории, что предполагается в схеме опа.
В итоге оп предлагает некие ограниченные симлинки, которым запрещено создавать лупы, но
1. не уверен, что такой запрет фундаментально осуществим за разумное время
2. программы впослне себе умеют работать с симлинками и без таких запретов?
В общем, прямо сейчас нет никаких проблем построить систему целиком из симлинков, и проверить, насколько это вообще полезно, не привлекая "разрабов линукса" с "форума", а проблему лупов решать после, если она вообще возникнет.
> включают ков
А ты типа луддит или что?
>Рефлинки детачат от оригинала
Хорошо, хардлинки не детачат от ков, и не требуют включения ков. Пользуйся.
Это типа не то, что оп хочет.
> детачат от ков
от оригинала всмысле
В посте есть про хардлинки.
Не дочитал пост до конца, сорян. Я уже сам запутался, я уже давал опу ответ про дедупликацию в бтрфс, но он ответил так:
>Нет это всё НЕ ТО и полумеры какието частные временные для порносайтов или хуй пойми.
Конечно, он хочет откровенную шизу, если кто-нибудь обладает связями в транс сообществе киньте ему инвайт в конфу, авось там его поймут. Вот, например, из недавнего транс-софта выкатили неиерархичный файловый менеджер https://github.com/kra-mo/hyperplane , начало положено.
>я уже давал опу ответ
ОП сумасшедший, это понятно, если почитать тред. Но, в целом, техническая задача интересная и вполне себе осуществимая на современных технологиях. Но оп, конечно, хочет, чтобы кто-то её сделал за него.
А я так, мимопроходил, пояснил за *линки.
Выглядит как будто ОП решил натянуть множественное наследование из классов на фс. Забыв что такое наследование это зло ебучее.
Как будто правы ребята что ОП хочет внести контекст определяемый человеком на уровень ФС. При этом каждому новому файлу нужно будет прокликивать из списка в какой контекст он относится? Т.к. никакая нейросеть сходу не определит что вот этот файлик хуета.txt в папке Моё относится к списку продуктов на выходные, которые мне жона скинула, пока я сам зачем то не пропишу тегом например. Ну либо должно отслеживаться всё на уровне перекидывания файлов, контекста и его паттернов взаимодействия и т.д. Крч ебические мощности нужны с зондами вплоть до энцефалограммы носителя. А для каталогизирования под какие то более узкие и определённые задачи давно сделали БД, теги, индексацию и т.д. Херня задача как будто, непрактичная и легко ломаемая именами файлов 1,12, 1111, 123, йцук и сильно завязанная на корректность описания контекста.
другой мимо прочёл по диагонали
Мне кажется, ты тоже сумасшедший.
>если кто-нибудь обладает связями в транс сообществе киньте ему инвайт в конфу, авось там его поймут.
Ну так это основная просьба треда я уже жду что ктото кинет ссылку на нужное коммюнити и нираз об этом писал. Будет от чего идти дальше. Да и велосипед не охота переизобретать нужны грамотные люди.
>Конечно, он хочет откровенную шизу
>Вот, например, из недавнего транс-софта выкатили неиерархичный файловый менеджер https://github.com/kra-mo/hyperplane , начало положено.
Почему шизу, если ты до конца не понял в чём суть и нужность ромбичности дирректорий, может поймёшь позже.
>Но, в целом, техническая задача интересная и вполне себе осуществимая на современных технологиях
Хоть в чём-то согласие.
>Но оп, конечно, хочет, чтобы кто-то её сделал за него.
Да схуяли за меня то? Врядли это когото больше волнуе т чем меня. Нет ну если вот прям щас готово и вышло с апдейтом то я конечно рад.
>Выглядит как будто ОП решил натянуть множественное наследование из классов на фс.
Лол ромбичность папок это просто ебический частный микрослучай посравнению с ромбичностью ООП который делается просто сместа, а то что это реализовано даже в ООП хоть и криво ебать какое достижение которое даже я не до конца понимаю как. Это просто стандартные вещички типа ссылок в оперативке только на харде. ПФФ даже сравнивать смешно.
>Забыв что такое наследование это зло ебучее.
Не спорю но как сказано выше это другое.
>ОП хочет внести контекст определяемый человеком на уровень ФС
Ну правильно а что тебе надо чтобы комп тебе попу мыл?
>При этом каждому новому файлу нужно будет прокликивать из списка в какой контекст он относится?
Обычные юзер действия.
>Т.к. никакая нейросеть сходу не определит что вот этот файлик хуета.txt в папке Моё относится к списку продуктов на выходные, которые мне жона скинула, пока я сам зачем то не пропишу тегом например.
Нейросети там не место это твои файлы. А программы ссылаются по дизайну туда куда нужно.
>Ну либо должно отслеживаться всё на уровне перекидывания файлов, контекста и его паттернов взаимодействия и т.д.
Ты выдумывать всё пытаешься налету. Не нужно граф папок итак содержит всю нужную информацию.
> Крч ебические мощности нужны с зондами вплоть до энцефалограммы носителя.
Не нужны. Как и задачи которые ты для этого ставишь.
> А для каталогизирования под какие то более узкие и определённые задачи давно сделали БД, теги, индексацию и т.д.
Говно архаичное эти БД. Вижу ваку с БД бегу по ебейшему радиусу от неё.
>Херня задача как будто, непрактичная и легко ломаемая именами файлов 1,12, 1111, 123, йцук и сильно завязанная на корректность описания контекста.
Неломаемая. Или имеющая в любом случае меньше минусов чем текущий мусор.
Сам ты блядь сумашедший пидор.
> до сих пор нельзя чтобы одна и та же папка лежала в нескольких папках одновременно?
Создай один реальный экземпляр и накидай на него симлинков, например. В /run и /proc это можно наблюдать почти в любом дистре. Там даже пижже - симлинки ещё и циклятся и перебирая такую папку тупым поиском исчерпаешь память.
Два чая адеквату
>Ты, как и многие, путаешь связи между объектами, использующие разные признаки, в том числе и связанные с техническим устройством системы, и смысловую иерархию, в которую они выстраиваются (в другом измерении). Первое не предусматривает и не задаёт второго.
Спасибо что обозначил это, но я как раз имею созревшее сформировавшееся понимание этих вещей, абстракция, конкретизация, физическое устройство и умозрительная семантика.
>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях
Суть в том что она семантически ущербна и ограничена. Мы даже программу не можем никакую нормально по папкам раскидать без ёбаного хаоса и пиздеца что где лежит, всё группируется по какимто архаичным признакам типа формата файлов, ну это вообще пиздец полный никуда не годится.
>Файловое дерево на самом деле не единственная присутствующая иерархия. Например, люди на автомате пользуются типами файлов или датами и не пытаются использовать видео в качестве фото (если они хоть что-то понимают). Нарушения здесь более трудоёмки (например, можно копировать скриншоты текста вместо копирования самого текст). Имена файлов тоже содержат значимые признаки.
Моя структура позволит явно обозначить любые почти связи какие ты посчитаешь значимыми, без циклов разумеется виду прагматичного учёта ограниченности железа.
>Кроме того, представлений файлов на практике тоже больше одного. Можно не помнить, на каком диске лежит фильм, если находишь его в общем списке торрент-клиента. Можно добавить все места хранения фото в менеджер картинок (или музыку — в проигрыватель) и пользоваться их проекциями, не думая о физическом расположении или формате.
Формат файла по смыслу абсолютно вторичен. Важно о чём он. У тебя в одной смысловой папке "Вася Пупкин" могут лежать разные форматы с голосовухами фотками видосами васи пупкина. И вася пупкин важнее формата файла, хотя комп васю никак автоматически обработать не способен, ну может быть нейросетями какието дополнительные связи установить где ты проебался.
>В общем, сущности могут располагаться в файловой системе, в базе данных, на листочке в виде подписанных овальчиков. А вот иерархия сложнее, расположена в голове и только проецируется куда-то.
Ясен что иерархия в голове но это никак не противоречит с тем что эта иерархия выражена в папках-нодах. А бвзы данных это архаика.
>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях. Компьютер не может тебе помешать поместить свои документы в каталог «Барнаул, Алтайский край». С другой стороны, даже у владельцев файлопомоек в голове появляется некая иерархия взаимосвязей, позволяющая находить, где что лежит.
Папки должны отображать человеческий смысл прежде всего приоритетно! Но тебе ничто не мешает создать паппку МП3 со ссылками на все файлы МП3 на твоём диске раз уж тебе так надо.
Моя предлагаемая структура бесконтурного орграфа не является ебать какой гиперструктурой на категориях, даже она содержить дохуя прагматичных упрощений. Например что папка может либо существовать либо нет, и других состаяний не существует. При желании можно копнуть и дальше и дальше, но я понимаю что продуктивность тут будет ниже чем переусложнённость. ЭТо примерно как с синтаксисами языков программирования заёбываться ими можно бесконечно не занимиясь программированием вообще, только нахуй это не нужно.
>В /run и /proc это можно наблюдать почти в любом дистре. Там даже пижже - симлинки ещё и циклятся и перебирая такую папку тупым поиском исчерпаешь память.
Понятно что налепили костылей поверх ущербной структуры поэтому такая ебала повсеместно. А то что циклятся даже так это для того чтобы прога могла с ноги за конечное число шагов зайти с любого конца цикла, ничего интересного.
Я уверен с ромбичностью ещё и от ебейшго числа конфликтов ПО можно избавиться. Ну и циклить нихуя не надо.
>без циклов разумеется виду прагматичного учёта ограниченности железа.
Хотя если сильно чешется то циклы можно и легитимизировать при условии что все элементы ноды цикла лежат в одной общей старшей ноде, прагматичная страховка для обхода. Только лучше не надо.
>Структура папок и файлов, в которой каждый объект имеет один родительский (или несколько, если использовать ссылки) не обязана быть осмысленной автоматически и не обязана совпадать в разных случаях.
Ты умничаешь лишь бы умничать. Проблема как раз в том что древовидная структура не позволяет задать зависимости вообще никогда скольконибудь адекватно, но при этом приходится эти зависимости выражать в специально написанном аппендиксе который будет содержать то как вещи и сущности на самом деле друг другу относятся ну типа того же MAKEа, вместо того чтобы держать всё это нативно и человекочитаемо как и положено в GNU.
Нет я даже готов смириться с циклами но сделанными по правилам чем с тем пиздецом что творится сейчас. Да скорее всего циклы таки понадобятся в редких исключительных ситуациях. Но не произвольные.
Вы год обсуждаете какую-то хуйню, но до сих пор так и не прояснили 3 основных момента:
1) каким образом ОП хочет использовать, что одна и таже папка лежит в разных папках?
2) почему ОП на протяжении всего треда игнорирует посты о ярлыках и ссылках? ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?
3) каким образом эта самая "одна и таже папка" по мнению ОПа должна попадать в эти самые "разные папки"? Как-то автоматом или что? Чем это вообще отличается от того, что я прямо сейчас скопировал папку у другую папку, или просто создал ярлык на папку?
1) каким образом ОП хочет использовать, что одна и таже папка лежит в разных папках?
2) почему ОП на протяжении всего треда игнорирует посты о ярлыках и ссылках? ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?
3) каким образом эта самая "одна и таже папка" по мнению ОПа должна попадать в эти самые "разные папки"? Как-то автоматом или что? Чем это вообще отличается от того, что я прямо сейчас скопировал папку у другую папку, или просто создал ярлык на папку?
>1) каким образом ОП хочет использовать, что одна и таже папка лежит в разных папках?
Для естественной нативной объектной нотации всякого, личных фоток по темам, сборок программ, часто один ресурс используется несколькими а те несколько одним ресурсом и чтобы это всё можно было скомпилить без вонючего MAKEа.
>2) почему ОП на протяжении всего треда игнорирует посты о ярлыках и ссылках? ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?
Кто игнорирует ёпт? Я не игнорирую а нахуй шлю это говно.
>3) каким образом эта самая "одна и таже папка" по мнению ОПа должна попадать в эти самые "разные папки"? Как-то автоматом или что? Чем это вообще отличается от того, что я прямо сейчас скопировал папку у другую папку, или просто создал ярлык на папку?
Каким образом? Начиная с нижнего уровня оно ссылками так же организовано просто и без задней мысли. Ты лучше подумай и скажи нахуя нужны мягкие ссылки.
>ОП хочет, чтобы у него физически, на диске, создавалось несколько копий содержимого папок?
Нет я хочу чтобы при копировании в пределах какойто ФС поумолчанию создавалась ссылка, а при желании копия дубликат одного и того же папки или файла.
Да и хорошо подумай над тем зачем вообще нужны откуда высрались мягкие ссылки и почему мне нужно вообще их различать за какимто хуем почему мне должно быть не похуй.
Вообще-то может. На винде может и уж тем более на Линуксе. Используй симлинки епта. Всё давно придумано и не нужно ничего дополнительно устанавливать.
>Зачем мне знать, где в системе находится отчёт за прошлые года по корректному продукту если я могу запросить "морковь отчёт 2018" и получить релевантные результаты?
Это сработает только пока пользовать нормально дает имена файлам, чтобы потом их было можно вот так найти.
А дерево папок тогда нахуя? Для красоты или чё? Или несудьба изначально было сделать систему гибче по дизайну. Нахуй не нужны твои симлинки потому что их как раз потом придётся различать ещё и вручную а автоматическая система сделал и забыл ёпта. Не нужно обмазываться говном пожалуйста. Да и все объеты имеют объектную нотацию это база.
>Это сработает только пока пользовать нормально дает имена файлам, чтобы потом их было можно вот так найти.
Ну так если пользователь криворучка ето его проблемы, можно кинуть ему ситуативный костыль как кость собаке чтобы за пределы загона не убегал и нормальные здоровые люди могли м здоровый менеджмент объектов.
Нахуя нужны симлинки нахуй, точнее нахуя вот мне различать вообще мягкая ссылка или жёсткая? Нахуя мне это надо? Мне чё заняться чтоли блядь нечем потвоему? А пакеты программ мне чё блядь тоже симлинками предлагаешь внутри связывать? Это говно а не решение. Ось должна в объектную нотацию ИЗКОРОБКИ блядь и никак иначе. Я смотрел даже какие утилиты при этом сломаются и их кстати не так уж и много. Ну монтирование придётся переделать а всё остальное как будто под это задумывалось изначально только чёто проебланили гдето на какомто этапе.
>зачем вообще нужны откуда высрались мягкие ссылки и почему мне нужно вообще их различать за какимто хуем почему мне должно быть не похуй
>приходися пакетный менеджер использовать чтобы он все пакеты топологически отсортированными держал у себя
Ну ты дислексик, конечно, но теперь я вроде понял что тебе не нравится. Вот только с прогами у тебя ничего не выйдет. Потому что проги раскидывают свои файлы по разным папам не из-за каких-то там легаси, а из-за безопасности. Потому что у файлов в этих папах разные права и у разных пользователей разные права на доступ к разным папкам. А если у тебя один и тот же файл лежит и в системной папке и в папке пользователя, то тогда пизда всем политикам безопасности и разделению учеток.
А с фотками и музыкой это делается через всякие коллекции и галереи, которые сейчас в любом плеере и просмотрщике есть. Там как раз можешь как угодно группировать и сортировать один и тоже файл, включать его в сколько угодно плейлистов и альбомов.
>Ну ты дислексик, конечно, но теперь я вроде понял что тебе не нравится. Вот только с прогами у тебя ничего не выйдет. Потому что проги раскидывают свои файлы по разным папам не из-за каких-то там легаси, а из-за безопасности. Потому что у файлов в этих папах разные права и у разных пользователей разные права на доступ к разным папкам. А если у тебя один и тот же файл лежит и в системной папке и в папке пользователя, то тогда пизда всем политикам безопасности и разделению учеток.
Получится, всё получится. Как раз в этом случае безопасность организовать даже проще и она будет даже менее костыльной чем в случае текущем, потому что можно будет организовать целые области видимости кому и кого надо. В случае что ты описал просто берётся функция eto_drugoe_ponimat_nado_smotrii_ne_pereputai которая как раз КОПИРУЕТ файл создавая его дополнительый экхемпляр в другом загоне и никто их не перепутает всё заебись. А если ещё серьёзнее то просто к функции копировать и вырезать надо добавить функцию связать, чтобы прокинуть жёсткую ссылку без копирования файла или папки.
>А с фотками и музыкой это делается через всякие коллекции и галереи, которые сейчас в любом плеере и просмотрщике есть. Там как раз можешь как угодно группировать и сортировать один и тоже файл, включать его в сколько угодно плейлистов и альбомов.
Нет всякие копрогалереи это говно ебаное для колхозников. И там как раз НЕЛЬЗЯ как угодно группировать из-за привязки к формату файла, архаика ебучая.
Овт смотри могу объяснить на пальцах. Есть у меня скажем знакомый, и на компе у меня есть папка с его именем, там лежат его фотки голосовухи и прочее, есть у него баба, папку с бабой можно считать подконтекстом моего кореша ибо нахуй она мне сдалась выше по контексту, ок создал подпапку баба кореша в папке кореш, у них родился наёбыш, папку с наёбышем проде надо кинуть в папку с бабой но и в пвпку с корешем. А ещё кореш сделал днк анализ что наёбыш его и прислал мне документ в формате пдф этот документ связывает кореша и его наёбыша поэтому принадлежит корневой папке кореша и подпапке наёбыша. Но тут ещё мякотка в том что документ о днк родстве является связующим для обоиз контекстов, а связующий может находиться как ниже так и выше по топологии контекстов. Тоесть ромбическую структуру можно ОТЗЕРАКЛИТЬ и смотрель задом наперёд а с деревом так нельзя, ну как бы можно но тогда это будет просто астнономическое количество ВСЕХ папок с подпапками до корня вот.
Но так же у моего кореша есть питомец который мне очень понравился и похоже который любит меня больше чем хозяев, папку с питомцем я кладу в подпапку всех членов семьи кореша а так же в контекст выше на равне с корешем, очень мне нравится это животное например, ну пусть это гекон будет какойнибудь например.
>А пакеты программ мне чё блядь тоже симлинками предлагаешь внутри связывать?
Ага. Это ведь работает. Например, можно папку из родной Program Files с диска C перекинуть куда-то ещё на другой диск, а обратно на С в Program Files вместо самой папки вернуть симлинк на папку и это будет работать. Будто никто ничего никуда и не перемещал вовсе. ну ещё ярлык в меню пуск надо будет поправить.
>придётся различать ещё и вручную а автоматическая система сделал и забыл ёпта.
Ну так напиши скрипты, автоматизируй епта. Добавь задания на запусмк в роднйо планировщик задач винды или в Cron на Linux/FreeBSD и дело-то. Мыслишь ограниченно в натуре как виндузятник.
Проблема любой структуры кроме древовидной в том, что ты забудешь о ее элементах уже через несколько месяцев.
Дерево же будет оставаться с тобой неизменным годами, дисциплинировать твой ум, и будет обрастать ответвлениями. И если наебыш для тебе через много лет станет важнее, чем его родичи, то дерево не надо менять, а достаточно продлевать его не меняя принципов построения. С ромбом или облаком ты получаешь мешанину и в мыслях и в файлах.
А для удобства доступа просто накидываешь ссылки на нужные элементы дерева в отдельные папки.
В этом суть прямых связей и ассоциативных.
Облако это грязная мешанина ассоциативных и прямых связей, которую ты заебешься перестраивать каждый год.
А правильно построенное дерево на прямых связях типа: род/вид, часть/целое и дополненное перекрестными линками - это практически вечная структура.
>ну ещё ярлык в меню пуск надо будет поправить.
В разных ситуациях этих дополнительных условий может быть неопределённое количество, что собственно является следствием костыльности нефундаментальности такого подхода, уровня ебануть поколхозному на время до лучших времён.
>Ну так напиши скрипты, автоматизируй епта. Добавь задания на запусмк в роднйо планировщик задач винды или в Cron на Linux/FreeBSD и дело-то. Мыслишь ограниченно в натуре как виндузятник.
Мне так придётся только написанием скриптов и заниматься.
>Проблема любой структуры кроме древовидной в том, что ты забудешь о ее элементах уже через несколько месяцев.
Цэ дуже потужный тезис, охуеть как дуже. Хотябы потому что в структуре приведённой к ромбической наиболее часто меньше нод, чем в древовидной, а в структуре с циклами их меньше или равно, чем в ромбической, но циклы не нужны, поэтому остановимся на декларируемом.
>Дерево же будет оставаться с тобой неизменным годами, дисциплинировать твой ум,
Это дисциплинирование ануса а не ума.
>и будет обрастать ответвлениями
>то дерево не надо менять, а достаточно продлевать его не меняя принципов построения.
Ога, знаю как оно будет обрастать, получится хуйня уровня:
/program/media/video
/program/
.program/messages/images
/program/messages/videos
/program/videos/messages
/images/videos/program
/чуета/видео/долбоебизм
/долбоебизм/говноедство/картинки
И такая сортировка файлов практически в любой проограмме какую не глянь. Открываешь пак игры и всё хранится по ебанутому модельки отдельно анимации отдельно, текстуры отдельно, нет ну зачем так париться хранили бы тогда всё в одном каталоге и всё ёбанарот только жизнь усложняют себе причём. Лучше вообще не иметь структуры чем говно вместо неё.
>А для удобства доступа просто накидываешь ссылки на нужные элементы дерева в отдельные папки.
Тут не в удобстве дело, а в том что в структуре отражена ключевая информация об объекте, а не колхоз долбаёба.
>В этом суть прямых связей и ассоциативных.
Чего блядь? Тут нет никакой разницы вообще. Это лишняя классификация, ненужная выкинь её.
>Облако это грязная мешанина ассоциативных и прямых связей, которую ты заебешься перестраивать каждый год.
Сам придумал сам добавил ещё один потешный тезис. Какой молодец.
>А правильно построенное дерево на прямых связях типа: род/вид, часть/целое и дополненное перекрестными линками - это практически вечная структура.
Безосновательное утверждение того что с ромбом это не так.
Я думаю ты не понял одну вещь, что IT обросло с кучей исторических артефактов сделанный в духе времени по ситуации но совершенно нерационально и неэффективно, вроде клавиатур до сих пор выпускаемых в такой компоновке как будто это печатная машинка, но печатных машинок уже давно нет в ходу и бумага уже сокращается а тут приходится гнуть пальцы в 2024м чтобы косплеить машинистку начала середины 20 века когда компов ещё не было, вот это умно ебать "вечная структура". И так же с файловой системой когда они только появлились "компьютерщики" решили что раз уж диск периферической устройство то каталог это интерфейс а потому должен иметь "упрощённую" структуру дерева ну чтобы бугалтерши не взвыли, но это был проёб и ты это упускаешь.
Я так же считаю что в интересах технической консистентности папки могут содержать системные циклы, но в пользователю это я думаю ни к чему.
А стоит ли говорить что даже сеть на самом фундаментальном уровне нихуя не древовидная, то нахуя тогда папки имеют древовидную структуру вообще тупизм какойто. Информация должна быть структурирована, без структуры инфа это просто мусор. А структуры нет и данных всё больше если не привести к порядку это всё сейчас то потом может стать поздно.
Ведь сеть это же интерфейс какойто там периферический. Или не периферический и не интерфейс, а хардкод? Или зависит от ситуации? Ой а давайте для каждой ситуации отдельную ветку дерева создадим удобно же. И для каждого возможного обхода графа тоже по ветке дерева охуеть как удобно ну.
>ррряяя то костыль, это костыль
>что в его понимании не костыль внятно объяснить не может
>Мне так придётся только написанием скриптов и заниматься.
А что ещё на Линухк делать-то? В игоры что ли играться?
Если раскрыть мысль точнее, я имел ввиду что, заниматься написанием скриптов для того что итак должно привычно работать само, когда можно писать скрипты для того чтобы модифицировать и кастомизировать уже привычное, что есть большая разница.
Да смена базы. Ярлыки ненужны не из-за циклов, а из-за необходимости в ненужном различии мягких и жёстких ссылок, спасибо за внимание.
Так как сделать то что я задумал?
Да хули тут искать ответов. Весь софтач давча это почти одни пидоры биомусор кароче. Пидорам софт не положен вот они и бесятся. Мало зиблокировали им халявы.
Красавица!
>Да иначе зачем изначально в линуксе все контексты сделали дирректориями, нелогично как-то получается
Кал нинужон.
Ну так не ешь.
Такс, есть для винды какой-то способ дедупликации? Скопировал с телефона фото/видео так как оно на нем лежало + ещё раз отсортировал по папка.
Да есть. Написать майкам пожалание перевести всё на новую ФС где будет разрешена схема папок предложенная мной, других способов нет, кроме ебли с ярлыками что тут предлагали.
Если немного погуглить то дедупликация таки есть. Но неизвестно к каким проблемам приведет включение.
Так мне лично не нужна дедупликация. Проблема которую я хочу решить не состоит в экономии места, а состоит в экономии информации о файлах, повышении связности. Ведь каша из файлов это даже ещё хуже чем просто забитый винт.
Шиз, у тебя всегда есть сосноль и возможность типа feh ~/Photo/porno/Pamela Anderson nude.jpg
Что за пердоговно?
Пусть тред живёт
Ну так линуксоиды вы где?
Ведро собирают?
И это не единственная проблема. Дата создания документа, как в ntfs, в linux/ext отсутсвтует! Есть чтение и модификация, а также изменение информации о файле. Притом дата создания - это важная информация, так как оно может говорить о большем, если бОльшая его часть была создана именно в этот момент. Исправил 1 букву - бац, новая дата "создания".
Благодарю анон что ты тред бампанул мой.
Я хотел написать видя что тред тонет, отвлёкся другими делами а когда вспомнил уже его могло не быть, но ты подкинул его вверх, спасибо.
Так вот я выяснил что в linuxе таки можно пихать ЖЁСТКИЕ ссылки куда угодно. И уже подумываю отсортировать красиво и компактно свои файлы по категориям как мне это и виделось.
И разобравшись в теме это и правда практически не несёт никаких проблем, кроме разве что при монтировании ддругих устройств и ФС и распаковки архивов, а в остальном мувмент папок создание удаление копирование работает как надо как и задумывалось.
Но у меня вопрос, почему тогда папки с программами отсортированы ТАК ВСРАТО? Это касается пакетов программ и самого линукса. Давно же можно всё отсортировать, так чтобы пакетный менеджер былш не нужен, в эту же структуру и права доступа засунуть туда же и виртуализацию со всем необходимым как .
>подумываю отсортировать красиво и компактно свои файлы по категориям как мне это и виделось
Ну как успехи? Наколхозил что-нибудь удововаримое?
>Опять ты.
Тебе выше ответили, что ты пытаешься спроектировать корабль, начиная с вензелей на двери капитанской каюты, опуская тысячи важных вещей.
Я не перестаю удивляться, насколько упало качество тредов в тематике. Я сначала проиграл, но когда увидел почти две сотни постов, ужаснулся.
Люди, которые разрабатывают алгоритмы, ПО, железо они не просто так свои степени по математике и кс десятилетиями получают. А структуры и основы способов работы с вызовами/адресами/ect были заложены еще тогда, когда у большинства в треде отцы и деды в своем колхозе один на троих плуг делили.
Почему рыбак с резиновой лодкой не дает советы по проектированию судов Samsung Heavy Industries ?
Зато ребята с > Аноним (Linux: Firefox based) копировав из дистровики 3 команды для настройки своих чулочков, уже рассуждают о вещах по типу устройства ос или фс и как было бы лудше)))0, пиздец. Что нас ждет дальше?
Я от треда в ахуе.
Это у тебя в твоей винде обоссанной служба упала иди чини, а не качество тредов, я знаю каким оно было достаточно в архивы заглянуть.
>Тебе выше ответили, что ты пытаешься спроектировать корабль, начиная с вензелей на двери капитанской каюты, опуская тысячи важных вещей.
Но при этом ты сам высираешь плюгавую пространную мусорную хуету без конкретики с одними метафорами мудрого пастуха, а не пошёл бы ты нахуй, подвиндовый выблядок?
Люди которые разрабатывали системы очевидно ОЧЕВИДНО обосрались на ровном месте, а чинить западло, учше делать вид что не воняет.
Если бы ты имел дело с программированием то там даже ТАМ блядь весь код укладывается в ромбическую структуру. А не по утилитарным помойкам которые надо потом MAKEом собирать.
В линуксе не просто так всё или почти всё засунуто в контекст на файловой системе, чтобы разные ресурсы могли с разных путей иметь доступ сверху вниз и снизу вверх, но не циклически. Это надо признать очень удобно, хотябы потому что не приходится такую структуру дублировать гдето ещё, но тебе ли реестроблядку костыльному это знать? Пошёл нахуй кароче долбаёб.
Нет пока не наколхозил, жду SSD для наката в RAID, а там посмотрю что можно сделать.
Тут дело даже не в самой системе а просто чтобы в самих архивах контент удобно хранить, а ты в систему кудато полез, хотя это и не обязательно было, сам обосрался кароче.
Во во, хардлинк по сути и есть то что ОП долбоеб хочет, для реализации все есть а уж кому реализовывать и как на это есть золотое правило СПО - если чего то нет, напиши это сам.
Хардлинк.
\thread
\thread
Это называется план9 и он не взлетел. В ит так работает что из божественной мультикс и прогрессивного план9 был выбран косожопый евнух, потому что пидорахи не заслужили удобство
ИИ говорит что существенных препятствий, кроме указанной мной проверки отсутствия циклов в структуре, нет.
> Почему в 2023м из-за того что по ошибке придумали хранить файлы в "папках" до сих пор нельзя чтобы одна и та же папка лежала в нескольких папках одновременно?
Ты долбоеб? Хардлинки и симлинки придумали уже лет 50 как наверное. Хардлинки это буквально то о чем ты говоришь
На папки нельзя сделать хардлинк.
doas ln -fs
>спроектировать корабль, начиная с вензелей на двери капитанской каюты
При проектировании дома нужно сразу учитывать удобство использования квартир; не опираться на это только лишь, но обязательно учитывать; вплоть до петель дверей, да. Но структура ФС - это не украшательство. Схожесть многих ФС друг с другом объясняется не тем, что найден лучший способ хранения данных... Это такое же заблуждение, как считать архитектуру x86 хорошей или, не дай бог, лучшей, а не просто архитектурой де-факто, местами неимоверно кривой.
> Исправил 1 букву - бац, новая дата "создания".
Неееет
Петушониксы, накатите себе уже винду и съебите с линуксов.
> (dbus) stat -L machine-id
> File: machine-id -> /etc/machine-id
> Size: 15 Blocks: 8 IO Block: 4096 symbolic link
> Device: 0,35Inode: 7832871 Links: 1
> Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2025-10-19 17:08:06.192869028 +0300
> Modify: 2025-09-25 19:47:05.466023769 +0300
> Change: 2025-09-25 19:47:05.466023769 +0300
> Birth: 2025-09-25 19:47:05.466023769 +0300
Во-первых, это расширенный функционал, которого 20 лет в linux не было. Даже до сих пор в каком-то ПО (не последней важности) этого нет, к сожалению.
Стандарт POSIX в 2024 редакции всё ещё имеет только 3 метки даты.
>Each file has three distinct associated timestamps: the time of last data access, the time of last data modification, and the time the file status last changed. These values are returned in the file characteristics structure struct stat, as described in <sys/stat.h>.
https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/V3_chap01.html#tag_18_01_01_06
> которого 20 лет в linux не было
А ты был?
statx вызов в coreutils существовал уже в ядре 4.11, это 2017 год.
https://man7.org/linux/man-pages/man2/statx.2.html
>в ядре 4.11
Не сразу с выходом новых функций, их берут в расчёт разрабы ПО. Проходит время; это годы. Плюс стабильные дистры подолгу не обновляются. Возьмём, например, Debian Stretch. Он вышел в 2017, но имел версию ядра 4.9.30, то есть ещё до введения расширенного функционала. Срок поддержки дистрибутива закончился в 2022, то есть это всего 3 года назад! Вероятно даже разработчики ПО не всегда следят за последними изменениями ядра, либо придерживаются принципа переносимости и универсальности своих программ.
Очевидно, что вся литература, ознакомительные статьи и тематические обсуждения по linux составлены очень давно. Форумы вообще не обновляются, а переизданием занимаются не все и не всегда. Уж тем более читатель не будет (и не должен) судорожно искать дату в пределах последних лет, уповая на то, что описанный в книге или на форуме функционал может быть описан не верно для текущего времени; тем более что linux как система и концепция известна своей стабильностью, и очень многие её составные части работают почти точь-в-точь как это было много лет назад.
С хэдерами ядра в дистрах стало поставляться 6 лет назад
https://github.com/coreutils/coreutils/blame/master/src/stat.c#L1283
Не много, но и не мало уже.
>до сих пор в каком-то ПО
Обнаружил, что mousepad переписывает birth. Очень неприятно. Даже консольный nano так не делает.
>все, что на носителе есть - это файл
В базе данных - нет. Но если бы дизайн ФС был прогрессивнее, то для небольших изменений в подходе, о которых речь в этом обсуждении, не нужно было бы абстрагировать его с почти полной потерей совместимости. Какой смысл в "файлах", если любой редизайн практически парализует ФС, прикорячивая к ней всякие БД или хоть даже жонглируя с симлинками, которые совершенно не понятны пользователю?
Ugh
У меня была мысль о том, что всякие bin sbin usr lib по десять раз дублируются, вынуждая запоминать /bin/usr или /usr/bin, /usr/share/lib или /usr/lib/share/bin/. Вот это точно выглядит уродливо. Ещё и от дистра к дистру меняется.
О том и тред. Конечно это всё можно упорядочить вообще без парадигмы в виде графа общего вида, но тогда хуй его знает что будет дальше. Если же контексты прибить гвоздями к парадигме, к DAG, что дескать зависимости всегда конечны, и не цикличны, как в языке C и C++ например, библиотеки не вызывают друг друга циклически, то можно вполне себе упорядочить это разросшееся сучье блядство. Можно исходить из парадигмы координат железо -> человекоинтерфейс. Где на одной границе графа низкоуровневые библиотеки а ближе к другой пользовательский контент.
>bin sbin usr lib
Зачем они нужны? Почему нельзя просто делить всё на физические диски, как на винде?
На винде как раз ничего не делится на физические диски. Это в DOS делалось, а винда для совместимости так разделы показывает. Кроме того, системных каталогов под разные нужды при многопользовательской или сетевой работе в ней не меньше.
А почему линукс так не показывает? Это же удобнее.
Почему не показывает? В самом что ни на есть обычном Gnome Files видим на панели перечень стандартных каталогов и все доступные для монтирования раздела по отдельности.
>Почему нельзя просто делить всё на физические диски, как на винде?
Потому что это может быть удобно только для домашнего компа, где мало дисков, редко что-то меняется, и пользователя реально волнует что такой-то диск физический, и он его может достать из компа. Для всех остальных вариантов удобнее файловая система, где диски вообще никак не видно, а каталоги можно расположить абсолютно любым способом, и смоделировать какое угодно взаимное расположение файлов.
Можно с 1993 (под нт, за прыщи не особо шарю) /иди нахуй /тхреад.
>android
Байткодный биомусор вообще права голоса не имеет.
Чё за тупизна? Из-за этого ведь и приходися пакетный менеджер использовать чтобы он все пакеты топологически отсортированными держал у себя, но это костыль.
Где есть форум где сидят разрабы линукса чтобы им написать об этом и приступить к работе?