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

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

Вы себя в чём-то пытаетесь убедить? Так не делайте этого публично. Я понимаю, что в отдельных местах у ufs есть плюсы, но в целом ZFS для бздунов оказалось маной небесной, с которой они собирались пройтись огнём и мечом по линуксам. Как-то не сложилось, да и опенсоларис со всеми своими киллер фичами примерно там же. А знаете почему? Потому что даже m$ понимает, что сидеть на одной ОС на десктопе и на другой на сервере - бред. Вся инфраструктура идёт к единообразию. Благодаря этой тенденции даже совершенно непригодная к серверному применению венда завоёвывает позиции в этом секторе. Потому что удобно, когда принципы и команды везде одни, когда софт единообразен. Это позволяет админить всяким лохам и студентам - за еду. А ведь именно это, а не мегасуперкуль админ с зарплатой как у финдеректора нужно бизнесу. Обезъяники, которые кое-как будут делать, "чтобы работало". Таких море в венде, потому она и на коне.

>Вы себя в чём-то пытаетесь убедить?

Я пытаюсь реабилитировать UFS2, традиционную ФС, перед лицом надвигающейся "угрозы" ZFS. А также показать зажравшимся жирным линуксоедам, что GEOM круче связки LVM2/MD как по гибкости, так и по простоте использования.

(Кстати, во время опытов с GEOM gstripe столкнулся с проблемами по автомонтированию страйпа во время загрузки машины: страйп фактически не монтируется в файловую систему ZFS — приходится делать "umount /dev/stripe/Obj && mount /dev/stripe/Obj" — иначе "он как бы есть, но его тут же нет". Уж не знаю, с чем это связано, и связано ли это напрямую с точкой монтирования в самой ZFS, но подозреваю, что так.)

Вечером, если будет время, протестирую другой (новый) zpool на тех же разделах (фактически ZFS будет работать на страйпе), да и сравнить результаты с UFS2 будет интересно.

> Что за система такая?

ext2, ext3, ext4

Ссылка где называют "извращенец и фанатик садо-мазо" за показаную кривизну http://www.linux.org.ru/jump-message.jsp?msgid=4196124&cid=4197758

А вот кстати интересная ссылка про просьбу увеличить количество байт на имя файла http://lists.openwall.net/linux-ext4/2008/11/22/8 . И о том как для этого нужно патчить ядро linux.

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

О! Пошли лозунги про свободу, больше сказать то нечего. С русскими тегам mp3 тоже много свободы, до сих пор все имеются. В армии тоже свободы не хватает? Надо что бы все могли ходить в чем попало и волосы красить. И что бы на улице милиционеры не мешали водку жрать и прохожих п***ить.

Не надо мешать в кучу свободу, нормально проектирование для использования многоязычности и тянущиеся костыли ещё с первой версии.

Кстати, вот ещё читата с сайта xfs: "The major XFS feature in 2.6.27-rc5 is support for case-insensitive file names. At this point it is still limited to 7bit ASCII file names, with updates for utf8 file names expected to follow later."

Так что все вопли про извращения с использованием не той локали идут лесом. Самые натуральные костыли, когда "7bit ASCII file names" используют для хранения utf кодировок. Даже в немеряно ругаемой NTFS и то "255 UTF-16 code units".

Так а что можно сказать ещё, кроме как посочувствовать челу, у которого венда головного мозга? Он же будет до седьмого пота находить, что угодно, что не как в венде и ныть про то, как плохо, что оно не как в венде. Ну и да, мне теги в mp3 не мешают, во-первых потому что mp3 говно, а во-вторых потому, что они практически все пирацкие

>> Что за система такая?

> ext2, ext3, ext4

Афигеть. Каким образом там _ФС_ зависит от локали? Имена - возможно (но ничего такого, что не решилось бы codepage и iocharset).

Впрочем...

> Мне лично, н***ть с высокой колокольни

> Тоже самое на красноглазых утверждающих что фоновая проверка ufs верх гениальности и не костыль.

> И так же сверху, на красноглазых, которым указали на наикревейший пример проектирования

Ничего личного, но ты слишком много с***шь.

Дело в том, мальчег, что я с вашим линаксом сношаюсь уже чуть ли не десять лет и замечаю, что каким он был, таким остался:

Ты наверное ставишь всё тот же дистрибутив десятилетней давности? :-)

нет поддержки юникода в именах ФС

$ locale
LANG=ru_RU.UTF-8
...
$ mkdir Юникод
$ ls
Юникод

А это что тогда было?

>А это что тогда было?

LC_ALL=ru_RU.KOI8-R ls

Вопрос: куда делась кириллица и как ее вернуть? Внутренний юникод -- это когда вне зависимости от установленной локали нацсимволы остаются нацсимволами, а не "цепочками байт". Я уже устал это в сотый раз объяснять.

> LC_ALL=ru_RU.KOI8-R ls

Юникод придумали для того, чтобы отказаться от множества национальных кодировок. Может всё же начать его использовать по назначению? Ладно если бы речь шла о FreeBSD, где, говорят, в консоли UTF-8 ещё не работает, соответственно возможны ситуации, когда русские буквы может требоваться смотреть в разных кодировках. Но в Linux с этим порядок.

Да, есть старый кривой софт, который не может работать с UTF-8, ну так уже близится к концу первое десятилетие XXI века. Пора значит такому софту на свалку. А если будем лелеять проблемы, корни которых остались в прошлом веке, то не хватит времени на что-то действительно стоящее и полезное. К звёздам например полететь, или хотя бы на Марс :-)

Ты просто форумный нытик или троль. Тебе уже предложили несколько вариантов самостоятельного решения проблемы (начиная от использования convmv и заканчивая написанием патча для ядра), почему-то но они остались проигнорированы тобой.

>Я уже устал это в сотый раз объяснять.

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

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

Понимаешь, поддержка юникода -- это не хранение имени файла в виде абстрактной последовательности байт, а хранения имени файла как последовательности unicode символов, так что работа с ним возможна независимо от локали. Я уже даже не говорю о том, куда покатится весь линукс, если попытаться работать с нормальным юникодом, а не костыльным utf-8 (да-да, я о символах, в которых может фигурировать нулевой байт).

>Любитеями анальной фиксации рекомендуется сидеть в своих виндоузах и макосях и не лезть ко взрослым со своими страхами про кодировки и обои.

Вообще-то, любители анальной фиксации в этом треде оголтело мастурбируют на LC_ALL=xx_XX.UTF-8, потому как альтернатив в линаксе нет, не было и не предвидится.

Почему юзерспейсную локаль на основе UTF-8 называют "поддержкой unicode на уровне ОС" мне совсем не понятно. Видимо у лоровцев поголовно диагноз "первая чашка убунты".

>Афигеть. Каким образом там _ФС_ зависит от локали? Имена - возможно (но ничего такого, что не решилось бы codepage и iocharset).

Ну наконец-то! Ты прочти man mount: у ext* нет опции iocharset. Они не производят преобразование кодировки в имени. Имя полностью формируется юзерспейсом и интерпретируется как "последовательность байт". На дворе, можно сказать, 2010 год, а основные фс в линуксе как не поддерживали юникод, так и не поддерживают.

> Имена - возможно (но ничего такого, что не решилось бы codepage и iocharset).

Все сообщения прочитать сложно? Читаем только выборочно?

Тогда ещё раз, вопрос ВСЕМ. Красноглазые линуксоиды считают нормальным ругать всякие zfs, ufs, в то время как в их разлюбимых файловых системах, поле для хранения имени предназначено для "7bit ASCII file names". А так как наступил тотальный уникод, то решили что туда будут записывать уникод. К чему это привело, можно почитать выше, в других не моих сообщениях. Разработчики, к тому же, решили что это нормально, и до сих пор, даже в ext4, тянут эти костыли.

Кроме ссылки на рассылку, что я привел выше, можно найти и почитать просьбы к разработчикам ext4 решить эту проблему. Разработчики заявляют, что в принципе можно, но есть ещё проблемы с дефайнами в ядре и что можно сделать это расширением, когда нибудь, как ядро пофиксят.

Пример, человек пишет, что у него коллекция книг, он сидел на koi8r дебиане, переехал на новую версию дебиана и пришел уникод. Сконвертил имена, а они покоцались, потому как русское имя теперь не длинее 120 с копейками символов. И таких примеров много. А все тут только и могут материть, как же так плохо про linux сказали.

Трололо, когда это UTF-8 перестал быть юникодом?

> Пример, человек пишет, что у него коллекция книг, он сидел на koi8r дебиане, переехал на новую версию дебиана и пришел уникод. Сконвертил имена, а они покоцались, потому как русское имя теперь не длинее 120 с копейками символов.

Назови хотя бы одну книгу, название которой длиннее 120 символов.

P.S. про ~60 китайских/японских/ещё_каких иероглифов, о которых говорили раньше: В китайском/японском/etc. один иероглиф может означать целое понятие, а то и предложение. Т.ч. они в свои 60 иероглифов иногда могут вместить то, на что тебе и 255 букв не хватит.

А вот лог теста:

% date
четверг,  5 ноября 2009 г. 21:31:02 (VOLT)
% dd if=/dev/zero of=/dev/ad6p2 bs=100M
dd: /dev/ad6p2: short write on character device
dd: /dev/ad6p2: end of device
21+0 records in
20+1 records out
2147483648 bytes transferred in 34.051015 secs (63066656 bytes/sec)
% dd if=/dev/zero of=/dev/ad10p2 bs=100M
dd: /dev/ad10p2: short write on character device
dd: /dev/ad10p2: end of device
21+0 records in
20+1 records out
2147483648 bytes transferred in 32.762120 secs (65547762 bytes/sec)
% zpool create arena ad6p2
% zfs set atime=off arena
% zpool status arena
  pool: arena
 state: ONLINE
 scrub: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	arena       ONLINE       0     0     0
	  ad6p2     ONLINE       0     0     0

errors: No known data errors
% zfs umount /arena
% zfs set mountpoint=/usr/obj arena
% zfs mount arena
% zfs list arena
NAME    USED  AVAIL  REFER  MOUNTPOINT
arena    78K  1,95G    18K  /usr/obj
% zpool add arena ad10p2
% zpool status arena 
  pool: arena
 state: ONLINE
 scrub: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	arena       ONLINE       0     0     0
	  ad6p2     ONLINE       0     0     0
	  ad10p2    ONLINE       0     0     0

errors: No known data errors
% zfs list arena
NAME    USED  AVAIL  REFER  MOUNTPOINT
arena    81K  3,91G    18K  /usr/obj
% dd if=/dev/zero of=/usr/obj/image-zpool bs=100M count=30
30+0 records in
30+0 records out
3145728000 bytes transferred in 28.713557 secs (109555497 bytes/sec)
% ls /usr/obj/
total 2852
drwxr-xr-x   2 root  wheel     3B  5 ноя 21:48 ./
drwxr-xr-x  18 root  wheel    18B  1 ноя 19:41 ../
-rw-r--r--   1 root  wheel   2,9G  5 ноя 21:48 image-zpool
% zfs list arena
NAME    USED  AVAIL  REFER  MOUNTPOINT
arena  2,93G  1000M  2,93G  /usr/obj
% rm /usr/obj/image-zpool

>> Имена - возможно (но ничего такого, что не решилось бы codepage и iocharset).

> Все сообщения прочитать сложно?

Да просто неинтересно - мне более-менее безразличны и макос, и zfs.

> Читаем только выборочно?

Ага, и удивляемся. Вот, например, не понял, что это:

> наикревейший пример проектирования их любимой linux фс

относится к обработке Unicode. Огромная проблема, да уж.

> вот кстати интересная ссылка про просьбу увеличить количество байт на имя файла http://lists.openwall.net/linux-ext4/2008/11/22/8

То есть ты не понял ответа Ts'o. Это многое объясняет.

Понимаешь, поддержка юникода — это не хранение имени файла в виде абстрактной последовательности байт, а хранения имени файла как последовательности unicode символов, так что работа с ним возможна независимо от локали.

Наверное нужно уже рассматривать ситуацию иначе - говорить не о поддержке UNICODE, а поддержке устаревших 8-битных кодировок. Ну и постепенно от неё отходить :-)

Я уже даже не говорю о том, куда покатится весь линукс, если попытаться работать с нормальным юникодом, а не костыльным utf-8 (да-да, я о символах, в которых может фигурировать нулевой байт).

UTF-8 - была придумана специально для Linux? Если говорить о её достоинствах и недостатках, это затронет большое количество софта, многие стандарты, а не только Linux.

> Назови хотя бы одну книгу, название которой длиннее 120 символов.

Да вот хотя бы взять гугл, статьи, если их сохранять на диск то в таком виде:

Топос. Михаил Эпштейн. Палиндромия как творческий потенциал языка. К философии и лингвистике обратного слова.

Сидерский Андрей Владимирович - "Йога восьми кругов. Омнио-тренинг-технология. Последовательности нулевого цикла"

Там не прям 120, но вполне еле влазит, добавим ещё .html и название сайта и все. А если поискать по озону, то будет оооочень много. Особенно если книга иностранная и писать сразу названия на двух языках.

И ещё раз, если сложно доходит, проблема не в 120 символах, а в костылях с многоязычной поддержкой на системном уровне. Пример костылей с linux фс фигня, если копнуть в ядро, то будет весело.

> про ~60 китайских/японских/ещё_каких иероглифов, о которых говорили раньше: В китайском/японском/etc. один иероглиф может означать целое понятие, а то и предложение. Т.ч. они в свои 60 иероглифов иногда могут вместить то, на что тебе и 255 букв не хватит.

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

> UTF-8 - была придумана специально для Linux

Подумайте на досуге почему в той же винде юникод utf-16, а в linux utf-8 =)

Так в поле для хранения "7bit ASCII file names" хранить utf8 это нормально или нет?

> То есть ты не понял ответа Ts'o. Это многое объясняет.

Может быть тогда разъясните что там непонятного?

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

Куча национальных кодировок типа cp866, cp1251, koi8-r и т.п. — куда больший костыль, чем UTF-8. И если кому яйца прищемило в далёком прошлом ими пользоваться, то пусть пинают на себя.

Когда этот ваш LVM2 будет поддерживаться нативно, а утилиты управления им войдут в core distribution хотя-бы половины дистров - тогда и поговорим.

Я на днях имел радость монтирования LVM2-пула через rescue mode датацентра _без_ поддержки devmapper ядром, наличия lvm2-utils и пакетного манагера. Примерно такая же ситуация будет если на сервере сгорит все, кроме сторейджа. Прочитать сходу LVM не выйдет. А zfs выйдет, если есть работающая соляра.

Спасибо, не надо.

> Так в поле для хранения "7bit ASCII file names" хранить utf8 это нормально или нет?

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

>> То есть ты не понял ответа Ts'o. Это многое объясняет.

> Может быть тогда разъясните что там непонятного?

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

>В китайском/японском/etc. один иероглиф может означать целое понятие, а то и предложение.

man hiragana, man katakana

Для Ъ: это слоговое письмо

>Трололо, когда это UTF-8 перестал быть юникодом?

UTF-8 -- самая угребищная реализация юникода ever. Это злобные америкосовские проделки, чтобы у них было "как всегда", а остальные народы жрали кактус. Hint: при переменном размере символа даже операция перехода к следующему знаку не так тривиальна, как кажется: появляются ветвления. Кстати, в свете OpenCL и вычислений на GPU, не исключено, что мир еще соснет условных ветвлений на UTF-8. Хотя, наверняка все закончится как обычно: будут конвертить в нормальный 16 или 32-битный юникод с фиксированной длиной символа, и будут обрабатывать такие строки.

>То есть ты не понял ответа Ts'o.

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

Я все правильно понял?

P. S.: И эти люди ругают винду за "графику в ядре".

>Наверное нужно уже рассматривать ситуацию иначе - говорить не о поддержке UNICODE

Ты меня вообще слушаешь? Я бы не ворчал, если бы в линаксовых фс имена файлов хранились в виде UTF-последовательностей символов. Проблема в том, что они хранятся "как юзерспейс скажет", а юзерспейт может сказать хоть "UTF-7", и в итоге твои не-ASCII имена файлов на другой машине могут прочитаться некорректно, если у вас настройки _юзерспейса_ не совпадут.

>UTF-8 - была придумана специально для Linux?

Ты опять меня не слушаешь? Я вообще-то пытаюсь сказать, что нормальный юникод с фиксированной шириной символа в линаксе невозможен, а в инде это прекрасно живет и работает уже более 15 лет.

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

Преимущество кучи obsoleted функций в WinAPI в том, что старый софт, не подозревающий о существовании XP, продолжает работать как ни в чем ни бывало.

Ты меня вообще слушаешь? Я бы не ворчал, если бы в линаксовых фс имена файлов хранились в виде UTF-последовательностей символов. Проблема в том, что они хранятся «как юзерспейс скажет», а юзерспейт может сказать хоть «UTF-7», и в итоге твои не-ASCII имена файлов на другой машине могут прочитаться некорректно, если у вас настройки _юзерспейса_ не совпадут.

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

Ты опять меня не слушаешь? Я вообще-то пытаюсь сказать, что нормальный юникод с фиксированной шириной символа в линаксе невозможен, а в инде это прекрасно живет и работает уже более 15 лет.

Во-первых, Юникод в принципе не является кодировкой с фиксированной шириной символа - из-за модифицирующих символов. Во-вторых, насколько я знаю, в UTF-16, которая использована в Windows, часть символов кодируется двумя байтами, а часть (более редко используемые) - четырьмя. То есть UTF-8 - может в каких-то случаях и неудобно, но другие представления Unicode имеют аналогичные недостатки.

> Преимущество кучи obsoleted функций в WinAPI в том, что старый софт, не подозревающий о существовании XP, продолжает работать как ни в чем ни бывало.

Ну да, людям не нравится, когда используемые ими программы ломаются из-за того, что у одного из разработчиков вдруг левая пятка зачесалась и он выкинул старую, по его мнению, функцию, не предоставив хотя бы временного костыля. Чего такого уж плохого в обратной совместимости API? Тем более, что из всего хоть сколько-нибудь популярного софта эти костыли давно выкинули.

А то, что полтора линуксоида застряли в далёком (по крайней мере, по компьютерным меркам) прошлом, никого не волнует, ради них никто особо париться с поддержкой древнего говна не будет.

Хмм, действительно фэйл, признаю отсутствие возможности указать кодировку ФС в отрыве от локали это недостаток. Но, вместе с тем, на протяжении всего треда меня не оставляет странное чувство. Вроде все тут кричат, указывают на проблемы, а мне как-то скучно. А всё потому, что на самом деле всё just works. Пусть есть недостатки, видимые пристальным взглядом, пусть что-то сделано в ЗФС или ЮФС/геом лучше, но в итоге это заботит лишь троллей, потому что не мешает работать вообще. Ни на линукс декстопе ни на линукс сервере. Потому и править/менять это никто не требует, потому и тревожит это только троллей. У линукса есть реальные проблемы, которые надо решать. А вот всё это - эстетика, которую можно вспомнить для троллинга, но которая не напрягает в реале. И да, кто ругается на висящие баги на эти темы - забудьте уже о принципах взаимодействия вендор-кастомер, в духе я тебе деньги ты мне услуги. Это всё осталось в борделе, т.е. в венде. Тут всё проще - по любви. Хочешь, чтобы что-то заработало, нужное тебе, напиши патч или реализацию - сам. Если это нужно не одному лишь тебе, это примут и внедрят. И спасибо скажут. А пенять, что за тебя не решают твои проблемы - глупо. Мне именно так как-то раз сказали разработчики, кажется, амеры, на мои наезды на тему поддержки русских локалей. И правда, им-то что? Русских программистов не осталось? Спились, или венду программируют за кровавые деньги?

>Хочешь, чтобы что-то заработало, нужное тебе, напиши патч или реализацию - сам.

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

Иными словами, скатились к тому, что опенсорс не эффективен для решения повседневных проблем?

>Мне именно так как-то раз сказали разработчики, кажется, амеры, на мои наезды на тему поддержки русских локалей.

И тебе это кажется правильным? "Мне плевать на твои проблемы, я написал свою гениальную поделку, и если тебе так неймется, то можешь своими кривыми ручками написать патч, а я посмотрю, принять его или нет". Я бы не сказал, что это здравый подход, даже если человек писал just for fun.

> Я все правильно понял?

Нет, ты опять бредишь.

> P. S.: И эти люди ругают винду за "графику в ядре".

Ты хочешь поговорить о том, как это правильно - держать GDI в ядре, и как тебе хорошо от этого?

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

С десктопной составляющей очень хорошо, если учитывать что это 1% десктопов. У какой другой ОС, кроме венды, так же всё хорошо на произвольном десктопе, как у линукса? А ведь это ещё и свободная лицензия и халява. А главное - меня вполне устраивает. Другое дело, что и недовольных много будет при таком подходе.

>И тебе это кажется правильным? "Мне плевать на твои проблемы, я написал свою гениальную поделку, и если тебе так неймется, то можешь своими кривыми ручками написать патч, а я посмотрю, принять его или нет". Я бы не сказал, что это здравый подход, даже если человек писал just for fun.

Чуваки справедливо говорят, что среди пользователей Linux русскоговорящих с проблемами кириллицы - меньше 10%. Зачем тратить на эти 10% силы, которых не хватает и так? Лучше сделать то, что очень нужно 90%-ам и забить на 10, чем наоборот.

Бугага. Русскоговорящие, говоришь? А про всяких Болгар, Сербов, Таджиков и прочих Монголов, которые используют кириллицу ты уже забыл? Сколько там в сумме получается? Почему-то я думаю, что уже далеко не 10%.

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

Насколько я понимаю, как раз около 10%, это видно по всем нелокальным проектам. Около 50% - англоговорящие, ещё около 30% - китайцы. Так что нам немного остаётся

Что, в самом деле десять процентов в большом количестве опенусрса? Ну нифига ж себе! Это же очень круто! Я думал, там единицы, если не доли процентов. Всего в три раза меньше, чем китайцев! Это вообще запредельная круть. При том, что народу русскоговорящего раз в пять меньше по всему миру, чем китайцев только в Китае. По англоговорящим - тоже поражает. Потому как даже чистых англосаксов в несколько раз больше, чем русскоговорящих, не говоря уже об общем уровне компьютеризации у них и у нас. А если ещё присчитать индусов, которых примерно столько же, сколько китайцев, но спокойно зачисляются в разряд англоговорящих...

[...] предположим, что нашелся красноглазый идиот, который отформатировал флешку в ext2 [...]

Если вся его Ъ-шность сводится к бессмысленным понтам, то да, ему придется заняться «угадайкой». И поделом.

Если же у него хоть какой-то намек на квалификацию имеется, то он осилит догадаться, к примеру, скормить вывод ls -1i в «куче с остальными кириллическими файлами» iconv'у

>Если же у него хоть какой-то намек на квалификацию имеется, то он осилит догадаться, к примеру, скормить вывод ls -1i в "куче с остальными кириллическими файлами" iconv'у

Не поможет. Надо переименовывать файлы. И это в 2009 году.

Надо переименовывать файлых

Для того, чтобы узнать, какой файл нужно печатать — не надо

Про год ты сам себе тверди, каждый раз как захочется ставить koi8-r бей себя по голове молотком со словами "2009-й год, юникод на дворе"

Разницу между юникодом и utf-8 на пальцах объяснить, или сам догадаешься?

> Разницу между юникодом и utf-8 на пальцах объяснить, или сам догадаешься?

Ну так в чём принципиальная разница? В UTF-8 символ имеет переменную длину? Ну так в Unicode вообще он может иметь переменную длину (к примеру, буква "Й" может обозначаться двумя символами: "И" и верхним "хвостиком"). Более того, в Windows используется UTF-16, м там так же используется кодирование (некоторые символы занимают два байта, а некоторые - четыре, миллион с лишним вариантов в два байта не вместить). Кстати, можно ещё отметить, что wchar_t в Windows API содержат закодированные в UTF-16 символы, а вот в GNU/Linux wchar_t имеет размер в 32 бита (http://ru.wikipedia.org/wiki/Wchar_t). В общем, видимо, чтобы перейти к 32-битному Юникоду, изменения нужны и в Windows, и в Linux.

Utf-8 лучше koi8-r в современном мире. Конечно, есть ещё куда развиваться, но в венде с её внутренним юникодом и внешним зоопарком ничем не лучше дела

>к примеру, буква "Й" может обозначаться двумя символами: "И" и верхним "хвостиком"

Вот только ты забыл упомянуть, что при этом это уже будет не русская буква «й», а какое-то инородное граффити. И откуда инфа про UTF-16 в Windows? Там используется какое-то подмножество unicode с фиксированной двухбайтной шириной символа. Очень правильно в отличие от плясок с бубнами вокруг utf-8, где даже переход к следующему символу без условного ветвления сделать не получится.