До этого - виндой. Когда начал переходить на Linux прочитал про настройку локалей. И в той статье было написано, что у Ъ UNIX'оида только один вариант - KOI8-R. Не cp1251 же в самом деле. Ну и вот. Массовый переход на локаль UTF-8 исторически был уже ближе к 2010-му году. В том же ядре default_utf8 выставили в true по умолчанию только в ядре 2.6.24 (январь 2008-го). С тех пор эту переменную необходимо переопределять строчкой в inittab'е:
Без wchar_t нужно держать под рукой ещё и таблицу модификаторов (диакритика и т.п.) и вручную всё это применять. Возможно это нужно применять вручную и с wchar_t. Я же говорю - цирк ещё тот.
Можно и без юзерского ввода, но тогда нужно чем-то конвертить «char *» в «wchar_t *». А чем именно это делать и можно ли вообще с ходу в этом вашем мраке не разберёшься.
Ну так это потому что нет в нём никакой «необходимости»
«Не нужность» и то, что «его не хотят возвращать» иллюзия, происходящая из-того, что пользователи для которых инсталятор важен уже как несколько лет назад ушли с дистрибутива. Смысл инсталятора не в том, чтобы угодить имеющимся пользователям, а в том, чтобы приобрести новых.
Например я ставил Генту, но сопутствующая возня для меня настолько не удобна, что превышает желание гентой пользоваться.
Даже если родным языком этого «Ъ UNIX'оида» не является русский?
Так статья писалась для русскоязычных юзеров.
Вообще-то примерно на 8 лет раньше, с выходом Red Hat Linux 8.0 (Psyche).
Смотря что чем называть. Так-то юникод появился в glibc раньше KOI8-R. Юникод впилили в glibc 2.0.1 (февраль 1997-го), а KOI8-R в 2.1.1 (май 1999-го). Поэтому там где нужно мультибайтовые функции могли задействоваться параллельно с локалью KOI8-R. А вот чтобы локаль UTF-8... Люди, видимо, долго ждали хороших векторных TTF шрифтов. В дистрибутивах начала 2000-х были в основном растровые для KOI8-R. Собственно, и сейчас в ядре действует куча ограничений на PSF шрифты. В т.ч. нельзя поставить шрифт весом более чем 64 Кб. Про кол-во символов вообще молчу. При размере символа 16x30 на однобайтную кодировку хватает, но не более. Так что, в этом смысле Linux к юникоду ещё не готов.
пользователи для которых инсталятор важен уже как несколько лет назад ушли с дистрибутива. Смысл инсталятора не в том, чтобы угодить имеющимся пользователям
Без wchar_t нужно держать под рукой ещё и таблицу модификаторов (диакритика и т.п.) и вручную всё это применять.
man icu.
Можно и без юзерского ввода, но тогда нужно чем-то конвертить «char *» в «wchar_t *». А чем именно это делать и можно ли вообще с ходу в этом вашем мраке не разберёшься.
Почему ты так привязался в wchar_t? Это _НЕ_ Unicode. Это wide character.
Мультибайтовые функции завязаны на wchar_t. Можно, конечно, пробовать парсить юникод однобайтными, но... И выше я критиковал таки тормознутость мультибайтовых функций, которые молотят «wchar_t *».
Не следует путать ламеров с рядовыми юзерами. Рядовой юзер должен сам собрать свою систему из командной строки и написать конфиги руками. А если потом его конфиги начинают игнорироваться, а в системе появляется какой-то троянистый комбайн...
Пользователи ставят федору/убунту/сусю, где все уже готово На сервера разворачиавют типовые конфигурации, где тоже уже все настроенно и готово А если тебе нужно поковырятся - есть гента
Мультибайтовые функции завязаны на wchar_t. Можно, конечно, пробовать парсить юникод однобайтными, но... И выше я критиковал таки тормознутость мультибайтовых функций, которые молотят «wchar_t *».
Во-первых, повторюсь. Это _НЕ_ Unicode. Это wchar. Почему ты пытаешься использовать wide character для Unicode не совсем понятно. В libc нет функций для работы с UTF-8.
Во-вторых, твои бенчмарки показывают только то, что на разных входных данных разные функции показывают разные результаты. Bad science, motherfucker.
«wide character» - это и есть «символ, который потенциально может весить больше чем 1 байт». То, что и привнесено юникодом.
на разных входных данных
Это одни и теже входные данные, только в разных кодировках. А я про то и говорил. Уже из за одного того, что в UTF-8 текст резко пухнет в байтах, _одну и туже последовательность символов_ становится дольше парсить в байтах. Тормоза by design. Вот если бы байт было бы столько же... Но, это возможно было бы только в том случае если бы юникод был однобайтным. Таким образом от преимуществ однобайтных кодировок никуда не деться.
Это одни и теже входные данные, только в разных кодировках. А я про то и говорил. Уже из за одного того, что в UTF-8 текст резко пухнет в байтах, _одну и туже последовательность символов_ становится дольше парсить в байтах. Тормоза by design. Вот если бы байт было бы столько же... Но, это возможно было бы только в том случае если бы юникод был однобайтным. Таким образом от преимуществ однобайтных кодировок никуда не деться.
А у Raspberry Pi 1 256-512 Mb RAM. Ресурсы железа надо экономить, тогда софт будет более кроссплатформенным и им будет приятнее пользоваться. А то понапишут жирного софта которому подавай 16 ядер проца и 32 гига оперативы...
А у Raspberry Pi 1 256-512 Mb RAM. Ресурсы железа надо экономить, тогда софт будет более кроссплатформенным и им будет приятнее пользоваться. А то понапишут жирного софта которому подавай 16 ядер проца и 32 гига оперативы...
Уф... Ладно, давай проще? Ты можешь на RPI запустить git? Можешь. Git использует utf-8 внутри. Всё. Заткнись и добро пожаловать в 21 век.
Это не дыра, это последовательная логика. Чем больше байт тем их дольше парсить. Так? Так. Одна и таже последовательность символов в KOI8-R и UTF-8 занимает разное кол-во байт. Так? Так. Ну и вот.
Ну там же можно сделать и системд. Хотя бы для повышения скиллов в работе с ним, поскольку в вакансиях чаще встречается знание центоси. Думаю, что имеет смысл держать хотя бы одну генту с системд как способ избежать установки чего-то другого. Было бы интересно узнать об опыте тех, кто использует systemd-mount в генте. Ждем ебилдов.
Deleted ()
Последнее исправление: Deleted
(всего
исправлений: 4)
git можно и не запускать. Да и сама по себе внутренняя отсылка к юникоду ещё почти ничего не означает. В glibc юникод появился раньше чем KOI8-R, и для glibc KOI8-R выглядит как набор символов юникода. Но, тем менее, есть локаль KOI8-R, которая позволяет работать с текстами в KOI8-R - создавать, читать, парсить,... А меньшее кол-во байт текста - быстрее обрабатывать и удобнее хранить.
Это не дыра, это последовательная логика. Чем больше байт тем их дольше парсить. Так? Так. Одна и таже последовательность символов в KOI8-R и UTF-8 занимает разное кол-во байт. Так? Так. Ну и вот.
Да нет, это именно что дыра. Ты говоришь, что _функции_ тормозят. Нет, функции не тормозят. Входных данных (в некоторых случаях) больше. Функции тут не при чем.
git можно и не запускать. Да и сама по себе внутренняя отсылка к юникоду ещё почти ничего не означает. В glibc юникод появился раньше чем KOI8-R, и для glibc KOI8-R выглядит как набор символов юникода. Но, тем менее, есть локаль KOI8-R, которая позволяет работать с текстами в KOI8-R - создавать, читать, парсить,... А меньшее кол-во байт текста - быстрее обрабатывать и удобнее хранить.
ИМХО: 1)Уже вышел RPI2 2)RPI в моём понимании это либо терминал, либо браузер или видиоплеер, и там и там скорость обработки юникода не должна быть критичной.
Так реализация нативной консоли в ядре Linux ещё не готова к шрифтам больше чем 64 Кб. Ну будут показываться символы однобайтной кодировки, а остальные «квадратами» - что это поменяет? А так тот же lynx адаптирует ряд юникодных символов к KOI8-R. Например, звёзды на ЛОРе у меня отображаются символами '*'. Да и в памяти тексты в юникоде займут больше места, а памяти там и так мало.
Так однобайтным функциям нужно скармливать строки в однобайтных кодировках, например KOI8-R. А это меньше байт чем в UTF-8.
Ещё раз повторяю, что я говорю про конкретные последовательности символов. Если мы одну и туже последовательность символов конвертируем и в KOI8-R и в UTF-8, то получается разное кол-во байт. _При текстах в KOI8-R меньше байт нужно парсить_. А _при тех же самых последовательностях символов в UTF-8 парсить больше_. И от этого никуда не деться.
Человек-то работает с конкретными последовательностями символов. И мне, например, не надо обрывка строки, который вмещается в выделенные N байт, а потому парсится с той же скоростью что и N символов в однобайтной кодировке. Строки нужно парсить полностью. А потому и сравнивать производительность нужно не по байтам, а по кол-ву символов. Независимо от кодировок.
Отлично, ты наконец-то пришел к тому, что тормозят не функции. Едем дальше. А теперь нам нужно разобраться, в каком конкретно случае ты заметишь ощутимую разницу между utf-8 и koi8-r.
Удобнее для машинной обработки чем простыни текста.
Неудобнее для сисадмина, который это все конфигурит. Многие программы (e.g. nftables) реализуют собственный DSL для конфигурации. Пихать его в key-value будет довольно неудобно. Ну или правила для logrotate.
Можно же «объединить» справку (man/info/howto) с реестром/БД. Открыл ветку, а сбоку справка по всем параметрам. Это может получиться даже лучше, чем man-ы.
В случае обработки сотен тысяч текстовых файлов конечно же. Но, это по производительности. А по жручести памяти всё произойдёт гораздо быстрее. Тем более что часто проще дампить кучу текста не по разным текстовым файлам, а в один. Так получаются текстовые файлы на много гигабайт (в KOI8-R). А если ещё начать работать с несколькими параллельно...
Можно же «объединить» справку (man/info/howto) с реестром/БД. Открыл ветку, а сбоку справка по всем параметрам. Это может получиться даже лучше, чем man-ы.