Vlákno názorů k článku Co se systemd… a Linuxem od Petr Ježek - Díky Adame, že nikomu nic nevnucujete a zůstáváte...
-
Petr Ježek (neregistrovaný)
Díky Adame, že nikomu nic nevnucujete a zůstáváte převážně v informativní rovině. Archlinux má pořád podporu sysV initu s rc.d a pro jednodušší nástroje to je stále optimální init. Jenže jsme to my, uživatelé, kdo neustále brečíme nad tím, že nám něco nechodí, jak by mělo navzdory všem wiki, man a distribuční diskusní moudrosti. Suckless idea UNIXu dnes zakopává o prostou skutečnost, že funkční rozšíření znamená růst systémové komplexity a nediplomatické kybermozky jako ten Poetteringův to prostě vnímají rigorozně jako kategorický imperativ. Proto to protlačování dosud jediného na rostoucí komplexitu reagujícího initu (jiný takový ve funkční podobě opravdu neexistuje navzdory uvedeným projektům). proto jsem také při své komplexní práci v Archu bez reptání na systemd přešel a získal jsem do té doby nebývalý přehled o nikde nedokumentovaných kolizích při zavádění a na tomto základě je i vyřešil. Projekty GNU jsou velmi sympatické, ale pracovat se s tím nedá a vývoj není ničím dostatečně stabilním tažen. Takže zaplať příroda, že se našel jeden kybermozek schopný stvořit a dále vyvíjet systemd.
-
j (neregistrovaný)
init (ani systemd) ale vubec neresi to, ze uzivatelum veci nefunguji. Naopak, uzivatelum velmi casto veci nefunguji prave proto, ze se vecne neco "modernizuje" ...
systemd navic zpusobuje to, ze veci prestavaji fungovat i tem, kterym bez nej fungovaly zcela bez problemu, viz trebas zminovany sitovky.
-
Lael Ophir (neregistrovaný)
Já vidím problém hlavně v té roztříštěnosti. Chcete zjistit, jestli nějaký servis jede, případně ho spustit nebo zastavit? Na Linuxu v podstatě neexistuje způsob jak to ověřit, protože systém může jet na sysvinit, Upstart, systemd, Initng a kdo ví čem ještě, přičemž většina z toho "pro jistotu" nemá API. A pokud hovoříme o Unixech, tak tam se k tomu ještě přidává Solaris Service Management Facility (který alespoň má API), MacOS X SystemStarter a launchd atd. To si fakt každý musí hrát na svém písečku, a v případě Linuxu ten malý píseček ještě demarkovat na vzájemně soupeřící kousky?
-
"Já vidím problém hlavně v té roztříštěnosti."
Vám to asi nevysvětlím, ale roztříštěnost není problém ale pozitivum. Ty forky nevznikají proto, že si někdo řekl, že jen tak pro chaos udělá další fork. Právě naopak, ten fork vzniká z toho důvodu, že na jeho konkrétní řešení se nic existujícího nehodí (případně ne dostatečně efektivně), tak si forkne cíly nejbližší projekt a ten si příslušně upraví. Díky tomu je snadné nalézt takový software (resp. v praxi spíš kombinaci), který řeší váš problém optimálně.
Jedno jediné správné řešení (TM) v praxi způsobuje to, že se vlastně nehodí téměř na nic.
"Na Linuxu"
Díváte se na to špatně. Chtějte to po konkrétním OS (který může a nemusí být postavený na Linuxu).
-
Lael Ophir (neregistrovaný)
Bohužel výsledkem je, že různé systém management deamony dělají víceméně to samé, ale dost odlišným způsobem.
Dám vám konkrétní příklad. Potřebuji napsat kus kódu, který zjistí, jestli běží deamon daného jména. Pozor, to neznamená proces daného jména - mohlo by se jednat o zcela odlišné procesy se stejným jménem image, případně o různé instance. To zjištění by mělo běžet na různých distrech Linuxu, na Solarisu, AIXu, HP-UX, a nejlépe i na MacOS X. Jaké API mi doporučíte použít?
A hned si odpovím: žádné API. Záleží na konkrétním OS, v případě Linuxu na konkrétním distru. Ve většině případů navíc neexistuje žádné API, jen klubko skriptů. Tolik k tomu, jak jsou Unixy vlastně jedna platforma, a Linux není roztříštěný.Ad jediné správné řešení v praxi způsobuje to, že se vlastně nehodí téměř na nic - nemyslím. Pokud se správně udělá design, řeší naprostou většinu případů. Ten malý zbytek případů se pak dá na většinové řešení nějak naroubovat. U Unixů je problém prostě v tom, že neexistuje žádná centrální autorita, a levá ruka neví co dělá pravá. Resp. to asi není přesné - těch rukou jsou desítky, většinu z nich nezajímá co dělají ostatní, a některé se spolu perou. V případě tak primitivní věci, jakou je správa servisů, se nelze vymlouvat na "špecifiká".
-
Lael Ophir (neregistrovaný)
A ještě jeden příklad. Mějme aplikaci, která běží jako servis. Potřebuji aby se byla schopná nainstalovat na různých distrech Linuxu, na Solarisu, AIXu, HP-UX, a nejlépe i na MacOS X. Co mi doporučíte? Vyrobit balíčky různého typu a s různým instalačním mechanismem pro každý OS, v případě Linuxu pro každé distro? To mi situaci moc neulehčí.
-
x (neregistrovaný)
Staci dat k dizpozici zdrojak, zajemce se uz postara aby mu aplikace chodila.
Zato na widlich aby resil chodak vyvojar na ktery verzi widli zrovna je ... a kam ma co nakopirovat, a to zcela ve svy rezii, protoze system sam nic takovyho neumi. Navic jeste aby resil, jak tu svoji plikaci aktualizovat ....
-
Lael Ophir (neregistrovaný)
Jo, stačí když ten SW dám lidem jako freeware i se zdrojákem, a instalaci možná vyřeší někdo další, pro každé distro (a každou jeho verzi) zvlášť. To je super rada třeba pro autory podvojného účetnictví, Photoshopu, Lotus Domino serveru nebo AutoCadu - ať to prostě dají zdarma :D
Ve Windows si ve Visual Studio uděláte setup project, a ten se postará o instalaci včetně dialogů (případně bez dialogů), registraci servisu, odinstalaci atd. Aktualizaci můžete řešit různými způsoby, umí ji třeba WiX Toolset.
-
j (neregistrovaný)
Hele loliku, to ze si retardovanej uz vime ... ale i pomerne hodne velkej retard ma aspon poneti, ze dat k dizpozici zdrojaky != dat neco nekomu zadarmo. Mimochodem ty jako propagator M$ bys trebas moh aspon tusit, ze kuprikladu akcapta (vytvor to koupeny M$), coz je mimochodem taky "ucetnicvi", muze mit zajemce vcetne kompletnich zdrojaku.
Ale to bys aspon musel tusit o cem plkas, ze ...
Projekt se postara leda o prdlajs, protoze kazdy jednotlivy soucasti musi vyvojar nastavit, kam ze se to ma dat.
-
Lael Ophir (neregistrovaný)
Oslovení "hele, lolíku" je nepatřičně familiérní. Zkuste trochu slušného vychování. Když vám někdo vyká, vykejte mu také, a odpusťte si familiérnost.
Dát k dispozici zdroják samozřejmě neznamená nutně dát aplikaci zdarma. Nicméně v kontextu je to snad jasné. Platící zákazník nebude řešit kompilaci ze zdrojáku a pracovat na dodělání instalace. Tuhle práci dělají zdarma správci dister, a to typicky jen pokud jde o open source aplikaci, ke které mají zdrojáky. To ovšem pro komerční SW není cesta.
Ad MS Dynamics AX (aka Axapta)... muze mit zajemce vcetne kompletnich zdrojaku - zdroj?
-
Hele, Lolíku, jako vývojář jsem se už několikrát pokoušel vytvořit balíček pro Windows, a je s tím takového drbání, že jsem to zatím pokaždé vzdal. Všichni kolegové, kteří instalují svou Windows aplikaci na Windows to většinou dělají nějak tak, že to tam prostě natvrdo nakopírují. (A tvářili se hrozně divně, když jsem se jich ptal na msi.)
Tak mi milý Lolíku nevykládej jak je to ve Windows jednoduché. Zlaté rpm, zladé deb. I za cenu zohlednění různých distribucí.
-
Lael Ophir (neregistrovaný)
Vidím že jste (nepatřičně) familiérní se mnou, ale zjevně ne s Visual Studiem :). Vytvořit MSI balíček z projektu je ve Visual Studio je otázka pár minut. Pokud to vy ani kolegové neumíte, tak bude zcela zjevně problém někde mezi klávesnicí a židlí.
Ad rpm, zladé deb. I za cenu zohlednění různých distribucí - takový výrok spíš ukazuje vaší neznalost.
-
Seti (neregistrovaný)
On normální SW závisí na verzi jednotlivých dister? To je zajímavé, že LO, FF, nebo tisíce jiných aplikací si můžu nainstalovat klidně i ve starších verzích, aniž by mě trápila verze distra. A samozřejmě není problém, pokud jde o nějaký Photoshop, Autocad, nebo účetnictví, udělat instalaci nezávisle na distru, jako to má třeba Sybase nebo VMWare.
-
Lael Ophir (neregistrovaný)
Většina SW používá řadu knihoven, které nejsou součástí balíčku. Pokud SW použijete na jiném distru (nebo na jiné verzi cílového distra), snadno dojde na dependency hell. Tedy pokud to distro vůbec umí instalovat balíčky daného formátu. Autoři komerčních aplikací to řeší nejčastěji tak, že SW kompilují staticky, a k tomu většinou vytvoří specifické balíčky pro několik dister.
Pokud jde o registraci deamonu, API pro zjištění stavu deamonu, spuštění a zastavení daemonu, samozřejmě na různých distrech a různých Unixech, tak se rád poučím, jak to efektivně řešit pro všechny systémy najednou. VMware (alespoň ve Windows) používá servis běžící na pozadí, takže předpokládám, že ho musí nějak registrovat. Možná budete vědět, jak to dělá. Podle všeho podporuje pár dister, a spoléhá na to, že si uživatel nenahradil init.d/systemd/UpStart/další za něco jiného.
BTW problematická je dokonce i registrace programu do Start Menu daného prostředí. Různá prostředí to totiž řeší různě, a i když máte balíček pro správnou verzi správného distra, aplikace se ve Start Menu nemusí objevit, pokud si uživatel nainstaloval alternativní prostředí. Nemluvě o různých Unixech.
A asi mi nebudete tvrdit, že technicky nelze vytvořit jednotný systém registrace deamonů, včetně jednotného API. Nebo že nelze dohodnout konvenci registrace programů ve Start Menu pro různá prostředí. Samozřejmě to (a mnohem víc) lze udělat, není to ani moc technické práce, a neexistují žádná "špecifiká", která by tomu bránila. Problém je jen v roztříštěnosti vývoje, kterou jsem popisoval.
-
Seti (neregistrovaný)
Nebudu opakovat pořád dokola to, co už bylo řečeno x-krát. Používejte si své windows ke své spokojenosti a jiné nechte si zase používat linux ke spokojenosti jejich. Já chápu, že trpíte nějakou obsedantní poruchou, protože žádný jiný důvod pro ty vaše projevy zde neexistuje, když linux nepoužíváte, ani pro něj nevyvíjíte. A vy zase pochopte, že diskuse s někovým takovým je pro mě nadále ztráta času.
-
Lael Ophir (neregistrovaný)
Aha. Takže když věcně kritizuji něco co je špatně udělané, tak místo technických argumentů začnete plácat cosi o obsedantní poruše. Jo, to fakt dává smysl :)
BTW ve vašem světe se k Linuxu smí vyjadřovat jeho nadšení uživatelé a nadšení vývojáři? To má samo o sobě dost velkou vypovídací hodnotu.
Souhlas, takováto diskuse je na nic. Neobtěžujte se odpovídat.
-
Seti (neregistrovaný)
Klidně se ještě jednou vyjádřím. Oni ti uživatelé a vývojáři nemusí být ani nadšení, stačí, že o systému něco ví a používají ho. To bylo ostatně hlavním bodem mého příspěvku, pokud jste to neráčil pochopit.
A ne, vy nekritizujete, co je udělané špatně. Vy haníte linux VŽDY na úkor windows, proto ta zmínka o obsedantní poruše. Když už není jiný pseudoargument k dispozici, tak přijde vaše obligátní "linux je opisem 50 let starého unixu".
-
ad dependenci hell: V linuxu na to máme nástroje. Balíčkovací systémy to řeší. Některé dostatečně, některé ještě lépe.
ad roztříštěnost api: Ano, je to prostor pro vylepšení, o tom žádná. Když by sis ale pozorněji (zda vůbec) přečetl místní kritiky, a trochu nad tím popřemýšlel, tak by ti vypadlo, že: systemd jako binární blob je cílem kritiky, ale problém to sám o sobě není. Problém je v tom, že se systemd stává defakto standardem, a znemožnuje nahradit sám sebe za něco jiného.
Na rozdíl od vývoje Windows, které od začátku měla jednu autoritu, která prosazovala, co uzná za vhodné, v Linuxovém světě něco takového není žádoucí. ANO, bylo by fajn, když by se objevilo nějaké unifikované API pro spouštění služeb, ale NE, ne za cenu, že nebude možné toto API nahradit za jiné.
ad roztříštěnost: Ano, je to problém. Je to komplikující, že máme na každou věc spousta implementací. A ano, bylo by fajn, když by se více lidí na něčem shodlo, a soustředili se na jednu věc. Jenomže NE, ne za cenu, že nebude možné použít něco jiného. Tohle je jedním ze základních důvodů, proč i navzdory roztříštěnosti je Linux lepší než Windows.
-
Lael Ophir (neregistrovaný)
Ad dependenc[y] hell - pokud instalujete na jiné než cílové verzi (toho samého) distra, snadno dojdete na závislost na verzi Qt, glibc nebo kernelu, kterou těžko vyřešíte.
Ad ANO, bylo by fajn, když by se objevilo nějaké unifikované API pro spouštění služeb, ale NE, ne za cenu, že nebude možné toto API nahradit za jiné - proboha proč byste nahrazoval dobře navržené API za jiné?
Pokud potřebujete pro svůj projekt nějakou specialitu, a chcete své služby spouštět nějakým obskurním způsobem, tak prostě implementujete jednu vlastní službu, pomocí které si pak můžete spouštět co chcete a jak chcete. Občas se takhle řeší portování unixových serverových aplikací (roztahaných do desítek executables, každá s jiným způsobem spouštění a zastavování) na platformu Windows.Ad Je to komplikující, že máme na každou věc spousta implementací - na tom se shodneme
Ad Jenomže NE, ne za cenu, že nebude možné použít něco jiného - u Unixů máte standardizovanou spoustu věcí: therading, libc, utility. Asi nebudete tvrdit, že je výhodou mít na každém Unix-based OS C runtime library s odlišným API, threading s odlišným API, nebo naprosto odlišné utility. Úplně stejně se dá standardizovat spouštění deamonů, multimediální API, a v podstatě cokoliv dalšího. Když se vám standardní implementace nelíbí, můžete si ji přece rozšířit, případně napsat jinou.
Skutečný problém je v tom co jsem popisoval: neexistuje žádná centrální autorita, a levá ruka neví co dělá pravá. Resp. těch rukou jsou desítky, většinu z nich nezajímá co dělají ostatní, a některé se spolu perou. S vaším přístupem bychom by auta neměla volant, aby si každý mohl (resp. musel) udělat vlastní v dílně. -
Seti (neregistrovaný)
Dependency hell: zajímavé je, že mně se to nestává. A pokud se to stane, je to řešitelné.
Unifikované API: co třeba proto, že existují systémy, které již jsou nějak řešené a zavedení toho jediného správného nenahraditelného API (tm) (r) tyto systémy rozbije? Že vy si žádný důvod nedokážete předsta it neznamená, že žádný neexistuje. Opět: vyjadřujete se k něčemu, co nepoužíváte.
A poslední odstavec: vybral jste si (nejspíš úplně čirou náhodou) standardy, u kterých tak nějak nemá smysl jiné řešení. Možná je to pro vás i po těch letech neustále nepochopitelné, ale variabilita linuxu je jeho výhodou. Díky tomu lze nalézt linux, na rozdíl od windows, všude možně. Díky tomu lze pro jeden problém použít různá řešení podle situace. Zřejmě máte stejný problém naprosto černobílého vidění jako výše p. Jirsák, který nechápe rozdíl mezi tím, když data poškodí běžicí služba a tím, když jsou data poškozena při startu služby.
"Když se vám standardní implementace nelíbí, můžete si ji přece rozšířit, případně napsat jinou."
To je to, čeho se kritici systemd obávají, a ostatně píše to i předřečník, že to možné NEBUDE.
-
"proboha proč byste nahrazoval dobře navržené API za jiné?" -- toto je přesně ten problém. Ty, milí Lolíku jsi windowsák, u windowsáků se to tak nedělá. My se ale této svobody velice neradi vzdáváme. Já považuji PostgreSQL za jedinou pravou databázi. Někdo ale z nějakého pro mě nepochopitelného důvodu dá přednost MySQL. Jenže je to jeho právo, bez ohledu na to, že já ho nechápu.
Když to pochopíš ty, milí Lolíku, naučíš se novou věc. No neber to.
Zbytek co píšeš je smetí, a nepravdy, namátkou libc, utility, pro všechno jsou alternativy, a někdy se dokonce i používají.
ČLÁNKY DO MAILU