Mno musím přiznat, že se mi starší nápad se soubory v /etc/users.d líbil více. Vidím tři potenciální problémy s .json souborem v domovském adresáři:
- identifikace domovského adresáře (/home se nepoužívá všude..)
- možnost ten soubor smazat (protože uživatel musí mít právo zápisu do "/home/user/." a nic více nepotřebuje)
- kolizi v případě použití /home z více různých strojů (NFS, více OS v grubu nebo třeba jen záloha a recovery pomocí jiného počítače)
Přednášku jsem ještě neviděl, takže pokud má na toto řešení, tak super. Na /etc/passwd totiž rozhodně netrvám. Jsou s tím v distribucích jenom potíže (jak si služba správně přidá svůj systémový účet během instalace?).
Utilita useradd nevyřeší konflikt uid. Také neumí zjistit, kdo daného uživatele přidal a po odinstalaci balíku ho zase spolehlivě odstranit. Každá distribuce na to má nějaká makra, ale neexistuje nic unifikovaného.
Navíc soubor /etc/user.d/jarda dodržuje pravidlo, že vše je soubor, o dost více než řádek v /etc/passwd. Ten navíc nemusí zmizet, ale klidně ho může systém generovat.
Všimněte si kolik konfigurace v /etc je dnes řešeno pomocí sluzba.d adresářů. Ono to totiž má spoustu výhod.
A poslední otázka bezpředmětná není. Stačí taková věc jako přeinstalace systému se zachování /home. Jak se má instalátor nového systému k tomu .json souboru zachovat? Podpis neověří, ale přepsat by ho také nemusel, protože neví, jestli je potřebný nebo ne.
Administrace Linuxu tak jsme ji znali jednoduse konci. Vsechno se ted automatizije a "*.d" adresare automatizaci vyrazne zjednodusuji. Potteringovi - jak se zda - ale vadi cely adresar /etc. Nejde jen o /etc/passwd ale i o resolv.conf fstab a dalsi konfiguracni soubory.
Cele se to posunuje k tomu, ze /etc/ bude "read-only" a skutecna konfigurace bude v pameti procesu a vytvori se behem bootu. To je mozna dobre pro male ARM krabicky, ale pro lidi, kteri leta administrovali servery je to tezko prijatelna predstava.
Naopak, myslím, že je velmi předmětná. Jak aplikace, naprogramovaná např. v C++, Pythonu nebo Rustu, vytvoří nebo zničí uživatelský účet? Nijak, protože na to neexistuje API. Argumenty o utilitách a skriptech jsou mimo podstatu věci. Tady nejde o to, jak snadno nebo složitě si to nějaký sysadmin naskriptuje, ale o to, jak vývojář třetí strany zajistí, aby potřebná operace proběhla na stroji cílového uživatele, kde žádný admin není, uživatel nemá nejmenší úmysl se jím stát, počítač má na to, aby na něm psal knihu (nikoliv unixové skripty) a očekává, že věci budou Prostě Fungovat(tm) ve sto procentech případů a jedním klikem, stejně, jako to je na Windows nebo na macu.
Možná jsem narazili na podstatu ....
Aplikace nemá mít šanci vytvořit nebo zničit uživatelský účet.
Tu šanci má mít jen ten kdo má právo instalovat a ten použije např. " id xyz || useradd -system xyz" ať již ručně nebo v install scriptu aplikace.
Aplikace instalované uživatelem mají běhat v kontaineru a nemají do systému co sahat.
Za A ten uživatelský účet je v tomto případě příklad, stejné je to se vším.
Za B, aplikace k tomu oprávněná samozřejmě musí být schopná vytvořit nebo zničit účet, od grafického rozhraní ve GNOME přes nějaký webový admin nástroj až po automatizovaný deployment v AWS atd.. K tomu je potřeba oficiální, dokumentované a předvídatelné API. Nějaký shellový guláš který čistě náhodou funguje u mne ale u nikoho jiného, protože někdo jiný to zase "na svém stroji chce takhle a ne onak" apod. to prostě neumožňuje.
@klokan 24.9.2019 9:04 [...] shellový guláš který čistě náhodou funguje u mne [...]
mozna varis shelove gulase, ale rec byla o standardnich terminalovych nastrojich, jestli je pouzije uzivatel v shellu, nebo tvurci GUI/PHP aplikace v GUI/PHP aplikaci je uz jedno, ty nastroje jsou dostupne v kazdem neoklestenem GNU/Linux, tedy slo/lze je bezproblemu pouzivat, nebo se da vytvorit API abys mel radost, ale muze pouzivat totozne configuracni soubory, neni kvuli tomu potreba aby se zahodilo zavedene /etc/passwd,shadow,group,gshadow... a znemoznilo pouzivani tech dostupnych nastroju a vseho co je do ted vyuzivalo...
Jenže mě jde o to, aby GNU/Linux byl nejlepší možný svobodný OS, ne o to, aby to nutně byl svobodný Unix. Soudě podle směru, kterým se mainstream vyvíjí, s touto představou nejsem sám, naopak to vypadá, že se kolem toho formuje konsensus. Na /etc/passwd, unixovém shellu a spol. není nic závazného a mimochodem ani Linus Torvalds za Linux, ani Richard Stallman za GNU nikdy nic takového netvrdili a nikomu neslibovali. Postupné nahrazování nejen initu, ale v důsledku prakticky celého základního userlandu novými komponentami kolem projektu systemd, fungujícími jinak, vyvíjenými s odlišným pojetím a filozofií, než Unix, není ani konspirace, ani "zrada" na nikom a na ničem, je to přirozený darwinovský vývoj tak, jak ve FOSS světě probíhal odjakživa. Mimochodem nemám ani akcie RedHatu, ani nejsem nějak zapojený do vývoje systemd, Poetteringa osobně neznám a na systemd jako takovém mi celkem nesejde, jde mi o směr a filozofii a tu dneska prosazuje systemd tak, jako to mohlo být něco jiného.
Ale všimni si prosím, že ještě dávno před systemd vznikl projekt Suckless, právě s cílem oponovat tomuto vývoji a razit unixovou údajnou filozofii. Jestli ho vůbec někdo doopravdy používá, tak je to celém světě pár jedinců. Uživatelská základna Debianu mezitím roste rychleji, než u Devuanu. Takže to asi o něčem svědčí.
S tou identifikací adresáře nevím, asi zo prostě povinně musí být v /home. Upřímně řečeno, nevím, proč by někdo bazíroval na tom, že se to ausgerechnet musí jmenovat jinak.
Pokud jde o ty adresáře z různých zdrojů, podíval jsem se na to video a mám pocit, ze je to naopak. Adresář není svázán s žádným konkrétním strojem, Poettering uvádí jako příklad, že je možné ho mít na flashce a jednoduše ji strčit do jakéhokoli počítače a bude to hned fungovat (samozřejmě s nastavitelnými bezpečnostními omezeními...). Ale nevím, nic z toho jsem nezkoušel, tak uvidíme.
Ano, přesně tak. To, co Windows mají už od dob NT, k tomu dochází Linux teď. Microsoft si to vyžral vrchovatě. Dodnes většina poloprofesionálů vůbec neumí ani s registry, ani s AD a GPO pracovat a jen na Windows nadávají. To samé se teď děje u Linuxu skrzevá systemd. Zavádějí se technologie, kterým už nebude každý rozumět na první pohled, ale bude se muset učit. Učení bolí, proto tolik povyku.
Linuxu teoreticky nic nebrání udržovat distribuce i s klasickým initem a PAM. Jenže v praxi vidíme, že dobrovolníci to nezachrání. Velcí kontributoři Linuxu (RedHat?) se rozhodli a díky penězům jim prostě komunita patří (financují si své lidi kteří jsou součástí komunity).
Za mě je to jednoznačně dobrý směr. Pokud se jednoduché Linuxové distribuce neudrží, stále tu máme celou rodinu BSD i dalších Unixů. Ale myslím, že to vůbec nebude potřeba. Na systemd-cokoliv si všichni (chtě nechtě) zvyknou a svět se bude točit dál.
Lennart se snaží splnit jiné zadání. Kiosky a stateless systém. Tvoří "home on a stick".
A o LDAP se nebojte, toho se RH nevzdá, protože ho chtějí zákaznici. Stejně tak kerberos. PAM je přimo v té přednášce zmíněný jako mechanizmus pro ten jeho nápad. V glibc taky asi nebudou určitě hned zahazovat podporu nsswitch.conf.
Dodnes většina poloprofesionálů vůbec neumí ani s registry, ani s AD a GPO pracovat a jen na Windows nadávají. To samé se teď děje u Linuxu skrzevá systemd. Zavádějí se technologie, kterým už nebude každý rozumět na první pohled, ale bude se muset učit.
Ono se pořád píše o těch technologiích, ale problém nejspíš vůbec nebude v nich. Požadavky na konfiguraci systémů a služeb už jsou tak různorodé a komplexní, že ta konfigurace je komplikovaná. A to je to, co dělá správcům problémy a co mají problém se naučit. Registry nebo AD jsou jen nástroj, jak tu konfiguraci spravovat. Teoreticky může být problém i v tom nástroji, ale spíš je to tak, že tyhle nástroje správu zjednodušují a pokud by se systém a služby konfigurovaly postaru, bylo to ještě podstatně komplikovanější.
> zastarala podstata sama?
Jako že už neplatí?:
1. nástroj má dělat jednu věc a to pořádně
2. má být schopen přijímat data od ostatních nástrojů a také jim data předávat co nejjednodušeji (v "čitelné" formě ...)
Jestli je to tak, tak byste to měl vysvětlit všem co se snaží obrovské molochoidní a neudržovatelné aplikace rozškubat do komponent/mikroservisů/... protože ti všichni jdou špatným směrem. A taky řekněte všem co poskytují otevřená data, že to dělají špatně, místo TXT/XML/JSON by měli data poskytovat v DBabc/JournaLFXNv.2.3/nebo jiném superformátu.
Sorry, ale málokdy se podaří, že by zesložitění za účelem zjednodušení fungovalo.
> k čemu je dobrá expirace hesel
To je diskusia mimo pointu. Pointa bola, ze /etc/passwd ako je teraz je *velmi* obmedzene a akakolvek extra funkcionalita sa musi dolepovat postrannymi subormi a konfiguraciami. Odtlacky prstov, yubikey.. Vsetko ma konfiguraciu niekde u seba a akakolvek pokrocilejsia konfiguracia uz v zasade /etc/passwd pouziva len na pridelenie UID. (aj aj to len preto lebo musi, UID ako take je dalsia z tych veci ktore su problematicke)
Přímo entelegentní je také model přístupových práv, kde právo vytvořit soubor v adresáři se rovná právo smazat kterýkoli jiný, ať už patří komukoliv. Samozřejmě, že místo, aby se to opravilo a zavedly se pořádné ACL (které uměl už MULTICS a které jsou výchozím modelem ve Windows), tak se implementoval rovnák pomocí dalších příznaků, ovládaných pochopitelně úplně jinak (chattr) a protože to má zase svoje úžasnosti, tak je ohýbák v podobě mount voleb, které ovšem pro jistotu většinou nejdou nastavit persistentně, atakdále...
Je logické, že moci vytvořit soubor je totéž, co smazat soubor patřící někomu jinému? Tohle může tvrdit jenom někdo, kdo uvažuje tak, že správně je to, co dělá Unix, i když je to dementní.
O setfacl jsem samozřejmě "slyšel". Jejich implementace v Linuxu jednak tento problém neřeší, jednak je silně nepružná a nepraktická, a navíc se vztahuje jenom na soubory, nelze je používat na libovolný typ jaderného objektu. Ty tzv. NFS4 ACL, jaké má mj. i FreeBSD, jsou už lepší.
Ano, sám jsem se o něm přece ve svém příspěvku zmínil. Klasický příklad, jak Unix jednu hovadinu "řeší" další hovadinou. Správně by bylo moci udělit právo "smazat tento objekt", nastavitelné v ACL pro jednotlivé uživatele nebo skupiny. Jenže to by bylo čisté a koherentní řešení, takže místo toho nám unixoví filozofové vyprodukovali toto veledílo, které se dá nastavit jenom stylem "všechno nebo nic" a jak jinak, než úplně jiným způsobem než např. práva čtení nebo zápisu, pomocí jiného syscallu a s jinými datovými strukturami.
Jak se tedy má systém zachovat, pokud máte právo smazat adresář, ale ne jeho obsah? Buď neumožníte smazat nic, nebo necháte adresář v nekonzistentním stavu (část souborů pryč) nebo uděláte to co unix a řeknete, že si můžu smazat cokoliv v objektech, které vlastním.
On je pak totiž problém třeba s dohledáním souborů, které se náhodně vytvořily jinde (logy z procesů spuštěných jako root) nebo kvótami.
Což je pro uživatele něco pekelného. Tohle můžete možná udělat na produkčním serveru, ale desktop se takto chovat nesmí. Dovedete si představit jak se bude tvářit uživatel, až mu řeknete, že si nesmí smazat adresář ze svého vlastního /home? Obzvláště veselé to bude v případě, že tam zůstalo něco neviditelného...
FHS poměrně striktně odděluje systémová a uživatelská data. A v takové hierarchii dává to současné chování perfektní smysl, protože vlastníkem /home/uzivatel je uživatel a vlastníkem třeba /var/lib/uzivatel je systém. Root nemá co vytvářet soubory u uživatele v /home.
Pokud by Lennart chtěl, tak klidně může v /home udělat uzivatel.home (metadata) a uzivatel (data) s různými vlastníky. Ostatně o té .home variantě v té přednášce mluví.
Systém oprávnění není totiž izolovaná věc, souvisí i s tím jak se ten systém interně používá.
1) Proč by to někdo mazal? Teoreticky omylem může, ale je to stejné riziko, jako že si omylem smaže celý home. Že se stávajícím systémem účet jako takový existuje v systému dál je plat prdné, když jednou zmizí všechna data. Pro uživatele totiž totiž mají cenu jeho dokumenty, ne jeho UID.
2) Pokud z toho máte obavy, dá se to celkem snadno řešit např. pomocí SELinuxu nebo AppArmoru
3) S tím, o čem jsme tady diskutovali výše, by to nebyl problém, na .identity by prostě nebylo nastavené právo smazání.
Zrovna sticky bit je přiklad, jak jeden bit zvládne udělat obrovský chlív. Jeden bit, dva naprosto odlišné koncepty použití (adresáře vs. soubory, u souborů to navíc nedává v 21. století smysl - o tom, že to vůbec nesouvisí s oprávněními nemluvě), nenavazuje dobře na zbytek systému práv. A co "unix", to jiné chování.
Ale hlavně že jedna věc, ale dobře.
Záleží na tom, co myslíte tou podstatou. Zda cíle, nebo prostředky, kterými jsou dosahovány. Protože jak se mění okolní svět, musíte měnit i prostředky, když chcete dojít ke stejnému cíli. Úplně stejně se muselo třeba na začátku dvacátého století řešit, co je podstatou dopravy – jestli je to kůň (prostředek), nebo jestli je to převezení něčeho někam (cíl). Protože k dosažení toho cíle začaly být vhodnější jiné prostředky.
tak to mam asi o 21. stoleti jinou predstavu, pane @silhavy. on ten @poettering asi bude docela chytry jedinec, ale je skoda, ze se neupnul na neco jineho, protoze prozatim mam pocit, ze na co v linux sahne, to rozbije a vzhledem k tomu, jak je urputny, tak zacinam mit strach, ze se mu podari podelat cely linuxovy ekosystem :-(
hlava mi nebere, jak na tohle mohla spousta distribuci naskocit. ze to udelal redhat me neprekvapuje, jejich distro s rpm jsem odepsal uz davno a pokazde, kdyz s nim prijdu do styku (pomerne casto), tak se v mem rozhodnuti jenom utvrdim, ale ze to udelal i debian, to me prekvapilo. diky bohu za gentoo.
to vam vsem, ktery systemd vychvalujete fakt nevadi binarni logy a naproste popreni toho, na cem unix stavi (command dela jen jednu vec, ale dela ji velmi dobre)? mne ten moloch (systemd) vazne desi a bojim se i tohoto noveho napadu s uzivateli...
to vam vsem, ktery systemd vychvalujete
Svět se nedělí na to, co vychvaluji a to, co zatracuji. Je možné docela obyčejně ocenit přínos něčeho, aniž bych z toho dělal existenční drama.
nevadi binarni logy
Binární logy jako takové mají svá plus a mínus. Osobně zrovna na tohle vyhraněný názor nemám a považuju to spíš za implementační detail.
naproste popreni toho, na cem unix stavi
To mi teda fakt nevadí, spíš si říkám, že už bylo dávno načase.
ano prosím
A když vytvoříte soubor mimo svůj home tak se k němu už příští přihlášení nemusíte dostat, protože UID bude dynamická lokální položka.
Teda pokud se mapování USERNAME<>UID nebude uchovávat v nějaké kryptické databázi která bude samozřejmě 10^7 krát lepší než /etc/passwd .
22. 9. 2019, 18:03 editováno autorem komentáře
Myšlenka mi přijde dobrá, i když nechápu, proč je potřeba nějaký systemd-whateverd když se to dá zařídit jedním pluginem do PAMu. Ale po zkušenostech se systemd jako správcem služeb se děsím toho, jak bude vypadat provedení.
> nebo, u zašifrovaných domovských adresářů pomocí LUKS, objektivně žádoucí možnost adresář zamknout a šifrovací klíč vymazat z RAM při uspání notebooku.
Zajímavé, mně tohle fungovalo v roce 2010, když ještě žádný systemd neexistoval. Právě pomocí modulu do PAMu, který měl asi 15 řádek.
99% všeho je skutečně PAM plugin. Ten systemd-homed se stará, pokud jsem to pochopil, jenom o odemykání a zamykání domovských adresářů na šifrovaných loopback souborech, což je velmi specifický scénář, který většina lidí asi v životě nepoužije. Používat systemd-homed jako název pro celý projekt je svým způsobem, jako kdyby se jazyku C říkalo setjmp().
IN-REPLY-TO Debian se musí zabývat přístupem k init systémům/Názory, pořád ještě nepovažujeme systemd za překomplikovaný dávno-už-ne-jen-init-systém?
Pokusme se na chvíli netrollovat a podívjme se na to trochu jinak, než je v těchto diskuzích obvyklé. Systemd není, nebyl a nebude jediná binárka. Ale představme si čistě teoreticky, že by byl, co by to znamenalo v praxi? Myslím si, že v podstatě vůbec nic.
Představme si tři binárky: funkceA, funkceB a funkceC. Jsme samozřejmě ve scénáři, že žádná z nich nemá nějaké zvláštní kapability, setuid root apod. Představme si dále, že by to místo toho někdo přepsal do jednoho programu, ve kterém by byly tři funkce funkceA(), funkceB() a funkceC() a dále main(), který by volal jednu nebo druhou, podle voleb. Z hlediska komplexity vývoje je to v podstatě jedno, každý si napíše svoji vlastní funkci, jediný reálný rozdíl je snad v tom, že některé potenciálně ošemetné věci (konfigurační parser, parser voleb na příkazové řádce, případný drop privilegií a další věci) se udělají jednou pro vždy v mainu, místo aby je každý musel dělat zvlášť a většinou blbě. Z hlediska bezpečnosti by případná zranitelnost v jedné z těch tří funkcí umožnila, např pomocí ROPu atd., volat i ty druhé dvě, ale úplně stejně může volat i ty ostatní binárky (ledaže by se používal seccomp, nějaký privátní kontejner atd., ale v praxi tomu tak téměř nikdy není, nemalou mírou i kvůli jekotu, že tyhle věci nejsou přenosné na BSD a/nebo nejsou tím pravým "unixovým" řešením - viděno na fórech Devuanu...).
Dále je možné se na to podívat tak, že je vlastně úplně jedno, jestli máme tři programy funkceA, funkceB a funkceC, nebo jeden program funkce, se závislostí na libfunkceA.so, libfunkceB.so a libfunkceC.so. I to jsou tři různé binárky, jenom způsob volání je jiný a tak nějak nevím, proč by na něm mělo vlastně záležet. V MULTICSu mimochodem neexistoval rozdíl mezi spustitelným programem a knihovnou a třeba by vůbec nebylo od věci se k tomuto principu vrátit.
A je tu ještě jeden možný náhled, co je vlastně binárka? Nic víc a nic míň, než speciální druh archivu. Je celkem snadné napsat filesystem ovladač (ať už v jádře nebo přes FUSE), aby šla jednotlivá binárka nebo knihovna namountovat a klidně pak vidět každou volatelnou funkci jako samostatnou "binárku". Jde jenom o to, na jakou úroveň si - v podstatě naprosto arbitrárně - nastavíme abstrakci. Z koncepčního hlediska se vlastně dá třeba i /dev/sda považovat za jednu gigantickou "binárku" a i když někdo bezpochyby okamžitě prohlásí, že to je blbost, takový ať si prosím alespoň všimne, že reálné rozdíly jsou vlastně jenom v implementačních detailech.
Problém neni ve formě uložení na disku, ale v závislostech. Pokud máte tři nezávislé funkce, tak prostě použijete jen tu, co se Vám líbí. Pokud vytvoříte tvrdou závislost (řekněme na systemd-logind), tak už tu volnost nemáte a je jedno jestli jsou to nezávislé binárky, funkce nebo dynamické knihovny.
Tak pokud instalujete např. balík coreutils, tak tam těch binárek máte požehnaně a rozhodně nemůžu tvrdit, že už jsem někdy (vědomě) použil všechny. Neboli stále je to jedno, prostě na disku je uložen kód, který třeba Vy osobně momentálně nepoužíváte (ale nevíte, jestli nějaká aplikace třetí strany ho náhodou nebude předpokládat) a nesejde na tom, v kterém konkrétním souboru se nachází. To na tom svém mnohaterabytovém disku máte nedostatek místa, nebo co? ;)
"Systemd není, nebyl a nebude jediná binárka. Ale představme si čistě teoreticky, že by byl, co by to znamenalo v praxi? Myslím si, že v podstatě vůbec nic.".....okrem hlbokeho rozporu so zakladnou filozofiou Unixu.
https://en.wikipedia.org/wiki/Unix_philosophy
"Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features"
"Write programs that do one thing and do it well"
"Economy and elegance of design due to size constraints ("salvation through suffering")."
Ale v principe ten vyvoj v Linuxe, kde na nas unixovych "dinosaurov" neberie ohlad, chapem. "Unixak" dnes nie je najcastejsim pouzivatelom Linuxu.
Řeknu Vám něco, co Vás asi šokuje. Lidé používají počítače proto, aby provozovali aplikace, vydělávali peníze, bavili se multimédii a hrami, učili se atd. Nikdo si nejde koupit počítač za účelem splnit "základní filozofii Unixu". Je to sice na jinou debatu, ale jsem pevně přesvědčen, že ona Unixová "filozovie" je ostatně v základu špatná a škodlivá, maximálně má smysl v některých velmi (zdůrazňuji velmi) úzce definovaných případech.
Kromě toho ta takzvaná "Filozofie" není filozofií, protože nikdo si nikdy nesedl, aby popřemýšlel o tom, jak nejlépe navrhnout funkční a koherentní OS. Unix vznikl z 95% tak, že každý si sám zbastlil nějakou slátaninu, která s odřenýma ušima řešila jeho okamžitý problém, bez žádné celkové vize nebo zamyšlení, jak zapadá do většího celku. Proto máme cron, který neví a nemůže vědět o tom, jaké služby mají běžet, mail, který je tak "geniální", že nemá API a proto nelze normálně mít v aplikaci funkci "odeslat mailem" aniž by člověk musel ručně implementovat klienta SMTP a všechno ostatní, konfigurace textovými soubory, každý s naprosto jinou a nekompatibilní syntaxí, a ex post zavedou bezpečnostní díru jménem setuid, když nějakému Unixovému filozofovi došlo, že v Unixu nejde nastavit různa přístupová práva pro různé části souboru, a tak bych mohl pokračovat donekonečna.
A navíc ta údajná "filozofie" prostě vůbec není pravda. V Unixu neexistuje jediný program, který by dělal "jednu věc". Dokonce i taková trivialita, jako je /bin/false, musí kromě vlastní primární funkce obsahovat... parser (přejděme taktně mlčením to, že je vůbec potřeba, aby existovalo cosi jako /bin/false). A za druhé neexistuje jeden jediný unixový program, o kterém bych mohl s klidným svědomím říct, že něco dělá "well". I ten zmiňovaný /bin/false má historii exploitů, s lpr se táhnou nevyřešené race conditions už desítky let, vi (kromě toho, že nevím, co je tak "well" na tom, že k pohybu kurzoru nemůžu ve výchozím stavu normálně používat šipky kurzoru) je tak proslulý svými bugy, že jiné programy, které se ho snaží nahradit, je musí záměrně implementovat taky, atd atd atd. Děkuji, myslím, že bez toho celkem přežiju a díky za systemd, Lennarte.
V posledním bodě máte pravdu, Unixák asi dneska není typickým uživatelem Linuxu ani typickou cílovou skupinou, ale možná nezbývá, než si spolu s Járou Cimrmanem říct, že o tom můžeme vést spory, můžeme s tím nesouhlasit, ale to je tak všechno, to s tím můžeme dělat.
" Lidé používají počítače proto, aby provozovali aplikace, vydělávali peníze, bavili se multimédii a hrami, učili se atd. Nikdo si nejde koupit počítač za účelem splnit "základní filozofii Unixu". "
S tym suhlasim, ale ak chcem pouzivat a administrovat pocitac tak, aby som skutocne rozumel to co robim a nie ako "cvicena opica, ktora si vie precitat a nasledne doslovne implementovat navod" tak tomu unixova filozofia pomaha. Beriem na vedomie, ze 99% pouzivatelov pocitacov takuto potrebu nema a tomu sa nasledne prisposobuju aj operacne systemy.
23. 9. 2019, 11:31 editováno autorem komentáře
Pak věřím, že jste si sám taky doma sletoval základní desku, abyste nevypadal jako cvičená opice, která tomu "nerozumí". Ze stejného důvodu je samozřejmě vyloučené na ní používat jakýkoli integrovaný obvod. Jak jste daleko s tím vaším překladačem C? Přece jenom cvičené opice se naučí používat gcc aniž by "tomu rozuměly".
PS - berte to prosím s nadsázkou...
Moj prvy pocitac, s vychodonemeckym klonom Z80 (U880D) vratane monitora napisaneho v strojovom kode (ziadny assembler), ktory mal 2kB RAM a 512B PROM, som si postavil niekedy v polovici 80. rokov. Vlastny CPU som si navrhol asi o 10 rokov neskor, ked som pracoval ako navrhar IO a dostal som sa k navrhovemu systemu Cadence.
Vlastny C kompilator nemam, ale jednoduchy Forth na mikrokontroler som si raz naprogramoval :-)
Příkazovou řádku jsem používal pár desítek let a rád ji používám i dnes tam, kde mi něco přináší, místo, aby byla koulí u nohy. Z čeho jsem už trochu vyrostl, je hraní si na l33t unixáka, který nalézá potěšení v tom, že patlá zabugované skripty na věci, které v takovém Windows prostě fungují samy od sebe. Been there, done that, jak se říká, dneska očekávám, že počítač bude plnit roli, na kterou počítače primárně existují, totiž automatizaci nudných, nezajímavých ale časově náročných činností, počínaje správou samotného OS.
> A za druhé neexistuje jeden jediný unixový program, o kterém bych mohl s klidným svědomím říct, že něco dělá "well".
Není to tak trochu klamání? Copak systemd je "well"? Ba co víc, je systemd alespoň víc "well"? Ano, dá se mu přiznat jistá snaha o koncepčnost a deklarativní způsob zápisu já taky rád. Ale obávám se, že už navěky se zapíše do Linuxové historie jako odstrašující příklad "not-well" projektu.
Žádný netriviální program není dokonalý. Systemd je určitě lepší, než to, co nahrazuje: je deklarativní, vychází z principu "všechno je API" místo "všechno je skript nebo textový soubor", je z podstaty bezpečnější (samozřejmě, že taky může mít, a už měl, zranitelnosti), má relativně výbornou dokumentaci a pokud vývojáři dister, většina uživatelů nebo správci data center ve Facebooku a Googlu všichni svorně nelžou, tak celkem spolehlivě funguje. Když někdo neustále opakuje, jak je špatný, tak bych rád slyšel nějaký opravdický argument, nejen povinnou recitaci unixové údajné filozofie nebo "moudra" stylu systemd je jedna obrovská binárka, systemd je x86 only nebo systemd je zlo, protože odstranil problém, který se můj skript snažil blbě řešit a ten skript mi tím pádem už nefunguje.
24. 9. 2019, 09:58 editováno autorem komentáře