Re:[tech brain][технота]

Решил.

if(shmt){

char t;

strncpy(&t,ctime(&fs.st_mtime), strlen(ctime(&fs.st_mtime))-1);

printf("%s ", &t);

}

Re:[tech brain][технота]

>Выводит дату последнего изменения файла и на следующей строке имя файла. Нужен вывод даты и имени файла в одной строке. Как бы это реализовать? Не соображаю пока.

Re:[tech brain][технота]

> Да все читают трекер, имхо.

Угу, я тоже по крайней мере.

Re:[tech brain][технота]

Хм, а кстати, а как в этов вашем линупсе вывести дату в текущей локали?

А то date это умеет делать, а сишные функции как будто бы нет:

$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
$ gcc -o time_test time_test.c 
$ ./time_test
ctime output = Sun Nov 18 20:57:08 2012

strftime output=Sun Nov 18 20:57:08 2012

$ date
Вс. нояб. 18 20:57:19 GMT 2012

Re:[tech brain][технота]

A C program inherits its locale environment variables when it starts up. This happens automatically. However, these variables do not automatically control the locale used by the library functions, because ISO C says that all programs start by default in the standard ‘C’ locale. To use the locales specified by the environment, you must call setlocale. Call it as follows:

     setlocale (LC_ALL, "");

to select a locale based on the user choice of the appropriate environment variables. 

Re:[tech brain][технота]

Перенёс в development, вот.

Re:[tech brain][технота]

> ISO C says that all programs start by default in the standard ‘C’ locale. To use the locales specified by the environment, you must call setlocale.

Бля, зачем они так делают!? Умолчания должны соответствовать как раз настройкам среды, а если прога хочет чего-то особенного - вот пусть и выставляет чо ей надо. Вобщем безобразие сплошное это ваше ИСО, вот что я вам скажу!

Re:[tech brain][технота]

>Бля, зачем они так делают!?
Хороший вопрос. Может быть ради производительности, так как включение определённой локали требует, как минимум проверки её на валидность (мало ли что там юзер в ENV вогнал), да и вообще каких-либо условно затратных действий. А Си - это вам не <любой_другой_язык>, тут за каждый бит бьются насмерть.

А может для обратной совместимости, ведь в дремучие года локалей наверняка не было.

P.S. исходники libc не смотрел, как оно реально работает - не знаю.

Re:[tech brain][технота]

Я думаю что второе.. Всё-таки Линусу надо было копировать НТ-шное ведро

Re:[tech brain][технота]

>Я думаю что второе..
А мне, почему-то, первый вариант кажется более реалистичным. Пилит кто-то свой суперсофт под слабое оборудование, такты вручную на калькуляторе заранее высчитывает, оптимизирует каждую строчку, пишет ассемблерные вставки - а тут ему при инициализации какие-то переменные с локалями меняются. Тогда уже пилить два стандарта - для тех, кто волнуется из-за локали, и для тех, кому пофигу и даже не нужно. Но это некрасиво, тогда уж можно просто написать "уточните у вашего автора libc дефолтную локаль". Но тогда это уже не стандарт, а хрень.

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

Вот в каком-нибудь C++ уже должно быть пофиг - там оверхед на классы и прочую мутотень должен перекрывать любые затраты на локаль.

>Всё-таки Линусу надо было копировать НТ-шное ведро
Надо было Plan 9 развивать, а не возиться с НТ или протухшим, как старый грязный труп, юниксом.

Re:[tech brain][технота]

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

Во-первых зачем они ему? Проще передавать данные в двоичном виде. А если ты показывать их пользователю собрался - то логично их показывать в том виде, как пользователь постановил. Обрати внимание, эти функции уважают таймзону, а настройки локали почему-то нет. Если бы это было упрощение ради экономии ресурсов - то какая нахрен зона, это куда более сложная и дорогостоящая херня - учитывать локальные особенности времени с 1го января 1970г чтобы избежать ошибок - там же не просто цифру отформатировать надо, придётся пройтись по всей истории из базы tz_data чтобы посмотреть когда какой царёк в данной зоне отменял переход на зимнее время, а когда другой царёк его восстановил, плюс периодические поправки времени, плюс любые другие возможные вмешательства и реформы - надо думать это всё куда дороже и сложнее, чем просто форматированный вывод даты по настройкам окружения.

Плюс огромное количество просто говна. Ты обратил внимание на вызов localtime() в моём примере? Нахуй он нужен если time_t однозначно представляет момент времени, а вызова strftime, который принимал бы time_t в качестве параметра не существует? Зачем вынуждать меня делать это преобразование, чреватое утечками памяти, между прочим. Ога, мне результат localtime() нужен только в одном месте и поэтому я его вызвал таким образом. А он что сделал? Распределил в памяти структуру tm, которая нигде не удаляется потому что мне лень писать три строчки вместо одной - присвоить результат вызова localtime() переменной, потом вызвать strftime(), потом освободить память, на которую указывает эта переменная (при этом сама переменная скорее всего останется висеть на стеке до конца функции - байты экономим, да?). Зачем всё это делать, если у нас есть универсальное представление времени time_t? Зачем вводить ещё одно, если оно используется лишь однократно, при вводе или выводе значения этой даты?

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

А чего стоит pthread.h например. Сколько там вызовов? 50? 70? Нахуй они нужны?? Всё, что мы хотим от потока - это стартануть его, ну плюс ещё, что намного реже, узнать в каком состоянии он находится в данный момент, или изменить его состояние - приоритет, потлитику его диспетчеризации или просто его прибить нафиг. Нормально написанной программе не приходится насильно прибивать потоки или пытаться понять что там с ними не так - всё равно она с ними взаимодействует. Ну ладно, иногда это нужно, хер с ним. Но вот нахер нам, например, надо какое-нибудь pthread_(set|get)specific()??? Что, нельзя просто локальную переменную определить для потокоспецифичных байтов?? Я уж не говорю о том, как часто встречается словосочетание "undefined behaviour" в документации к этому АПИ. Хорошее же бля _системное_ АПИ, если у него "undefined behaviour" на каждом шагу.

А разделяемые ресурсы? Есть же разделяемая память, очереди сообщений - нахуя спрашивается, людям приходится громоздить всякие пайпы, сокеты и дбусы чтобы просто позволить двум приложениям обменяться теми же сообщениями? Ты можешь это объяснить?

Re:[tech brain][технота]

>но каждый раз, как приходится взглянуть на потроха этой юниксовой рухляди - каждый раз такое ощущение, как будто это куча отбросов каких-то, плотно утрамбованных в одно большое ведро.
"Not only is UNIX dead, it's starting to smell really bad." (c) Роб Пайк.

>Проще передавать данные в двоичном виде. А если ты показывать их пользователю собрался - то логично их показывать в том виде, как пользователь постановил.
Ещё немного - и получится аналог рассуждений Поттеринга. Сейчас меня заплюют, но он, в общем-то, во многом прав, только качество реализации у него очень страдает, и гигантомания слишком развита.

>Если бы это было упрощение ради экономии ресурсов - то какая нахрен зона, это куда более сложная и дорогостоящая херня - учитывать локальные особенности времени с 1го января 1970г чтобы избежать ошибок - там же не просто цифру отформатировать надо, придётся пройтись по всей истории из базы tz_data чтобы посмотреть когда какой царёк в данной зоне отменял переход на зимнее время, а когда другой царёк его восстановил, плюс периодические поправки времени, плюс любые другие возможные вмешательства и реформы - надо думать это всё куда дороже и сложнее, чем просто форматированный вывод даты по настройкам окружения.
Тут как - если посмотреть в прошлое, когда компьютеры развивались в англоязычных странах и/или теми, кто знает английский как родной, вопрос локали был не особо существенен. Учёным да программистам локаль почти не нужна, а "обычный" пользователь в те времена встречался редко. А вот таймзона была важна с самого начала. Потому расходы на неё были более обязательны, чтоли. Сейчас, конечно, всё не так.

>Ты обратил внимание на вызов localtime() в моём примере?
>А зачем там несколько функций, преобразующих дату в строку в неправильном формате? Тем более, что одна из них, как в насмешку ещё и \n принудительно вставляет в вывод?
Видимо, ИСО-шники просто закрепили то, что было раньше. А уж почему раньше так сделали - сложно сказать. С \n вообще весело, я был поражен, раньше не знал о таком. Приёмы прокетирования, видимо, были другие, а уж вывод только в терминал считался чем-то общепринятым. Оттого и поставили тогда, а теперь ломать поздно.

Вообще Си, имхо, сборник костылей by design (плюйте, плюйте!), так как выразительность языка променяли на производительность. Впрочем, я даже не знаю, можно ли было сделать иначе.

>Но вот нахер нам, например, надо какое-нибудь pthread_(set|get)specific()??? Что, нельзя просто локальную переменную определить для потокоспецифичных байтов??
Думаю, это было бы сложно сделать.

>А разделяемые ресурсы? Есть же разделяемая память, очереди сообщений - нахуя спрашивается, людям приходится громоздить всякие пайпы, сокеты и дбусы чтобы просто позволить двум приложениям обменяться теми же сообщениями? Ты можешь это объяснить?
Всё объяснить не могу:) Но у дбуса, например, немного другая задача - он должен быть жутко универсальным, типа шины обмена данных для всех, кому захочется, и чтоб формат был относительно унифицирован. Хоть для баш-скрипта и программы на эрланге. Тут приличных решений вообще мало, не в память же друг другу писать (особенно на баше). Чтоб мой виджет для 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, кстати, пытались это решить, и вроде даже смогли, но он уже умер по другим причинам.

А чо там с ним?

Re:[tech brain][технота]

>Но клонировать это в 90х уже как-то неправильно было, нехорошо Линус поступил.
Ему нельзя было писать своё с нуля, потому что оно было бы никому не нужно. Либо ты делаешь что-то POSIX-образное, либо у тебя маргинальная поделка, которая никому не интересна. А так оно выскочило, так как свободное/бесплатное юникс-образное, людям было относительно привычно и понятно всё, что там можно сделать. Ну или можно было другую популярную систему выбрать, но я сходу ничего из начала 90-х не вспомню. Не венду же клонировать, которая тогда на досе держалась.

>Терминал не терминал, но есть системный подход к разработке, а есть бессистемный: на выходе у первого подхода получается система, а у второго - груда разноцветных костылей разного размера. И если продуманную систему можно _понять_, то в груде костылей запомнить каждый баг невозможно, поэтому под ту же венду программировать проще.
Ну не скажи, вполне себе система получилась. Местами не очень - так и winapi тоже не идеальный. Насчёт того, где проще программировать - это уж кому как. По мне так под ляпих намного веселее и удобнее. Я, правда, в дебри системных вызовов не лезу, специфика работы такая.

>Не, сам-то Си - нормальный язык, оптимальный я бы сказал.
Кому как. Мне, например, не нравится невозможность возвращать из функции несколько значений сразу. Хочешь что-то сделать - а функция тебе только код ошибки даёт, а переменную под результат надо передавать в неё саму, и она там её будет менять. А функция, меняющая свои аргументы, имхо, некрасива и неудобна, побочные эффекты, все дела. И ещё куча всего, что мне лень перечислять.

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

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

Кто виноват, что люди даже хелловорлд на классах делают? Люди же. Если запрещать в языке все конструкции во избежание людской глупости, то будет сложно реализовывать специфические вещи. Впрочем, Си и без наворотов даёт прекрасную возможность стрелять себе в ноги, одного ручного выделения памяти достаточно:)

>Конечно можно было бы. Сделать новую библиотеку с учётом накопленного за последние 20-30 лет опыта взломов юникс-систем, а старую задепрекатить.
В ИСО просто сидят ретрограды и консерваторы. А если они таки сделают новую, то их заплюют ретрограды-пользователи.

>А что мы видим в реализации тредов в линупсе? Куча каких-то функций, которые нахрен не нужны и/или не имеют отношения к собственно к задаче создания треда, и список которых не помещается в экран.
А что мешает их не использовать, если они не нужны?:)

>Поддержка транзакций, бродкастинг в сети, гарантированная доставка сообщений, балансировка нагрузки (ну, всё то что, приходит в голову при мысли о жутко универсальной шине) - это всё дэбус делает?
Я же говорю, реализация хромает. Но ничего, кроме дбуса, пока не изобрели. А если изобрели, то в массы не пошло, по каким-то причинам. Думаешь, они жуют кактус добровольно?

Хотя да, есть ещё zeromq и rabbitmq, но почему не они - не знаю.

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

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

Кстати, в дбусе приложения могут (или смогут когда-нибудь) напрямую гонять друг другу данные, что написано вот тут.

Впрочем, дбус не заменяет очереди, он просто более высокоуровневый.

>А чо там с ним?
А ничего. Умер. Кто-то что-то пилит ради интереса, но ничего глобального не планируется. Собственно, это уже не проблема системы или архитектуры, это проблема текущей ситуации вообще.

Сейчас у нас есть миллиарды компьютеров на планете, огромное количество хардвара, куча серверов, отработанные годами схемы работы и так далее. Тут нет смысла завязывать свои дела на новой и перспективной ОС, даже если она будет, допустим, на 20% выгоднее в денежном плане (за счёт экономии сил программистов, например). Просто потому, что слишком много побочных эффектов вылезет.

Например, есть какой-нибудь драйвер для вайфая, его может и написали за один месяц, зато потом отлаживали годами внутри ляпихового ядра. Наделали кучу хаков, ведь и ОС, и хардвар, не идеальны, и без хаков никуда. А теперь у нас новая хорошая, но малоизвестная ОС, и процесс надо начинать с нуля, заодно переучиваясь на новые технологии. Кто на такое пойдёт? Можно налепить слой совместимости, да, но тогда либо придётся мириться с тем, что не все хаки заработают, либо перенести все хаки и получить ещё один ляпих, только с другим названием. И такое не только с драйверами, но и с программами, и даже программистами. Весь комплекс разработки стал настолько крупным и раздутым, что перенести его на другую систему уже совсем непросто.

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

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

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

Re:[tech brain][технота]

> Ну или можно было другую популярную систему выбрать, но я сходу ничего из начала 90-х не вспомню
Полуось (OS/2), BeOS.

Re:[tech brain][технота]

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

Вообще да, WinNT к тому времени не было ещё пожалуй.

> Ну не скажи, вполне себе система получилась. Местами не очень - так и winapi тоже не идеальный.

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

При том речь не идёт о кернеле - ну что, он худо-бедно обеспечивает основные функции, которые нужны системе - доступ к ресурсам, то же IPC, привилегии доступа (хотя судя по существованию селинкса и аппармора - последнее кернел делает из рук вон плохо). Получается что мы говорим о системном АПИ. При этом винапи объективно лучше. Но у линукса же есть винапи! Что такое вайн как не винапи к ядру линупса? Под ним вон, говорят, даже программы лучше работают - типа того же фаерфокса. Мне кажется что Линусу вместо того, чтобы прыгать по блогам и критиковать разработчиков ДЕ было бы лучше подраскритиковать POSIX-API и призвать разработчиков переходить на вайн как АПИ, а со своей стороны налечь на реализацию недоделанного в вайне функционала и лучшую его поддержку со стороны ядра. Это хотя бы будет поближе к сфере его еомпетенции, чем до DE докапыватьсяю

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

Да нигде в Линупсе не легче, по разным причинам. Есть например куча разрозненных переменных окружения, но даже единого _реестра_ для этих настроечных опций нет!

> Кому как. Мне, например, не нравится невозможность возвращать из функции несколько значений сразу.

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

> Ну да, не позволяет. Вот только код на ООП-языке для создания виджета на гтк будет в пару раз короче, чем аналогичный на Си. Причем на Си он ещё будет какой-то дико замудрёный и неочевидный. Потому что без ООП гуёвые тулкиты делать сложно, а гтк-фанатики боялись себе признаться, что им нужен другой язык. Там такие монстры в коде, что страшно становится от одного вида.

Вот на Дельфи такой код смотрится естественно и даже эротично. А эти тупые фанатики шарахаются от Лазаруса.

> Кто виноват, что люди даже хелловорлд на классах делают? Люди же. Если запрещать в языке все конструкции во избежание людской глупости, то будет сложно реализовывать специфические вещи.

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

> Впрочем, Си и без наворотов даёт прекрасную возможность стрелять себе в ноги, одного ручного выделения памяти достаточно:)

Си ему в этом не уступает.. Хотя было дело переопредял я когда-то оператор new в плюсах.

> В ИСО просто сидят ретрограды и консерваторы. А если они таки сделают новую, то их заплюют ретрограды-пользователи.

Кто мешает сделать альтернативную и её развивать. А потом ИСО как-нибудь подстроится.

> А что мешает их не использовать, если они не нужны?:)

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

> Хотя да, есть ещё zeromq и rabbitmq, но почему не они - не знаю.

Да они и не планировали в дбусе делать поддержку сети. Вообще. ЕМНИП, речь шла о том, что "в будущем возможно появятся плагины сторонних разработчиков для передачи мессажей по сети".

> А потом ты добавишь в неё что-то ещё, затем описание интерфейсов для автогенерации в xml, и вот - у нас есть дбус.

Ну тоже верно. В конце концов это не ядерная вещь, а так - типа пользовательской библиотеки. Но почему приложения под этим вашим линупсом почти не пользуются разделяемой памятью и совсем не пользуются очередями сообщений?

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

Несколько разных приложений могут накласть демону в очередь. Кто мешает нескольким демонам читать из этой одной очереди (для масштабируемости например).

> Например, центральный демон может разбираться с пространствами имён, которые надо делать для разных пользователей. А как без них на десктопе?

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

> Кстати, в дбусе приложения могут (или смогут когда-нибудь) напрямую гонять друг другу данные, что написано вот тут.

Поржал. Сперва перевёл фразу:
> "I worked on having D-Bus directly in the Linux kernel to improve its performances."
как "я работал над внедрением D-Bus в ядро чтобы улучшить производительность ядра"

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

А зачем в ядре высокоуровневые вещи? Почему они туда лезут понятно, но они там не нужны же.

>> А чо там с ним?
> А ничего. Умер. Кто-то что-то пилит ради интереса, но ничего глобального не планируется. Собственно, это уже не проблема системы или архитектуры, это проблема текущей ситуации вообще.

Ну как умер? Он заслуженно стал неинтересен поскольку не мог предложить ничего принципиально нового или просто лицензия неудачная попалась?

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

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

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

Линупс вон вылез, хотя никто не нуждался в ещё одном юнипсе.

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

Вообще на мобилки любое говно сойдёт, там пока не особо нужны эти линупсовые плюшки типа управления cpuset'ами и поддержки ccNUMA-памяти :)

> Вот 30 лет назад всё было проще, компьютеров было мало, хардвара тоже. Достаточно было придумать что-то удачное, вложить некие силы и средства - и у нас новый участник игры.

Минуточку. Я например сторонник взгляда, что хорошие вещи делаются Just For Fun, а за бабло сделают на отъебись, при том чем больше заказчик платит - тем хуже получится (по двум причинам: на большие бабки слетаются любители бабок, усердно отталкивая от кормушки любителей делать хорошие системы. А с другой стороны за деньги часто делают не как надо, а как насяльника хосет) т.е. я не вижу связи с рынком. Более простое, логичное и совершенное решение чем линупс сейчас имеет все шансы. Народ вон уже к Беосу Haiku даже начинает проявлять интерес - правда скорее всего от того, что хайкуфаги в последнее время повылазили из под могильных плит и страшно пеаратся в тёмных маргинальных уголках интернета.

Re:[tech brain][технота]

> Полуось (OS/2), BeOS.

Разработка последнего только начиналась, чо о ней мог знать Линус? Бери уж нетварь тогда, вроде её хвалили за устойчивость.

Re:[tech brain][технота]

охбле столько тролленга на разные темы в одном посте. мой жирнометр зашкалило

Re:[tech brain][технота]

> Это всё, на самом деле, из косяков юникса вытекает, ведь изначально была неплохая концепция "всё есть файл", а тут появилась сеть, и всё перестало быть файлом.
А разве ЮНИКС не изначально сетевым был? Предназначался-то для компов с множеством терминалов и пользователей(многозадачная и многопользовательская система, хуле), т.е. сеть была изначально.

Re:[tech brain][технота]

>Получается что мы говорим о системном АПИ. При этом винапи объективно лучше. Но у линукса же есть винапи! Что такое вайн как не винапи к ядру линупса? Под ним вон, говорят, даже программы лучше работают - типа того же фаерфокса.
>призвать разработчиков переходить на вайн как АПИ
Хорош толстеть.

Подписываюсь под словами Туксоида про жир.

>лучше подраскритиковать POSIX-API
По правде всем уже немного наплевать на POSIX. Собственно, что это такое? Набор вещей, которые должны быть в ОС. Но должны быть != только они будут. Юзерспейс у ляпиха вполне ничего, и ядро, пусть и не идеальное, вполне шустрое и приятное. Иначе бы им никто не пользовался. Ломать же существующий в ляпихе POSIX нельзя, так как есть те, кто на нём сидит.

>Есть например куча разрозненных переменных окружения, но даже единого _реестра_ для этих настроечных опций нет!
Там фридесктоп усилиями Поттеринга, кстати, приводит всё к единому знаменателю. Да так приводит, что крик стоит на весь интернет, и дальше вырывается.

>К тому же передавать большие объекты по значению - сам понимаешь чем это чирьевато для производительности
Так можно указатель возвращать. Тем более я не предлагаю везде прям взять и заменить текущее на новое. Но возможность такая была бы неплоха.

>и в любом случае аллоцировать их внутри функции и возвращать вызывающему коду - это просто неприлично. От этого делаются лейки.
Лейки делаются потому, что кто-то забывает память освобождать. А про то, что её нужно освобождать, написано в документации. Да и так можно догадаться, в общем-то. Вот strdup сам выделяет, и ничего, никто пока не умер. Забывчивый программист может и про самолично устроенный malloc забыть.

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

>Вот на Дельфи такой код смотрится естественно и даже эротично. А эти тупые фанатики шарахаются от Лазаруса.
Может они нашли что-то лучше?:)

>Но вот есть же джава на которой могут пейсать даже индусы и код которой можно нормально читать в большинстве случаев, даже дебайткодированный.
Это преимущество?

То-то куча народу, как только доберётся до серьёзного проекта, начинает возиться со всякими scala, clojure и groovy. Чего ж им родной джавы-то не хватает?:)

>Кто мешает сделать альтернативную и её развивать. А потом ИСО как-нибудь подстроится.
Хороший вопрос.

>Да они и не планировали в дбусе делать поддержку сети. Вообще. ЕМНИП, речь шла о том, что "в будущем возможно появятся плагины сторонних разработчиков для передачи мессажей по сети".
Ещё впилят, я думаю. Учитывая тенденции - оно вполне возможно.

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

>Несколько разных приложений могут накласть демону в очередь. Кто мешает нескольким демонам читать из этой одной очереди (для масштабируемости например).
То есть давать разным демонам читать некую общую очередь? Да ещё и не удалять оттуда сообщения о прочтении, а оставлять для соседей, который прочитать не успели? Так тут как раз и нужен сервер, для контроля всего этого дела, и для удаления уже не нужных сообщений. А иначе демонам придётся ещё заморачиваться с очисткой общей очереди. Можно, если хочется, но выйдет страшно.

>Поржал. Сперва перевёл фразу:
Грешно смеяться над французами!

>А зачем в ядре высокоуровневые вещи? Почему они туда лезут понятно, но они там не нужны же.
Эээ, а где я говорил про ядро? Дбус, пока что, к ядру не относится, и я туда его засовывать не собираюсь. Да даже если бы собирался - не смог бы.

>Ну как умер? Он заслуженно стал неинтересен поскольку не мог предложить ничего принципиально нового или просто лицензия неудачная попалась?
Он остался интересен. Пожалуйте туда. Вот только сообщество мелкое, и реально втыкать его куда-то для серьёзной работы никто не планирует. А основные разработчики из Bell Labs свалили в гуголь, заодно придумав по пути язык Go.

>А что, линупсовые драйвера принципиально нельзя использовать? Это какое-то архитектурное ограничение у плана? Или таки можно было прорисовать им слой абстракции - и юзать пока нативные не пойдут?
Я ниже в исходном тексте предположил, что слой абстракции будет слишком толстым, и план станет ещё одним ляпихом.

>Линупс вон вылез, хотя никто не нуждался в ещё одном юнипсе.
Когда он вылез - нуждался. Его серьёзная популярность начала проявляться в конце 90-х, когда классические юникс-вендоры совсем перестали заниматься чем-то полезным. Один Sun с соляркой что-то развивал, остальные упёрлись в ынтерпрайз и гребли кучу денег на маленьком рынке. В сегменте мелких серверов и десктопов юниксов не было, была только венда, которая для десктопа может и годится, а для сервера уже не очень. Ну и нетварь была ещё, но она как-то сама сдохла. Вот тут линукс и выстрелил, потом уже пойдя вверх.

>Вообще на мобилки любое говно сойдёт, там пока не особо нужны эти линупсовые плюшки типа управления cpuset'ами и поддержки ccNUMA-памяти :)
Современные мобильники скоро мой десктоп по производительности уделают. И по нагрузкам, учитывая джаву и всякие распознавания речи. Естественно, это не монстры из топ500, но всё же.

>Минуточку. Я например сторонник взгляда, что хорошие вещи делаются Just For Fun, а за бабло сделают на отъебись, при том чем больше заказчик платит - тем хуже получится (по двум причинам: на большие бабки слетаются любители бабок, усердно отталкивая от кормушки любителей делать хорошие системы. А с другой стороны за деньги часто делают не как надо, а как насяльника хосет) т.е. я не вижу связи с рынком.
Одно дело сделать вещь, другое - её раскрутить, образно говоря. Вон, упомянутая выше полуось была вполне ничего, и где она сейчас?:) For fun, или в исследовательских целях, можно сделать неплохую систему, но допиливать до той стадии, когда её можно будет воткнуть на критически-важный сервер на одном энтузиазме нельзя. Или пилить сотню дров для тьмы непонятных устройств. Сейчас мало кто пойдёт на новую систему, у которой "ничего нет", тут нужно что-то вроде решительного действия какого-нибудь гугла, который начнёт миграцию своих серверов на новую ОС. Но это экономически выгодно только, если новая ОС действительно в разы лучше предыдущей, а на предыдущей уже ничего сделать нельзя.

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

>Народ вон уже к Беосу Haiku даже начинает проявлять интерес - правда скорее всего от того, что хайкуфаги в последнее время повылазили из под могильных плит и страшно пеаратся в тёмных маргинальных уголках интернета.
Народ - это три с половиной маргинала от сообщества хардкорных линуксоводов, которое само по себе тоже три с половиной маргинала. Если смотреть на эти масштабы, то и plan 9 живой, и даже GNU Hurd стучит по своей надгробной плите снизу.

Re:[tech brain][технота]

>А разве ЮНИКС не изначально сетевым был? Предназначался-то для компов с множеством терминалов и пользователей(многозадачная и многопользовательская система, хуле), т.е. сеть была изначально.
Сеть-то была, однако с ней, как с файлом, уже нельзя было работать. Нужны были сокеты и прочее, они похожи на файлы, но не файлы:) Многопользовательскость (ну и слово) - это, всё же, немного не то.

А в plan 9 можно работать с сетевыми адресами как с файлами. Например, можно примонтировать IMAP: /imaps/imap.gmail.com/[email protected]. Или чужую мышку, если права позволяют. Или вебсайт.

Re:[tech brain][технота]

> А разве ЮНИКС не изначально сетевым был?

Если под сетью понимать соединение вычислительных машин друг с другом - то нет, наверное.

> Предназначался-то для компов с множеством терминалов и пользователей(многозадачная и многопользовательская система, хуле), т.е. сеть была изначально.

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

Re:[tech brain][технота]

> Хорош толстеть.
> Подписываюсь под словами Туксоида про жир.

Какой жир?? Более совершенное и более эффективное АПИ. Зачем пользоваться худшим, когда можно пользоваться тем, что лучше. Со временем портировать вайн под соляку, чпукс и эйайкс - и все ОС получат унифицированное АПИ. Все же только выиграют от этого.

> По правде всем уже немного наплевать на POSIX.

Ага, вот видишь, а ты под тюксоидным жыром уже подписался. Поспешил!

> Собственно, что это такое? Набор вещей, которые должны быть в ОС. Но должны быть != только они будут.

Если стащить весь хлам в одну кучу - стройной системы не получится. Получится неподъёмная куча хлама. Неужели непонятно, что нагромождение компонентов без всякой на то шужды усложняет систему, тянет её назад и не позволяет ей развиваться?

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

Срать всем на шустрость. Линупс работает на дешёвых х86, дешевле в поддержке, есть несколько конкурирующих между собой поставщиков линупса.

> Ломать же существующий в ляпихе POSIX нельзя, так как есть те, кто на нём сидит.

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

> Там фридесктоп усилиями Поттеринга, кстати, приводит всё к единому знаменателю. Да так приводит, что крик стоит на весь интернет, и дальше вырывается.

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

> Так можно указатель возвращать.

Некоторые функции так и делают, см. ниже чем это плохо.

> Лейки делаются потому, что кто-то забывает память освобождать. > А про то, что её нужно освобождать, написано в документации. Да и так можно догадаться, в общем-то. Вот strdup сам выделяет, и ничего, никто пока не умер. Забывчивый программист может и про самолично устроенный malloc забыть.

Ну да. Я кран включил - я его и выключу. Память должна освобождаться на том уровне, где выделялась. Код выделения памяти - как флажок: где-то рядом она должна освободиться обратно. Код ведь пишется не один раз, его потом умпрувить разные программисты будут годами. Очень легко не заметить что где-то там выше по коду память распределилась неявным образом, а теперь ты ещё случайно код её очистки ветвлением отгородил, например. Что особенно приятно если освобождение памяти будет опускаться в каких-то редких трудновоспроизводимых условиях малыми порциями. Пойди заметь, пока оно в продакшене с помпезностью не наебнётся, попутно вызвав миллионные потери прибыли.

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

А кто тебе мешает писать на этерпрайзных языках с уборкой мусора? Это другой уровень просто.

> Может они нашли что-то лучше?:)

И теперь скрывают?

>Но вот есть же джава на которой могут пейсать даже индусы и код которой можно нормально читать в большинстве случаев, даже дебайткодированный.
> Это преимущество?

Нет. Это не преимущество. Это - Очень Большое Преимущество.

> То-то куча народу, как только доберётся до серьёзного проекта, начинает возиться со всякими scala, clojure и groovy. Чего ж им родной джавы-то не хватает?:)

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

> Ещё впилят, я думаю. Учитывая тенденции - оно вполне возможно.

Может и впилят. Задача любого карьериста - застолбить за собой как можно большее поле. А потом уже пусть начальство выделяет тебе подчинённых чтобы переделать это всё по уму. Как только красношляп надумает это пихать в энтерпрайз - а оно в планах уже вроде есть, то ему придётся что-то сделать с этим гарри поттером, чтобы он все свои плюшки сделал управляемыми - чтобы их можно было мониторить, лимитировать, права там раздавать. И чтобы по мессажам в логах от этого евоного дэбуса можно было понять что вообще там с этим дэбусом в системе происходит, а при наличии проблем - установить их причину.

> С чего ты взял?

Я это взял из вывода команды ipcs с ключиком -p. Да, у меня есть несколько стандартных кедэшных прог, которые разделяемой памятью пользуются. И всё. Очередями сообщений вообще не пользуется никто. ни один процесс.

> Я на многих форумах видел кучу вопросов по этим делам.

На форуме - возможно, но не в реальной системе.

> Там, где надо гонять много данных, народ использует это. Ну а для простого десктопного софта проще взять дбус, так как толку от других механизмов будет не больше, а времени потратят много.

Так и без дэбуса не пользовались. Хотя наверняка библиотек дохрена существует для упрощения жизни. Но в мейнстрим чот не идёт.

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

> То есть давать разным демонам читать некую общую очередь?

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

> Да ещё и не удалять оттуда сообщения о прочтении, а оставлять для соседей, который прочитать не успели?

А соседей-то зачем грузить сообщениями, которые ты уже отработал?

> Так тут как раз и нужен сервер, для контроля всего этого дела, и для удаления уже не нужных сообщений. А иначе демонам придётся ещё заморачиваться с очисткой общей очереди. Можно, если хочется, но выйдет страшно.

Когда нужно чего-то сложного - так и делают. Диспетчера можно поставить, например, который будет роутить сообщения, и, возможно. подключать новые процессы, если старые сдохли (что юнипсах, к сожалению, случается чаще чем в виндовсах просто потому, что там АПИ замуженное и разработчики вечно что-то накосячат) или просто не справляются.

> Эээ, а где я говорил про ядро? Дбус, пока что, к ядру не относится, и я туда его засовывать не собираюсь. Да даже если бы собирался - не смог бы.

Дак ты сам писал, что завёлся такой маньяк. А с другой стороны - почему бы и не вставить? Только почему именно дбус..

> Он остался интересен. Пожалуйте туда. Вот только сообщество мелкое, и реально втыкать его куда-то для серьёзной работы никто не планирует.

Пусть с драйверами сперва придумают чо. Хотя обращаться к почте и локальным устройствам с помощью длинных УРЛов ме как-то вообще влом.

> Я ниже в исходном тексте предположил, что слой абстракции будет слишком толстым, и план станет ещё одним ляпихом.

Ну это да, нужно будет эмулировать то самое АПИ, которое не должно быть постоянным

> Когда он вылез - нуждался. Его серьёзная популярность начала проявляться в конце 90-х, когда классические юникс-вендоры совсем перестали заниматься чем-то полезным. Один Sun с соляркой что-то развивал, остальные упёрлись в ынтерпрайз и гребли кучу денег на маленьком рынке. В сегменте мелких серверов и десктопов юниксов не было, была только венда, которая для десктопа может и годится, а для сервера уже не очень. Ну и нетварь была ещё, но она как-то сама сдохла. Вот тут линукс и выстрелил, потом уже пойдя вверх.

На десктопе он и по сей день без надобности, а для мелких серверов фряха была, в конце девяностых линупс вообще серьёзно ещё не рассматривали

> Одно дело сделать вещь, другое - её раскрутить, образно говоря. Вон, упомянутая выше полуось была вполне ничего, и где она сейчас?:)

Ну так опять же бабло, тем более что там микрософт баблом поучаствовал. А потом ради ещё большего бабла на себя одеяло перетянул. Все беды от бабла.

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

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

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

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

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

Облака то там при чём?

> Народ - это три с половиной маргинала от сообщества хардкорных линуксоводов, которое само по себе тоже три с половиной маргинала. Если смотреть на эти масштабы, то и plan 9 живой, и даже GNU Hurd стучит по своей надгробной плите снизу.

Ну так они популяризировать пытаются свою систему, вот к ним и тянутся. Несмотря на то, что никто не в курсе чем это Хайку принципиально лучше линупса.

Re:[tech brain][технота]

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

Re:[tech brain][технота]

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


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

Re:[tech brain][технота]

А ARPANET? Он как раз во времена ЮНИКСВ начал создаваться и на них потом и существовал.

Re:[tech brain][технота]

По ВиКи: "In 1983, TCP/IP protocols replaced NCP as the ARPANET's principal protocol, and the ARPANET then became one subnet of the early Internet".

TCP/IP в той древности не было. Правда модемов никто не отменял, но модемы использовали как "удинители" для тех же терминалов. Самое продвинутое средство взаимодействия между компьютерами был UUCP - протокол пераццкого копирования файлов по тем же терминальным линиям, если ими соединить два компа. Только он появился уже после юнипса.

Re:[tech brain][технота]

>Какой жир?? Более совершенное и более эффективное АПИ. Зачем пользоваться худшим, когда можно пользоваться тем, что лучше.
Давай уж пруфы, раз так. А то странно, почему-то почти все серверные программы серьёзные люди под unix-like запускают, а система с лучшим API стоит в сторонке.

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

>Получится неподъёмная куча хлама. Неужели непонятно, что нагромождение компонентов без всякой на то шужды усложняет систему, тянет её назад и не позволяет ей развиваться?
Это не всегда применимо к программным продуктам. Проблемы ядра ляпиха сейчас лежат в области драйверов, всяких там видеокарт и дисковых подсистем. Тут дряхлый POSIX уже никаким боком не влияет.

Алсо, stable_api_nonsense.txt как раз и отвечает на все эти вопросы. Нужно ради развития поломать - поломаем. Как раз так, как ты хочешь. Причем ломают, в основном, внутриядерное API, а внешне ядро уже давно стабильно.

>Линупс работает на дешёвых х86
А ничего, что кроме x86 почти никого не осталось? Даже в топ500. Это в 2000-м году можно было говорить, что x86 ставят нищие неудачники, а ынтерпрайз сидит на спарках с поверами. А теперь вот хрен, кончилось их время, да здравствует массовое производство дешевого ширпотреба. И это, кстати, не так плохо.

>Хорошо, можно для совместимости, на какое-то время пока это наследие прошлого века окончательно отомрёт, оставить где-нибудь в легаси-репозитарии пакет совмести с позиксом
ИМХО, любой слой совместимости будет либо неполным (прям как вайн), либо будет превращать систему в клон предыдущей (а зачем тогда новая система?).

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

>Ну да. Я кран включил - я его и выключу.
Так вызывая функцию ты тоже включаешь кран, просто другой командой. Впрочем, ладно, твои аргументы тоже убедительны, так что всё выливается в вопрос вкуса.

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

>Нет. Это не преимущество. Это - Очень Большое Преимущество.
Сложность чтения кода вообще мало зависит от языка. Человек, который умеет более-менее средне писать программы, прочитает любую программу, если поймёт алгоритм работы кода, структуру программы и прочее. А алгоритмы и структуры определяются не языком, а фреймворком, в рамках которого пишется код. То есть даже на джаве, если дать большой простор для творчества конкретному индусу, получится хрень, которую без поллитра не осилить. Вроде бы буквы те же, а как оно работает - даже с дебаггером не ясно. Что-то кто-то откуда-то вызывает и куда-то передаёт, и нагромождения друг на друге.

И наоборот, на каком-нибудь лиспе, если писать в рамках проработанной архитектуры (или фреймворка, что одно и то же в данном случае), любой программист поймёт смысл довольно быстро. Если он знаком с этим самым фреймворком.

А вот выразительные возможности языка, наличие лямбд и прочих замыканий, сложность понимания правильно спроектированного кода совершенно не повышает, если даже не наоборот. Плюс джавы тут только в том, что у неё есть масса популярных фреймворков, в рамках которых работают индусы. И язык тут никаким боком. С тем же успехом программы на C++/Qt довольно понятны, если разбираешься в Qt и знаешь приёмы работы с ним. Хотя сам язык позволяет делать и нечитабельные вещи.

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

>Что-то я никакой скалы не наблюдаю в окрестностях, видимо у нас проекты несерьёзные.
Видимо:)

>Как только красношляп надумает это пихать в энтерпрайз оно - а в планах уже вроде есть, то ему придётся что-то сделать с этим гарри поттером, чтобы он все свои плюшки сделал управляемыми - чтобы их можно было мониторить, лимитировать, права там раздавать.
Да уже, вроде как. Редхат чётко хочет видеть в rhel и системд, и дбус. Вопрос только в сроках. Как раз к следующему стабильному релизу оттестируют. И Поттеринг делает всё в соответствии с планами. Другое дело, что можно было бы сделать тот же системд более модульным, и было бы в разы лучше, но для rhel это не важно, потому и не пилится.

>Так и без дэбуса не пользовались. Хотя наверняка библиотек дохрена существует для упрощения жизни. Но в мейнстрим чот не идёт.
Видимо, никакая библиотека не давала нужных результатов, и всё равно приходилось изобретать дбус. Раньше вот CORBA вообще была, хехе.

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

>Почему разным? Одинаковым. Не справляется один демон с нагрузкой - запускаешь второй экземпляр, он цепляется к той же очереди и тоже обрабатывает сообщения, например.
>А соседей-то зачем грузить сообщениями, которые ты уже отработал?
Не, вот есть у меня штука, которая при переключении раскладки выдаёт сигнал, мол, так и так, у нас тут новая раскладка. А слушать её может кто угодно. Тут без внешнего диспетчера не обойтись, который будет раздавать сообщение всем слушателям, которым интересно узнать про раскладку. И учёт их вести.

Можно, конечно, каждому слушателю цепляться к нашей штуке, и она будет им каждому слать отдельное, личное сообщение, причем одинаковое для всех. Но это как-то не очень красиво, если у тебя слушателей 10, а штука одна, причем ещё экономящая ресурсы. Это надо 10 соединений неких держать. А ведь слушатели могут ещё с кем-то соединения держать. В общем, выгоднее всем цепляться к одному серверу и использовать одно соединение на рыло, а уж пусть сервер там в это соединение все event-ы засовывает.

>Дак ты сам писал, что завёлся такой маньяк. А с другой стороны - почему бы и не вставить? Только почему именно дбус..
Видимо, в головы разработчиков ничего умнее не приходит. Может они и правы, и дбус есть шедевр софтостроения?:)

>Хотя обращаться к почте и локальным устройствам с помощью длинных УРЛов ме как-то вообще влом.
Так не ты будешь, а софт. Зато софту надо только файлы читать уметь - сразу уменьшение лишних сущностей в разы.

>На десктопе он и по сей день без надобности, а для мелких серверов фряха была, в конце девяностых линупс вообще серьёзно ещё не рассматривали
Начинали рассматривать. И где сейчас фряха?

>Если система будет хороша для энтерпрайза - то для неё найдётся место.
Учитывая, что энтерпрайз сейчас стал жутко жирным, тут никакая система не даст решительных преимуществ. Например, упадёт время простоя с 10% до 5%. Вроде бы и профит, а не факт, что оно окупит затраты на переход. Чем толще ынтерпрайз - тем меньше разница, так как в самом ынтерпрайзном софте уже столько накручено проблем, что ОС тут побоку.

Толк был бы, если бы очень глючную кривую систему меняли на идеально стабильную. Но так в жизни редко бывает, так как глючит всё, особенно новые ОС. А старые, набитые костылями, уже вроде бы и не глючат.

>Облака то там при чём?
Облака и прочий сетевой компутинг - модная и прогрессивная тема. Но вместо написания специальной облачной сетевой системы (похожей на план9, кстати), сейчас предпочитают накручивать юзерспейсные костыли на несетевой юникс. И ничего, выходит, работает и продаётся. И пока они там не упрутся во что-то радикально непреодолимое, никто про новую ОС не вспомнит.

Re:[tech brain][технота]

А на чём ARPANET строили? На Юниксах и VMS. В 1983 ЮНИКС был её молодой, развивающейся системой, современные стандарты на него стали формироваться несколько позже.

Re:[tech brain][технота]

>>> Но вот нахер нам, например, надо какое-нибудь pthread_(set|get)specific()??? Что, нельзя просто локальную переменную определить для потокоспецифичных байтов??
>> Думаю, это было бы сложно сделать.
>Почему??

Вобщем непонятно зачем в библиотеку для работы с потоками понапихали весь этот склад костылей, совершенно неспецифичный для, собственно, потоков.