Локали в кодировках, отличных от UTF-8, объявлены устаревшими в Debian

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

Одно дело - убирать UTF-8 из GUI-настроек. Тут я только поддержу. Хотя по-моему там и так его не было, ставил последние версии дебиана, оно молча UTF-8 ставило и не спрашивало. Другое дело - объявлять его deprecated, хотя никаких объективных причин этому лично я не вижу.

Кодовая страница для однобайтной кодировки занимает один килобайт, если ничего не сжимать. Тысяча кодовых страниц это один мегабайт. Даже если каждый язык будет реализовывать его самостоятельно, а не реюзать какой-нибудь libiconv, который никуда не девается, всё равно это ерунда. А если не полениться и сжать, то там будут десятки-сотни килобайтов от силы.

Кодовая страница для однобайтной кодировки

Не все legacy-кодировки однобайтные.

Опенсорс, как правило, написан по принципу «работает на моей машине, у кого не работает — форкните сами». Понятно, что всем кодерам объяснять, почему ascii плохо несмотря на то, что написано в их туториале по сям 1990 года выпуска — сложнее, чем просто задепрекэйтить.

Ну речь же идёт о том, что они упразднили все кодировки, а не какие-то странные. Я не знаю, что там за eu-jp, про такую и не слышал никогда. Но какие проблемы поддерживать CP1251, например, я не понимаю.

В CP1251 нет emoji !!!!

И это хорошо.

Неважно хорошо или плохо. Реальность такова что уже стало неотемлимым атрибутом :)

:-O

какие-то странные

Что в ней странного? Это стандартная линуксовая кодировка для японского из до-utf8 времён. Чем она хуже cp1251?

Есть shift-jis, стандартная виндовая доюникодная кодировка. Она ещё веселее. Почему cp1251 должна поддерживаться, а она нет?

Ну-ну.

Попробуйте на каком-нибудь Хабре эмодзю вставить.

А всему виной MySQL, у которого несколько вариантов кодировки для UTF-8, и люди десятилетиями не замечали, потому что всё работало.

Я без понятия, что это за кодировка. Если не сложно, пускай поддерживается. CP1251 поддерживать точно не сложно.

Хз, на реддите работает.

Скорее всего этот зоопарк никто не хочет поддерживать. Никому не нужно, вот и хочется упростить.

Смутно помню, что локали в glibc были какие-то странные, с глобальным состоянием и ещё каким-то тупняком.

Локалями должно прикладное приложение жонглировать, если ему это нужно. Это к вопросу о wine.
Кому не нужно, тех насильно заставляем поддерживать utf-8, что есть хорошо и правильно.

Так из glibc'а поддержку неюникодных кодировок никто не выкидывает, и их поддержка там вообще реализована как поддержка подмножеств юникода.

Тема конкретно про Debian и диалоги его тулз, которые теперь при настройке $LANG и $LC_ALL будут предлагать только UTF-8. Не более того.

Кому не нужно, тех насильно заставляем поддерживать utf-8, что есть хорошо и правильно.

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

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

Кому не нужно, тех насильно заставляем поддерживать utf-8, что есть хорошо и правильно.

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

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

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

Да, если экосистема языка мешается, вместо того, чтобы помогать.

к тому же такой код медленнее работает

Да. Но это небольшая часть рантайма, никто не заметит.

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

Если взять тот же python, то там манипуляции со строками медленные вовсе не из-за utf-8.
Тем не менее полмира на этом пишет: статус utf-8 как first class citizen важнее производительности почти для всех.

Тем не менее полмира на этом пишет: статус utf-8 как first class citizen важнее производительности почти для. всех.

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

То есть кодировок надо две, для окошек utf, а для внутренностей программ и вывода в консоль однобайтную кодировку, всё равно там всё будет на английском.

Тем не менее полмира на этом пишет: статус utf-8 как first class citizen важнее производительности почти для. всех.

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

То есть кодировок надо две, для окошек utf, а для внутренностей программ и вывода в консоль однобайтную кодировку, всё равно там всё будет на английском.

Тут вот какое дело, не код для кодировок пишут и под код данные, а работают с данными, которые надо обрабатывать корректно, альтернативы юникоду просто нету

всё равно там всё будет на английском

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

Делать по своему можно что и как угодно, никто обычный null-terminated char на мороз не выкинет. Только если есть нормальная поддержка utf-8, вы сами забьёте на велосипединг с поиском подстрок, перекодированием в utf-16 и прочее.

Пока в Вилларибо дописывают функции, как разбить utf-8 строку по символу и обрезать вторую часть по произвольному числу глифов, в Виллабаджо уже давно задеплоено в продакшен.