Энтузиасты взяли в свои руки реализацию ZFS для MacOS X

>но в венде с её внутренним юникодом и внешним зоопарком ничем не лучше дела

Внутренний юникод -- это хорошо и правильно. Это гарантия того, что хоть у меня и однобайтовая кодировка, но имена на флешке не "сломаются", если я принесу их, скажем, на компьютер китайца.

И раз уж на то пошло, в CP1251 кириллица расположена в правильном порядке, т. е. коды символов соответствуют их положению в алфавите, как и в ISO8859-5, как и в CP866, но не как в KOI8-R. Чем тут руководствовались, я понять не могу. Это к слову об "открытых стандартах", кстати. Даже кодировку вменяемую придумать не могут.

>в CP1251 кириллица расположена в правильном порядке, т. е. коды символов соответствуют их положению в алфавите, как и в ISO8859-5, как и в CP866, но не как в KOI8-R.

Как будто не знаешь, почему в КОИ8 порядок символов не алфавитный, и как этот факт соотносится с существованием КОИ7 и ASCII ?

> в CP1251 кириллица расположена в правильном порядке, т. е. коды символов соответствуют их положению в алфавите, как и в ISO8859-5, как и в CP866, но не как в KOI8-R. Чем тут руководствовались, я понять не могу. Это к слову об "открытых стандартах"

Это к слову о детях, не знающих истории.

>Это к слову о детях, не знающих истории.

+ мильён

откуда инфа про UTF-16 в Windows? Там используется какое-то подмножество unicode с фиксированной двухбайтной шириной символа.

UCS-2 в Windows. «UCS-2 (2-byte Universal Character Set) is a similar yet older character encoding that was superseded by UTF-16 in Unicode version 2.0»

Успокойтесь уже. Всю тему засрали своими кодировками.

Вот только ты забыл упомянуть, что при этом это уже будет не русская буква «й», а какое-то инородное граффити.

Насколько я знаю, это будет та же буква й. И из соответствующего раздела статьи про Юникод в Википедии можно сделать тот же вывод. В частности там говорится:

Поскольку одни и те же символы можно представить различными кодами, что иногда затрудняет обработку, существуют процессы нормализации, предназначенные для приведения текста к определённому стандартному виду.

То есть может быть несколько способов обозначить один и тот же символ. И это будет та же «й», несмотря на то, состоит из одного или из двух символов.

И откуда инфа про UTF-16 в Windows? Там используется какое-то подмножество unicode с фиксированной двухбайтной шириной символа.

Я же приводил ссылку на статью в Википедии про wchar_t, там в частности говорится:

В Windows API, тип wchar_t имеет размер 16 бит. Windows API нарушает стандарт ANSI/ISO C, который требует, чтобы символьный тип wchar_t поддерживал все представимые в системе символы в одном объекте wchar_t. Вместо этого, wchar_t в Windows представляет собой символы (либо часть символа) в кодировке UTF-16.

В GNU/Linux тип wchar_t имеет размер 32 бита.

Получается, что в чём-то поддержка Unicode лучше в Windows, а в чём-то в Linux.

Очень правильно в отличие от плясок с бубнами вокруг utf-8, где даже переход к следующему символу без условного ветвления сделать не получится.

А в UTF-16 это получится? ;-) Если символ из одного диапазона, то следующий - это +2 байта, если из другого, то следующий - это +4 байта.

>Получается, что в чём-то поддержка Unicode лучше в Windows, а в чём-то в Linux.

Во-первых, GNU/Linux не имеют никакого отношения к wchar_t. Это все gcc.

Во-вторых, ни одна из функций glibc для работы с "внешним миром" не принимает wchar_t в качестве аргумента. Более того, гнулинакс и gnu/gcc даже не могут с этим wchar_t сделать ничего полезного. Зато да, он есть "для галочки" и можно доставать четырехбайтную бесполезную пипиську и хвалиться, как все круто в линаксе с юникодом. Только получается как в пустом множестве ("все элементы пустого множества зеленые, потому что у него нет элементов") -- в линаксе с юникодом все хорошо, потому что юникода нет.

>А в UTF-16 это получится?

UCS-2 или UCS-4. Или это "некрута", патамушта латиница получается раздутая и "прогрессивному сообществу не нравится"?

>Это к слову о детях, не знающих истории.

Вопль типичного линаксоида: Виндоус -- это плохо! Там кругом костыли для обратной совместимости! Очень плохая система!!! MUST DIE!!!

Теперь получается, что весь ваш гнулинакс -- это один большой костыль для обратной совместимости непонятно с чем. Даже дефолтовая русская кодировка х-з сколько лет была KOI8-R. Какая мерзость!

> Преимущество UTF-8 в том, что старый софт, не подозревающий о существовании юникода, продолжает работать как ни в чём не бывало, потому что в области кодов 0-127 ASCII и UTF-8 полностью идентичны.

Вот именно. Тут про это и толкуют. Ядро писали без оглядки на многоязычность. UTF8 выбрали потому как это самый приемлимый вариант не поломать совместимость, если где вместо обычного ansi передадут utf8. И использую utf8 там где только необходимо. Все хорошо, но блин, от этого ядро linux выглядит, в этом плане, явно не лучшим образом.

> Да, это нормально. UTF8 для этого и разрабатывалась.

Зашибись. А ещё винду ругают за то что тянет совместимость со старым софтом.

> Мне-то всё понятно: введение более длинных имен потребует доработки по всему ядру (и отмазки о том, что эта поддержка будет опциональной, не катят), и эти доработки нафиг никому, кроме openwall, не нужны;

Ну дык, я про тоже.

> более длинные имен будут ломать существующие программы (кстати, открывая новое направление для security attacks).

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

> И раз уж на то пошло, в CP1251 кириллица расположена в правильном порядке, т. е. коды символов соответствуют их положению в алфавите, как и в ISO8859-5, как и в CP866, но не как в KOI8-R. Чем тут руководствовались, я понять не могу. Это к слову об "открытых стандартах", кстати. Даже кодировку вменяемую придумать не могут.

KOI8, самую извратную из всех кириллических кодировок, придумали в СССР.

Руководствовались чито практическими соображениями: если отрезать у koi8-r старший бит (а так часто случалось с программами, которые не знали/не хотели знать о нелатинских кодировках), то текст останется читаемым. Проверьте!

Да уж конечно, линуксоиды они такие придумщики. Это ничего, что RFC 1489 (тот самый КОИ8-Р) датирован 1993 годом, когда Линукса как бы еще не было в широком обращении (тем более русскоязычном) ?

Но до инновационной придумки windows-1251 им, конечно, очень далеко :-)

>Но до инновационной придумки windows-1251 им, конечно, очень далеко :-)

В CP1251 есть символ "№". Есть что возразить?

>если отрезать у koi8-r старший бит

А почему регистр инвертируется?

>Да уж конечно, линуксоиды они такие придумщики.

>dA UV KONE^NO, LINUKSOIDY ONI TAKIE PRIDUM]IKI.

> Все ожидаемо и потери на _первой_ записи, и нулевые потери на всех последующих. Это на одном диске, без RAID, без кэша.

Точно? А вот товарищ Chris Mason (http://lwn.net/Articles/358940/) так не думает:

> Doing snapshots at the device mapper/LVM layer involves making a lot more copies of the relevant data. Chris ran an experiment where he created a 400MB file, created a bunch of snapshots, then overwrote the file. Btrfs is able to just write the new version, while allowing all of the snapshots to share the old copy. LVM, instead, copies the data once for each snapshot. So this test, which ran in less than two seconds on Btrfs, took about ten minutes with LVM.

>В CP1251 есть символ "№"

Этот незаменимый символ был вообще-то в еще 866 кодировке DOS-а. IBM для OS/2 использовала именно ее. Ну да куда им до фантазеров из MS.

> Это ничего, что RFC 1489 (тот самый КОИ8-Р) датирован 1993 годом, когда Линукса как бы еще не было в широком обращении (тем более русскоязычном) ?

KOI8-R — это дополненная KOI8 (ГОСТ 19768-74). Но коды букв остались те же, поэтому их можно считать взаимозаменяемыми. А никакого линукса, тем более в СССР, тогда "и в проекте не было". :)

>Ну да куда им до фантазеров из MS.

Найди этот символ в KOI8-R.

>Найди этот символ в KOI8-R.

Его там нет, сам ведь знаешь. Ради него был пополнен зоопарк русских кодировок еще одной ? Использовать DOS 866 или ISO 8859-5 это не Microsoft-way ?