systemd
Всем привет. Внезапно я поставил себе дебиан на десктоп и решил посмотреть есть ли жизнь на systemd. Я видел https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.ru.html https://wiki.debian.org/systemd#Installing_without_systemd но этого как-то мало. Что нужно читать про использование дебиана с systemd? Как теперь настраивать сеть? Почему и кто трогает мой /etc/resolv.conf при 'ifup eno1' если # cat /etc/network/interfaces | grep -v '^#' auto lo iface lo inet loopback allow-hotplug eno1 iface eno1 inet static address 192.168.33.8/24 gateway 192.168.33.1 (Там появляется ipv6 nameserver, но iface eno1 inet6 auto я закомментировал) Откуда берутся названия интерфейсов и почему они самопроизвольно меняюся? Вначале были enp6s0 и enp7s0, потом они превратились в enp7s0 и enp8s0 (или 8 и 9, уже не помню), а теперь eno1 и eno2. Что ещё не так, помимо сети? За systemd будущее, стоит тратить на него время и изучать _или_ место systemd рядом с hal и defvs, надо срочно снести его, забыть, и подождать пока дебиан вернёт всё как было с следующему выпуску? -- sergio
Re: systemd
On 11/11/2015 02:34 PM, sergio wrote: > https://wiki.debian.org/systemd#Installing_without_systemd должно быть https://wiki.debian.org/systemd -- sergio
Re: systemd
> Откуда берутся названия интерфейсов и почему они самопроизвольно > меняюся? Вначале были enp6s0 и enp7s0, потом они превратились в enp7s0 и > enp8s0 (или 8 и 9, уже не помню), а теперь eno1 и eno2. https://lists.debian.org/debian-devel/2015/06/msg00018.html
Re: systemd
В сообщении от [Ср 2015-11-11 14:34 +0300] sergio пишет: > Что нужно читать про использование дебиана с systemd? Начните с главной страницы [1], если английский напрягает, то сперва читайте и смотрите всё где стоит 'Russian'. Потом исходя из своих потребностей, будете выбирать то что нужно. > Откуда берутся названия интерфейсов и почему они самопроизвольно > меняюся? Вначале были enp6s0 и enp7s0, потом они превратились в enp7s0 и > enp8s0 (или 8 и 9, уже не помню), а теперь eno1 и eno2. > > Что ещё не так, помимо сети? Ответ на ваш вопрос на 96 странице этой книги [2], в ней собраны переводы статей Поттеринга. > За systemd будущее, стоит тратить на него время и изучать Да, изучать стоит. [1]: https://wiki.freedesktop.org/www/Software/systemd/ [2]: http://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf -- Коротаев Руслан http://blog.kr.pp.ru/
Re: systemd
sergio -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 14:34:40 +0300: s> место systemd рядом с hal и defvs, надо срочно снести его, забыть, и s> подождать пока дебиан вернёт всё как было с следующему выпуску? Я пока придерживаюсь этой точки зрения. Не уверен за "как было" - devfs был не просто выкинут, а заменен на udev, но есть шансы, что этому глюкалу к следующему stable все-таки найдут более вменяемую замену. Ну, или придется признать вырождение debian и дружно мигрировать на gentoo.
Re: systemd
On Wed, Nov 11, 2015 at 02:34:40PM +0300, sergio wrote: > Почему и кто трогает мой /etc/resolv.conf при 'ifup eno1' если Можно установить такую растяжку: chattr +i /etc/resolv.conf strace -e open,fork,execve -f /sbin/ifup eno1 и смотреть кто подорвётся на обращении к /etc/resolv.conf. :) > Откуда берутся названия интерфейсов и почему они самопроизвольно > меняюся? Вначале были enp6s0 и enp7s0, потом они превратились в enp7s0 и > enp8s0 (или 8 и 9, уже не помню), а теперь eno1 и eno2. Прямо в /etc/network/interfaces меняются? Или в живой системе? Если в системе, то, возможно, это из-за свежего udev'а, который (судя по манам) всё больше и больше срастается с systemd. Мне пришлось зафиксировать udev 224 там, где его новые версии разносят систему, но какая именно система пострадает, а какая нет -- понять не удаётся. Почти все мои машины с одним интерфейсом апгрейд пережили, а где несколько сетевушек -- везде пришлось откатиться. -- Eugene Berdnikov
Re: systemd
s>> место systemd рядом с hal и defvs, надо срочно снести его, забыть, и s>> подождать пока дебиан вернёт всё как было с следующему выпуску? > Я пока придерживаюсь этой точки зрения. Не уверен за "как было" - devfs > был не просто выкинут, а заменен на udev, но есть шансы, что этому > глюкалу к следующему stable все-таки найдут более вменяемую замену. +1 я hal, dbus, pulseaudio и прочую муть просто переждал пока сама не сдохнет. с systemd тоже самое будет: Debian проголосовали конечно (хотя там конечно формулировка была такая что systemd не мог не пройти), однако подумали подумали и вот уже grub например вставляет item'ы про SysV, и дальше SysV никуда не денется ибо systemd это УГ только про линукс, а Debian это не только Linux > Ну, или придется признать вырождение debian и дружно мигрировать на > gentoo. в генте тоже systemd у кого-нибудь кстати есть объяснение почему этот systemd так везде пихают? у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять зачем я увы не могу. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
> Заговор, не иначе ) > Очевидно, что раз открытые проекты добровольно выбирают это решение, значит > оно > лучше других. я думаю причина объясняется так: разработчики Gnome/KDE зачем-то поставили зависимость на systemd а майнтенерам лень ее отрезать. зависимость поставлена видимо потому что упомянутые ацтои содержат в себе некоторые системные "админки" вроде "настроить сеть" итп. > Чем именно надо спрашивать у тех кто выбирает, но мне например, > нравится интерфейс systemd (как нравится интерфейс wajig'а), нравится идея > journald. Из аргументированных минусов только привязка к linux, но это думаю > со > временем поправят, была даже попытка. бинарные логи - зло в чистом виде. прямой привет из ада а в Unix лет этак 30 с гаком есть syslog, который умеет и логи реплицировать на другие хосты и логи склеивать/сплитить итп итд. зачем нужен идиотский бинарный формат логов и отдельная к ним прибамбасина - ума не приложу -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
11 ноября 2015 г., 17:03 пользователь Dmitry E. Oboukhov написал: > у кого-нибудь кстати есть объяснение почему этот systemd так везде > пихают? > у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять > зачем я увы не могу. Да в общем-то тут не надо быть семью пядями. Есть ряд подсистем, которые раньше работали независимо, а теперь пришли к пониманию, что они должны быть взаимосвязаны. Пока одни рассуждали как это сделать, другой взял и сделал. Из того, что приходит в голову первым: появились всякие wifi, прочие PAN'ы и VPN'ы, а значит юзеру понадобилась возможность конфигурить сетевые интерфейсы роутинг и так далее, без консоли и sudo. Так появился первый предвестник - network manager. Потом начались всякие приблуды с примаунчиванием томов по USB, правами доступа к этим томам. Захотелось увязать это всё с наличием юзера в системе - типа вышел юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться. Или допустим другой вопрос: стоит ли давать удалённому юзеру возможность маунтить локальные флэшки? Если нет, то нужно как-то определять, какой юзер локальный, а какой удаленный, кому показывать notification с предложением примаунтить флэшку? И вот уже связь: сетевая подсистема и файловая связывается с понятием сессия пользователя или даже сессия локального пользователя. Раньше никто не запаривался, потому как это не свойственно для серверов, где железо (и интерфейсы) не появляются и исчеазают каждые 5 минут, но теперь-то у нас вроде как и десктопная ОС тоже. Кроме того, появились хитрые требования к запуску, остановке, перезапуску служб и зависимостей. Захотелось параллельности. И так далее. И вот Поттеринг взял и написал это, ни с кем не обсуждая, но как-то работающее. А те, кто кричит, что systemd не нужен, так и застряли на уровне обсуждения того, как всё будет стройно, когда мы это придумаем, или тупо игнорируют то, что необходимость в реформе назрела. Сильно упрощая можно уподобить этот процесс флеймвару между монолитом и микроядром, где первое - это systemd, а второе old school (SysV, sudo, /etc/interfaces и конфиги). Ещё можно вспомнить как кривой и плохой TCP/IP победил красивый и академичный сетевой стэк ISO/OSI. Таких примеров тьма-тьмущая. Участвовать в их обсуждении считаю не нужным. Либо ты плывешь по течению, либо делаешь своими руками сам и убеждаешь, что оно лучше. "оно не нужно", "закапывайте обратно" - это всё только для ЛОРа. -- With best regards Max Dmitrichenko
Re: systemd
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 17:03:47 +0300: >> Ну, или придется признать вырождение debian и дружно мигрировать на >> gentoo. DEO> в генте тоже systemd Насколько я знаю, в генте _можно_ собраться с systemd. А можно и без него. Вплоть до того (но тут уже не уверен), что можно оторвать, не помню, кто у нас намертво привязан, consolekit, что ли, от systemd-login. Или гном от consolekit. У нас-то, собственно, чуть ли не всего одна паразитная зависимость в дистрибутиве, которая тянет systemd-login и всю структуру systemd, если хочешь поставить какую-нибудь DE. Ну, в stable. Судя по тому, что тут пишет Женя, в unstable ситуация уже хуже. DEO> у кого-нибудь кстати есть объяснение почему этот systemd так везде DEO> пихают? DEO> у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять DEO> зачем я увы не могу. Я наблюдаю некий заказ, не факт, что осознаваемый разработчиками, на фактическое прикрытие Open Source по принципу "не только в коде, но и в настройке не должен быть способен разобраться почти никто". Такой vendor lock не мытьем, так катаньем. С gtk и гномом я это пронаблюдал уже несколько лет назад, и судя по письмам тут, ситуация с тех пор становится все хуже. Затем они начали лочить на DBus с его бинарным API изрядную часть системных инструментов. Ну а systemd - это прям подарок. Группа процессов в сердце системы, которую лихо сращивают с тем же gnome - и привет, любая установка линукса тянет за собой весь гном.
Re: systemd
Не скажу что я фанат systemd, не буду его продавать, но не очень понимаю всеобщей ненависти к нему. Как-то почитал про него какую-то ссылку (непомню, вроде http://tlhp.cf/sia1/) и мне всё вполне понравилось. On Ср, ноя 11, 2015 в 5:45 , Dmitry E. Oboukhov wrote: я думаю причина объясняется так: разработчики Gnome/KDE зачем-то поставили зависимость на systemd а майнтенерам лень ее отрезать. Опять же, gnome/kde крупные проекты, не думаю что мы будем обвинять их в некомпетентности, они раньше как-то обходились без systemd и приложили усилия чтобы на него перейти, видимо есть резон бинарные логи - зло в чистом виде. прямой привет из ада формат логов это же мелочь, systemd имеет кучу интересных фич, journald например вроде как умеет делать цифровые подписи логам для защиты от модификации. А параллельная загрузка? А крутая фича которой нам так нехватало - процесс от которого зависят другие процессы может дать явный сигнал что он готов к работе. Например redis должен слать такой сигнал когда подгрузил данные с диска, иначе демоны зависимые от него стартуют, а он ещё не готов, без systemd такое только костылями можно делать. А переход на конфиги? Это же ацкий костыль что скрипты инициализации пишутся на баше, по сути на универсальном языке программирования, это избыточно и явно минус с точки зрения безопасности, а ещё говорят что systemd зависит от всяких ненужных вещей, а система инициализации зависящая от шела это норм?
Re: systemd
Руслан Коротаев -> РК Alex Mestiashvili -> AM >> Откуда берутся названия интерфейсов и почему они самопроизвольно >> меняюся? Вначале были enp6s0 и enp7s0, потом они превратились в enp7s0 и >> enp8s0 (или 8 и 9, уже не помню), а теперь eno1 и eno2. РК> Ответ на ваш вопрос на 96 странице этой книги [2], в ней собраны РК> переводы статей Поттеринга. AM > https://lists.debian.org/debian-devel/2015/06/msg00018.html Ничего не понял. Где именно ответ на мой вопрос на 96 странице? Вот у меня мать, на ней _припаяно_ два сетевых интерфейса. Больше никаких других сетевых интерфейсов нет. Я поставил дебиан, названия были enp6s0 и enp7s0, потом, совершенно внезапно, они стали называтся enp7s0 и enp8s0, а потом eno1 и eno2. Предсказуемые имена? -- sergio
Re: systemd
Как-то так, нашлись только одни герои которые попытались сделать лучше, но ненадолго хватило их задора http://uselessd.darknedgy.net On Ср, ноя 11, 2015 в 5:52 , Max Dmitrichenko wrote: И вот Поттеринг взял и написал это, ни с кем не обсуждая, но как-то работающее. А те, кто кричит, что systemd не нужен, так и застряли на уровне обсуждения того, как всё будет стройно, когда мы это придумаем,
Re: systemd
Max Dmitrichenko -> Dmitry E. Oboukhov @ Wed, 11 Nov 2015 17:52:07 +0300: MD> И вот Поттеринг взял и написал это, ни с кем не обсуждая, но как-то MD> работающее. А те, кто кричит, что systemd не нужен, так и застряли на MD> уровне обсуждения того, как всё будет стройно, когда мы это придумаем, MD> или тупо игнорируют то, что необходимость в реформе назрела. Сильно MD> упрощая можно уподобить этот процесс флеймвару между монолитом и MD> микроядром, где первое - это systemd, а второе old school (SysV, sudo, MD> /etc/interfaces и конфиги). Ещё можно вспомнить как кривой и плохой MD> TCP/IP победил красивый и академичный сетевой стэк ISO/OSI. Таких MD> примеров тьма-тьмущая. Участвовать в их обсуждении считаю не нужным. MD> Либо ты плывешь по течению, либо делаешь своими руками сам и MD> убеждаешь, что оно лучше. "оно не нужно", "закапывайте обратно" - это MD> всё только для ЛОРа. Понимаешь, в чем разница... Не скажу за TCP, а монолитное ядро стали включать в дистрибутивы ОС только после того, как оно заработало лучше, чем то, что там было раньше. (Ну да, если быть совсем уж точным, то на замену юниксам пришел весь комплект GNU/Linux, но идея как раз в том, что он лучше работал.) Что-то я подозреваю, что TCP/IP выиграл у ISO/OSI по другой причине - наличия реализации у первого и отсутствия у второго, а вот у конкурентов вроде IPX - именно тем, что лучше работал. IPX годился только для локальных сетей, к задержкам и потерям пакетов относился весьма нервно. А вот в случае с systemd заменяют надежное, пусть и далекое от идеала по архитектуре, более близким к идеалу по идее (по архитектуре, кстати, боюсь, не получилось), но безнадежно глючащим. Идея рубить сук, на котором сидишь, мне не импонирует. Одним из основных маркетинговых преимуществ линукса, в т.ч. и на десктопах, до сих пор была по сравнению с виндой бОльшая надежность. (А с MacOS X - бОльшая свобода за меньшие деньги; надежностью там нижний уровень от FreeBSD заведует, у него с этим тоже все в порядке. Но шаг влево, шаг вправо стоит дорого.) Если мы теряем сразу и надежность, и дешевые шаги влево-вправо, то мы проигрываем на обоих фронтах сразу.
Re: systemd
On 11/11/15 10:33, Artem Chuprina wrote: > Я наблюдаю некий заказ, не факт, что осознаваемый разработчиками, на > фактическое прикрытие Open Source по принципу "не только в коде, но и в > настройке не должен быть способен разобраться почти никто". Такой > vendor lock не мытьем, так катаньем. С gtk и гномом я это пронаблюдал > уже несколько лет назад, и судя по письмам тут, ситуация с тех пор > становится все хуже. > > Затем они начали лочить на DBus с его бинарным API изрядную часть > системных инструментов. > > Ну а systemd - это прям подарок. Группа процессов в сердце системы, > которую лихо сращивают с тем же gnome - и привет, любая установка > линукса тянет за собой весь гном. > "прикрытие Open Source" сильно сказано. На мой взгляд люди готовы открыть исходники, но хотят заработать на этом. Они делают сложные системы и готовы помочь с настройкой (за деньги) У пользователя есть возможность открыть исходники и попытаться понять что программа делает, изменить ее поведение, если нужно, скомпилировать обратно. Насколько я помню, именно отсутствие исходников побудило Столманна на бунт, вылившийся в FSF. Теперь пожалуйста - исходники есть, разбирайся, делай форк, Усложнение программ неизбежно. Open Source эволюционирует. все что выше ИМХО, конечно. Тимур smime.p7s Description: S/MIME Cryptographic Signature
Re: systemd
On 11/11/15 08:18, Eugene Berdnikov wrote: > и смотреть кто подорвётся на обращении к /etc/resolv.conf. :) dhclient и подорвется см /etc/dhcp/dhclient.conf smime.p7s Description: S/MIME Cryptographic Signature
Re: systemd
On Wed, Nov 11, 2015 at 06:33:14PM +0300, Artem Chuprina wrote: > > Ну а systemd - это прям подарок. Группа процессов в сердце системы, > которую лихо сращивают с тем же gnome - и привет, любая установка > линукса тянет за собой весь гном. Ну это просто не так. systemd позволил выкинуть кучу костылей из gnome, но обратной то зависимости нет. Наоборот создается инфраструктура, которая все заботы связанные с сессиями берет на себя, как-раз позволяя ограничиться простым WM.
Re: systemd
Tim Sattarov -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 11:33:43 -0500: >> Я наблюдаю некий заказ, не факт, что осознаваемый разработчиками, на >> фактическое прикрытие Open Source по принципу "не только в коде, но и в >> настройке не должен быть способен разобраться почти никто". Такой >> vendor lock не мытьем, так катаньем. С gtk и гномом я это пронаблюдал >> уже несколько лет назад, и судя по письмам тут, ситуация с тех пор >> становится все хуже. >> >> Затем они начали лочить на DBus с его бинарным API изрядную часть >> системных инструментов. >> >> Ну а systemd - это прям подарок. Группа процессов в сердце системы, >> которую лихо сращивают с тем же gnome - и привет, любая установка >> линукса тянет за собой весь гном. >> TS> "прикрытие Open Source" сильно сказано. TS> На мой взгляд люди готовы открыть исходники, но хотят заработать на этом. TS> Они делают сложные системы и готовы помочь с настройкой (за деньги) TS> У пользователя есть возможность открыть исходники и попытаться понять TS> что программа делает, изменить ее поведение, если нужно, скомпилировать TS> обратно. TS> Насколько я помню, именно отсутствие исходников побудило Столманна на TS> бунт, вылившийся в FSF. TS> Теперь пожалуйста - исходники есть, разбирайся, делай форк, TS> Усложнение программ неизбежно. Open Source эволюционирует. TS> все что выше ИМХО, конечно. Исходники были в те времена, когда создавался FSF. Сейчас разобраться в исходниках гнома _пользователь_, даже если он хороший программист, может только если будет заниматься этим fulltime. Это уже чисто формально открытые исходники. Можно писать проще, если делать это не на самых низкоуровневых из высокоуровневых языков, а на чем-нибудь поприличнее.
Re: systemd
Иван Лох -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 20:24:55 +0300: >> Ну а systemd - это прям подарок. Группа процессов в сердце системы, >> которую лихо сращивают с тем же gnome - и привет, любая установка >> линукса тянет за собой весь гном. ИЛ> Ну это просто не так. systemd позволил выкинуть кучу костылей из gnome, ИЛ> но обратной то зависимости нет. Наоборот создается инфраструктура, ИЛ> которая все заботы связанные с сессиями берет на себя, как-раз позволяя ИЛ> ограничиться простым WM. Вот уж не уверен... Я двадцать лет ограничиваюсь простым WM и за все двадцать лет ни разу не нуждался в услугах DE. Я все-таки прогнозирую, что скоро срастят. Насколько я помню, сейчас уже в нескольких местах, не в одном bluez, нету не-гномовских юзерских интерфейсов к подсистемам. У нас уже пароли кэшировать норовит гномовская приблуда, аж svn, запущенный из командной строки, ее дергает. Не документированная, кстати, почти совершенно. Система хранения и кэширования паролей. Не документирована. Так что срастить systemd с гномом в обратную сторону - раз плюнуть. Логи у него уже бинарные, сделать бинарными еще и конфиги, не документировать формат, и конфигурилку сделать только гномовскую.
Re: systemd
On Wed, Nov 11, 2015 at 10:16:50PM +0300, Artem Chuprina wrote: > > Можно писать проще, если делать это не на самых низкоуровневых из > высокоуровневых языков, а на чем-нибудь поприличнее. Это про Vala или javascript?
Re: systemd
On Wed, Nov 11, 2015 at 10:26:16PM +0300, Artem Chuprina wrote: > ИЛ> Ну это просто не так. systemd позволил выкинуть кучу костылей из gnome, > ИЛ> но обратной то зависимости нет. Наоборот создается инфраструктура, > ИЛ> которая все заботы связанные с сессиями берет на себя, как-раз позволяя > ИЛ> ограничиться простым WM. > > Вот уж не уверен... Я двадцать лет ограничиваюсь простым WM и за все > двадцать лет ни разу не нуждался в услугах DE. > > Я все-таки прогнозирую, что скоро срастят. Насколько я помню, сейчас > уже в нескольких местах, не в одном bluez, нету не-гномовских юзерских > интерфейсов к подсистемам. У нас уже пароли кэшировать норовит > гномовская приблуда, аж svn, запущенный из командной строки, ее дергает. > Не документированная, кстати, почти совершенно. Система хранения и > кэширования паролей. Не документирована. Кстати, gnome-keyring-daemon единственная гномовская программа, которую я использую. Удобно же для всех браузеров иметь одно защищенное хранилище паролей. И, да, для mutt и git тоже ))) С документацией там, правда, не очень. Только что касается ключей это обычный ssh и gnupg agent, а от хранилища паролей ничего кроме secret-tool не требуется обычно. > Логи у него уже бинарные, сделать бинарными еще и конфиги, не > документировать формат, и конфигурилку сделать только гномовскую. Ну так у гнома (dconf) конфиги по-умолчанию бинарные )))
Re: systemd
11.11.2015 19:40, Tim Sattarov пишет: > On 11/11/15 08:18, Eugene Berdnikov wrote: >> и смотреть кто подорвётся на обращении к /etc/resolv.conf. :) > dhclient и подорвется > см /etc/dhcp/dhclient.conf > Но зачем он там, если в interfaces прописано static? -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: systemd
On 11/11/2015 04:18 PM, Eugene Berdnikov wrote: > Можно установить такую растяжку: > >chattr +i /etc/resolv.conf Ну я так и сделал. >strace -e open,fork,execve -f /sbin/ifup eno1 > > и смотреть кто подорвётся на обращении к /etc/resolv.conf. :) Только это не поможет. Виноват был rdnssd. > Прямо в /etc/network/interfaces меняются? Или в живой системе? При перезагрузке, сами названия, network/interfaces никто не трогает. > Если в системе, то, возможно, это из-за свежего udev'а, который > (судя по манам) всё больше и больше срастается с systemd. Мне пришлось > зафиксировать udev 224 там, где его новые версии разносят систему, > но какая именно система пострадает, а какая нет -- понять не удаётся. Я поставил sid в октябре. Судя по https://packages.qa.debian.org/s/systemd.html я мог видеть только 227-2, 227-1, 226-4. Если я не ошибаюсь, то последнее переименование enpXsY -> enoX произошло после обновления биоса. Вообще это какая-то надуманная проблема. Все интерфейсы которые важны я называю сам, а на остальные насрать. Даже наоборот, хочется не фиксированных имён для всех остальных. Ну то есть что бы usb сетевушка воткнутая первой была usb0. -- sergio.
Re: systemd
> 11.11.2015 19:40, Tim Sattarov пишет: >> dhclient и подорвется >> см /etc/dhcp/dhclient.conf Может ты и есть dhclient, раз так уверен, что подорвется? > Но зачем он там, если в interfaces прописано static? И правда, зачем? -- sergio
Re: systemd
В Thu, 12 Nov 2015 02:50:15 +0300 sergio пишет: > On 11/11/2015 04:18 PM, Eugene Berdnikov wrote: > > Если я не ошибаюсь, то последнее переименование enpXsY -> enoX > произошло после обновления биоса. > > > Вообще это какая-то надуманная проблема. Все интерфейсы которые важны > я называю сам, а на остальные насрать. Даже наоборот, хочется не > фиксированных имён для всех остальных. Ну то есть что бы usb сетевушка > воткнутая первой была usb0. Проблема не надуманая, проблема из-за реализации PCI device enumeration которая приводила к тому, что при следующей загрузке сетевые карты могли быть обнаружены в другом порядке. Что могло привести к недоступности машины с двумя сетевыми картами после перезагрузки. Решили что внезапное изменение порядка сетевых карт хуже, чем переименование интерфейса при замене единственной карты - там у тебя хотя бы есть причина озаботиться тем, что могут потребоваться изменения. А придумать более хорошего алгоритма никто не смог. -- Victor Wagner
Re: systemd
On 11/12/2015 08:21 AM, Victor Wagner wrote: > Проблема не надуманая, проблема из-за реализации PCI device enumeration > которая приводила к тому, что при следующей загрузке сетевые карты > могли быть обнаружены в другом порядке. Что могло привести к > недоступности машины с двумя сетевыми картами после перезагрузки. Я знаю хороший алгоритм --- хэш от мака. Хочешь нормальное название открой map файл и пропиши там строчку в формате "mac name". -- sergio
Re: systemd
11 ноября 2015 г., 19:28 пользователь Artem Chuprina написал: > Понимаешь, в чем разница... Не скажу за TCP, а монолитное ядро стали > включать в дистрибутивы ОС только после того, как оно заработало лучше, > чем то, что там было раньше. Я, наверное, что-то пропустил, но разве были такие open source ОС, которые сменили микроядро на монолит? > (Ну да, если быть совсем уж точным, то на > замену юниксам пришел весь комплект GNU/Linux, но идея как раз в том, > что он лучше работал.) Что-то я подозреваю, что TCP/IP выиграл у > ISO/OSI по другой причине - наличия реализации у первого и отсутствия у > второго, а вот у конкурентов вроде IPX - именно тем, что лучше работал. > IPX годился только для локальных сетей, к задержкам и потерям пакетов > относился весьма нервно. Ну, если проводить аналогии между стэками и init'ами, то IPX - это таки upstart. Хороший конкурент systemd, но лишенный части функциональности, которая всем дистростроителям вдруг оказалась нужна. А sysV в этой истории - это вообще соединение по нуль-модемному кабелю ) Таким образом, ISO/OSI в этой истории продолжает соответствовать некой гипотетической рассово, идейно и архитектурно верной системе init, реализации которой мы не увидим никогда ) > А вот в случае с systemd заменяют надежное, пусть и далекое от идеала по > архитектуре, более близким к идеалу по идее (по архитектуре, кстати, > боюсь, не получилось), но безнадежно глючащим. Идея рубить сук, на > котором сидишь, мне не импонирует. > Одним из основных маркетинговых > преимуществ линукса, в т.ч. и на десктопах, до сих пор была по сравнению > с виндой бОльшая надежность. (А с MacOS X - бОльшая свобода за меньшие > деньги; надежностью там нижний уровень от FreeBSD заведует, у него с > этим тоже все в порядке. Но шаг влево, шаг вправо стоит дорого.) > > Если мы теряем сразу и надежность, и дешевые шаги влево-вправо, то мы > проигрываем на обоих фронтах сразу. > -- With best regards Max Dmitrichenko
Re: systemd
On Thu, Nov 12, 2015 at 02:50:15AM +0300, sergio wrote: > Вообще это какая-то надуманная проблема. Все интерфейсы которые важны я > называю сам, а на остальные насрать. Даже наоборот, хочется не > фиксированных имён для всех остальных. Ну то есть что бы usb сетевушка > воткнутая первой была usb0. А кому-то не понравится именование по типу шины, и захочется именование по типу среды: eth5, wlan2, bt0 и т.д. И он будет по-своему прав. Проблема с udev не в том, что он стал вычурно именовать интерфейсы, и не в том, что их имена иногда меняются. Проблема в том, что старые добрые конфигурации из /etc/udev/rules.d кое-где перестали работать, несмотря на на наличие там файликов от предыдущих инкарнаций, где имена были чётко привязаны к mac-адресам сетевушек. Кроме того, иногда при замене сетевушки новый udev не спасает её данные в /etc/udev/rules.d/. Эта гармонично дополняется тем, что в дебиане по умолчанию логгирование действий udev'а отключено, и когда критичная для жизни подсистема ошибается, причину этого впоследствии понять невозможно. Для диагностики нужна пересборка initrd и/или пляски с --debug за консолью. -- Eugene Berdnikov
Re: systemd
>>> Ну, или придется признать вырождение debian и дружно мигрировать на >>> gentoo. DEO>> в генте тоже systemd > Насколько я знаю, в генте _можно_ собраться с systemd. А можно и без > него. ну дык и в Debian _можно_ его не устанавливать. вопрос тут в том что поставят ли зависимость с xorg на systemd или нет. если не поставят, то и можно будет на Debian/Gentoo жить без него, если поставят - тут нужно будет думать в любом дистре > Ну, в stable. Судя по тому, что тут пишет Женя, в unstable ситуация уже > хуже. я не обновлялся еще до последнего unstable, но парумесячной давности пока без systemd у меня живет. щас там резко переколбасили xorg: перенесли его полностью в userspace и поэтому теперь есть проблемы в работе xdm (и вообще всего X'ового, запускающегося от root) DEO>> у кого-нибудь кстати есть объяснение почему этот systemd так везде DEO>> пихают? DEO>> у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять DEO>> зачем я увы не могу. > Я наблюдаю некий заказ, не факт, что осознаваемый разработчиками, на > фактическое прикрытие Open Source по принципу "не только в коде, но и в > настройке не должен быть способен разобраться почти никто". Такой > vendor lock не мытьем, так катаньем. С gtk и гномом я это пронаблюдал > уже несколько лет назад, и судя по письмам тут, ситуация с тех пор > становится все хуже. > Затем они начали лочить на DBus с его бинарным API изрядную часть > системных инструментов. да кстати, DBus в целом идея нормальная, но блин бинарный протокол все портит -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
>> у кого-нибудь кстати есть объяснение почему этот systemd так везде >> пихают? >> у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять >> зачем я увы не могу. > Да в общем-то тут не надо быть семью пядями. Есть ряд подсистем, > которые раньше работали независимо, а теперь пришли к пониманию, что > они должны быть взаимосвязаны. Пока одни рассуждали как это сделать, > другой взял и сделал. > Из того, что приходит в голову первым: появились всякие wifi, прочие > PAN'ы и VPN'ы, а значит юзеру понадобилась возможность конфигурить > сетевые интерфейсы роутинг и так далее, без консоли и sudo. я, увы, не понимаю зачем для конфига wifi, pan, vpn надо переколбашивать /sbin/init. вот wifi: у нас был (и есть) отличный демон, управляемый из консоли, из сокета - кому как нравится: хочешь подключить к Wifi - подключай, хочешь отключить - отключай. зачем тут модифицированный /sbin/init? > Так > появился первый предвестник - network manager. Потом начались всякие > приблуды с примаунчиванием томов по USB, правами доступа к этим томам. вроде нарисовался вполне себе тру-вей на этот гребанный автомаунт: udev в связке с тем же dbus, далее показывай себе окошки в ответ на всовывание девайса. но нет, зачем-то понадобилось переписывать /sbin/init. я не вижу обоснования - зачем? sudo не нравится? ну дык напишите свой gnome-su, блин, пусть работает по таким правилам как вам нравится > Захотелось увязать это всё с наличием юзера в системе - типа вышел > юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться. ну дык все эти гномы/kde работают поверх каких-то gdm/kdm. запуск/логин юзеров в них происходит. далее никаких проблем нет управлять тасками atexit > Или допустим другой вопрос: стоит ли давать удалённому юзеру > возможность маунтить локальные флэшки? Если нет, то нужно как-то > определять, какой юзер локальный, а какой удаленный, кому показывать > notification с предложением примаунтить флэшку? тут я тоже не вижу необходимости переписывать /sbin/init, поясните зачем это понадобилось? > И вот уже связь: > сетевая подсистема и файловая связывается с понятием сессия > пользователя или даже сессия локального пользователя. Раньше никто не > запаривался, потому как это не свойственно для серверов, где железо (и > интерфейсы) не появляются и исчеазают каждые 5 минут, но теперь-то у > нас вроде как и десктопная ОС тоже. вот именно - десктопная. мой разнесчастный десктоп апгрейдится с 1998-го года (с Debian/potato). проблемы с апгрейдом у меня начали появляться только как systemd стали вкручивать. > Кроме того, появились хитрые > требования к запуску, остановке, перезапуску служб и зависимостей. > Захотелось параллельности. И так далее. дык на эту тему давно работа проведена, загляните в любой скрипт /etc/init.d там в заголовке шапка: от чего зависит и после чего запускаться должен -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
Случайно нажал отправить, не дописав ответ. 11 ноября 2015 г., 19:28 пользователь Artem Chuprina написал: > А вот в случае с systemd заменяют надежное, пусть и далекое от идеала по > архитектуре, более близким к идеалу по идее (по архитектуре, кстати, > боюсь, не получилось), но безнадежно глючащим. Всё же мне чисто субъективно кажется, что бОльшая часть проблем с systemd в данный момент из-за того, что мы не умеем его готовить, а не из-за реальных глюков. Штука новая, большая, с кондочка не освоить за бутылочкой пива. А тот, кто разобрался и знает, очевидно, видит в нём преимущества и продвигает его в том дистре, в разработке которого он участвует. > Идея рубить сук, на > котором сидишь, мне не импонирует. Идея консерватизма тоже даёт сбои. Давай, вспомним, как медленно развивающий XFree86 превратился в бурно развивающийся X.org (если оставить за скобками повод в изменении лицензии). Всё-таки мне кажется, что заядлым консерваторам место где-то в районе между NetBSD и OpenBSD ) > Одним из основных маркетинговых > преимуществ линукса, в т.ч. и на десктопах, до сих пор была по сравнению > с виндой бОльшая надежность. Ну не знаю за все дистры не скажу, но дебиан с маркетингом связан слабо. Я не знаю наверняка, но подозреваю, что если бы в команде DD нашелся человек, который сказал бы "я буду нести на себе крест, по поддержке SysV и гарантирую работу всех пакетов, у которых есть инит-скрипт, с обеими системами", то никто бы не возражал. Но как всегда, видимо, дальше разговоров о том, что systemd - плохой и ненужный, дело не пошло. -- With best regards Max Dmitrichenko
Re: systemd
12 ноября 2015 г., 11:55 пользователь Dmitry E. Oboukhov написал: > вроде нарисовался вполне себе тру-вей на этот гребанный автомаунт: > udev в связке с тем же dbus, далее показывай себе окошки в ответ на > всовывание девайса. но нет, зачем-то понадобилось переписывать > /sbin/init. я не вижу обоснования - зачем? > sudo не нравится? > ну дык напишите свой gnome-su, блин, пусть работает по таким правилам > как вам нравится А вот никто не хочет решать этот вопрос в рамках одного конкретного декстоп-окружения. Поэтому захотелось решить это на более глубоком, системном уровне. И в общем-то это правильно, я считаю. > >> Захотелось увязать это всё с наличием юзера в системе - типа вышел >> юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться. > > ну дык все эти гномы/kde работают поверх каких-то gdm/kdm. Во-первых, классическая архитектура X11 подразумевает, что даже DM может быть запущен удалённо. Во-вторых, а почему, собственно, вы относите данные проблемы исключительно к проблемам графического окружения? На мой имховый взгляд, для консоли можно поставить ровно такие-же вопросы на повестку дня. Конечно, бородатому админу они покажутся смешными, но решать их исключительно в пространстве GUI на мой взгляд не правильно. Кроме того, как только дашь это на откуп DM, то начнется свистопляска, что один DM это делает, а другой не делает. Кому нужен этот "парад сувернитетов"? >> Или допустим другой вопрос: стоит ли давать удалённому юзеру >> возможность маунтить локальные флэшки? Если нет, то нужно как-то >> определять, какой юзер локальный, а какой удаленный, кому показывать >> notification с предложением примаунтить флэшку? > > тут я тоже не вижу необходимости переписывать /sbin/init, поясните > зачем это понадобилось? Ну вот как-то так оказалось, что капнёшь в одном месте, а вылезешь в другом. Я сам ещё до конца не понял и не обозрел этого зверя systemd, но подозреваю, что была необходимость увязать init с остальным. > вот именно - десктопная. > мой разнесчастный десктоп апгрейдится с 1998-го года (с > Debian/potato). > проблемы с апгрейдом у меня начали появляться только как systemd стали > вкручивать. Пользуюсь начиная с woody. Но помилуйте. В то время не на каждом ноуте работало под линксум всё железо. О каких проблемах, которые решаются сейчас, можно было тогда думать? > дык на эту тему давно работа проведена, загляните в любой скрипт > /etc/init.d там в заголовке шапка: от чего зависит и после чего > запускаться должен Если мы рассматриваем исключительно процесс init, то мне очень нравился upstart (по прочитанной в общеобразовательных целях доке), хотя ни разу его не юзал. Но одного инита оказалось мало. -- With best regards Max Dmitrichenko
Re: systemd
>> Затем они начали лочить на DBus с его бинарным API изрядную часть >> системных инструментов. > > да кстати, DBus в целом идея нормальная, но блин бинарный протокол все > портит И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО сложнее в написании безопасного кода. Не говоря уже о накладных расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято принебрегать. Не хватало ещё очередного джаббера для демонов на XML. -- With best regards Max Dmitrichenko
Re: systemd
On 11/11/15, Alexey Shrub wrote: > А переход на конфиги? Это же ацкий > костыль что скрипты инициализации > пишутся на баше, по сути на > универсальном языке программирования, > это избыточно и явно минус с точки > зрения безопасности, а ещё говорят что > systemd зависит от всяких ненужных вещей, > а система инициализации зависящая от > шела это норм? Сделайте, пожалуйста, на этом вашем systemd обновление nginx или unicorn без обрыва существующих соединений. И без читерста a-la использования внешних утилит на шелле (хотя systemd всё равно не сможет её использовать, ибо кроме start-stop-restart-reload больше ничего не знает).
Re: systemd
Max Dmitrichenko -> Debian Russian Mailing List @ Thu, 12 Nov 2015 11:38:57 +0300: >> Понимаешь, в чем разница... Не скажу за TCP, а монолитное ядро стали >> включать в дистрибутивы ОС только после того, как оно заработало лучше, >> чем то, что там было раньше. MD> Я, наверное, что-то пропустил, но разве были такие open source ОС, MD> которые сменили микроядро на монолит? Появились дистрибутивы примерно тех же на уровне userspace (и даже почти обратно совместимых) ОС. В том числе с заменой closed source на open source. >> (Ну да, если быть совсем уж точным, то на >> замену юниксам пришел весь комплект GNU/Linux, но идея как раз в том, >> что он лучше работал.) Что-то я подозреваю, что TCP/IP выиграл у >> ISO/OSI по другой причине - наличия реализации у первого и отсутствия у >> второго, а вот у конкурентов вроде IPX - именно тем, что лучше работал. >> IPX годился только для локальных сетей, к задержкам и потерям пакетов >> относился весьма нервно. MD> Ну, если проводить аналогии между стэками и init'ами, то IPX - это MD> таки upstart. Хороший конкурент systemd, но лишенный части MD> функциональности, которая всем дистростроителям вдруг оказалась нужна. MD> А sysV в этой истории - это вообще соединение по нуль-модемному кабелю MD> ) Таким образом, ISO/OSI в этой истории продолжает соответствовать MD> некой гипотетической рассово, идейно и архитектурно верной системе MD> init, реализации которой мы не увидим никогда ) Я почти со всем из этого согласен. Я не согласен только с одним - что в этой аналогии systemd соответствует TCP/IP. TCP/IP выиграл у IPX за счет того, что работал надежнее в сложных условиях. В скорости он как раз уступал, и в локалке IPX был удобнее. А systemd как раз сколь-нибудь надежно работает только в тщательно отгороженной от реальности песочнице, а чуть сталкивается с реальностью - сразу проблемы. (Кстати, из сказанного, вероятно, следует, что он может оказаться неплох на виртуалках - они как раз те самые песочницы, с предсказуемым окруженем. Но бОльшая часть его функций-то как раз для реальности...)
Re: systemd
почему-то письма от Вас (и только от Вас) приходят с отломанным от письма тегом List-ID. если Вам не трудно, пользуйтесь кнопкой "ответить в рассылку" вместо той которую там используете. >>> Затем они начали лочить на DBus с его бинарным API изрядную часть >>> системных инструментов. >> >> да кстати, DBus в целом идея нормальная, но блин бинарный протокол все >> портит > И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО > сложнее в написании безопасного кода. Не говоря уже о накладных > расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято > принебрегать. текстовые протоколы гораздо проще в написании кода. насчет безопасного кода - я не понял нифига. но большинство протоколов в интернете - текстовые. правда тут полезли неофиты из гугла и прочих копрораций и начали внедрять бинарные расширения к HTTP. увы и ах - тоже дурная тенденция. насчет накладных расходов: Dbus предполагает систему евентов на локальной машине (с возможным гейтом в сеть). я не понимаю кого и как тут могут волновать накладные расходы какие-то > Не хватало ещё очередного джаббера для демонов на XML. вот XML - это не текстовый протокол. ибо текстовый - это когда имеем человекочитаемый текст. а XML - это с трудом человекочитаемый бред. в мире есть множество порождений абсолютного зла: бинарный Dbus, systemd, Windows, Lua, итп XML в этом списке не на последнем месте -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 11:44:56 +0300: >>>> Ну, или придется признать вырождение debian и дружно мигрировать на >>>> gentoo. DEO>>> в генте тоже systemd >> Насколько я знаю, в генте _можно_ собраться с systemd. А можно и без >> него. DEO> ну дык и в Debian _можно_ его не устанавливать. DEO> вопрос тут в том что поставят ли зависимость с xorg на systemd или DEO> нет. DEO> если не поставят, то и можно будет на Debian/Gentoo жить без него, DEO> если поставят - тут нужно будет думать в любом дистре Собственно, идея в том, что в Debian есть один вариант сборки xorg, а в Gentoo - пяток флагов (для xorg, может, и все два десятка), и при сборке можно указать любую их конфигурацию. Проблема возникнет только тогда, когда xorg будет написан так, что без systemd не сможет работать в принципе. Это если и произойдет, то нескоро, поскольку systemd линукс-специфичен, а xorg работает еще как минимум на фрюхе, а если копнуть, то может оказаться, что и в MacOS X нижним уровнем графики работает тоже он...
Re: systemd
On Thu, 12 Nov 2015 12:17:34 +0300 Max Dmitrichenko wrote: > >> Затем они начали лочить на DBus с его бинарным API изрядную часть > >> системных инструментов. > > > > да кстати, DBus в целом идея нормальная, но блин бинарный протокол > > все портит > > И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО > сложнее в написании безопасного кода. Не говоря уже о накладных > расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято > принебрегать. Не хватало ещё очередного джаббера для демонов на XML. > XML это НЕ ТЕКСТОВЫЙ ПРОТОКОЛ. Я бы даже IMAP из-за обязательных идентификаторов команды относил к "полутекстовым". Текстовый это, например язык shell. А авторам шины сообщений следовало законодательно ограничить длину сообщения 80-ю символами. Чтобы не возникало у пользователей идеи, что по этой шине можно передавать данные, как это периодически возникает у авторов всяких KDE-шных приблуд. Кстати, для бинарного протокола все равно пришлось писать библиотеку маршаллинга. Потому что современные недопрограммисты НЕ В СОСТОЯНИИ написать разбор бинарного формата. Можно было и для текстового формата эту библиотеку написать. Или взять готовую - питоновский argparse например. Потому что очевидно, что синтаксис шины сообщений должен быть максимально близок к синтаксису командной строки.
Re: systemd
>> вроде нарисовался вполне себе тру-вей на этот гребанный автомаунт: >> udev в связке с тем же dbus, далее показывай себе окошки в ответ на >> всовывание девайса. но нет, зачем-то понадобилось переписывать >> /sbin/init. я не вижу обоснования - зачем? >> sudo не нравится? >> ну дык напишите свой gnome-su, блин, пусть работает по таким правилам >> как вам нравится > А вот никто не хочет решать этот вопрос в рамках одного конкретного > декстоп-окружения. Поэтому захотелось решить это на более глубоком, > системном уровне. И в общем-то это правильно, я считаю. фиксируем: имеет место быть попытка построить всех в один строй. знаете почему я терпеть не могу gnome? из за XML в конфигах меня очень тошнит от этих всяких blob-реестров итп. я прекрасно обхожусь без этого мусора и мне очень импонирует что я понимаю как я могу решить ту или иную задачу будь она передо мной встанет я не хочу в строй. мало того в моем мире нет "проблемы автомаунта", равно как и нет проблемы "автонастройки сети" итп итд но в этот мой мир ломятся какие-то варвары из мира Windows и пытаются мне насильно решить отсутствующие у меня проблемы. >>> Захотелось увязать это всё с наличием юзера в системе - типа вышел >>> юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться. >> >> ну дык все эти гномы/kde работают поверх каких-то gdm/kdm. > Во-первых, классическая архитектура X11 подразумевает, что даже DM > может быть запущен удалённо. не вижу противоречия. когда он запускается удаленно, то в любом случае и локально тоже код работает. именно тот код, который от удаленного десктопа принимает команды и выполняет их на локальном. почему atexit не может быть распределенным - я тоже не понимаю. > Во-вторых, а почему, собственно, вы > относите данные проблемы исключительно к проблемам графического > окружения? да в общем и для неграфического окружения точно так же переписывание /sbin/init не требуется для размонтирования флешки при логауте. и кстати само это размонтирование при логауте - если подумать тоже зло. > На мой имховый взгляд, для консоли можно поставить ровно > такие-же вопросы на повестку дня. Конечно, бородатому админу они > покажутся смешными, но решать их исключительно в пространстве GUI на > мой взгляд не правильно. в общем виде когда ты с хостом удаленно работаешь, то довольно часто используешь n соединений с ним. при логауте какого размонтировать? > Кроме того, как только дашь это на откуп DM, то начнется свистопляска, > что один DM это делает, а другой не делает. Кому нужен этот "парад > сувернитетов"? мне нужен. именно благодаря параду сувернитетов у меня пока получается успешно и спокойно существовать вне этого поганого мира systemd итп >>> Или допустим другой вопрос: стоит ли давать удалённому юзеру >>> возможность маунтить локальные флэшки? Если нет, то нужно как-то >>> определять, какой юзер локальный, а какой удаленный, кому показывать >>> notification с предложением примаунтить флэшку? >> >> тут я тоже не вижу необходимости переписывать /sbin/init, поясните >> зачем это понадобилось? > Ну вот как-то так оказалось, что капнёшь в одном месте, а вылезешь в > другом. Я сам ещё до конца не понял и не обозрел этого зверя systemd, > но подозреваю, что была необходимость увязать init с остальным. я этой необходимости не вижу была необходимость стандартизовать какие-то межсистемные взаимодействия - да. ну сядьте и напишите стандарт. да набор скриптов/демонов к нему. зачем переписывать /sbin/init да еще попутно запихивая в него совершенно независимые от него вещи, как логгирование, http-серверы, и прочие кофемолки? >> вот именно - десктопная. >> мой разнесчастный десктоп апгрейдится с 1998-го года (с >> Debian/potato). >> проблемы с апгрейдом у меня начали появляться только как systemd стали >> вкручивать. > Пользуюсь начиная с woody. Но помилуйте. В то время не на каждом ноуте > работало под линксум всё железо. О каких проблемах, которые решаются > сейчас, можно было тогда думать? оно и сейчас под линуксом далеко не все железо работает. вот блютух мышка у меня работает, а блютух модем нет. Поттеринг чтоли озадачился драйвер для блютух мне сделать? нет, он пытается мне сломать то, что у меня итак без него работало >> дык на эту тему давно работа проведена, загляните в любой скрипт >> /etc/init.d там в заголовке шапка: от чего зависит и после чего >> запускаться должен > Если мы рассматриваем исключительно процесс init, то мне очень > нравился upstart (по прочитанной в общеобразовательных целях доке), > хотя ни разу его не юзал. Но одного инита оказалось мало. но обоснований переписывать init я пока не увидел -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
> Проблема возникнет только тогда, когда xorg будет написан так, что без > systemd не сможет работать в принципе. Это если и произойдет, то > нескоро, поскольку systemd линукс-специфичен, а xorg работает еще как > минимум на фрюхе, а если копнуть, то может оказаться, что и в MacOS X > нижним уровнем графики работает тоже он... так я ж о том и говорю: Debian тоже НЕ линукс-специфичен. поэтому, думаю, Debian будет последним дистрибутивом на котором можно будет еще жить без systemd, когда все прочие уже попадут в адЪ. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
12 ноября 2015 г., 12:50 пользователь Victor Wagner написал: > On Thu, 12 Nov 2015 12:17:34 +0300 > Max Dmitrichenko wrote: > >> >> Затем они начали лочить на DBus с его бинарным API изрядную часть >> >> системных инструментов. >> > >> > да кстати, DBus в целом идея нормальная, но блин бинарный протокол >> > все портит >> >> И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО >> сложнее в написании безопасного кода. Не говоря уже о накладных >> расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято >> принебрегать. Не хватало ещё очередного джаббера для демонов на XML. >> > > XML это НЕ ТЕКСТОВЫЙ ПРОТОКОЛ. Дело вкуса. > Я бы даже IMAP из-за обязательных > идентификаторов команды относил к "полутекстовым". Текстовый это, > например язык shell. Как вы (апологеты текстовых протоколов) пользуетесь бинарными ssh'ем, tcp/ip и так далее? Быть может, ещё и UTF-8 давит? ) Большинство протоколов - бинарные, и это правильно. Текстовые протоколы - это наследие первой тысячи RFC. Тогда не было инструментов типа современных wireshark, люди осознано шли на такие жертвы, чтобы глазами можно было найти ошибку. Тогда же ещё боялись 8-битных кодировок и избегали использования первых 30 символов в payload'е. Вы как хотите, а не хочу в такое прошлое. > А авторам шины сообщений следовало законодательно ограничить длину > сообщения 80-ю символами. Чтобы не возникало у пользователей идеи, что > по этой шине можно передавать данные, как это периодически возникает у > авторов всяких KDE-шных приблуд. Ага, не джаббер для демонов, а твиттер ) Ну-ну ) > Кстати, для бинарного протокола все равно пришлось писать библиотеку > маршаллинга. Потому что современные недопрограммисты НЕ В СОСТОЯНИИ > написать разбор бинарного формата. Вообще, переиспользование кода - это благо, безотносительно кривизны недопрограммистких рук. Тут же ещё акромя маршалинга, надо использовать unix socket'ы - вот это реально та вещь, которую не каждый в жизни щупал за вымя. > Можно было и для текстового формата > эту библиотеку написать. Или взять готовую - питоновский argparse > например. Не хватало ещё зависимостей от питона в этих вещах. > Потому что очевидно, что синтаксис шины сообщений должен быть > максимально близок к синтаксису командной строки. Для чего и кому это надо? Иметь возможность слать event'ы из коммандной строки штука нужная и полезная. Но это делается отдельной утилитой, которая понимает синтаксис текста и конвертирует их в сообщения шины. Один хрен, подрубиться telnet'ом к unix socket'ам и начать фигачить командочки не получится. -- With best regards Max Dmitrichenko
Re: systemd
> > была необходимость стандартизовать какие-то межсистемные > взаимодействия - да. > ну сядьте и напишите стандарт. да набор скриптов/демонов к нему. Вот пока одни рассуждали и ругались, у кого это архитектурнее получается, другой просто сделал. Подозреваю, что если бы Линус Торвальдс начал обсуждать как ему лучше писать ядро в известной рассылке, вместо того, чтобы взять и написать его, никого не спрашивая, то мы бы сейчас дискутировали на иные темы. > зачем переписывать /sbin/init да еще попутно запихивая в него > совершенно независимые от него вещи, как логгирование, http-серверы, и > прочие кофемолки? Логгирование потому, что для меня, например, всегда было проблемой посмотреть и понять ошибки, которые возникали на стадии загрузки. Приходилось очень сильно выпендриваться, чтобы их найти и исправить, так как лог загрузки тупо нигде и никем не сохранялся. Другое дело - бинарность логов. Тут можно спорить. Серверы, как я понимаю, там именно потому, что это сервисы, за стоп/старт/рестарт которых логично отвечать той же подсистеме init, а не inetd. Ну и что, что они активируются не при старте системы, а при обращении по порту? > оно и сейчас под линуксом далеко не все железо работает. > вот блютух мышка у меня работает, а блютух модем нет. > Поттеринг чтоли озадачился драйвер для блютух мне сделать? А собственно почему вы предлагаете другим писать то, что нужно вам, а не то, что им интересно делать? Это как-то более чем странно. Могут ведь и показать, куда надо идти. > нет, он пытается мне сломать то, что у меня итак без него работало Так не обновляйтесь. Или прекратите ныть, вступайте в дискуссии с теми, кто _принимает_ решения, доказывайте свою правоту до и во время драки и предлагайте _свою_ помощь в том, что _вам_ необходимо. -- With best regards Max Dmitrichenko
Re: systemd
>> Я бы даже IMAP из-за обязательных >> идентификаторов команды относил к "полутекстовым". Текстовый это, >> например язык shell. > Как вы (апологеты текстовых протоколов) пользуетесь бинарными ssh'ем, бинарный он на транспортном уровне, а пользуемся мы им в текстовой форме. я кстати еще застал времена когда ssh не было, а был telnet. а ssh тогда только появился как [платная] приблуда к нему с шифрованием. > tcp/ip и так далее? Быть может, ещё и UTF-8 давит? ) Большинство > протоколов - бинарные, и это правильно. Текстовые протоколы - это > наследие первой тысячи RFC. Тогда не было инструментов типа > современных wireshark, люди осознано шли на такие жертвы, чтобы > глазами можно было найти ошибку. нет, тогда просто люди занимались этим с рассмотрением того как это можно расширять, как налаживать, как сопровождать. а теперь тяп-ляп и в продакшен > Тогда же ещё боялись 8-битных > кодировок не боялись, а пытались быть совместимыми со всем на свете что было тогда на свете. типа мы пишем протокол так чтобы им ПРОСТО могли воспользоваться из любой системы >> А авторам шины сообщений следовало законодательно ограничить длину >> сообщения 80-ю символами. Чтобы не возникало у пользователей идеи, что >> по этой шине можно передавать данные, как это периодически возникает у >> авторов всяких KDE-шных приблуд. > Ага, не джаббер для демонов, а твиттер ) Ну-ну ) просто это сервер СООБЩЕНИЙ. гнать через него данные - это использовать микроскоп для забивания гвоздей. для данных есть сокеты, файлы и прочие механизмы >> Кстати, для бинарного протокола все равно пришлось писать библиотеку >> маршаллинга. Потому что современные недопрограммисты НЕ В СОСТОЯНИИ >> написать разбор бинарного формата. > Вообще, переиспользование кода - это благо, безотносительно кривизны > недопрограммистких рук. Тут же ещё акромя маршалинга, надо > использовать unix socket'ы - вот это реально та вещь, которую не > каждый в жизни щупал за вымя. те кто программировал TCP-сокеты с UNIX-сокетами проблем ощущать не будет. >> Можно было и для текстового формата >> эту библиотеку написать. Или взять готовую - питоновский argparse >> например. > Не хватало ещё зависимостей от питона в этих вещах. уж лучше зависимость от питона на init-уровне, чем зависимость от гроба на колёсиках >> Потому что очевидно, что синтаксис шины сообщений должен быть >> максимально близок к синтаксису командной строки. > Для чего и кому это надо? Иметь возможность слать event'ы из > коммандной строки штука нужная и полезная. помимо прочего правильная реализация предполагает правильное использование. вот сделали blob, далее появляется неофит, который думает: "а чтобы по этому blob не послать 1Gb данных?" и погнали... а был бы у него лимит на размер мессаджа, он бы посидел и подумал :) -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
On Thu, 12 Nov 2015 13:02:53 +0300 "Dmitry E. Oboukhov" wrote: > > Проблема возникнет только тогда, когда xorg будет написан так, что > > без systemd не сможет работать в принципе. Это если и произойдет, > > то нескоро, поскольку systemd линукс-специфичен, а xorg работает > > еще как минимум на фрюхе, а если копнуть, то может оказаться, что и > > в MacOS X нижним уровнем графики работает тоже он... > > так я ж о том и говорю: Debian тоже НЕ линукс-специфичен. Что-то не знаю ни одного человека, который был реально использовал Debian/kFreeBSD или Debian/GNU Hurd. А людей, которые используют FreeBSD - знаю.
Re: systemd
Иван Лох -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 22:54:39 +0300: ИЛ> Кстати, gnome-keyring-daemon единственная гномовская программа, которую ИЛ> я использую. Удобно же для всех браузеров иметь одно защищенное хранилище ИЛ> паролей. И, да, для mutt и git тоже ))) ИЛ> С документацией там, правда, не очень. Только что касается ключей это ИЛ> обычный ssh и gnupg agent, а от хранилища паролей ничего кроме secret-tool ИЛ> не требуется обычно. В принципе да, удобно. Мне, правда, надо еще шарить пароли с андроидом и виндой, поэтому для хранения паролей я как-то больше keepassx использую. Но он не работает агентом. Я бы даже и использовал, он даже установлен у меня, но я так и не сумел понять, каким инструментом посмотреть/поредактировать keyring. >> Логи у него уже бинарные, сделать бинарными еще и конфиги, не >> документировать формат, и конфигурилку сделать только гномовскую. ИЛ> Ну так у гнома (dconf) конфиги по-умолчанию бинарные ))) Во-во... Давайте к бинарным логам systemd добавим еще бинарные конфиги, которые нечем изменить, если гномосессия не сумела подняться...
Re: systemd
On Thu, Nov 12, 2015 at 01:36:45PM +0300, Max Dmitrichenko wrote: > Приходилось очень сильно выпендриваться, чтобы их найти и исправить, > так как лог загрузки тупо нигде и никем не сохранялся. bootlogd-то установить что-ли?! ;) > > нет, он пытается мне сломать то, что у меня итак без него работало > > Так не обновляйтесь. Или прекратите ныть, вступайте в дискуссии с > теми, кто _принимает_ решения, доказывайте свою правоту до и во время > драки и предлагайте _свою_ помощь в том, что _вам_ необходимо. А вот тут вы в какой-то удивительный раз оказались правы. Не понимаю тех DD, которые промолчали все что можно, ничего не сделали сами для изменения итогов голосования и сейчас застывают в гордой позе оскорбленного достоинства... Нет, товарищи - _вы_ сделали Debian таким. Вот эти самые премудрые пескари, которые все пережидают в уютной норке halы, pulseaudio, etc.
Re: systemd
Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 13:52:09 +0300: >>> Я бы даже IMAP из-за обязательных >>> идентификаторов команды относил к "полутекстовым". Текстовый это, >>> например язык shell. >> Как вы (апологеты текстовых протоколов) пользуетесь бинарными ssh'ем, DEO> бинарный он на транспортном уровне, а пользуемся мы им в текстовой DEO> форме. DEO> я кстати еще застал времена когда ssh не было, а был telnet. telnet, кстати, тоже обладает нехилым протоколом, с точки зрения человека бинарным.
Re: systemd
Max Dmitrichenko -> Victor Wagner @ Thu, 12 Nov 2015 13:24:15 +0300: >> Потому что очевидно, что синтаксис шины сообщений должен быть >> максимально близок к синтаксису командной строки. MD> Для чего и кому это надо? Иметь возможность слать event'ы из MD> коммандной строки штука нужная и полезная. Но это делается отдельной MD> утилитой, которая понимает синтаксис текста и конвертирует их в MD> сообщения шины. Один хрен, подрубиться telnet'ом к unix socket'ам и MD> начать фигачить командочки не получится. telnet'ом - нет, а nc - можно. А "для чего"... Чем больше прослоек между трафиком по сети и глазами того человека, который ищет проблему, тем больше вероятность, что проблема потеряется в этих прослойках. Если оказывается, что две библиотеки несовместимым образом реализуют бинарный протокол (ошибки, чтоб никому не было обидно, предположим в обеих), то декодер, основанный на одной из них, покажет только половину проблем. А если ошибка только в этой библиотеке, то и вообще покажет ошибку не там, где она на самом деле. Иногда бинарный формат окупается. В первую очередь в криптографии, где зашифрованный текст не должен иметь осмысленной интерпретации сторонним наблюдателем, и поэтому нет смысла делать его человекочитаемым. А вот метаинформацию TCP/IP сделать текстовой, может, и стоило. Я сильно подозреваю, что количество мест, где от этого заметно просела бы производительность, невелико. На совсем коротких интерактивных пакетах, где payload - один-два символа, она и так уже безнадежна, на длинных разница в оверхеде будет незаметна, а ситуаций, где размер payload'а порядка размера заголовка, тупо мало.
Re: systemd
On Thu, 12 Nov 2015 13:24:15 +0300 Max Dmitrichenko wrote: > Один хрен, подрубиться telnet'ом к unix socket'ам и > начать фигачить командочки не получится. Эта утилита называется socat. Эдакий telnet для всех типов сокетов. -- Alexander Galanin
Re: systemd
Alexey Shrub -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 18:29:33 +0300: AS> А переход на конфиги? Это же ацкий костыль что скрипты инициализации пишутся AS> на баше, по сути на универсальном языке программирования, это избыточно и явно AS> минус с точки зрения безопасности, а ещё говорят что systemd зависит от всяких AS> ненужных вещей, а система инициализации зависящая от шела это норм? Тонкий нюанс. Если посмотреть на ряд таких скриптов, станет понятно, почему. Потому что это не конфиг, а программа запуска. Которая неизбежно является программой, потому что у многих сложных сервисов содержит ряд нетривиальных действий. Она, кстати, не зависит от шелла, программу запуска можно писать на любом языке.
Re: systemd
On Thu, Nov 12, 2015 at 02:46:31PM +0300, Artem Chuprina wrote: > Иван Лох -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 22:54:39 > +0300: > > ИЛ> Кстати, gnome-keyring-daemon единственная гномовская программа, которую > ИЛ> я использую. Удобно же для всех браузеров иметь одно защищенное хранилище > ИЛ> паролей. И, да, для mutt и git тоже ))) > > ИЛ> С документацией там, правда, не очень. Только что касается ключей это > ИЛ> обычный ssh и gnupg agent, а от хранилища паролей ничего кроме > secret-tool > ИЛ> не требуется обычно. > > В принципе да, удобно. Мне, правда, надо еще шарить пароли с андроидом > и виндой, поэтому для хранения паролей я как-то больше keepassx > использую. Но он не работает агентом. > > Я бы даже и использовал, он даже установлен у меня, но я так и не сумел > понять, каким инструментом посмотреть/поредактировать keyring. seahorse
Re: systemd
On 11/11/15 18:29, Alexey Shrub wrote: А параллельная загрузка? О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна?
Re: systemd
Иван Лох -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 15:55:05 +0300: >> ИЛ> Кстати, gnome-keyring-daemon единственная гномовская программа, которую >> ИЛ> я использую. Удобно же для всех браузеров иметь одно защищенное >> хранилище >> ИЛ> паролей. И, да, для mutt и git тоже ))) >> >> ИЛ> С документацией там, правда, не очень. Только что касается ключей это >> ИЛ> обычный ssh и gnupg agent, а от хранилища паролей ничего кроме >> secret-tool >> ИЛ> не требуется обычно. >> >> В принципе да, удобно. Мне, правда, надо еще шарить пароли с андроидом >> и виндой, поэтому для хранения паролей я как-то больше keepassx >> использую. Но он не работает агентом. >> >> Я бы даже и использовал, он даже установлен у меня, но я так и не сумел >> понять, каким инструментом посмотреть/поредактировать keyring. ИЛ> seahorse Только комбайн? Не то чтобы он уж очень толстый комбайн, но все же...
Re: systemd
Dmitry Alexandrov -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 15:56:39 +0300: >>А параллельная загрузка? DA> О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней DA> все так носятся, с этой с параллельной загрузкой демонов, как с писанной DA> торбой? Зачем она вообще нужна? Ну, как минимум, чтобы в случае, когда заткнулся один, спокойно загрузились остальные, если они от него не зависят. Даже так: если они от него не зависят жестко. Правда, я сильно подозреваю, что последнее как раз забыли реализовать, потому что граждане, которые ЭТО везде проталкивают, слова "надежность" в лексиконе не имеют.
Re: systemd
12 ноября 2015 г., 15:56 пользователь Dmitry Alexandrov <321...@gmail.com> написал: > On 11/11/15 18:29, Alexey Shrub wrote: > >> А параллельная загрузка? > > > О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с > ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной > торбой? Зачем она вообще нужна? Windows 8 дюже быстро загружается ) Конкуренция, однако. -- With best regards Max Dmitrichenko
Re: systemd
On Thu, Nov 12, 2015 at 03:56:39PM +0300, Dmitry Alexandrov wrote: > On 11/11/15 18:29, Alexey Shrub wrote: > > >А параллельная загрузка? > > О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с > ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной > торбой? Зачем она вообще нужна? Ну вот загружаешься ты а сетевой провод оборван. Если загрузка последовательная, то надо или маленький таймаут ставить (что черевато) или ждать
Re: systemd
On Thu, 12 Nov 2015 13:24:15 +0300 Max Dmitrichenko wrote: > > Потому что очевидно, что синтаксис шины сообщений должен быть > > максимально близок к синтаксису командной строки. > > Для чего и кому это надо? Иметь возможность слать event'ы из > коммандной строки штука нужная и полезная. Но это делается отдельной Главное, это не слать, главное - это обрабатывать. Основная на мой взгляд, проблема DBus - это отсутствие возможности быстренько на коленке сляпать обработчик определенного сигнала. Одной-двумя шелловскими командами. Слать-то можно. С уродским синтаксисом dbus-send, но можно. > утилитой, которая понимает синтаксис текста и конвертирует их в > сообщения шины. Один хрен, подрубиться telnet'ом к unix socket'ам и > начать фигачить командочки не получится. А вот надо было дизайнить шину так, чтобы получилась. А главное, чтобы можно было приконнектиться и посмотреть, что кому и от кого ходит. Если это шина, к ней должен быть свой аналог wireshark-а. dbus-monitor, увы, откровенно слабоват. Потому что написать "безопасный код" все равно не получится. Поэтому надо стремиться не к тому, чтобы код не мог сделать ничего вредного (поскольку тогда он и ничего полезного сделать не сможет, что мы сейчас и имеем во всяких андроидах, где встроенных средств автоматизации считай нет), а к тому чтобы было легко разобраться в том, что произошло, и что сделать чтобы в следующий раз произошло то, что надо. Классический unix был хорош тем, что для решения специальных, редко встречающихся задач, как правило не нужно было использовать специальные инструменты, можно было пользоваться теми, которыми пользуешься каждый день для часто встречающихся задач. Например логи анализировать тем же grep-ом, которым анализируешь тексты. И да, писать скрипты запуска системы на том же шелле, на которым ты ежедневно отдаешь команды запуска любимого текстового редактора, отправки заданий на печать etc.
Re: systemd
On 11/12/2015 05:12 PM, Иван Лох wrote: On Thu, Nov 12, 2015 at 03:56:39PM +0300, Dmitry Alexandrov wrote: On 11/11/15 18:29, Alexey Shrub wrote: А параллельная загрузка? О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна? Ну вот загружаешься ты а сетевой провод оборван. Если загрузка последовательная, то надо или маленький таймаут ставить (что черевато) или ждать И что? -- Best regards, Dim
Re: systemd
On 11/12/2015 03:56 PM, Dmitry Alexandrov wrote: On 11/11/15 18:29, Alexey Shrub wrote: А параллельная загрузка? О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна? Вот и мне интересно. Такое ощущение что народ ставит себе систему и целый день её ребутит ребути и ребутит. А от скорости ребута прямо стабильность ядерного реактора зависит. -- Best regards, Dim
Re: systemd
On Thu, Nov 12, 2015 at 06:55:48PM +0300, D.Himro wrote: > >или ждать > > > > И что? Ну жди, мне то…
Re: systemd
Что-то много текстопротокольного фанатизма, протоколы это не художественная литература, бинарные протоколы это норма, никто не заставляет руками набирать бинарные сообщения в hex редакторе, всегда есть/можно написать простую утилиту которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть отладочную инфу нет смысла все сто лет иметь оверхед от текстового протокола On Чт, ноя 12, 2015 в 11:44 , Dmitry E. Oboukhov wrote да кстати, DBus в целом идея нормальная, но блин бинарный протокол все портит
Re: systemd
Думаю скрипты запуска не должны быть программами, интересно бы услышать конкретные примеры зачем это может быть нужно. Как-то же уложили всё в конфиги, значит возможно. On Чт, ноя 12, 2015 в 3:14 , Artem Chuprina wrote: Потому что это не конфиг, а программа запуска. Которая неизбежно является программой, потому что у многих сложных сервисов содержит ряд нетривиальных действий. Она, кстати, не зависит от шелла, программу запуска можно писать на любом языке.
Re: systemd
On 12/11/15 17:12, Иван Лох wrote: On Thu, Nov 12, 2015 at 03:56:39PM +0300, Dmitry Alexandrov wrote: On 11/11/15 18:29, Alexey Shrub wrote: А параллельная загрузка? О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна? Ну вот загружаешься ты а сетевой провод оборван. Если загрузка последовательная, то надо или маленький таймаут ставить (что черевато) или ждать Серьезно? Время от времени загружаюсь не то, что с оборванным, а с заведомо отключенным сетевым кабелем — и никто никого не ждет — ну нет связи и нет — проехали, грузимся дальше. Я что-то не так делаю? Более того, хотя за последними версиями этой Систем-Д не уследишь, но та, что в Джесси, по части поднятия отсутствующей сети дает абсолютно идентичный Сис-5-иниту результат — приказано ждать (auto) — ждет, тормозя загрузку; приказано не ждать (allow-hotplug) — не ждет. И я нахожу это логичным. Что изменилось-то, кроме того, что старый инит показывает мне вывод dhcpd, по которому хотя бы видно, который из интерфейсов не подымается, а Систем-Д только крутит красивые красные звездочки напротив чего-то типа «Raising network»?
Re: systemd
On 12/11/15 16:49, Max Dmitrichenko wrote: 12 ноября 2015 г., 15:56 пользователь Dmitry Alexandrov <321...@gmail.com> написал: On 11/11/15 18:29, Alexey Shrub wrote: А параллельная загрузка? О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна? Windows 8 дюже быстро загружается ) Конкуренция, однако. Ну да, вот у меня тоже сложилось впечатление, что немалая доля в заваренной каше у тех, кому очень захотелось померяться чем-нибудь с секундомером в руках. Ничего, что практическое значение близко к нулю, зато наглядно. Стометровку бы лучше бегали, ей богу. :-)
Re: systemd
Alexey Shrub -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 19:57:36 +0300: AS> Думаю скрипты запуска не должны быть программами, интересно бы услышать AS> конкретные примеры зачем это может быть нужно. Как-то же уложили всё в AS> конфиги, значит возможно. Это значит, что скрипт запуска просто переложили из /etc/init.d в другое место. Или даже не переложили, а прямо его же и используют. Конкретный пример из своей работы. Скрипт запуска веб-сервера, выполняющего некоторую вполне конкретную задачу. Надо 1. вычистить именованные сокеты, которые могли остаться после падения в предыдущем запуске 2. поднять unicorn 3. поднять демон, выполняющий отложенные задания База данных, фронтэнд и почтовка поднимаются отдельно, это собственно application level. На практике пять строчек на bash. База данных и почтовка к моменту запуска обоих демонов должны работать, фронтэнд можно, в общем, запускать и до unicorn (идеально было бы после того, как тот будет готов работать, о чем он вряд ли умеет сообщать, а демонизируется, скорее всего, раньше, чем будет готов). Предъяви, пожалуйста, конфиг для systemd. Призовая игра. Апгрейд. Надо 1. git pull 2. если при git pull поменялся скрипт апгрейда, перезапустить скрипт апгрейда 3. bundle install 4. rake assets:precompile 5. положить вышеперечисленную пару (во время апгрейда базы она не должна пытаться работать) 6. rake db:migrate 7. только после успешного завершения поднять вышеперечисленную пару 8. обновить crontab Особое внимание на последовательность пп. 5-7. Как провести эту операцию с systemd, если systemd будет пытаться поднять unicorn при обращении к сокету? Нет, я подозреваю, что как-то можно заткнуть эту его продвинутую функциональность на время апгрейда, потому что такое надо в каждом втором случае. Но процедуры апгрейда, т.е. необходимости писать скрипт, это не отменяет. И надо заметить, что unicorn поднимается-то небыстро, так что поднимать его по первому обращению к сокету может быть и не шибко замечательно, лучше бы поднять пораньше, чтобы к первому обращению он уже был готов работать. По сравнению со всем этим идея, что мне ах, безумно не хватает возможности начать стартовать unicorn только после того, как postgresql готов работать (unicorn действительно нервно отнесется к отказу в коннекте), выглядит одной из мелочей. Тупой sleep на 12 секунд в начале скрипта запуска (только при старте системы, при апгрейде этот вариант не выполняется) _на практике_ работает достаточно надежно, не приходится даже изгаляться с несколькими предварительными попытками соединения через psql. А почтовка и сама успевает запуститься раньше. Оно, конечно, чисто в идеале было бы прям замечательно зацепиться за зависимости (почтовка и постгрес готовы? ура, поднимаем движок), но необходимости в _процедуре_, а не просто конфигурации, запуска это не отменяет. И суть, собственно, в том, что у каждой плюс-минус сложной подсистемы эта процедура своя, поэтому единую систему конфигурации, которая бы годилась для всех вариантов и не была бы при этом Тьюринг-полной или близкой к тому, скорее всего, не сделать. Тому же постгресу, если почитать его скрипт запуска, скорее всего, надо перед стартом демона проверить базу на целостность, и если что, попытаться починить. Это, конечно, тоже можно переписать на систему зависимостей, но дело в том, что система зависимостей, которая справится с любой такой задачей, неизбежно будет Тьюринг-полна. Т.е. будет полноценным языком программирования, и скорее всего, хуже шелла, а не лучше (ибо чтобы сделать лучше, надо и мозги иметь не хуже, чем у отцов-основателей юникса, а такое встречается нечасто). AS> On Чт, ноя 12, 2015 в 3:14 , Artem Chuprina wrote: >> Потому что это не конфиг, а программа запуска. Которая неизбежно >> является программой, потому что у многих сложных сервисов содержит ряд >> нетривиальных действий. Она, кстати, не зависит от шелла, программу >> запуска можно писать на любом языке.
Re: systemd
On Чт, ноя 12, 2015 в 3:56 , Dmitry Alexandrov <321...@gmail.com> wrote: все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна? Да не то чтобы она сильно нужна, но странно в 21 веке на многоядерных процах запускать независимые процессы последовательно
Re: systemd
On Чт, ноя 12, 2015 в 9:20 , Artem Chuprina wrote: 1. вычистить именованные сокеты, которые могли остаться после падения в предыдущем запуске мне кажется что это какой-то грязный костыль не имеющий отношения с системе инициализации, чистить мусор за собой должен тот что его создал = освобождать ресурсы должен тот кто их занимал, если без костыля никак, то делать его нужно отдельным процессов от которого должен зависеть дальнейших запуск 2. поднять unicorn 3. поднять демон, выполняющий отложенные задания База данных, фронтэнд и почтовка поднимаются отдельно, это собственно application level. На практике пять строчек на bash. почему это нельзя сделать зависимостями? Призовая игра. Апгрейд. а как апгдейд связан с системой инициализации? И да, если во время апгрейда ничего не должно работать, то надо всё стопать чтобы ничего не работало. Начать видимо с nginx, тогда к остальным запросы перестанут переходить.
Re: systemd
On Thu, Nov 12, 2015 at 09:56:48PM +0300, Alexey Shrub wrote: > On Чт, ноя 12, 2015 в 9:20 , Artem Chuprina wrote: > >1. вычистить именованные сокеты, которые могли остаться после падения в > >предыдущем запуске > > мне кажется что это какой-то грязный костыль не имеющий отношения с системе > инициализации, чистить мусор за собой должен тот что его создал = > освобождать ресурсы должен тот кто их занимал, если без костыля никак, то > делать его нужно отдельным процессов от которого должен зависеть дальнейших > запуск systemd включает в себя специальный демон systemd-tmpfiles для самой изощренной работы с временными файлами. Но в данном случае достаточно установить RuntimeDirectory= и systemd ее почистит после остановки сервиса
Re: systemd
On 11/12/15 22:54, Иван Лох wrote: > Но в данном случае достаточно установить RuntimeDirectory= > и systemd ее почистит после остановки сервиса А перед? Остановка сервиса может быть по броску питания.
Re: systemd
Согласен, наверное, многие используют shell скрипты и то что ими нельзя обработать считают злом. Таким посоветовать могу пользоваться питоном вместо баша - им наверное можно все практически окучить :) apt-cache search python | grep systemd 12.11.2015 19:55, Alexey Shrub пишет: Что-то много текстопротокольного фанатизма, протоколы это не художественная литература, бинарные протоколы это норма, никто не заставляет руками набирать бинарные сообщения в hex редакторе, всегда есть/можно написать простую утилиту которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть отладочную инфу нет смысла все сто лет иметь оверхед от текстового протокола On Чт, ноя 12, 2015 в 11:44 , Dmitry E. Oboukhov wrote да кстати, DBus в целом идея нормальная, но блин бинарный протокол все портит
Re: systemd
On Thu, Nov 12, 2015 at 11:11:25PM +0300, Alex Kicelew wrote: > On 11/12/15 22:54, Иван Лох wrote: > > Но в данном случае достаточно установить RuntimeDirectory= > > и systemd ее почистит после остановки сервиса > > А перед? Остановка сервиса может быть по броску питания. Думаю, что да. Но в любом случае это поддиректория /run и находится на tmpfs. По скачку очистится.
Re: systemd
On 11/12/2015 08:02 PM, Dmitry Alexandrov wrote: > приказано ждать (auto) — ждет, > тормозя загрузку; приказано не ждать (allow-hotplug) — не ждет. Сам придумал? -- sergio
Re: systemd
В Thu, 12 Nov 2015 18:54:06 +0300 "D.Himro" пишет: > On 11/12/2015 03:56 PM, Dmitry Alexandrov wrote: > > On 11/11/15 18:29, Alexey Shrub wrote: > > > >> А параллельная загрузка? > > > > О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, > > чего с ней все так носятся, с этой с параллельной загрузкой > > демонов, как с писанной торбой? Зачем она вообще нужна? > > Вот и мне интересно. Такое ощущение что народ ставит себе систему и > целый день её ребутит ребути и ребутит. А от скорости ребута прямо > стабильность ядерного реактора зависит. > Что характерно, разработчики систем инициализации ровно это и делают. Они ставят тестовую систему и после каждого изменения в коде, которое надо протестировать, ее перезапускают. -- Victor Wagner
Re: systemd
В Fri, 13 Nov 2015 00:11:24 +0300 Илья пишет: > Согласен, наверное, многие используют shell скрипты и то что ими > нельзя обработать считают злом. Таким посоветовать могу пользоваться Компьютер - он чтобы работать. Поэтому операции, которые нельзя заскриптовать - действительно зло. Нужно чтобы любое действие, которое ты делаешь руками можно было взять откуда-то, куда оно записалось автоматически (например в history shell-а), и поместить куда-то, откуда оно будет вызываться само. shell это компромисс между "удобно делать интерактивно" и "пригодно для неинтерактивного выполния". > питоном вместо баша - им наверное можно все практически окучить :) Питон - существнно более низкоуровневый язык. В нем интерактивно можно разве что арифметические выражения вычислять. То есть для большинства решаемых пользователем задач он - гораздо худший компромисс между "решить интерактивно" и "решить автоматически". Фвктически лично мне удобно использовать питон в интерактивном режиме только для ситуации "попробовать как работает тот или иной питоновский объект, который я собираюсь использовать при написании программы". А шелл гораздо лучше питона подходит для обратной задачи "программно сделать то, что я обычно делаю руками в этом же шелле". -- Victor Wagner
Re: systemd
12.11.2015 15:56, Dmitry Alexandrov пишет: On 11/11/15 18:29, Alexey Shrub wrote: А параллельная загрузка? О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной торбой? Зачем она вообще нужна? Я думаю тут дело не только в одной загрузке. Параллельная загрузка это "побочный" эффект наличия механизмов управления службами. По идее systemd должен способствовать более эффективному использованию ресурсов системы.
Re: systemd
13.11.2015 08:16, Victor Wagner пишет: В Fri, 13 Nov 2015 00:11:24 +0300 Илья пишет: Компьютер - он чтобы работать. Поэтому операции, которые нельзя заскриптовать - действительно зло. Нужно чтобы любое действие, которое ты делаешь руками можно было взять откуда-то, куда оно записалось автоматически (например в history shell-а), и поместить куда-то, откуда оно будет вызываться само. Получается мышь и GUI это зло. :) shell это компромисс между "удобно делать интерактивно" и "пригодно для неинтерактивного выполния". питоном вместо баша - им наверное можно все практически окучить :) Питон - существнно более низкоуровневый язык. В нем интерактивно можно разве что арифметические выражения вычислять. То есть для большинства решаемых пользователем задач он - гораздо худший компромисс между "решить интерактивно" и "решить автоматически". Ну для меня важнее не классификация, а решении задачи. Я даже не пробовал заменить bash на питон :) Хотя теоретически можно реализовать среду программирования которая добавит "интерактивности". Думаю не корректно сравнивать среду (shell) и язык программирования. Фвктически лично мне удобно использовать питон в интерактивном режиме только для ситуации "попробовать как работает тот или иной питоновский объект, который я собираюсь использовать при написании программы". А шелл гораздо лучше питона подходит для обратной задачи "программно сделать то, что я обычно делаю руками в этом же шелле". Я хотел сказать, что есть задачи в которые удобнее решать другим инструментом, а уже результатом можно пользоваться в шелле. Команды grep ни ls ведь на СИ написаны, но вы ими пользуетесь Я думаю интернет бороздить удобнее тем же links чем telnet. ps Прошу прошения, за письмо в личку - спал уже
Re: systemd
> Что-то много текстопротокольного фанатизма, протоколы это не художественная > литература, бинарные протоколы это норма, никто не заставляет руками набирать > бинарные сообщения в hex редакторе, всегда есть/можно написать простую утилиту > которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть > отладочную инфу нет смысла все сто лет иметь оверхед от текстового протокола пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо что-то пропустил -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
13.11.2015 09:37, Илья пишет: > 13.11.2015 08:16, Victor Wagner пишет: >> В Fri, 13 Nov 2015 00:11:24 +0300 >> Илья пишет: >> >> Компьютер - он чтобы работать. Поэтому операции, >> которые нельзя заскриптовать - действительно зло. Нужно чтобы любое >> действие, которое ты делаешь руками можно было взять откуда-то, куда >> оно записалось автоматически (например в history shell-а), и поместить >> куда-то, откуда оно будет вызываться само. > > Получается мышь и GUI это зло. :) Для выполнения задач, которые можно заскриптовать - да. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: systemd
13.11.2015 09:59, Dmitry E. Oboukhov пишет: Что-то много текстопротокольного фанатизма, протоколы это не художественная литература, бинарные протоколы это норма, никто не заставляет руками набирать бинарные сообщения в hex редакторе, всегда есть/можно написать простую утилиту которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть отладочную инфу нет смысла все сто лет иметь оверхед от текстового протокола пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо что-то пропустил Для начала, стоит наверное определится что такое текстовый протокол. Если понимать под этим символьное (UTF,koi) представление данных и служебной информации, то в этом случае объем передаваемой информации больше, чем у как то кодированого. Больше объем - больше требуется ресурсов. В качестве примера можно рассмотреть HTML + XML + JS. Ну или скрипты java (размер исходника, компилятор,java машина) против бинарной программы на СИ. Я считаю, что тут проблема не в самих протоколах, а в том как их используют. Мегабайтные странички в памяти и браузер сжирающий процессор это писец - но это не проблема в самом протоколе http.
Re: systemd
On Fri, 13 Nov 2015 09:37:47 +0300 Илья wrote: > > > 13.11.2015 08:16, Victor Wagner пишет: > > В Fri, 13 Nov 2015 00:11:24 +0300 > > Илья пишет: > > > > Компьютер - он чтобы работать. Поэтому операции, > > которые нельзя заскриптовать - действительно зло. Нужно чтобы любое > > действие, которое ты делаешь руками можно было взять откуда-то, куда > > оно записалось автоматически (например в history shell-а), и > > поместить куда-то, откуда оно будет вызываться само. > > Получается мышь и GUI это зло. :) Злом явлется отсутствие средств, позволяющих легко поручить работу с GUI компьютеру. В принципе, можно бы было себе представить инструмент, который позволяет сценарий работы пользователся с GUI превратить в скрипт. К сожалению, все реально существующие подобные инструменты настолько неудобны, что даже при тестировании программ их применяют далеко не все. За попытками создать подобные средства я слежу года, наверное с 1992 (когда впервые увидел macro recorder, входивший в состав Windows 3.1). Пока сплошные фейлы. Основная проблема заключается в том, как описать что именно видит человек на экране, когда принимает то или иное решение. Корректно описать куда именно нужно послать событие от мыши обычно проще. Потому что в большинстве случаев достаточно сказать "ткнуть мышью вот в этот виджет (кнопку, позицию меню)" а у виджета имя есть (надпись на кнопке). > > Ну для меня важнее не классификация, а решении задачи. > Я даже не пробовал заменить bash на питон :) Хотя теоретически можно Ну вот. Это к вопросу обсуждения вкуса устриц с теми, кто их ел. > реализовать среду программирования которая добавит "интерактивности". > Думаю не корректно сравнивать среду (shell) и язык программирования. Тем не менее unix shell это и есть язык программирования. > Я хотел сказать, что есть задачи в которые удобнее решать другим > инструментом, а уже результатом можно пользоваться в шелле. > Команды grep ни ls ведь на СИ написаны, но вы ими пользуетесь Важно не то, на чем оно написано, а то, придется ли мне его переписывать. grep это кирпичик с четко специфицированным и, главнное, надежно заученным интерфейсом. Если меня он не устроит, я не буду его переписывать, а просто возьму другой сходный инструмент - sed, awk, perl, vim в конце концов. Вместо ls можно опять же взять mc, vifm или vim. Это одна из возможностей. Не нравится, не ешь. Легенды про людей у которых в поле shell в /etc/passwd написано /usr/bin/tclsh, /usr/bin/ipython или /usr/bin/perl ходят. А systemd и dbus претендует на незаменимое место в системе. > Я думаю интернет бороздить удобнее тем же links чем telnet. Вот наборот. links это компромисс достаточно неудачный. Он не обладает ни преимуществами телнета (полной визуализацией служебных полей текстового протокола http и полным контролем над ними), ни преимуществами графического браузера (удобным для восприятия рендерингом страниц, наличием интерпретатора скриптов). То есть вот лично я телнетом пользуюсь для доступа к веб-серверам чаще, чем links. А занимайся бы отладкой всяких веб-сервисов чуть более регулярно, поставил бы себе в iceweasel live-http-headers и имел бы все преимущества телнета в сочетании с преимуществами графического браузера.
Re: systemd
Alexey Shrub -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 21:56:48 +0300: >> 1. вычистить именованные сокеты, которые могли остаться после падения в >> предыдущем запуске AS> мне кажется что это какой-то грязный костыль не имеющий отношения с системе AS> инициализации, чистить мусор за собой должен тот что его создал = освобождать AS> ресурсы должен тот кто их занимал, если без костыля никак, то делать его нужно AS> отдельным процессов от которого должен зависеть дальнейших запуск Это теория или практика? Питание никогда не пропадало? OOM killer никогда не срабатывал? >> 2. поднять unicorn >> 3. поднять демон, выполняющий отложенные задания >> База данных, фронтэнд и почтовка поднимаются отдельно, это собственно >> application level. На практике пять строчек на bash. AS> почему это нельзя сделать зависимостями? "Вы не брезгливы, но невнимательны" (c) Это можно сделать зависимостями, я об этом писал. А можно написать на ассемблере. И то, и другое - сложнее и более чревато ошибками, чем написать процедуру на sh. >> Призовая игра. Апгрейд. AS> а как апгдейд связан с системой инициализации? И да, если во время апгрейда AS> ничего не должно работать, то надо всё стопать чтобы ничего не AS> работало. Начать видимо с nginx, тогда к остальным запросы перестанут AS> переходить. Так к nginx они будут приходить, и systemd будет пытаться поднять его. Поднимет, а от него уже пойдут запросы к движку. Предлагаем остановить systemd? :)
Re: systemd
Иван Лох -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 00:34:47 +0300: >> > Но в данном случае достаточно установить RuntimeDirectory= >> > и systemd ее почистит после остановки сервиса >> >> А перед? Остановка сервиса может быть по броску питания. ИЛ> Думаю, что да. Но в любом случае это поддиректория /run ИЛ> и находится на tmpfs. По скачку очистится. После срабатывания OOM killer не очистится. Если перед почистит, то, конечно, хорошо. Но фразам вида "думаю, что да" относительно systemd я верить не могу. Либо "да", в смысле проверяли, либо "хрен его знает".
Re: systemd
Илья -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 10:53:59 +0300: >>> Что-то много текстопротокольного фанатизма, протоколы это не художественная >>> литература, бинарные протоколы это норма, никто не заставляет руками >>> набирать >>> бинарные сообщения в hex редакторе, всегда есть/можно написать простую >>> утилиту >>> которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть >>> отладочную инфу нет смысла все сто лет иметь оверхед от текстового >>> протокола >> >> пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо >> что-то пропустил И> Для начала, стоит наверное определится что такое текстовый протокол. И> Если понимать под этим символьное (UTF,koi) представление данных и служебной И> информации, то в этом случае объем передаваемой информации больше, чем у как И> то кодированого. Больше объем - больше требуется ресурсов. В качестве примера И> можно рассмотреть HTML + XML + JS. Ну или скрипты java (размер исходника, И> компилятор,java машина) против бинарной программы на СИ. И> Я считаю, что тут проблема не в самих протоколах, а в том как их И> используют. Мегабайтные странички в памяти и браузер сжирающий процессор это И> писец - но это не проблема в самом протоколе http. И не в протоколе HTML. Память и процессор он сжирает вовсе даже бинарными структурами.
Re: systemd
>>> нет, он пытается мне сломать то, что у меня итак без него работало >> >> Так не обновляйтесь. Или прекратите ныть, вступайте в дискуссии с >> теми, кто _принимает_ решения, доказывайте свою правоту до и во время >> драки и предлагайте _свою_ помощь в том, что _вам_ необходимо. > А вот тут вы в какой-то удивительный раз оказались правы. Не понимаю > тех DD, которые промолчали все что можно, ничего не сделали сами > для изменения итогов голосования и сейчас застывают в гордой > позе оскорбленного достоинства... Нет, товарищи - _вы_ сделали > Debian таким. Вот эти самые премудрые пескари, которые все > пережидают в уютной норке halы, pulseaudio, etc. да тут ты меня уел :) что сказать, да - голосовал в голосованиях, да спорил в IRC. да в рассылке поддержал тех кто сказал что "когда в Debian нельзя будет жить без systemd, я уйду из Debian", но этого всего недостаточно разумеется. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
On Thu, Nov 12, 2015 at 07:55:22PM +0300, Alexey Shrub wrote: > Что-то много текстопротокольного фанатизма, протоколы это не > художественная литература, Да, протоколы серьёзнее: их приходится не только читать, но иногда и понимать. В отличие от художественной литературы. :) > бинарные протоколы это норма, никто не > заставляет руками набирать бинарные сообщения в hex редакторе, > всегда есть/можно написать простую утилиту которая всё делает > читаемым. Скажем так: "можно" это меньше 15 минут, "невозможно" это больше 15. Именно столько готов потратить юзер на поиск утилиты, которая расшифрует ему протокол, если таковая существует. Если же нет, то никто ни писать дешифратор, ни даже покупать техподдержку не будет. Просто забьёт на глюкало вместе с его протоколом, в результате протокол и глюкало сдохнут вместе. Теоретическое существование людей, способных написать дешифратор, ничего не меняет. Эти люди вообще окажутся не в курсе проблемы. Чтобы до них багрепорт дошёл, кто-то должен проблему внятно сформулировать, поэтому дешифратор протокола следует прикладывать к базовой софтине сразу. Сетевик не может жить без игрушек вроде tcpdump'a, а разработчику DE нужен какой-нибудь dbus-monitor. Чтобы видеть текст, ага. > Ради того чтобы раз в сто лет посмотреть отладочную инфу > нет смысла все сто лет иметь оверхед от текстового протокола Главное достоинство текстовых протоколов не столько в читабельности (это действительно решается правильным логгингом и декодерами), сколько в гибкости и лёгкой расширяемости под СВОИ нужды. Скажем, добавить лишнюю опцию вроде ECN в ip-хедер проблематично без комитета, а добавить лишний хедер в HTTP может любой, никого не спрашивая. Причём так, что этот хедер ничему мешать не будет. Эта возможность важнее 100 лет оверхеда. :) -- Eugene Berdnikov
Re: systemd
13 ноября 2015 г., 12:36 пользователь Eugene Berdnikov написал: > Скажем так: "можно" это меньше 15 минут, "невозможно" это больше 15. > Именно столько готов потратить юзер на поиск утилиты, которая > расшифрует ему протокол, если таковая существует. Если же нет, > то никто ни писать дешифратор, ни даже покупать техподдержку > не будет. Просто забьёт на глюкало вместе с его протоколом, > в результате протокол и глюкало сдохнут вместе. Таки интересные вещи вы тут рассказываете. А чё скайп-то до сих пор жив? Бинарный, глюкавый, без дешифраторов, например. Или вот появилась же как-то Samba, которая проимплементила бинарный закрытый глюкавый протокол. > Главное достоинство текстовых протоколов не столько в читабельности > (это действительно решается правильным логгингом и декодерами), > сколько в гибкости и лёгкой расширяемости под СВОИ нужды. Скажем, > добавить лишнюю опцию вроде ECN в ip-хедер проблематично без комитета, > а добавить лишний хедер в HTTP может любой, никого не спрашивая. > Причём так, что этот хедер ничему мешать не будет. > Эта возможность важнее 100 лет оверхеда. :) Таки IP-хедер продукт старой школы. Бинарные TLV структуры, с выделенным пространством T для vendor extension's - давно используются во многих протоколах. -- With best regards Max Dmitrichenko
Re: systemd
13.11.2015 11:29, Artem Chuprina пишет: >> Призовая игра. Апгрейд. Так к nginx они будут приходить, и systemd будет пытаться поднять его. Поднимет, а от него уже пойдут запросы к движку. Предлагаем остановить systemd? :) systemctl disable systemctl stop на крайний случай systemctl mask Не работает разве отклчение? Или я чего не понял? http://lexpr.ru/node/503
Re: systemd
On Fri, Nov 13, 2015 at 01:05:00PM +0300, Max Dmitrichenko wrote: > 13 ноября 2015 г., 12:36 пользователь Eugene Berdnikov > написал: > > Скажем так: "можно" это меньше 15 минут, "невозможно" это больше 15. > > Именно столько готов потратить юзер на поиск утилиты, которая > > расшифрует ему протокол, если таковая существует. Если же нет, > > то никто ни писать дешифратор, ни даже покупать техподдержку > > не будет. Просто забьёт на глюкало вместе с его протоколом, > > в результате протокол и глюкало сдохнут вместе. > > Таки интересные вещи вы тут рассказываете. А чё скайп-то до сих пор > жив? Бинарный, глюкавый, без дешифраторов, например. Не знаю, бинарный ли протокол у скайпа: он закрыт и зашифрован, нигде кроме скайпа не используется, никто из пользователей не пытается его разобрать, так что в контексте нашей дискуссии пример мимо тазика. > Или вот появилась > же как-то Samba, которая проимплементила бинарный закрытый глюкавый > протокол. В результате трудоёмкость диагностики проблем виндовых клиентов превышает все пределы разумного. Потому что невозможно понять без поллитры, что хочет клиент и что ему отвечает сервер. В данном случае закрытость и вычурность протокола -- инструмент Майкрософта в конкурентной борьбе со всем остальным программистским комьюнити, т.е. путь войны, а не конструктивного сотрудничества, это и есть зло в чистом виде. И поскольку всё человечество победить невозможно, рано или поздно MS проиграет всем, начиная с Гугла. Базовый формат XML для офиса (docx, xlsx..) это показательно. -- Eugene Berdnikov
Re: systemd
On Fri, Nov 13, 2015 at 11:31:50AM +0300, Artem Chuprina wrote: > Иван Лох -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 00:34:47 > +0300: > > >> > Но в данном случае достаточно установить RuntimeDirectory= > >> > и systemd ее почистит после остановки сервиса > >> > >> А перед? Остановка сервиса может быть по броску питания. > > ИЛ> Думаю, что да. Но в любом случае это поддиректория /run > ИЛ> и находится на tmpfs. По скачку очистится. > > После срабатывания OOM killer не очистится. А здесь точно очистится. systemd следит за состоянием служб (наличием PID в списке процессов и т. д.) чистит, переапускает
Re: systemd
13.11.2015 11:33, Artem Chuprina пишет: Илья -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 10:53:59 +0300: >>> Что-то много текстопротокольного фанатизма, протоколы это не художественная >>> литература, бинарные протоколы это норма, никто не заставляет руками набирать >>> бинарные сообщения в hex редакторе, всегда есть/можно написать простую утилиту >>> которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть >>> отладочную инфу нет смысла все сто лет иметь оверхед от текстового протокола >> >> пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо >> что-то пропустил И> Для начала, стоит наверное определится что такое текстовый протокол. И> Если понимать под этим символьное (UTF,koi) представление данных и служебной И> информации, то в этом случае объем передаваемой информации больше, чем у как И> то кодированого. Больше объем - больше требуется ресурсов. В качестве примера И> можно рассмотреть HTML + XML + JS. Ну или скрипты java (размер исходника, И> компилятор,java машина) против бинарной программы на СИ. И> Я считаю, что тут проблема не в самих протоколах, а в том как их И> используют. Мегабайтные странички в памяти и браузер сжирающий процессор это И> писец - но это не проблема в самом протоколе http. И не в протоколе HTML. Память и процессор он сжирает вовсе даже бинарными структурами. Это какими? Если исключить flash и медиа, то остается js со всякими json,xml,css, cookies.Есть еще вроде gzip не текстовый но позволяет быстрее передать текстовые мегабайты. Что то еще? wget www.google.ru - найдется все :)
Re: systemd
Илья -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 13:17:30 +0300: >> >> Призовая игра. Апгрейд. >> Так к nginx они будут приходить, и systemd будет пытаться поднять его. >> Поднимет, а от него уже пойдут запросы к движку. Предлагаем остановить >> systemd? :) И> systemctl disable И> systemctl stop И> на крайний случай И> systemctl mask И> Не работает разве отклчение? Или я чего не понял? Да нет, я сразу сказал, что такая функциональность у systemd наверняка есть, она нужна ну всем ваще. А точно я не знаю, поскольку у меня systemd отсутствует. Поэтому я не пытался обвинять systemd в том, что ее у него нет, я всего лишь говорил, что это нас опять от декларативных конфигов приводит к процедуре. А дальше мне предложили стопить nginx, чтобы запросы не поднимали стоящий за ним unicorn. Я объясняю, что это - попытка свести задачу к эквивалентной, но на соседней улице.
Re: systemd
On Fri, Nov 13, 2015 at 02:05:13PM +0300, Иван Лох wrote: > On Fri, Nov 13, 2015 at 11:31:50AM +0300, Artem Chuprina wrote: > > Иван Лох -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 00:34:47 > > +0300: > > > > >> > Но в данном случае достаточно установить RuntimeDirectory= > > >> > и systemd ее почистит после остановки сервиса > > >> > > >> А перед? Остановка сервиса может быть по броску питания. > > > > ИЛ> Думаю, что да. Но в любом случае это поддиректория /run > > ИЛ> и находится на tmpfs. По скачку очистится. > > > > После срабатывания OOM killer не очистится. > > А здесь точно очистится. systemd следит за состоянием служб > (наличием PID в списке процессов и т. д.) чистит, переапускает И да, кстати, одна из фишек systemd проистекающая из его тесной связи с cgroups это разумное и легко настраиваемое поведение OOM killer для служб
Re: systemd
> Что-то много текстопротокольного фанатизма, протоколы это не > художественная > литература, бинарные протоколы это норма, никто не заставляет руками > набирать > бинарные сообщения в hex редакторе, всегда есть/можно написать простую > утилиту > которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть > отладочную инфу нет смысла все сто лет иметь оверхед от текстового > протокола пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо что-то пропустил >> И>>> Для начала, стоит наверное определится что такое текстовый протокол. И>>> Если понимать под этим символьное (UTF,koi) представление данных и служебной И>>> информации, то в этом случае объем передаваемой информации больше, чем у как И>>> то кодированого. Больше объем - больше требуется ресурсов. В качестве примера И>>> можно рассмотреть HTML + XML + JS. Ну или скрипты java (размер исходника, И>>> компилятор,java машина) против бинарной программы на СИ. И>>> Я считаю, что тут проблема не в самих протоколах, а в том как их И>>> используют. Мегабайтные странички в памяти и браузер сжирающий процессор это И>>> писец - но это не проблема в самом протоколе http. >> >> И не в протоколе HTML. Память и процессор он сжирает вовсе даже >> бинарными структурами. >> > Это какими? Если исключить flash и медиа, то остается js со всякими > json,xml,css, cookies.Есть еще вроде gzip не текстовый но позволяет > быстрее передать текстовые мегабайты. Что то еще? html парсится в DOM, на стадии парсинга и передачи по сети накладные расходы если посчитать и сравнить их с расходами на рендеринг, наложение стилей и прочая прочая, то получится что парсинг html - самая простая задача. решается где-то 500-ми строк кода парсера. -- . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 signature.asc Description: Digital signature
Re: systemd
Max Dmitrichenko -> Eugene Berdnikov @ Fri, 13 Nov 2015 13:05:00 +0300: >> Скажем так: "можно" это меньше 15 минут, "невозможно" это больше 15. >> Именно столько готов потратить юзер на поиск утилиты, которая >> расшифрует ему протокол, если таковая существует. Если же нет, >> то никто ни писать дешифратор, ни даже покупать техподдержку >> не будет. Просто забьёт на глюкало вместе с его протоколом, >> в результате протокол и глюкало сдохнут вместе. MD> Таки интересные вещи вы тут рассказываете. А чё скайп-то до сих пор MD> жив? Бинарный, глюкавый, без дешифраторов, например. Или вот появилась MD> же как-то Samba, которая проимплементила бинарный закрытый глюкавый MD> протокол. Ну да. И в результате работа с SMB - одно из самых глюкавых мест в нынешних линуксах вот уже лет 15. >> Главное достоинство текстовых протоколов не столько в читабельности >> (это действительно решается правильным логгингом и декодерами), >> сколько в гибкости и лёгкой расширяемости под СВОИ нужды. Скажем, >> добавить лишнюю опцию вроде ECN в ip-хедер проблематично без комитета, >> а добавить лишний хедер в HTTP может любой, никого не спрашивая. >> Причём так, что этот хедер ничему мешать не будет. >> Эта возможность важнее 100 лет оверхеда. :) MD> Таки IP-хедер продукт старой школы. Бинарные TLV структуры, с MD> выделенным пространством T для vendor extension's - давно используются MD> во многих протоколах. Это, опять же, сведение задачи, ну не к эквивалентной, но весьма схожей - нужно централизованное выделение подпространств в этих пространствах, как с OID в ASN.1 (это, безусловно, проще, чем каждый раз править протокол, но тем не менее), а то будут клэши. И размер идентификатора довольно быстро растет. Зато, правда, есть именно что гарантия отсутствия клэшей, а не просто хороший шанс, как в случае добавления значимого текстового имени. Зато под СВОИ нужды как раз становится неудобно расширять. В HTTP добавил СВОЙ хедер, носишь его к СВОЕМУ серверу - и ничего тебя не гондурасит. Контент все равно парсишь, если он парсится плохо - игнорируешь. Избыточности для обнаружения того, что что-то тут не так, в текстовом протоколе достаточно. А в случае с TLV, если ты не прошел процедуру получения своего подпространства имен, шанс нарваться на то, что тебе принесут с тем же T совершенно другое по замыслу отправителя V, заметно возрастает из-за неизбыточности кодирования. Естественные языки избыточны не просто так...
Re: systemd
13.11.2015 13:48, Eugene Berdnikov пишет: On Fri, Nov 13, 2015 at 01:05:00PM +0300, Max Dmitrichenko wrote: 13 ноября 2015 г., 12:36 пользователь Eugene Berdnikov написал: Скажем так: "можно" это меньше 15 минут, "невозможно" это больше 15. Именно столько готов потратить юзер на поиск утилиты, которая расшифрует ему протокол, если таковая существует. Если же нет, то никто ни писать дешифратор, ни даже покупать техподдержку не будет. Просто забьёт на глюкало вместе с его протоколом, в результате протокол и глюкало сдохнут вместе. Таки интересные вещи вы тут рассказываете. А чё скайп-то до сих пор жив? Бинарный, глюкавый, без дешифраторов, например. Не знаю, бинарный ли протокол у скайпа: он закрыт и зашифрован, нигде кроме скайпа не используется, никто из пользователей не пытается его разобрать, так что в контексте нашей дискуссии пример мимо тазика. В данном случае закрытость и вычурность протокола -- инструмент Майкрософта в конкурентной борьбе со всем остальным программистским комьюнити, т.е. путь войны, а не конструктивного сотрудничества, это и есть зло в чистом виде. И поскольку всё человечество победить невозможно, рано или поздно MS проиграет всем, начиная с Гугла. Базовый формат XML для офиса (docx, xlsx..) это показательно. Базы данных тоже в тестовом виде хранить надо? Шифрование, нормализацию, индексацию и деревья отменить :) Я считаю иногда нужно все таки идти на компромис, все зависит от решаемых задач, а не удобства. А отсуствие у пользователя утилит для парсинга протоколов это уже не проблема протокола
Re: systemd
Илья -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 14:12:25 +0300: >> >>> Что-то много текстопротокольного фанатизма, протоколы это не >> художественная >> >>> литература, бинарные протоколы это норма, никто не заставляет руками >> набирать >> >>> бинарные сообщения в hex редакторе, всегда есть/можно написать >> простую утилиту >> >>> которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть >> >>> отладочную инфу нет смысла все сто лет иметь оверхед от текстового >> протокола >> >> >> >> пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо >> >> что-то пропустил >> >> И> Для начала, стоит наверное определится что такое текстовый протокол. >> И> Если понимать под этим символьное (UTF,koi) представление данных и >> служебной >> И> информации, то в этом случае объем передаваемой информации больше, чем >> у как >> И> то кодированого. Больше объем - больше требуется ресурсов. В качестве >> примера >> И> можно рассмотреть HTML + XML + JS. Ну или скрипты java (размер >> исходника, >> И> компилятор,java машина) против бинарной программы на СИ. >> И> Я считаю, что тут проблема не в самих протоколах, а в том как их >> И> используют. Мегабайтные странички в памяти и браузер сжирающий >> процессор это >> И> писец - но это не проблема в самом протоколе http. >> >> И не в протоколе HTML. Память и процессор он сжирает вовсе даже >> бинарными структурами. И> Это какими? Если исключить flash и медиа, то остается js со всякими И> json,xml,css, cookies.Есть еще вроде gzip не текстовый но позволяет быстрее И> передать текстовые мегабайты. Что то еще? Структурами в памяти, в которые он транслирует вышеперечисленное. Он же жрет процессор и память, а не сеть. Поскольку флеш и прочая медия у меня без явного пинка не запускается, в первую очередь я грешу на выполнение js. Но и парсинг XML, по крайней мере у firefox, по крайней мере раньше, был очень так себе в смысле потребления памяти. Куда он ее столько жрал - не знаю, но жрал конкретно.
Re: systemd
On Fri, Nov 13, 2015 at 02:34:15PM +0300, Dmitry E. Oboukhov wrote: > наложение стилей и прочая прочая, то получится что парсинг html - > самая простая задача. решается где-то 500-ми строк кода парсера. xhtml если только
Re: systemd
13.11.2015 14:20, Artem Chuprina пишет: Илья -> debian-russian@lists.debian.org @ Fri, 13 Nov 2015 13:17:30 +0300: Да нет, я сразу сказал, что такая функциональность у systemd наверняка есть, она нужна ну всем ваще. А точно я не знаю, поскольку у меня systemd отсутствует. Поэтому я не пытался обвинять systemd в том, что ее у него нет, я всего лишь говорил, что это нас опять от декларативных конфигов приводит к процедуре. А дальше мне предложили стопить nginx, чтобы запросы не поднимали стоящий за ним unicorn. Я объясняю, что это - попытка свести задачу к эквивалентной, но на соседней улице. А я понял, что systemd как раз есть уход от скриптового управления службами к декларативным.
Re: systemd
Max Dmitrichenko wrote: > 12 ноября 2015 г., 15:56 пользователь Dmitry Alexandrov > <321...@gmail.com> написал: > > On 11/11/15 18:29, Alexey Shrub wrote: > > > >> А параллельная загрузка? > > > > > > О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об???яснит, чего с > > ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной > > торбой? Зачем она вообще нужна? > Windows 8 дюже быстро загружается ) Конкуренция, однако. Она быстро загружается потому, что свято верит в неизменность незакрытого тома с прошлого отключения. Как только эта вера спотыкается об реальность - том-то где-то смонтировали прочекали - вся быстрота улетучивается.
Re: systemd
On Fri, 13 Nov 2015 14:29:43 +0300 Илья wrote: > Базы данных тоже в тестовом виде хранить надо? Шифрование, > нормализацию, индексацию и деревья отменить :) Почувствуйте разницу между "хранить" и "передавать". А лучше прочитайте 24-ю главу документации на PostgreSQL где подробно разбирается почему у pg_dump текстовый формат, и почему индексы в дамп не попадают. Можно все что угодно с целью оптимизации держать в каких-то процессор-специфичных структурах. Но когда информация попадает на долговременный носитель или передается по сети, то есть ставится задача прочитать его на другой машине, с другим порядком байт и другим размером машинного слова, требуется некое универсальное представление. Текст по определению является таким представлением, потому что предназначен для человека, а человек - мера всех вещей. Была уже история, что оцифровали какую-то древнюю британскую летопись и выпустили тираж на сидюке. Через десять лет выяснилось, что прочитать тот сидюк уже не на чем - та аппаратная платформа под которую он делался вымерла. А исходный манускрипт 1000-летней давности прекрасно читается. Кстати, между прочим, бинарное представление XML/SGML в виде DOM с которым работают браузеры, форматтеры и xslt-преобразователи занимает обычно в 10 раз больше места, чем текстовый формат в utf-8. То же самое с индексами. Ситуация когда единичный индекс (я уж не говорю про все множество индексов к данной таблице) занимает больше места, чем сама таблица - совершенно рядовая.
