> Тут как - если посмотреть в прошлое, когда компьютеры развивались в англоязычных странах и/или теми, кто знает английский как родной, вопрос локали был не особо существенен.
Тем не менее системная консольная команда date уважает локаль, а АПИ - нет.
Вообще тупое клонирование этим и плохо - автору приходится смотреть в прошлое, в то время как если уж делаешь что-то новое - то лучше вообще-то в будущее смотреть, а даже не на настоящее. Разработчики юнипсов вон лет на 15-20 вперёд всё-таки смотрели. Но клонировать это в 90х уже как-то неправильно было, нехорошо Линус поступил.
> С \n вообще весело, я был поражен, раньше не знал о таком. Приёмы прокетирования, видимо, были другие, а уж вывод только в терминал считался чем-то общепринятым. Оттого и поставили тогда, а теперь ломать поздно.
Терминал не терминал, но есть системный подход к разработке, а есть бессистемный: на выходе у первого подхода получается система, а у второго - груда разноцветных костылей разного размера. И если продуманную систему можно _понять_, то в груде костылей запомнить каждый баг невозможно, поэтому под ту же венду программировать проще.
> Вообще Си, имхо, сборник костылей by design (плюйте, плюйте!), так как выразительность языка променяли на производительность.
Не, сам-то Си - нормальный язык, оптимальный я бы сказал. Не позволяет программистам возводить иерархии классов с множественным наследованием и перегрузкой операторов чтобы они делали что-то неочевидное. Но вот библиотеки эти евоные..
> Впрочем, я даже не знаю, можно ли было сделать иначе.
Конечно можно было бы. Сделать новую библиотеку с учётом накопленного за последние 20-30 лет опыта взломов юникс-систем, а старую задепрекатить.
>> Но вот нахер нам, например, надо какое-нибудь pthread_(set|get)specific()??? Что, нельзя просто локальную переменную определить для потокоспецифичных байтов??
> Думаю, это было бы сложно сделать.
Почему?? Тред - он функция. Локальная переменная сидит на стеке. В венде всё что тебе надо знать для работы с тредом - это то, что существует такая функция как CreateThread. Всё. Везде, в каждом руководстве для любых чайников написано: хочешь тред - сделай функцию и запусти её посредством CreateThread, бойся одновременного доступа к ресурсам (см.объекты синхронизации). Всё, это всё, что надо знать. Есть ещё несколько функций для работы с приоритетами, но нечасто они нужны.А что мы видим в реализации тредов в линупсе? Куча каких-то функций, которые нахрен не нужны и/или не имеют отношения к собственно к задаче создания треда, и список которых не помещается в экран.
> Всё объяснить не могу:) Но у дбуса, например, немного другая задача - он должен быть жутко универсальным, типа шины обмена данных для всех, кому захочется, и чтоб формат был относительно унифицирован.
Поддержка транзакций, бродкастинг в сети, гарантированная доставка сообщений, балансировка нагрузки (ну, всё то что, приходит в голову при мысли о жутко универсальной шине) - это всё дэбус делает?
> Хоть для баш-скрипта и программы на эрланге. Тут приличных решений вообще мало, не в память же друг другу писать (особенно на баше).
А почему нет?? Есть же разделяемая память - специально для этого. Всяко быстрее чем сокетами гонять, небось. Некоторые процессы ею пользуются (ipcs -m). Надо стандартизованно и из баша - ну почему не создать систему поименования и не приделать библиотечку утилит, которые позволят разным приложениям обмениваться данными и сообщениями посредством стандартных механизмов юнипса. Утилиту для баша можно назвать dbus-send, например.
> Чтоб мой виджет для awesome мог дёргать демон, контролирующий раскладку клавиатуры, например. Реализация, опять же, там немного странная, но тут уж как смогли.
Демон при создании открывает очередь сообщений, в которую ему заинтересованные приложения отправляют команды в заранее оговоренном формате. Администратор может контролировать нагрузку на очередь сообщений и параметры этих очередей. Чо ещё надо? Ну может сокет открыть - какая разница.
> Сокеты, по идее, дают возможность сделать более общую штуку, которая работает и локально, и по сети. Только код инициализации меняй. Это всё, на самом деле, из косяков юникса вытекает, ведь изначально была неплохая концепция "всё есть файл", а тут появилась сеть, и всё перестало быть файлом. Вот в plan 9, кстати, пытались это решить, и вроде даже смогли, но он уже умер по другим причинам.
Re:[tech brain][технота]
> Тут как - если посмотреть в прошлое, когда компьютеры развивались в англоязычных странах и/или теми, кто знает английский как родной, вопрос локали был не особо существенен.
Тем не менее системная консольная команда date уважает локаль, а АПИ - нет.
Вообще тупое клонирование этим и плохо - автору приходится смотреть в прошлое, в то время как если уж делаешь что-то новое - то лучше вообще-то в будущее смотреть, а даже не на настоящее. Разработчики юнипсов вон лет на 15-20 вперёд всё-таки смотрели. Но клонировать это в 90х уже как-то неправильно было, нехорошо Линус поступил. > С \n вообще весело, я был поражен, раньше не знал о таком. Приёмы прокетирования, видимо, были другие, а уж вывод только в терминал считался чем-то общепринятым. Оттого и поставили тогда, а теперь ломать поздно.
Терминал не терминал, но есть системный подход к разработке, а есть бессистемный: на выходе у первого подхода получается система, а у второго - груда разноцветных костылей разного размера. И если продуманную систему можно _понять_, то в груде костылей запомнить каждый баг невозможно, поэтому под ту же венду программировать проще.
> Вообще Си, имхо, сборник костылей by design (плюйте, плюйте!), так как выразительность языка променяли на производительность.
Не, сам-то Си - нормальный язык, оптимальный я бы сказал. Не позволяет программистам возводить иерархии классов с множественным наследованием и перегрузкой операторов чтобы они делали что-то неочевидное. Но вот библиотеки эти евоные..
> Впрочем, я даже не знаю, можно ли было сделать иначе.
Конечно можно было бы. Сделать новую библиотеку с учётом накопленного за последние 20-30 лет опыта взломов юникс-систем, а старую задепрекатить.
>> Но вот нахер нам, например, надо какое-нибудь pthread_(set|get)specific()??? Что, нельзя просто локальную переменную определить для потокоспецифичных байтов??
> Думаю, это было бы сложно сделать.
Почему?? Тред - он функция. Локальная переменная сидит на стеке. В венде всё что тебе надо знать для работы с тредом - это то, что существует такая функция как CreateThread. Всё. Везде, в каждом руководстве для любых чайников написано: хочешь тред - сделай функцию и запусти её посредством CreateThread, бойся одновременного доступа к ресурсам (см.объекты синхронизации). Всё, это всё, что надо знать. Есть ещё несколько функций для работы с приоритетами, но нечасто они нужны.А что мы видим в реализации тредов в линупсе? Куча каких-то функций, которые нахрен не нужны и/или не имеют отношения к собственно к задаче создания треда, и список которых не помещается в экран.
> Всё объяснить не могу:) Но у дбуса, например, немного другая задача - он должен быть жутко универсальным, типа шины обмена данных для всех, кому захочется, и чтоб формат был относительно унифицирован.
Поддержка транзакций, бродкастинг в сети, гарантированная доставка сообщений, балансировка нагрузки (ну, всё то что, приходит в голову при мысли о жутко универсальной шине) - это всё дэбус делает?
> Хоть для баш-скрипта и программы на эрланге. Тут приличных решений вообще мало, не в память же друг другу писать (особенно на баше).
А почему нет?? Есть же разделяемая память - специально для этого. Всяко быстрее чем сокетами гонять, небось. Некоторые процессы ею пользуются (ipcs -m). Надо стандартизованно и из баша - ну почему не создать систему поименования и не приделать библиотечку утилит, которые позволят разным приложениям обмениваться данными и сообщениями посредством стандартных механизмов юнипса. Утилиту для баша можно назвать dbus-send, например.
> Чтоб мой виджет для awesome мог дёргать демон, контролирующий раскладку клавиатуры, например. Реализация, опять же, там немного странная, но тут уж как смогли.
Демон при создании открывает очередь сообщений, в которую ему заинтересованные приложения отправляют команды в заранее оговоренном формате. Администратор может контролировать нагрузку на очередь сообщений и параметры этих очередей. Чо ещё надо? Ну может сокет открыть - какая разница.
> Сокеты, по идее, дают возможность сделать более общую штуку, которая работает и локально, и по сети. Только код инициализации меняй. Это всё, на самом деле, из косяков юникса вытекает, ведь изначально была неплохая концепция "всё есть файл", а тут появилась сеть, и всё перестало быть файлом. Вот в plan 9, кстати, пытались это решить, и вроде даже смогли, но он уже умер по другим причинам.
А чо там с ним?