LINUX.ORG.RU
ФорумTalks

Создатель Linux назвал файловую систему OS X худшей в мире, а разработчиков Apple – обезьянами

 , ,


0

2

Обсуждение файловой системы HFS+ в соцсети началась после того, как разработчики Git обнаружили в ней серьезную проблему. Судя по всему, как NTFS, так и HFS+ нечувствительны к регистру, и это создает определенные проблемы. Не так давно разработчикам пришлось выпустить новую версию Git, которая только устраняла проблемы в операционных системах Windows и OS X.

В данном случае речь идет о критической уязвимости CVE-2014-9390 в Git, позволяющей выполнить произвольные команды на клиенте. Соответствующие исправления вышли несколько недель назад. Линус Торвальдс дал развернутый комментарий по поводу данной проблемы, а также объяснил, почему HFS+, по его мнению, является самой худшей файловой системой.

«Откровенно говоря, HFS+ — худшая из всех существующих файловых систем. Господи боже, какая же это хрень. У NTFS были аналогичные проблемы со стандартизацией UTF-8 (например, использование нетрадиционных форм косой черты). Кажется, они это хотя бы исправили. А вот проблемы в OS X, похоже, фундаментальны».

«Самый ужас в HFS+ не в том, что она несовершенна, а в том, что она спроектирована из рук вон плохо людьми, которые убеждены в правильности своих идей. Нечувствительность к регистру символов –- просто чудовищная затея, и в Apple могли это исправить. Но вместо этого они решили удвоить ставку и активно распространили свою идею на Unicode, причём сделали это отвратительно», – написал Линус Торвальдс в комментариях к постингу Хунио Амано в Google+.

На этом Торвальдс решил не останавливаться и назвал еще несколько неудачных, с его точки зрения, решений, принятых Apple в отношении HFS+, а затем назвал разработчиков этой файловой системы обезьянами.

Источник

Перемещено Shaman007 из apple

★★★

Последнее исправление: AP (всего исправлений: 2)

Палец для невидии, обезьяны для эппл.
Мне нравится этот парень

yacuken ★★★★
()

Судя по всему, как NTFS, так и HFS+ не чувствительны к регистру

Я что-то сегодня шуток не понимаю.

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

Америку открыл.

Нечувствительность к регистру символов – ужасно плохая идея

А с этим еще активно спорят.

mandala ★★★★★
()

доверила написание кода файловой системы обезьянам

Разве политкорректно так говорить? Надо не «обезьянам», а «одарённым природой приматам». Обезьяны - оскорбительно для программистов. Куда они там катятся в этих США? Скоро уже афроамериканцев неграми начнут называть.

mbivanyuk ★★★★★
()
Ответ на: комментарий от mbivanyuk

В правильном направлении катятся - называют вещи своими именами.

anonymous
()
Ответ на: комментарий от ymn

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

Valdor ★★
()

доверила написание кода файловой системы обезьянам

Ну и зачем он обезьян оскорбил?

anonymous
()

А кто знает нюансы юникода? Там можно без особых хардкодов из одного символа получить этот же символ в другом регистре? Или для этого нужны миллионы if-ов?

Stahl ★★☆
()
Ответ на: комментарий от Stahl

Или для этого нужны миллионы if-ов?

так долго, лучше матрица 2^16 или 2^32 символа =))

Atlant ★★★★★
()

Судя по всему, как NTFS, так и HFS+ не чувствительны к регистру

Какая обезьяна это написала? Фраза «Судя по всему» употребляется когда говорящий не уверен в истинности высказывания, а только лишь предполагает.

anonymous
()
Ответ на: комментарий от mbivanyuk

Разве политкорректно так говорить?

В США можно, там настоящая свобода слова в отличие от гейропейской показухи.

anonymous
()

Сразу видно крупного и уважаемого в IT мире разработчика!

SpaceRanger ★★★
()

Торвальдс всё правильно сказал за исключением того, что создатели HFS+ обезьяны. Эти дегенераты хуже обезьян.

Quasar ★★★★★
()

У всех все работает на HFS+
У Линуса не работает git на HFS+
HFS+ - говно

Ок.

urandom
()

А разве HFS+ НЕчувствительна к регистру? он ее с HFSX не путает?

ossa ★★
()

Обезьянами обыкновенными или онанирующими?

shrub ★★★★★
()

Линус - торт!

Как вендузятник говорю!

dk-
()

ilipnitsky

Ну еще бы уто бы написал. Этот школьник может еще 1000$ спустит на развитие HFS+?

Torvalds

А этот ваще Школьник. Ибо HFS+ умеет стопудово в SSD, в то время как детища Линуксостроения имеют ограниченную поддержку ssd.

bookman900 ★★★★★
()

про нечувствительность к регистру:

Имхо:
1. Для системы\софта и т.п., конечно же лучше, когда буквы в разном регистре - это разные буквы.
2. Но для человека в быту это менее удобно. И я рад, что в моей оси «Каталог» и «КАТАЛОГ» - одно и то же.

dk-
()
Ответ на: комментарий от Deleted

Разве там нельзя включить чувствительность к регистру?

Можно. Он там как раз жалуется, что оно где-то запрятано и не форсится ябблом.

AP ★★★★★
()

Напомните, зачем в питухоси (а также в винде) в принципе была нужна поддержка юникода на уровне файловой системы. Есть же непрозрачные байтовые строки, как в онтопике.

d_a ★★★★★
()

Записал через ntfs-3g два файла с одинаковыми именами но в разных регистрах, Шинда загрузилась и даже chkdsk не ругался. Правда доступ был только к тому файлу, у которого в имени первым встречался символ в верхнем регистре. После удаления первого файла, появился доступ ко второму. Так что дело не в ntfs, а в шин32.

Khnazile ★★★★★
()
Ответ на: про нечувствительность к регистру: от dk-

Читать оригинальный пост, а не бредни переводчиков/копипастеров. Там не столько про нечувствительность к регистру, сколько про NFD и то, как это реализовано в HFS+. Естественно технические подробности все упустили.

ncrmnt ★★★★★
()
Ответ на: комментарий от d_a

Напомните, зачем в питухоси (а также в винде) в принципе была нужна поддержка юникода на уровне файловой системы. Есть же непрозрачные байтовые строки, как в онтопике.

А как без поддержки юникода назвать файл у которого первое слово на китайском, а второе на русском?

Loki13 ★★★★★
()

А что думает Линус про CUPS?

praseodim ★★★★★
()
Ответ на: комментарий от Stahl

Нюансы юникода в том, что вообще говоря это очень сложная штука, гораздо сложнее чем привычные всем UCS2/4. Может такое быть, что перевод буквы в верхний регистр есть, а в нижний нет. Или что есть несколько вариантов перевода в другой регистр, в результате перевод не транзитивен, вверх-вниз-вверх дает другой символ, не тот что был в начале. Или что символ состоит из трех - буква, диакритика и модификатор, который преобразовывается в один, а потом при обратном преобразовании опять в один. Или наоборот - в немецком ß (нижний регистр) преобразовывается в SS. Или один и тот же символ с диакритикой нижнего регистра в одних языках преобразовывается вверх с диакритикой, а в других диакритика отбрасывается.

shimshimshim
()
Ответ на: комментарий от Loki13

Напомните, зачем в питухоси (а также в винде) в принципе была нужна поддержка юникода на уровне файловой системы. Есть же непрозрачные байтовые строки, как в онтопике.

А как без поддержки юникода назвать файл у которого первое слово на китайском, а второе на русском?

Выделил для тебя жирным ключевое место.

d_a ★★★★★
()
Ответ на: комментарий от shimshimshim

Т.е. нормальным бескостыльным образом игнорирование регистра для юникода сделать невозможно и Линус как всегда прав?

Stahl ★★☆
()
Ответ на: комментарий от Stahl

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

shimshimshim
()
Ответ на: комментарий от d_a

Выделил для тебя жирным ключевое место.

Т.е. ты предлагаешь чтобы ОС навешивала кучу костылей на ФС без поддержки юникода?

Loki13 ★★★★★
()
Ответ на: комментарий от bookman900

Линуксостроения умеют голый NAND, что делает SSD не особо нужным.

Quasar ★★★★★
()

Видел на одной странице

Сабж.

EXL ★★★★★
()

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

Miguel ★★★★★
()

а разработчиков Apple – обезьянами

Такие смешные… Лучше бы за своим говнокодом следили бы.

What_nick
()

https://plus.google.com/ JunioCHamano/posts/1Bpaj3e3Rru

Для Ъ:

Sure, it's old. Sure, it does a horrible job of actually protecting your data. But those are more «it's not a great filesystem» issues. They aren't «that's incredible crap designed by morons that have a hard time figuring out how to feed themselves».

The true horrors of HFS+ are not in how it's not a great filesystem, but in how it's actively designed to be a bad filesystem by people who thought they had good ideas.

The case insensitivity is just a horribly bad idea, and Applie could have pushed fixing it. They didn't. Instead, they doubled down on a bad idea, and actively extended it - very very badly - to unicode. And it's not even UTF-8, it's UCS2 I think.

Ok, so NTFS did some of the same. But apple really took it to the next level with HFS+.

There's some excuse for case insensitivity in a legacy model («We didn't know better»). But people who think unicode equivalency comparisons are a good idea in a filesystem shouldn't be allowed to play in that space. Give them some paste, and let them sit in a corner eating it. They'll be happy, and they won't be messing up your system.

And then picking NFD normalization - and making it visible, and actively converting correct unicode into that absolutely horrible format, that's just inexcusable. Even the people who think normalization is a good thing admit that NFD is a bad format, and certainly not for data exchange. It's not even «paste-eater» quality thinking. It's actually actively corrupting user data. By design. Christ.

And Apple let these monkeys work on their filesystem? Seriously?

There are lots of good reasons to not move to ZFS (cough-Oracle-cough), but they could have pushed people to case-sensitive HFS+, which would have then made it much easier to (in the long run) migrate to anything else saner. But no. There is a case sensitive option, but Apple actively hides it and doesn't support it.

The stupidity, it burns.

Manhunt ★★★★★
()
Ответ на: комментарий от Loki13

Т.е. ты предлагаешь чтобы ОС навешивала кучу костылей на ФС без поддержки юникода?

Я интересовался, цитирую ещё раз:

зачем в питухоси (а также в винде) в принципе была нужна поддержка юникода на уровне файловой системы

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

d_a ★★★★★
()
Ответ на: комментарий от Stahl

Там тихий ужас начинается мягко говоря:

Notes Only 1:1 character mapping can be performed by this function, e.g. the Greek uppercase letter 'Σ' has two lowercase forms, depending on the position in a word: 'σ' and 'ς'. A call to std::tolower cannot be used to obtain the correct lowercase form in this case.

Внезапно, оказывается у символа может быть не одно lower-case представление.

http://en.cppreference.com/w/cpp/locale/tolower

invy ★★★★★
()

Судя по всему, как NTFS, так и HFS+ нечувствительны к регистру

Судя по всему, 2+2=4.

P.S. HFS+ всегда умела быть чувствительной к этому самому регистру, если её попросить. Так что шутка действительно странная.

asaw ★★★★★
()

Что-то я не понимаю, HFS+ же можно сконфигурировать с чувствительностью к регистру.

Она только из-за регистра плохая или еще почему-то?

hibou ★★★★★
()
Последнее исправление: hibou (всего исправлений: 1)

Судя по всему, как NTFS, так и HFS+ нечувствительны к регистру, и это создает определенные проблемы.

Ну и школьник, этот ваш Линус. После такого вообще стрёмно его поделие использовать.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от AP

это можно выбрать при форматировании, мышкой, прямо в том же окне.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Manhunt

Во, так и оказалось: сам Линус и не писал, что «по-видимому 2+2=4».

asaw ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.