Názory k článku Dá se ještě žít bez systemd?

Obvyklé kvality windows jsou co? Nikdo neví, co to dělá? Chování se každou chvíli mění? Není možné se jednoduše dostat k logům na nefunkčním systému? Ne, děkuji, o to opravdu nestojím. Já chápu, že je to super, že se něco spouští paralelně a naběhne to o pár vteřin dřív, ale zkus si někdy přidat vlastní službu. Správně funkční závislosti? Možná na desktopu na internety, mail a office. Restart při pádu procesu? Za prvé - proces nemá co padat. Pokud padá, je třeba ho opravit a taková featura bude opravy oddalovat, protože i když je to špatně, tak to nějak jede a bude to mít menší priority. Až po roce zjistíme, že nám při každým pádu zmizela část dat, bude pozdě. Za druhé - na to mizivé procento opravdu potřebných a nenahraditelných padajících procesů se vždycky nasadila kontrola přes cron a bylo to. Tohle nejsou featury, kvůli kterým si ze systému chci udělat black box ala windows, kterej bude dělat to, co chce a ne to, co chci já a bude se po každým updatu chovat jinak. A další důvod proti SystemD je zcela osobní - vyvíjí ho blbeček, podle kterýho je všechno špatně a jen jeho pravda je ta jediná správná. Ať si udělá vlastní OS, kterej si pak může zmršit, jak bude chtít. Zatím nedokázal udělat nic, co by bylo opravdu funkční a bezproblémové.

Dovoluji si nesouhlasit s osobnim nazorem na Lennarta - doporucuji osobni setkani na nejake dalsi konferenci. To ze pulseaudio byl ze zacatku prusvih stejne jako se v jemny prusvih vyvinul systemd je jina vec. Kazdy muze mit nejaky nazor a vizi jako neco vyresit, ale jen nekdo ma schopnosti to udelat. Lennart je ma a to je neoddiskutovatelne. To ze je jeho reseni pro jine neprijemne, jeste neznamena ze Lennart je blbecek.

Nesouhlasit samozřejmě můžeš, ale na mým názoru to nic nezmění. Podle mě ty schopnosti nemá, je zcela evidentní, že jeho práce je zmatená a bez jasných cílů, SystemD mi momentálně připomíná Windows 10 - je to nedodělaná beta, v každé nové verzi se pokazí něco jinýho a už teď se to snaží stát nepostradatelným, ačkoliv je to v některých případech nepoužitelný. V zásadě by mi SystemD tak úplně nevadil, kdyby dělal jednu věc a nenabaloval na sebe spoustu daších. Jeho řešení není nepříjemné, jeho řešení zcela ignoruje dosavadní filozofii a podle mě to nemá v Linuxu co dělat, minimálně ne ve stavu, kdy se to snaží stát nepostradatelnou součástí OS. Jako jedna z alternativních možností, především pro desktopy to může pomoct rozšíření Linuxu mezi BFU, ale jestli se to dostane do stavu, že žádná rozumná distribuce bez SystemD nebude, osobně jdu do CokolivBSD.

No to jsi ale pozorovatel!

Mohl byste nám prozradit, co přesně vám brání v tom, abyste ten shell skript spustil pod systemd?

Chapat "systemd jako kritickou komponentu systemu" bude mozne, az ho za 10 rokov platna dostane do stavu ked bude aspon tak stabilny, ako kernel.

> Vyhoda systemd je v tom ze jednotlive komponenty (utility) jsou lepe propojene tudiz, je mensi sance, ze neco prestane fungovat kdyz se nejak knihovna nebo utilita zmeni.

I kdyz tohle se nam stavalo furt, ale tohle ma byt chvalozpev :)
Najvacsi for vznikne, ked partial update stihne zaktualizovat libsystemd a clovek zrazu nevie masinu ani zresetovat :)

> PS. osobne vidim v budoucnosti desktop linuxu prostor pro vetsi integraci komponent (Xserver, WM, atd) jakozto system kritickych

A potom nam neostane nic ine, len znova objavovat Unix :(

To řešení není nepříjemné. Ono je především blbě naimplementované.

Když se mě tuhle kamarád ptal na systemd a co a jak tak jsem vynechal všechny koncepční věci (filozofie, jak by to mělo být apod.) a sdělil jsem mu, že: hromada nápadů, některé i dobré, ale kvalita provedení katastrofální. Za ideálních podmínek to funguje, ale když to vykolejí, tak je konec.

Osobně, protože se systemd v praxi stejně nevyhnu, to testuju na soukromých serverech už skoro dva roky. Kromě již mnohokrát omýlaného journald jsem narazil především na nedodělávky.

Například způsob konfiguračních souborů networkd je super, fakt se mi to líbí (což je dáno především tím, že do té doby byly distribuční skripty na nastavené sítí fakt špatné - zkuste si nastavit pomocí distribučních skriptů 30 ip adres).

No jo, ale potom přijdete na to, že resolved neumí nastavit vyhledávací doménu. Fakt nevím, jakým způsobem je systemd vyvíjen a co vedlo autora resolvedu k tomu, že zrovna toto neimplementoval. Takže síť máte nastavenou jednou přes systemd, ale dns resolving musíte mít staticky přes /etc/resolv.conf (jako, ne že by to něčemu vadilo, ale místo, aby se uklidilo a používaly se jen prostředky systemd - když už jsou - tak je to další chaos). Stejně jako další služby systemd. Místo ntp timesyncd, ok, proč ne, ale kde jsou statistiky stavu synchronizace? ntpq? Nejsou, takže zpět na ntp.

Takže nápady někdy dobré, ale realizace těžce a někdy nesmyslně, pokuhlává.

To je v poho, to zase j siri bludy. (Dalsi faze je, ze na tebe zacne rvat, jaky jsi tatar)

A protoze je to x86-only show. tak je trebas v Arm Archu (viz linky nize) Arm Fedore (viz linky nekde okolo) a nebo v prehrsli debianich architektur viz link zde?

https://packages.debian.org/jessie/systemd

Ok. Tomuto držím palce, networkd (jak jsem psal) se mi fakt líbí, konečně "distribuční" způsob, jak nastavit bridge, bond (což má příjemně podobnou konfiguraci), více IP, apod. V network-scripts to bylo hodně nepřehledné a složité.

jj, slozitost sama ...

Psal jsem: V network-scripts to bylo hodně nepřehledné a složité.
Ne v něčem jiném. Viz:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-networkscripts-interfaces.html

On ani Debian to neměl nijak slavné:

https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually

Z tohoto pohledu vidím networkd jako pokrok.

Doufam, ze jednou na to osobni setkani jednou nekdo zajde s kusem plynove roury.

Pokud proces padne, tak se nemá restartovat. Riziko poškození dat. Automatický restart je akceptovatelný pouze po explicitní kontrole. Rozhodně ne by default.

To by mne zajímalo, jaké riziko poškození dat hrozí třeba u webového serveru poskytujícího data z read-only souborového systému. Navíc proces, který poškozuje data, je podle mne daleko horší, než proces, který se neočekávaně ukončí. Ale pokud chcete nějakou službu startovat ručně, systemd vám v tom nijak nebrání.

Co je to za zmatený příspěvek?!

Pokud máte webový server, který čte z ro FS, tak mu, ano, nastavíte že se může restartovat. Ačkoliv stejně bych o tom chtěl vědět.

To, že najdete pár případů, kdy se auto-restart hodí přece nemůže znamenat, že ten auto-restart nacpete povinně všude!

Proces, který poškozuje data je horší, než ten, který se neočekávaně ukončí. Ale jak to souvisí s tím, že bych takový proces měl chtít auto-restartovat?

Pokud proces padne, tak se nemá restartovat.
Pokud máte webový server, který čte z ro FS, tak mu, ano, nastavíte že se může restartovat.
Někdo z nás dvou je vskutku zmatený.

auto-restart nacpete povinně všude!
Kdo kam nacpal povinný autorestart? Nikdo nikom, to jenom jeden z nás dvou je zmatený.

Zapoměl jste uvést argumenty. Nebo alespoň nějaké vysvětlení.

Mám to tedy chápat tak, že SystemD by default nerestartuje služby?

Vysvětlení čeho? Že tvrzení „neexistuje proces, který by bylo možné po pádu restartovat“ a tvrzení „existuje proces, který by bylo možné po pádu restartovat“ jsou ve vzájemném rozporu a je zvláštní, pokud jeden komentující v jednom komentáři tvrdí to první a v následujícím to druhé?

System.d umožňuje spouštět služby jak v režimu „spusť a dál se o proces nestarej“ tak v režimu „udržuj spuštěné“. Přičemž u toho druhého lze ještě nastavit pravidla jako maximální možný počet restartů. Možnosti tedy máte obě dvě, což je v rozporu s vaším tvrzením „povinný autorestart“.

No, problém bude v tom, že toto jsem nikde nenapsal, že ano.

Řekl jsem, že nemůžete jednu výjimku nacpat za pravidlo. Nikde jsem nepsal, že neexistuje případ, kdy by se to nehodilo.

Ptal jsem se, zda je či není autorestart by default. Odpověď, že ano, vypnout to jde, není validní odpověď.

Aha, takže komentář od Bone Flute z 6.11. 14:24 jste nepsal vy. Tak to se omlouvám.

Psal. Proč?

Právě proto, aby si pořád to samé nemusel bastlit každý ve vlastní režii, vznikají správci služeb. Správce služeb se napíše jednou a pak se může používat opakovaně, pro různé služby. A je dost pravděpodobné, že to bude fungovat lépe, než když si nějakou imitaci správce služeb napíše každý sám pro svou aplikaci.

Automatický restart serveru není potřeba, je to možnost jak zautomatizovat něco, se se zautomatizovat snadno dá. Ve spoustě případů by správce po zjištění, že služba se ukončila, službu nastartoval, a pak by začal zkoumat, proč k tomu došlo. To rutinní nastartování služby ale nemusí dělat správce (ještě s rizikem, že na to zapomene nebo to udělá špatně), když to lépe zvládne automat.

bastlit

Fascinující. Toto mě něpřestává bavit. Evidentně není problém napsat funkční program čítající možná miliony LOC, ale ve všech diskusích má někdo problém s tím, že je potřeba to distribuovat v 3 balíčkovacích systémech, psát init skripty pro 5 (ani ne) init + rc a teď je dokonce problém udržet ten program na nohou.

Fakt je s podivem, že existuje tolik distribucí s takovým množstvím software, když je kdejaká prkotina (kterou stejně lze u složitější programu jen těžko vyřešit init systémem, takže si to stejně budou řešit dál sami) nepřekonatelný problém vyžadující baslení.

Funkční program čítající miliony LOC píše někdo, kdo chce psát ten program, umí psát v daném jazyce a rozumí doméně, kterou řeší ten program. Init skripty pak píše – ten, kdo chce psát ten hlavní program, umí psát v jazyce, ve kterém je ten hlavní program napsaný, a rozumí doméně, kterou řeší ten hlavní program. Zato v shellu se moc nevyzná, init skriptům nerozumí, dělá to na poslední chvíli, protože to předtím nikdo neřešil, a za úkol to dostal proto, že už nějaký skript na startování té aplikace pro sebe napsal, tak ať to přiohne, aby to fungovalo ještě aspoň na dvou počítačích kolegů.

Nepřekonatelné problémy to nejsou. To, že jsou to všechno jenom shell skripty, které si mohou psát sami, tady uvádí spoustu zastánců SysVinit. A že je to bastlení, to je důsledek toho, že se to dělá pro jednu konkrétní situaci a řeší to problém, který už měl být dávno vyřešen obecně. Skript, který si píše správce pro pár svých serverů, samozřejmě bude mnohem méně dokonalý, než něco, co je určené k použití na milionech počítačů.

A pokud někdo má své dokonalé skripty, lepší než systemd, tak přece nebude na systemd přecházet. Mne zase baví, jak si tu různí „správci“ stěžují, jak mají promakaný a vyšperkovaný svůj systém, vědí o každém bitu – a pak tvrdí, že se jim tam systemd doinstaluje, aniž by věděli jak a proč.

chce psát ten program, umí psát v daném jazyce a rozumí doméně, kterou řeší ten program

A současně nechce udělat nic proto, aby ten program také někde běžel. Chápu.

init skriptům nerozumí, dělá to na poslední chvíli, protože to předtím nikdo neřešil

Aha a zbytek programu od týmu, který takto řeší problémy, bude jistě v pořádku. Určitě.

Pokud někdo tímto stylem vyvíjí software, tak celý program bude jeden velký bastl a nemá smysl se jím vůbec zabývat.

řeší to problém, který už měl být dávno vyřešen obecně

Měl? Kdo říkal? Jinak obecně, obecně stačí vzít jakýkoliv template pro daný init, dopsat tam příslušná volání té své binárky a je to. Obecně jsou ty init skripty v podstatě všechny stejné. Ano, je to trochu víc řádek, než unita u systemd, ale to snad ničemu nevadí.

Chtít a umět jsou dvě různé věci.

Pokud jsou ty skripty v podstatě všechny stejné, proč je ve skutečnosti každý jiný? A co je tedy špatného na tom ty stejné části vytáhnout do obecné utility, a konfigurovat skutečně jen to volání binárky?

A co je tedy špatného na tom ty stejné části vytáhnout do obecné utility, a konfigurovat skutečně jen to volání binárky?
Není na tom nic špatného. Jen to ještě nikdo neudělal.
A Pottering dělá všechno kolem, jen ne toto.

A třeba tohle je co?

[Unit]
Description=Knot DNS server

[Service]
ExecReload=/usr/sbin/knotc reload
ExecStart=/usr/sbin/knotd -c /etc/knot/knot.conf
Restart=on-abort

[Install]
WantedBy=multi-user.target

Ano, tohle je hezké, a myslím, že kdyby systemd skončil vyladěným tímto, tak by všichni byli happy a prostě by si to přidali do sbírky podobných software.

Ne, místo toho se řeší, kdy a jak správně zamrznout.

Ostatně, init systémů, které mají podobně jednoduchou konfiguraci je vícero a existovaly i před systemd (a nějak neměly potřebu se propenetrovat do celého ekosystému). Kupodivu ty ostatní initrc systémy lze spouštět jeden z druhého, takže nejsou výjimkou instalace, kde je nějaký systémový init a v rámci jedné bundle aplikace je i její správce služeb, který potom řeší služby dané aplikace. Jak prosté.

Asi nepřekvapí, že tím systémovým initrc byl systemd. Zvláštní, že výrobce aplikace používá ještě další init (taktéž OSS projekt, nic vlastního) a že to nepřepsal do jednoho univerzálního systemd.

Systemd to neřeší místo toho, systemd to řeší navíc, a nemusíte to používat. Klidně můžete použít ty skripty, které to řeší v jiných init systémech.

Systemd také můžete integrovat k jiným init systémům. Systemd nemá potřebu propenetrovat do celého ekosystému – akorát asi nabízí takové služby, které autoři distribucí a software rádi využijí. To, že je to pod jednou hlavičkou, tedy konfiguruje se to stejným způsobem a navzájem to spolupracuje, to je samozřejmě plus a důvod, proč si autoři vyberou radši ekosystém systemd než něco jiného. To ale není chyba systemd – nikomu nic nebrání nabídnout něco konkurenčního, co nabídne alespoň ty samé služby. A nemusí dokonce ani nahrazovat celý ekosystém systemd, může nahrazovat jenom dílčí části. Protože systemd používá jako rozhraní standardní mechanismy, na které se může napojit každý.

To, že autor aplikace používá vlastní správce služeb (qmail používá daemontools, Postfix ho má integrován…) není nic nového, to tady bylo dávno před systemd – což je poněkud divné, pokud na těch původních init systémech není co zlepšovat, ne?

Systemd nemá potřebu propenetrovat do celého ekosystému

A teď tu o červené karkulce. Evidentě jste posledních x let žil v jiném vesmíru.

To, že autor aplikace používá vlastní správce služeb není nic nového, to tady bylo dávno před systemd

Ano, to jsem také psal.

což je poněkud divné, pokud na těch původních init systémech není co zlepšovat

To tady snad nikdo nepsal. A opět se vracím k tomu evidentnímu nepochopení, co původní init + rc vlastně je. Původní init je relativně jednoduchý (viděl jsem tedy i jednodušší implementaci na jednu stránku kódu v C), který prostě dělá to co má dělat proces s pid 1 (stará se o zombíky a tak) a (při bootu) spustí další proces (většinou v shellu), který se postará o spuštění skritpů v určitých adresářích. Nic trvale něběží (kromě povinného pid 1), je klid. Běží jen procesy démonů. Jsou-li nějaké.

Toť vše. Nic víc, nic méně. Neřeší to autoritativní informaci o stavu těch procesů (to ani nikde není slibováno) neřeší to hromadu dalších věcí. Proč? Protože to lze snadno vyřešit jinými prostředky.

Jestli má někdo potřebu složitějšího řízení, může si klidně jako jednu (a taky jedinou) servicu spustit složitějšího správce služeb. Vzhledem k tomu, že nic z původního rc trvale neběží, tak tento správce má k disposici všechny prostředky pc.

Teď totéž udělejte se systemd. Po bootu na stroji bez nakonfigurovaných démonů nepoběží žádný proces toho systemd. Neuděláte.

Opět, dočkal jsem se odpovědi od různých lidí (i z distribucí), kteří se ptali: "a čemu to vadí?" apod. Ano, takže linux dopracovat do stavu, kdy v systému je něco zbytečného, co se nepoužívá a ještě to běží. Prostě jako widle. Vedle v diskusi se už doporučuje spouštět cosi jako root, někteří doporučují nepřemýšlet nad tím, proč je v distru něco, co se nepotřebuje. Prostě to ignoruj, je to v distribuci, tak to tam nech. A udělej si to vedle podle své potřeby.

Systemd nemá potřebu propenetrovat do celého ekosystému – A teď tu o červené karkulce. Evidentě jste posledních x let žil v jiném vesmíru.
Mohl byste něčím doložit tu potřebu? To, že se systemd používá stále víc nemusí znamenat, že ho autoři někam protlačují, ale prostě jen to, že řeší skutečné potřeby a ostatní ho tedy rádi použijí.

Původní init je relativně jednoduchý (viděl jsem tedy i jednodušší implementaci na jednu stránku kódu v C), který prostě dělá to co má dělat proces s pid 1 (stará se o zombíky a tak) a (při bootu) spustí další proces (většinou v shellu), který se postará o spuštění skritpů v určitých adresářích.
To samé dělá systemd init.

Protože to lze snadno vyřešit jinými prostředky.
Teoreticky to lze snadno vyřešit jinými prostředky, prakticky se ty jiné prostředky používají těžko a ještě hůř se kombinují. Pokud by se to snadno řešilo jinými prostředky, bude to těmi jinými prostředky dávno snadno vyřešené a nebude teď nikdo přecházet na systemd.

Teď totéž udělejte se systemd. Po bootu na stroji bez nakonfigurovaných démonů nepoběží žádný proces toho systemd. Neuděláte.
Opravdu? Které procesy tam poběží navíc, oproti tomu, kdybyste totéž udělal se SysVinit?

Jirsak, napadlo vas nekdy, ze firma, co ma spickove prgace, co se vyznaji v monstrech o milionech radku, asi nebude cas techto lidi plytvat na psani nejakych skriptu v shellu, kteremu treba nerozumi? Namisto, aby ten clovek tyden cetl manualy a bastlil skript, muze dal delat na dalsim milionu radku a ten skript napise nekdo jiny. Nekdo, kdo se v tom vyzna a i s otestovanim to sfoukne za podstatne kratsi dobu.

Jo jo, když má firma barák plnej programátorů, bude najímat dalšího programátora na půl hodiny. To je super nápad, to nějakému manažerovi navrhněte.

Poslyšte, a není jednodušší, než aby se programovalo pořád totéž dokola a abychom měli experty na programování init skriptů, není jednodušší, když se to naprogramuje jednu do init systému?

Tak kdyz firma pise veci o milionech radku, tak asi nebude mit pet programatoru a uklizecku. Bude mit take adminy, testery, lidi, co to pripravuji pro distribuci.... a co ja vim.

To je hezký výčet, ale „specialista init skriptů“ tam nevidím. A hlavně mi taková role připadá nesmyslná. Připravit prostředí pro start aplikace a řídit její běh není žádná raketová věda a dnes je to tak komplikované především proto, že se aplikace nemohly spolehnout skoro na žádnou podporu od init systému, takže si spoustu věcí nějak zbastlily po svém, aby to jakž takž fungovalo. Což samozřejmě komplikuje zařazení do nějakého normální prostředí. To samozřejmě nebude trvat věčně, autoři aplikací se rádi spolehnou na to, že tohle za ně zařídí init systém – akorát že to pak samozřejmě znamená závislost na ekosystému systemd, když jiný init systém příslušné služby nenabízí.

Tak jiste, proc by programator nemohl pripravovat distribucni CD. A nakonec by mohl delat i helpdesk.

https://xkcd.com/927/

Jediný reálny prínos SystemD k popisovanému "problému".

V systému, jehož jméno se tu nesmí vyslovit, to je snad čtvrt století tak, že služba má uvedeno jestli se má při havárii restartovat, když ano tak kolikrát po sobě a po jak dlouhé době.
Tak nějak by to snad být mělo, ne?

Ano, tak nějak by to mělo být v systému, jehož jméno nechci vyslovit, ve kterém je běžné, že si každá služba sem tam jenom tak pro radost spadne. Může to tak být i na desktopu, kde běží kdejaká podivnost, možná na testovacích strojích, ale na produkčním serveru s ostrými daty nemají služby jen tak padat a proto by neměl být důvod je jen tak nahazovat. Základem dobrého systému je jeho předvídatelnost a pokud předvídatelný není, je to známkou chyby, kterou je třeba opravit, ne zamést chybu pod SystemD.

Na produkčním serveru s ostrými daty nemá jen tak docházet k výpadkům napájení nebo selháním datového úložiště, takže by neměl být důvod data žurnálovat. Stejně tak tam nemá jen tak docházet k chybám uživatelů, takže by neměl být důvod data zálohovat.

Nicméně zkušenější vědí, že občas dochází i k situacím, ke kterým by docházet nemělo. Proto zálohují, data ukládají do více lokalit, atd. atd. No a taky provozují aplikace tak, že se v případě ukončení procesu automaticky spustí znova. Protože když běhové prostředí té aplikace spadne na segmentation fault, když se při větší zátěži pokouší udělat optimalizaci, správce toho systému by tu aplikaci stejně v první řadě spustil znova, protože nebude čekat, až někdo udělá analýzu core dumpu, vytvoří se ticket u dodavatele toho běhového prostředí a pak se bude několik měsíců čekat, než to dodavatel vyřeší. Ono k takové chybě dochází průměrně jednou za půl roku, jak se později ukáže, nicméně i tak by se mohlo stát, že dřív, než dodavatel chybu opraví, pochcípá v clusteru tolik serverů, že už aplikace nebude zvládat nápor uživatelů. Ono by se těm uživatelům těžko vysvětlovalo, že administrátor je zásadový a server nespustí dřív, než bude chyba opravena. A mimochodem, ta chyba optimalizátoru končila segfaultem jen v menším množství případů, častěji skončila pouze poškozením spuštěného běhového prostředí. Takže vaše představa, že každá závažnější chyba musí skončit pádem aplikace, je také mimo.

Jen pro pořádek: Vy o té službě víte, že padá. Víte, že když spadne a znovu ji nahodíte, tak to bude v pohodě. - Jenže toto je trochu jiný scénář. Problém, konkrétně já, vidím v tom, když je tam ten autorestart by-default.

Restart: If set to no (the default), the service will not be restarted.

Navíc administrátor snad ví, co dělá, a nerozhodí ho nějaký default, protože si to nastaví tak, jak on potřebuje.

K logům nefunkčního systému se dostanete jednoduše tak že zabootujete jiný systém (na tom samém nebo jiném stroji), a log file otevřete Event Viewerem.

Ano, bootovani jinych Widli na stroji, kde Widle lehly, je jiste tak trivialni, jako vytvoreni live USB s Knoppixem. A az ten log otevru v Event Vieweru, tak se mi to bude naramne dobre grepovat. Zejmena, kdyz na Widlich neni grep. Podobne to bude na systemd. On Tuxik nepsal o tom, ze je nemozne se dostat k logum, ale ze se k nim nelze dostat jednoduse.

Ad Restart při pádu procesu? Za prvé proces nemá co padat - to je pěkná teorie. Jenže když máte systém v produktivním provozu, tak po spadnutí servisu nechce čekat, než se někdo dostane k tomu aby ho restartoval. Řešit to schedulerem je samozřejmě možné, ale daleko praktičtější je nastavit akci (restart servisu, spuštění programu, restart stroje) přímo ve vlastnostech servisu.

Cimz eventuelne zajistite, ze neprijdete o cast dat, ale o vsechna. Ne vsechno se da takto restartovat a o tom, co se ma a co nema restartovat by nemel rozhodovat OS, ktery o tom vi hovno.

Navíc klasický management služeb na Unixech je hrozivý, resp. prakticky absentuje. Jde o změť skriptů, na každé platformě jinak.

Nadhera, co? Vsechno, co potrebujete, si naskriptujete a nepotrebujete na to Powershell s kryptickymi prikazy, ktere budete ctrnact dni hledat na Googlu. Jo, kdyby tohle slo ve Widlich, byl by zivot jednodussi. Ne nadarmo se tohohle NIXy drzi. Vam to sice pripada spatne, ale jinym naopak o mnoho prehlednejsi a srozumitelnejsi.

K logům nefunkčního systému se dostanete jednoduše tak že zabootujete jiný systém (na tom samém nebo jiném stroji), a log file otevřete Event Viewerem.

Ano, bootovani jinych Widli na stroji, kde Widle lehly, je jiste tak trivialni, jako vytvoreni live USB s Knoppixem. A az ten log otevru v Event Vieweru, tak se mi to bude naramne dobre grepovat. Zejmena, kdyz na Widlich neni grep. Podobne to bude na systemd. On Tuxik nepsal o tom, ze je nemozne se dostat k logum, ale ze se k nim nelze dostat jednoduse.

Základní problém je v tom, že nechápeš, že když Lael Ophir řekne, že to je jednoduché, tak se o tom nepochybuje. Natož aby si mu oponoval, že tobě, nebo dokonce ještě někomu jinému to jednoduché nepřijde.

Každopádně tentokrát ti to odpustíme, protože Lael nepoužil kouzelné slovíčko "zjevně". To už by byla teprve drzost.

Tak asi je pravda, ze kdyz nekdo leta dela veci komplikovanym zpusobem, tak mu to zacne pripadat uplne normalni a jeste treba rekne, ze je to snadne. Vzdy oni treba i zasahy do registru na nefunkcnim stroji delaji snad porad jeste tak, ze vyndaji disk, daji do jineho stroje, tam to pripoji jako vetev do stavajiciho registry a edituji. Pak to strci zpatky a kdyz se nepovedlo, tak cele znovu.

On vie eventviewer celkom schopne vyhladavat. Ak si pod "schopne" predstavis ten uplne najdementnejsi, slimaci fulltext search, vzdy len v jednom logu/kategorii.
Ale ak vies, co hladas, nakoniec najdes ;-)

Ono to stejne je jedno. Clovek se z toho obvykle nedozvi nic pouzitelneho.

stačí vzít médium s Windows, zabootovat z něj, spustit Windows Recovery Environment command prompt....

Ano, zabootuju z toho media, co ho skoro k zadnemu pocitaci nedostanu a muzu si ho stahnout s uloz.to. Jinak tahle "horka novinka" prisla tak deset let po Linuxu. To je ale fofr!

Pro každý Unix i různá distra Linuxu (naštěstí ne všechny) musíte mastit skript, starat se kam ho umístit, editovat skript a nastavovat v něm env variables... Plus je to kompletně bez API, není způsob jak zjistit jaké servisy na stroji jsou ani v jakém jsou stavu... Kdybychom tohle měli ve Windows, byl by život daleko složitější.

Tak vsechny skripty delat urcite nebudu, na to jsou sestavovatele dister. A to, ze mam nejake API, ktere rekne, ze service bezi, jeste neznamena, ze funguje. Jak tu bylo receno na vice mistech, tohle se stejne musi monitorovat jinak.

BTW, updatujte si zkusenosti s vi. Na Linuxu uz je davno mozne pouzit sipky.

pokud jste počítač dostal předinstalovaný, instalační médium je na něm, a můžete z něj udělat bootovací USB klíčenku nebo DVD.

Tak nevim, co je ted v mode. Ja na disku na Esusu mel akorat recovery partition s XP a ta preflakne oddil s Widlemi i s uzivatelskymi daty. Jo, tehdy jsem jeste dosta CD. Nevim, jestli je to plnohodnotna instalace nebo nejake recovery, nikdy jsem to nepouzil.

Ovsem s tim, co pisete, je maly problem. Vetsina lidi si koupi stroj a vubec netusi, ze tam instalace nekde lezi a uz vubec si z ni neudelaji boot DVD nebo USB flash. A kdyz ten stroj nebootuje, tak uz to moc nejde. Nehlede na to, ze DVD za pul roku nebude asi fungovat a klicenku zase nikdo nebude chtit obetovat na to, aby jen tak lezela v supliku. Vysledkem je, ze 99% lidi boot medium nema.

Ale to, že nemůžete pomocí API zjistit ani jaké jsou na stroji servisy a zda běží, přesto považuji za neomluvitelné.

Tak mam prikaz ps, ktery mi rekne, co je v pameti. To, ze to tam nemam rozskatulkovane na sluzby a dalsi veci, je celkem jedno.

Osobně jsem ještě nikdy nepotřeboval číst event log offline.
To, že vy máte štěstí, nás ostatní dost dobře vůbec nezajímá.

příkaz a nikoliv API
Umělé rozdělení, čistě pro tvoji potřebu. Úplně stejně bych mohl říct, že Win nemají API, protože není jak se dotázat na seznam služeb. A kecal bych stejně jako kecáš ty, protože konkrétní formát ani nástroje API nedělají.

A to že nezjistíte přes API seznam služeb, nezaložíte novou, nezjistíte stav těch nainstalovaných, a mimo jiné například nezaložíte uživatele, je samozřejmě dost problém.
By byl problém, pokud by to byla pravda.

A jak jsem už psal, boot log je i ve Windows textový...

Sakra, tady je jeste prostor k vylepseni! Ten by mel byt binarni a cist by ho mohla akorat specialni utilita z boot disku Widli.

Ne, to je jen tvůj omezený Windows-centrický pohled na věc. Tvoje smůla. A naše neštěstí, že tě tu máme, a musíme tě poučovat o tak základních věcech.

Tak například HTTP RESTFul je samozřejmě API, ale řešené funkcema to není.

Pro programátora je jedno, zda to zavolá tak, či onak. V Unixu nezáleží na tom, zda je executable soubor script, nebo binárka. Programátor, není-li autor, to vůbec nerozlišuje. Chová se to stejně. Nemůžeš žít v představě, že všude to funguje stejně debilně jako bat, wsh na windows.

Argumentovat, že na unixu se API neřeší funkcema je stejně absurdní, jako vyčítat Windows, že nemá použitelný shell. No, není, a no nemá.

V unixu je všechno soubor. Tudíž, chceš-li znát seznam všech nástrojů v unixu, stačí ti pro to ls. Ano, není to funkce. No, to je toho.

Na Unixech API samozřejmě je. Servisy mají jasně definované rozhraní, a dají se vylistovávat, spravovat a vůbec. Na rozdíl od Windows na to ale je možné používat takové nástroje, které se adminovi hodí. Jediná výjimka je správce softwaru jako takového. To může být jen jeden. (Což zrovna Windows neuznávají, a proto je v tom takovej bordel.)

O to, kam se umistťují jendotlivé soubory se stará standard. Který je dokonce napříč různými rodinami Unixů. Takže obvykle, když balím nějaký program tak mezi Debian-like, RedHat-like jsou minimání rozdíly. Dokonce i ten Mac je docela podobnej. Jen Windows v tom má dost bordel, protože v každé verzi jsou různé soubory na různých místech. No, nevyčítám jim to, je to vývoj. Ale jako argumentace je to dosti lživý.

Takže když to shrnu, milý Laeli, opět klameš.
A co hůř, za celou tvou existenci tady, co jsem mě tu smůlu tě sledovat, jsi přinesl jednu jedinou užitečnou informaci.

projděte si Single UNIX Specification. API najdete v kapitole System Interfaces. Utility najdete v kapitole Shell & Utilities. Samozřejmě můžete poučovat, ale chtělo by to, abyste o věci něco věděl :)
http://pubs.opengroup.org/onlinepubs/9699919799/
Kdyby tak vědět, kde to najít stačilo, že? Musíš tomu taky rozumět.

Ad HTTP RESTFul je samozřejmě API - In computing, Representational State Transfer (REST) is the software architectural style of the World Wide Web. To že si někteří lidé navykli nazývat http-based interface API je sice pravda, ale API to z něj nedělá.
https://en.wikipedia.org/wiki/Representational_state_transfer

Což je podmnožina API. Že to nějakýmu Laelovi nestačí, protože to není reprezentováno funkcemi, to mě žíli netrhá.

rozdíl mezi utiliou a skriptem bych neřešil, akorát že skripty nemají ani standardní jména. Programátorovi ale samozřejmě není jedno, jestli použije utilitu/skript nebo API. Spuštění utility či skriptu znamená shell out (nedej bože přes katastrofickou sekvenci volání fork/exec), předání parametrů na command line či stdin, a pak parsování výsledku. Je to pomalé a nespolehlivé. Naproti tomu volání API je velmi rychlé, a lze předat oběma směry libovolné parametry, navíc bez marshallingu, parsování a podobných obezliček.

To co popisuješ ohledně toho mapování, je sice pravda, ale nijak to není specifikum Unixu. Když by si hrál férovou hru, tak by si řekl, že windows ten Marshaling má v mnoha případech vestavěný - a to bych ti uznal, to je pravda. Dokonce bych to považoval i za výhodu. Jenže takhle to vypadá, že znáž jen spoustu slov, a absolutně ti uniká smysl. Chápeš ty vůbec, k čemu je v unixu třeba takovej stdin?

Scritpy nemusím mět standardní jména. K čemu by to bylo, když jméno toho scriptu definuje api? Jo možná myslíš parametry. No, a ty jsou celkem standardní, nepsaně, ale jsou. Programátorovi to samozřejmě jedno je. Co to konkrétně udělá při spuštění utility ho zas až tak netankuje. Já třeba dodneška tak docela netuším, co se děje při cabal build, maven install, ale dokážu si představit, jak bych to zjišťoval. Ve windows si nepředsavím nic.

Jako, že má Linux spoustu probémů, a že by se to dalo udělat lépe, o tom žádná. Bohužel z těch tří je na tom Linux nejlíp, a Windows nejhůř. Sorry, ale je to tak,

utilita ani skript není API.
Ne? Protože jsi to řekl?

Windows samozřejmě má použitelný shell, který je generačně napřed proti shellům na Unixech. Seznamte se někdy s PowerShellem.
PS znám. Problém je v tom, že on je to sice naprosto skvělej koncept, ale budem si muset počkat do Win12, než to bude možné rozumě používat. Jenže, co bych já házel špínu na PS, když si na něj stěžují Windowsáci?

Seznamte se s Unixovými shelly. Máte-li rád Lisp, můžete použít lispovej shell. Máte-li rád cčko, můžete použít shell používající céčkovou syntax. Máte-li rád python, tak i pro vás by se něco našlo. Záleží čistě na vás, stačí si to nastavit. No, a pak je samozřejmě spousta adminů, kteří jsou konzervy a mají rádi bash.

Můžeš si všimnout, že v Unixu, díky dobře navrženému API, není problém dokonce rozchodit PS. Jenže lidé to prostě zatím neocenili.

No, smůla.

problém je v tom, že pro řadu věcí je soubor špatnou abstrakcí. Už nežijeme v době děrných pásek. Například pro servis je zjevně lepší abstrakcí objekt s vlastnostmi a metodami. Nakonec i souborové API v libc používá handles, což je svým způsobem rudimentální implementace objektů.
Problém je v tom, že lidé zkoušeli používat objekty na tyto věci, a vono to prostě lepší není, no.

Ale to člověk nesmí narazit na někoho, který díky znalostem kladiva vidí ve všem hřebík.

OK. Jak je to rozhraní definované? Jak získám seznam servisů s jejich stavem, zastavím servis, spustím servis, založím servis?
V mém oblíbené distribuci (tak bavíme se o oblíbencích že jo?!) se to napíše takto:
service postgre start
service postgre stop
service postgre restart
service postgre status
Instalace se dělá pomocí package manageru (samozřejmě).

Seznam servisů, C/C++: EnumServicesSta­tusEx(); C#: System.Service­Process.Servi­ceController.Get­Services()
Spuštění servisu, C/C++: ControlService(); C#: ServiceContro­ller.Start()
Zastavení servisu, C/C++: ControlService(); C#: ServiceContro­ller.Stop()
Založení servisu, C/C++: CreateService(); C#: ServiceInstaller­.Install()

No, hezký. Dejme tomu, že ti to přijde i elegantní. A když se přihlásim na win počítač skrze ssh, jak spustím takovou službu? A nejlíp, když se přihlásí skrze ssh nějaký program.

který standard? Single UNIX Specification toho moc neříká, popisuje jen /dev/console, /dev/null, /dev/tty a /tmp. Natož aby řekl, jak registrovat servis na všech Unixech.
Obecně standard. Není jeden. A každá distribuce si volí, co a který použije. Většina dodržuje POSIX, a FHS.

Ne, závazné nejsou. Ostatně to nedělá nikdo. Ne, nepokrývá všechno. No, ale tak na to si nikdo nehraje, ne?

to není bordel, ale záměr. Ve Windows nespoléháte na to že dokumenty budou v C:\Documents and Settings\[Accou­ntName]\Documen­ts, protože v jiné jazykové mutaci či verzi to může být C:\Dokumenty a nastavení\[Ac­countName]\Do­kumenty, nebo něco úplně jiného. Správnou lokaci získáte přes API, případně přes env variables.
Už jsem se lekl, že jsi se z této schizofrénie, kdy v případě unixu je to samozřejmě bordel, zatímco v případě Windows je to samozřejmě záměr - uzdravil. No nic. Žádná změna.

Záměr nezáměr, faktem je to, že Windows mají hezké představy, které se verzi od verze liší, a navíc je stejně nikdo nerespektuje.
Léta mají Windows MSI instalátor, a když sem se kámoše windowsáka na to ptal, jak vytvořit MSI balíček, tak na mě koukal jak trubka.

Nechtěl by si raději dělat osvětu svejm vlastním lidem? To by bylo určitě užitečný.

Každopádně, myslím, že já jsem tento měsíc svůj kredit radit windowsákům vyčerpal. Ať si s trolly hraje zase někdo jiný.

Čau.

Mozna by stacilo natrit predni okno auta psim hovnem a pobliz umistit kameru. :-)

To by byl spis namet na postapokalipticky sci-fi fil. IT valka pote, co se Microsoft polusil nastolt svetovou nadvladu. Vlady, tvorene farmami serveru s Widlemi, nezvladly situaci, kdyz doslo k runtime error fghkg8369í567 a nekolika BSOD, v dusledku toho nebyl v televizi oblibeny televizni serial a navic doslo k nedostatku kecupu. Nasledne povstani obyvatelstva se widloservery pokusily potlacit zaslanim armady autonomich valecnych stroju, coz obyvatelstvo strasne nasralo, prestoze se widlostroje z poloviny postrilely navzajem nasledkem poruchy v dlazdicce. Doslo totiz ke zniceni tovarny na levne parky z odpadku. No a pak uz to jede. Svetova mesta lezi v troskach, v kanalech se organizuje odboj, jehoz nejvetsim problemem jsou vsudyritomni potkani. Widloservery servery se opevnily v jadernych elektrarnach a zbesile brani zasobovaci cesty palivovych clanku......

Tak ještě jednou k API vs utilitám. API je určené primárně k použití autory aplikací. Utilita je určená primárně pro admina nebo skriptování. Utility nejsou API.
To je čistě tvoje tvrzení. Nevidím důvod takového rozdělení.
Naopak, pro Unix je typické, že nedělá rozdíl mezi člověkem a programem.

ne, to je specifikum používání utilit místo API. Musíte sestavit string s paramaretry, spustit proces s těmi parametry, a pak parsovat výsledek. To je ovšem postup typický pro shell skript, ne pro aplikaci
Aha. A SQL je vzduch.

jména skriptů žádné API nedefinuje.
Definují. Je to oblíbený a osvědčený vzor, který se používá nejen v shellu.

LOL. PowerShell funguje na Linuxu díky projektu Mono, což je (nekompletní) port .NETu, tedy to dobře navržené API.
Když by Unix neměl API, tak si .NET může to své strčit víš kam.

Navíc vaše oblíbené distro je pro autora aplikace celkem nuda.
No, tak ty taky cpeš Windows, které jsou většině místních volné, že jo. A navíc ho neumíš ani dobře prodat.

kámoš asi není programátor
Kámoš právě že je programátor. A na fulltime. Přece nejsem blbej, abych se ptal někoho, kdo o tom nic neví. Třeba tebe.

a kde vidíte důvod spojovat utility a API, když jsou to dvě zásadně odlišné věci?
Nejsou.

Ad A SQL je vzduch - to je dobrá ukázka. Jak provádíte dotazy do DB? Jestli není rozdíl mezi API a utilitou/scriptem, tak zřejmě nějak takhle: Do stringu postupně připisujete věci jako "SELECT * FROM Employees WHERE Surname=" + EscapeString("No­vak") + ";", pak provedete fork/exec ke spuštění "sqlplus user/password@db", nakrmíte stdin procesu tím SQL, a pak budete ze stdout (nebo souboru) parsovat hlavičku tabulky a jednotlivé záznamy. Je to samozřejmě neskutečný opruz na psaní, je to pomalé jako slimák, závislé na tom že utility jsou kde mají být, váš profil má správně nastavené env variables atd.
Jak se to ve skutečnosti dělá? Založíte connection object, připojíte se k DB, založíte dotaz, nastavíte parametry, provedete dotaz, dostanete nějaký dataset, všechno je typované. Jinými slovy nepoužíváte žádné utility ani skripty, ale čistě volání API.
Bláb blá blá, spoustu keců o ničem. Co dostane SQL server na vstupu, v tom nejužším hrdle?

Ad Když by Unix neměl API, tak si .NET může to své strčit víš kam - já nikdy netvrdil, že Unixy nemají API. Tvrdím že nemají API ani pro základní operace jako je správa servisů, což je prostý fakt.
To je prostě tvoje tvrzení. Nic víc. Jó, že to má každá distribuce jinak, možná. Že je to divné, neintuitivní, fajn - věc názoru. Že se nedrží přísně nějakého strandardu, no dejme tomu. Psanýho asi ne. Ale říct o jakémkoliv software, že nemá API, je tak strašná blbost, že už se k tomu nebudu dál s tebou přetahovat.

Na Windows je správa servisů zpracovaná řádově lépe.
Tvoje tvrzení. Jednu službu jsem psal. Těžko říct, zda je to "řádově lépe", ale mořil jsem se s tím dlouho.
Zatímco službu pro debiana jsem měl do hodiny. (Pochopitelně bez předchozích znalostí.) Službu pro centos taky. Ano, každá se psala jinak. Ale rozhodně to bylo snazší.

v tom případě bych čekal, že už někdy dělal instalační balíček. Pokud ne, tak to možná něco vypovídá o jeho práci
Ubohé, navážet se do někoho, koho neznáš.

ale nevím co by to mělo vypovídat o Windows Installeru.
A co to vypovídá o tobě, vzhledem k tomu, že já o kvalitách Windows Installeru neřekl ani slovo?

Ad Bláb blá blá, spoustu keců o ničem. Co dostane SQL server na vstupu, v tom nejužším hrdle? - to je jedno, protože jako autor aplikace prostě volám API a nikoliv utilitu. Ale není to tak jak si představujete. Závisí to na konkrétním DB engine. Na příklad MS SQL Server používá Tabular Data Stream Protocol, US Patent 7318075. Dotaz je binární struktura obsahující mimo jiné SQL statements, parametry jsou tuším typované a ukládané zvlášť. Výsledek je binární struktura obsahující mimo jiné popis sloupců a řádky, vše je typované. Koukněte se tady na kapitolu 4. To XML je jen dekompozice binární struktury.

To ale nemůže být pravda, protože přeci to nejužší hrdlo musí být volání funkcí, to dá rozum. Jinak to není API toho serveru. Přece. Zjevně. A Samozřejmě.

což bohužel znemožňuje použít jeden způsob registrace servisu pro různá distra Linuxu, nemluvě o různých Unixech. A nemluvě o jednom způsobu získání seznamu servisů atd.
Jo, no a? Koho to pálí?

to záleží z jaké perspektivy vycházíte. Pro admina je možná snazží napsat init skript, jenže to (alespoň na Windows) není jeho práce, protože dostane hotový balíček. Pro programátora je *výrazně* praktičtější použít API, které funguje na všech cílových systémech, než řešit skripty pro nevím kolik odrůd Unixů, včetně dister Linuxu.
No, já ti, jako vývojář, na tu *výrazně* praktičtější praktičnost z vysoka kašlu, když službu pro Windows jsem psal týden, zatímco službu pro Linux hodinu. (A to jsem v tý době byl windowsák).

zato když se vy navážíte do mě, tak to ubohé rozhodně není, že?
Tebe znám. Bohužel.
S nikým jiným, ani s žádným jiným Windowsákem nemám problém se bavit na úrovni. Ale demagogy, jakýkoliv, bytostně nesnáším.

Není všechno hned navážení se.
OK, omluva se přijímá.

Ten dotyčný dělá normálně v C++, C# a VB. Většinou koncové aplikace, s databází. Takže jsem si tipnul, že na lepší šanci už mět nebudu. No výsledek je takovej, že MSI balíček je pro mě stále problém.

Ad protože přeci to nejužší hrdlo musí být volání funkcí, to dá rozum - pletete si snad protokol a API?
Já ne. U sqlserveru je protokol tcp/ip a api je SQL jazyk.

Ad Jo, no a? Koho to pálí? - no, skoro nikoho. Jenom všechny autory SW pro Unixy. Výjimkou jsou možná ti, kterým připraví balíčky autoři dister Linuxu, pro které je to mimochodem také komplikace.
Ví vůbec ti autoři dister, že se jich tak zastáváš, a že je tak strašně lituješ?

Tady na rootu dokonce byl jeden autor distra. Zeptej se ho. Určitě ti potvrdí, že nejhorší na celé té přípravě byla právě ta rozdílnost mezi distry. - matko, to je materiál...

ehm. Ve VS najdete template Windows Service. Ve VS 2010 a dřívějších verzích stačilo přidat project typu Setup, do něj přidat výstup hlavního projektu a buildnout to, v output dir budete mít MSI balíček. Jestli jste na *tohle* přicházel týden, přesto že na MDSN máte vyjma popisu i tutorialy, tak k tomu nemám komentář.
No jo, ale když jsem tak blbej, to ta tebou dehonestovaná (ne)čitelnost, rotříštěnost a nedostatečný apismus linuxových scriptů získává úplně jinej rozměr. Vždycky sem si myslel, že pro blbý je spíše Windows. Hmm.

Precti si Practical API design od Jardy Tulacha, ten docela uspesne polemizuje s omezenim API na nejake to volani procedur a RESTovani..

Tak ono je asi nejlepsi mit v OS oboji. V NIXech jsou hlavne utility, ve Widlich hlavne API, zatimco utility jsou tragedie. A vzhledem k tomu, ze admini spis, nez psat aplikace, co volaji API, budou spis psat skripty, co colaji utility, tak bych rekl, ze NIXy jsou na tom o dost lepe.

No, vzhledem k tomu, ze na NIXech ty utility nekde ty vysledky musi ziskavat, protoze z prstu si je necucaji, kdyz nemaji prsty, tak nejake API nebo neco tam byt musi. Nehlede na to, ze v Linuxu mate spoustu k dispozici v /proc, coz je dost prakticka vec.

Utility ve Widlich jsou obvykle tragicke. Nehlede na to, ze bych podeziral, ze ani v Powershellu je porad jeste nelze retezit pres rouru, jako na NIXech, coz tyto utility cini mnohem mene uzitecnymi, nez by jinak mohly byt.

Dali vec, kterou jsem u widlackych utilit zaznamenal, je ze rada jich ani zrejme nepouziva standardni output nebo co, takze ani nejde vystup nekam presmerovat. Vystupy jsou casto znecisteny bordelem, ktery nejde vypnout, takze kdyz to chcete pouzit, musite to napred proparsovat a odstranit nesouvisejici svincik. Dale vystupy jsou casto spatne parsovatelne, uz proto, ze kazda utilita si bastli oddelovace, jak se ji zachce. Nekdy tabulator, nekdy mezery. Nekdy lze oddelovac zvolit, obvykle ale ne..... MS zretelne nemel zadna pravidla pro psani utilit, aby davaly smysl. A kdyz pak jednou mnozina utilit od nesourodych autoru dostatecne nakynula, MS z toho udelal Resource Kit a nestesti bylo hotovo.

neni nad dobre podlozenou kritiku: http://www.tomsitpro.com/articles/powershell-piping-filtering-objects,2-771.html

Jezis, to je pokrok! Po letech, kdy name muselo stacit type <file>|more z dob DOSu, se uz daji rourovat i jine veci. Nicmene i tak asi stale bude problem v tom, ze jestli MS nezcivilizoval spoustu svych starsich utilit, tak vystup z nich nepujde narvat do roury a u tech, u kterych to jde, to nepujde bez proparsovani a odstraneni bordelu. Jestli jsi mel nekdy cest s Resource Kitem, tak to byl dost des.

Jinak si vsimni, ze jsem napsal: "Nehlede na to, ze bych podeziral....". Nikde jsem netvrdil, ze mam jistotu, ze to tak stale je.

Jenže co je to třeba proti PHP, kde najdete konstrukce typu find(needle, haystack) i find(haystack, needle) :)

Tak ono PHP nastesti neni NIX, ze jo.

Víš Laeli co mě na tobě nejvíc provokuje? Že je spousta věcí, kterých se dá na Windows vychválit (namátkou DCOM). Je spousta věcí, které se dají na Linuxu kritizovat. A ty se budeš trefovat všude jinam, jen ne do těch opravdu skutečnejch kladů a záporů. To musíš snad dělat schválně.

Ad bootovani jinych Widli na stroji,...
Tak já vám to přeji, no.

Ad Ne vsechno se da takto restartovat a o tom
Dobře to děláte. Žel diskuse je o tom, že, SystemD to tak nedělá, proto ten hluk.

Ad eventuelne zajistite, ze neprijdete o cast dat, ... Ale je to dost nepravděpodobné.
O pravděpodobnosti v souvislosti se strátou dat se není co bavit. Murphiho zákony hovoří jasně.

Ad Nadhera, co? Vsechno, co potrebujete,...
PowerShell je tak klasická windowsovatina - skvělej nápad a tak strašně nepovedej.
V Unixu netřeba žádné scripty mastit... No, vůbec tendenční příspěvek, který se dá jedna ku jedné říct o Windows beze změny významu.

Mimochodem Unix api samozřejmě má. Dokonce s dokumentací. Netvrdím, že by se nedalo zlepšit, ale furt je, zvláště v některých věcech vepředějc, než windows. A to hovořím jako člověk, který naprosto fascinovaně koukal na DCOM.

Ad Vam to sice pripada spatne, ale jinym naopak ..
Dojdou-li argumenty, hejt se hodí, že?

Kurnik, Flute, voni tady nadavaj na Laela, ale kvotujou me. Nechaj si to, jo?!

Sorry, nechtělo si mi to tam psát celé.

Ad V Unixu netřeba žádné scripty mastit... No, vůbec tendenční příspěvek, který se dá jedna ku jedné říct o Windows beze změny významu - ve Windows se servis skládá z binárky a její registrace v Service Manageru. Registraci servisu provede instalátor, pro autora aplikace to znamená jen přidat servis do instalovaných komponent.
Tak, a teď mi prosím vysvětli, proč to takhle nejde udělat v Unixu? Tiše předpokládám, že ten rozdíl mezi Win a Unix není jen v tom, že ve Win je služba binárka, a v Unix script, že ne?! Protože co mi paměť slouží, tak ve všech distribucích, které jsem kdy používal se služby instalovali přes balíčkovač. Závislost aplikace na takové službě je také samozřejmostí, stejně jako automatické nainstalování takové služby, je-li potřeba. (Což třeba windows (a ve skutečnosti i Mac) stále ještě nemají dotažené. Ačkoliv msi (homebrew u Mac) maj dobře nakročeno.)

Ad Dojdou-li argumenty, hejt se hodí, že - a vám nepřijde ten popsaný jev fascinující? Můžeme se jen dohadovat, jestli jde o hate, věkem danou konzervativnost, nebo něco úplně jiného.
Ale ano, je to fascinující. Jenže to není ani zdaleka specifikum Linuxu. Já měl šéfa, který vždycky přišel za klientem s rozbytým počítačem (Windows). Chvilku tam jen tak nazdařbůh otevíral a zavíral dialogová okna v nastavení. Po půl hoďce prohlásil, že "tak, to by bylo. Zbytek ještě budu muset doladit na dálku." Přišel do kanclu, a já to měl (tentokrát opravdu) opravovat. Netřeba zdůrazňovat, že ten vynález spočívající ve vzdálené správě jsme přitáhli mi, dělnická třída z kanclu.

A takhle je to u Windows se vším. Mají prvotřídní obchodníky, to jim nemohu upřít. Rozhraní mají skoro tak dobré, jako Mac. Technologické řešení skoro tak dobré jako Unix. Někdy se Microsoftu opravdu povedou skvělé nápady (třeba ten DCOM je fakt bomba). Ale nikdy to ve Windows nefungovalo tak intuitivně a bezešvě jako v Mac, a nikdy to ve Windows nefugovalo tak technologicky čistě, a průhledně jako v Unixu. Je to prostě už na věky kočkopes.

Ale zvyknout si lze na cokoliv. Na Vim, i na EventViewer. Dokonce i na ten Ribbon. Ačkoliv si nejsem jist, zda by zrovna MSWord byl vhodným nástrojem na čtení logů. Po pravdě si myslím, že i ten EventViewer na ty logy není moc vhodný. A tak je sice ten Vim magor na ovládání, ale aspoň je schopný.

A takhle je to u Windows se vším. Mají prvotřídní obchodníky, to jim nemohu upřít. Rozhraní mají skoro tak dobré, jako Mac.

Ehm, vazne? Dlazdicky?

protože na různých unixech máte různé správce servisů, různé umístění skriptů
Jenže to vadí jen tobě.

v řadě případů musíte ty skripty editovat a nastavovat v nich environment variables.
Ano, a ve Windows rozchodit python a nastavit tomu cesty je procházka růžovou zahradou mi chceš tvrdit, že jo.

Samozřejmě můžete službu nainstalovat přes balíčkovač, pokud ovšem někdo připraví balíček pro konkrétní verzi konkrétního distra.
Samozřejmě windows má balíčky na všechno. A když je nemá, tak je to snadné všechno nastavit.

no rozhraní Macu, s těmi menu na horní hraně obrazovky, mi na větších obrazovkách přijde dost nepraktické.
Nesmysl. Ale to by's musel mět větší představivost a víc zkušeností s návrhem UX.
Ale beru to jako tvůj názor.

ovšem Apple vyrábí HW i SW, a s těmi pár modely HW je to o dost jednodušší.
Já měl na mysli SW architekturu. To, že ve Windows občas něco spadne neřeším.
Bav se o jednom tématu laskavě.

Mimochodem Apple opakovaně hodil uživatele přes palubu.
Prohlásit něco takového, když ve skutečnosti QT se s Mac táhne až do dneška. Když ve skutečnosti se i v posledním El Capitano emulují některé PPC věci, aby se dali spustit některé staré aplikace.

Pravdou je, že Apple udělalo obrovské věci, aby usnadnili uživatelům i vývojářům přechod, a co nejméně trpěli - transparentní emulace, duplikace kódu pro Motorolu, PPC i Intel. Některé věci zařízli, uznávám. Ale nazvat to hozením přes palubu?! Tím spíše, že Windows má problémy s jednou jedinou platformou a s udržením konzistentního API?

řekl bych že výrazně lepší než Unix. Windows mají lepší kernel a daleko bohatší API.
Nepsal jsi někdy jinde, že Unix API nemá?
No, ale já ti tvůj názor neberu. Pro mě je Windows bordel na kolečkách. Hlavně, že mají API dělené funkcemi (to je hejt na tebe a ty tvé keci, MS vývojářů si vážím).

Problém je v tom, že vi je mizerné v textovém režimu a naprosto zbytečné v GUI.
Problém s tím máš jen ty.
Výborné na vi je to, že ať se dobouchám kamkoliv, do jakéhokoliv stroje, tak tam *minimálně* to vi najdu, a bude fungovat i přes gsm, a budu schopen řešit problémy. Teda, nesmím mít smůlu, a nesmí na tom stroji běžet windows. Pak se mi všechny problémy zdrcnou na jeden jediný.

jistě, a proto distra hromadně přecházejí na systemd :)
Aha. Kvůli tomu, že unixy mají scripty na různých místech. Chápu.

Nastavení aplikací se necpe do startovacího skriptu, ale do nastavení aplikace.
V čem je rozdíl?

U LibreOffice, KMailu ani Gimpu nejspíš žádné env variables ve start scriptu nenastavujete.
Protože nastavovat env jsou možnost, ne nutnost. Což je výhoda, ne chyba.

chápu že když máte SDK s dokumentací, příklady a tutoriály na jednom místě, tak je to hnus oproti situaci na Unixech, kde máte jako "zaručené" API leda libc, dokumentace pro různé knihovny je psaná různým stylem a ve velmi různé kvalitě, hledáte ji po všech čertech, a ještě hromada API chybí :)
Jasně. Já někde psal, že msdn je bordel?

Mimochodem na stroj s Windows se i z mobilu v pohodě připojíte přes RDP.
No, fór je v tom, že já netuším, jak bych něco takového udělal. Musel bych si to nastudovat. Stejně netuším, a musel bych si dostudovat, jak bych se na ten stroj připojil přes X11.
Ale vím, jak spustit vi.

to je jeden z důvodů. Jako další bych viděl funkční závislosti a existenci API.
Co by si ty viděl já ani nechci vidět. Takže těch spekulací už nech.

Já nic netvrdím, ale wikina tvrdí, že Poettirng chtěl překonat stávající inity, chtěl lepší řešení závislostí, chtěl paralelní běh, chtěl redukovat režii shelu.

Nic o roztříštěnosti init scriptů, nebo jejich nepřehlednosti, nebo cokoliv, co jim vyčítáš ty.

Obdivuji tvou schopnost vystihnout to, co není ten problém :-)

V čem je rozdíl - například v tom že můžete použít ke změně nastavení GUI nástroje dané aplikace. Startovací skript vám budou editovat těžko.
Fajn to beru. Co neberu je, proč bych chtěl nastavovat konkfiguraci z aplikace, která je jen filtrem. Tam je naopak env parádní věc. Když funguje, že áno.

ovšem pokud je použijete, je tím efektivně zajištěno, že nastavení budete provádět editací skriptu.
Opět nesprávně: já si komplet změním prostředí aplikace, tudíž, bude-li něco ukládat, bude to ukládat... například do jiného home.

Psal jste, že pro vás je Windows bordel na kolečkách. Já oponuji, že dokumentace je velmi kvalitní a snadno se v ní orientuje, a chaos je vidět naopak na Unixech.
Fajn. A já oponuji, že mandarinky bez pecek jsou úplně nejlepší.

nejspíš byste si stáhnul aplikaci Remote Desktop, zadal hostname serveru a přihlásil se.
Na Linuxu? A v čem je to jednodužší, než napsat
$ ssh hostname
# vi
?

osobně by mě víc trápila třeba možnost ztráty dat při patchování nahrazením otevřených souborů.
No, vědí Lael, že tento přístup se třeba ve FP běžně používá? A je považován za obrovskou přednost.

Je úsměvné, jak já díky tvému hejtování získávám stále větší a větší ocenění pro Unixovou architekturu.

kvality obvyklé ve Windows 20 let

Ano, na tom se shodneme.

funguje restart při pádu procesu

Zdravé procesy nepadají. Pokud má stroj uptime 400 dnů (ne, že by to tak bylo správně *), tak procesy spuštěné při bootu prostě 400 dnů běží. Pokud někdo ručně (ne, že by to tak bylo správně **) spustí po 200 dnech provozu démona, tak za dalších 200 dnů prostě běží.

Požadavek na restart při pádu procesu je tedy nulový. Jestli jej tam někdo zavádí, asi k tomu má důvod a opět to cosi vypovídá o kvalitě.

*) Uptime je vlastně doba říkající jak dlouho stroj nemá aktuální jádro.

**) Pokud má služba běžet, je nutné ji tak definovat a ne partyzánsky spouštět nutné procesy ručně.

Zajímalo by mne, zda stejně přistupujete k zálohování nebo RAIDu. Zdravé disky přece také neodcházejí, zdravé programy a zdraví uživatelé nezpůsobují ztrátu dat.

Také by mne zajímalo, co je špatného na procesu, který byl odstřelen OOM killerem.

Navíc systemd není jediný správce služeb, jehož autoři si myslí, že pokud správce služeb dostane za úkol, že nějaká služba má být spuštěná, má udělat co je v jeho silách, aby spuštěná byla. A není úkolem správce služeb hodnotit kvalitu té služby, prostě má běžet, takže ji nastartuje, když neběží. Myslel si to také třeba autor daemontools, Daniel J. Bernstein, autor qmailu. Zrovna jeho bych nepodezíral z toho, že prosazoval padající aplikace.

Mimochodem, přesně tohle byl první důvod, proč jsem si uvědomil, že SysVinit&spol. je špatně – protože „správce služeb“ hlásil, že služba je v pořádku, přitom příslušný proces vůbec neběžel. Takhle se zdravý správce služeb nechová.

Myslis to, co se dela pomoci StartLimitInterval a StartLimitBurst?

Samozřejmě, že by k pádu procesu mělo docházet naprosto výjimečně. Ale podle mne je chyba se tvářit, že k tomu nemůže dojít nikdy. Když správce služeb dostane za úkol držet službu spuštěnou, má se o to snažit, ne spekulovat o tom, že přece není dobrý důvod, proč by se služba ukončila. Pokud dostane za úkol službu nastartovat a dál se o ni nestarat, má to udělat. Systemd (i jiné systémy pro správu služeb) umožňují obojí.

Pokud má někdo svůj blog na nějakém VPS, asi nebude řešit load balancing a clusterware. Monitoring je hezká věc, ale „aha, proces spadnul, znovu ho nastartuju“ není nic tak sofistikovaného, aby to muselo čekat, než se majitel toho blogu vrátí z víkendu a provede to ručně – tohle snadno zvládne software.

Bohužel to běžně vede ke stavu "no co, už to běží, peču na to". Jak jsem již říkal, pro BFU fajn, jako volitelná možnost SystemD má svůj význam, ale OS se na tom prostě nesmí stát natolik závislým, aby nebyla jiná možnost. V tom případě už by to mělo být přilepený k jádru a to bych si potom moc rád přečetl, jak Linus komentuje tomu "jehož jméno se mi příčí vyslovit" commity :-D

Bohužel to běžně vede ke stavu "no co, už to běží, peču na to".
Správce služeb má spravovat služby, ne vychovávat administrátora.

OS se na tom prostě nesmí stát natolik závislým, aby nebyla jiná možnost
To ale není problém systemd. To evidentně znamená, že systemd poskytuje služby, o které je zájem. Nikomu nic nebrání napsat alternativní implementaci. Pak bude ten jiný software záviset na nějakém obecném rozhraní, a každý si vybere, kterou implementaci chce. Ale to, že neexistuje alternativní implementace, přece není chyba systemd.

Ale existuje spousta alternativ (zatím). Problém je v tom, že díky jakési pochybné davové psychóze, vyvolané pravděpodobně posvátným "RH to řekl takhle", je možnost použití alternativ postupně omezována a to podle mě dost zákeřným a nepřípustným způsobem. Ano, většinu lidí to nezajímá, zajímá to především správce, ale co by lidé řekli na to, kdyby jim někdo postupně vnucoval, až téměř nařizoval, že od teď můžou používat pouze jedno konkrétní grafické rozlišení a to zcela nezávisle na velkosti, typu a rozlišení monitoru a navíc své rozhodnutí jednou za měsíc náhodně změní a všichni musí povinně přepnout na jiné rozlišení? Stačí to jako BFU přirovnání?
Jinak příklad, teď jsem se přihlásil k jednomu nedávno instalovanému firewallu, Slackware, 34 procesů, ani jeden modul jádra, využitá paměť 33MB. Opravdu na to budu v budoucnu potřebovat SystemD?

A o tom je ten článek, napřed si ho přečti, než začneš diskutovat.

A vidíš tam nějakou dostatečně robustní distribuci do produkce? Blázen jsem sice velkej, ale nevím, co mi řeknou v práci, když začnu používat nějaký "onemanshow" distra a budu je každýho půl roku měnit podle toho, kdo na to zrovna má víc času a komu se to povedlo líp.

Fork je zbytecny. Minimalne v ramci Debianu existuje reseni, ktere je stale funkcni i na development verzi - pokud z nejakeho duvodu admin nechce systemd, tak ho mit proste nemusi. Ze je neco "default" vazne jeste neimplikuje, ze se to tak musi kazdy pouzivat. Samozrejme admini, co jedou vicemene "na defaultu" na zaklade nejakych copy&paste navodu nejvic rvou. A rvou proto, ze jsou lini se zacist do dokumentace...

Pokud Debian bude jediny, nakonec podlehne. Treba proto, ze na SD bude zavisla kazda druha aplikace.

Zavislost aplikace na nejake knihovne ze systemd jeste neznamena, ze je nutne vymenit samotny init. Nac vylevat s vanickou i dite ;-)

Ne. Jen zase nechceš pochopit, na co si ti dotyční admini stěžují.

Neboli, žádný admin tu nikde netvrdí, že initd je perfektní, jak se tu snažíš tvrdit. Ale, že v porovnání se SystemD je snad cokoliv lepší, i ten initd.

Jenže to by si musel být menší demagog.

"Nikomu nic nebrání napsat alternativní implementaci. Pak bude ten jiný software záviset na nějakém obecném rozhraní, a každý si vybere, kterou implementaci chce. Ale to, že neexistuje alternativní implementace, přece není chyba systemd."

Je to jeho chyba, protože obecné rozhraní systemd neexistovalo snad déle než po dobu jedné verze.

Když správce služeb dostane za úkol držet službu spuštěnou

No to je otázka, zda správce služeb (init + rc) dostal za úkol držet službu spuštěnou, nebo dostal za úkol ji spustit.

Když se tak dívám na man service a man chkconfig (standardní nastavovátka rc skriptů na centos6) tak se nikde nepíše o tom, že daná služba má být spuštěná.

Naopak se tu píše, že service jen volá příslušný skript v /etc/init.d/ s daným parametrem a nějakým enviromentem.

A chkconfig jen nastavuje linky v /etc/rcX.d adresářích.

Ani slovo o tom, že "úkol držet službu spuštěnou".

V man init se píše "and is responsible for starting all other processes". Starting, nikoliv udržovat nastartované. (Ano, je možné v inittabu použít respawn.)

Tak jen jestli nedošlo k nepochopení toho, co tyto init + rc skripty mají dělat.

Já potřebuju udržovat službu spuštěnou. Když to init + rc neumí, je logické, že použiju něco jiného.

Já ne. Čím to, že se tvá potřeba stala etalonem do takové míry, že mě to komplikuje život?

Prilis jednoduche. Nasadte systemd, nez bude pozde.

No... ne že bych měl rád qmail, hlavně kvůli podivnému licencování, ale zrovna ten bych se asi styděl v diskusi o SystemD zmiňovat... spousta na sobě v podstatě nezávisejících modulů, každý z nich se dá nahradit čím chceš, do každé části zpracování emailů se dá cokoliv vložit, cokoliv se dá přeskočit, celý se to tváří velmi transparentně... To je přesný opak SystemD a tak to podle mě má vypadat a na správu i debug je to velmi jednoduché.

Podle mne systemD není přesný opak, ale je postavené na stejném principu. Spousta modulů, kterýkoli můžete nahradit jinou implementací. To, že jiná implementace v současné době neexistuje, není chyba systemd.

Je. Vždyť SystemD tomu aktivně brání tím, že mění API s každou verzí. Je to v článku pěkně zmíněno včetně příkladů.

Zajímalo by mne, zda stejně přistupujete k zálohování nebo RAIDu. Zdravé disky přece také neodcházejí, zdravé programy a zdraví uživatelé nezpůsobují ztrátu dat.

Naprosto nesmyslné srovnání. HW pochopitelně odchází, protože fyzické vlivy v tomto vesmíru nelze odstínit. Uživatelé jsou jen lidé, tedy značně nedokonalí, takže občas smažou něco co se mazat nemělo. Apod.

Pokud proces spadne, tak to má vždy jasnou příčinu (sice ne vždy jasně odhalitelnou). V praxi je to tak, že se během vývoje a testování program testuje na všechny (dosud) známé chyby a pokud spadne, jak je to důvod hledání dosud neznámého vlivu. Není tedy možné jej prostě spustit znovu.

A v praxi (alespoň mé) procesy jen tak nepadají. Opravdu jsem zvyklý na to (asi jsem výjimka), že proces, který se spustí při bootu běží po libovolně dlouho dobu běhu toho stroje.

Také by mne zajímalo, co je špatného na procesu, který byl odstřelen OOM killerem.

To je otázka na další zkoumání. Možná na něm není špatného nic a jen si OOMK vybral špatný cíl. V každém případě je nutné identifikovat příčinu nedostatku paměti (a potvrdit, že paměti bylo skutečně nedostatek a nezbláznil se jen OOMK) a tuto příčinu vyřešit. Nelze nechat OOMK střílet procesy na jedné straně, a nechat init systém tyto procesy stále dokola spouštět na straně druhé.

Mimochodem, přesně tohle byl první důvod, proč jsem si uvědomil, že SysVinit&spol. je špatně – protože „správce služeb“ hlásil, že služba je v pořádku, přitom příslušný proces vůbec neběžel. Takhle se zdravý správce služeb nechová.

Na jedné straně ok, na druhé straně já osobně jsem nikdy init a rc systém nebral jako zdroj autoritativní informace o stavu služeb už jen prostě z toho důvodu, jakým způsobem je to naimplementováno.

Navíc v praxi mě ani tak moc nezajímá co si o dané službě myslí správce služeb, ale to, zda to skutečně funguje. Tedy pokud se na portu 80 nedočkám odpovědi, tak je mi naprosto jedno, že si systemd myslí, že služba běží. Abych se od správce služeb dočkal autoritativní odpovědi, tak ten správce služeb musí mít naimplementovaný i monitoring toho, co daný proces má dělat.

Naprostý souhlas. Ještě bych doplnil, že pokud OOMK něco odstřelí, je to chyba buď poddimenzovaného serveru, nebo opět špatného procesu. V obou případech OOMK pouze reaguje na problém, který je potřeba řešit a prostý restart daného procesu není řešením, respektive může být dočasným řešením, ale nechat si na serveru běžet proces, který mi bezdůvodně požírá paměť, to je pro mě osobně zcela nepřijatelné. Minimálně to zmenšuje použitelnou cache a to je až na vyjímky vždy špatně.

Nebo je to chyba úplně jiného procesu, který třeba běžel výjimečně. Problém je potřeba řešit, ale není žádný důvod, proč by během toho řešení nemohl běžet ten proces, který byl odstřelen.

Tak. Pri rozhodovani, co restartovat a co nechat lezet je potreba trochu myslet a podle toho to nakonfigurovat. Trebas u stateless zalezitosti je (obcasny!) restart celkem bezpecna zalezitost.

Možná jsem divnej, ale to že serveru dojde paměť může podle mě znamenat asi milión věcí a minimálně půlka z nich mě děsí, proto rozhodně netoužím po tom, aby mi server sám nahazoval popadané služby, ať už za to může OOMK, nebo jakákoliv chyba procesu. Pokud je u něčeho dobré to jednou za čas restartovat, napíšu si to do cronu a nebudu doufat, že mi to občas shodí OOMK a nahodí systemd, protože mám v serveru nějakej nefunkční nepořádek.

Tak evidence vozidel neběžela déle, ztratila se data a nikoho to nějak výrazně netankovalo (teda až na řidiče, ale ti přece nikoho nezajímají).

Nebo systémy úřadů práce ;-).

Neznám příčiny těchto výpadků (což by bylo dobré zveřejnit, aby se z toho dalo poučit), ale znám příčiny jiných výpadků (ve státní správě).

Ty výpadky byly způsobeny požadavkem (od někoho, kdo neví který bije, ale má "hodnost") na nulovou nedostupnost služby. Takže místo toho, aby se systém prostě na pár hodin odstavil a udělala se standardní údržba, tak se učinil pokus o "bezvýpadkové řešení", které vedlo k několikadennímu problému. ;-)

Pochopitelně na skutečné HA řešení zase nikdo nedá peníze. Takže se oficiálně jede bez výpadku, neoficiálně se to bastlí tak dlouho, dokud to nespadne.

No vlastně je to podobné jako kauza VW a spotřeba TV. Někdo nařídí nižší spotřebu (technologicky jen těžko dosažitelnou), nenechá si to vymluvit, no tak se to prostě zařídí tak, aby to v testech dopadlo OK. Jak prosté.

Jenže tohle je jádro toho problému. Na poptávku řešení s HA nabídne určitá firma řešení za cenu, za kterou to nelze dodat, a tak to pak bastlí. Peníze by přitom na pořádné řešení byly, očekávaná cena byla pětinásobná oproti vysoutěžené.

Ano, ale to je opět chyba toto zadatele (veřejné zakázky) nebo obecně objednatele. Nikdo ho nenutí převzít a zaplatit za dílo, které neodpovídá zadání. A dokonce ho ani nic nenutí (v případě státní správy) si vybrat nejlevnější dílo (navíc pokud nevyhovuje zadání, tak ho mohou rovnou vyřadit).

Nebo, pokud už to ta firma s 5x nižší cenou vyhrála, tak trvat na tom, že to prostě pojede ve smluveném režimu a za každý výpadek tvrdě vymáhat smluví pokuty. Třeba až do bankrotu té firmy. Alespoň by se pročistil trh.

Ne, ono se to dělá tak, že papírově se jede na 100% dostupnost, prakticky se to bastlí co to jde a v případě problému se to nějak zahladí a jede se dál.