Никита Прокопов (nikitonsky), автор «Моё разочарование в софте» рассуждает о маленькой, но очень важной детали, как не туда свернула ИТ-отрасль. Предлагаю обсудить.
«Иногда я жалею, что развитие компьютеров пошло не тем путем, которым могло бы. Одна из таких деталей — различение папок и файлов.
Почему папка не работает как просто еще один тип файла? Казалось бы, программисты должны уметь в абстракции и переиспользование, но вот конкретно здесь почему-то не получилось.
В командной строке чтобы скопировать папку нужно писать дополнительные ключи. Чтобы создать или удалить папку нужны отдельные команды. Приложить папку к письму нельзя. Загрузить папку на сайт нельзя. Удалить или скопировать папку с 100к файлами занимает миллион лет, хотя один файл такого же суммарного размера может скопироваться за полсекунды. Да что там, даже размер папки посмотреть уже нетривиальная какая-то операция.
Все это, конечно, неудобно, поэтому возникла целая индустрия архиваторов: способ взять папку и сделать из нее файл. Множество программ изобретали с нуля способы упаковать в один файл несколько файлов. Условный docx, jar и почти все игры. В исполняемые файлы тоже умеют засовывать другие файлы, нужные во время исполнения. Все это ТОЛЬКО ради того, чтобы на выходе не дай бог не получилась папка.
А ведь насколько круче было бы, если бы вместо доморощенного архива, тупо склеивающего файлы в непрозрачный формат, я мог бы просто зайти внутрь файла файловым менеджером и посмотреть, что там лежит!
Делать с этим, наверное, уже что-то поздно. Но может быть рано или поздно компьютеры переизобретут, и этот человек совершенно случайно прочитает этот пост и сделает все правильно. Пишу это для тебя!»
(публикуется с разрешения автора)
Канал Никиты: Стой под стрелой
Еще заплюсованные посты Никиты на Хабре
- Моё разочарование в софте
- Пора обновить ваш монитор
- Font size бесполезен, давайте это исправим
- Под капотом у Emoji
- Производительность главнее всего
- Как НЕ надо нанимать разработчика софта
- Создание совершенной печатной машины из Sublime Text
- Графика для JVM
- Вам не нужны ни PWA, ни AMP, чтобы ваш сайт загружался быстро
- Либо быстро, либо неправильно
- Python как инструмент сборки
- Компьютеры, какими я их любил
- Хорошие времена рождают слабаков
- Люди подозревают, что технологии — отстой, потому что они на самом деле отстой
Комментарии (27)
apachik
26.04.2022 22:21+13можем устроить. мы же инженеры.
но потом не обижайтесь, что станет трудно (долго) добавлять внутрь новый файл или удалять уже существующий в папке
hurtavy
26.04.2022 22:23+6просто зайти внутрь файла файловым менеджером
Откройте для себя нормальные файловые менеджеры. Хотя даже виндовый умеет в zip
vagon333
26.04.2022 22:32+2Удалить или скопировать папку с 100к файлами занимает миллион лет, хотя один файл такого же суммарного размера может скопироваться за полсекунды.
Желание понятное, но надежность файловой системы важнее.
Представьте в базе данных транзакцию на 100к записей: кажду запись (файл) нужно отработать отдельно. Отсюда и задержка.
Раньше, с FAT, было масса проблем как раз из-за ненадежности файловых операций, с NTFS стало надежнее.
Вроде не перевод, но фразы ниже словно сгенерены ботом:
> Казалось бы, программисты должны уметь в абстракции и переиспользование ...
> Еще заплюсованный посты Никиты на Хабре
RUTSTER
26.04.2022 23:25+1Вроде не перевод, но фразы ниже словно сгенерены ботом:
> Казалось бы, программисты должны уметь в абстракции и переиспользование ..."уметь в ..." - распространенное сленговое выражение
iliasam
26.04.2022 22:33+1Почему
папкакнига не работает как просто еще один типфайластраницы?
чтобы скопироватьпапкукнигу нужнописать дополнительные ключииметь типогафию, копира недостаточно. Приложитьпапкукнигу к письму[бумажному] нельзя.
И так дальше в том же духе.
masai
26.04.2022 23:10Не совсем корректная аналогия. Например, страница вполне может работать как книга.
paranoya_prod
26.04.2022 22:39+5Все это, конечно, неудобно, поэтому возникла целая индустрия архиваторов: способ взять папку и сделать из нее файл.
Странное предположение об назначении архиваторов. Автор не задумывался о том, что основное назначение данных программ в том, чтобы файл или файлы просто уменьшить в размере из-за того, что стоимость хранения 1МБ была высока и скорость передачи, если говорить об отправки письма, была не велика и могла занимать долгие и долгие часы? А не для того, чтобы из кучи файлов сделать один.
Фактически, папка и есть файл, по крайней мере в FAT, только это особый файл, он не содержит данные, а содержит только список файлов.
Все остальные минусы папок пошли оттого, что файловые системы изначально разрабатывались тогда, когда компьютеры были медленными. Да, можно было сделать у папки параметр "объём" и обновлять его каждый раз, когда происходят изменения внутри, но! папки умеют вложенность, и чем больше вложенность, тем большее число раз приходилось бы обновлять объём у каждой вышестоящей папки, а это время. И тогда автор бы очень сильно возмущался, почему так долго копируется один файл.
Копирование одной папки со 100к файлами и одного файла такого-же объёма имеют существенную разницу - надо на каждый файл создавать структуру в таблице распределения файлов, а это всё тоже время, время найти таблицу, время найти свободное место в таблице, время найти свободные блоки в разделе с данными. А один файл это только один раз обратиться к таблице размещения файлов и создать там только одно имя для нового файла.
vvviperrr
26.04.2022 23:03+4>Автор не задумывался о том, что основное назначение данных программ в том, чтобы файл или файлы просто уменьшить в размере
архивирование (archiving) и сжатие (compressing) - разные операции, не всегда зависимые.
tmnhy
26.04.2022 23:06+1Вы путаете архиватор и программу сжатия данных. Исторически архиватор как раз и использовался только для упаковки многих файлов в один архив во время записи на ленту. Без сжатия.
А программы сжатия данных с функцией архивации стали называть в быту "архиваторами" сравнительно недавно.
Это уточнение не отменяет бредовости высказанных (или пересказанных) автором мыслей. Потому что он упускает важную составляющую - ФС. А о многом просто не знает, например, что блочное устройство с ФС может быть обычным файлом.
ermouth
26.04.2022 23:13+5То-есть это даже сохранилось в расширениях, tar – это как раз tape archive, без сжатия, а живее всех живых.
masai
26.04.2022 23:12+2Странное предположение об назначении архиваторов. Автор не задумывался о
том, что основное назначение данных программ в том, чтобы файл или
файлы просто уменьшить в размере из-за того, что стоимость хранения 1МБ
была высока и скорость передачи, если говорить об отправки письма, была
не велика и могла занимать долгие и долгие часы? А не для того, чтобы из
кучи файлов сделать один.Изначально архиваторы как раз и были предназначены для того, чтобы много файлов превратить один. Например, CPIO или TAR ничего не сжимают. Да и сейчас их часто используют без сжатия. Компрессоры были отдельными программами. Но потом появились форматы, объединяющие оба качества, и архиватором стали называть и программу для сжатия.
amarao
26.04.2022 23:16+4Именно потому, что вы не можете открыть каталог как "файл" архиватором и находится вся волшебная сила файловой системы. Потому что пока вы открываете "файл" каталога в этот момент сосед пишет в каталог, а другой сосед удаляет. Из того же самого каталога.
Всё волшебство команды
mv(которая делает атомарное переименование) возможно только в условиях СУБД, в качестве которой выступает ядро ОС. Вам дают транзакции, целостность и т.д. - а взамен вы должны пользоваться только интерфейсами ядра.Сравните выгрузку 100000000 строк из SQL базы со временем копирования той же самой базы на файловом/блочном уровне. Почему-то медленее. Почему? Потому что это данные высшего качества, а не грубые сельские блоки с диска.
Kremleb0t
26.04.2022 23:24+3Складывается впечатление, что автор статьи сам не знает как работает файловая система.
Что будет, если внутри этой папки-файла удалить файл на 1мб и добавить новый на 2мб? Делать дефрагментацию файла-папки а затем дефрагментацию вышестоящей файловой системы?
Допустим есть file_folder_1 и file_folder_2. Надо перетащить файл file_folder_1/file.txt в папку-файл file_folder2/ - что делать в этом случае? Копировать содержимое file.txt из файла-папки file_folder_1 в файл-папку file_folder_2 ?
Я ожидал в статье какие-то технические подробности, объяснение как это должно работать, примеры, аргументацию.
MagisterLudi Автор
26.04.2022 23:28-1Вот тут еще 100+ комментов на эту тему, не знаю как их сюда перетащить.
nochkin
26.04.2022 23:41+7Надо сделать так, что бы комменты и посты были одно и тоже, но только с разным типом.
aamonster
27.04.2022 00:19+1Интересно, что бы сказал автор, увидев бандлы в макоси. Устроили бы они его или всё ещё "слишком фолдеры"?
А zipfolders для винды? (отличается от поддержки архивов в проводнике тем, что содержимое зипа доступно для любой программы... Когда-то было удобно, сейчас уже не очень надо).
VBKesha
27.04.2022 00:32+3Давайте сделаем сами:
dd if=/dev/zero of="./New Folder.bin" bs=1G count=10 mkfs.ext4 "./New Folder.bin" #да разгорится FS срач mkdir "./New Folder" sudo mount "./New Folder.bin" "./New Folder"
AAbrosov
Упаси боже от таких переизобретений. Даже то, что уже не очень, всегда можно испортить еще сильнее. Для примера можно посмотреть на датасеты в z/OS, вам не понравится.
drblez
А что не так с датасетами? Когда я работал с з/ос я не парился))) Пересел на мсдос, не хватало функциональности датасетов, потом привык и не парюсь ))))
В общем, как мне кажется, написанное в статье имеет место. Может не так сурово, но добавить тип файла, который был бы папкой, фактически, поддерживаемый на уровне ос, было бы полезно. А там, глядишь, народ бы втянулся )))
ermouth
Датасеты это реликт с дофайловых времён, они для концепции файлов – предки, не другая ветвь эволюции.
AlB80
Ага, сейчас, конечно.
Датасет это набор записей, то есть структура заведомо более сложная, чем последовательность байт (файл). Ваше непонимание z/OS датасетов происходит от того, что в этой системе перепрыгнули через файловую абстракцию (последовательность байт), лепят датасеты сразу поверх дисковых треков/цилиндров. Сейчас работа напрямую с треками/цилиндрами звучит дико, но тут так заведено. Античное IT.
ermouth
Безо всяких «конечно» концепция record/dataset появилась гораздо раньше концепции «файл».
И да, просто последовательность байт – это запись, а никак не файл.
Как там заведено я неплохо себе представляю, ваши довольно грубые намёки на моё непонимание неуместны.
AlB80
Концепция датасет/запись перешагнула концепцию файловая система/файл. Неудобно или непривычно, но так получилось. Люди решали практические задачи.
А что же такое файл, как не последовательность байт? Именованная последовательность байт?
ermouth
Да нормально для некоторых задач, совсем не только в экзотике кстати водится.
Насчёт «перешагнула», ну это как посмотреть. Понятно, что во всамделишном хайлоаде, да особенно если там механика на шпинделях, вся эта концепция, реализованная вместо ФС, уделывает любую ФС по производительности и по гарантиям всухую.
Тем не менее, в реальном мире задачи обычно поразнообразнее, чем заполнять блины однотипными записями, и потому все эти датасеты реализуют всё же поверх ФС, а не вместо неё.
Заодно прикладываются и все плюшки ФС, а если вам не нужно каких-то запредельных гарантий перфоманса под нагрузкой близкой к 100%, общий перфоманс с ФС на совр. железе и получше может оказаться. Не смотря на то, что датасеты в результате в файлах лежат.
AlB80
Посмотрим с другой стороны. Какая "файловая система/файл" может предложить из коробки индексированный по ключу доступ к записям переменной длины?
Так что ваше высказывание:
ошибочно до наоборот.