Portál AbcLinuxu, 1. května 2025 20:41
Proto se taky mluví o GNU/Linuxu. Gratulace oběma.
Řekl bych, že dnes už toho GNU v linuxu moc není a do kernelu přispívají korporace
Linux je jen jádro. GNU/Linux není to, co si stáhneš z kernel.org, ale to, co se dostane na tvůj počítač v podobě nějaké distribuce.
Takže se jedná o ryze korporátní projekt. Bohužel.
Vzhledem k tomu, že největší objem práce jsou vlastně ovladače hardwaru a související věci, tak mi na tom nepřijde až tak nic špatného – prostě přidávají podporu pro svůj HW. Jiné velké firmy přispívají k tomu, aby ten systém běžel dobře na velkých serverech nebo měl naopak nějaké optimalizace pro mobily atd. to mi taky přijde OK. Ty kontroverzní/diskutabilní věci typu systemd se obvykle odehrávají mimo jádro.
Linux je jen jádro. GNU/Linux není to, co si stáhneš z kernel.org, ale to, co se dostane na tvůj počítač v podobě nějaké distribuce.Ve které toho z GNU moc není.
Až na takové drobnosti jako GCC, coreutils, Grub, make, AWK, Gnome, Gimp, GnuPG, Emacs, Guile, Bash, Midnight Commander, wget, GnuRadio, GnuCash, parallel, screen, GTK, Octave a spousty dalších aplikací a knihoven. Nemluvě o projektech, které třeba nejsou oficiální součástí GNU, ale sdílí stejné hodnoty a navazují na to, co začal RMS.
Jen jsem tím chtěl naznačit, že linux už je primárně vyvíjen a používán velkými firmami.
Takže už to dávno není "lidé sobě".
Takže tu máme Microsoft s Windows, Apple s MAc OS a pár korporátních firem s Linuxem.
Dost zásadní rozdíl je v tom, že ty první dva systémy jsou proprietární, zatímco ten třetí je svobodný ;-)
nebo napis konkretne CO by BFU v Debianu(s Xfce/KDE/Gnome) MUSEL konfigurovat v terminalu... Já cca 2012 nainstaloval Sida a od tý doby jen upgrade.
Linux lze provozovat bez systemd, ale člověk musí být geek, který se tomu věnuje, ne normální uživatel.
BFU by zase neměl dělat nic speciálního, aby narazil na problémy se systemd – a pokud na ně narazí, tak se to nahlásí jako chyba a budou to řešit třeba v tom Red Hatu.
Tohle mi přijde jako vykonstruovaný problém (uživatel, který si neumí ani vybrat distribuci, ale zároveň je tak náročný, že mu nestačí výchozí nastavení v Ubuntu/Debianu/Fedoře/SUSE/…).
systemd upstream se zajímá spíš o embedded nasazeníPreboha a prečo? Spravujem aj pár embedded zariadení ako kamery, nejaké optické snímače, IO moduly... a systemd je tam len na prekážku. Načo je dobré mať v jednoúčelovej krabičke, kde beží počet procesov blížiaci sa nule moloch ktorý tam robí najväčšie problémy? Napr. na takej kamere je odhalenie že niečo padlo asi ten posledný problém, kedže z nej neleze obraz. Tu je fakt Bash najlepší pomocník a nechápem (ja viem managery) nasadenie a tie hlášky čo z toho lezú...
v "jednoúčelové" krabičce může běžet větší množství našich procesůJako nechápem, asi mám v mozgu málo bizmis buniek. Je to jednoučelové zariadenie ako píšeš, beží tam presne daný počet služieb, takže načo tú šmejďárnu? Ako som písal vyššie systemd ako tak rieši, že niečo beži, ale nijak nerieši, že z toho lezú hovná. Na toto sa aj tak píšu skripty a keď už píšem ten skript, tak zistím že mi je celý systemd vlastne k hovnu. Kurwa čo je jednoduchšie ako ušiť Linux enviroment na konkrétnu krabičku a bude to fungovať sto rokov. Kľudne s tebou pôjdem na pivo, ale toto už predomnou niky nespománaj kámo.
Pak přijde další věrozvěst s tím, že xinetd je fuj a že se má používat systemd socket based activation.
Když už je řeč o xinetd: tam by zasloužilo doimplementovat podporu unixových soketů a případně podporu dědění více otevřených FD z rodičovského procesu, což pak vyžaduje i nějaké API (třeba proměnné prostředí), přes které rodičovský proces potomkovi sdělí, který FD je který (např. 4 = IMAP4, 5 = POP3, 6 = HTTP pro správu). Systemd má sice hlavičkové soubory s pár funkcemi pro identifikaci těch FD a teoreticky by jiný init systém mohl toto rozhraní implementovat, ale AFAIK to není standardní stabilní API určené k tomu, aby ho implementoval někdo třetí, takže by to byla taková partyzánská akce a dříve či později by to skončilo nekompatibilitou. Obecně je to ta standardizace, o které mluvím. Stejně tak by se hodilo mít standardní formát pro deklarativní popis služeb – základní metadata, závislosti, sokety + volitelná rozšíření jednotlivých init systémů – ale ten základ by byl stejný a velké části služeb by stačil. Pak by stačilo mít jeden deklarativní popis služby a dal by se použít napříč distribucemi a init systémy, nebo by ho stačilo jen lehce rozšířit o specifika jednotlivých init systémů.
Problém s tou kritikou je, že ačkoli je systemd v mnoha ohledech špatný, tak ta jiná nabízená řešení nemají odpovídající funkce a nejsou plnohodnotnou náhradou (viz třeba ten xinetd). Ono kdyby ty hezké vlastnosti ze systemd někdo implementoval jinde (a modulárněji a s menším množstvím kódu), tak by to byla ta nejúčinnější kritika systemd.
U některých velmi okrajových případů použití jsme museli párkrát kouknout do zdrojáku nebo lehce opatchovat - kód přehledný, čistý, s řadou starších projektů se spoustou historického balastu se to nedá srovnat.
S tímhle mám právě problém. Systemd má skoro půl milionu řádků kódu a to je podle mého nepřiměřeně mnoho. Jednak bych čekal lepší poměr mezi dodanou funkcionalitou a počtem řádků a jednak je to monolitické monstrum, kde máš v jednom gitovském úložišti mnoho komponent. Tohle by zasloužilo rozdělit na moduly, aby si z toho každý mohl vzít jen to, co pro své použití potřebuje (a jen to stahovat a kompilovat).
Pro srovnání: celé GNU Guile (implementace programovacího jazyka Scheme) má nějakých 270 tisíc řádků. Takže i kdyby k systemd přibalili Guile, stále by jim zbývalo přes 200 tisíc řádků pro samotnou implementaci, kterou by navíc mohli psát ve vyšším programovacím jazyce. Nebo taková Lua má jen 32 tisíc řádků, takže kdyby přibalili Luu a psali v ní, možná by to mohlo být výrazně kratší, než to mastit celé v C. Nebo to mohli napsat v C++ (beztak to kompilují kompilátorem, který C++ podporuje a je v něm i sám napsaný) a opět by to bylo o dost kratší.
A jak jsou na tom jiné init systémy: OpenRC má 16 tisíc řádků, GNU Shepherd 4 tisíce, Upstart 76 tisíc, InitNG 38 tisíc, Launchd 21 tisíc. Neříkám, že ta funkcionalita je shodná se systemd, ale ten základ lze prokazatelně implementovat s řádově nižší komplexitou a všechny ostatní komponenty můžou být volitelné.
Jinak souhlasím, že systemd má i hezké vlastnosti, líbí se mi deklarativnost konfigurace a řada funkcí. Z uživatelského hlediska s ním nemám zásadní problém (až tedy na extrémní pomalost napovídání v Bash completion).
S tímhle mám právě problém. Systemd má skoro půl milionu řádků kódu a to je podle mého nepřiměřeně mnoho. Jednak bych čekal lepší poměr mezi dodanou funkcionalitou a počtem řádků a jednak je to monolitické monstrum, kde máš v jednom gitovském úložišti mnoho komponent. Tohle by zasloužilo rozdělit na moduly, aby si z toho každý mohl vzít jen to, co pro své použití potřebuje (a jen to stahovat a kompilovat).Není to monolitické monstrum. Snad jen tím, že je to spousta komponent v jednom repozitáři se společným vývojovým cyklem. Možná je to špatně, nás to nijak neomezuje a používáme jen ty komponenty, které potřebujeme. Pro průmyslové embedded projekty se obvykle dělá build úplně všeho ze zdrojáků a nepotřebné věci není třeba kompilovat vůbec. Ten projekt poskytuje možnou náhradu pro spoustu dalších věcí než jen init systém. Třeba timesyncd pro základní použití nahradí ntpd, networkd nahradí dnsmasq, journald nahradí rsyslog (plus tam jsou komponenty pro remote forwarding server/klient), LLDP server, radvd ... Když se tohle všechno započítá, plus tradiční problémy s připraveností a ohýbáním jiného SW na cross-kompilaci, tak to není zas tak zlé. Součástí repository je dále udev, jednoduchý bootloader (dříve gummiboot), pomocné nástroje jako systemd-analyze, různé -generatory pro kompatibilitu s legacy řešeními a další. Organizováno je to celkem přehledně a nepotřebných komponent si člověk nevšímá. Jednotlivé komponenty nejsou použitelné úplně samostatně, nemají úplně stabilní API, takže je v praxi jediné rozumné je používat všechny ve stejné verzi a pak už není tolik důvodů štěpit to na desítky repositories a přidávat overhead se správou toho, které verze spolu fungují. To neznamená, že to je monolit, lze použít poměrně minimální core subset a další jednotlivost dle potřeby. I ten core je proti minimálním init systémům poměrně velký, ale další konfigurovatelná menší varianta už by podle mě byla za příliš velkou cenu. Navíc počet řádků nepovažuji za úplně vypovídající metriku. Systemd je plain C, což samozřejmě vede ve srovnání s jinými jazyky na větší rozsah kódu, ale asi k tomu byl nějaký důvod.
systemd neni init, ale distribuce. (staci pridat jadro, bootloader a vlastni applikaci)
Na druhou stranu, řada lidí si dlouhodobě stěžuje „jak je ten Linux roztříštěný a základní věci jsou v každé distribuci jinak“. Pak přijde někdo, kdo se to pokusí sjednotit a udělat nějaký základ, který by mohl být stejný napříč distribucemi… a lidi si zase stěžují.
Svým způsobem chápu oba ty pohledy :-) Podle mého je řešení v té modulárnosti. Chápu, že definovat stabilní (resp. sémanticky verzované) API mezi komponentami něco stojí a je to „práce navíc“, ale myslím, že by to za to stálo. Tzn. když už je to tak velký projekt a závisí na něm tolik firem a lidí, tak by i ten vývoj měl být profesionálnější, méně punkový a měla by tam být nějaká standardizace.
Z uživatelského hlediska s ním nemám zásadní problém (až tedy na extrémní pomalost napovídání v Bash completion).to mi taky vadi, jde o to ze pred napovidanim kontroluje jake sluzby ne/bezi a buhvi co jeste (protoze zobrazeni stavu vsech sluzeb mi time hlasi real 0m0,015s, rozpasrovat i zprasene bash skriptem by bylo max 0.5s ale na tab systemctl zareaguje az za 2s), nedavno tu nekdo nadaval odkaz na workaround v podobe vypnuti zjistovani stavu(tusim) ale to mi nepomohlo (nebo to mozna z vice s zkratilo na ty 2s), kazdopadne pro okamzite tab doplneni pouzivam: "service sluz<tab>" ktere (alespon v *buntu 18.04) vola ve vysledku stejne systemctl... a navic nenarazim na nesmyslne prohozeni poradi "codelat sluzba" ale klasicke "sluzba codelat" :)
měl jsem půjčený MacBook Air
+1, měl jsem půjčený nějaký MacBook Pro, stejná zkušenost. Po HW stránce to působí kvalitně (i když klávesnici a myš jsem si tedy připojil vlastní). Ale jinak nevím, co pozitivního o tom říct – asi tak, že je tam GNU Bash, a tím pádem celkem použitelný příkazový řádek (byť tam spousta programů chybí).
Tím GUI bych si nebyl tak jistý. Chápu, že je to i otázka zvyku a někomu to možná vyhovuje, ale mně to přišlo horší než KDE, které používám.
nikdo nebere grafickemu designerovi (coz ty dle vystupovani asi tezko budes, ale hlavne ze jsi ukradl Photoshop na zruseni cervenych oci kdyz ses ozralej fotil) ze je pro nej macOS lepsi
Ono i v oblasti grafiky se toho hodně změnilo. Stačí se podívat, jaké úžasné věci jsou lidé schopní vytvořit ve svobodných nástrojích jako Gimp, Krita nebo Blender. Podpora tabletů a 3D myší je v GNU/Linuxu taky slušná. A i nějaké ty CADy jsou…
utokama ve forme lhani, pomlouvani a prekrucoani si prisel prvni, takze se nemuzes divit kdyz ti to nekdo "vraci"Lžeš, nikde jsme na nikohjo neutočil a už vůbvec nikoho neobviňoval z trestného činu
ze mas pocit ze ti gimp nestaci, neznamena ze nema moznosti k zvladnuti tvejch potreb...Lžeš, gimp velmi dobře znám a pro určité účely používám - pro mé fotografické účely je ale naprosto nedostatečný.
k cene Adobe, pokud vemu jen cenu Photoshop+Lightroom tak za rok jde o 21000KcLžeš, fotografický plán (Photoshop+Lightroom+...)stojí 25 EUR měsíčně, což je necelých 8000 ročně. V akci, aktuálně do konce srpna, za 10 EUR, tj něco málo přes 3000 ročně. To je částka, za kterou nedostaneš ani slušný fotomobil.
Vzhledem k tomu, že Gimp nebo Kritu nebo jakýkoli jiný svobodný software můžeš používat neomezeně dlouho, tak se cena odpovídajícího předplatného proprietárního softwaru blíží nekonečnu.
O jakých šmejďárnách mluvíš? Na komerčním sw není nic principiálně šmejdského a Adobe SW pro fotografy je na špičkové úrovni.Ja ti tvoj názor ani nechcem vyvrátiť a verím, že si naozaj spokojný. Tak pochop aj druhú stranu.
A co by to přineslo? Bude to na 32bitových tisknout kvalitněji? Jinak tohle je věc, kterou si tam člověk vymění/dobastlí celkem snadno.
do kernelu přispívají korporacePokud se da pouzit i nejen pres tu korporaci a navic je to cele modularni pak jen vidim +.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
26.8.2019 14:09
26.8.2019 21:14
26.8.2019 15:10
26.8.2019 17:51
26.8.2019 18:42
27.8.2019 16:32
28.8.2019 09:32
28.8.2019 09:49
29.8.2019 01:07
26.8.2019 22:23
26.8.2019 19:22