Теперь в системд будет свой mount - systemd-mount

До этого - виндой. Когда начал переходить на Linux прочитал про настройку локалей. И в той статье было написано, что у Ъ UNIX'оида только один вариант - KOI8-R. Не cp1251 же в самом деле. Ну и вот. Массовый переход на локаль UTF-8 исторически был уже ближе к 2010-му году. В том же ядре default_utf8 выставили в true по умолчанию только в ядре 2.6.24 (январь 2008-го). С тех пор эту переменную необходимо переопределять строчкой в inittab'е:

r2::wait:/bin/echo 0 > /sys/module/vt/parameters/default_utf8

Без wchar_t нужно держать под рукой ещё и таблицу модификаторов (диакритика и т.п.) и вручную всё это применять. Возможно это нужно применять вручную и с wchar_t. Я же говорю - цирк ещё тот.

Можно и без юзерского ввода, но тогда нужно чем-то конвертить «char *» в «wchar_t *». А чем именно это делать и можно ли вообще с ходу в этом вашем мраке не разберёшься.

Так я и юзаю собственную сборку на основе LFS'а. Без systemd.

у Ъ UNIX'оида только один вариант - KOI8-R

Даже если родным языком этого "Ъ UNIX'оида" не является русский?

Массовый переход на локаль UTF-8 исторически был уже ближе к 2010-му году.

Вообще-то примерно на 8 лет раньше, с выходом Red Hat Linux 8.0 (Psyche).

С тех пор эту переменную необходимо переопределять

Нет такой необходимости…

строчкой в inittab'е

…как, впрочем, и inittab'а.

Ну так это потому что нет в нём никакой «необходимости»

«Не нужность» и то, что «его не хотят возвращать» иллюзия, происходящая из-того, что пользователи для которых инсталятор важен уже как несколько лет назад ушли с дистрибутива.
Смысл инсталятора не в том, чтобы угодить имеющимся пользователям, а в том, чтобы приобрести новых.

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

Даже если родным языком этого «Ъ 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 к юникоду ещё не готов.

Нет такой необходимости...

У юзеров локали KOI8-R есть.

То, что он относится к «Ещё пару-тройку лет, и наступит эпоха GNU Systemd (вместо GNU Linux)», а не к «GNU Linux» (т. е. Linux как часть GNU).

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

ВП детектед.

Без wchar_t нужно держать под рукой ещё и таблицу модификаторов (диакритика и т.п.) и вручную всё это применять.

man icu.

Можно и без юзерского ввода, но тогда нужно чем-то конвертить «char *» в «wchar_t *». А чем именно это делать и можно ли вообще с ходу в этом вашем мраке не разберёшься.

Почему ты так привязался в wchar_t? Это _НЕ_ Unicode. Это wide character.

они должны думать о том как будет удобнее юзерам

Рядового юзера не должно волновать, что у него под капотом. Система должна просто работать и все тут.

Мультибайтовые функции завязаны на wchar_t. Можно, конечно, пробовать парсить юникод однобайтными, но... И выше я критиковал таки тормознутость мультибайтовых функций, которые молотят «wchar_t *».

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

Пользователи ставят федору/убунту/сусю, где все уже готово
На сервера разворачиавют типовые конфигурации, где тоже уже все настроенно и готово
А если тебе нужно поковырятся - есть гента

А теперь поставь десктопный софт из популярных
Всякие LibreOffice и т.д.
Начнется срач из кучи директорий

Почему юникод говно? Что плохого в одной кодировке для всех языков?
Если функции жрут ресурсы, то может дело в том, что они говно?

Мультибайтовые функции завязаны на wchar_t. Можно, конечно, пробовать парсить юникод однобайтными, но... И выше я критиковал таки тормознутость мультибайтовых функций, которые молотят «wchar_t *».

Во-первых, повторюсь. Это _НЕ_ Unicode. Это wchar. Почему ты пытаешься использовать wide character для Unicode не совсем понятно. В libc нет функций для работы с UTF-8.

Во-вторых, твои бенчмарки показывают только то, что на разных входных данных разные функции показывают разные результаты. Bad science, motherfucker.

Оно требует иксов, которых у меня нет. А вот GNU/Linux таки современный.

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

Потому, что то, что можно записать однобайтной кодировкой, занимает больше памяти в юникоде

Почти во всех современных ляптопах есть 16G RAM. ШЕСТНАДЦАТЬ ГИГАБАЙТ ПАМЯТИ, КАРЛ.

Это _НЕ_ Unicode. Это wchar

«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 в генте. Ждем ебилдов.

Рядовой юзер должен сам собрать свою систему из командной строки и написать конфиги руками.

Машина должна служить человеку, а не наоборот. И да, командный интерфейс пытались закопать еще во времена Windows 3.x

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 - создавать, читать, парсить,... А меньшее кол-во байт текста - быстрее обрабатывать и удобнее хранить.

удобнее хранить

ААААААААААААААААААХАХАХАХАХАХАХАХАХАХАХАХА.

Человек не умеет должным образом пользоваться тем, что не собрано его руками. Так что, нужно сначала собрать, а только потом пользоваться.

Мало ли кто там что пытался. Командная строка рулит и всегда будет рулить.

Входных данных (в некоторых случаях) больше

Ну так из за юникода же. Чтобы юникодные функции не тормозили они должны парсить быстрее чем однобайтные. Иначе это тормоза by design.

ИМХО:
1)Уже вышел RPI2
2)RPI в моём понимании это либо терминал, либо браузер или видиоплеер, и там и там скорость обработки юникода не должна быть критичной.

Ну так из за юникода же. Чтобы юникодные функции не тормозили они должны парсить быстрее чем однобайтные. Иначе это тормоза by design.

Чувак, если скормишь эту строку strlen, strlen тоже будет работать дольше. strlen тормозит?

Мало ли кто там что пытался. Командная строка рулит и всегда будет рулить.

Картиночки ты тоже в консоли рисуешь?

Так реализация нативной консоли в ядре Linux ещё не готова к шрифтам больше чем 64 Кб. Ну будут показываться символы однобайтной кодировки, а остальные «квадратами» - что это поменяет? А так тот же lynx адаптирует ряд юникодных символов к KOI8-R. Например, звёзды на ЛОРе у меня отображаются символами '*'. Да и в памяти тексты в юникоде займут больше места, а памяти там и так мало.

Так однобайтным функциям нужно скармливать строки в однобайтных кодировках, например KOI8-R. А это меньше байт чем в UTF-8.

Ещё раз повторяю, что я говорю про конкретные последовательности символов. Если мы одну и туже последовательность символов конвертируем и в KOI8-R и в UTF-8, то получается разное кол-во байт. _При текстах в KOI8-R меньше байт нужно парсить_. А _при тех же самых последовательностях символов в UTF-8 парсить больше_. И от этого никуда не деться.

Человек-то работает с конкретными последовательностями символов. И мне, например, не надо обрывка строки, который вмещается в выделенные N байт, а потому парсится с той же скоростью что и N символов в однобайтной кодировке. Строки нужно парсить полностью. А потому и сравнивать производительность нужно не по байтам, а по кол-ву символов. Независимо от кодировок.

нативной консоли в ядре Linux

Нативная консоль в ядре Linux нужна только для того, чтобы починить упавшую систему.

Нет, она нужна чтобы в ней жить без иксов.

Отлично, ты наконец-то пришел к тому, что тормозят не функции. Едем дальше. А теперь нам нужно разобраться, в каком конкретно случае ты заметишь ощутимую разницу между utf-8 и koi8-r.

Нет, она нужна чтобы в ней жить без иксов.

За что ты себя так ненавидишь?

В GNOME и реестр есть, и это тоже плохо.

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

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

А что хорошего?

Какие «картиночки»? Я рисую псевдографикой.

Какие «картиночки»? Я рисую псевдографикой.

Повторюсь: за что ты себя так ненавидишь?

В бинарности. Конфиги должны быть в человекочитаемом plaintext'е.

Удобнее для машинной обработки чем простыни текста.

Удобнее для машинной обработки чем простыни текста.

Неудобнее для сисадмина, который это все конфигурит. Многие программы (e.g. nftables) реализуют собственный DSL для конфигурации. Пихать его в key-value будет довольно неудобно. Ну или правила для logrotate.

чем с БД с неясными и не ведомыми ключами

Можно же «объединить» справку (man/info/howto) с реестром/БД. Открыл ветку, а сбоку справка по всем параметрам. Это может получиться даже лучше, чем man-ы.

В случае обработки сотен тысяч текстовых файлов конечно же. Но, это по производительности. А по жручести памяти всё произойдёт гораздо быстрее. Тем более что часто проще дампить кучу текста не по разным текстовым файлам, а в один. Так получаются текстовые файлы на много гигабайт (в KOI8-R). А если ещё начать работать с несколькими параллельно...

Можно же «объединить» справку (man/info/howto) с реестром/БД. Открыл ветку, а сбоку справка по всем параметрам. Это может получиться даже лучше, чем man-ы.

Ну, man'ы описывают не только опции конфигурации.