love5an | Почему Линукс - говно. Часть 1. п╒п╣п╨я│я┌.

Таки решил начать писать цикл статей, где я буду долго, обстоятельно, и по пунктам, обосновывать почему мне так не нравится Линукс(и отчасти, Unix вообще), и даже больше - почему я считаю его просто говном.

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

Заголовок можно расшифровать вот тут:
http://www.artlebedev.ru/tools/decoder/

Да, все вещи, связанные с этим вот словом - одна из очень веских причин называть линукс говном(да и не только его - и многие другие unix-like системы тоже).

Вообщем, с текстом в линуксе ад и погибель.

В Windows все просто и прозрачно - с кодировками мы мучаемся только когда работаем с данными из файлов и прочих бинарных блобов^[1].

Для системных же вызовов, включая чтение текста с консоли, у нас всегда есть функции с суффиксом «W», про которые мы точно знаем - там и на входе и на выходе используется UTF-16, вне зависимости от того, как локализована система, или, скажем, аниму какой страны производства смотрит пользователь в данный момент.

В именах файлов Windows всё так же просто и понятно - имена файлов, и, вообще, имена каких-либо объектов системы, это именно текст, и не просто бинарные блобы, содержащие хрен пойми что вплоть до управляющих символов, заставляющих терминал издавать звуки, а буквы юникода закодированные в UTF-16. Для имен файлов и вообще, путей, существуют четкие и строгие соглашения, навязываемые самой системой - например, имена разделяются или слэшем(причем слэш это вам не байт 00101111b(47), а буква из юникода с кодом 002Fh), и/или обратным слэшем(причем только им, если путь в форме UNC), например, и в них не может быть некоторых литер - и с путями другого вида система просто не работает^[2].

Но в линуксе, и многих подобных ему unix-like системах - ничего такого просто нет. Имя файла это просто куча байт.

Поэтому, например, существуют целые талмуды о том, как правильно работать с путями файлов даже из банального bash^[3], заточенного, казалось бы, на юникс по самые уши.

Если говорить о кодировках, то большинство разработчиков, админов и пользователей Linux по умолчанию подразумевает под текстом ASCII-7, Latin-1, или UTF-8, но на практике, это просто не правильно, и часто просто не работает, и ломается при первом же шаге в сторону(и ломается даже не только у пользователей из каких-нибудь восточных стран с их иероглифами в CJK, а даже просто у каких-нибудь ретроградов из бСССР, у которых любимая кодировка - что-нибудь из линейки KOI8), или при переносе файла с других операционных систем или просто с переносных носителей.^[4]

Самое смешное что линукс, да и вообще юникс, при этом всем, ориентирован именно на текстовые протоколы.

То есть, хотя бы в том плане, что если на Windows мы, для работы с системой, используем какие-либо функции из системных DLL, которые работают со структурами языка Си и вообще, со структурированными данными, со стабильным ABI, если для системных API и межпроцессного взаимодействия у нас есть объектно-ориентированный COM, то на линуксе для решения задач, связанных с общением с системой и другими программами принято гонять plain-текстом по файлам(в т.ч. VFS), пайпам и сокетам, использовать текстовые конфигурационные файлы(привет DOS и Win3x с их .ini!), использовать для многих программ и сервисов разнообразные кривые скриптовые языки программирования, типа bash, perl, python или ruby(которые добавляют своих приколов^[5]), и т.п.

Кроме проблем с представлением текста это всё, понятное дело, приносит в систему неслабые такие накладные расходы по производительности, памяти и месту на диске(хотя последнее в наше время уже не так актуально, да, если только вы не используете source-based дистрибутив).