tiphareth: mega-permissions --files 644

(Читать комментарии) - (Добавить комментарий)

grusha
2023-08-17 22:05 (ссылка)

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

Линукс, помимо всего прочего, много заботится о том чтобы поиск файла по имени работал как можно быстрее. Потому что разные программы очень часто обращаются к разным файлам по имени. Особенно на серверах, кстати. Вот, можешь почитать: https://www.kernel.org/doc/html/latest/filesystems/path-lookup.html

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

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

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

(Анонимно)
2023-08-18 02:30 (ссылка)

> Если строка это по определению последовательность байт, то разным последовательностям всегда соответствуют разные строки.

нет, конечно. и utf8/16/64 тут ни при чем. я ж дал ссылку на стнадарт, прочти про каноническое равенство строк. Одна строка по-разному представляется последовательностями юникод пойнтов, а последовательности пойнтов потом кодируется в последовательность байтов - это уже utf.

> если ты хочешь думать не о байтах, а об абстрактных символах, - юзай более высокоуровневые абстрации, более высокоуровневые API, только и всего

я только за. и в каком API мне найти функцию OpenFileUnicode ?

(Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth
2023-08-18 03:48 (ссылка)

>и в каком API мне найти функцию OpenFileUnicode ?

если бы она была нужна, ее бы написали
не надо нахуй никакого юникода в названиях файлов

Родина им дала ascii — носи! Носи ascii, блядь! Не хочу, хочу жрать говно!
Что такое? Это линукс?! Это линукс?! Суки… Мудачьё — программисты. Погоны нацепили, говно жрут — пидоры, блядь, ёбаные…

(Ответить) (Уровень выше) (Ветвь дискуссии)

(Анонимно)
2023-08-18 06:47 (ссылка)

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

(Ответить) (Уровень выше)

grusha
2023-08-18 11:35 (ссылка)

Какое именно слово в словосочетании "Если строка это по определению последовательность байт" тебе непонятно? Для ОС строка это последовательность байт и только. Для многих приложений тоже.

>я только за. и в каком API мне найти функцию OpenFileUnicode ?

Откуда я знаю. Если нет, напиши. API для создания файлов есть, API для нормализации строк наверно тоже есть (было бы очень смешно если нет: "стандарт" 30 лет как есть, а имплементации нет), комбинировать одно с другим - дело тривиальное, не?

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

(Анонимно)
2023-08-18 14:17 (ссылка)

Лол. Опять ты программист тебе надо ты пиши.
Расскажи это Эпплу. У них имя файла это декомпонованный юникод например, когда все остальные везде используют компонованный.

> (было бы очень смешно если нет: "стандарт" 30 лет как есть, а имплементации нет)

ну вот я и смеюсь. Стандарт не может стать стандартом, если каждый будет "ты программист тебе надо ты пиши".
Вон баш ваш спокойно матчит на уайлдкард символы юникода, а не байты, и не выебывается. И апач всякий отдает файлы по именам без проблем.
Но "в каком это АПИ" никто не знает.

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

Во первых, сраные программеры хотят директории тоже на своих фарси называть.
Во-вторых, сраный Апач не хочет читать каждый файл, чтоб ответить на ГЕТ ё.тхт. Ты ж сам говоришь, что надо быстро, особенно бля на сервере.
Сервер же бля на запросы отвечает.
А запросы это строки. Юникод. И если он будет в кернеле, сервера будут работать и быстро и стандартизовано.
Но этого не будет, потому что Каледин сказал нахуй юникод.
Не, я понимаю, никто не мешает программерам писать свои сервера со своими датабейсами имен и слоями кэшей. Вон апач же на линуксе быстро работает. Быстрее же, чем сраный виндоуз. Быстрее же, да? Ну только если без сраного юникода?

(Ответить) (Уровень выше) (Ветвь дискуссии)

grusha
2023-08-19 00:40 (ссылка)

>Лол. Опять ты программист тебе надо ты пиши.

Речь шла о написании кода вычисляющего 2 + 2 * 2, с использованием готовых операций + и *.

>Расскажи это Эпплу. У них имя файла это декомпонованный юникод например, когда все остальные везде используют компонованный.

Теряюсь в догадках, почему меня это должно ебать.

>Стандарт не может стать стандартом, если каждый будет "ты программист тебе надо ты пиши".

Если стандарт не торопятся имплементировать (или даже так: имплементация есть, но юзать ее не торопятся), значит недорогого этот стандарт стоит.

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

Anyway, в стандарте юникода что-то говорится об именах файлов?

>Вон баш ваш спокойно матчит на уайлдкард символы юникода, а не байты

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

>Но "в каком это АПИ" никто не знает.

Что мешает узнать? Код открыт.

>Во-вторых, сраный Апач не хочет читать каждый файл, чтоб ответить на ГЕТ ё.тхт. Ты ж сам говоришь, что надо быстро, особенно бля на сервере.
>Сервер же бля на запросы отвечает.

А, то есть проблема не в том что имена файлов могут быть неканоничные (или где энфорсить их каноничность - в юзерспейсе или в кернеле), а в том что строки в GET запросах могут быть неканоничные? И поэтому приходится каноникализировать при каждом запросе, а не только при создании файлов? Ну ок, я сочувствую этой проблеме, а ядро и его файловые интерфейсы каким боком к http запросам?

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

(Ответить) (Уровень выше)

(Анонимно)
2023-08-18 06:58 (ссылка)

> Ты при этом предлагаешь, чтобы он вместо простого strcmp проверял юникодные строки на эквивалентность. Ну ты понел, да?

Чисто чтоб придраться: это не очевидный аргумент. Ты говоришь "эта хуйня и так сложная, а ты ее еще затормозить хочешь". Да, а может она уже такая сложная, что ебаный юникот будет инсигнификант. Ну ты понел, да? такие поверхностные аргументы про перформанс не канают

(Ответить) (Уровень выше) (Ветвь дискуссии)

grusha
2023-08-18 11:41 (ссылка)

Ты таки не понел. Сложно сделать чтоб оно работало быстро, но таки можно, и это таки сделано.

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

Бремя доказательства на тебе. Например, юникодные таблицы занимают много места в памяти, так что мне неочевидно, что каноникализацию или сравнение юникодных строк в принципе можно реализовать cache-efficiently. Тебе очевидно? Код в студию.

(Ответить) (Уровень выше) (Ветвь дискуссии)

(Анонимно)
2023-08-18 14:39 (ссылка)

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

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

Этому срачу, естественно, много лет, и этот диалог уже давно написан

(Ответить) (Уровень выше) (Ветвь дискуссии)

grusha
2023-08-19 00:14 (ссылка)

Ты предлагаешь такое-то изменение в API ядра (несовместимое, кстати, ни с существующей posix-семантикой сисколов, ни с семантикой существующих физических файловых систем, т.е. несовместимое вообще почти ни с чем; ну да ладно, мы сейчас говорим о производительности). Соответственно, на тебе бремя доказательства того, что это хорошая идея.

И это ты не мне будешь доказывать, а мейнтейнерам ядра, когда будешь сабмитить свои патчи.

>Да, средняя взвешенная производительность по всем юзкейсам

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

>Особенно учитывая, что вебсервера давно используют кернел кешинг

Не знаю, о чем это. Часть сервера реализована как модуль ядра? В таком случае что мешает в этом модуле и реализовать все чего ему не хватает?

(Ответить) (Уровень выше)

(Читать комментарии) -