Vlákno názorů k článku
Šéf Mandrivy: zruinovaly nás soudní spory se zaměstnanci od Metrák - Dobrý, teď se ještě zbavit KDE + Evolution...

Vypínání je zbytečný. Ostatně, může si přes genitálně nastavený polkit + sudo změnit systémový čas, získat roota a pak to konečně vypnout. Pokrok nezastavíš!

Nechápu, jaké násilí spatřujete v zapalování pneumatik na krku mrtvoly. Je to sice dost nechutné, ale mrtvoly se obvykle příliš nebrání ;-)

Nejde teda spíš o politickou zombie?

Upír - důchodce. Dřív mi totiž dost pil krev, ale moje krevní skupina mu zjevně nedělala dobře. Teď je zjevně díky podlomenému zdraví někde ukrytej a tak maximálně občas neškodně cení zuby. Škoda pneumatiky, podle mě.

Skutečně je násilí jediným způsobem? :) Třeba by Jarda uměl Hitlera ukecat, že Židy miluje nebo že se nemá stát politikem.

Neříkám, že by to nutně bylo lepší řešení, než jak to skutečně bylo, nicméně myslím si, že je vždy více řešení, než jen jedno.

Skutečně je násilí jediným způsobem? :)

To jistě ne. Např. Lael by mohl uspořádat vůdcovi několik agitačních přednášek, možná by to uspíšilo jeho sebevraždu o mnoho let. :-D

Nepřeceňujte mě. Vy jste četl spoustu mých textů, a zatím to nezabralo ;)

Kéž by...

Kdyby treba nekdo vcas zabil Hitlera nabo Stalina, spousta pruseru by nikdy nevznikla.

K tomuto doporučuji knihu Making History od Stephena Frye

Ad navrhovat násilí jako řešení toho, že někdo jiný maká způsobem, co se ti nelíbí, to vážně nemáš nárok - naprostý souhlas. Ještě by to měli uživatelé Linuxu vzít za své, než začnou psát o donucování výrobců HW dodávat počítače s jejich oblíbeným systémem. Princip je totiž stejný: člověk nemá ostatním co zasahovat do jejich svobod. A to že někdo píše SW způsobem který uzná za vhodný, nebo dodává HW v konfiguraci kterou uzná za vhodnou, je jednoznačně věc svobody.

Jarda to psal z legrace, což průměrně inteligentní člověk pochopí. Pravda, reklamní troll s tím může mít jisté potíže.
Jinak Poettering je opravdu magor, což vám potvrdí každý, kdo se s ním osobně setkal. Kromě toho produkty jeho choré mysli, to je tragédie v duchu nejlepších tradic vašeho zaměstnavatele, takže úvaha, zda nejde o vašeho trójského koně nebo nástroj RedHatu k ovládnutí dister, je zcela na místě.

Pokud jsou ty produkty skutečně tak špatné, proč je všichni chtějí?

Proč je nutné označovat jiné za magory, když nesouhlasíme s jejich názorem? -- Například škola Montesori říká, že učitel nehodnotí žáka, protože tím se staví do pozice někoho lepšího, znalejšího. Když už (vyjímečně) hodnotí, tak práci, nikoli žáka.

Tj. říká: Dobrá práce nebo To se (ti) opravdu nepovedlo.

Ale neříká: Jseš borec! nebo Jseš magor!

Dále přiřazení nějaké vlastnosti osobě zní definitivně - jseš magor nadosmrti.
Kdežto když se něco nepovede, ... každému se někdy něco nepovedlo, je to běžný stav, nic výjimečné.

Přirovnávat někoho k Hitlerovi vzhledem k jeho skutkům nepovažuji za povedenou legraci.

Já jsem si myslel že systemd se intenzivně vyvíjí a ne že je dodělaný :) osobní zkušenost zatím nemám, ale vím, že když někdo (třeba já) něco vyvíjí, tak je v tom plno chyb.
Dobrá, souhlasím, že něco, co se nasazuje na produkční servery by mělo být odladěné.

Třešnička: Není jedno jestli pro prohlížení logu použiju příkaz cat nebo jiný příkaz?

Ve chvíli, kdy budete ty logy lovit třeba na disku, kde havaroval, z libovolného důvodu, file systém, to uvidíte naprosto jinak.
A jestli chcete vidět opravdovou lahůdku, mrkněte třeba na systemd generators. Něco tak blbého se jinde těžko vidí.
Systemd je z jiného světa, který je s unixovými OS obtížně slučitelný. Mrzí mě, že se ta banda přilepila zrovna na Linux, kde v poslední době dělá spoustu škod - vzniká podivný hybrid, kde bude vše souviset se vším tak jako u produktů společnosti, která nám sem nasadila toho trolla LO.

Dívám se do /var/log v Debianu Jessie se systemd a kromě btmp, lastlog and wtmp (které se systemd nemá nic společného) žádné binární logy nevidím. Co dělám špatně?

A není to náhodou tím, že z blabla-journald to do txt tahá nějaký standardní syslog démon?
Takže opatření distribuce, aby to pro adminy ještě aspoň chvíli bylo snesitelné... než to velikým vizionářem bude prohlášeno za nepřípustné a bude to zakázáno?

Sakra, proč se lidi jako vy a Poettering motají kolem Unixu?

Ne, je to protože systemd journal je pouze v paměti (tmpfs) a slouží pro rychlé třídění nedávných záznamů (debugovaní s ním je opravdu výrazně rychlejší, než procházet textové logy a hledat, co souvisí s čím; ale musíte to se naučit používat, což zde bude nejspíš ten hlavní problém), zatímco dlouhodobé záznamy se odesílají do vhodného úložiště ve formátu toho úložiště. Výchozí jsou textové logy ve /var/log, ale klidně se to může posílat třeba do SQL databáze nebo Google Analytics.

Pochybuju, že v Debianu se někdy bude něco měnit jen proto, že někdo něco prohlásí za nepřípustné.

Journal pokud vim neumi textovy logy, nebot lennart prohlasil, ze je to nanic, takze tam musi bezet nejakej dalsi logdemon, kterej to jako text uklada ... zatim.

A jak je to rychly sem si uz parkrat pocet ... ze pri 1GB logu se to zhrouti a je to zcela nepouzitelny, pricemz grep z textu funguje i pro TB. Ostatne, presne stejne se chovaj widli logy ... neni to tak davno, co po me nekdo chtel, abych logoval pristupy k souborum na disku, tak sem to zkousel ... naprosto nepouzitelny, generuje to miliony zaznamu, ktery pak nejde ani zobrazit, a navic jejich vypovidaci schopnost je nula.

A jako bonus, když se celá slavná binární srágora zhroutí, tak Lennartovo řešení zní "tak ten log smaž".

Po příchodu PA do fedory mi přestal fungovat audio loop z levné, ale rychlé TV karty. Tehdy jsem ještě nevěděl kdo je LP. Když jsem hledal co s tím, postupně jsem se dobral odpovědi, že zastaralý HW je nezajímá a na rozdíl od minula si teď můžu poslat zvuk na jiný počítač...

A takhle ortogonálně k mým potřebám se Lennartware a jeho apologetové chovají dosud.

A protoze tomu nerozumis a neumis to opravit, tak tu zvanis tyhle nesmysly o najimani vraha? Clovece, chapes, ze tohle uz neni sranda a jsi fakt mimo?

Nechapu redakci, jak tu muze tyhle nazory trpet.

Presne podobne problemy som mal na Kubuntu (priatelkin PC)... Presla na OpenSUSE a zatial je vsetko ok...

Jj ale ako pise nizsie Sten mozno to bolo len blbo nakonfigurovane... Neviem v konfigurakoch som sa velmi nehrabal a stare si akosi neukladam... Ono aj ten prechod na OpenSUSE nebol len kvoli PA... Kubuntu po aktualizacii (LTS) uz proste nechcelo nabehnut do KDE... najrychlesia moznost bola preinstalovat to a a dat nieco s cim bezny uzivatelia nemaju problem... Vyhralo OpenSUSE...

Systemd jsem viděl jen z rychlíku. Ale dalo by se argumentovat, že nemůže být horší než to klubko init skriptů, které nemá žádné API pro zjištění jaké máte v systému služby, zjištění jejich stavu, jejich zastavení, spuštění, přidání služby, nastavení kontextu ve kterém služba běží atd.

Zadne api netreba, protoze v tuxovi kdyz nekdo sluzbu spusti, tak proste bezi, az dokud ji neukonci. Zato ve widlich aby clovek nejdriv podriz slepici za uplnku a skropil stroj jeji krvi, protoze jinak se mu sluzbu treba ukoncit nepovede, protoze to uzasny api se rozhodlo, ze to proste nejde.

Wow, už i redakce si všimla stylu vašich příspěvků?

API samozřejmě je potřeba, protože ne vždy služby spouští a zastavuje manuálně admin. A samozřejmě je dobré mít API i na zakládání služby, změnu vlastností (kontext, popis, způsob spouštění, akce když služba selže). Zkuste nevidět svět jen z role admina.

Ad ve widlich... se mu sluzbu treba ukoncit nepovede, protoze to uzasny api se rozhodlo, ze to proste nejde - Service Manager posílá službě signál k ukončení. Pokud služba neodpovídá, tak to jaksi není chyba API ani Service Manageru. Na Linuxu to nakonec máte udělané dost podobně: init skript pošle službě signál k ukončení, a služba ho může a nemusí akceptovat. Pochopitelně by bylo možné procesy natvrdo odstřelovat, ale tím si jen říkáte o problémy.

lol ... kdyz admin rekne UKONCIT, tak system proste sluzbu ukonci i kdyby ji mel natvrdo odstrelit, To je jeho UKOL, to je JEDINEJ duvod, proc tam system je.

Dojebany widle se pak radsi ani nerestartnou, ale nejde se na ne ani pripojit, protoze proste neco uz odstrelili ale neco ne, a cekaji na smilovani bozi ... lol. Vzivote bych nedal widle na stroj, kterej nema draca nebo neco takovyho, protoze bez moznsoti na dalku navrdo dat reset, bych neustale musel jezdit na vejlety, protoze widle neco neukoncily.

A systemd je presne stejne dojebanej jako ty widle.

Ad kdyz admin rekne UKONCIT, tak system proste sluzbu ukonci i kdyby ji mel natvrdo odstrelit - super nápad. Když například DB právě zakládá nový soubor a minutu se přehrabuje na disku a ve vlastních strukturách, tak je nejlepší nápad prostě ustřelit proces :). Nechce se mi věřit, že by si vás někdo platil jako admina.

Ad widle se pak radsi ani nerestartnou - Windows nakonec servis odstřelí, pokud si nevyžádal dodatečný čas pomocí volání API. Pokud systém nelze restartovat, asi jste narazil na zombie process. Na Unixech se to stává také.

Ad bych neustale musel jezdit na vejlety, protoze widle neco neukoncily - kupodivu veliká spousta firem má stroje v serverovnách, a jejich pracovníci si výlety dělat nemusí, stejně jako si je nedělám já. Samozřejmě jeden nikdy neví, a je dobré mít pro jistotu možnost i stroj vzdáleně otočit.

super nápad. Když například DB právě zakládá nový soubor a minutu se přehrabuje na disku a ve vlastních strukturách, tak je nejlepší nápad prostě ustřelit proces :)

Tak jistě. A když právě někdo něco hacknul, tak ho necháme samozřejmě dodělat jeho práci, přece mu to nebudu kazit pod rukama. A když má spammer zrovna rozdělanou rozesílku mailů, tak mu přece nějakej pitomej admin nemůžu shodit mailserver, no ne?

Super nápad.

V prvním případě můžete sestřelit proces. V druhém případě není problém, protože mail server typicky lze zastavit po přenosu každé zprávy.

Kupodivu lze normalni mailserver zastavit zcela kdykoli. A kupodivu se normalni sluzba ukonci okamzite a bez kecu. A kupoduvu databaze uz par patku umeji transakce, a kdyz tu databazi strelim v polovine, tak se to proste priste rollbackne ... zazrak.

A nejakym zazrakem taky muze nekdo odpojit nekde sitovej kabel, a mail se nedoprenasi ... strasny. Nj, s tim M$ tvorba nepocita ... chapu. Jejich neustale rozesranou exchange databazi je primo posusnani opravovat. A co teprve kdyz nekdo hleda nejakej smazlej mail ... nebo ma dokonce tu drzost pouzivat pravidla ...

Ad Kupodivu lze normalni mailserver zastavit zcela kdykoli - kupodivu je to přesně to co jsem psal.

Ad kupoduvu databaze uz par patku umeji transakce, a kdyz tu databazi strelim v polovine, tak se to proste priste rollbackne - jednak ne všechny, a potom se to netýká ve všech případech změny interních struktur DB.

Ad nejakym zazrakem taky muze nekdo odpojit nekde sitovej kabel, a mail se nedoprenasi - a co to s tím má společného?

Ad kupodivu se normalni sluzba ukonci okamzite a bez kecu - většinou se služby opravdu ukončí poměrně rychle. Když se ovšem služba odmítne ukončit, například protože se sekla nějaká akce, tak to může dopadnout jinak. To byste samozřejmě věděl, kdybyste v životě nějakou službu napsal, nebo alespoň věděl jak fungují.

To se ovšem zřejmě týká aplikace, nikoliv služby. WinXP uživateli aplikace při odlogování/shut­downu nesestřelí, protože v nich může mít neuložená data. Ne každá aplikace totiž umí při ukončování session uložit svůj stav a ukončit se.

Ad zminena sracka patri k ovladaci grafiky - jistě. Driver (ani grafické karty) nesmí poskytovat uživatelský interface, a aplikace běžící ve vaší session nesmí mít přímý přístup k HW. Takže máte driver, a ve vaší session pak běží user-mode aplikace, která si s tím driverem povídá. Jinými slovy je to aplikace jako každá jiná.

Ad proc tam bezi jakysi progress bar timeoutu, kdyz na konci se to zastavi a nic - progress bar aby uživatel viděl že se něco děje. Pokud akce nedoběhne v typickém čase, tak se zobrazí dialog o běžících aplikacích, s možností je odstřelit.

Ad kdyz reknu shutdown tak shutdown - což by způsobilo spoustu nepříjemností lidem, kteří si neuložili data v aplikaci. Pokud chcete opravdu provést shutdown (a případně díky tomu ztratit neuložená data), tak je v tom dialogu tlačítko Force, nebo jak se to ve WinXP jmenovalo.

Udělej si na ploše zástupce shutdown /t 0 /s /f - protože u MS usoudili, že zachrání všechny debily světa, co si před vypnutím počítače neumí uložit práci (což stejně u spousty aplikací nefunguje, naopak to "funguje" u úplných nesmyslů, kde žádné práce k uložení není.

přičemž na rozdíl od inittab jdou spouštět v určitém pořadí a i vypnout,

No, vypnout právě nejdou vůbec, natož v určitém pořadí. Vono totiž pochopit, že stop znamená, že službu chci prostě zastavit a ne to, že si ji nějaká socket sračka může kdykoliv zase zapnout, to už holt chce pořádného fištróna, že...

Pokud zavoláte stop na službu, kterou může spouštět socket, tak vás to upozorní, že se to může stát, prostě protože stop znamená (a když nad tím zauvažujete, tak je to celkem logické) „vypni to, dokud to někdo opět nezapne“, přičemž ten někdo může být i nějaký trigger. Pokud chcete službu odstavit tak, aby ji nikdo nemohl znovu spustit, dokud ji opět nepovolíte, tak použijte disable.

a když nad tím zauvažujete, tak je to celkem logické

Samozřejmě, v duchu Lennartovy "logiky" to je úplně logické... škoda mluvit.

Triggery se chovají stejně jako xinetd. U toho taky sestřelení procesů neznamená, že by se nové nespouštěly, musíte tu službu deaktivovat.

Tak určitě...

Když si vypnete doma jističe a dostanete při opravě zásuvky pecku, protože Vám je mezitím někdo jiný zapnul, tak si půjdete (nebo Vaši pozůstalí) stěžovat výrobci jističů?

Mimochodem odkdy se vypnout překládá jako stop?

Když vypnu jističe, tak neočekávám, že si je bojler sám zapne...

V systemd se služba nezapíná jen tak sama, zapíná se, když ji někdo vyžaduje. Když vypnete jističe a soused bude chtít teplou vodu, nejspíš je taky nenechá vypnuté.

Ne, soused co se vraci z dovoleny vytoci cislo, a boiler si sam jistice nahodi ...

A nejen ze systemd neumi sluzby vypnout, on je neumi ani zapnout, viz tisk ... lol ... misto aby proste nastartoval demon, tak se pusti podelanej socket ... a pak se na nej posila request, aby system vubec vedel, ze nejaky tiskarny ma ... lol lol lol.

Tak si změňte nastavení, ať se takhle systemd nechová ;-) Tahle nastavení vůbec nejsou součástí zdrojáků systemd, ale jednotlivých služeb.

Disable taky nefunguje. "Řešení" => NOTABUG. Lennartův inteligentní "workaround" kolem debilního designu toho paskvilu je symlink do /dev/null. Lejno (_|_) sračka, Lennartwaru značka!

Tohle se týká jen rc-local.service, která je specifická, protože jde o emulaci rc.local v sysvinitu, kde se to chovalo stejně debilně. Aneb: o kolik by bylo systemd jednodušší, kdyby se nemuselo zabývat zpětnou kompatibilitou se sysvinitem.

Ne, von celý systemd je "specifický". Protože stop (zastavit službu do explicitního spuštění a disable (vypnout navždy, dokud to někdo znova ručně nezapne) by bylo moc logické. Takže stop je de facto k ničemu, disable funguje jen někdy a navrch budeme vymýšlet 3,14viny se symlinky do /dev/null. N

emluvě o tom, k čemu vede ta krávoviny se socket-base aktivací, kterou je samozřejmě nutno cpát naprosto všude, ačkoliv se k tomu absolutně nehodí, že.

Příklad: rozbijeme tisk, to nikdo nepotřebuje, přece! https://bugzilla.suse.com/show_bug.cgi?id=857372

stop (zastavit službu do explicitního spuštění a disable (vypnout navždy, dokud to někdo znova ručně nezapne)

Jaký je v tom rozdíl?

rozbijeme tisk, to nikdo nepotřebuje, přece!

Jistě, to, že na serveru služba by default nenaslouchá na vnějších portech, protože když to dělala, byla to zranitelnost s CVE, za to určitě může systemd.

Jaký je v tom rozdíl?

V čem jako je jaký rozdíl?

Jistě, to, že na serveru služba by default nenaslouchá na vnějších portech, protože když to dělala, byla to zranitelnost s CVE, za to určitě může systemd.

Zjevně jsi absolutně nepochopil problém. To asi bude tím, že ses neobtěžoval přečíst si víc než ten nadpis.

V čem jako je jaký rozdíl?

Jaký je rozdíl mezi vámi definovanými akcemi stop a disable? Podle mě dělají totéž.

Zjevně jsi absolutně nepochopil problém. To asi bude tím, že ses neobtěžoval přečíst si víc než ten nadpis.

Ne, to bude spíš tím, že jsem četl i reakce, ne jen prvních několik řádek. Přečtěte si komentáře #17 a #66, kde se vysvětluje, proč systemd nastavuje výchozí hodnoty tak, aby tam nebyla bezpečnostní díra, a komentář #140, kde je jasně uvedeno, že za celou situaci může YaST, ne systemd.

Jaký je rozdíl mezi vámi definovanými akcemi stop a disable? Podle mě dělají totéž.

Aha. Takže když rebootnu systém, tak dostanu totéž? Vážně?

Přečtěte si komentáře #17 a #66, kde se vysvětluje, proč systemd nastavuje výchozí hodnoty tak, aby tam nebyla bezpečnostní díra

Zkus použít tu hmotu, co máš v makovici, a zamysli se nad tím, proč jsme s použitím toho úžasného Lennartova křápu dospěli do stavu, kdy to, co léta bez problémů fungovalo, již nefunguje. (Ne, s bezpečnostní dírou ani YaSTem to nemá absolutně nic do činění.)

Aha. Takže když rebootnu systém, tak dostanu totéž? Vážně?

Podle vás by se ta služba měla spustit, jen když jí explicitně řeknete, že může. Restart systému je trigger, úplně stejně jako socket, nic explicitního pro danou službu, takže by mělo být špatně, že se služba po restartu spustila. Co když ten restart byl způsobený výpadkem proudu nebo nekompetentním adminem, který zmáčkl reset na jiném stroji, a ta služba stále není správně nastavená?

Zkus použít tu hmotu, co máš v makovici, a zamysli se nad tím, proč jsme s použitím toho úžasného Lennartova křápu dospěli do stavu, kdy to, co léta bez problémů fungovalo, již nefunguje. (Ne, s bezpečnostní dírou ani YaSTem to nemá absolutně nic do činění.)

Protože se místo spuštění spousty služeb, kterou většinu času nikdo nepotřebuje, rozhodli ty služby spouštět, jen když je někdo opravdu potřebuje, a Red Hat to do své distribuce zařadil, aniž by to jeho konfigurační nástroj podporoval. Zajímavé, že v Debianu tohle funguje.

Aha. Nojo, RedHat. S YaSTem a řeší to Na SUSE bugzille. Hlavně, že sis ten bug důkladně pročetl, viď. To snad není pravda. Vidím, že předpoklad o hmotě v makovici byl zcela mylný.

Ano, je to SuSE, hrozná ostuda, používal jsem ho naposledy před patnácti lety, už si nepamatuju, co tyhle distribuce, kam se cpe každá vývojová verzi každého software, používají za Reinvented-Wheel konfigurační nástroje.

Děkuji za komentář ad hominem, třeba se někdy dočkáme i věcného komentáře.

Tak jistě, můžou za to konfigurační nástroje typu reinvented-wheel. Pochopitelně. Protože prostě ta socket-based aktivace na tom printserveru poběží, kdyby trakaře padaly, hadi měli blít a letadla couvat. Řekl to tak soudruh Lennart a tak to je správné a tak to musí být, soudruzi! Kázeň, kázeň je to hlavní!!! Co na tom, že uživatelé nevidí tiskárny. Hlavně že na tiskovém serveru neběží zbytečně tisková služba!!!

Protože prostě ta socket-based aktivace na tom printserveru poběží, kdyby trakaře padaly, hadi měli blít a letadla couvat. Řekl to tak soudruh Lennart a tak to je správné a tak to musí být, soudruzi!

Lennart neurčuje, co bude nebo nebude v SuSE.

Hlavně že na tiskovém serveru neběží zbytečně tisková služba!

Pokud někdo provozuje tiskový server, tak ho taky musí tak nastavit. Je na to potřeba jeden příkaz, kterým se změní funkce z lokálního serveru na sdílený. Jak hrozné! Lol Phirae to nezvládá!

Ten tiskový server léta a léta bez Lennarta prostě fungoval. Připojils tiskárnu, CUPS ji přes broadcast našel, když jsi ji nasdílel, nabídnul ji pro všechny počítače v síti, ty ji viděly a mohly na ní tisknout.

https://www.cups.org/documentation.php/doc-1.5/sharing.html

CUPS browsing works by periodically broadcasting information about printers that are being shared to client systems on the same subnet. Each client maintains its own list of shared printers, and when more than one server shares the same printer (or the same kind of printer) the client uses all of the servers and printers to provide high-availability and failsafe printing.

To configure printers on the same subnet, do nothing. Each client should see the available printers within 30 seconds automatically. The printer and class lists are updated automatically as printers and servers are added or removed.

Hle, již to nefunguje. Nevím, co k tomu dál dodávat. Opravdu jsme to "vylepšili": Hlavně že proboha neběží "zbytečně" služba! Kreténi.

To bude tím, že se díváte na dokumentaci verze 1.5. CUPS browsing je od verze 1.6 (tři roky staré) nepodporovaný a místo toho se používá Avahi (Bonjour), které CUPS spustí ve chvíli, kdy je potřeba.

Avahi spustí samozřejmě hovno a ne CUPS. Ten furt běží. Do doby, než nějaký magor vymyslí, že běží zbytečně. To, jestli se tiskárny broadcastují nebo anoncují přes Avahi (mimochodem, další Lennartova sračka) nebo přes SMB je opět úplně jedno. S diskutovaným problémem to nema NIC, ale ZHOLA NIC společného.

Avahi je implementace mDNS (RFC 6762). CUPS vyvíjí Apple. Apple používá Bonjour pro mDNS. Apple změnil CUPS, aby používalo Bonjour. Na Linuxu tak celkem logicky používá Avahi. S tím nemá Lennart nic společného.

Při sdílení přes Avahi je nutné povolit přístup na CUPS zvenčí. Avahi pak spouští CUPS automaticky, protože se ho dotazuje, jaké tiskárny sdílí. Stejně tak při sdílení přes SMB spustí Samba CUPS.

Avahi nic nespouští. Pro info - bavím se normálním systému s normálním CUPSem a normálním init-em. Ne o systému zaneřáděném Lennartovým shitem.

A proč ten CUPS trvale běží? Ano, správně - no protože jsi sám popsal, že ta socket-based aktivace je zcela k hovnu, protože ta služba stejně běží pořád, aby to mohlo fungovat!!!

Se Sambou funguje i socket-based aktivace. Mimochodem tohle se týká případů, kdy CUPS sdílí lokální tiskárny na síti, což není běžná situace, na kterou by se optimalizovalo výchozí nastavení. Nejčastěji se tiskne přes síťové tiskárny nebo nějaký tiskový server. Pro tyhle případy je socket-based aktivace vhodnější řešení. Že s tím má YaST problém, za to nemůže systemd, ale ten, kdo nepodporovanou socket-based aktivaci do SuSE zařadil. Znovu opakuji, že v Debianu to funguje správně.

Mimochodem tohle se týká případů, kdy CUPS sdílí lokální tiskárny na síti,

Ne, netýká. Zbytek blábolu je tudíž uplně zbytečná rozebírat.

" a ta služba stále není správně nastavená?"

WHAT? Jiste, my, Sten (Poettering) Veliky vime nejlip co ma kde bezet a jak to ma byt nastaveno ...

Kdyz neco disabluju, tak proto, ze ze si preju a rozkazuju systemu, ze to NIKDY nema nastartovat. Kdyz neto STOPuju, tak proto, ze to TED chci stopnout. Je to tak ODJAKZIVA.

A je uplne jedno jestli po stopnuti sluzby prijde start sluzby vyvolanej adminem, nebo start sluzby vyvolanej adminem pomoci restartu.

Jestli tobe vypadava na serverech elektrika, tak by ses mel jit zivit lopatou. Nadelas podstatne min skod.

Kdyz neco disabluju, tak proto, ze ze si preju a rozkazuju systemu, ze to NIKDY nema nastartovat. Kdyz neto STOPuju, tak proto, ze to TED chci stopnout. Je to tak ODJAKZIVA.

Tak to ale funguje i v systemd.

A je uplne jedno jestli po stopnuti sluzby prijde start sluzby vyvolanej adminem, nebo start sluzby vyvolanej adminem pomoci restartu.

Vy spouštíte služby restartem severu? Tak to se už ničemu nedivím.

Tak to ale funguje i v systemd.

Ne, nefunguje, jak jsme si již několikrát v diskusi ukázali. Ani to disable nefunguje tak, jak je u lidí se zdravým rozumem zvykem.

Funguje to stejně. Stop zastaví službu hned s tím, že může někdy později znovu nastartovat. Přesně podle vašeho popisu, jak to má fungovat.

Ne. To, že ji může znova nastartovat kdejakej Franta Vocas přes stupidní socket, to opravdu nefunguje "přesně tak, jak jsem napsal".

Funguje to úplně stejně, pokud službu stopnete, trigger ji může znovu spustit, a je úplně jedno, jestli je ten trigger restart systému nebo socket.

Ty mas vazne nasrano, kdyz neco stopu, tak to rozhodne nenastartuje samo. Co na tom tvoje koule nechape?

To fakt nemá chybu, tohle. To je asi stejná logika, jako když stopnu mailserver (třeba protože zavirovaný Widle někde na síti posílaj tisíce mailů) a ten mailserver se opět "inteligentně' sám spustí, protože na něj někdo zkouší poslat mail. Prostě úplně normální design... :-DDDDDDD

Presne, tohle ani widle jeste neimplementovaly. Pocitam ze jedinej rozumnej zpusob jak to stopnout bude killall postfix && rm /usr/sbin/postfix. I kdyz ... kill je knicemu, to se musi zakazat. To by jako neslo pouzivat nejaky neschvaleny postupy.

Takze lip ... musis dobehnout, capnout napajeci snuru a vsi silou za ni rvat az dokud ji nevyrves. A pak capnout palici, a cely to rozflakat na padrt.

Edit: Nabizim, automaticky strihac napajecy snury Poettering ltd.

Zcela garantovane stopne libovolne sluzby.

Ve Windows to funguje úplně stejně. Služby s on-demand spouštěním musíte zakázat, jinak se budou spouštět ve chvíli, kdy je někdo požaduje.

Ve Windows to funguje úplně stejně.

To je opravdu ultimátní argument. Děkuji, tímto diskusi raději končím. Diskutovat s hluchým nemá absolutně žádný smysl.

Jde o reakci na j-ho tvrzení tohle ani widle jeste neimplementovaly

Jak rikam, totalne vymeteno. Ne widle vazne sluzbu od demand nenastartujou na req po siti. Pokud totiz ma neco na siti poslouchat, tak to kupodivu musi bezet.

Podle sebe soudíte druhé, že?

Windows umí spouštět služby on demand i při přístupu na jejich port

Jakou logiku má to, že se ta služba po restartu serveru znovu spustí? Když jsem ji stopnul, tak má být přeci vypnutá, dokud ji znovu nespustím, ne že si ji spustí něco samo. Co když jde o unattended restart VPSky? Nebo o automatický restart po kernel panic? Prostě služba buď nemá běžet, pak se nemá spustit ani po restartu, nebo má běžet, a pak je jedno, jestli ji spouští restart nebo socket.

Důležité je, aby bylo chování jasně definované. Zbytek je jenom konvence.

Ono to samo nenastartuje. Nastartuje to určitá událost, která je nastavená, že to má nastartovat. Úplně stejně jako služby startoval sysvinit (událost = změna runlevelu) či xinetd (událost = otevření socketu).

Co asi jinyho ma delat sluzba na serveru nez naslouchat? lol ... a jasne, tim ze poslu req a sluzbu si nastartuju je z ni sluzba nenaslochajici ... jiste ...

Služba naslouchala na víc portech, než měla. Přečtěte si CVE-2012-6094.

Sem si precet, systemd zkurvili co mohli tak se to svalilo na cups ... chapu. A debil admin jako ty provozuje server na kterym nechava vsechny porty otevreny, taky chapu.

Presne jako ve widlich ... lol.

Jakou vinu nese systemd na tom, že správci CUPS napsali do definice používaného socketu:

ListenStream=631
ListenDatagram=0.0.0.0:631

místo

ListenStream=127.0.0.1:631
ListenDatagram=127.0.0.1:631

?

Můžu se tě zeptat, proč spamuješ diskusi "příspěvky" o bugu, který sis přes opakované výzvy zjevně bud vůbec nepřečetl, nebo absolutně nepochopil podstatu problému?

Co jsem na něm nepochopil? Že když se v titulku vyskytne slovo systemd, tak za to může Lennart? Ve zdrojácích systemd žádný cups.socket není.

On nema cups svuj konfigurak? Aha, ma, vid? Ale systemd na nej sere vid? Co ma Ipcko spolecnyho s aplikaci? Aha, NIC. Kupodivu kazdej servis posloucha presne tam, kam je naconfenej. Ovsem pokud se startuje nejakym srackometem, tak to nemuze fungovat ... divny.

On nema cups svuj konfigurak?

Má

Ale systemd na nej sere vid?

CUPS má svůj konfigurák, kde nastavuje tiskárny, a systemd má svůj konfigurák, kde se nastavuje, jak má CUPS spustit

Co ma Ipcko spolecnyho s aplikaci? Aha, NIC.

Proč se tedy IP adresy uvádí jak v konfiguráku CUPS, tak v konfiguráku systemd?

Kupodivu kazdej servis posloucha presne tam, kam je naconfenej.

Samozřejmě, a pokud ho máte nastavený, že má naslouchat všude, jako to bylo v tom cups.socket, tak naslouchá všude.

Ovsem pokud se startuje nejakym srackometem, tak to nemuze fungovat

Ano, pokud se to spouští se sysvinit, tak to takhle nefunguje ;-)

Výchozí nastavení všech služeb je (či by alespoň mělo být) dělané tak, aby ty služby byly zabezpečené, na tom systemd nic nemění; ne všichni jsou admini. Jestli tedy admin má něco dělat, tak že povolí naslouchání na dalších rozhraních. Což evidentně spouště lidí se systemd dělalo hrozný problém.

ne všichni jsou admini

Tomu vážně nerozumím. Ještě včera jsi nám tu cpal, že kdo chce tisknout, tak má být admin.

Nic takového jsem nepsal. Psal jsem, že pokud někdo chce rozbíhat tiskový server (obsluhující celou síť), tak by měl být admin.

Přesně tak to bylo míněno, jen mám pocit, že systemd označuje tuto cedulku jako "mask".

Když už i Debian přešel na systemd jako výchozí a Ubuntu se rozhodlo opustit svůj Upstart, asi to nebude tak špatný software.

tohle je absolutne nesvepravna uvaha, stejne jako napr.:

Kdyz jsou Windows tak rozsirene...
Kdyz se rozsirilo VHS misto Beta nebo V2000...
Kdyz se OS/2 nerozsirila...
Kdyz opensource...

Jeste je dobre to podporit nevyvratitelnym argumentem "protoze to rikali v televizi"

Ale zase je to o dost více svéprávná úvaha, než to, co naznačujete. Přechod na systemd byl výsledkem diskuze. Sice poměrně vášnivé a vypjaté, ale byla to diskuze.

Ten produkt prostě musel něčím zaujmout, rozhodnutí nedělali nesvéprávní lidé, ale odborníci na slovo vzatí.

Schrödinger tiše závidí.

Která událost z těchto jmenovaných nastala po dlouhé diskusi odborníků, kam měli možnost se zapojovat i uživatelé, a rozhodně se neřešila cena?

Si mo vzal z klavesnice :)