> локаль в RH делается как ru_RU.koi8r

Так называется файл или сама локаль ??

> для этого необходимо сделать линк в каталоге /usr/lib/locale с ru_RU.koi8r на ru_RU.KOI8-R

sh-2.05$ ls /usr/lib/locale/ | grep ru_
ru_RU
ru_RU.koi8r
ru_UA
sh-2.05$ locale | head -1
LANG=ru_RU.KOI8-R
sh-2.05$

Никаких линьков.

> который позволял делать перекодировку русских имен файлов в транслит, это требовалось для DOS, так как он не понимал русские символы в именах файлов

У меня глючит мозилла ?? Или я единственный, кто видел дос живьем ?? :-))))
(Слабо верится, что этот патчик был сделан во времена DOS 1.0 :-)) )

ЗЫ. А "ru_UA" выглядит прикольно :-)))))

хм, вот меня интересует, как в юникоде будет работать команда tac?

по поводу нормальной работы utf-8 - не проще ли в РХ написать дескать так и так, в мс кракозябры с русской локалью, мол баг это? кто нибудь это делал? может быть здесь напишете примерный образец багрепорта по этому поводу, а то с англицуим туговато, боюсь не поймут...

Такой багрепорт уже есть. Я видел список багрепортов по RH8: он полон сообщениями о программах, не работающих с UTF-8, и Midnight Commander там тоже упомянут. Правда, жалуется гражданин, работающий с эстонской локалью, :-) но от этого суть не меняется.

Добрый день

Я RedHat 8 не видел. Просто любопытно: как там со шрифтами? В принципе mc можно пожертвовать как программой, но если там, например, не могут работать cyr-rfx шрифты, то это уже глобальная проблема, которую следует решить. В противном случае будем сидеть на том, что американцы считают русскими шрифтами.

С уважением Евгений

2McMCC (*) (2002-11-22 01:29:23.403)
Извиняюсь за слово "борьба", если оно Вас так задело (просто первое, что пришло в голову, прочитав... ).
Через год, говорите? Значит будем ждать год... Мне нужна система почти совсем "из коробки" - не хватает времени _серьезно_ геморроиться. Когда-то было, сейчас нету его :(

XMMS

У меня после обновлния RH7.2 -> RH8.0 XMMS на mp3 файлах стал работать молча :)

Простое make install помогло.

С интересом прочитал статью и с не меньшим интересом -- данный thread.

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

oli> ряда юридических лиц ( AltLinux? ASPLinux, Linux-Ink и др.), для которых это (КОИ8) источник средств для существования ;)

, а именно от Linux-Инк.

Как это ни странно, я почти целиком согласен с мнениями как уважаемого McMCC, так и не менее уважаемого svu. Оба они правы, но каждый по своему. Безусловно, Unicode -- светлое будущее к которому надо стремиться. Но излишнего фанатизма при этом проявлять не следует. Да и с самим RedHat'ом тоже не все так просто -- см. RELEASE-NOTES:

Certain third party applications, such as the Adobe(R) Acrobat Reader(R), may not function correctly (or crash upon startup) because they lack support for Unicode locales. Until third party developers provide such support in their products, you may work around this issue by setting the LANG environment variable at the shell prompt to C prior to typing the application name. For example:

env LANG=C acroread

Столкнувшиеся с 8.0 могли заметить, что не все так хорошо и с не third party applications :(

Хотелось бы отметить, что и в остальном мире ОС все не так однозначно. Вспомните сколько времени понадобилось Micro$oft, что бы переползти на Unicode, но и до сих пор письма из Windows обычно шлют в CP1251. А из Sun'а -- в ISO8859-5 (хотя там UTF8 тоже присутсвует уже достаточно давно).

Относительно девелоперов: девелоперы девелоперам рознь -- кому то нужно или интересно возится с вживлением Unicode, а кому-то с чем-то другим. Кому что интересно, тот пусть тем и занимается (правда не забывая о том, что Unicode на свете все таки есть -- во избежание собственного геморроя в дальнейшем). В конце концов, большинство разработчиков в Linux'овом мире работает за бесплатно.

Кроме того, кроме разработчиков на свете есть много других людей которых не волнуют эти религиозные войны и они хотят делать какое-то свое дело, так как им это удобнее. У нас, например, бывают заказчики которым и вовсе бывает нужно IBM866 (помните такую кодировку? :) и мы им это организуем.

Относительно же того, что себе думает RedHat и как мы к этому относимся, я скажу так: главный наш принцип -- не навредить и иногда это получается ;). Когда мы лепим свой RH Cyrillic Edition, то достаточно большую часть усилий мы тратим на то, что бы найти путь решения проблем дистрибутива, привносящий минимальные изменения в систему. И разумеется, все время тестируем -- не сломали ли мы что-то такое, что до нашего вмешательства работало.

Так например, и в данном вопросе у нас был соблазн пойти по тому же пути, что предлагается в статье, и просто заменить пакет 'kbd'. Но это действительно несколько нарушает ту систему локализации, что предложена RedHat'ом. По этому мы потратили некотрое количество времени, для того что бы найти действительно болевую точку в локализации текстового режима -- файл /sbin/setsysfont. После внесения в него дополнений все чудесным образом заработало с родным пакетом 'kbd'. Далее мы просто добавили поддержку KOI8 в родные RedHat'овские конфигурялки. Таким образом, вся родная локализация осталась на месте и вы вольны выбирать через стандартные средства системы, работать вам в KOI или в родной RH'овской UTF.

Но в любом случае, работу с Unicode мы ведем, да и сам RedHat тоже. Просто не все сразу делается...

Позиция linux-inc понятна и ясна. Правда, результат их работы было бы вернее назвать RH KOI-8 Edition:) Кстати, а зачем заказчику конкретная кодировка, если не секрет? Обычно людям просто нужно, чтобы русский язык всегда был русским языком (что лучше уникода в принципе ни одна кодировка гарантировать не может - в принципе, я не говорю про конкретные приложения). Ну да чорт с ним, с уникодом - действительно, очень интересны мотивы заказчика, настаивающего на кодировке (чем им тот же КОИ не угодил)?

Да, про "чудесным образом заработало" - что, и русский ввод|вывод в уникодной консоли у Вас работает без проблем? Если это не секретное знание - было бы интересно где-нибудь об этом прочитать. Я в консоли бываю редко (в основном - как рут, и в эти моменты русский меня мало волнует), живу, в основном, в gnome-terminal. Но все-таки интересно... Соббсно, это пример того, о чем я говорил - больше документов о хорошей жизни под уникодом. Меньше - об искуственных почках и открытом массаже сердца.:)

И еще вопрос - тоже не из самых актуальных. При русской системой локали у кого-нибудь показываются нормально русские сообщения о старте и стопе сервисов? С запуском еще как-то, а вот с остановом...

Да, это все мелочи, никак не влияют на работу системы - но вдруг есть быстрый способ это дело "уконтрапупить"?

Последний вопрос - про принципы: кому не навредить? Заказчику или дистрибутиву? Иногда (особенно в случае РХ80) эти задачи конфликтуют. Заказчик хочет консерватизма и знакомой жизненной среды. РХ80 - "Revolution #8" (да простят меня битлы за смену номера).

Да, спасибо за работу с уникодом. "Верной дорогой..."

svu> интересны мотивы заказчика, настаивающего на кодировке (чем им тот же КОИ не угодил)?

Проблемы у людей бывают разные: например многие гос. структуры зачастую не могут или не хотят от огромного количества унаследованных DOS приложений писанных на Clipper/FoxPro в 19... году. При этом хотят тонкого клиента для консолидации процесса поддержки своей системы, да еще подешевле и пооткрытее. Очевидный ход с нашей стороны -- эмуляция DOS на Linux-сервере с подключением тонких клиентов под Linux'ом же по telnet'у, ssh'у или просто RS232. В этом случае, без 866 страницы обойтись трудно, причем в консольном режиме.

svu> Да, про "чудесным образом заработало" - что, и русский ввод|вывод в уникодной консоли у Вас работает без проблем?

Нет, нет речь шла исключительно о том, что в /sbin/setsysfont не обрабатывался параметр SYSFONTACM из /etc/sysconfig/i18n, и KOI8 установки работавшие в 7.3, не отрабатывали корректно.

svu> При русской системой локали у кого-нибудь показываются нормально русские сообщения о старте и стопе сервисов? С запуском еще как-то, а вот с остановом...

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

svu> Последний вопрос - про принципы: кому не навредить? Заказчику или дистрибутиву? Иногда (особенно в случае РХ80) эти задачи конфликтуют.

Разумеется, дистрибутиву в первую очередь. У нас дистр. -- вообще точная копия с RedHat'овских imag'ей. Вся русификация на отдельном диске -- хочешь ставь, хочешь не ставь, хочешь -- ставь только то что нужно.

Если заказчику хочется чего-нибудь особенного -- ему делается система под заказ. Например Aquarius'у мы в свое время лепили спец. дистр. специально под их машинки. Машины были слеплены на Intel 810, который тогда RedHat'ом еще не поддерживался. Правили инсталлятор...

svu> Заказчик хочет консерватизма и знакомой жизненной среды.

Заказчики бывают разные....

большое спасибо автору за статью!!!
но ее бы на пару недель пораньше :)))
тогда я бы не стал сносить РХ-8.0 :(
до настройки локали дошел почти своим умом и при помощи
wuk-a, про то что в РХ-8 кривой МС тоже дошел почти сам
кстати по борьбе с глюками:
поставил РХ-8 как апдейт на 7.3.
кодировка слетела подправил вроде заработала.
XMMS опять таки криво собран с МР3 не работал (работал mpg123)
неправильно брались ttf шрифты и мелкие глюки с работой других приложений
криво собранные пакеты заменялись на аналогичные из ALT linux Master.
единственный вопрос который возник время при установке апдейтом раза в три больше времени на уставновку с нуля :(
ну и не понял для чего теститься диск в самом начале установке РХ-8.0 и что он требует за диски при первом замуске иксов?

2svu: Вы действительно, вслед за Gnome team и RH, считаете, что для работы с Unicode необходима Utf8 locale? Зачем?
Не происходит ли здесь подмены понятий?
"Революция #8" в части UTF8 locales абсолютно не подготовлена и не продумана, она держится на паре хаков и надежде, что все теперь сами что-то придумают. Не придумают ничего, кроме новых хаков.
Хотите Unicode систему (а не систему, в которой можно работать с Unicode) -- берите plan9.
_Навязывание_ же всем _только_ UTF8 locales -- гнилая затея.
RH8 -- прекрасный дистрибутив. Для разработчиков. Если бы на еще на коробке было написано "Опасно для здоровья админов и пользователей" -- совсем здорово. И все его новшества, кроме UTF locales, дали очень серьезный импульс разработке.
Кстати, по поводу "кривых" шрифтов. Во-первых, сглаживание легко отключить. Во-вторых, рендеринг ttf в freetype из RH8 и freetype-2.1.3 не является более приоритетной задачей, зато рендеринг Type1 значительно улучшен. И это правильно, так как свободных Type1 уже много. Забудьте про ttf от MS, используйте urw с кириллицей Валька, cm-super, шрифты Шарашкина и Сорокина.

2svu (*) (2002-11-22 12:25:27.762):

> Заказчик хочет консерватизма и знакомой жизненной среды.
> PХ80 - "Revolution #8" (да простят меня битлы за смену номера).

Прощаем :-) Тем более, что обыграно неплохо.

А переход 7->8 по обсуждаемой схеме мне напоминает не менее известное
"Шаг вперёд, два шага назад". Кому-то это, конечно же, надо. Но
было бы более прогрессивно приложить усилия по продвижению юникода.

2aen (*) (2002-11-22 13:41:30.66):

> Забудьте про ttf от MS, используйте urw с кириллицей Валька,
> cm-super, шрифты Шарашкина и Сорокина.

Пользуясь случаем хотел спросить, где они лежат? Можно и погуглить,
но... если не получу ответ. ;-)

2aen (*) (2002-11-22 13:41:30.66):

> _Навязывание_ же всем _только_ UTF8 locales -- гнилая затея.

Я думаю, svu призывал не к навязыванию, а к продвижению юникод-идей.
Может быть его речи немного напоминали пламенных революционеров, но
это вопрос стиля.

И если RedHat взялся делать "революцию", то, как я понял svu,
это хороший трамплин для внедрения таких идей.

Возможно, это моя технологическая серость - но я действительно так считаю. Чтобы ВСЕ приложения (не только браузер, почтовик и офис) могли работать с уникодом - нужна уникодная локаль (например, utf-8 - хотя не обязательно). Чтобы команды cat, date, ls и пр. работали с любыми символами. Расскажите, как это сделать без юникодной локали.

Да, не подготовлена эта революция. "Безумству храбрых..." Насчет ничего не придумают - не согласен. Ответственные хакеры, увидев эти грабли, все-таки пытаются придумывать не хаки, а решения. Например (сорри за нескромность), вчера лично мной были пофикшены intltool - они не работали в юникодных локалях, потому что использовали перловую конструкцию unpack ( "C*", ... ). Было заменено на unpack ( "U*", ... ) Это хак или фикс? Или перловые ребята должны были заменить определение формата С в уникодных локалях? Они этого не сделали (не без оснований)

Навязывание - гнилая идея. А promotion - правильная:)

Про надпись на коробке - согласен. Только красным цветом (желательно blinking) и шрифтом побольше:)

Кстати, а все вышеперечисленные шрифты - столь же корректны в вопросе уникода, как эти самые MS? И 10646-1 там есть?

О, меня уже толкуют...:) Что интересно - достаточно правильно.

Да, над стилем мне, возможно, придется поработать...

А ты написал в комментах, что можно использовать только perl 5.6.1 и выше :)?

Я написал, что работает у меня на 5.8.0 - и что с более ранними могут быть проблемы. Как я понял, с серией 5.6 все нормально - но тут народ из РХ6.2 начал жаловаться, что 5.005 не тянет - вот там сейчас разборки на эту тему и идут:). В любом случае, мне кажется, вариант U - единственно правильный. Кажется, хозяева intltool cо мной согласны. У Вас возражения будут?

Товарищи, а случаем никто не подскажет где можно коробочную версию RH7.3 в России купить?

1. Чтобы _вывод_ date и ls был в Unicode -- нужна Unicode locale. Но при этом date все равно будет показывать дату на языке locale, то есть Unicode как бы и не особо нужен, а для того, чтобы нужен был ls, придется переименовать файлы в Unicode. Полагаю, что это нужно крайне небольшому числу пользователей. Предоставить для них такую возможность -- нужно, но вот делать ее умалчиваемой для всех -- нет.
Что касается cat, то это из другйо оперы. Прежде нужно перекодирвоать все плоские файлы в UTF, в том числе файлы конфигурации с комментариями на неанглийском языке.
Еще раз: я не говорил "без юникодной локали", но юникодная локаль в POSIX-системе -- хак. Создатели POSIX locales меньше всего думали о UTF-8 locales. Именно потому я говорил о plan9, где юникодность заложена в архитектуре изначально.
2. Смысл POSIX locale -- в прозрачности. Со стороны пользователя: написла LANG=ru_RU.UTF-8 -- получил приложение, работающее в UTF-8. Сейчас же, не считая заранее спроектированных для такой работы Gtk2/Gnome2 и qt/KDE (кстати, в qt/KDE UTF8 locale абсолютно не нужна, но может использоваться), мы получим кучу хаков и выброшенных за пределы RH проектов, у которых не хватает сил для переписывания системы (ну, не все хотят хачить!)
3. Про "безумство храбрых". Все зависит от того, на какое слово ударение. Авантюра такого рода должна начинаться с развернутой программы действий. Если она есть и закрыта, -- плохо, так как это дело всего community. Если ее нет и все сводится к ряду технических идей, а именно так все выглядит со стороны, -- тоже плохо, так как дезориентирует разработчиков, каждый из которых волен предположить дальнейшее движение (а вариантов очень много) так, как ему заблагорассудится.
4. А в общем все, конечно, устаканится. Меня RH8 _очень_ порадовал.
5. Перечисленные шрифты содержат глифы Latin1,2 и кириллицу. Но они свободны и есть pfaedit.

urw в варианте Валентина Филиппова лежат в RH8 (с правкой Owen'а для трех), свежая версия -- на ftp://ftp.gnome.ru
cm-super ищите на CTAN или ftp://ftp.vsu.ru
Шрифты Шарашкина и Сорокина -- на ftp://ftp.ice.ru (Будьте осторожны, из 4-х шрифтов Сергея Шарашкина два сделаны на основе шрфитов Peter Soos, а они сомнительны).
Наконец, все вышеперечисленные шрифты, кроме (пока) cm-super, есть в Sisyphus (пакеты urw-fonts, sharatype-fonts, dmtr40in-fonts).
Там же пакет бесплатных (не свободных, см. лицензию) декоративных шрифтов проекта Vedi ( http://vedi.d-s.ru )

А проблема с МС из под Хтерминала осталась :(((((( Текстовый нормально, а вот иксовая консоль КРЯВАЯ!!!!!! :((((

>А проблема с МС из под Хтерминала осталась :(((((( Текстовый нормально, а >вот иксовая консоль КРЯВАЯ!!!!!! :((((

2vada: Нет там никаких проблем, ставишь хтерминалу фонт Andale Monо и все
становится нормально....

Нет, ребята, что не говорите, а UTF-8 - классная штука. Вчера добрался до postgres'а. Создал базу в Unicode и был приятно удивлен приличной руссификацией. Более того удалось создать таблицу с русским именем и полями в кирилице. Правда Upper() не работает, но это поправимо. И стоит ли из-за одного МС такой огород городить? Хотя шаг 3 ( по памяти) по переустановке шрифтов необходим, я бы добавил - подредактировать файл раскладки консолевской клавиатуры. В любом случае, труд господина МсМСС достоин уважения. Пишите, Шура, пишите...:-) Главное, он достоин уважения уже за то,что инициировал данную дискуссию. Полагаю, что RH >= 8 достоин отдельной конфы.

1. Ну, может, я хочу сделать

for i in ru de en fr; do

LANG=$i date

done

Такой я извращенец:) Да, а вот смотреть файлы с разными именами - это вполне может пригодиться. Например, в немецко-русской компании (или китайско-французской). Вообще, задолбали опции encoding+charset в самбе (и smbfs) :)))

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

2. Смысл локали, мне кажется, я понимаю почти так же. Выброшенные проекты - это "плохой код". Если раньше "плохим" считались приложения, некорректно работающие с 8-м битом, то теперь - некорректно работающие с многобайтными символами. Новый виток (скачок, если хотите) эволюции.

3. Библиотека gettext решает некоторые проблемы для С-прог. Стандартные тулкиты - тоже как-то справляются. Что еще из основных блоков не охвачено? А конечные приложения - да, нужно фиксить...

4. :)

5. А у мелкомягких-то кодировок поболе будет:) Со всем уважением и преклонением перед трудолюбием авторов этих шрифтов.

for i in `ls /usr/lib/locale`; do

echo -n "$i -> " ; ( LANG=$i date; ) ;

done

Смешно получается...

1. Еще раз: я за поддержку UTF-8 locales, но в качестве опции. В POSIX-системах они прилеплены сбоку и попытка развивать их как основные приведет к серьезным проблемам, а любые серьезные проблемы -- проблемы безопасности.
2. Выброшенные проекты -- это не плохой код, они просто не соответствуют новым веяниям. Переход на 8 бит породил кучу проблем с безопасностью. Тотальный переход на UTF-8, не предусмотренный архитектурой системы, породит бОльшие проблемы. Это абсолютно недопустимо.
Одни профанируют систему явно и по-хамски, как Lindows с его работой только от root. Другие, но из тех же побуждений (погоня за Win), делают это исподволь, закладывая бомбу замедленного действия.
Возможно, это и к лучшему, -- старая архитектура быстрее помрет, сделавшись глюкалом. Но вот новой RH пока не предусмотрел.
3. Еще тулкиты есть, отличные от gtk и qt. И ничего Вы там не пофиксите. Похачите -- да. А фиксить не нужно, потому что отсутствие поддержки UTF-8 locales (не отсутствие поддержки Unicode, заметьте!) -- не ошибка и даже не отсутствие важной feature, если вывод Unicode поддерживается (про ввод не будем, Вы как автор gswitchit сами знаете, что проблем здесь нет).
5. Если народ не хочет иметь хорошие свободные шрифты, то он заслужил их отстутсвие. А мне хватит, в случае чего, шрифтов George Williams. Пусть и кривоваты, но прочитать можно.


И главное. На вопрос "Зачем решать проблему Unicode переходом на UTF-8 locale по умолчанию?" я услышал лишь признание в извращенстве :-) Я не упертый, если мне убедительно ответят на этот вопрос -- признаю неправоту. Буду рад новым аргументам.

1. ОК. Вы - за поддержку. И я - тоже. Я надеюсь, что под поддержкой мы оба, в частности, понимаем способность всех (ну, почти всех используемых:) программ жить (нормально, в т.ч. безопасно, работать) в этой локали. Теперь скажите мне - когда (и если) такой момент настанет, много ли людей останется в 8-битных локалях? На новых десктопных системах, мне кажется - 0%. На унаследованных, конечно, больше - но динамика будет и это число постепенно сводить к 0. Если Вы согласны с такой картиной мира, то и я не против. Другое дело, что этот процесс надо всячески поддерживать как прогрессивный. Само по себе оно не сложится...

Кстати, интересный опрос для LOR - "Если уникодная локаль в линухе будет поддерживаться 99% ваших любимых программ, будете ли вы использовать 8-битную?". Варианты ответов: а)да б)уже там в)ни за что г)а что такое уникод?

2. Да, проблемы с уникодом будут. Охотно верю, что системные администраторы последними начнут ставить уникодные локали на серверах. Тут первыми "жертвами" должны стать десктопы и девелоперы. Как мы с Вами уже согласились - РХ80 совсем не годится для серверов.

3. Неужели есть и другие тулкиты?:) Кстати, расскажите, а кто из них выводит уникод корректно без уникодовской локали? Честное слово - я не знаю. А те, которые не умеют - может, их, если и учить уникоду - так "снизу", а не "сверху"? Кстати, а как отношения мотифа с уникодом?

5. Да, в вопросе со шрифтами Вы, похоже, столь же экстремист, как я - с уникодом:) Да, вы правы - только мне на экране действительно монотайповские уж очень нравятся (привычны). Может, стОит переучиться...

Соббсно, мой основной внутренний аргумент - ощущение красоты архитектуры. Посмотрите, файловые системы (во всяком случае, про ext2 так мне сказал Cox, когда был в Дублине год назад) умеют уникод. Тулкиты (ну, самые продвинутые) - тоже умеют. А что посередине? Кривая 8-битная прослойка? Это же глупо - человек запускает опенофис, набирает документ (не думая про кодировки), потом хочет его сохранить - и выясняет, что не все символы ему доступны для имени файла. Ему обидно должно быть! Потом он хочет этот файл сохранить как просто текстовый - выясняется, что программа cat не справляется этот файл корректно показать. А если он его, текстовый, все-таки хочет как-то подредактировать по-быстрому - пожалуйста, изволь загрузить какой-нибудь yudit (извините, он мне не показался очень удобным). В имидже такой системы нет целостности. И именно для десктопа это очень важно - если мы хотим, чтобы линуховый десктоп воспринимался не как курьез и признак маргинальности.

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

Вот так. Наверное, на этом мои аргументы кончились...:) Да, меня очень огорчило, что мою идею поддержки уникода приняли за погоню за Win. "Покорение космоса - не моя дурацкая блажь, и не понимать это могут только очень ограниченные люди. Простите, я лучше думал о Вас!" (с) "Укрощение огня" Ничего личного, просто цитата;) Серьезно - вы же не считаете, что поддержка html mail нынешними униховыми почтовыми клиентами является погоней за Win.

Да, расскажите, пожалуйста - что именно в архитектуре локалей (или униха вообще) принципиально несовместимо с уникодом. Почему Вы считаете их "прилепленными сбоку"? Мне очень нравится то, что я слышал о plan9 - но это все пока не может рассматриваться как business-явление.

Что-то я разошелся. Вечер пятницы располагает к растеканию мыслью по древу...

А не подскажет никто как в rh 8.0 настроить обычную PS2 мышь с колесиком Logitech M-S48? выбирал все что можно в mouseconfig ,перезапускал иксы - мышь работает, а колесико нет 8-(

2anonymous (*) (2002-11-23 04:38:11.975)
Сморти в /etc/X11/XF86Config или /etc/X11/XF86Config-4 на наличие записей типа:
Section "InputDevice"
Driver "mouse"
. . .
Option "Protocol" "IMPS/2"
Option "ZAxisMapping" "4 5 6 7"
EndSection

Сорри за оффтопик: товарищи из linux-ink, плиз прочтите почтовый ящик webmaster(at)linux-ink.ru или укажите другой ящик на который можно слать вам письма. На вашем сайте так и не заметил ни одного мыла кроме webmaster@ Спасибо.

Мое мнение:
Софт, который не может работать в локали utf8, не может нормально работать с Chinese/Japanese/Korean (CJK) кодировках.
Если бы пользователи CJK были трудолюбивыми и усердными, весь гнушный софт бы сейчас нормально работал в локали utf8. В общем, виноваты CJK people в первую очередь - у них было аж 10 лет исправить весь софт :) Но и прямо сейчас можно лазать в CJK версии дистрибьютивов за спец. патчами по поддержке CJK - многие из этих патчей улучшают работу программ под utf8 локалью.
Правда у них немного другой случай - все их иероглифы не помещаются в память знакогенератора видеоадаптера..
Что касается отношения редхата к продавливанию инноваций - они ведут себя архиглупо и сами себе роют могилу - пользователи от них просто убегут если они будут продолжать так себя вести IMHO.
Но не думаю что они начнут выкидывать софт, который плохо ведет себя в utf8 (просто потому, что их целевая аудитория - USA - плохого поведения просто не заметит).
Что делать: думаю можно заваливать багрепортами багзиллу РХ - авось некоторые из них будут исправлены инженерами из РХ (хотя инженеров у них уже не много - вроде около 70).. Ну и если кому-то очень скучно - самому исправлять эти ошибки..
Позицию же остальных дистрибьюторов линукса и их представителей можно понять - корректно исправить софт для поддержки utf8 локалей - титанический труд, для некоторых программ будет легче переписать их с нуля.. Посему оффициально/неофициально/на подсознательном уровне от них вполне логично ожидать неприятие локали utf8 как дефолтовой (просьба не считать это обвинением в леняйстве; это просто практичность; не стоит просить от них нереальных вещей).
Для русскоязчных, а также для latin1 users - utf8 локаль это как золотой крестик весом в 1кг на шее - модно, но тяжело, очень дорого, нефункционально и то, без чего спокойно можно обойтись. IMHO.

2hvv (*) (2002-11-23 13:42:07.916)
Что значит "нормально работать с Chinese/Japanese/Korean (CJK) кодировками"?

Вот этого

export LC_ALL=ja_JP.eucJP
export XMODIFIERS=@im=kinput2
kinput2 &

уже хватает для ввода в gimp (gtk, да?) и в Mozilla японских символов, не говоря уже о kterm и vim (там еще работает FreeWnn сервер для перевода японской азбуки в иероглифы, но это к делу не относится).
Другое дело, что в случае такой системы ввод русских букв + японских иероглифов у меня возможен только в Mozilla, но это нужно _только_ мне, никак не японцам!
Японцы вполне могут работать даже на не-уникодной системе (комбинации японский+английский, предоставляемой локалью ja_JP.eucJP, им за глаза хватает), или я не прав?

ПС. О том, насколько смотрябельны японские man, я не знаю ничего (за неимением :-), но подозреваю, что эта проблема в локали ja_JP.eucJP решена.

ППС. Вот все думаю, ставить себе TeX-jap.rpm или как-его-там... Будет у меня он 3-язычный текст обрабатывать? Может, в рулетку сыграем? :-)

   2hvv (*) (2002-11-23 13:42:07.916)
   Что   значит   "нормально  работать  с  Chinese/Japanese/Korean  (CJK)
   кодировками"?
   Вот этого
   export LC_ALL=ja_JP.eucJP
   export XMODIFIERS=@im=kinput2
   kinput2 &
   уже хватает для ввода в gimp (gtk, да?) и в Mozilla японских символов,
   не  говоря  уже  о  kterm  и  vim (там еще работает FreeWnn сервер для
   перевода японской азбуки в иероглифы, но это к делу не относится).
Они и в utf8 нормально работают.
А ты попробуй в японской локали пустить mc (хотя это плохой пример - он
нарисовать ничего не сможет), tac, pr, wc - в общем любую утилиту, которой
надо вычислять длину текста в символах, а не байтах.

Да, ты прав :-)
[nihil@localhost nihil]$ ls -la | wc -l
317
[nihil@localhost nihil]$ ls -la | wc
wc: :213: Invalid or incomplete multibyte or wide character
wc: :314: Invalid or incomplete multibyte or wide character
wc: :315: Invalid or incomplete multibyte or wide character
wc: :316: Invalid or incomplete multibyte or wide character
wc: :317: Invalid or incomplete multibyte or wide character
317 2882 22256
[nihil@localhost nihil]$

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

По поводу крестика в 1кг. Да, сегодня это именно так, как Вы говорите. Так давайте же его облегчать - крестик-то красивый (и действительно золотой, не то что бронзулетки кои и 1251). Про нефункциональность. Скажите, в какой русской 8-битной кодировке есть символ Евро? Маленькая смешная буква е. И про очень дорого - не уверен. Все-таки в уникодной локали жить можно уже сегодня. Ну, во всяком случае, я как-то живу:) Единственные неудобные для меня вещи - лог-файлы (ненавижу проги, кладущие в лог локализованные сообщения:) и movaTK (хотя она прекрасно работает, если перед ней в явном виде сказать LANG=ru_RU.KOI8-R). Все. Да, я не являюсь профессиональным админом. Моя тачка - дескоп-девелопмент. Но живет. И работает. И не очень напрягает. Так что - наверное, не 1кг, а грамм 300. Конечно, тянет, но можно привыкнуть. И НАДО ОБЛЕГЧАТЬ ДАЛЬШЕ. А бронзулетки - в тумбочку:)

Кстати господа! А у кого в gnome terminal RH 8.0 пишет по русски? Признавайтесь! Это единственное место где Я не могу увидеть русский текст. В xterm пожалуйста, а вот в gnome terminal нет. Может кто чего подскажет?

   Так  давайте  же  его облегчать - крестик-то красивый (и действительно
   золотой,  не  то  что бронзулетки кои и 1251). Про нефункциональность.
   Скажите,   в  какой  русской  8-битной  кодировке  есть  символ  Евро?
   Маленькая  смешная буква е. И про очень дорого - не уверен. Все-таки в
Ну а где он может понадобиться? В html можно вбить это символ через эскейп-
последовательность. Во всяких офисных пакетах - через ВставкуСпецСимвола
(каким-либо образом).
Как его набить скажем на русской клавиатуре (хоть под виндой)?
Где в других местах он может пригодиться?
Зато если хранить все данные в utf8, файлы становятся больше в 2 раза. Соотв-но
по сети передаются в 2 раза медленнее (хотя их сниффить тяжелее, согласен :)
   уникодной  локали  жить  можно  уже  сегодня.  Ну, во всяком случае, я
   как-то  живу:)  Единственные  неудобные  для  меня  вещи  -  лог-файлы
Ну ты же консолью не пользуешься, сам сказал. А я вот лично в ней и сижу
только.
   (ненавижу  проги,  кладущие  в лог локализованные сообщения:) и movaTK
   (хотя  она  прекрасно  работает,  если  перед ней в явном виде сказать
   LANG=ru_RU.KOI8-R).  Все.  Да,  я не являюсь профессиональным админом.
   Моя  тачка  -  дескоп-девелопмент.  Но  живет.  И работает. И не очень
   напрягает. Так что - наверное, не 1кг, а грамм 300. Конечно, тянет, но
   можно   привыкнуть.  И  НАДО  ОБЛЕГЧАТЬ  ДАЛЬШЕ.  А  бронзулетки  -  в
   тумбочку:)
Как говориться, я не против дальнейшего облегчения. И буду благодарен тем,
кто его будет обеспечивать, и буду поддерживать морально.
Но личное время на эту реализацию этой поддержки тратить не буду. Хотя никого
отговаривать не собираюсь, и поддержу морально.
То есть неплохо иметь поддержку utf8 локалей в программах, но пользоваться
будут ей в Раше архиредко. Только русским, уехавшим в страны Европы она
из русскоязычных и нужна.

aen

> На вопрос "Зачем решать проблему Unicode переходом на UTF-8 locale по умолчанию?" я услышал лишь признание в извращенстве :-) Я не упертый, если мне убедительно ответят на этот вопрос -- признаю неправоту.

1) Вам приносят винт (флешку, флоп,..) с файлами, имена которых и содержание набраны не latin1, и локаль не известна. Известно только точно, что не UTF-* .Узнать ее возможности нет. Ваши действия ??? А если там еще и не один язык ???

2) Накрылась система (ну давайте немного пофанатзируем :-))) ) - под рукой только флоп/компакт без локалей. bash без локали будет выдавать знаки вопроса, в readline вы ничего не введете, и не то, что бы какие-то там wc и tr будут не корректно работать, а даже cp и rm останутся не у дел.

3) Чем плохо получить сразу возможность ЧИТАТЬ родной (и не только родной) язык, а возможность на нем еще и писать - подключением раскладки клавы ?? Без "export LC_ALL=...; loadfont ..." не говоря уже о монтировании...

hvv

> utf8 локаль это как золотой крестик весом в 1кг на шее - модно, но тяжело, очень дорого,

Издеваетесь ?? "Тяжело" ?? "Дорого" ?? Да линукс от темечка до пяток весь обвешан таким количеством свиселок, гуделок, пыхтелок и наколок, как ни одна другая ось ! Тут хоть реально стоящую вещь предлагают, а не очередной "прозрачный терминал", или "графический фронтенд к /bin/cp".

> нефункционально

А iocharset'ы и codepage'ы - это функционально ???

> и то, без чего спокойно можно обойтись.

Определенно издеваетесь. Обойтись можно и без русского языка. У R&T на PDP-11 с ним было туго :-)) Ничего, выдюжили мужики. :-)))

> "Вам приносят винт (флешку, флоп,..) с файлами, имена которых и содержание набраны не latin1, и локаль не известна. Известно только точно, что не UTF-* .Узнать ее возможности нет. Ваши действия ??? А если там еще и не один язык ???"

Хмм... Я прошу прощения за своё ламерство, но, интересно было бы знать, чем тут сможет помочь наличие юникодной локали? :-))

а почему тогда сразу не перейти на UCS2[4]? сказать gcc вот, мол char теперь 4 байта и вперед с песней?

> а почему тогда сразу не перейти на UCS2[4]? сказать gcc вот, мол char теперь 4 байта и вперед с песней?

Собственно, об этом en и вел речь, как я понимаю? Ибо UTF-8 - грязный хак(tm), для облегчения перевода 8-битных систем... А вот когда все будет UTF-8 - будет очередной этап перевода с него на UCS4 :))))

Прав автор статьи. Никому етот UTF не нужен. Только пустая трата времени на переписивание и переделивание прог, вместо того, чтоби тратить драгоценное время на написание нових. Опять угробиться море времени, и линукс отстанет о МС на несколько километров. :-\\

Ron

> Хмм... Я прошу прощения за своё ламерство, но, интересно было бы знать, чем тут сможет помочь наличие юникодной локали? :-))

Я прошу прощения за моё ламерство, но что, уже сейчас можно писать имена файлов на ext2-ext3 в уникоде ??

> сказать gcc вот, мол char теперь 4 байта и вперед с песней?

Потому что тогда более грамотная половина софта не будет компилится, а другая - работать.

То ЛамерОК :-)
Писать на ext2-3 можно в любой кодировке - фс пофигу, она не разбирает... мало того, нефига не шарит какая к-ка :-) Вот была кои, поставвил РХ8 - и пользовательским названиям на русском - можно сказать "до свидания" :-) если не перекодировать вручную. Новые создаются в utf8 - и их видно, естественно.
С utf8 в самом деле хак, ведь для вывода (экранного) придётся парсить все строки, чтобы правильно вычислить длину строки в отображаемых символах: что и видно в мц под РХ утф8. Отсюда и проблемы, безопасности (как говорил АЕН) - правильная прога будет парсить строку, что она там найдёт :-) и как на это среагирует?... Кроме того рост накладных на простейшую обработку этих утф8 строк...
Насчёт удлиннения перекачек - не уверен, все ucs2 и ucs4 кодировки прекрасно жмутся - как архиваторами, так и аппаратной сжималкой момеда :-)
Что касаемо для чего нужен юникод? Ну, во первых, конечно не хак УТФ.хх - а полноценный - для того чтобы было видно несколько кодировок одновременно, хотябы те: которые я выбрал в качестве используемых, а не текс с фрагментами кракозябр. и.т.п.
Ещё есть вопросы сортировки символов .... но это вообще труба :-)

ЗЫ:) ИМХО, всётаки лучше мимовую фс + система на UCS2-UCS4 :-)

немного не в тему но есть вопрос: кто-нибудь смог собрать gcc-3.2 с rawhide на rh7.3?

если смог то как?

Cимвол евро (и фунта, кстати) может пригодиться в плейн-тексте... Запросто. Набрать его в клавиатуре - не проблема. Прислать раскладку для иксов?:) Про "раздувание данных" и их компрессию любым способом - уже указали выше.

Консоль - да, самое тяжелое место для уникода. Поэтому, разумеется, наиболее легкий путь внедрения уникода - через десктоп. И именно для десктопа уникод наиболее актуален. Соббсно, о десктопе я, в основном, и писал все это время. С консолью действительно тяжело и болезненно. Хотя, конечно, это не значит, что нужно ее "бростать" в 8-битности...

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

Про русских в Европе - это я должен воспринять как наезд?:) А как насчет русских, ведущих дела с Европой? То, что символ доллара Вы можете использовать - это нормально? А вот символ евро - ненужная роскошь? (опять же, о фунте упоминать не буду).

Готов поддержать UCS2[4] так же как поддерживаю UTF-8. Для меня, если честно, не очень важен в данном случае способ представления уникода. Для меня важен сам уникод. Только америкосам будет очень сложно - а они очень ленивы. Поэтому практическая возможность внедрения этих кодировок - сомнительнся. Хотя - всякое быват... И, кстати, мне кажется (могу ошибаться) переход с UTF-8 на UCS4 - будет технологически легче, чем с 8-битности на UTF. Я неправ?

>немного не в тему но есть вопрос: кто-нибудь смог собрать gcc-3.2 с
>rawhide на rh7.3?
>
>если смог то как?

Проще поставить 8-ку и не гемороиться, так как апдейт потянет за собой
много чего....

asoneofus

> Писать на ext2-3 можно в любой кодировке

Если мне не изменяет склероз - почти любой набор 8-ми битных символов (за исключением некоторых). Я не о физической возможности говорил. :-)))

> Вот была кои, поставвил РХ8 - и пользовательским названиям на русском - можно сказать "до свидания" :-)

Все настолько плохо ??? Я думал, они хоть как-то поддержат чтение имен в иных кодировках.

> С utf8 в самом деле хак, ведь для вывода (экранного) придётся парсить все строки, чтобы правильно вычислить длину строки в отображаемых символах:

Не понял. Их по любому придется "парсить", что бы вычислить длинну - хотя бы тем же strlen(). Так какая нафиг разница ??

> Отсюда и проблемы, безопасности (как говорил АЕН) - правильная прога будет парсить строку, что она там найдёт :-) и как на это среагирует?...

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

> Кроме того рост накладных на простейшую обработку этих утф8 строк...

Тебя пугает потеря 0,003% процессорного времени ??? :-))) Или ты работаешь за ENIAC'ом ?? :-)))))))

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

А каким боком этому мешает utf-8 ??? Может ты чего перепутал с ограничениями текстового vga режима ??? :-)))

> Ещё есть вопросы сортировки символов .... но это вообще труба :-)

Наоборот - никакой трубы. Стандартный qsort () требует указания програмы сортировки.

> ЗЫ:) ИМХО, всётаки лучше мимовую фс + система на UCS2-UCS4 :-)

А на кой хрен тебе мимовая фс ?? Файловые расширения замучали ??? :-))