Здравствуйте, Marty, Вы писали:

A>>Говорят, что в пределах диска.

M>Не врут? Хардлинк — это же просто запись в каталоге и инкремент inode, разве это может быть где-то на стороне?

В пределах файловой системы.

M>Какая-то есть, видимо. В винде симлинки не каждому разрешено создавать

Не доверяет вам Билл Гейтс. Считает, что без админского диплома вы симлинков не осилите

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

А у тебя носки дома тоже могут одновременно на нескольких полках храниться?

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

Здравствуйте, Hоmunculus, Вы писали:

H>Потому что наше сознание иерархично. И само бытие иерархично. Как бы всякие анонимусы2 ни пытались все замешать в серую однородную каловую массу

Ну, строго говоря, оно иерархично в контексте. При смене контекста может измениться и иерархия.

Если относиться к файловой системе как к месту, где хранятся вещи, то всё довольно логично: на этой полочке носки, на этой — трусы, а на этой — патроны для дробовика. А вот засовывать в древовидную иерархию всё, как это предлагает делать ООП, не всегда бывает удобно.

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

Здравствуйте, ononim, Вы писали:

Pzz>>А у тебя носки дома тоже могут одновременно на нескольких полках храниться?
O>кстати не помешал бы тег, связывающий каждый носок с его парным экземпляром

Но в принципе можно обойтись и вложенностью — вкладывать один носок в другой

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.
Легаси. Первые файловые системы были плоскими. Древовидные появились позже, и это позволяло файлы группировать.

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

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
1. Иерархическое дерево/файловая система.
2. Система контроля версий.
3. Реляционная БД.

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

Здравствуйте, SkyDance, Вы писали:

S>>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

SD>Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.

Это типа граф?

SD>3. Реляционная БД.

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

А как же ключ-значение?

S>А как же ключ-значение?

Это начальная стадия реляционной БД. Все K-V в итоге превращаются в (недоделанные) реляционные.

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева?

Удобнее всего в виде линейного списка до 5-7 элементов, а дальше емкость внимания начинает мешать. Потому приходится сворачивать в под элементы — такой прием вообще везде, например на куртке карманы, в кармане кошелек, в кошельке отделения, в отделениях деньги-записки-карточки

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

Здравствуйте, SkyDance, Вы писали:

SD>Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.
SD>3. Реляционная БД.
Есть объектно-ориентированные БД, вернее сказать DDL — data definition language, e.g EXPRESS. Конкретные реализации БД могут смешивать иерархический подход и реляционный — например PostgreSQL. Системы контроля версий это вариации двух других.

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

Здравствуйте, Shmj, Вы писали:

S>В Windows есть ярлыки, но это не равнозначные теги. Остальное только через командную строку, чем мало кто пользуется.
Этим "остальным" пользуются примерно все. В рамках повседневного опыта — через подсистему SxS.
В рамках девелоперского — через менеджер пакетов pnpm, который экономит овердофига места и времени по сравнению с npm.
Иногда даже вручную — если хочется добиться того же эффекта, что и у этих инструментов, то делаем через Far, в котором всё это очевидно.

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

Здравствуйте, SkyDance, Вы писали:


SD> ... существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.
SD>3. Реляционная БД.

С терминами бы определиться сначала.

А то как каша структур (#1) и систем (#2, #3) пока выглядит (к тому же некоторые #2 могут быть реализованны на базе #3 — явно одно из двух не фундаментальное )

P>С терминами бы определиться сначала.

Согласен, после перевода на русский вышло как-то коряво.

P>А то как каша структур (#1) и систем (#2, #3) пока выглядит (к тому же некоторые #2 могут быть реализованны на базе #3 — явно одно из двух не фундаментальное )

Так и задумано — из любых двух можно создать третье, но сказать, какое "более фундаментально", невозможно. Впрочем, на это уже указали ранее. Что, однако, не меняет изначальный посыл — очередное гениальное изобретение корпоративных software architect на поверку оказывается чем-то из этих трех.

Здравствуйте, SkyDance, Вы писали:

SD>Надо будет как-нибудь причесать внутрикорпоративный "билль о системах", и выложить в виде блог-поста. Суть этого билля в том, что существует только 3 фундаментальные структуры:
SD>1. Иерархическое дерево/файловая система.
SD>2. Система контроля версий.
SD>3. Реляционная БД.

4. тейп-бэкап.
5. Redis (или его аналоги, многие получше и поудобнее, в т.ч. в малых масштабах)

Здравствуйте, SkyDance, Вы писали:

SD>Это начальная стадия реляционной БД. Все K-V в итоге превращаются в (недоделанные) реляционные.

Ну да, ну да...
А точка — это область, при правильном преобразовании системы координат. ))

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

Здравствуйте, Shmj, Вы писали:

S>Такой вопрос. Почему все-таки для нас удобнее чтобы файлы были представлены в виде дерева? Один файл в одном месте иерархи.

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

=======
С другой стороны, здесь правильно подметили, что ассоциативность порождает в общем случае множество отношений, поэтому, папки "фотографии за 2024-й" и "фотографии с мариной" могут содержать копии (или ссылки/линки на одни и те же файлы).

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