Проект GNU представил (http://savannah.gnu.org/forum/forum.php?forum_id=8146) выпуск простейшей утилиты GNU hello 2.10 (https://www.gnu.org/software/hello/), выводящей на экран надпись "Hello, world!" при запуске. Несмотря на кажущуюся бессмысленность выпуска отдельной программы для подобных целей, GNU hello представляет собой некий эталон оформления кода программ GNU, который демонстрирует методы использования Gettext для перевода сообщений на различные языки, показывает как обрабатывать аргументы командной строки и пользоваться сборочным инструментарием.
По сравнению с прошлым выпуском в версии 2.10 основной текст 'Hello, World' оформлен через файлы переводов, задействованы методы нерекурсивной сборки, представлен пример добавления секций в man-руководство, вместо fprintf (stderr) задействована libc-функций 'error()', добавлен вызов 'make
update-copyright', обеспечено формировние ChangeLog из лога коммитов в git.URL: http://savannah.gnu.org/forum/forum.php?forum_id=8146
Новость: http://www.opennet.me/opennews/art.shtml?num=41066
воу воу воу, отпусти меня чудо трава!
"версии 2.10" - нет, серьезно, что они там курят?
Яркий пример как из 2+2 сделать дырявую софтну.
lib/localcharset.c:239:23: warning: Potential leak of memory pointed to by 'old_res_ptr'
strcpy (res_ptr + res_size - (l2 + 1) - (l1 + 1), buf1);
^~~~~~
lib/localcharset.c:244:26: warning: Potential leak of memory pointed to by 'res_ptr'
cp = "";
^~
lib/xmalloc.c:86:3: warning: Potential memory leak
return memset (xmalloc (s), 0, s);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Яркий пример человека, разбирающегося в программировании чуть менее чем никак, которому в руки попал статический анализатор.
Специально не стал писать дополнение про статич. анализаторы, ждал дебилов. :D
А что Вас, собственно, удивляет? Вон до того, как true и false стали выводить по флагу --version текущую версию coreutils, они выводили свои версии: и народ также удивлялся, мол, "как можно четыре раза переписывать программу, которая НИЧЕГО не делает"? =)Кстати, с тех пор эти утилиты тоже претерпели весьма солидные изменения. False, например, вообще из двух строчек состоит, и обе - макросы cpp.
И не надейся, не отпущу !
Твоя трава-мурова.- - -
После распаковки архива имеем следующее:
Файлов: 304
Папок: 10
Размер: 3 138 617 байтДобротно спроектировано, правда почему без UI непонятно, и почему бы не применить последние наработки Qt.
> почему без UI непонятноущербный интерфейс, не годится для конвеерности.
> почему бы не применить последние наработки QtБогомерзкие плюсы потому что. info standards.
GNU API будет?
Для яваскрипта?
Это просто праздник какой-то!
Ох, камон. Научи нас программы писать.
Unix way!
> Unix way!“GNU's Not Unix!”
The GNU Project was launched in 1984 to develop the GNU system.
The name “GNU” is a recursive acronym for “GNU's Not Unix!” - https://www.gnu.org/
>> Unix way!
> “GNU's Not Unix!”
> The GNU Project was launched in 1984 to develop the GNU system.
> The name “GNU” is a recursive acronym for “GNU's Not Unix!” -
> https://www.gnu.org/GNU's Not Unix не значит GNU's Not Unix-way.
После сЫстемДы - 100% значит. Даже нет, теперь - 100% финдоузь вэй.
Проиграли линуксоиды, все мечтали финдоузь разгромит, да прощёлкали казачка то :-(
> После сЫстемДы - 100% значит. Даже нет, теперь - 100% финдоузь вэй.
> Проиграли линуксоиды, все мечтали финдоузь разгромит, да прощёлкали казачка то :-(Линус считает, что многие изначальные идеалы Unix в современном мире стоит рассматривать
скорее как результат устоявшегося мировоззрения, чем как обусловленную реалиями
необходимость. Традиционный подход Unix "сделать одно дело и сделать это хорошо",
подразумевающий разложение выполнения сложной задачи на связанную цепочку этапов,
на каждом из которых применяется простой инструмент, слабо сочетается с тем,
как в реальности работают современные усложнённые системы и приложения.http://www.opennet.me/opennews/art.shtml?num=40622
>> После сЫстемДы - 100% значит. Даже нет, теперь - 100% финдоузь вэй.
>> Проиграли линуксоиды, все мечтали финдоузь разгромит, да прощёлкали казачка то :-(
> Линус считает, что многие изначальные идеалы Unix в современном мире стоит рассматривать
> скорее как результат устоявшегося мировоззрения, чем как обусловленную реалиями
> необходимость.одно другому не мешает. даже устоявшееся мировоззрение берётся из обусловленной реалиями необходимости.
> Традиционный подход Unix "сделать одно дело и сделать это хорошо",
> подразумевающий разложение выполнения сложной задачи на связанную цепочку этапов,
> на каждом из которых применяется простой инструмент, слабо сочетается с тем,
> как в реальности работают современные усложнённые системы и приложения.а это следствие безграмотного подхода к разработке, желания вендорлока, графоманства, максимума распространения своей летящей, свестящей и пердящей программулинки разваливающейся под тяжестью "я всё могу, я всё умею, выбери меня".
> даже устоявшееся мировоззрение берётся из обусловленной реалиями необходимостиИли просто из кривой интерпретации этой самой действительности.
>> даже устоявшееся мировоззрение берётся из обусловленной реалиями необходимости
> Или просто из кривой интерпретации этой самой действительности.можно без или. и так и так.
>> Линус считает, что многие изначальные идеалы Unix
>> в современном мире стоит рассматривать скорее как результат
>> устоявшегося мировоззрения, чем как обусловленную реалиями необходимость.
> одно другому не мешает.
> даже устоявшееся мировоззрение берётся из обусловленной реалиями необходимости.реалии в 1970 и 2014 несколько разные.
>> Традиционный подход Unix "сделать одно дело и сделать это хорошо",
>> подразумевающий разложение выполнения сложной задачи на связанную цепочку этапов,
>> на каждом из которых применяется простой инструмент, слабо сочетается с тем,
>> как в реальности работают современные усложнённые системы и приложения.
> а это следствие безграмотного подхода к разработке, желания вендорлока, графоманства,
> максимума распространения своей летящей, свестящей и пердящей программулинки
> разваливающейся под тяжестью "я всё могу, я всё умею, выбери меня".да-да, точно так же критиковали и самого Линуса за то, что он сделал монолитное ядро,
а не так как учил великий Таненбаум - микроядерную ос в полном соответствии с принципами
UNIX way: "Write programs that do one thing and do it well. Write programs to work together." и т.п.ну так сделайте нормальную микроядерную ос, чего зря критиковать-то... ?
> реалии в 1970 и 2014 несколько разные.Выглядит, будто эти люди оправдывают свой буллшит объективной необходимостью, хотя "необходимость" здесь очевидная.
> ну так сделайте нормальную микроядерную ос, чего зря критиковать-то... ?
уже есть. несколько. сюрприз-сюрприз. и критика - это нормально, пнятненько?
>> реалии в 1970 и 2014 несколько разные.
> Выглядит, будто эти люди оправдывают свой буллшит объективной необходимостью,
> хотя "необходимость" здесь очевидная.Вместо того чтобы строить теории на эту тему
- лучше прочитать всю новость целиком:http://www.opennet.me/opennews/art.shtml?num=40622
Линус Торвальдс занял нейтральную позицию в отношении systemd>> ну так сделайте нормальную микроядерную ос, чего зря критиковать-то... ?
> уже есть. несколько. сюрприз-сюрприз. и критика - это нормально, пнятненько?Minix и Hurd так "есть", что можно сказать что их и вовсе "нет",
- почти все пользуются Linux или *BSD с "неправильной монолитной архитектурой".P.S.
Да, да, я уже в курсе, у systemd тоже неправильная монолитная архитектура.
> Вместо того чтобы строить теории на эту тему
> - лучше прочитать всю новость целиком:
> http://www.opennet.me/opennews/art.shtml?num=40622
> Линус Торвальдс занял нейтральную позицию в отношении systemdвозьми и причитай, раз надо.
> Minix и Hurd
и L{3,4}, QNX, и еще несколько совсем малоизвестных.
> так "есть", что можно сказать что их и вовсе "нет", - почти все пользуются Linux или *BSD с "неправильной монолитной архитектурой".
Ну и что с того? ты возмущался, дескать: «ну так сделайте нормальную микроядерную ос, чего зря критиковать-то... ?»
Делали, делают, и будут делать. И критиковать тоже будут.
> возьми и причитай, раз надо.мы с вами разве знакомы?
>> Minix и Hurd
> и L{3,4}, QNX, и еще несколько совсем малоизвестных.QNX не open source, хотя система интересная.
L{3,4} - это не есть "нормальная микроядерная ос".
>> почти все пользуются Linux или *BSD с "неправильной монолитной архитектурой".
> Ну и что с того?Аналогия с systemd. у него тоже "неправильная архитектура",
и им тоже пользуются почти все (из основных дистрибутивов).> «ну так сделайте нормальную микроядерную ос, чего зря критиковать-то... ?»
И что самое интересное - до сих пор нет нормальной микроядерной ос,
которая могла бы заменить собой Linux на десктопах или серверах.> Делали, делают, и будут делать.
Hurd делают до сих пор, "by a few volunteers in their spare time".
Так сильно оно видать всем надо.> И критиковать тоже будут.
Очень давно я не видел конструктивной критики в адрес systemd.
А про хейтеров, которые пытаются "быть святее папы римского" даже и говорить нет смысла.
Тем более, что Линус Торвальдс очень вежливо и точно про них уже сказал:После появления Linux в 1991 году наблюдалась похожая реакция.
На вопрос "не приведёт ли усложнённость systemd к появлению единой точки отказа",
Линус сказал, что с тем же успехом единой точкой отказа можно считать ядро или glibc.
Волну недовольства по отношению к systemd можно объяснить тем, что люди любят критиковать,
имея лишь поверхностное представление о проблеме. Вероятно, если бы они обладали
более глубокими знаниями вопроса их мнение бы изменилось.
>> возьми и причитай, раз надо.
> мы с вами разве знакомы?нам жеманства ни к чему.
>>> Minix и Hurd
>> и L{3,4}, QNX, и еще несколько совсем малоизвестных.
> QNX не open sourceтеперь уже с распространённости скачем по лицензиям? Или ты забываешь с чего начал?
> L{3,4} - это не есть "нормальная микроядерная ос".
у тебя свои критерии, да.
> Аналогия с systemd. у него тоже "неправильная архитектура",
> и им тоже пользуются почти все (из основных дистрибутивов).
> И что самое интересное - до сих пор нет нормальной микроядерной ос,
> которая могла бы заменить собой Linux на десктопах или серверах.для тебя - да. ну и что с того? это не важно.
> Hurd делают до сих пор, "by a few volunteers in their spare
> time".
> Так сильно оно видать всем надо.системде куда нужнее, и вероятно, все даже знают кому, или какой компании именно.
>> И критиковать тоже будут.
> Очень давно я не видел конструктивной критики в адрес systemd.ты вообще ничего не видел, походу. микроядра не видел, нормального микроядра не видел, нормальной распространённой микроядерной оси не видел, и нормальной критики не видел, и то что причина системде скорей экономическая, чем техническая - тоже не видишь.
>> мы с вами разве знакомы?
> нам жеманства ни к чему."Ничто не обходится нам так дешево и не ценится так дорого, как вежливость".
"Противоположностью вежливости являются грубость, хамство, проявление высокомерия и пренебрежительного отношения к людям".
>>> L{3,4}, QNX, и еще несколько совсем малоизвестных.
>> QNX не open source
> теперь уже с распространённости скачем по лицензиям?
> Или ты забываешь с чего начал?Этот сайт называется opennet.ru, и по умолчанию
здесь обсуждается free / open source software.>> L{3,4} - это не есть "нормальная микроядерная ос".
> у тебя свои критерии, да.Я вижу разницу между microkernel и operating system, да.
>> И что самое интересное - до сих пор нет нормальной микроядерной ос,
>> которая могла бы заменить собой Linux на десктопах или серверах.
> для тебя - да. ну и что с того? это не важно.а для вас есть такая ос?
>> Hurd делают до сих пор, "by a few volunteers in their spare time".
>> Так сильно оно видать всем надо.
> системде куда нужнее, и вероятно,
> все даже знают кому, или какой компании именно.В том числе, потому что позволяет настраивать сервера без танцев с бубном.
# localectl set-locale LANG=en_US.UTF-8
# timedatectl set-timezone Europe/Moscow
# systemctl set-default multi-user.target
и т.п.
>> Очень давно я не видел конструктивной критики в адрес systemd.
> ты вообще ничего не видел, походу. микроядра не видел, нормального микроядра не
> видел, нормальной распространённой микроядерной оси не видел, и нормальной критики не
> видел, и то что причина системде скорей экономическая, чем техническая -
> тоже не видишь.Да, systemd позволяет экономить много времени при настройке софта.
Потому что писать sysvinit скрипты для каждого стороннего сервиса - извините,
у меня есть и более интересные занятия. И systemd здесь очень сильно помогает.Собственно, почему для обычных пользователей системы (не разработчиков ос/дистров) -
systemd является более предпочтительной системой инициализации, чем например, sysvinit.
> "Ничто не обходится нам так дешево и не ценится так дорого, как
> вежливость".
> "Противоположностью вежливости являются грубость, хамство, проявление высокомерия и
> пренебрежительного отношения к людям".ты мне еще нравоучения почитай. сам придумал - сам обиделся.
> Этот сайт называется opennet.ru, и по умолчанию
> здесь обсуждается free / open source software.ну и что теперь? а я вот снова упомяну L4 и QNX, да и еще раз скажу что микроядра есть, и хорошие программы писать можно и в этом веке. Писать голиматьё можно в любом веке, и оправдывать это тем что щас другое время. А ты продолжай искать во мне противоположности вежливости, да указывать на правила сайта, несмотря на то что QNX - shared source, L4 - opensource, а оскорблять тебя незачем, ты и так обидчивый как девочка.
> Я вижу разницу между microkernel и operating system, да.
молодец, чо. я рад за тебя. мы ведь о микроядре и начали.
> В том числе, потому что позволяет настраивать сервера без танцев с бубном.
> # localectl set-locale LANG=en_US.UTF-8вместо простого и кроссплатформенного export LANG=en_US.UTF-8 ?
> # timedatectl set-timezone Europe/Moscowвместо простого и кроссплатформенного ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/local-time ?
> # systemctl set-default multi-user.target
telinit 4 в inittab?
> и т.п.
да, таких примеров туча.
> Да, systemd позволяет экономить много времени при настройке софта.
пришло время настраивать софт!11 софт сам по себе не настроится))
> Потому что писать sysvinit скрипты для каждого стороннего сервиса
ну и какие ты писал?
> у меня есть и более интересные занятия. И systemd здесь очень сильно
> помогает.да нифига у тебя нет и не было, и системде тебе не поможет, потому что ты ничего не решаешь с его помощью, чего раньше не мог)
> Собственно, почему для обычных пользователей системы (не разработчиков ос/дистров) -
> systemd является более предпочтительной системой инициализации,обычные пользователи не пишут юниты? юниты сами себя пишут.
> ты мне еще нравоучения почитай. сам придумал - сам обиделся.Вам ненавязчиво предлагают подняться на ступеньку над собой -- Вы продолжаете... :(
>> ты мне еще нравоучения почитай. сам придумал - сам обиделся.
> Вам ненавязчиво предлагают подняться на ступеньку над собой -- Вы продолжаете... :(Миш, если считаешь что переборщил - три что считаешь, или удаляй целиком. Без сантиментов и духовности. Каждая троллдевочка норовит спустить диалог в "мама, он меня с*кой назвал".
> Миш, если считаешь что переборщил - три что считаешь, или удаляй целиком.Если скажете, сотру; сам не вижу оснований, а вот "притормозить" решил предложить. Надеюсь, и Вы меня притормозите, когда заносит.
> ...ты мне еще нравоучения почитай. сам придумал - сам обиделся
> ...а оскорблять тебя незачем, ты и так обидчивый как девочка
> ...да нифига у тебя нет и не было, и системде тебе не поможетмолодой человек, почему вы мне хамите, я вас чем-то обидел?
================================================================
> а я вот снова упомяну L4 и QNX,
> да и еще раз скажу что микроядра есть, и хорошие программы
> писать можно и в этом веке. Писать голиматьё можно в любом
> веке, и оправдывать это тем что щас другое время.то есть, systemd и Linux - это "голиматьё", я вас правильно понимаю?
>> # timedatectl set-timezone Europe/Moscow
> вместо простого и кроссплатформенного
> ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/local-time
> ?простой и кроссплатформенный симлинк /etc/local-time будет проигнорирован системой.
а команда timedatectl set-timezone Europe/Moscow как раз и делает симлинк
/etc/localtime на ../usr/share/zoneinfo/Europe/Moscow, при этом проверяя
аргументы на валидность и не делая ошибок/опечаток в имени симлинка.>> И systemd здесь очень сильно помогает.
> да нифига у тебя нет и не было, и системде тебе не поможет,
> потому что ты ничего не решаешь с его помощью, чего раньше не мог)мог. только вместо написания скрипта на bash - теперь достаточно
просто написать unit-файл, а всю остальную работу сделает systemd.>> Собственно, почему для обычных пользователей системы (не разработчиков ос/дистров)
>> - systemd является более предпочтительной системой инициализации
> молодой человек, почему вы мне хамите, я вас чем-то обидел?да. прости мне моё хамство и не заостряй на ней внимание.
> то есть, systemd и Linux - это "голиматьё", я вас правильно понимаю?
ты оправдываешь голимый софт тем, что дескать не он первый?
> простой и кроссплатформенный симлинк /etc/local-time будет проигнорирован системой.
да у вас вечно всё неработает. потому и системде изобрели, где это тоже не работает, зато работает черезжопу.
> а команда timedatectl set-timezone Europe/Moscow как раз и делает симлинк
> /etc/localtime на ../usr/share/zoneinfo/Europe/Moscow, при этом проверяя
> аргументы на валидность и не делая ошибок/опечаток в имени симлинка.У меня <tab> тоже не делает ошибок и опечаток. А про валидность в строке с слэшем - бугага :D Смешно, даже для такого простого действия нужно писать некроссплатформенную сишную портянку на 600 строк.
> мог. только вместо написания скрипта на bash - теперь достаточно
> просто написать unit-файл, а всю остальную работу сделает systemd.Вот, ты подтвердил: нихренульки ты нового не решил. Только перестал писать скрипты, которые и раньше не писал, просто еще одно оправдание.
Ну и как ты проверяешь код возврата запущенного приложения через юнит, если приложение запустилось успешно? Никак. Тебе либо это "не надо", либо пишешь на шелле. Предлагаю тебе писать сразу на Си. Потому что так гораздо проще и удобнее, чем проверить [ $? -eq 0 ]. Или патчить системде, и т.к. лёня с командой патчи не принимают, мешающие их мировоззрению - держи у себя локальное дерево этого быдлокода с захардкоженными путями. И если новое обновление что-то поменяет - патч, мазафака! Или жди обновление. А потом снова патч с своими изменениями!
>> молодой человек, почему вы мне хамите, я вас чем-то обидел?
> да.интересно, чем же, тем что у меня есть свое мнение по поводу systemd ?
>> то есть, systemd и Linux - это "голиматьё", я вас правильно понимаю?
> ты оправдываешь голимый софт тем, что дескать не он первый?я не считаю, что systemd и Linux - это "голимый софт", поэтому и оправдывать нечего.
There are only two kinds of languages:
the ones people complain about and the ones nobody uses. — Bjarne StroustrupЕсть всего 2 типа языков:
те, на которые все жалуются и те, которыми никто не пользуется. — Бьерн Страуструпс операционными системами и системами инициализации имхо примерно такая же ситуация.
>> только вместо написания скрипта на bash - теперь достаточно
>> просто написать unit-файл, а всю остальную работу сделает systemd.
> Вот, ты подтвердил: нихренульки ты нового не решил.Я и не собирался ничего нового решать.
Для моих задач systemd подходит лучше, чем sysvinit.Причем, в некоторых вариантах использования systemd будет значительно удобнее
и значительно упрощает пользование системой, по сравнению с sysvinit скриптами на bash.> Только перестал писать скрипты, которые и раньше не писал, просто еще одно оправдание.
Оправдание чего?
> Ну и как ты проверяешь код возврата запущенного приложения через юнит, если
> приложение запустилось успешно? Никак. Тебе либо это "не надо", либо пишешь
> на шелле. Предлагаю тебе писать сразу на Си. Потому что так
> гораздо проще и удобнее, чем проверить [ $? -eq 0 ].Если демон стартует через двойной форк - код завершения ничего не скажет.
Поэтому - не понимаю зачем мне это может быть надо. Хотя, возможность такая есть.> Или патчить системде, и т.к. лёня с командой патчи не принимают,
> мешающие их мировоззрению - держи у себя локальное дерево этого быдлокода
> с захардкоженными путями. И если новое обновление что-то поменяет - патч,
> мазафака! Или жди обновление. А потом снова патч с своими изменениями!Что изменится, если в этом фрагменте текста
"systemd" заменить на "Linux", а "лёня" заменить на "Линус" ?
> интересно, чем же, тем что у меня есть свое мнение по поводу systemd ?тем что мы о другом, а тебе лишь бы на сентименты всё свести да на личности. мученик системде :D
> Есть всего 2 типа языков:
> те, на которые все жалуются и те, которыми никто не пользуется. —
> Бьерн Страуструпто-то пришлось всем впаривать системде, чтоб они пользовались, а когда начали жаловаться - конечно, можно поговорить о том, что это происходит потому что этим шитом пользуются)
> с операционными системами и системами инициализации имхо примерно такая же ситуация.
да, с виндой также. Линукс выбирают, и его в отличие от системде и винды - не насаживают.
> Я и не собирался ничего нового решать.
обновления ради обновлений.
> Для моих задач systemd подходит лучше, чем sysvinit.
узкий у тебя круг задач и операционных систем. не у всех так.
> Причем, в некоторых вариантах использования systemd будет значительно удобнее
ага, видели. timectl или как-там, или systemd-fsck, или еще что :-D
> и значительно упрощает пользование системой, по сравнению с sysvinit скриптами на bash.
если вообще не копаться в системде и оставить как есть. тогда в общем то пофиг что за инит. а если надо поковырять, то шелл на выбор для любых систем + инит - то что доктор прописал. работает везде.
>> Только перестал писать скрипты, которые и раньше не писал, просто еще одно оправдание.
> Оправдание чего?нужности системде из уст форумных агитаторов.
>> Ну и как ты проверяешь код возврата запущенного приложения через юнит, если
>> приложение запустилось успешно?
> Если демон стартует через двойной форк - код завершения ничего не скажет.какое уместное замечание.
> Поэтому - не понимаю зачем мне это может быть надо.
> Хотя, возможность такая есть.нету, не ври.
> Что изменится, если в этом фрагменте текста
> "systemd" заменить на "Linux", а "лёня" заменить на "Линус" ?что ты как маленький? новостей о диалогах линуса и поццеринга с сиверсом не читал?
> мы о другомо теории заговора про то, как Red Hat хочет захватить весь мир и подкупила
или запугала TC дебиана / разработчиков других дистрибутивов и DE,
заставив их всех перейти на systemd ?может быть все проще, и сотрудники компании Red Hat
просто делают то, что им надо и то что им интересно?а другие дистрибутивы переходят на systemd только потому,
что все остальные варианты (sysvinit,upstart,...) еще хуже?>> Для моих задач systemd подходит лучше, чем sysvinit.
> узкий у тебя круг задач и операционных систем. не у всех так.разве есть какие-то задачи, которые можно решить с помощью sysvinit,
и нельзя решить с помощью systemd ? там же соблюдается обратная совместимость.>> не понимаю зачем мне это может быть надо. Хотя, возможность такая есть.
> нету, не ври.я не вру, есть.
> о теории заговорао том, что GNU's Not Unix != GNU's Not Unix-way
>>> Для моих задач systemd подходит лучше, чем sysvinit.
>> узкий у тебя круг задач и операционных систем. не у всех так.
> разве есть какие-то задачи, которые можно решить с помощью sysvinit,
> и нельзя решить с помощью systemd ?да, например работать в системах без cgroups или на базе других ядер. не годится для встраиваемой техники, т.к. дублирует функционал и так необходимый вне зависимости есть это голиматьё или нету.
>>> не понимаю зачем мне это может быть надо. Хотя, возможность такая есть.
>> нету, не ври.
> я не вру, есть.обычная ложь обычного системде агитатора. нету.
> о том, что GNU's Not Unix != GNU's Not Unix-wayмежду прочим, я никогда не утверждал обратного.
о том, что такое Unix Philosophy и Unix-way очень подробно
написано здесь: http://www.catb.org/esr/writings/taoup/html/тогда встречный вопрос - много ли Unix Philosophy
в таком монстре, как GNU Emacs или vim, или perl?>> разве есть какие-то задачи, которые можно решить с помощью sysvinit,
>> и нельзя решить с помощью systemd ?
> да, например работать в системах без cgroups или на базе других ядер.
> не годится для встраиваемой техникипонятно. только меня этот вопрос интересует
исключительно в аспекте серверов и десктопов.>>>> не понимаю зачем мне это может быть надо. Хотя, возможность такая есть.
>>> нету, не ври.
>> я не вру, есть.
> обычная ложь обычного системде агитатора. нету.возможность такая есть, и это правда.
хотя до сих пор не понятно, кому и зачем
это может понадобиться при старте демонов.
>> о том, что GNU's Not Unix != GNU's Not Unix-way
> между прочим, я никогда не утверждал обратного.
>>> Новость о GNU.
>> Цитата: Unix-way.
> Ответ: GNU's Not Unix.загадочно выражаешься.
>тогда встречный вопрос - много ли Unix Philosophy в таком монстре, как GNU Emacs или vim, или perl?
всё в мире относительно, а системде - кусок буллшита, несовместимый целиком и полностью.
> понятно. только меня этот вопрос интересует исключительно в аспекте серверов и десктопов.
все это и в контексте серверов, и десктопов. Просто у тебя свой контекст, потребительский, где всё за тебя делают. А чего нет - того и не надо.
> возможность такая есть, и это правда.
только не в системде :)
> всё в мире относительно,
> а системде - кусок буллшита, несовместимый целиком и полностью.и с чем в таком случае сравнивается systemd - неужели с sysvinit ?
например, те же launchd/SMF/upstart - они сильно лучше по сравнению с systemd ?
>> меня этот вопрос интересует исключительно в аспекте серверов и десктопов.
> все это и в контексте серверов, и десктопов. Просто у тебя свой
> контекст, потребительский, где всё за тебя делают. А чего нет - того и не надо.если systemd чего-то не умеет - никто не запрещает написать
этот фрагмент на bash или любом другом языке программирования.можно даже вообще не заморачиваться с изучением systemd, а продолжать
писать инит-скрипты на bash и все будет работать под управлением systemd.http://www.freedesktop.org/wiki/Software/systemd/
systemd is a system and service manager for Linux,
compatible with SysV and LSB init scripts.>> возможность такая есть, и это правда.
> только не в системде :)ExecStart=
> если systemd чего-то не умеет - никто не запрещает написать
> этот фрагмент на bash или любом другом языке программирования.и до тоже никто не запрещал, а всё что умеет оно - всё это было и раньше. нужность у системде технически нулевая, экономически -поживём увидим.
>>> возможность такая есть, и это правда.
>> только не в системде :)
> ExecStart=ты не понимаешь о чём я, видимо. Как ты запустишь сервис, когда запуск вспомогательной утилиты вернул 0?
>> если systemd чего-то не умеет - никто не запрещает написать
>> этот фрагмент на bash или любом другом языке программирования.
> и до тоже никто не запрещал, а всё что умеет оно - всё это было и раньше.все что умеет vim - умеет и ed, следовательно vim не нужен.
все что умеет emacs - умеет и vim, следовательно emacs не нужен.
все что умеет linux - умеет и freebsd, следовательно linux не нужен.
> нужность у системде технически нулевая, экономически - поживём увидим.
https://en.wikipedia.org/wiki/Red_Hat
Revenue US$ 1,534.615 million (2014)
>>>> возможность такая есть, и это правда.
>>> только не в системде :)
>> ExecStart=
> ты не понимаешь о чём я, видимо. Как ты запустишь сервис,
> когда запуск вспомогательной утилиты вернул 0?в ExecStart= разве нельзя прописать шелл-скрипт,
который и будет делать такой conditional start ?
> все что умеет vim - умеет и ed, следовательно vim не нужен.системде что с шеллом, что без шелла - не умеет ничего такого, чего не умеет sysvinit с шеллом. Потому замена по дефолту крайне сомнительна, учитывая технические минусы этой программы и упоротость её создателей :-)
>>>>> возможность такая есть, и это правда.
>>>> только не в системде :)
>>> ExecStart=
>> ты не понимаешь о чём я, видимо. Как ты запустишь сервис,
>> когда запуск вспомогательной утилиты вернул 0?
> в ExecStart= разве нельзя прописать шелл-скрипт,
> который и будет делать такой conditional start ?ну вот, а то валенком прикидывался. Можно и в Start, и в Stop, и так далее. Учитывая какие в красношляпке пИсари, приколюсь через годик-два на смесь шелл-скриптов и юнит-файлов :-D Надеюсь будем живы и здоровы, и я тебе напомню. Забавно будет. Ну, или поцц добавит еще один кондишн. Тогда посмотрим сколько их накопится за пару лет)
>> все что умеет vim - умеет и ed, следовательно vim не нужен.
> системде что с шеллом, что без шелла - не умеет ничего такого,
> чего не умеет sysvinit с шеллом.http://0pointer.de/blog/projects/why.html
http://0pointer.net/blog/projects/the-biggest-myths.html
> Потому замена по дефолту крайне сомнительна,
> учитывая технические минусы этой программы и упоротость её создателей :-)"Волну недовольства по отношению к systemd можно объяснить тем,
что люди любят критиковать, имея лишь поверхностное представление о проблеме.
Вероятно, если бы они обладали более глубокими знаниями вопроса их мнение бы изменилось.">>> Как ты запустишь сервис, когда запуск вспомогательной утилиты вернул 0?
ExecStart=/bin/bash -c "helper-util && main-binary"
очень сложно?
только это искуственный пример, таких задач на практике не возникает.> Учитывая какие в красношляпке пИсари, приколюсь через
> годик-два на смесь шелл-скриптов и юнит-файлов :-D Надеюсь будем живы и
> здоровы, и я тебе напомню. Забавно будет. Ну, или поцц добавит
> еще один кондишн. Тогда посмотрим сколько их накопится за пару лет)не обязательно ждать несколько лет. там и сейчас смесь шелл-скриптов и юнитов systemd.
например, сеть поднимается в CentOS 7 через shell скрипт, - и никаких проблем с этим нет.systemd не заставляет выбирать: используй или юнит-файлы или инит-скрипты на баше.
можно использовать одновременно и то и другое, выбирая, какой вариант будет удобнее.
в 99% случаев удобнее юнит-файлы, где их будет не достаточно - там инит-скрипты на баше.
> http://0pointer.de/blog/projects/why.html
> http://0pointer.net/blog/projects/the-biggest-myths.htmlмоветон кидать ссылки на войну и мир этого нытика. лучше уж его старательные картиночки, в духе systemd vs sysvinit, нечто вроде этого: http://i.imgur.com/usftZ.png
дальше комментировать твою библию нет смысла.
>>>> Как ты запустишь сервис, когда запуск вспомогательной утилиты вернул 0?
> ExecStart=/bin/bash -c "helper-util && main-binary"
> очень сложно?нисколько. нужнее от этого системде не становится. лишний комбайн.
> только это искуственный пример, таких задач на практике не возникает.
этот пример не существует. таких задач не возникает. отрицай.
> не обязательно ждать несколько лет. там и сейчас смесь шелл-скриптов и юнитов
> systemd.одно время фанатики поттеринга напевали об унификации. обманулись.
> systemd не заставляет выбирать:
вообще не заставляет. либо системде - либо форкай всё что они успеют включить в системде))
>> http://0pointer.de/blog/projects/why.html
>> http://0pointer.net/blog/projects/the-biggest-myths.html
> моветон кидать ссылки на войну и мир этого нытика.вот как удобно, назвал кого-то нытиком, и все - сразу опроверг все что там написано.
> нужнее от этого системде не становится. лишний комбайн.
не надо - не пользуйся.
>>> http://0pointer.de/blog/projects/why.html
>>> http://0pointer.net/blog/projects/the-biggest-myths.html
>> моветон кидать ссылки на войну и мир этого нытика.
> вот как удобно, назвал кого-то нытиком, и все - сразу опроверг все
> что там написано.но ведь он нытик. и то что там пишет - бред сивой кобылы. тут практически все видели эти ссылки и обсуждали их уже не раз.
>> нужнее от этого системде не становится. лишний комбайн.
> не надо - не пользуйся.Не пользуюсь, навязывают. Рекламируют как секта. Ходят, рассказывают о системде и о том как их жизнь после этого изменилась. Непринявших системде называют греш^W ретроградами, а своего лидера видят чуть ли не революционером. Приписывают этой программе свойства, которые никто никогда не видел. Сектанты то ведут себя агрессивно, то прикидываются жертвами репрессий.
>>>> http://0pointer.de/blog/projects/why.html
>>>> http://0pointer.net/blog/projects/the-biggest-myths.html
>>> моветон кидать ссылки на войну и мир этого нытика.
>> вот как удобно, назвал кого-то нытиком,
>> и все - сразу опроверг все что там написано.
> но ведь он нытик. и то что там пишет - бред сивой кобылы.
> тут практически все видели эти ссылки и обсуждали их уже не раз.тут разумеется собралось очень мощное экспертное сообщество,
которое просто на раз-два умеет ставить диагнозы по переписке,
но я бы все-таки предпочел увидеть аргументированные опровержения,
которые написаны авторитетными разработчиками уровня Линуса Торвальдса
или его непосредственных заместителей. Пока что есть только одно выступление
Линуса на эту тему и оно достаточно нейтральное по отношению к systemd.>>> нужнее от этого системде не становится. лишний комбайн.
>> не надо - не пользуйся.
> Не пользуюсь, навязывают.заставляют пользоваться?
> Рекламируют как секта. Ходят, рассказывают о системде и о том как их жизнь
> после этого изменилась. Непринявших системде называют греш^W ретроградами,какой ужас. так ведь и до Holy War совсем недалеко.
> а своего лидера видят чуть ли не революционером.
да, он задумал сделать государственный переворот, не меньше:
http://www.opennet.me/opennews/art.shtml?num=40494
в средневековье таких запросто сжигали на кострах.> Приписывают этой программе свойства, которые никто никогда не видел.
> Сектанты то ведут себя агрессивно, то прикидываются жертвами репрессий.они же теперь прочитают это, поймут что их раскусили и сменят тактику.
после чего их будет еще труднее обнаружить. вот идешь по улице - смотришь,
вроде бы обычный человек идет. а если присмотреться повнимательнее - окажется,
что это Агент Смит из Матрицы/Системы/systemd. Как страшно жить. И только бесстрашные
борцы с Системой(D) днем и ночью ведут свою священную войну с Матрицей и ее агентами.Пожалуй надо будет еще раз посмотреть все части Матрицы и купить побольше попкорна. :)
> тут разумеется собралось очень мощное экспертное сообщество,
> которое просто на раз-два умеет ставить диагнозы по переписке,
> но я бы все-таки предпочел увидеть аргументированные опровержения,
> которые написаны авторитетными разработчиками уровня Линуса Торвальдса
> или его непосредственных заместителей. Пока что есть только одно выступление
> Линуса на эту тему и оно достаточно нейтральное по отношению к systemd.мне не нужны авторитеты. тебе нужны - сам и ищи. Говорю это просто, но с уважением. Зная какая ты плакса ;-)
> заставляют пользоваться?
угу. приходит лично поттеринг и под дулом пистолета заставляет.
> Пожалуй надо будет еще раз посмотреть все части Матрицы и купить побольше попкорна. :)
первая - наивняк полнейший. Забавно посмотреть через столько лет) Зато последние - айс. Кстати советую "Эквилибриум". Как и в матрице есть и философия, а зрелищность ;-)
>> тут разумеется собралось очень мощное экспертное сообщество,
>> которое просто на раз-два умеет ставить диагнозы по переписке,
>> но я бы все-таки предпочел увидеть аргументированные опровержения,
>> которые написаны авторитетными разработчиками уровня Линуса Торвальдса
>> или его непосредственных заместителей. Пока что есть только одно выступление
>> Линуса на эту тему и оно достаточно нейтральное по отношению к systemd.
> мне не нужны авторитеты. тебе нужны - сам и ищи."но ведь он нытик. и то что там пишет - бред сивой кобылы. тут практически все видели
эти ссылки и обсуждали их уже не раз" - это как раз и есть отсылка к "авторитетам",
которым безоговорочно надо верить на слово, даже при полном отсутствии аргументов.> Говорю это просто, но с уважением. Зная какая ты плакса ;-)
я тебя опять чем-то обидел?
Вообще, это такое свойство человеческой психики, кто сам сильно обидчивый,
тот всех вокруг считает обидчивыми. кто сам обманщик - тот всех вокруг
считает обманщиками и т.п. на этом построено очень много методик исследования
личности. например, в тесте http://www.midot.ru/ задают вопросы о том, что человек
думает про окружающих себя людей. И человек думает что рассказывает что-то о других,
но на самом деле - он рассказывает только о себе. И на основании этих его рассказов
делается очень точный психологический портрет личности. Причем таким образом человек
рассказывает о себе практически все, даже то, что хотел бы скрыть от других.
> "но ведь он нытик. и то что там пишет - бред сивой
> кобылы. тут практически все видели
> эти ссылки и обсуждали их уже не раз" - это как раз
> и есть отсылка к "авторитетам",
> которым безоговорочно надо верить на слово, даже при полном отсутствии аргументов.это факт который ты игнорируешь.
> я тебя опять чем-то обидел?
да, тем что ты за системде и говоришь правду, которую мне невыносимо слушать.
> Вообще, это такое свойство человеческой психики, кто сам сильно обидчивый,
> тот всех вокруг считает обидчивыми. кто сам обманщик - тот всех вокруг
> считает обманщиками и т.п.кто сам агрессивный - считать всех вокруг агрессивными... да, поттеринг и системдешники дебиана?))
Братцы, вам делать нечего?..
>> "но ведь он нытик. и то что там пишет - бред сивой
>> кобылы. тут практически все видели
>> эти ссылки и обсуждали их уже не раз" - это как раз
>> и есть отсылка к "авторитетам",
>> которым безоговорочно надо верить на слово, даже при полном отсутствии аргументов.
> это факт который ты игнорируешь."он нытик" и "то что там пишет - бред сивой кобылы" - это не факты, а оценочные суждения.
>> я тебя опять чем-то обидел?
> да, тем что ты за системде и говоришь правду, которую мне невыносимо слушать.тебя действительно обижает тот факт, что у других людей мнение отличное от твоего?
>> Вообще, это такое свойство человеческой психики, кто сам сильно обидчивый,
>> тот всех вокруг считает обидчивыми. кто сам обманщик - тот всех вокруг
>> считает обманщиками и т.п.
> кто сам агрессивный - считать всех вокруг агрессивными...
> да, поттеринг и системдешники дебиана?))даже на этом форуме я видел неоднократные угрозы физического устранения Поттеринга.
не смотря на то, что "Угроза убийством или причинением тяжкого вреда здоровью"
- это есть уголовное преступление, ст.119,ч.2 в УК: http://www.zakonrf.info/uk/119/
> systemd не заставляет выбирать: используй или юнит-файлы или инит-скрипты на баше.
> можно использовать одновременно и то и другое, выбирая, какой вариант будет удобнее.Раздавались шумы насчёт желательности исправления этой "недоработки", имейте в виду.
>>>> не понимаю зачем мне это может быть надо. Хотя, возможность такая есть.
>>> нету, не ври.
>> я не вру, есть.
> обычная ложь обычного системде агитатора. нету.Вы говорите с грамотным системным администратором, которого я на лжи не ловил, например.
Прошу держать себя в руках. Нет смысла ругаться. А спорить -- только если и сам ещё слышишь.
> тем что мы о другом, а тебе лишь бы на сентименты всё
> свести да на личности. мученик системде :DЕсть предложение не заниматься самополяризацией -- общение подразумевает наличие общей темы, не лучше ли понять и обсудить её, чем то, кто что думает иначе и всё тут?
>> Или патчить системде, и т.к. лёня с командой патчи не принимают,
>> мешающие их мировоззрению - держи у себя локальное дерево этого быдлокода
>> с захардкоженными путями.
> Что изменится, если в этом фрагменте текста
> "systemd" заменить на "Linux", а "лёня" заменить на "Линус" ?Линуса можно переубедить аргументами, недавно наблюдали очередной такой случай с патчем коллеги.
> Потому что писать sysvinit скрипты для каждого стороннего сервиса - извините,
> у меня есть и более интересные занятия. И systemd здесь очень сильно помогает.Раз речь о systemd - не-Linux вам не интересен. Раз речь о Linux - кто виноват в том, что автор не удосужился ознакомиться с LSB?
Не понимаю такой логики. Один раз человек отказался учиться и не сделал работу. С какой стати вы решили что в другой раз он выучит незнакомый синтаксис и работу таки сделает?
> Не понимаю такой логики. Один раз человек отказался учиться и не
> сделал работу. С какой стати вы решили что в другой
> раз он выучит незнакомый синтаксис и работу таки сделает?Дело не в синтаксисе и даже не в "конфигурация vs код". Дело в том, что некомпетентный человек, которому дали более высокоуровневые инструменты, опирающиеся на более сложные сущности (в первую очередь зависимости) -- допустит ещё более безнадёжные ошибки.
>> Потому что писать sysvinit скрипты для каждого стороннего сервиса - извините,
>> у меня есть и более интересные занятия. И systemd здесь очень сильно помогает.
> Раз речь о systemd - не-Linux вам не интересен.Почему же, другие OS мне тоже интересны, но в текущий момент,
CentOS + OpenVZ является наиболее оптимальным вариантом для сервера.> Раз речь о Linux - кто виноват в том, что автор не удосужился ознакомиться с LSB?
Не в этом дело. Например, понадобилось мне настроить второй monit чтобы он запускался
и работал от имени пользователя www, - с systemd это делается достаточно просто:===================================
[Unit]
Description=Pro-active monitoring utility for unix systems
After=network.target
ConditionFileNotEmpty=/home/www/.monitrc[Service]
Type=simple
ExecStart=/usr/bin/monit -I -c /home/www/.monitrc
ExecStop=/usr/bin/monit -c /home/www/.monitrc quit
ExecReload=/usr/bin/monit -c /home/www/.monitrc reload
Restart=on-failure
User=www[Install]
WantedBy=multi-user.target===================================
При использовании sysvinit - пришлось бы писать и отлаживать инит-скрипт на баше.
Причем, я даже и не знаю, как просто и изящно на баше сформулировать Restart=on-failure
> Почему же, другие OS мне тоже интересны, но в текущий момент,
> CentOS + OpenVZ является наиболее оптимальным вариантом для сервера.Для VPS быдлохостинга ты хотел сказать?
>> Раз речь о Linux - кто виноват в том, что автор не удосужился ознакомиться с LSB?
> Не в этом дело.Альтернативное объяснения - просто забил на работу. Непонятно почему другой инструмент неприменно заставит его эту работу таки сделать.
> При использовании sysvinit - пришлось бы писать и отлаживать инит-скрипт на баше.
Скопировать системный init-файл и поменять пару строк - не судьба?
> Причем, я даже и не знаю, как просто и изящно на баше
> сформулировать Restart=on-failureЯ рад, что ты хоть дошел до честного "я не знаю". Правильное решение этой проблемы - узнать (man inittab).
>> CentOS + OpenVZ является наиболее оптимальным вариантом для сервера.
> Для VPS быдлохостинга ты хотел сказать?я сказал ровно то, что хотел сказать.
>>> Раз речь о Linux - кто виноват в том, что автор не удосужился ознакомиться с LSB?
>> Не в этом дело.
> Альтернативное объяснения - просто забил на работу. Непонятно почему другой инструмент
> неприменно заставит его эту работу таки сделать.при чем тут LSB?
>> При использовании sysvinit - пришлось бы писать и отлаживать инит-скрипт на баше.
> Скопировать системный init-файл и поменять пару строк - не судьба?это не всегда возможно.
>> Причем, я даже и не знаю, как просто и изящно на баше
>> сформулировать Restart=on-failure
> Я рад, что ты хоть дошел до честного "я не знаю".
> Правильное решение этой проблемы - узнать (man inittab).тот вариант, который рекомендуется в
http://mmonit.com/monit/documentation/monit.html# Run Monit in standard run-levels
mo:2345:respawn:/usr/local/bin/monit -Ic /etc/monitrcне эквивалентен Restart=on-failure, потому что будет перезапускать monit всегда,
даже после graceful завершения процесса командой monit quit
>>> CentOS + OpenVZ является наиболее оптимальным вариантом для сервера.
>> Для VPS быдлохостинга ты хотел сказать?
> я сказал ровно то, что хотел сказать.Ну тогда вы, извините, дурак. Сервера выполняют самые разные задачи, а вовсе не
>>>> Раз речь о Linux - кто виноват в том, что автор не удосужился ознакомиться с LSB?
>>> Не в этом дело.
>> Альтернативное объяснения - просто забил на работу. Непонятно почему другой инструмент
>> неприменно заставит его эту работу таки сделать.
> при чем тут LSB?При том, что стандарт позволяет сделать означенную работу.
>>> При использовании sysvinit - пришлось бы писать и отлаживать инит-скрипт на баше.
>> Скопировать системный init-файл и поменять пару строк - не судьба?
> это не всегда возможно.Мы не об абстрактных случаях, а о совершенно конкретном.
>[оверквотинг удален]
>> Я рад, что ты хоть дошел до честного "я не знаю".
>> Правильное решение этой проблемы - узнать (man inittab).
> тот вариант, который рекомендуется в
> http://mmonit.com/monit/documentation/monit.html
>
> # Run Monit in standard run-levels
> mo:2345:respawn:/usr/local/bin/monit -Ic /etc/monitrc
>
> не эквивалентен Restart=on-failure, потому что будет перезапускать monit всегда,
> даже после graceful завершения процесса командой monit quitОн эквивалентен разумной части вашей хотелки (процесс помирать не должен никогда). Впрочем, учитывая условия задачи - о разуме ее создателя можно сказать много "хорошего". Но это уже детали.
> вы, извините, дурак.по сравнению с Альбертом Эйнштейном - да, разумеется.
ну поправь файл-демон, чтоб вместо простого quit было вроде
quit)
shed -i 's/нужная строка/закомментированная строка/' /etc/inittab
kill -HUP [pid]
...по аналогии, добавь строчку в start которая раскомментирует.
> ну поправь файл-демон, чтоб вместо простого quit было вроде
>
> quit)
> shed -i 's/нужная строка/закомментированная строка/' /etc/inittab
> kill -HUP [pid]
> ...
>
> по аналогии, добавь строчку в start которая раскомментирует.ответ на вопрос, что удобнее в использовании - systemd или sysvinit уже очевиден или нет?
> ответ на вопрос, что удобнее в использовании - systemd или sysvinit уже
> очевиден или нет?этот пример не показывает всего удобства системде. написал ты юнит файл, написал шелл-скрипт, какая разница? последний хоть работает везде, а в первом случае может не заработать в следующей версии, если вдруг задумают какую-нибудь опцию переименовать/удалить. а если нет нужных кондишинов, так и на шелле придётся писать, и умножать сущности: юнит-файл + шелл-скрипт. И ради чего, комбайна который ничего не умеет нужного, а то что умеет - сто лет в обед везде работало?
>> ответ на вопрос, что удобнее в использовании - systemd или sysvinit уже
>> очевиден или нет?
> этот пример не показывает всего удобства системде.всего - нет. но некоторые ситуации, когда systemd удобнее за sysvinit показывает.
> написал ты юнит файл, написал шелл-скрипт, какая разница?
разница в количестве времени, которое надо затратить на написание и отладку файла/скрипта.
> последний хоть работает везде
"In theory there is no difference between theory and practice. In practice there is".
Например, инит-скрипт, который работает на CentOS - перестал работать на Ubuntu,
потому что они там пораскладывали системные утилиты по совсем другим каталогам.> а в первом случае может не заработать в следующей версии,
> если вдруг задумают какую-нибудь опцию переименовать/удалить.точно так же софт не будет работать на следующей версии ядра,
если вдруг задумают какой-нибудь системный вызов переименовать/удалить.> а если нет нужных кондишинов, так и на шелле придётся писать,
> и умножать сущности: юнит-файл + шелл-скрипт.лучше 10 строчек юнит-файла и 10 строчек скрипта на bash, чем 50 строчек скрипта на bash.
> И ради чего, комбайна который ничего не умеет нужного,
> а то что умеет - сто лет в обед везде работало?я уже отвечал на этот вопрос: лично мне удобнее написать небольшой юнит-файл
и в декларативном стиле объяснить systemd что именно я хочу получить,
вместо того, чтобы в императивном стиле это все кодировать на bash в виде инит-скрипта.например, первые СУБД не были реляционными, а были иерархическими или сетевыми.
и для того чтобы сделать выборку из такой базы данных - приходилось писать
отдельную программу и запускать ее на выполнение.после того, как появились реляционные базы данных - необходимость писать программу
на каждый запрос уже отпала и можно было очень быстро делать выборки сформулировав
на декларативном языке SQL запрос о том, что именно надо получить в результате,
и при этом не надо детально и пошагово расписывать как именно это сделать.согласен с тем, что systemd не идеальная система и что у нее много недостатков.
но покажите хотя бы одну "декларативную" а не "императивную" систему инициализации,
которая будет лучше чем systemd ("лучше" - это в смысле "удобнее для пользователя").кстати, первые реляционные СУБД тоже ведь были монстрообразными, работали очень медленно
и требовали много ресурсов по сравнению с быстрыми и очень эффективными иерархическими
или сетевыми СУБД у которых был почти нулевой оверхед и очень высокая производительность.P.S.
https://ru.wikipedia.org/wiki/Луддиты
> всего - нет. но некоторые ситуации, когда systemd удобнее за sysvinit показывает.какие ситуации? покажи их, пусть увидят да прозреют.
>> написал ты юнит файл, написал шелл-скрипт, какая разница?
> разница в количестве времени, которое надо затратить на написание и отладку файла/скрипта.согласен, скрипт быстрее поправить. только где здесь преимущество системде?
> Например, инит-скрипт, который работает на CentOS - перестал работать на Ubuntu,
> потому что они там пораскладывали системные утилиты по совсем другим каталогам.Либо сразу program, либо PROGRAM=$(which program). А редхат всегда славилась кривыми шелл скриптами. Настоящими макаронными чудовищами даже. Разобраться в их помойке было действительно непросто. Ну да все равно у каждого дистрибутива свои юнит-файлы для системде, так что проблему они все равно не решили. А другие дистры такой проблемы и не имели.
>> а в первом случае может не заработать в следующей версии,
>> если вдруг задумают какую-нибудь опцию переименовать/удалить.
> точно так же софт не будет работать на следующей версии ядра,
> если вдруг задумают какой-нибудь системный вызов переименовать/удалить.в случае с системде такое бывало: то удаляли добавленные переменные, то меняли поведение условия, то файлы переносили с места на место.
> лучше 10 строчек юнит-файла и 10 строчек скрипта на bash, чем 50
> строчек скрипта на bash.10, 10, 50... какие пропорции.. чувствуется опыт.
> я уже отвечал на этот вопрос: лично мне удобнее написать небольшой юнит-файл
а иногда и баш-скрипт :-D
> и в декларативном стиле объяснить systemd что именно я хочу получить,
> вместо того, чтобы в императивном стиле это все кодировать на bash в
> виде инит-скрипта.если в нём предусмотрено поттерингом то что ты хочешь. Иначе - соси лапу и пиши на баше. Потом вызывай баш скрипт из юнита.
> согласен с тем, что systemd не идеальная система и что у нее
> много недостатков.
> но покажите хотя бы одну "декларативную" а не "императивную" систему инициализации,
> которая будет лучше чем systemd ("лучше" - это в смысле "удобнее для
> пользователя").пользователь вообще не лезет в инит. тем более не для того чтоб подтюнинговать под свои нужды.
> https://ru.wikipedia.org/wiki/Луддиты
ааа, так это ты? уже не первый раз кидаешь в дискуссиях эту ссылку. Долго небось удерживался от "прогрессивных" метафор :-D
>> всего - нет. но некоторые ситуации, когда systemd удобнее за sysvinit показывает.
> какие ситуации? покажи их, пусть увидят да прозреют.лучше чем Линус Торвальдс я вряд ли скажу:
...
Поляризация взглядов в сообществе не является чем-то новым, например, обсуждения systemd
против традиционных систем инициализации лишь продолжают традицию возникновения дискуссий
на темы "emacs против vi", "SysV init против BSD init", "лицензия GPL против BSD", "KDE
против GNOME", "монолитные ядра против микроядер". После появления Linux в 1991 году
наблюдалась похожая реакция. На вопрос "не приведёт ли усложнённость systemd к появлению
единой точки отказа", Линус сказал, что с тем же успехом единой точкой отказа можно
считать ядро или glibc. Волну недовольства по отношению к systemd можно объяснить тем,
что люди любят критиковать, имея лишь поверхностное представление о проблеме. Вероятно,
если бы они обладали более глубокими знаниями вопроса их мнение бы изменилось.
...http://www.opennet.me/opennews/art.shtml?num=40622
>>> а в первом случае может не заработать в следующей версии,
>>> если вдруг задумают какую-нибудь опцию переименовать/удалить.
>> точно так же софт не будет работать на следующей версии ядра,
>> если вдруг задумают какой-нибудь системный вызов переименовать/удалить.
> в случае с системде такое бывало: то удаляли добавленные переменные, то меняли
> поведение условия, то файлы переносили с места на место.1) не ошибается только тот, кто ничего не делает.
2) ломать стабильные релизы RHEL они вряд ли станут.
>> я уже отвечал на этот вопрос: лично мне удобнее написать небольшой юнит-файл
> а иногда и баш-скрипт :-Dесли честно, bash - это монстр. и я даже 50% его возможностей не знаю.
синтаксис настолько кривой после perl или python, что временами
он больше похож на cmd.exe или Windows PowerShell какой-нибудь.> пиши на баше. Потом вызывай баш скрипт из юнита.
если выбор между "писать все на баше" и "писать только небольшую часть на баше",
то второй вариант мне нравится больше.>> покажите хотя бы одну "декларативную" а не "императивную" систему инициализации,
>> которая будет лучше чем systemd ("лучше" - это в смысле "удобнее для
>> пользователя").
> пользователь вообще не лезет в инит. тем более не для того чтоб
> подтюнинговать под свои нужды."пользователь systemd, а не разработчик дистрибутива/systemd".
пользователи бывают разные. например, все системные администраторы.
иногда им приходится прикручивать к серверу сервис, которого нет в дистрибутиве.
>>> всего - нет. но некоторые ситуации, когда systemd удобнее за sysvinit показывает.
>> какие ситуации? покажи их, пусть увидят да прозреют.
> лучше чем Линус Торвальдс я вряд ли скажу:ни ты, ни он так и не сказал какие ситуации. Ну он то ладно, но ты сам ведь начал говорить что некоторые ситуации... взял и снова пропагандировать баттл пошёл)
> 1) не ошибается только тот, кто ничего не делает.
ошибайся в своей песочнице, добр человек. Только не надо впутывать других.
> 2) ломать стабильные релизы RHEL они вряд ли станут.
это должно успокоить дебианщиков :-D
> если честно, bash - это монстр. и я даже 50% его возможностей не знаю.ты и системде не знаешь. ни то, ни другое, отсюда и заинтересованность в пропаганде системде. тебя это не касается.
> "пользователь systemd, а не разработчик дистрибутива/systemd".
это что за каста? любителей знать опции ini-файла системде и незнающие кроме этого больше ничего?
> пользователи бывают разные. например, все системные администраторы.
сисадмин незнающий шелл - бедняга, а не админ. эникей. ему лучше платить редхату или кому-нибудь еще.
> иногда им приходится прикручивать к серверу сервис, которого нет в дистрибутиве.
добавить/удалить сервис еще мелочи. когда нужно будет что-нить посерьёзней, тогда тому сисадмину нужно будет становиться программистом знающим Си.
>>>> всего - нет. но некоторые ситуации, когда systemd удобнее за sysvinit показывает.
>>> какие ситуации? покажи их, пусть увидят да прозреют.
>> лучше чем Линус Торвальдс я вряд ли скажу:
> ни ты, ни он так и не сказал какие ситуации. Ну он
> то ладно, но ты сам ведь начал говорить что некоторые ситуации...например, http://www.opennet.me/openforum/vsluhforumID3/100090.html#102
> взял и снова пропагандировать баттл пошёл)
по большому счету мне всеравно, какой именно системой инициализации будешь
пользоваться ты, дебианщики, убунтоводы, пользоваели freebsd и т.п.что мне не всеравно - я не хочу чтобы кто-то навязывал мне,
какой именно системой инициализации я должен пользоваться.>> 1) не ошибается только тот, кто ничего не делает.
> ошибайся в своей песочнице, добр человек. Только не надо впутывать других.песочница - RHEL/Fedora. этот призыв наверное адресован Поттерингу и Red Hat ?
>> 2) ломать стабильные релизы RHEL они вряд ли станут.
> это должно успокоить дебианщиков :-Dдебианщики могут избрать другой состав TC, который вернет sysvinit в качестве
системы инициализации по умолчанию в Debian, если это им действительно надо.>> если честно, bash - это монстр. и я даже 50% его возможностей не знаю.
> ты и системде не знаешь.на 100% не знаю. но то, что вижу и знаю - мне нравится.
тебе наверное не нравится "Тёмная сторона Силы systemd".> ни то, ни другое, отсюда и заинтересованность в пропаганде системде.
даже после 100% изучения всех возможностей bash - он не станет удобнее systemd.
>> "пользователь systemd, а не разработчик дистрибутива/systemd".
> это что за каста?
>> системные администраторы.
> сисадмин незнающий шелл - бедняга, а не админ.
> эникей. ему лучше платить редхату или кому-нибудь еще.ты уверен, что знаешь наизусть содержимое man bash и все 100% возможностей bash ?
даже если и так, "сисадмин" который знает ТОЛЬКО bash - это не более чем эникей.>> иногда им приходится прикручивать к серверу сервис, которого нет в дистрибутиве.
> добавить/удалить сервис еще мелочи.мелочи. и поэтому лучше на эти мелочи тратить минимум времени и сил.
например, софт который написан на java - он pid-файлы создавать не умеет,
значит надо их делать вручную из инит-скрипта. дальше - при получении команды
service <servicename> start - надо проверить не запущен ли уже этот сервис,
и если запущен - ничего не делать. и вот тут вот начинается самое интересное.
на машине этот сервис не один и какой-то другой процесс может получить тот же
pid, что и вылетевший сервис. но инит-скрипт будет делать вид, что сервис запущен.
как от этого защититься? проверять имя процесса и аргументы командной строки.
а если еще надо запускать сервис не от рута, а другого пользователя...
и т.д. и т.п.получится примерно вот такая портянка:
https://github.com/srvg/sysadmintools/blob/master/java/java-...
- и то здесь реализована только небольшая часть необходимого функционала.> когда нужно будет что-нить посерьёзней, тогда тому
> сисадмину нужно будет становиться программистом знающим Си.не переживай, он справится.
> например, http://www.opennet.me/openforum/vsluhforumID3/100090.html#102снова ложь.
> по большому счету мне всеравно, какой именно системой инициализации будешь
> пользоваться ты, дебианщики, убунтоводы, пользоваели freebsd и т.п.
> что мне не всеравно - я не хочу чтобы кто-то навязывал мне,теперь ты можешь понять пользователей дебиана, рача, гнома, нетворк-манагера ну и т.д.
>[оверквотинг удален]
> service <servicename> start - надо проверить не запущен ли уже этот сервис,
> и если запущен - ничего не делать. и вот тут вот начинается
> самое интересное.
> на машине этот сервис не один и какой-то другой процесс может получить
> тот же
> pid, что и вылетевший сервис. но инит-скрипт будет делать вид, что сервис
> запущен.
> как от этого защититься? проверять имя процесса и аргументы командной строки.
> а если еще надо запускать сервис не от рута, а другого пользователя...
> и т.д. и т.п.какие интересные проблемы. ты просто не осилил pgrep. у него есть все опции что тебе нужно.
> получится примерно вот такая портянка:
> https://github.com/srvg/sysadmintools/blob/master/java/java-...
> - и то здесь реализована только небольшая часть необходимого функционала.приведи пример из дистра красношапки. аргументнее аргумент будет.
> не переживай, он справится.
неа, хомячёк уповающий на поттеринга.
> снова ложь."есть всего два мнения, мое и неправильное" ?
>> по большому счету мне всеравно, какой именно системой инициализации будешь
>> пользоваться ты, дебианщики, убунтоводы, пользоваели freebsd и т.п.
>> что мне не всеравно - я не хочу чтобы кто-то навязывал мне
> теперь ты можешь понять пользователей дебиана, рача, гнома, нетворк-манагера ну и т.д.могу понять. но пользователи дебиана демократично делегировали свое право выбора TC.
>[оверквотинг удален]
>> самое интересное.
>> на машине этот сервис не один и какой-то другой процесс может получить
>> тот же
>> pid, что и вылетевший сервис. но инит-скрипт будет делать вид, что сервис
>> запущен.
>> как от этого защититься? проверять имя процесса и аргументы командной строки.
>> а если еще надо запускать сервис не от рута, а другого пользователя...
>> и т.д. и т.п.
> какие интересные проблемы. ты просто не осилил pgrep.
> у него есть все опции что тебе нужно.pgrep, sed, и еще с десяток утилит командной строки
для создания подпорок, костылей и т.п. заплаток.спасибо, не надо.
This is the Unix philosophy: Write programs that do one thing and do it well.
что мы имеем в сухом остатке: система инициализации sysvinit призвана решать
всего одну задачу - управлять сервисами. но эту задачу она не умеет делать хорошо,
и поэтому приходится использовать большое количество подпорок, костылей, заплаток,
и писать много дополнительного кода на bash для выполнения этой *одной* задачи.для сравнения, systemd с точки зрения пользователя -
соответствует "Unix philosophy" и свою основную задачу выполняет хорошо.выводы:
1) systemd - это unix way
2) sysvinit - это не unix way>> получится примерно вот такая портянка:
>> https://github.com/srvg/sysadmintools/blob/master/java/java-...
>> - и то здесь реализована только небольшая часть необходимого функционала.
> приведи пример из дистра красношапки. аргументнее аргумент будет.так я и говорю о том, что не всегда нужный софт есть в дистрибутиве.
тебе нравится писать такие портянки как в ссылке выше?
пиши. и гордись своим глубоким знанием bash. я ж не против.
> могу понять. но пользователи дебиана демократично делегировали свое право выбора TC.вроде устраивают митинги тех.коммитету)) вообще, бюрократия - серьёзная проблема больших проектов.
> pgrep, sed, и еще с десяток утилит командной строки
> для создания подпорок, костылей и т.п. заплаток.
> спасибо, не надо.даа, да. костылей, подпорок, колясок, и прочие больные метафоры. однако эти костыли уделают на любой дороге твой системде-велосипед. Они тюнингуются в любой местности, под любую задачу. а системде просто включает эти утилиты в себя, в урезанном виде.
> тебе нравится писать такие портянки как в ссылке выше?
ты просто не умеешь в шелл. те кто не умеет - пишут такие простыни.
> пиши. и гордись своим глубоким знанием bash. я ж не против.
я не горжусь знаниями, как и ты не стыдишься незнания.
>> pgrep, sed, и еще с десяток утилит командной строки
>> для создания подпорок, костылей и т.п. заплаток.
>> спасибо, не надо.
> даа, да. костылей, подпорок, колясок, и прочие больные метафоры. однако эти костыли
> уделают на любой дороге твой системде-велосипед.по скорости? не уделают. по удобству использования? тоже нет.
> Они тюнингуются в любой местности, под любую задачу.
"В Линуксе можно настроить ВСЁ — и ты будешь настраивать ВСЁ!"
> а системде просто включает эти утилиты в себя, в урезанном виде.
чего будет вполне достаточно для ~ 99% задач управления сервисами.
для остальных (сложных) задач - можно использовать обычные инит-скрипты, как и раньше.
>> тебе нравится писать такие портянки как в ссылке выше?
> ты просто не умеешь в шелл. те кто не умеет - пишут такие простыни.книжка Classic Shell Scripting by Arnold Robbins and Nelson H. F. Beebe
Copyright © 2005 O’Reilly Media, Inc. подойдет чтобы научиться в шелл ?
> по скорости? не уделают. по удобству использования? тоже нет.и по скорости, и по удобству использования тем более.
>> Они тюнингуются в любой местности, под любую задачу.
> "В Линуксе можно настроить ВСЁ — и ты будешь настраивать ВСЁ!"если хочешь. так лучше.
> чего будет вполне достаточно для ~ 99% задач управления сервисами.
мало у тебя задач. тебе и на 100% хватить может.
> для остальных (сложных) задач - можно использовать обычные инит-скрипты, как и раньше.
а для некоторых вообще невозможно системд использовать.
> Copyright © 2005 O’Reilly Media, Inc. подойдет чтобы научиться в шелл ?
незнаю. смотри скрипты проектов, так и найдёшь лучшее.
>> по скорости? не уделают. по удобству использования? тоже нет.
> и по скорости, и по удобству использования тем более.вряд ли. создание нового процесса - это очень трудоемкий процесс.
при использовании sysvinit их создается достаточно много при старте.
каждый вызов pgrep, sed и т.п. - это продождение нового процесса.>> чего будет вполне достаточно для ~ 99% задач управления сервисами.
> мало у тебя задач. тебе и на 100% хватить может.причем, такая же ситуация и у большей части пользователей Linux.
«Простые вещи должны оставаться простыми, а сложные — стать выполнимыми»
«Easy things should be easy and hard things should be possible»
- https://ru.wikipedia.org/wiki/Perl>> для остальных (сложных) задач - можно использовать обычные инит-скрипты, как и раньше.
> а для некоторых вообще невозможно системд использовать.для некоторых и Linux kernel не подходит.
>>> по скорости? не уделают. по удобству использования? тоже нет.
>> и по скорости, и по удобству использования тем более.
> вряд ли. создание нового процесса - это очень трудоемкий процесс.
> при использовании sysvinit их создается достаточно много при старте.
> каждый вызов pgrep, sed и т.п. - это продождение нового процесса.ExecStart=/bin/bash -c "helper-util && main-binary"
:-D
Да плевать на загрузку, здесь скорость неважный критерий ни на десктопе, ни на сервере. Важна скорость решения, сопровождения, изменения под нужды. Тут у системде проблемы. Сырая сишная портянка с неадекватом у руля непринимающим патчи.
> «Простые вещи должны оставаться простыми, а сложные — стать выполнимыми»
> «Easy things should be easy and hard things should be possible»
> - https://ru.wikipedia.org/wiki/Perl
>>> для остальных (сложных) задач - можно использовать обычные инит-скрипты, как и раньше.
>> а для некоторых вообще невозможно системд использовать.
> для некоторых и Linux kernel не подходит.А инит-{скрипты} продолжит работать и без linux kernel, с другим ядром, с другим ПО.
> А инит-{скрипты} продолжит работать и без linux kernel, с другим ядром, с другим ПО.Для дебиана это может быть и актуально, а для других дистрибутивов - вряд ли.
Кстати, народ в дебиане уже бунтует/митингует и уже начинают кричать "Панду геть!" ?
По крайней мере, давление на TC оказывают моральное очень сильное, так что члены TC
уже не выдерживают этого давления и один за другим оставляют свои посты и уходят.Только у них мало шансов, потому что Debian находится между Red Hat и Ubuntu,
по сути это важный транспотный коридор, чтобы транслировать новые возможности
systemd из RHEL в Ubuntu. В Ubuntu уже приняли решение о переходе на systemd
и заинтересованы в получении этих технологий самым дешевым способом - через Debian.Есть такое мнение, что превращение Debian в зону хаоса очень выгодно другой системе,
которая находится очень далеко от материка Linux, по сути на другом континенте
и там все не как у людей, даже слеши у них и то - в другую сторону повернуты.
> Для дебиана это может быть и актуально, а для других дистрибутивов - вряд ли.это для программы актуально. взамен гибкого, годами проверенного решения работающего от и до - предлагают узконаправленную софтину с архитектурными ограничениями (специально! созданными). И переходить на эту хрень заставляют зависимостями и включением подконтрольных редхату утилит в системде.
>> Для дебиана это может быть и актуально, а для других дистрибутивов - вряд ли.
> это для программы актуально. взамен гибкого, годами проверенного решения
> работающего от и до - предлагают узконаправленную софтину с архитектурными
> ограничениями (специально! созданными). И переходить на эту хрень заставляют
> зависимостями и включением подконтрольных редхату утилит в системде.у sysvinit гибкость такая, что аж слишком. по сути каждый
инит-скрипт - это полноценная программа, хоть и на скриптовом языке.кстати, совет использовать pgrep - это не очень хороший совет,
потому что не факт, что такая утилита будет установлена в системе.
если работать с /proc/$PID напрямую - это гарантированно будет работать всегда.если сравнить Linux и BSD - в чем сила линукса? в том что есть всего одно ядро,
общее для всех. и сколько бы не было дистрибутивов - везед внутри линукс.
BSD - очень много форков. в результате для развития каждого из них не хватает ресурсов.не будет ли замедление скорости развития, если вместо одной основной системы
инициализации сделать несколько десятков, которые будут конкурировать между собой?никто же ведь не возмущается что практически во всех дистрибутивах используется
одно и то же ядро Linux и одна и та же библиотека glibc - наоборот, это хорошо и полезно.
>>> Для дебиана это может быть и актуально, а для других дистрибутивов - вряд ли.
>> это для программы актуально. взамен гибкого, годами проверенного решения
>> работающего от и до - предлагают узконаправленную софтину с архитектурными
>> ограничениями (специально! созданными). И переходить на эту хрень заставляют
>> зависимостями и включением подконтрольных редхату утилит в системде.
> у sysvinit гибкость такая, что аж слишком.да, она есть в отличие от.
> кстати, совет использовать pgrep - это не очень хороший совет,
> потому что не факт, что такая утилита будет установлена в системе.даже не факт что cgroups будет установлена. системде вообще работать не будет, а на шелле ты поедешь дальше не теряя времени сделав просто pgrep-функцию. Даже писать не нужно, в нете найдёшь.
> если работать с /proc/$PID напрямую - это гарантированно будет работать всегда.гибкость. ты можешь использовать несколько путей решения, тот, что нужен именно тебе.
> если сравнить Linux и BSD
нам незачем это делать.
> не будет ли замедление скорости развития, если вместо одной основной системы
> инициализации сделать несколько десятков, которые будут конкурировать между собой?силой навязывать одну, достаточно костыльную - тоже не вариант. пусть победит лучшая, в этом сила открытого и свободного софта, сила свободного сообщества.
>> у sysvinit гибкость такая, что аж слишком.
> да, она есть в отличие от.почему "в отличие от", если точно те же инит-скрипты можно запускать и на systemd ?
systemd - это sysvinit + дополнительный функционал, грубо говоря.по поводу гибкости - не факт. например, если есть какой-то сервис,
который порождает много дочерних процессов - в systemd можно сделать
так, чтобы при останове сервиса все эти процессы тоже убивались.в sysvinit такой гибкости нет. можно написать свою программу на bash,
которая будет сканировать дерево процессов и пытаться это сделать.
но - будут race conditions и надежно такой алгоритм работать не будет.> даже не факт что cgroups будет установлена.
cgroups - это подсистема ядра.
>>> у sysvinit гибкость такая, что аж слишком.
>> да, она есть в отличие от.
> почему "в отличие от", если точно те же инит-скрипты можно запускать и
> на systemd ?потому что инит и скрипты можно запускать там, где системде+инит+скрипты запустить нельзя.
> по поводу гибкости - не факт. например, если есть какой-то сервис,
> который порождает много дочерних процессов - в systemd можно сделать
> так, чтобы при останове сервиса все эти процессы тоже убивались.
> в sysvinit такой гибкости нет. можно написать свою программу на bash,
> которая будет сканировать дерево процессов и пытаться это сделать.
> но - будут race conditions и надежно такой алгоритм работать не будет.ты снова говоришь что не осилил pkill?
>> даже не факт что cgroups будет установлена.
> cgroups - это подсистема ядра.и она может быть не включена.
> инит и скрипты можно запускать там, где системде+инит+скрипты запустить нельзя.в таком случае MS-DOS лучше за Linux,
потому что MS-DOS можно запускать там, где Linux запустить нельзя.>> по поводу гибкости - не факт. например, если есть какой-то сервис,
>> который порождает много дочерних процессов - в systemd можно сделать
>> так, чтобы при останове сервиса все эти процессы тоже убивались.
>> в sysvinit такой гибкости нет. можно написать свою программу на bash,
>> которая будет сканировать дерево процессов и пытаться это сделать.
>> но - будут race conditions и надежно такой алгоритм работать не будет.
> ты снова говоришь что не осилил pkill?а чем pkill тут поможет?
>>> даже не факт что cgroups будет установлена.
>> cgroups - это подсистема ядра.
> и она может быть не включена.и много ты знаешь таких дистрибутивов, в которых включена systemd и выключена cgroups ?
>> инит и скрипты можно запускать там, где системде+инит+скрипты запустить нельзя.
> в таком случае MS-DOS лучше за Linux,
> потому что MS-DOS можно запускать там, где Linux запустить нельзя.только инит+скрипты могут всё что может системде и больше, а мсдос нет.
> а чем pkill тут поможет?
pkill + ps поможет остановить процессы.
> и много ты знаешь таких дистрибутивов, в которых включена systemd и выключена cgroups ?
и много ты видел дистрибутивов в которых включен пульсаудио и выключена альса?
> инит+скрипты могут всё что может системде и большебез комментариев
>> а чем pkill тут поможет?
> pkill + ps поможет остановить процессы.не поможет, как минимум будет race condition
>> инит+скрипты могут всё что может системде и больше
> без комментариевсистемде не может все то, что может инит+скрипты.
вот.>>> а чем pkill тут поможет?
>> pkill + ps поможет остановить процессы.
> не поможет, как минимум будет race conditionа как максимум? ну же, застращай!
>>>> а чем pkill тут поможет?
>>> pkill + ps поможет остановить процессы.
>> не поможет, как минимум будет race condition
> а как максимум?достаточно и того, что как минимум.
и что самое интересное - корректного решения этой задачи,
если нет использовать cgroups похоже что нет.а если использовать cgroups - то это у нас в конечном итоге
получится systemd, который будет написан не на С а на bash.
>>>>> а чем pkill тут поможет?
>>>> pkill + ps поможет остановить процессы.
>>> не поможет, как минимум будет race condition
>> а как максимум?
> достаточно и того, что как минимум.да, достаточно манов не читать, чтоб случилось что угодно.
> и что самое интересное - корректного решения этой задачи,
> если нет использовать cgroups похоже что нет.панацея, да. а еще cgroups доступен только из системде.
> а если использовать cgroups - то это у нас в конечном итоге получится systemd, который будет написан не на С а на bash.
получится то что ты захочешь чтоб получилось. а не то, что безумный поттеринг задумал.
>>>>> pkill + ps поможет остановить процессы.
>>>> не поможет, как минимум будет race condition
>>> а как максимум?
>> достаточно и того, что как минимум.
> да, достаточно манов не читать, чтоб случилось что угодно.каким образом pkill + ps + "чтение манов" поможет избежать race condition ?
напомню условие задачи:
есть процесс X, который время от времени запускает дочерние процессы.
задача: убить процесс X и всего его дочерние процессы.
>>>>>> pkill + ps поможет остановить процессы.
>>>>> не поможет, как минимум будет race condition
>>>> а как максимум?
>>> достаточно и того, что как минимум.
>> да, достаточно манов не читать, чтоб случилось что угодно.
> каким образом pkill + ps + "чтение манов" поможет избежать race condition ?каким и много лет до этого.
> напомню условие задачи:
> есть процесс X, который время от времени запускает дочерние процессы.
> задача: убить процесс X и всего его дочерние процессы.с SID, PPID, PGID и божьей помощью я это сделаю.
>> условие задачи:
>> есть процесс X, который время от времени запускает дочерние процессы.
>> задача: убить процесс X и всего его дочерние процессы.
> с SID, PPID, PGID и божьей помощью я это сделаю.убиваемый процесс не создает новую сессию и свою группу процессов.
>>> условие задачи:
>>> есть процесс X, который время от времени запускает дочерние процессы.
>>> задача: убить процесс X и всего его дочерние процессы.
>> с SID, PPID, PGID и божьей помощью я это сделаю.
> убиваемый процесс не создает новую сессию и свою группу процессов.тогда тем более.
> тогда тем более.все понятно, вопросов больше нет.
> все понятно, вопросов больше нет.прочитал ман наконец? давно бы так.
>> все понятно, вопросов больше нет.
> прочитал ман наконец?нет, просто понял что по сути вопроса ты ничего ответить не можешь.
> cgroups - это подсистема ядра.Опцинальная. Как и ntfs.ko и ещё over9000 "подсистем".
> если сравнить Linux и BSD - в чем сила линукса? в том что есть всего одно ядро, общее для всех.Разных версий. С нестабильным ABI и системным API.
> и сколько бы не было дистрибутивов - везед внутри линукс.
Бывает лишь одно название, а поверх наворочено такого... андроида.
> BSD - очень много форков. в результате для развития каждого из них не хватает ресурсов.
Я знаю только два форка: FreeBSD и OpenBSD. Остальные — чисто экспериментальные.
Зато дистрибутивов линукса...> не будет ли замедление скорости развития, если вместо одной основной системы инициализации сделать несколько десятков, которые будут конкурировать между собой?
Десяток коммерческих дистрибутивов линукса опровергли факт замедления развития: развития уже давно нет, но изобретаются альтернативы существующим подсистемам в *.nix ОС по типу SystemD и KMS.
> никто же ведь не возмущается что практически во всех дистрибутивах используется
> одно и то же ядро Linux и одна и та же библиотека
> glibc - наоборот, это хорошо и полезно.В Google Android с ядром Linux glibc не используется.
>> если сравнить Linux и BSD - в чем сила линукса? в том что есть всего одно ядро
> Разных версий. С нестабильным ABI и системным API.Изя, учите матчасть и не повторяйте чушь за совсем неграмотными.
>> BSD - очень много форков.
> Я знаю только два форка: FreeBSD и OpenBSD. Остальные — чисто экспериментальные.
> Зато дистрибутивов линукса...Такие же "знатоки" щас скажут, что знают только редхат и дебиан. :)
>>> если сравнить Linux и BSD - в чем сила линукса? в том что есть всего одно ядро
>> Разных версий. С нестабильным ABI и системным API.
> ИзяДавай без переиначиваний ников, хорошо? Ты знаешь, я не люблю и себе не позволяю. И только в крайних случаях, когда всё безнадёжно. arisu простительно, но тебе...
> Давай без переиначиваний ников, хорошо? Ты знаешь, я не люблю и себе
> не позволяю. И только в крайних случаях, когда всё безнадёжно.Именно такой случай и произошёл -- насколько помню, Вам User294 чуть ли не лекцию читал на тему линуксовых API/ABI. Ну или спросите разработчиков фряшного ядра, как они охарактеризуют сравнительную стабильность интерфейсов ядер фри и линукса внутри и наружу.
Т.е. я-то согласен, но и Вас прошу не доходить до такой безнадёги. Чешется язык -- порой лучше чаю заварить, чем жмакнуть в "отправить".
>> Зато дистрибутивов линукса...
> Такие же "знатоки" щас скажут, что знают только редхат и дебиан. :)Oracle Linux, CentOS — это всё дистрибутивы Red Hat Linux, только пропатчены и подписаны другими. FreeBSD может оперировать пакетами Red Hat и включать их в работу в линуксуляторе.
Debian и Ubuntu — родственные души, несовместимые с Red Hat чуть более, чем полностью.
Gentoo, Slackware, Arch линуксы — другая вселенная.
>> если сравнить Linux и BSD - в чем сила линукса?
>> в том что есть всего одно ядро, общее для всех.
> Разных версий. С нестабильным ABI и системным API.внутреннее kernel API/ABI и не должно быть стабильным, его видят только модули ядра.
>> и сколько бы не было дистрибутивов - везед внутри линукс.
> Бывает лишь одно название, а поверх наворочено такого... андроида.да. в том то и дело. ядро - это самая сложная часть операционной системы.
вот GNU Hurd уже сколько десятков лет пилят, а воз и ныне там.стоимость разработки ядра Linux исчисляется уже миллиардами долларов
и огромным количеством человеко-часов. в линуксе мы видим кумулятивный эффект.тот же андроид - это не отдельная ос, это тоже линукс,
и свои патчи и наработки они возвращают в основное ядро.впрочем, есть еще один важный аспект - лицензия.
GPL vs BSD. например, компания apple может легко утащить исходники
и на их базе сделать коммерческий продукт с закрытыми исходниками.с Linux так не получится, и все кто работал над ядром,
- все они возвращают свои наработки в основную ветку.>> BSD - очень много форков. в результате для развития каждого из них не хватает ресурсов.
> Я знаю только два форка: FreeBSD и OpenBSD. Остальные — чисто экспериментальные.NetBSD - это та ос, на основе чего была создана OpenBSD и отдельный форк ядра.
https://ru.wikipedia.org/wiki/Список_BSD-систем
Активные главные BSD-системы
Dragonfly BSD
FreeBSD
NetBSD
OpenBSD> Зато дистрибутивов линукса...
много. но ядро всего одно.
>> не будет ли замедление скорости развития, если вместо одной основной системы инициализации сделать несколько десятков, которые будут конкурировать между собой?
> Десяток коммерческих дистрибутивов линукса опровергли факт замедления развития:потому что все они пилят одно и то же ядро. например, такие компании,
как Red Hat, Oracle, Google, Samsung, Intel, ... которые в обычных условиях
являются конкурентами - здесь работают вместе для улучшения одного и того же ядра.> развития уже давно нет но изобретаются альтернативы существующим
> подсистемам в *.nix ОС по типу SystemD и KMS.а где есть развитие, в BSD ?
Много ли коммерческие пользователи вернули кода в основную ветку системы?
>> никто же ведь не возмущается что практически во всех дистрибутивах используется
>> одно и то же ядро Linux и одна и та же библиотека
>> glibc - наоборот, это хорошо и полезно.
> В Google Android с ядром Linux glibc не используется.по сравнению с ядром, glibc - совсем не сложная часть ос.
>>> если сравнить Linux и BSD - в чем сила линукса?
>>> в том что есть всего одно ядро, общее для всех.
>> Разных версий. С нестабильным ABI и системным API.
> внутреннее kernel API/ABI и не должно быть стабильным, его видят только модули ядра.Вот поэтому, наверное, нужно ждать выхода графического драйвера под новое ядро, а старый драйвер в большинстве случаев не работает или работает с глюками. (Если что, я имею в виду проприетарные решения, где используются модули ядра от сторонних производителей)
> стоимость разработки ядра Linux исчисляется уже миллиардами долларов
> и огромным количеством человеко-часов. в линуксе мы видим кумулятивный эффект.
> тот же андроид - это не отдельная ос, это тоже линукс,
> и свои патчи и наработки они возвращают в основное ядро.
> впрочем, есть еще один важный аспект - лицензия.
> GPL vs BSD. например, компания apple может легко утащить исходники
> и на их базе сделать коммерческий продукт с закрытыми исходниками.У CISCO в своё время силой вырывали пропатченные исходники Linux. Другие компании как-то тоже не сразу выкладывают модифицированные исходники Linux в публичный доступ.
> с Linux так не получится, и все кто работал над ядром, - все они возвращают свои наработки в основную ветку.
Спустя какое-то время...
>>> BSD - очень много форков. в результате для развития каждого из них не хватает ресурсов.
>> Я знаю только два форка: FreeBSD и OpenBSD. Остальные — чисто экспериментальные.
> NetBSD - это та ос, на основе чего была создана OpenBSD и отдельный форк ядра.Я же говорю: от NetBSD произошли все современные *BSD. Но реально используются в продакшене только две - FreeBSD и OpenBSD. И ещё куча закрытых *BSD во встраиваемых вариантах, о которых мы ещё не знаем, но от них во FreeBSD, к примеру, приходит новый код, который влияет на подсистемы ОС, увеличивает функциональность в отдельном аспекте использования. И всё это независимо от лицензии - по доброй воле собственника кода.
> https://ru.wikipedia.org/wiki/Список_BSD-систем
> Активные главные BSD-системы
> Dragonfly BSD
> FreeBSD
> NetBSD
> OpenBSDЭто всё? Наконец-то. Теперь покажи области применения каждой из них.
>> Зато дистрибутивов линукса...
> много. но ядро всего одно.Ядер линукса также много, соседние версии несовместимы с системным ПО (принято по умолчанию).
FreeBSD поддерживает обратную совместимость запуска программ, сделанных ещё для 4-ой версии!> потому что все они пилят одно и то же ядро. например, такие
> компании,
> как Red Hat, Oracle, Google, Samsung, Intel, ... которые в обычных условиях
> являются конкурентами - здесь работают вместе для улучшения одного и того же
> ядра.
>> развития уже давно нет но изобретаются альтернативы существующим
>> подсистемам в *.nix ОС по типу SystemD и KMS.
> а где есть развитие, в BSD ?Смотри ежеквартальные отчёты о развитии FreeBSD. Для Linux такое почему-то пишут очень редко, а в последний год-два вообще что-то глухо.
> Много ли коммерческие пользователи вернули кода в основную ветку системы?
Что значит "вернули"? Открытый код нельзя просто так взять, а потом вернуть. Они добавляют в систему новый исходный код, который начинают сопровождать заинтересованные разработчики.
>>> никто же ведь не возмущается что практически во всех дистрибутивах используется
>>> одно и то же ядро Linux и одна и та же библиотека
>>> glibc - наоборот, это хорошо и полезно.
>> В Google Android с ядром Linux glibc не используется.
> по сравнению с ядром, glibc - совсем не сложная часть ос.Дело не в сложности, а в специализации.
>> внутреннее kernel API/ABI и не должно быть стабильным, его видят только модули ядра.
> Вот поэтому, наверное, нужно ждать выхода графического драйвера под новое ядро,
> а старый драйвер в большинстве случаев не работает или работает с глюками.
> (Если что, я имею в виду проприетарные решения, где используются модули
> ядра от сторонних производителей)Разумеется. Еще есть EXPORT_SYMBOL и EXPORT_SYMBOL_GPL, чтобы с помощью
"мягкой силы" "заставить" писателей драйверов выложить свой код под GPL.Это политическое решение, чтобы производители проприетарных драйверов поняли,
что им проще и удобнее сделать свой код open source и не носиться с BLOB`ами.>> GPL vs BSD. например, компания apple может легко утащить исходники
>> и на их базе сделать коммерческий продукт с закрытыми исходниками.
> У CISCO в своё время силой вырывали пропатченные исходники Linux. Другие компании
> как-то тоже не сразу выкладывают модифицированные исходники Linux в публичный доступ.если бы исходники ядра были под лицензией BSD -
тогда у CISCO вообще ничего не получилось бы вырвать.>> с Linux так не получится, и все кто работал над ядром,
>> - все они возвращают свои наработки в основную ветку.
> Спустя какое-то время...лучше поздно, чем никогда.
>>>> BSD - очень много форков. в результате для развития каждого из них не хватает ресурсов.
>>> Я знаю только два форка: FreeBSD и OpenBSD. Остальные — чисто экспериментальные.
>> NetBSD - это та ос, на основе чего была создана OpenBSD и отдельный форк ядра.
> Я же говорю: от NetBSD произошли все современные *BSD.FreeBSD произошла от 386BSD.
> Но реально используются в продакшене только две - FreeBSD и OpenBSD.
NetBSD разве нигде и никем не используется ?
Кстати, NetBSD - это тоже форк 386BSD.
> И ещё куча закрытых *BSD во встраиваемых вариантах, о которых мы ещё не знаем,
> но от них во FreeBSD, к примеру, приходит новый код, который
> влияет на подсистемы ОС, увеличивает функциональность в отдельном аспекте использования.
> И всё это независимо от лицензии - по доброй воле собственника кода.Дело не в доброй воле. Собственник оценивает стоимость поддержки форка своими силами
и ценность этого кода. Если получается что дешевле вернуть код в основную ветку - так и делает.То есть, FreeBSD - это по сути базовый код для прошивок маршрутизаторов Juniper.
http://www.opennet.me/opennews/art.shtml?num=33358>> https://ru.wikipedia.org/wiki/Список_BSD-систем
>> Активные главные BSD-системы
>> Dragonfly BSD
>> FreeBSD
>> NetBSD
>> OpenBSD
> Это всё? Наконец-то. Теперь покажи области применения каждой из них.я в сортах BSD не разбираюсь, и какие у них области использования - тоже не в курсе.
просто обращаю внимание, что есть четрые основных ветки и это четыре разных ядра.
в результате разработчики вынуждены делать в 4 раза больше работы, создавая
подсистемы с нуля или занимаясь портированием кода туда и обратно.
если бы это было одно ядро - оно развивалось бы в 4 раза быстрее.>>> Зато дистрибутивов линукса...
>> много. но ядро всего одно.
> Ядер линукса также много, соседние версии несовместимы с системным ПО (принято по умолчанию).это одно и то же ядро линукса, просто разных версий. например,
во всех дистрибутивах используется та же файловая система XFS и тот же сетевой стек.> FreeBSD поддерживает обратную совместимость запуска программ, сделанных ещё для 4-ой версии!
Solaris имеет еще более качественную обратную совместимость, но это ему не очень сильно помогло.
>>> развития уже давно нет но изобретаются альтернативы существующим
>>> подсистемам в *.nix ОС по типу SystemD и KMS.
>> а где есть развитие, в BSD ?
> Смотри ежеквартальные отчёты о развитии FreeBSD. Для Linux такое почему-то пишут очень
> редко, а в последний год-два вообще что-то глухо.FreeBSD - операционная система, Linux - ядро операционной системы.
Если сравнивать, то лучше сравнивать, например, FreeBSD и RHEL.https://access.redhat.com/documentation/en-US/Red_Hat_Enterp.../
> kill -HUP [pid]На практике так не делают, а пишут файлик для logrotate.
> Правильное решение этой проблемы - узнать (man inittab).Причем это описывается в мане даже самого monit. В самом начале.
> После сЫстемДы - 100% значит.и гнома, и кде, и прочего. Просто используй хорошие программы, а не всякий шит.
> Проиграли линуксоиды,
я не проиграл.
> все мечтали финдоузь разгромит
я не мечтал.
> да прощёлкали казачка то :-(
да пох на плохие программы. просто используй хорошие.
> После сЫстемДы - 100% значит.Не подскажете, где он на gnu.org?
У микрософт такого нет!
Да, суровая программулина...
согласен сурово. а нельзя было просто шеллом? типа echo "Hello world" ? и накрутить ему qt-шную гую и все прибамбасы чтоб еще медленнее было))) или там принцип только c/c++))) шелл и есть юникс вей)))
/* hello.c -- print a greeting message and exit.Copyright 1992, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2005,
2006, 2007, 2008, 2010, 2011, 2013, 2014 Free Software Foundation,
Inc.This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */#include <config.h>
#include "system.h"
#include "errno.h"
#include "error.h"
#include "progname.h"
#include "xalloc.h"static const struct option longopts[] = {
{"greeting", required_argument, NULL, 'g'},
{"help", no_argument, NULL, 'h'},
{"traditional", no_argument, NULL, 't'},
{"version", no_argument, NULL, 'v'},
{NULL, 0, NULL, 0}
};/* Forward declarations. */
static void print_help (void);
static void print_version (void);int
main (int argc, char *argv[])
{
int optc;
int lose = 0;
const char *greeting_msg;
wchar_t *mb_greeting;
size_t len;set_program_name (argv[0]);
/* Set locale via LC_ALL. */
setlocale (LC_ALL, "");#if ENABLE_NLS
/* Set the text message domain. */
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
#endif/* Having initialized gettext, get the default message. */
greeting_msg = _("Hello, world!");/* Even exiting has subtleties. On exit, if any writes failed, change
the exit status. The /dev/full device on GNU/Linux can be used for
testing; for instance, hello >/dev/full should exit unsuccessfully.
This is implemented in the Gnulib module "closeout". */
atexit (close_stdout);while ((optc = getopt_long (argc, argv, "g:htv", longopts, NULL)) != -1)
switch (optc)
{
/* --help and --version exit immediately, per GNU coding standards. */
case 'v':
print_version ();
exit (EXIT_SUCCESS);
break;
case 'g':
greeting_msg = optarg;
break;
case 'h':
print_help ();
exit (EXIT_SUCCESS);
break;
case 't':
greeting_msg = _("hello, world");
break;
default:
lose = 1;
break;
}if (lose || optind < argc)
{
/* Print error message and exit. */
error (0, 0, "%s: %s", _("extra operand"), argv[optind]);
print_help ();
}len = mbsrtowcs(NULL, &greeting_msg, 0, NULL);
if (len == (size_t)-1)
error (EXIT_FAILURE, errno, _("conversion to a multibyte string failed"));
mb_greeting = xmalloc((len + 1) * sizeof(wchar_t));
mbsrtowcs(mb_greeting, &greeting_msg, len + 1, NULL);/* Print greeting message and exit. */
wprintf (L"%ls\n", mb_greeting);
free(mb_greeting);exit (EXIT_SUCCESS);
}
/* Print help info. This long message is split into
several pieces to help translators be able to align different
blocks and identify the various pieces. */static void
print_help (void)
{
/* TRANSLATORS: --help output 1 (synopsis)
no-wrap */
printf (_("\
Usage: %s [OPTION]...\n"), program_name);/* TRANSLATORS: --help output 2 (brief description)
no-wrap */
fputs (_("\
Print a friendly, customizable greeting.\n"), stdout);puts ("");
/* TRANSLATORS: --help output 3: options 1/2
no-wrap */
fputs (_("\
-h, --help display this help and exit\n\
-v, --version display version information and exit\n"), stdout);puts ("");
/* TRANSLATORS: --help output 4: options 2/2
no-wrap */
fputs (_("\
-t, --traditional use traditional greeting\n\
-g, --greeting=TEXT use TEXT as the greeting message\n"), stdout);printf ("\n");
/* TRANSLATORS: --help output 5+ (reports)
TRANSLATORS: the placeholder indicates the bug-reporting address
for this application. Please add _another line_ with the
address for translation bugs.
no-wrap */
printf (_("\
Report bugs to: %s\n"), PACKAGE_BUGREPORT);
#ifdef PACKAGE_PACKAGER_BUG_REPORTS
printf (_("Report %s bugs to: %s\n"), PACKAGE_PACKAGER,
PACKAGE_PACKAGER_BUG_REPORTS);
#endif
#ifdef PACKAGE_URL
printf (_("%s home page: <%s>\n"), PACKAGE_NAME, PACKAGE_URL);
#else
printf (_("%s home page: <http://www.gnu.org/software/%s/>\n"),
PACKAGE_NAME, PACKAGE);
#endif
fputs (_("General help using GNU software: <http://www.gnu.org/gethelp/>\n"),
stdout);
}
/* Print version and copyright information. */static void
print_version (void)
{
printf ("%s (%s) %s\n", PACKAGE, PACKAGE_NAME, VERSION);
/* xgettext: no-wrap */
puts ("");/* It is important to separate the year from the rest of the message,
as done here, to avoid having to retranslate the message when a new
year comes around. */
printf (_("\
Copyright (C) %d Free Software Foundation, Inc.\n\
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n\
This is free software: you are free to change and redistribute it.\n\
There is NO WARRANTY, to the extent permitted by law.\n"), COPYRIGHT_YEAR);
}
Кроме кода там ещё всякая "обвязка". На самом деле -- эдакий шаблон. Хорошо.
Предлагаю замутить на его основе фреймворк для хелловорлдов.
> Предлагаю замутить на его основе фреймворк для хелловорлдов.(apt-get | yum | zypper) install autoproject
switch (optc) так и надо , чтобы навыворот?
{
case "v":
print_version();
case "h":
print_help();
}
"for instance, hello >/dev/full should exit"Опаньки, опечатка. Можно выпускать следующую версию
Ждем ускорения чрез GPU
> Ждем ускорения чрез GPU
// This is the REAL "hello world" for CUDA!
// It takes the string "Hello ", prints it, then passes it to CUDA with an array
// of offsets. Then the offsets are added in parallel to produce the string "World!"
// By Ingemar Ragnemalm 2010
#include <stdio.h>
const int N = 16;
const int blocksize = 16;
__global__
void hello(char *a, int *b)
{
a[threadIdx.x] += b[threadIdx.x];
}
int main()
{
char a[N] = "Hello \0\0\0\0\0\0";
int b[N] = {15, 10, 6, 0, -11, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
char *ad;
int *bd;
const int csize = N*sizeof(char);
const int isize = N*sizeof(int);
printf("%s", a);
cudaMalloc( (void**)&ad, csize );
cudaMalloc( (void**)&bd, isize );
cudaMemcpy( ad, a, csize, cudaMemcpyHostToDevice );
cudaMemcpy( bd, b, isize, cudaMemcpyHostToDevice );
dim3 dimBlock( blocksize, 1 );
dim3 dimGrid( 1, 1 );
hello<<<dimGrid, dimBlock>>>(ad, bd);
cudaMemcpy( a, ad, csize, cudaMemcpyDeviceToHost );
cudaFree( ad );
cudaFree( bd );
printf("%s\n", a);
return EXIT_SUCCESS;
}
kernel (hello.cl)__kernel void hello(__global char* string)
{
string[0] = 'H';
string[1] = 'e';
string[2] = 'l';
string[3] = 'l';
string[4] = 'o';
string[5] = ',';
string[6] = ' ';
string[7] = 'W';
string[8] = 'o';
string[9] = 'r';
string[10] = 'l';
string[11] = 'd';
string[12] = '!';
string[13] = '\0';
}host (hello.c)
#include <stdio.h>
#include <stdlib.h>
#ifdef __APPLE__
#include <OpenCL/opencl.h>
#else
#include <CL/cl.h>
#endif
#define MEM_SIZE (128)
#define MAX_SOURCE_SIZE (0x100000)
int main()
{
cl_device_id device_id = NULL;
cl_context context = NULL;
cl_command_queue command_queue = NULL;
cl_mem memobj = NULL;
cl_program program = NULL;
cl_kernel kernel = NULL;
cl_platform_id platform_id = NULL;
cl_uint ret_num_devices;
cl_uint ret_num_platforms;
cl_int ret;
char string[MEM_SIZE];
FILE *fp;
char fileName[] = "./hello.cl";
char *source_str;
size_t source_size;
/* Load the source code containing the kernel*/
fp = fopen(fileName, "r");
if (!fp) {
fprintf(stderr, "Failed to load kernel.\n");
exit(1);
}
source_str = (char*)malloc(MAX_SOURCE_SIZE);
source_size = fread(source_str, 1, MAX_SOURCE_SIZE, fp);
fclose(fp);
/* Get Platform and Device Info */
ret = clGetPlatformIDs(1, &platform_id, &ret_num_platforms);
ret = clGetDeviceIDs(platform_id, CL_DEVICE_TYPE_DEFAULT, 1, &device_id, &ret_num_devices);
/* Create OpenCL context */
context = clCreateContext(NULL, 1, &device_id, NULL, NULL, &ret);
/* Create Command Queue */
command_queue = clCreateCommandQueue(context, device_id, 0, &ret);
/* Create Memory Buffer */
memobj = clCreateBuffer(context, CL_MEM_READ_WRITE,MEM_SIZE * sizeof(char), NULL, &ret);
/* Create Kernel Program from the source */
program = clCreateProgramWithSource(context, 1, (const char **)&source_str,
(const size_t *)&source_size, &ret);
/* Build Kernel Program */
ret = clBuildProgram(program, 1, &device_id, NULL, NULL, NULL);
/* Create OpenCL Kernel */
kernel = clCreateKernel(program, "hello", &ret);
/* Set OpenCL Kernel Parameters */
ret = clSetKernelArg(kernel, 0, sizeof(cl_mem), (void *)&memobj);
/* Execute OpenCL Kernel */
ret = clEnqueueTask(command_queue, kernel, 0, NULL,NULL);
/* Copy results from the memory buffer */
ret = clEnqueueReadBuffer(command_queue, memobj, CL_TRUE, 0,
MEM_SIZE * sizeof(char),string, 0, NULL, NULL);
/* Display Result */
puts(string);
/* Finalization */
ret = clFlush(command_queue);
ret = clFinish(command_queue);
ret = clReleaseKernel(kernel);
ret = clReleaseProgram(program);
ret = clReleaseMemObject(memobj);
ret = clReleaseCommandQueue(command_queue);
ret = clReleaseContext(context);
free(source_str);
return 0;
}
Скачал, поставил, полет отличной
> Скачал, поставил, полет отличнойУже в продакшене или в стэйдже тестишь?
Новая версия, урашечки! Ща заценим
Когда ебилды будут?
Я сначала тоже ржал, пока скачивал. Но внутре вобщем-то зачотный скелетон, если чо.
> Я сначала тоже ржал, пока скачивал. Но внутре вобщем-то зачотный скелетон, если чо.Внутре шкафа? Ать-ать-ать! :)
Хмм, хороший пример.
Для такой простой программы, выводящий текст в stdout, они умудрились ещё подключить отличные от stdio.h хидеры и вставить кучу лишнего мусора, справку и прокомментировать всё это. Они совсем кислородом не дышат ?
Уметь надо!
Нужно было новость начинать со слов: "после 13 месяцев разработки представлена новая версия ..."
> Нужно было новость начинать со слов: "после 13 месяцев разработки представлена новая версия ..."Ага, со слов: "После 13 месяцев молчания увидела свет новая версия ...". И первый комментарий к новости: "'Hello, world' от глухонемых?".
Исправлено множество ошибок...
Ну через 20 лет и тут найдут багу которая была впилена в релизе?
Напишу для особых оленеводов. Это не программа для вывода надписи, а пример/шаблон как нужно делать свои проекты, как оформлять и т.д.
% pkg info -d hello-2.9
hello-2.9
Depends on :
indexinfo-0.2
gettext-0.18.3.1_1% pkg info -l hello-2.9
hello-2.9:
/usr/local/bin/hello
/usr/local/info/hello.info
/usr/local/man/man1/hello.1.gz
/usr/local/share/locale/bg/LC_MESSAGES/hello.mo
/usr/local/share/locale/ca/LC_MESSAGES/hello.mo
/usr/local/share/locale/da/LC_MESSAGES/hello.mo
/usr/local/share/locale/de/LC_MESSAGES/hello.mo
/usr/local/share/locale/el/LC_MESSAGES/hello.mo
/usr/local/share/locale/eo/LC_MESSAGES/hello.mo
/usr/local/share/locale/es/LC_MESSAGES/hello.mo
/usr/local/share/locale/et/LC_MESSAGES/hello.mo
/usr/local/share/locale/eu/LC_MESSAGES/hello.mo
/usr/local/share/locale/fa/LC_MESSAGES/hello.mo
/usr/local/share/locale/fi/LC_MESSAGES/hello.mo
/usr/local/share/locale/fr/LC_MESSAGES/hello.mo
/usr/local/share/locale/ga/LC_MESSAGES/hello.mo
/usr/local/share/locale/gl/LC_MESSAGES/hello.mo
/usr/local/share/locale/he/LC_MESSAGES/hello.mo
/usr/local/share/locale/hr/LC_MESSAGES/hello.mo
/usr/local/share/locale/hu/LC_MESSAGES/hello.mo
/usr/local/share/locale/id/LC_MESSAGES/hello.mo
/usr/local/share/locale/it/LC_MESSAGES/hello.mo
/usr/local/share/locale/ja/LC_MESSAGES/hello.mo
/usr/local/share/locale/ka/LC_MESSAGES/hello.mo
/usr/local/share/locale/ko/LC_MESSAGES/hello.mo
/usr/local/share/locale/lv/LC_MESSAGES/hello.mo
/usr/local/share/locale/ms/LC_MESSAGES/hello.mo
/usr/local/share/locale/nb/LC_MESSAGES/hello.mo
/usr/local/share/locale/nl/LC_MESSAGES/hello.mo
/usr/local/share/locale/nn/LC_MESSAGES/hello.mo
/usr/local/share/locale/pl/LC_MESSAGES/hello.mo
/usr/local/share/locale/pt/LC_MESSAGES/hello.mo
/usr/local/share/locale/pt_BR/LC_MESSAGES/hello.mo
/usr/local/share/locale/ro/LC_MESSAGES/hello.mo
/usr/local/share/locale/ru/LC_MESSAGES/hello.mo
/usr/local/share/locale/sk/LC_MESSAGES/hello.mo
/usr/local/share/locale/sl/LC_MESSAGES/hello.mo
/usr/local/share/locale/sr/LC_MESSAGES/hello.mo
/usr/local/share/locale/sv/LC_MESSAGES/hello.mo
/usr/local/share/locale/th/LC_MESSAGES/hello.mo
/usr/local/share/locale/tr/LC_MESSAGES/hello.mo
/usr/local/share/locale/uk/LC_MESSAGES/hello.mo
/usr/local/share/locale/vi/LC_MESSAGES/hello.mo
/usr/local/share/locale/zh_CN/LC_MESSAGES/hello.mo
/usr/local/share/locale/zh_TW/LC_MESSAGES/hello.mo% locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_ALL=ru_RU.UTF-8% hello
Hello, world!Локализацию поддерживает только для 8-битных кодировок.
Попробуем так:
% setenv LC_ALL ru_RU.KOI8-R
% locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.KOI8-R"
LC_COLLATE="ru_RU.KOI8-R"
LC_TIME="ru_RU.KOI8-R"
LC_NUMERIC="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES="ru_RU.KOI8-R"
LC_ALL=ru_RU.KOI8-R
% hello
Hello, world!% setenv LANG ru_RU.KOI8-R
% locale
LANG=ru_RU.KOI8-R
LC_CTYPE="ru_RU.KOI8-R"
LC_COLLATE="ru_RU.KOI8-R"
LC_TIME="ru_RU.KOI8-R"
LC_NUMERIC="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES="ru_RU.KOI8-R"
LC_ALL=ru_RU.KOI8-R
% hello
hello: ������� �� �������.Ждём порт 2.10.
Бедная фришка! даже hello и та работает в урезанном виде, это карма!
> Бедная фришка! даже hello и та работает в урезанном виде, это карма!Ну еще бы: LC_ALL=ru_RU.KOI8-R - скелетон увидел в этой некромансии конкуренцию.
% locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_ALL=ru_RU.UTF-8
% setenv LC_ALL ru_RU.KOI8-R
% setenv LANG ru_RU.KOI8-R
% locale
LANG=ru_RU.KOI8-R
LC_CTYPE="ru_RU.KOI8-R"
LC_COLLATE="ru_RU.KOI8-R"
LC_TIME="ru_RU.KOI8-R"
LC_NUMERIC="ru_RU.KOI8-R"
LC_MONETARY="ru_RU.KOI8-R"
LC_MESSAGES="ru_RU.KOI8-R"
LC_ALL=ru_RU.KOI8-R
% hello
Hello, world!Не хочет переводить на русский.
> Не хочет переводить на русский.Потому что в 2014 году кои8 пользуются только полные утырки.
> Потому что в 2014 году кои8 пользуются только полные утырки.Т. е. ты пользуешься KOI7?
> Потому что в 2014 году кои8 пользуются только полные утырки.Гнутые? У меня везде ru_RU.UTF-8, а эти выкатили переводы для 8-битных кодировок.
> меня везде ru_RU.UTF-8, а эти выкатили переводы для 8-битных кодировок.Не поверишь! но там тоже используется UTF-8!!!
Вангую! libc во фришке в части локализации по прежнему кривая :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767172лол. Надо сделать что-то типа следующего, чтобы заработало:
diff --git a/src/hello.c b/src/hello.c
index 8c36915..ff30bd1 100644
--- a/src/hello.c
+++ b/src/hello.c
@@ -47,7 +47,7 @@ main (int argc, char *argv[])
{
int optc;
int lose = 0;
- const char *greeting_msg = _("Hello, world!");
+ const char *greeting_msg;
wchar_t *mb_greeting;
size_t len;
greeting_type g = greet_traditional;
@@ -63,6 +63,8 @@ main (int argc, char *argv[])
textdomain (PACKAGE);
#endif
+ greeting_msg = _("Hello, world!");
+
/* Even exiting has subtleties. On exit, if any writes failed,
change the exit status. The /dev/full device on GNU/Linux can be used
for testing; for instance, hello >/dev/full should exit unsuccessfully.
> - const char *greeting_msg = _("Hello, world!");
> + const char *greeting_msg;…
> + greeting_msg = _("Hello, world!");Тогда уж const надо убрать, а то запись в константу greeting_msg
>> - const char *greeting_msg = _("Hello, world!");
>> + const char *greeting_msg;
> …
>> + greeting_msg = _("Hello, world!");
> Тогда уж const надо убрать, а то запись в константу greeting_msgНе, константой ведь объявляется не указатель, а память на которую указатель указует. Там ведь не char* const greeting_msg написано.
Для работы нужен systemd?
Надо проводить аудит кода на наличие скрытых закладок слежения за пользователем :)
> Надо проводить аудит кода на наличие скрытых закладок слежения за пользователем :)А ты думаешь КУДА она копию вывода шлёт!?!?! Враг знает что ты видишь! :)))))
Неужели Столламну? Да, хороший враг всегда прячется там, где никому и в гойлову не прийдёт искать...
Вот до чего Идеология доводит.
> Вот до чего Идеология доводит.Как ни странно, программа на самом деле достаточно неплохой пример.
И до чего же она доводит?
В качестве шелла для некоторых будет самое оно...
>[оверквотинг удален]
> эталон оформления кода программ GNU, который демонстрирует методы использования Gettext
> для перевода сообщений на различные языки, показывает как обрабатывать аргументы командной
> строки и пользоваться сборочным инструментарием.
> По сравнению с прошлым выпуском в версии 2.10 основной текст 'Hello, World'
> оформлен через файлы переводов, задействованы методы нерекурсивной сборки, представлен
> пример добавления секций в man-руководство, вместо fprintf (stderr) задействована libc-функций
> 'error()', добавлен вызов 'make
> update-copyright', обеспечено формировние ChangeLog из лога коммитов в git.
> URL: http://savannah.gnu.org/forum/forum.php?forum_id=8146
> Новость: http://www.opennet.me/opennews/art.shtml?num=41066Господа, неужели это он (в смысле вендекапец)?!
Когда сделают настройку скрыть анонимные комментарии? Противно читать opennet.
Что интерестно, сами исходники (т.е. если считать только папку src) в gnu hello всего 123 строки, но если считать все файлы, то 38793 строк, из которых 18681 - sh-скрипт, а 8855 - m4
Лучше бы они написали либу, которая выдаёт hello world, и привели пример всей autotools-машинерии, чтобы её собрать, а также тест-программку, которая дёрнет эту функцию оттуда.
