В ответ на публикацию исправления проблемы, связанной с поддержкой работы ФС Bcachefs в режиме без учёта регистра символов в именах каталогов, Линус Торвальдс заявил, что разработчики ФС видимо не способны учиться на своих ошибках, поскольку это далеко не первая проблема в коде обработки регистронезависимости...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63149
Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются новые правила. Одна программа может поддерживать одну версию стандарта, а другая другую и их поведение в обработке одинаковых данных будет отличаться.
> Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются новые правилаКакие например?
>> Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются новые правила
> Какие например?Черт знает насчет стандарта - а например андроида дико колбасит при попытке засэйвить имена файлов с цветными смайликами.
При том иногда оно умудряется - засэйвить. Но тогда - какая-нибудь программа типа индексатора или файлменеджера начинает выдаваьт совершенно левые сообщения при попытках что-то делать с этим файлом. И наверняка в софте есть более 9000 вулнов которые можно на этой почве проэксплуатировать.
Когда видение ОС/ФС и программы расходятся это целый класс багов, desync. Типа атак на HTTP хидеры когда разный парсинг там и тут юзается для чего-то полезного атакующему. Вот тут у вас deny не сработал и файло - умыкнули, а вот тут - файло удалось переписать леваком. А вот тут - вообще удалось ваши системы заклинить. Это мощный - и забавный - класс багов. Где очень сложно понять с какой стороны подстав вообще ждать. Торвальдс набрал достаточно опыта чтобы тоже это усвоить. Чем он и крут.
Стандарт Юникода нельзя сравнивать со Стандартами языков программирования. В Юникоде кодовые позиции символов не пересматриваются. Каждый следующий стандарт привязывает к определённой кодовой позиции какой-либо символ.
... к незанятой кодовой позиции, какой-нибудь "новый" символ.
Он-то как раз и учёл. И прямо об этом говорит.
И появляются не "правила", а новые символы и новые, дополнительные интерпретации. Старое не ломается.
> Он ещё не учёл, что в каждой новой версии стандарта Unicode появляются
> новые правила. Одна программа может поддерживать одну версию стандарта, а другая
> другую и их поведение в обработке одинаковых данных будет отличаться.Он как раз в правильной точке чтобы наесться всего этого жуткого булшита досыта. И именно поэтому и выступил с такой отповедью. Он буквально сказал: разработчики пытаются найти правильное решение задачи, выкатывая исправления. Проблема в том что нельзя сделать явно кривое действие - правильным. Правильного решения этой проблемы не существует в природе. Должен же кто-то сказать это борцам с ветряными мельницами, когда они увлекшись очередной атакой на проклятого монстра - забыли что это вообще смысла не имеет?!
Больше всего мне нравятся толкователи слов учителя. Но обычно толкованием занимаются после смерти, а тут ещё при жизни. Повезло ему.
> Больше всего мне нравятся толкователи слов учителя. Но обычно толкованием занимаются
> после смерти, а тут ещё при жизни. Повезло ему.Я способный ученик. Поэтому могу взять да укатать этим классом багов в репу, без ложной скромности. Поэтому понимаю о чем он говорит. Он вот тоже - пришел к тем же выводам. Ему тоже не хочется иметь дело с целым классом вулнов из разряда "desync" на ровном месте.
Типичная ситуация, когда борятся со следствием, а не решают проблему.
> Типичная ситуация, когда борятся со следствием, а не решают проблему.Вот Торвальдс и сказал что решать надо - проблему. Как то - наворачивание потуг придавать байтам и их комбо специальный смысл вместо того чтобы просто и брутально сохранить как есть, с минимумом ограничений ("can't contain null and /") - ведет к великому множеству дурных факапов на ровном месте.
Зеня вон даже любезно подогнал примеры файликов как вам ВНЕЗАПНО можно попробовать перезапиать файло. Или стырить его - нарушив ACL. ЧСХ в виндах точно были факапы с тырингом внеплановых файлов через HTTP сервера, черех вулны с именами. По моему даже чуть ли не в IIS не говоря уж о других :)
Удобно же когда некто deny на СуперСекретныйФайл влепил, но он все равно - скачался как суперсекретныйфайл, если софт тупанул :)
> Торвальдс сообщил, что времена FAT давно закончилисьEFI system partition уже можно в ext4 ?!!
Разрешаю!
Можешь реализовать, а мы посмотрим.
Кто сказал CoreBoot и CanoeBoot?
KogoeBoot?
Das U-Boot
U96: Das Boot
>Maximum velocity
>Das boot
>System activated
вообще можно.. но стандарт требует от производителей ефи добавлять только минимальный набор драйверов среди которых нет ехт4, но он не запрещает его добавлять а значит можно иметь ефи систем партишн на любом разделе.
А исполняемые файлы EFI в формате ELF можно?
В маке вроде hfs+? =)
В маке APFS.
В смысле? Вы в курсе что если в новой системе форматировать диск в ext4 в его в старой системе (где то же есть ext4) не сможете даже примонтировать !
для переноса данных используется ext3, а для починки новой системы не используйте древний rescue. а спасти данные можно - читать то можно, только писать нельзя...
ему не надо чинить. Там на старой системе отказ монтировать из-за того, что диск отформатирован с поддержкой фич, о которых старое ядро внезапно не знает.
это да
но с другой стороны, не невыпускать же новые версии теперь
наверное можно указать уровень совместимости при создании, чтобы при смене дистриба не напороться
Монтируйте в ext2.
ESP - это ошибка
Точно!
Надо UKI сразу в ПЗУ шить. 😏
> Точно!
> Надо UKI сразу в ПЗУ шить. 😏Рассматривая мини-линуз-как-бутлоадер в SPI флешке - да ты телепат почти?!
> EFI system partition уже можно в ext4 ?!!Можно, и не только в ext4: https://efi.akeo.ie/downloads/efifs-1.11/x64/
Там ext4 нету. Но я знаю, где есть. :) Только куда их положить, чтобы заработало? (:
> Там ext4 нетуЕсть. ext2_x64.efi -- общий драйвер для ФС семейства ext*
> Только куда их положить, чтобы заработало?
Сначала по этой инструкции https://github.com/pbatard/efifs/wiki/Adding-a-driver-to-a-U... (раздел "Creating the UEFI firmware module") драйвер нужно преобразовать в формат, понятный прошивке. Потом любым рабочим способом добавляешь получившийся модуль в образ биоса, после чего прошиваешь. Только учти, что обычными утилитами модифицированную прошивку не залить -- нужно либо снимать защиту вручную (как -- гугли сам, я уже не помню деталей), либо использовать программатор.
Ну да, времена FAT может и закончились, а вот мс до сих пор жив - поэтому секуре в бут вам всем, пока эту нежить не закопаете.
>> Торвальдс сообщил, что времена FAT давно закончились
> EFI system partition уже можно в ext4 ?!!Теоретически там хоть btrfs можно. Практически - зависит от того какие драйвера ФС в фирмвари были.
Воткните нужный драйвер в фирмварь и вперед. Вантуз правда будет в некотором удивлении и не сможет обновлять загрузчик. Но это может и хорошо :).
Куда именно воткнуть? (:
> Куда именно воткнуть? (:В образ фирмвари, куда ж еще. Да, для этого его придется перегенерять.
Все правильно сказал. Регистронезависимость -- это Приколюха™, которую нам подложили диды. Те же самые диды, которые решили, что было бы Прикольно™, если бы IP-адреса записывались не только как десятичные числа через точку, но и как всякие там 127.1, 0x7f.0.0.1 и еще какая-нибудь ересь.
Молодому поколению похоже не объяснили, что ip-адрес это просто число. А запись числа может быть любой.
Старшему поколению походу не объяснили, что поддерживать множество способов ввода числа нужно сразу везде: во всех приложениях с полем ввода IP-адреса, во всех библиотеках, парсящих IP-адрес из строки. В итоге разные приложения/библы поддерживают разную часть Прикольного™ RFC.
А по какой причине предъява людям, придумавшим ИП, а не писателям программ втч себе?!
> А запись числа может быть любой.А есть хотя бы одна причина использовать какие-то числа кроме ОБЫЧНЫХ ?
Чуви явно не видел IP-адреса IPv6. Ничего, подрастёшь и узнаешь, а пока делай ДЗ и кушай кашку
> А есть хотя бы одна причина использовать какие-то числа кроме ОБЫЧНЫХ ?Что такое "обычные" числа? Беззнаковые целые длиной 8, 16, 32, 64 бита? Знаковые той же длины? Т.н. числа с плавающей точкой? Это раз.
Два - вон там рядом новость про qbittorrent. Торрентами пользуетесь? Наверняка. А в их спецификации есть такая штука, как DHT. Где идентификатор каждого узла - число в 20 байт длинной. Более того, для работы DHT над такими числами ещё и разные операции совершать нужно - XOR, сравнение. Шифрование - тоже внезапно сплошь и рядом работа с "длинной" арифметикой. А без шифрования вы бы даже сюда не попали - сайт то скорее всего по протоколу https загружен.
> узла - число в 20 байт длинной. Более того, для работы
> DHT над такими числами ещё и разные операции совершать нужно -
> XOR, сравнение. Шифрование - тоже внезапно сплошь и рядом работа с
> "длинной" арифметикой. А без шифрования вы бы даже сюда не попали
> - сайт то скорее всего по протоколу https загружен.Более того - когда вы будете делать операции над числом 20 байтов размером - вы заодно невольно озаботитесь и endianess :) ибо есть минимум 2 способа записать такое число в память. Начиная с старшего байта, или с младшего.
> Более того - когда вы будете делать операции над числом 20 байтов размером - вы заодно невольно озаботитесь и endianess :) ибо есть минимум 2 способа записать такое число в память.Совершенно не важно, как число лежит в памяти. Результат a+b не должен зависеть от расположения байт, это гарантирует язык программироавания (например, Си). endianess появляется, когда вы хотите отправить это число на другое устройчтво.
> Совершенно не важно, как число лежит в памяти.Вообще-то важно. Ибо мы храним это число грубо говоря, как uint8_t whatever[20]. И вот тут возникает вопрос: whatever[0] это MSB или LSB этого числа? Сия договоренность также может влиять на транспортный формат. Если мы выстреливаем 20 байтов в провол - который из них будет первым в проводе? И что он представляет? Это важно для имплементера альтернативной реализации, который будет сам имплементить совместимое решение по спекам, а не "возьмите нашу волшебную фигню".
Это же будет колыхать и при чтении допустим файла в память. Потому что запись 20 байтов в файл - это запись 20 байтов в файл. Само по себе ничего не говорит как эти байты трактовать.
> Результат a+b не должен зависеть от расположения байт,
Вообще-то он таки будет зависеть от него при операции с 20-байтовым (160-битным) числом ибо делая математику "этажеркой" надо заморочиться в какую сторону carry делать.
Если что я писал сравнимую "широкую" математику. Ну напиши допустим сравнение A vs B на тему ">" или "<" не учитывая где MSB а где LSB в представлении something[20]. Это как бы влияет на то какой индекс надо первым чекать.
> это гарантирует язык программироавания (например, Си).
Покажи мне в си работу с целыми integer, размером 2^160. Вон тому типу это надо - для DHT, там адресация 160 битов. Ну и кроме всего прочего с этими числами делается математика. Конечно есть либы для big int, но тот вопрос полностью не отвалится и там - и они могут быть и не оптимальны для частного случая 1 конкретной математики фиксированной - но большой - ширины.
А еще бывает математика с КАСТОМНЫМИ правилами. Что такое "operator +" и "operator -" или например "operator > " в той или иной математике может здорово варьироваться. Если сомневаетесь посмотрите на поля галуа допустим. А круто когда "operator +" определен так же как "operator -" и результат операций - одинаковый? :)
> endianess появляется, когда вы хотите отправить это число на другое устройчтво.
У вон того кадра это DHT, там это by default. Но вообще-то оно появляется и без отправки. Скажем реализуй "operator >" без знания где у тебя MSB и LSB?!
> Совершенно не важно, как число лежит в памяти. Результат a+b не должен
> зависеть от расположения байт, это гарантирует язык программироавания (например, Си).
> endianess появляется, когда вы хотите отправить это число на другое устройчтво.ЯП вам ничего не гарантирует в этом плане. Потому что порядок байт зависит от процессора. ЯП (если говорим про С/С++) вам гарантирует лишь то, что при операциях со стандартными типами результат вычислений будет корректным для данного конкретного типа данных (сейчас опускаем нюансы с обработкой переполнения типа). Потому что в большинстве случаев работа с типами диапазона 8-bit-64-bit и порядком байт "вшита" на уровне процессора. То же относится к типам float и double (для них даже отдельный сопроцессор бывает). Там есть нюансы - например 64-bit типы на 32-bit процессорах обычно обрабатываются "программно", а не "аппаратно" - я же сейчас говорю в общем и целом, про то, что актуально для архитектуры х86_64. Интересное начинается тогда, когда вам нужно всё это дело в каком-либо виде представлять человеку. Потому что вам нужно бинарное число, которое суть есть просто массив с n байт, преобразовать например в массив байт в кодировке ASCII (которая обычно для вывода чисел и используется). Т.е. вам нужно прочитать массив байт числа в определенном порядке, затем привести его к определённому основанию (например преобразовать в десятичное число, или в шестнадцатиричное) и вывести на печать в определённой кодировке. Операции приведения к основанию и перевода в кодировку обычно совмещены в единое целое.
Более того, стандартные типы чисел в С/С++ такие, какие они есть, потому что их делали на базе поведения процессоров. Поэтому в частности претензии растовиков к undefined behavior выглядят очень смешно для того, кто хоть немного понимает о чём речь. Иными словами, когда вам кто-то пытается втереть про undefined behavior для числовых типов в С/С++, знайте - этот человек просто ничего не понимает в программировании. И скорее всего продвигает чьи-то корыстные интересы. Но это так, к слову.
И да, если вам нужно передавать "сырые" байты с устройства на устройство, порядок байт может сказываться. Поэтому например для Internet Protocol (те самые ip адреса) чётко прописано, что для ipv4 адрес - это big endian 32-bit беззнаковое целое. А порт - big endian 16-bit беззнаковое целое. И если вы реализуете какой-то собственный сетевой протокол, то очень желательно сразу чётко оговаривать, в каком виде у вас будут передаваться числа.
> что их делали на базе поведения процессоров. Поэтому в частности претензии
> растовиков к undefined behavior выглядят очень смешно для того, кто хоть
> немного понимает о чём речь.Вообще-то ничего смешного тут нет. Ибо упростили жизнь комитету и имплементерам компилера - ценой дохрена левых багов которых вообще быть не должно было.
В частности то что сишка делает с signed int over/underflow и integer promition это за гранью добра и зла. И с enum - тоже.
В хрусте хватило ума хотя-бы не пытаться заметать проблему под ковер а честно пофиксить. Да, путем усложнения компилера. Но 1 раз наверное можно и подраспереться чтобы ВООБЩЕ ВСЕЙ ПЛАНЕТОЙ не огребать глупейшие баги, оптом, где их быть не должно. В C23 и соотв C++ комитет ьбакланов даже чуть попустило, signed int теперь только в twos complement можно, и все остальное noncompliant. Но, блин, долбаные пасатижи, доделать до well defined behavior ДО КОНЦА - ИХ НЕ ХВАТИЛО. Чтобы wrap в этом случае был строго регламентирован.
> Иными словами, когда вам кто-то пытается
> втереть про undefined behavior для числовых типов в С/С++, знайте -
> этот человек просто ничего не понимает в программировании.Или что вероятнее - задолбался прыгать по граблям которых быть вообще не должно было. Ибо правила си в работе с integer оставляют желать много лучшего. Это я как махровый сишник говорю. Это источник грабель.
> И скорее всего продвигает чьи-то корыстные интересы. Но это так, к слову.
Или кто-то не понял что premature optimization is a root of all evil (c) D.Knuth.
> И да, если вам нужно передавать "сырые" байты с устройства на устройство,
> порядок байт может сказываться. Поэтому например для Internet Protocol (те самые
> ip адреса) чётко прописано, что для ipv4 адрес - это big
> endian 32-bit беззнаковое целое. А порт - big endian 16-bit беззнаковое
> целое. И если вы реализуете какой-то собственный сетевой протокол, то очень
> желательно сразу чётко оговаривать, в каком виде у вас будут передаваться
> числа.Если это не оговарить - первый же имплементер альтернативной реализации покроет вас последними словами. А уж что будет на машине с другим endianess... поэтому такой подход в целом - не годится для всего что IO делает. А compute-only задач на этом глобусе не так уж и много, особенно совсем без IO с хоть чем-то.
> Вообще-то ничего смешного тут нет. Ибо упростили жизнь комитету и имплементерам компилера
> - ценой дохрена левых багов которых вообще быть не должно было.Не обижайтесь, но это именно, что смешно ;) Проще говоря, вы - живая иллюстрация моих слов. Почему - объясню чуть ниже.
> В частности то что сишка делает с signed int over/underflow и integer
> promition это за гранью добра и зла. И с enum -
> тоже.Вот это например. "сишка" ничего с этим не делает, а делает процессор. И если у вас переполнение - то вы сам себе злобный буратино, ибо не учли, что у вас числа могут "выезжать" за границы используемого типа данных. А процессор делает ровно то, что вы ему сказали делать.
> В хрусте хватило ума хотя-бы не пытаться заметать проблему под ковер а
> честно пофиксить. Да, путем усложнения компилера. Но 1 раз наверное можно
> и подраспереться чтобы ВООБЩЕ ВСЕЙ ПЛАНЕТОЙ не огребать глупейшие баги, оптом,
> где их быть не должно. В C23 и соотв C++ комитет
> ьбакланов даже чуть попустило, signed int теперь только в twos complement
> можно, и все остальное noncompliant. Но, блин, долбаные пасатижи, доделать до
> well defined behavior ДО КОНЦА - ИХ НЕ ХВАТИЛО. Чтобы wrap
> в этом случае был строго регламентирован.Ну т.е. "махровый сишник" даже не подозревает о существовании типов фиксированной длины.
Всяких там uint32_t и подобного. И не понимает, для чего нужны типы int, unsigned int, и почему они именно такие. Ну-ну.> Или что вероятнее - задолбался прыгать по граблям которых быть вообще не
> должно было. Ибо правила си в работе с integer оставляют желать
> много лучшего. Это я как махровый сишник говорю. Это источник грабель.Это вы мне как очередной, нанятый за копеечку строчить комментарии, говорите. Уж извините за прямоту. Понимаю, жизнь бывает тяжёлая, но не стоит таким заниматься. Это вам же и отольётся в будущем, когда очередной, наслушавшийся вас неофит вообразит, что очередной же "суперсовременный" ЯП решит все проблемы за него и полезет писать на нём прошивку системы управления ядерным реактором или автопилотом самолёта. А источник грабель в данном случае лишь "программист", который не понимает как это всё работает.
> Или кто-то не понял что premature optimization is a root of all
> evil (c) D.Knuth.А это здесь причём?))
> Более того - когда вы будете делать операции над числом 20 байтов
> размером - вы заодно невольно озаботитесь и endianess :) ибо есть
> минимум 2 способа записать такое число в память. Начиная с старшего
> байта, или с младшего.Именно.
16тиричная система не так уж и плоха для адресов от 00 до ff в каждом из 4 сегментов адреса. 7F.0.0.1 или C0.A8.0.1 выглядит ничуть не хуже десятичной системы, даже как-то лаконичнее.
Суть не в том, хуже или лучше шестнадцатиричная запись десятичной. А в том, что вариант должен быть один, потому что это стандарт. Нет ни единой причины использовать много вариантов там, где можно использовать один. Было бы сэкономлено много человеколет, если бы стандартодатели выбрали бы один вариант для записи ip-адреса.
> Суть не в том, хуже или лучше шестнадцатиричная запись десятичной. А в
> том, что вариант должен быть один, потому что это стандарт.Тогда это должен быть хекс, вероятно. Ибо представлять байты как именно десятичные значения - тот еще изврат. Это и парсить не особо удобно, и тому как хранится не соответствует.
> Нет ни единой причины использовать много вариантов там, где можно использовать один.
В IPv6 придумали, блин, сразу несколько причин. Увы и ах.
> Было бы сэкономлено много человеколет, если бы стандартодатели выбрали бы один
> вариант для записи ip-адреса.Бы - не считается. Скажем для v6 сокращенная форма есть. Или еще вариант для link local. Не очень хорошо с их стороны но где ж вы тогда были?
> выглядит ничуть не хуже десятичной системы, даже как-то лаконичнее.Речь про сопровождение двух взаимоисключающих форматов записи.
Есть куча кода, для которого ip адрес это четыре байтовых числа через точку.
Твоё удобство и лаконичность я поддерживать не собираюсь
> Есть куча кода, для которого ip адрес это четыре байтовых числа через точку.Вот это, как раз, и нестандартное использование IP адреса. Ведь известно, что IP адрес - это 4х байтовый беззнаковый int.
>> Есть куча кода, для которого ip адрес это четыре байтовых числа через точку.
> Вот это, как раз, и нестандартное использование IP адреса. Ведь известно, что
> IP адрес - это 4х байтовый беззнаковый int.Int - это как правило нечто вообще хзкакого размера и endianess. А IPv4 это вполне себе 4 байта в вполне конкретном порядке. И нехило это как раз подчеркнуть.
Для IPv6... ну вы его по другому и не захотите особо записывать. Ибо если вы попробуете это как uint128 напечатать, да еще ктулху упаси в десятичной системе ... ух... удачи! Как видите этот номер как раз - не работал.
Разделение на октеты важно, оно позволяет видеть некторые вещи на глаз, скажем "тот же это subnet или нет". Удобно, быстро, визуально. Вы охренеете с какой скоростью devops ворочают такие вещи.
а обычные у вас это какие числа?
> у васЗайди в магазин, купи 0xFA3 гвоздей
> Зайди в магазин, купи 0xFA3 гвоздейНахрен тебе их столько? В таком количестве их обычно уже на вес норовят продавать. Кто ж их будет пересчитывать в таком объеме? :)
@то в штуках, килограммах, а может быть в фунтах ?
Эффективное хранения в памяти.
Для IPv4 ровно 4 байта нужно.
Да оно так и в любой системе и хранится, но интерпретация этих 4 байт может быть разной.
Попробуйте попинговать адре типа 192.168.0.10 и 192.168.0.010. Меня результат удивил.
Во втором случае ping идет на 192.168.0.8. Почему?
Подсказка: ping 192.168.0.0x10
Т.е. программу не смущает, что часть нужно интерпретировать в десятичном формате, и часть в шестнадцатиричном? Видимо, есть какой-то алгоритм, т.е. каждый октет по порядку проверяет на принадлежность к системе счисления.
Внезапно 010 - это число в восьмиричной системе. Если в десятичную перевести как раз 8 будет. Вообще программирование это про числа а не так как сейчас многие привыкли....
Во всяких устройствах с недоношенным вводом, типа телевизоров, одно-двухзначные адреса как раз добиваются нулями в начале. И при этом работают как без нулей.
Видимо, это от самой программы зависит то, как она обрабатывает входные данные.
> 0x7f.0.0.1ужас. кошмар. Но я знаю одного человечка, который в HTTP статусах возвращал 0x404 и 0x200.
Он думал, что хакеры вот так по крутому числа пишут, наверное
Не мог он возвращать 0х404. На что вы намекаете? Говорите прямо
> Не мог он возвращать 0х404. На что вы намекаете? Говорите прямо
>> Не мог он возвращать 0х404. На что вы намекаете? Говорите прямо
> https://paste.pics/800754f3080456c9627bfe0ef0180452Это видимо дотнетчик был, или накрайняк жабист, судя по коду который с трудом влезает на экран на здоровенном мониторе.
> 0х200HTTP статус-код 512 не является стандартным кодом; он был предложен для использования в определенных приложениях, чтобы указывать на ошибку сервера, когда произошла хотя бы одна ошибка.
Мдя..
Вас это удивит, но наберите в браузере http://3644916501/63149
Однако
молодец. Теперь бери этот айпишник - 3644916501 - и попробуй его вводить во все остальные проги: настройки прокси-сервера, нетворк-менеджер, какой-нибудь ip route add, cli докера, пинг, а еще вот сюда: https://www.wikihow.com/images/thumb/2/25/Find-Your-Subnet-M...
Поэтому и изобретают json, потому как думают, что всё должно быть читаемым. Им же не приходит на ум, что процессор видит только числа и никаких скобок и прочего.
> Поэтому и изобретают json, потому как думают, что всё должно быть читаемым.
> Им же не приходит на ум, что процессор видит только числа
> и никаких скобок и прочего.И его тоже полностью в полном виде - как generic - корректно от и до не парсит почти никто из существуюшего софта :). А реакция на "нежданчики" у софта бывает самой разной. Экспериментируйте - и вы найдете много вещей которых эти, которым не хочется напрягаться, забыли предусмотреть. Это позволит вам извлечь море лулзов.
Ну вот например я какого-то бота подвесил насмерть. Он просто не ожидал мой формат выхлопа и кажется очень увлекся парсингом. Посмотрим как такой оборот его владельцу :)
Это что такое?!
Меня это ОЧЕНЬ удивило, спасибо.
Меня удивляет что это кого-то удивляет. И много ли тут людей меньше 20?
"Экслера не читали" (с) что там было про обходы сквида ? Сколько там прошло - лет 20-25 ?Ну что, новое поколение пытается пройтись по тем же граблям :-)
И это неплохо, раз читать они так и не научились.
ты прав, малолетки придумали ipv6, у которого формы записи куда более логичны
Ну вот маску подсети можно было бы как-то проще делать или наоборот - более интересно. Хорошо хоть короткую преамбулу придумали и на этом спасибо.
Ну дык пиши netmsk 0xffffff00
Жиза, только сегодня пришлось иметь дело с renpy и файлы были в рандомном регистре повсюду. Часто с электроном то же самое.
Пингвин прав - регистронезависимые имена файлов это сознательное упрощение для первых неискушённых пользователей персональных компьютеров времён MS-DOS с кодировкой ASCII, чтобы им было проще освоить диковинную чудо-технику. Но сейчас-то все уже прошаренные - называют файлы большими и маленькими буквами, некоторые даже с пробелами)) Зачем тащить этот анахронизм в сегодняшнее время? Тем более в юникоде понятие регистра действительно крайне расплывчатое...
Некоторые даже в национальных кодировках, прикинь! Но, как правило - не ъ. Третьего дня мне тут пара человек зачесывала кто за название книг транслитом, кто против имен возможности имена пользователя\пароли в кодировках, отличных от дефолтной протестовал, кто на Power-Shell ругался...
В общем, те-о-ре-ти-чес-ки да, но нет.
Ага ! А ещё и с помощью эмодзи (где там птичий язык ?) ...Даёшь приведение эмодзи в нижний регистр !!! И чтоб библиотека была на языке, который нельзя называть !
Даже ASCII далек от адекватного. Что уж говорить про Unicode.
Но ведь и в ext4 недавно добавили nocase: https://www.opennet.dev/opennews/art.shtml?num=50581
Опционально. Очевидно - для узких нужд.
> Опционально. Очевидно - для узких нужд.А кстати, для каких? Всегда было любопытно
Для совместимости с уже существующими решениями.Например, при монтировании сетевой виндовой шары как cifs, регистр не учитывается.
Сервис, который с ней работает, ищет файлы по имени, а расширения перебирает по типам всегда в нижнем регистре.
Потребовалось сделать зеркало сервиса вместе с данными.Так как расширения у файлов стандартные и латиницей, но встречаются в любом регистре, а имена числовые, то было решено отформатировать раздел с этой опцией. Это позволило rsync-ом забирать только дельту.
Сами файлики выгружаются из ИС с сохранением исходного расширения, а добавляются пользователями. За годы работы их накопилось весьма много.
Разработчикам ушел запрос на доработку экспорта, по пока не переделали.
Тут скорее имело бы смысл сделать запрос на доработку поиска (игнорировать регистр расширений).Кейс понял, но если уже есть зеркало, приведение к нужному виду по идее решается массовым переименованием сначала с одной стороны, потом с другой, с переключением на одну файловую систему пока обрабатывается другая.
На самбе, емнип, все эти штуки с регистром и автоконвертацией имён решались настройками сервера.
в комплект к вайну. когда пытаешься виндовое что-то копировать, типа патча поверх, то может оказаться всё в разных регистрах
> А кстати, для каких? Всегда было любопытноЯ в код не смотрел, но подозреваю, что след тянется к Майкрософт. Они ж в последнее время активно начали в Линукс влазить и использовать его у себя. А имена файлов и папок без различия регистра - это именно их детище.
Маки тоже по дефолту apfs в case insensitive форматирует.
Всё верно сказал!
сердечки в юникоде еще и размер меняют?
>сердечки в юникоде еще и размер меняют?Не понял вопроса? Есть кодовая позиция, она может быть занята определённым символом, либо может быть незанятой, свободной. Если красному и чёрному сердцу отвели определённые кодовые позиции, то это разные символы. Если например, не вдаваясь в подробности просто, символ "сердце" привязяли к определённой кодовой позиции, и нет других привязок с графичеим русунком в форму сердца. То тогда все сердца разных форм и цветов будут считаться одним символом. Такова анатомия Юникода. Всё дело в привязке: "кодовая позиция = графический рисунок".
Сердечки в имени файла. Это мы заслужили. За такое надо было бить по рукам с самого начала, а теперь все эти dei расплодились.
> За такое надо было бить по рукам с самого началаА за умляуты в имени файла тоже? Это же такая наглость желать писать слово правильно!
А за иероглифы тоже?Слава богу таких даунито как ты никто не слушал. И позволили писать то, что они хотят.
Сперва сердечки разных цветов, потом буквы разных цветов. Это же круто, мы же всё можем. И причем тут национальные алфавиты? Там есть сердечки?
Бессердечные алфавиты!
>>> Сердечки в имени файла.
>> За такое надо было бить по рукам с самого начала
> А за умляуты в имени файла тоже?В первую очередь, бить надо за подобную гнилую софистику, когда демагог приравнивает спецсимволы (НЕ применяются для записи слов) к буквам (используются для записи слов) с целью развязать тупой спор.
> (НЕ применяются для записи слов)каким кодом в юникод закодирована "Ritratto di Monna Lisa del Giocondo"?
С чего бы анониму решать это? Хочу и использую, вот, держи 🤡
А за Unicode куда бить?
> Не понял вопроса?ну вот у "а" и "А" одна и таже буква, имеют разные коды, и мы говорим что "А" это буква "а" большого размера (верхнего регистра). Ну вот с буквами понятно, а понятие регистра разве у сердечек есть? "Красное сердечко" никоим образом не является "регистром" "черного сердечка", это два разных символа.
Строго говоря Юникод не знает таких понятий как "верхний регистр", "нижний регистр". Есть кодовая позиция, и есть прявязанный к конкретно данному коду, символ. И всё! Термины: "регистр", "глиф символа", "кегль", "шрифт" относятся к типографике, а не Юникоду.
Юникод оперирует такими понятиями, как направления письма (левое, правое), можно ли один символ комбинировать с другим символом (диакритика), тип разрыва строки.Кириллическое А = U+0410 - а это его кодовая позиция.
Кириллическое а - U+0430
Латинская A - U+0041
Латинская a - U+0061
Прям какой-то антипатерн "dont repeat your self" получается...
Это про
U+0410 и U+0041
U+0430 и U+0061
Если что
Сами-то символы одинаковые
Комитет стандартизирующий Юникод очень экономно подходит к "расходованию" кодовых позиций. Если комитет решил, что латинское "A" и кириллическое "А" разные символы значит на то были веские основания. Когда решают поместить какой либо символ в состав Юникода, тщательно изучается история данного символа.
А как вы объясните zalgo ?
> Строго говоря Юникод не знает таких понятий как "верхний регистр", "нижний регистр". Есть кодовая позиция, и есть прявязанный к конкретно данному коду, символ. И всё!Никто с этим не спорит, ибо юникод это средство кодирования символов того или иного алфавита языков, и других неязыковых (неграфических) символов. Вот смотрите:
//ru.wikipedia.org/wiki/Русский_алфавит
"""
Ру́сский алфави́т (ру́сская а́збука) — алфавит русского языка, включающий 33 буквы.
"""Ну это что за ересь? 33 звука - а не символа (буквы), ибо символы в таблице ниже там с разным регистром.
Аа, Бб, Вв, ... - и сколько в итоге букв? вот столько же и кодов в юникоде, и есть соглашение, что код условно 0001 - это символ "А", а 0002 - символ "а" это один и тот же звук в разном регистре. Для чего вообще придумали регистр символов это вообще другая тема обсуждения.
Но те же сердечки будучи символами условно "смузихлебного" алфавита разве имеют понятие регистра? "Черное сердечко" и "Красное сердечко" это два разных регистра одного сердечка получается? Или все же есть "Большое красное сердечко" и "маленькое красное сердечко"?
"""
(например, кто-то считает символы "❤" и "❤️" одинаковыми в режиме без учёта регистра, а кто-то нет)
"""с какого бодуна? разве не алфавит того или иного языка об этом должен говорить? Алфавит "смузихлебного" языка говорит, что это разный регистр одного сердечка?
> Такова анатомия Юникода. Всё дело в привязке: "кодовая позиция = графический рисунок".а что есть регистр? это "кодовая позиция('a') ~ кодовая позиция('A')"
Пивожор как-то забыл, что был ASCII одним регистром во времена, когда он ещё не умел списывать. И что filename должен быть именно что name, где Алекс, алекс и аЛеКс — это одно и то же, а смайлы должны запрещаться/меняться на всякие (0x444) и т.д.
Регистронезависимость в именах файлов — благо системного уровня, а не прикол от дедов.
Никто не виноват, что вас в шелле не научили эскейпить файлы и параметры в кавычки брать.
> был ASCII одним регистром во временаНикогда не был. Символы 'A' и 'a' имеют разные коды в ASCII
Вот да. Может в 1970х где-то и экономили битик.
Но уже́ в 80х была ASCII-7 и аналоги (7 бит). 127 символов (и 0-й байт) для кодирования регистрозависимой латиницы — выше крыши.* Я не настолько старый чтобы помнить причину изначально 7-битной кодировки. Но вроде в 8-й бит засовывали чётность для передачи по всяким-разным каналам.
Регистронезависимость в именах файлов - отрава и мина замедленного действия.
Как и регистрозависимость
Есть хоть одна техническая причина превращать одно имя файла в другое? Линус прав, имя файла - это просто набор байтов, и самый переносимый способ записывать имя - это любые байты, кроме '\0', '/' и ещё '\n', но во многих случаях даже он ничего не сломает. Если файловая система занимается подобной хренью, как превращение одних кодировок в другие или сменой регистра, то пусть будут добры занимать сразу ВСЕ возможные имена, если им делать нехрен.
Внезапно, в NTFS могут быть '\0' в имени файла. ;)
> Внезапно, в NTFS могут быть '\0' в имени файла. ;)О, круто, надо будет с HTTP серваком поэкспериментировать на юзерах винды, посмотреть сколько софта такие имена даунлоадов сожрать сможет - и что потом с юзерами винды и их софтом случится.
В линухе то такую диверсию зарубят прям на уровне сисколов. А вот в винде есть шансы что софт хорошенько налетит на том что такможнобыло с 1 стороны и 0x0 имеет специальное значение в C строках - с другой. Знаешь сколько сплойтов такого плана существует в этом мире? Видимо нет. Иначе не считал бы такие вещи - фичой. Вон там в ссылках написали несколько идей как юзеров винды можно огревать эксплойтами, через git и чего там еще, но это - далеко не полный список подарков им по линии ФС которые можно отгрузить при креативном подходе к вопросу.
И чем больше таких нежданчиков - тем больше шансов что тот или иной програмер продолбается и это будет - экслуатируемый вулн скорее всего.
Не вижу проблемы в создании стандарта с набором регистрозависимых символов, включающего только алфавиты существующих языков + что-то по иероглифам если там оно есть. Всё остальное не имеет регистра и не учитывается. Готов к решению следующей задачи
Ты предложил простое и неправильное решение. С турецким языком что делать будем, например? Там с английским регистры их версий I не совпадают: I → ı, İ → i.
Нашёл о чём капитанить, старый брюзжун. Лучше бы набросил на тему неактуальности древовидных ФС с их директориями/папками, симлинками и прочим.
> просто бесятся от того, что им приходилось пыриться в детстве в консольку.Вот не надо тут. Мне в детстве приходилось пыриться в интерфес, сделанный из вот такой cpaни
╔════════════════════╗
║░░░░░░░░░░░░░░░░░░░░║
║░░░░░░░░OPEN░░░░░░░░║
║░░░░░░░░░░░░░░░░░░░░║
╚════════════════════╝Но я совсем не против использования юникода в именах файлов.
В чем удобство использования Юникода в именах файлов?
> В чем удобство использования Юникода в именах файлов?Можно без обиняков обозвать файло "неведомая долбаная фигня ❤ и ❤️" и это даже будет корректно оотображаться. Но если удумать еще и регистр этого процессить... выйдет неведомая долбаная фигня! :)
Тут не с регистронезависимостью проблема, а с тем, что в именах файлов разрешена всякая дичь вроде вот этих юникодных сердечек.
Ну, иди расскажи японцам, что они должны файлы латиницей называть.
Проблема вообще не в символах, а всего лишь в синдроме утенка вскормленных Виндой.
Они считают правильной всю ту дичь, которую Микрософт накосорезил в своих системах в 1980-х - и продолжает бережно тащить ее в 2020-е.
Ну регистронезависимость важна при поиске. При обращении к файлу регистр однозначно должен соблюдаться, в противном случае имя файла нельзя представить в виде набора конкретных байт и тут все абстракции поехали... Как велосипед на квадратных колёсах!
Для обеспечения регистронезависимого поиска по файловой системе вовсе не требуется поддержка со стороны файловой системы
Против символов национальных алфавитов никто не против. А вот цветные смайлики в именах файлов... Зачем?
> Против символов национальных алфавитов никто не против.В чем разница? Написать 赤いハート или поставить ❤️?
> А вот цветные смайлики в именах файлов... Зачем?
Не зачем, а почему бы и нет. И то, и другое просто код юникода.
В данном случае проблема это "регистронезависимые файловые системы". Которые просто пережиток старых времен.
>> Против символов национальных алфавитов никто не против.
> В чем разница? Написать 赤いハート или поставить ❤️?Ну зачем так далеко ходить:
ͦpͤnnͤͭ - удачи любителям "независимости" подобрать тот самый, единственно-верный "регистронезависимый" вариант. Я уж не говорю о всяких скучных öäÜóß ... и о том, как ЭТО более-менее эффективно можно парсить.
> удачи любителям "независимости" подобрать тот самый,
> единственно-верный "регистронезависимый" вариант.А зачем тебе вообще "регистронезависимый" вариант? Чтобы со всяким старьем было совместимо?
Сейчас даже NTFS поддерживает case-sensitive.> Я уж не говорю о всяких скучных öäÜóß
Так как раз из-за того, что ß просто так в upper-case не конвертнешь, и нужно использовать case-insensitive!
>>Сейчас даже NTFS поддерживает case-sensitive.Да как бы не с W2K... Только в реестре отключено по дефолту и софту может чеку сорвать от таких фокусов.
>В чем разница? Написать 赤いハート или поставить ❤️?В количестве и комбинациях байт. Ели это имена файлов, то это два разных файла.
> А вот цветные смайлики в именах файлов... Зачем?Просто красиво,
Только найди потом файл с таким названием.
>> А вот цветные смайлики в именах файлов... Зачем?
> Просто красиво,
> Только найди потом файл с таким названием.У вас в find юникод сломали?
Ааа, ну с таким подходом можно что угодно нагромоздить. Было бы желание. Только пусть желающие это громоздят на своей системе, но нет же - навязывают остальному миру, ворую ресурсы цивилизации.
Затем, что когда-то иероглифы и были этими самыми смайликами, только не всегда цветными.
Ничего они, поди, email адреса то латиницей пишут, не обламываются.
> Ничего они, поди, email адреса то латиницей пишут, не обламываются.Боюсь, обламываются, но не они - 二ノ宮@黒川.日本, например.
Я извиняюсь, а японцы виндой пользуются? Там же все ФС регистронезависимые.
> Они считают правильной всю ту дичь, которую Микрософт накосорезил в своих системах в 1980-х - и продолжает бережно тащить ее в 2020-е.Ну в ненужное же тащат из 70х.
Напиши список разрешенных символов
Этот список уже до меня давно написали. ASCII называется.
Ну, ок, конвертнём в base64 и будем в таком виде хранить на диске, а в файлменеджере будем показывать исходную форму с сердечками, иероглифами и арабской вязью.
Товальдс такой жест придумал нвидии.
Ну это которым потом он, пазязя, напишите драйверы.
А чтой то не пишут драйверы для Нвидиа.
Молодец ну.
> в режиме без учёта регистраА теперь поиграйтесь в регистре где символы L I i l выглядят одинаково.
Если я хочу тебя взломать или обмануть это мне только плюс. Поэтому я буду продавливать регистронезависимость всеми силами.
Да не, иногда в шрифтах L выглядит как i, 0 как o, я про это.
Меня нечего взламывать, я не криптовалютчик.
Диды придумали нолик зачёркивать. И всё было хорошо, однозначно и недвусмысленно, пока не пришёл юникод со скандинавским Ø.
> пока не пришёл юникод со скандинавским Ø.Про ISO8859 ты, понятное дело, не в курсе.
> регистронезависимостьТак это как раз про регистрозависимость. В каком-нибудь досе или винде 3.1 по умолчанию все имена файлов заглавными буквами показываются, и сразу понятно, где L, а где I.
Не было такого в досе и 3.1. Прописными.
Я всегда говорил что Линус наш слоняра. Все правильно и по полочкам разложил.
Это называется дорисовка личности, ты дорисовываешь все хорошее, как бы игнорируя минусы, занимаясь самообманом.
Поздно рассуждать о боржоми, когда почки накрылись. Само появление не-ascii символов в именах файлов открыло ящик пандоры. ИЧСХ, если появится менеджер паролей i❤mypasswords или криптокошелёк i❤cryptocoins - найдутся лопухи, которые будут ими пользоваться, и их потом поимеет злой хакирь, который выпустит, соответственно, менеджер паролей i❤️mypasswords или криптокошелёк i❤️cryptocoins со зловредами внутри, в том же каталоге приложений.
> Поздно рассуждать о боржоми, когда почки накрылись. Само появление не-ascii символов в
> именах файлов открыло ящик пандоры.Как открыло, так и закроет. Немного боли и придет стандартизация.
>> Поздно рассуждать о боржоми, когда почки накрылись. Само появление не-ascii символов в
>> именах файлов открыло ящик пандоры.
> Как открыло, так и закроет. Немного боли и придет стандартизация.Который оно там год уже "приходит"? А тем временем нас заваливает пачками глупых вулнов и просто глюков на ровном месте.
> времена FAT давно закончилисьТут я бы поспорил. Даже на больших флешках, таких как 128 Гб, FAT32 прекрасно себя чувствует. По размеру кластера они вроде как с exFAT одинаковы. Единственный минус - нельзя создавать файлы больше 4 Гб.
FAT32 позволяет вставить флешку в телевизор, магнитолу, приставку, смартфон, и не думать "а поддерживается ли там exFAT или нет?".
По поводу юникода и FAT32. Поддерживается. Файлы со спецсимволами создаются. А во поводу регистров (а тем более регистров спецсимволов), ну, под Linux FAT32 case sensitive. А под виндой nocase. Но там и NTFS - nocase.
Разве речь о том, чтобы выпилять FAT32 из линукса?Речь о том, чтобы в новые ФС не тянуть старые неактуальные привычки.
> Разве речь о том, чтобы выпилять FAT32 из линукса?
> Речь о том, чтобы в новые ФС не тянуть старые неактуальные привычки.Ну не знаю, мне лично с nocase удобнее. Всяко лучше, чем иметь в одной папке файлы вида:
привет.txt
Привет.txt
ПрИвЕт.txt
привет.txT
> с nocase удобнее. Всяко лучше, чем иметь в одной папке файлы вида:
> привет.txt
> Привет.txt
> ПрИвЕт.txt
> привет.txTСоглашусь,
Temp
tempКруто., а теперь разберись какая из них, Temp, temp.
Это как пример.
> Круто., а теперь разберись какая из них, Temp, temp.
> Это как пример.Три буквы: FHS.
Никому не нужное нагромождение костылей, которого сам стандартизатор не придерживается.
> Три буквы: FHS.FHS, или фолликулостимулирующий гормон , — это гормон, вырабатываемый гипофизом как у мужчин, так и у женщин.
> Ну не знаю, мне лично с nocase удобнее. Всяко лучше, чем иметь
> в одной папке файлы вида:
> привет.txt
> Привет.txt
> ПрИвЕт.txt
> привет.txTГнилой виндузоид - палится сразу. Вон там для таких любезно штуки три CVE на основе такого упрощения. Представляешь, в уникоде топик кто кому upper case - весьма сложная штука. И это порождает неоднозначный парсинг.
Вот так вот тебе кто-то зальет ПрИвЕт.txt - а он и перезапишет привет.txt без спроса - хотя софт был уверен что все окей, файло же разное! При том понятие одинаковости и разности начинает еще и зависеть от программы - и попробуй вообще угадай где на тебя ВНЕЗАПНО упадет такой рояль.
> Гнилой виндузоид - палится сразу.А зачем останавливаться на одних только лишь именах файлов? Можно ещё емейлы делать типа lena@mailbox.org, Lena@mailbox.org, LeNa@mailbox.org, lenA@mailbox.org... Да чего уж там - сразу URL-ы серверов. Вот набираешь ты в адресной строке не google.com, а Google.com, и попадаешь на другой сайт. А ещё имена улиц можно делать "некрасова" и "Некрасива", и чтобы они находились в разных частях города. Не нравится? Ты что не современный?
> старые неактуальные привычкиЭто называется "обеспечивать совместимость, столь ценимую нашими корпоративными клиентами". Например, так:
Invalid file or folder names
Applies to: OneDrive for BusinessThese names aren't allowed for files or folders: .lock, CON, PRN, AUX, NUL, COM0 - COM9, LPT0 - LPT9, _vti_, desktop.ini, any filename starting with ~$.
Notes:
_vti_ can't be used anywhere in a file name.
forms can't be used when the folder or file is at the root level of a library.
゛and ဧ can't be used as the first character of a folder.
Торвальдс однозначно не прав.
Все эти свистелки и перделки разбаловали юзеров!Нужно делать как в RT-11.
6+3 длинна имени файла, и фиксированный набор "A—Z, 0—9, $, ., %"
Этого хватит всем!А то взяли моду придумывать длинные названия, да еще и какие-то сердечки туда пихать!!11
> Нужно делать как в RT-11.
> 6+3 длинна имени файла, и фиксированный набор "A—Z, 0—9, $, ., %"Ну вообще чем прощще тем лучше, тем это более надежнее, правда длинна имени файла коротка.
Насамом деле как в Windows, нормально вполне.
Или это такое развлечение, играться с именами файлов папок из таблицы символов, сомнительное развлечение.
Все эти регистры, Temp temp.
С точки зрения пользователя все же регистронезависимые имена удобны. И если проблема в похожих символах UTF-8, которые нельзя порой в нужный регистр привести, то может проблема в UTF-8?
Какие собственно проблемы хранить тогда локаль в файловой системе? Это от силы один байт. Да и при наличии локали отпадает необходимость в utf-8 или решает проблемы какими символами имя файла ограничить в utf-8. Главное графически отобразить локаль и будет сразу видно где турецкая l, а где английская l. Или чего там ещё. Ну а список эмодзи можно и ограничить, тогда и не будет проблем. У сердечек нет верхнего и нижнего регистра, это вообще картинка которая записана как символ в utf-8. Такие картинки порой решают некоторые проблемы программистов.
Такая, что это не очень совместимо с ФС.
Он очень умен он очень умен.
Торвальдс абсолютно прав. И правильное решение - прямо в винде включить регистрозависимые пути в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive=dword:00000000Для тех каталогов, где прям супер-нужно регистронезависмость можно её включить через fsutil.exe file setCaseSensitiveInfo <path> enable/disable
Ага, а потом сидеть гадать почему софтина не работает и пополнять список исключений
А весь секрет в том, что юникод - это не кодировка, юникод - это бинарный формат для хранения текстовой информации, наравне с odt, openxml и Microsoft doc/docx. Именно поэтому там есть "символы" типа "обратить весь последующий текст задом нарерёд" и подобные, о которых никто не в курсе. Стоит понять эту простую истину, и куча вопросов к юникоду, используемому в качестве кодировки, сразу отпадает.
> docxС каких пор он бинарный?
Мож байтовый?
Лично у меня и так к нему вопросов никаких нет. Я его не использую. Достаточно национальных кодировок.
Юникод - это попытка снова сделать одну кнопку для решения всех проблем, как, например, сделали с браузером. Впрочем с браузером скорее другое дело. Там, видимо, целенаправленно делали все для того, чтобы влезть каждому в ПК.
В винде ж как-то сделали.
Более того, там по ходу дискуссии дальше объясняют, что в винде NTFS как раз имеет правильное решение.
> NTFSНу потому что они не выпускают по +100500 файловых систем раз в два месяца.
А улучшают NTFS.
Да наверняка сделали только для широкоизвестных алфавитов. А остальное, как придётся.
А остальное, как придётся.Потому что гомункулы не равны между собой )
Товальдс, офигенный, парень.
В виде Легаси и совместимость. Которую надо тащить десятилетиями.
Пользуясь случаем "❤" и "❤️" Чиркову за дополнение оригинала - ссылками на конкретные вулны.
Проблема не стоит выеденного яйца. Микрософт скоро закопают окна в пользу Марины и регистронезависимость ни кому будет не нужна.
Маринка кде закопали она теперь Азер Линукс.
Да без разницы, логика ведет к тому, что окна рано или поздно будут закопаны вместе со всем своим барахлом, в т.ч и с регистронезависимостью.
А что эта? Новый виндопс?
Ну че там, пацан то Товальдс, как он там.
Краткое руководство по опеннету:
1. ругать решения майкрософта
2. точно такие же решения Applе (да-да, регистронезависимость) замалчивать либо хвалить
3. ???
4. PROFIT
> 1.А ругань где увидели-то?
> 2.
Вживую никогда не пользовался и не интересовался, сказать нечего.
> 3.
А чего сказать-то хотели?
> 4.
Хотя-бы какая-нить св***ь, хотя-бы на банку пива подкинула! Нету желающих.
> ругать решения майкрософтаНу типа как найти отдушину определенную, в данном случае Microsoft.
Товальдс, реально, четкий пацан.
А можно было сделать проще, у файла два атрибута номер и текстовое поле, система оперирует именами, а текстовое поле это та фигня, что отображается пользователю и в принципе не важно, что там записано и каким регистром.
Система оперирует номерами, ачепятка-)))
А можно было изначально не использовать объект (файл) из реального мира, но это была-бы уже другая история.
В том-то и дело. Изначально, у греков, "файл" - не объект, а процесс. "Как вы лодку назовёте, так она и поплывёт"
Аноним изобрел i-node, какой ужас.
Ну че там, четкий пацан Товальдс, как он там.
Только не говорите ему про базы данных - совсем расстроится... :) А вообще, нужно просто принять единый общемировой стандарт, включающий в себя однозначные правила преобразования регистра для каждого естественного языка (письменности) на планете. И в каждом коде должны быть реализованы только эти правила, а все остальные - исключены. Вроде, ничего сложного.
ASCII качественно не смогли сделать... Что уж про остальное говорить?
Вероятно когда-нибудь так и будет.Но пока есть проблемы и неочевидные подводные камни.
Вот хорошая статья на эту тему в переводе:
https://habr.com/ru/articles/525608/
Особенно интересен момент с важностью локали, хотя всегда считал, что Unicode придумали, чтобы этой проблемы не существовало.
> однозначного, правильного и безошибочного пути выполнять данную операцию просто не существуетДа что там, даже однозначного, правильного и безошибочного способа определить ширину произвольного набора кодовых точек Юникода в экранных знакоместах шрифта с фиксированной шириной — тоже не существует. Разные либы разных версий дают разное. В far2l неплохо так задолбались с этим
Ну как там, чувак, Товальдс, нормусик?