SystemD - Jak dál (diskuse)

[java]

Proč FreeBSD? A proč ne třeba Slackware?

[Jack Hokus]

Dobrý den,

jednoduchá odpověď, FreeBSD je moje řekněme srdeční záležitost. Proto padla volba na něj.

Petr

[jadd]

Obrázek čertíka se ti líbí?

[=^..^= AmigaPower®]

Myslíš ten jak mrdá tuxe?

[jadd]

A kdo z nich nakonec vyhrál?

[=^..^= AmigaPower®]

Ten buvol nebo pakůň nebo co to je, vošukal je voba...

[Grunt]

Ten buvol nebo pakůň nebo co to je

To je antilopa ty vole. Wildebeest, kdyby něco.

[=^..^= AmigaPower®]

Zajímavý...

Slovo KOKOT Max zcenzuroval a slovo MRDÁ nechal...

[_]

To je z nějakého kotyzova yiff artu?

[=^..^= AmigaPower®]

Nevim co to je

[kotyz]

Projdi si e621.net a budeš vědět. A budeš chtít abys nevěděl

[R]

Ked som naposledy pouzival Slackware, tak bol problem aj s tym "blbym" libreoffice. Oficialny balik neexistuje a neoficialne su stare a/alebo nefunkcne.

[jyrki]

SalixOS...Slackware s dodatecnymi baliky. Tento problem resi spolehlive

[JS1]

SystemD prorůstá Linuxem a pohřbívá pilíře na kterých je Linux postaven, jako možnost sestavit systém z jednotlivých komponent podle vlastní volby.

Tohle je zcela presne, a je jadrem tveho, (IMHO) iracionalniho odporu proti systemd. Proste, ty beres Linux jako hru. A lide, kteri to neberou jako hru (dost lidi by s tim, ze Linux stoji a pada s vyse uvedenym asi nesouhlasilo, protoze Linux pouzivaji na jinou praci a zda je komponentni je jim sumak), najednou zmenili pravidla (toho, co ty uctivas jako hru) a tim se te dotkli.

Podstatne je, ze to cele probiha na emocionalni urovni. Je to jako kdyby jsi hral leta sachy a nekdo zmenil oficialni pravidla, ze treba jde vratit rosadu. Taky by se to spouste lidi nelibilo, rikali by, jak je to najednou mizerna hra. Racionalne ale vzato, ta hra by zustala zhruba stejna. Pocit, ze byla predtim lepsi, je jen nostalgie.

Cele je to o nadhledu, uvedomit si, jaky problem se snazis vyresit. Ten problem muze byt i "chci si hrat" (coz se mi zda byt tvuj pripad, kdyz rikas "možnost sestavit systém z jednotlivých komponent"). Pak to ale vubec neni o systemd - je to o tom "chci vyzkouset, jake je BSD". Pokud to tak necitis, budes nakonec z BSD taky zklamany, protoze tech neprakticnosti nejspis nakonec bude vic, nez u Linuxu se systemd.

[Ondrej]

v tom co jsi napsal je mozna takl trochu pravdy na tom, ze OP si chce hrat. Ale to je asi tak vsechno.

Tvuj priklad s tema sachama je totalne mimo. Ja uvedu jiny priklad, a to s autama, protoze v kazde diskuzi musi byt priklad s autem. Mame tedy auta osobni, nakladni, obojzivelna, rodine a sportaky - proste pro kazde nejake pouziti je to trochu jine auto. A presto v kazdem z tech aut se pouzivaji stejne srouby, matice, klinove remeny, trysky a buhvi co jeste. Rika se tomu modularita, neco , cemu je software jeste na hony vzdalene. A proto vznika takove Lennartware, ktere proste modularitu zabiji.

Samozrejme, ze na vine neni jen pan Poettering. Firma RH je firma se schopnym managementem a tito lide vedi, ze servry je navzdycky neuzivi. A proto se rozhodli, ze se pokusi ukrojit i neco z toho kolace trhu tabletu a tech jinych mobilnich blbustek. Jako operacni system potrebuji ale neco, co nabootuje rychleji nez nejaky bezny linux a zrovna tak i v oblasti servru , ktere musi bezet skoro porad je urychleni bootovani zadouci. Modularne by se to udelalo tak, ze by byly ruzne linuxy pro ruzna pouziti. Uz pred 20 lety pozadoval Mike Gancarz spec. linux pro desktop. Ale to panum informatikum nevoni a proto budeme mit linux pro 'uplne vsechno'.

[JS1]

Ta stiznost "neni to modularni" neni technicky argument. Na to je totiz prilis hruby - museli bychom se bavit o konkretnim defektu. A pokud chces argumentovat jakkoli jinak, nez "je to hra", musis prednest technicky argument, jinak je to diskuse o nicem (a trochu to pripomina slavnou debatu o mikrokernelu).

To co rikas naprosto ignoruje fakt, ze systemd pomaha serverum taky, v jinych smerech (napr. sprava demonu). Ten priklad s temi soucastkami kulha, protoze systemd je modularni - presne podle soucasne urovni znalosti o tom, co je potreba.

[TM]

Já vám vůbec nerozumím. Až donedávna jsem si myslel, že Linux používáme proto, že nám vyhovuje filosofie Unixu, která, mimo jiné vyznává principy jednoduchosti, průhlednosti a snadné portability - to jsou naprosto zásadní technické vlastnosti.
Teď vidím, že jsou tu tací, kterým se snad líbí to, co vše z toho zásadním způsobem pošlapává. Kroutím hlavou a říkám si, proč nám otravují vzduch, když svůj OS už dávno mají - jmenuje se Windows a je ho všude kolem plno.
Proč vytvářet nová Windows?
To nesouvisí s nějakým "chci si hrát". To znamená “chci pružný, variabilní OS, který mě poslouchá, neomezuje a neotravuje blbostmi - prostě chci v nějaké podobě Unix.“
RedHat udělal pro Linux hodně a nelze mu to nijak upřít. Ale to, jak to vše teď pomocí té bandy magorů a bastličů kolem Poeteringa, zabijí, to je k pláči - hodně smutné

[podlesh]

Já vám vůbec nerozumím. Až donedávna jsem si myslel, že Linux používáme proto, že nám vyhovuje filosofie Unixu, která, mimo jiné vyznává principy jednoduchosti, průhlednosti a snadné portability - to jsou naprosto zásadní technické vlastnosti.
Teď vidím, že jsou tu tací, kterým se snad líbí to, co vše z toho zásadním způsobem pošlapává.

WTF? Kritiku toho, jak Linux pošlapává UNIXové principy, již čtu pořád dokola 18 let (vesměs od příznivců *BSD).

[frdrx]

Příznivci *BSD pouze ventilují mindráky z toho jak ten ty jejich zázraky GNU/Linux ve všem bez ustání válcuje.

Myslím, že zapomínají na Rule 16:

Rule of Diversity: Distrust all claims for “one true way”.

[frdrx]

A taky Rule 14:

Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

[JS1]

Tak ja za sebe muzu rict, ze filozofie Unixu je jen incidentalni detail; hlavni duvod, protoze pouzivam Linux je proto, ze je to OSS a s tim spojenymi vyhodami. Ano, znamena to spis dobry navrh, protoze se na tom podili spousta lidi, a mnoho z nich to dela "z lasky". Ale kdyby byl postaveny na necem jinem (ja bych treba rad system, kde by programovacim jazykem vyssi i nizsi urovne byl Lisp), vyslo by to nastejno.

Strucne receno, z toho pozadavku, ktery chces, nijak nevyplyva nic proti systemd.

P.S. Vzpominas si jeste na dobu, kdy se na Linuxu musela disketa nebo CDRom rucne "mountovat"? Tezko by to dnes nekdo nepovazoval za "neotravovani blbostmi" - vlastne ani v te dobe ne. Ano, Unix je elegantni - ale navrzeny trochu pro jinou eru.

[Heron]

Vzpominas si jeste na dobu, kdy se na Linuxu musela disketa nebo CDRom rucne "mountovat"?

Jak vzpomínáme? To snad platí dodnes. Nebo snad on má někdo nastavený systém tak, že po detekci nového blokového zařízení něco z křišťálové koule vyvěští, jaký asi fs tam je a s jakými parametry to asi chce někdo připojit? A chce to vůbec připojit? Nechce s tím pracovat právě jen jako s blokovým zařízením?

[pavlix]

Nebo snad on má někdo nastavený systém tak

Není to náhodou výchozí stav nejběžnějších distribucí?

[Heron]

Netuším, vycházím z chování CentOS 5 a 6, Debianu Wheezy a Jessie. Každý připojený USB mass storage si mountuju ručně.

[Josef Kufner]

V tom případě si udělej výlet do světa moderních desktopů a uvidíš, že po připojení se objeví upozornění na nové zařízení a po kliknutí na něj se připojí. Odpojení pak je velmi podobné. V KDE jsem viděl i volby na automatické připojování známých (dříve připojených) zařízení (nastavitelné pro jednotlivá zařízení) a podobné hračky.

[Heron]

Tohle samozřejmě vím, ale považuji to špatnou vlastnost.

[Josef Kufner]

Co je špatného na tom, že když chci připojit flashku, stačí kliknout na její ikonku? Automatika jen detekuje nové blokové zařízení, nepřipojí se to samo, pokud nechci (což je výchozí konfigurace).

[Heron]

Oddaluje to člověka od počítače. Spousta lidí vůbec neví, jak věci fungují, ty věci jsou schované za x vrstvama více či méně prostupné izolace a tito lidé si dělají špatný obrázek o tom, jak věci ve skutečnosti fungují uvnitř.

V praxi se setkávám s lidmi, kteří nejenže nezbytně potřebují phpmyadmin (protože jinak nejsou schopní s mysql pracovat), ale dokonce phpmyadmina považují za tu db samotnou. Důsledky asi netřeba dál popisovat.

Dnes se dokonce objevuje pojem empatie k hw a označuje se tím to, že ten člověk (nejčastěji vývojář v nějakém vysokém programovacím jazyce) zná a rozumí tomu, co tam někde v hloubce dělá ten hw. Tohle je důsledek toho, že ti lidé běžně vůbec neví, jak se stane, že ten jejich produkt vlastně běží. Takže honem další buzzword hw empathy.

Pochopitelně já to mám ve svém xfce také tak. Nepřipojuji flash disk přes mount. Ale vím, co všechno se "na pozadí" musí provést. Na rozdíl od jiných, kteří vyrostou na prázdných /etc, autovšechno apod.

Abych nebyl špatně pochopen, já nepovažuji automatizaci za špatnou. Ale ten člověk musí být schopen to v první řadě umět udělat ručně už jen proto, aby věděl, co všechno ten automat může a co naopak nemůže dělat.

[Jendа]

Flash připojuju ručně, ale znamená to zjistit z dmesg písmenko a číslo. Okýnko s dotazem by potěšilo. Jak mě takové okýnko „oddálí od počítače“?

Adminer (dle mého názoru lepší než phpmyadmin) používám, protože z hlavy nedám CREATE nebo ALTER se správnou syntaxí, tak si to radši naklikám. Databáze fakt nedělám každý den, tak to holt neumím.

[onanista]

ano vazeni, toto je ucebnicovy priklad technicke masturbace

[m.]

a na masturbaci je neco spatneho?

[biolog]

Lidé, co nezbytně potřebují phpmyadmin nebo jej dokonce považují za db samotnou, počítačům nerozumí. A ejhle, přesto dokáží provést jednoduché databázové operace. Ta vrstva zvyšuje jejich produktivitu, bez ní by měli produktivitu nulovou. (Důsledky asi netřeba dál popisovat.)

Ano, je užitečné vědět, jak to ten hardware dělá. Program je pak rychlejší, bez těch extra vědomostí by jenom fungoval (program od extrémních amatérů by samozřejmě nefungoval). Je potřeba vědět ty vlastnosti stroje nebo systému v těch ohledech, kde se chová nějak nežádoucně. Např data rozhozená na pevném disku náhodně se budou číst pomalu, tedy pro efektivní používání disků to musí programátoři (a rádoby-programátoři) a částečně uživatelé vědět. U SSD disků to pravidlo/omezení neplatí, tedy se to vědění neuplatní.

Ale rotující disky lépe udělat nejde, kdežto software obvykle ano. Např vyhledání (ne instalování) bezpečnostních záplat mi rachotí s diskem a zpomaluje steamování videa, přestože vím, že stačí stáhnout jeden malý soubor a porovnat s posledně staženým souborem (pokud od posledně nové záplaty nejsou) nebo (pokud nové jsou) stáhnout větší soubor a při slévacím algoritmu z disku sekvenčně přečíst seznam nainstalovaných balíků. (V tomhle případě přílišné vědomosti uvádějí v omyl o tom, jak jsou aktualizace implementované.)

Pro porozumění fungování je stejně efektivnější kouknout do Wikipedie nebo do učebnice, skript nebo na online kurz - je to poučnější než v manuálu koukat, co které písmenko dělá (čí přepínač, jméno programu program nebo volby v konfiguráku), která písmenka je potřeba je potřeba přidat aby to dělalo to co se obvykle potřebuje, které volby jsou principiálně důležité a které jsou jen proto, že to tak bylo napsané. Ty extra vrstvy v reálném OS člověka od poznání neoddalují, protože reálný OS je na učení nepraktický.

[Heron]

Důsledky asi netřeba dál popisovat.

Ty důsledky by mě tedy zajímaly. Protože většinou to dopadne tak, že mají efektivitu zápornou (tedy, Česky řečeno, přidělávají práci ostatním).

bez těch extra vědomostí by jenom fungoval

Nebo by jen vypadal, že funguje.

Ale rotující disky lépe udělat nejde, kdežto software obvykle ano.

Ale lze je používat lépe. Pokud někomu jedna činnost zpomaluje na stejném disku druhou činnost, tak by se měl zamyslet nad tím, zda by nebylo vhodnější ty činnosti serializovat (aby se využilo 200x rychlejšího sekvenčního čtení disku oproti náhodnému) nebo naopak paralelizovat hw (práci paralelně vykonávat nad nezávislými disky -- potom se třeba může narazit na propustnost řadiče disků nebo sběrnic).

[biolog]

Ty důsledky by mě tedy zajímaly. Protože většinou to dopadne tak, že mají efektivitu zápornou (tedy, Česky řečeno, přidělávají práci ostatním).

To je nesmysl. Důsledek je, že tu práci mohou dělat i lidé, kteří by ji bez nástrojů dělat nemohli. (Předpokládám, že namítnete, že existují věci, na které musí být zkušený odborník - to je pravda, ale nemá to vliv na typický případ.) Když to dopadne špatně, použili neadekvátní program, který produkuje výsledek, který vypadá laikovi OK, nemá Undo atd. Nebo nemají vědomosti, které se týkají jejich oboru (že v účetnictví existují odpisy); pokud mají problém s ovládáním SW (např kde v účetním SW najdou odpisy a jakým tlačítkem vytvoří nový záznam a zda se už vytvořil) je to chyba softwaru. Linuxáci tohle zaměňují.

Phpmyadmin nenahradí znalost toho co je tabulka, co je normalizace dat, efektivní vyhodnocování SQL dotazů, ale nahradí znalost syntaxe SQL, znalost v jaké DB jsou definovaní SQL uživatelé atd. (Asi namítnete, že existuje SQL příkaz, který phpmyadmin neumí.)

bez těch extra vědomostí by jenom fungoval

Nebo by jen vypadal, že funguje.

I to je možné. Ale to nevyvrací to, co říkám, a sice že vědomosti pomáhají. Podívejte na všechny ty redakční systémy, informační systémy aj. Fungují, přestože je píší středoškoláci, co se naučili PHP kecáním na fórech. Profík by to napsal lépe, ale fungují i tak. (Teď namítnete, že nesplňují normu, takže nefungují. Nebo že jste viděl aplikaci, která často padala nebo byla příliš pomalá.)

Ale lze je používat lépe. Pokud někomu jedna činnost ...

Ano, to je další příklad znalosti, která se hodí vědět při používání pevných disků. Jenže u softwaru je často potřeba něco vědět jen proto, že je tak udělaný, přestože by nemusel. Například mí rodiče nerozumí tomu, proč se musí ztratit stav spuštěných programů, když chtějí vypnout počítač (tím myslí přepnout jej do stavu, kdy nedělá hluk a nežere elektřinu), přestože by si počítač mohl stav RAM uložit na disk. (Teď už jim suspend funguje.) Podobně nerozumí proč by měli oni (jiní ať si konfigurují dle libosti) konfigurovat síť, když se počítač může se sítě zeptat. (Dhcp jim taky už funguje.)

[Bedňa]

Pretože neochota sa vzdalávať ide ruka v ruke s naivitou že tu raz bude dobre.

Prečo by tu raz malo byť dobre pokiaľ väčšine vyhovuje nevedomosť a to sa nebavíme len o IT.

[Josef Kufner]

V současném světě je toho tolik a natolik složitého, že to jeden člověk nemá šanci ovládnout vše. A to platí i o detailech toho, co běžně dělá. Když si chci uvařit oběd, nepotřebuju vědět jaký plyn mi jde do sporáku, nebo jak vypadá ventil, kterým ho ovládám, nebo jaký je vhodný tvar hořáku. Stačí mi vědět, že ho musím zapálit a pak to hřeje.

Neochota vzdělávat se je naprosto v pořádku, neboť mám na práci lepší věci, například se vzdělávat v tom, co mne zajímá.

[Bedňa]

Kupodivu aj tebou spomenutý príklad čiastočne ovládam. Zaujímam sa o veci okolo seba. V baráku asi nieje vec ktorú by som nemal v ruke. Nedalo by mi ani pozerať sa na telku aby som ju nevidel z vnútra. Možno som iný ako ostatné deti, ale takto to vnímam ja.

[=^..^= AmigaPower®]

To by ste se divil pane! Ale hlavně ginekologii jak Bedňa ovládá! Von se zajímá o věci kolem sede, v ulici neni kunda ve který by neměl ruku...

[Bedňa]

Jj a podnes ma majú všetky radi, čo mojej neviem prečo vadí

Ako náhody neexistujú, tak moja si zrovna teraz zavolala pomocníka z vesnice aby nám pomohol zo sťahovaním nábytku a moja mama nezabudla dodať že je to syn mojej bývalky, čo mojej určite prospelo

[biolog]

Ti lidé typicky jsou ochotní se vzdělávat, jinak by neznali phpmyadmin, PHP a podobné snadné věci. Možná se vzdělávají v jiném oboru informatiky (3D grafika?), nebo v něčem jiném než informatika (např zaměstnavatel vyrábí plasty). Možná rozeznají rozdíl mezi univerzálními vědomostmi a pouhou syntaxí příkazů (a konfiguráků a názvů programů a souborů atd) a to druhé ví, že si nemusí pamatovat, stačí vygooglit až nastane příležitost.

Prečo by tu raz malo byť dobre pokiaľ väčšine vyhovuje nevedomosť

Protože ta minimální úroveň stačí na skoro vše. Stačí míst dost odborníků na pár těch důležitých věcí.

[Jendа]

Fungují, přestože je píší středoškoláci, co se naučili PHP kecáním na fórech. Profík by to napsal lépe, ale fungují i tak.

Ano, fungují výtečně. Z těch zajímavějších mi dokonce díky SQL injection běží lokální mirror.

[biolog]

Někdy je výsledný program pomalý, někdy má bezpečnostní díry (někdy vykonání kódu, někdy jen SQL injection, někdy jen XSS, někdy jen DoS). Ale stále je ten software obvykle užitečný. Heron a teď Jendа říkají, že někdy je ulepený SW naprd, to je pravda, ale většina SW (skoro všechny webky) je taková a je užitečná. Všichni by chtěli bezchybný SW, ale málokdo je ochotný za něj odpovídajícně zaplatit. To mám vyjmenovávat každou nepodstatnou výjimku z mého tvrzení? (Že u vás je něco jinak, je nepodstatné.)

[Bedňa]

ale málokdo je ochotný za něj odpovídajícně zaplatit.

A to sa ti zdá malo niekoľko miliárd za nefunkčný daňový softvér na Slovensku? Nefunkčný prepis aut v Česku, alebo datové schránky ktoré sa riešili roky?

O penizoch to rozhodne nieje, ako vidíme profesionalita tiež vedie do peknej prdele, teda väčšej ako ten čo sa to naučil z webu.

[biolog]

Státní zakázky nejsou protipříklad na mé tvrzení. Veřejnost chce kvalitní software, ale úředníky, kteří o zakázce rozhodují, zajímá teplíčko, případně aby jim kamarád dodavatel přihrál nějaký ten milion úplatku.

Neznám případ slovenského daňového systému, ale u registru vozidel v ČR je malý objem dat a nejsou tam žádné složité operace. Na jeho implementaci by stačil kompetentní PHP kodér, není třeba génia z MFF UK, není třeba pokročilé znalosti DB, ani tušit co jsou pointery, rekurze či dokonce algoritmus.

[Bedňa]

Takže som majiteľom firmy a objednám si u profíkov čo robili daňový systém na Slovensku softvér, ako zistím že by to študák spravil lepšie za tisícinu ceny? Všetko o profi firmách sú báchorky na vyťahanie prachov, Pokiaľ do toho nevidíš tak s tebou zametú.

[biolog]

To majitel nezjistí, bohužel. Poznat kvalitní software je pro laika těžké, to nemění nic na mém tvrzení, že kvalitní programátor (vy byste řekli správný programátor) je drahý. Teoreticky vzato, kdyby byl od packala naprosto neodlišitelný, nemohl by chtít víc peněz, ale trochu je poznat jde.

(Připomínám, že jsem řekl, že by stačil kompetentní PHP kodér, ne génius ani packal. Nevím do které z těchto 3 skupin spadá průměrný študák za tisícinu ceny.)

[pavlix]

Poznat kvalitní software je pro laika těžké, to nemění nic na mém tvrzení, že kvalitní programátor (vy byste řekli správný programátor) je drahý. Teoreticky vzato, kdyby byl od packala naprosto neodlišitelný, nemohl by chtít víc peněz, ale trochu je poznat jde.

Obávám se, že se v této oblasti nejvíc platí za úplně jiné kvality ;).

[pavlix]

Neznám případ slovenského daňového systému, ale u registru vozidel v ČR je malý objem dat a nejsou tam žádné složité operace. Na jeho implementaci by stačil kompetentní PHP kodér, není třeba génia z MFF UK, není třeba pokročilé znalosti DB, ani tušit co jsou pointery, rekurze či dokonce algoritmus.

Odhlédnu li od toho, že spojení kompetentní PHP kodér zní jako oxymorón, nemyslím si, že je dobré, aby něco takového vytvářeli a zaváděli od začátku do konce amatéři. Je sice fajn, že to kdejaký phpkář dokáže splácat na koleni, ale pokud se objeví nějaký problém, tak od toho dá rychle ruce pryč. Nejhorší na tom je, že se u podobných státních zakázek zvládá jak vybrat hodně peněz, tak přenechat veškerou práci břídilům a ještě jim na to dát málo peněz.

[pavlix]

Jinak z vlastní zkušenosti vím, že některé větší firmy v tomto fungují úplně stejně jako státní sektor. Během střední školy jsem takhle za pár drobných pracoval na shopu nadnárodní korporace.

[biolog]

Však neříkám, že by bylo přijatelné, aby to dělali amatéři. Říkám, že stačí střední liga.

Ad oxymorón: PHP je pověstné tím, že jej používají teenageři, to jo. Ale z části z nich (řekněme 10% ?) vyrostli kompetentní PHP programátoři, i přes ošklivost jazyka. Ostatně Mediawiki je psáno v PHP. Facebook taky.

[Petr Tomášek]

Problém je, že ono se to často připojí i když člověk na žádnou ikonku neklikne. A pak se diví, co mu to tam systém zase nasral, když on to chtěl úplně jinak...

[Václav "Darm" Novák]

Tak s tím jsem se v KDE ještě nesetkal.

[Ondrej 'SanTiago' Zajicek]

V tom případě si udělej výlet do světa moderních desktopů a uvidíš, že po připojení se objeví upozornění na nové zařízení a po kliknutí na něj se připojí.

Cimz ale potvrzujes to, co pise Heron - zarizeni se samo nenamountuje, ale GUI nabidne akci 'pripojit' uzivateli. To je varianta, ktera je zaroven rozumna a zaroven user-friendly. Nedavno jsem si tohoto chovani vsiml v LXDE a potesil me odklon od plne automatickeho mountovani (coz jsem vzdy povazoval za spatny krok) v modernich desktopech.

[Josef Kufner]

Nikoliv. Je tam jím zavrhovaná křišťálová koule, která vyvěští filesystém a parametry, se kterými se to má připojit.

[kavol]

... a po kliknutí na něj se připojí.

no a klikáš teda ručně nebo ne?

btw, kde se vzala podmínka, že se bavíme o "moderním desktopu (KDE)", a ne třeba o serveru bez grafiky?

[Josef Kufner]

Pokud je na tom server tak špatně, že je potřeba připojovat flashka, tak má uživatel/správce takové trable, že ho napsání příkazu pod rootem nevytrhne, neboť tam stejnak bude jako root a dávat to dokupy.

Leda by to byl offline zálohovací disk, ale na to si tam připraví skript, který zavolá patřičné nástroje. Na malé objemy dat odpovídající flashce nemá smysl se zvedat ze židle a hledat server, to se zvládne po ssh.

[kavol]

proč špatně? a nebyla řeč o obecném zařízení (floppy, cdrom ...)?

a kde je odpověď na to, jestli za tebe kliká robot nebo to děláš sám?

a co na to Jan Tleskač?

[pavlix]

A vycházíš z výchozí desktopové instalace?

[Heron]

Vycházím z té instalace, kterou si jako admin sám nainstaluji.

[dementni.lojzik]

Samozrejme, ze na vine neni jen pan Poettering.

jj, kdyz obcas ctu zdejsi flamy o systemd, nekdy z toho mam pocit, ze Lennart je inkarnace vsecho zla, ale nepamatuju se, ze bych tady nekdo intenzivne spilal napr. clenum Fesco (kde to IIRC vsechno zacalo, a vsadim se, ze tam tou dobou byli i nejaci cesi)

Firma RH je firma se schopnym managementem a tito lide vedi, ze servry je navzdycky neuzivi. A proto se rozhodli, ze se pokusi ukrojit i neco z toho kolace trhu tabletu a tech jinych mobilnich blbustek.

ne ze bych mel velky prehled o RH aktivitach a projektech, ale ze by RH delal do tabletu a mobilu je teda pro me novinka. Urcite budes mi po ruce link na nejaky relevatni projekt. Ja v souvislosti s mobily vim jen ruzny JS-like sra*kach jako aerogear (coz pochopitelne nema se systemd co delat), ale vim o projektech, ktere systemd vyuzivaji (jako napr. geard) a jsou to ciste severove projekty. Kdyz vezmu v uvahu, jak se RH angazuje v OpenStacku, tak bych rekl, ze to tvoje tvrzeni je dost mimo misu ...

[kavol]

Fesco (kde to IIRC vsechno zacalo

mohl bys tuto svoji verzi historie trošku rozvést?

[dementni.lojzik]

kde to IIRC vsechno zacalo

IIRC byla Fedora prvni distribuce, co mela systemd

Fesco

jak funguji procese ve Fedore moc nevim, ale soude podle tohoto linku (FESCo handles the process of accepting new features), o zacleneni systemd asi rozhodovalo Fesco. Cimz jsem chtel rict, ze kdyz uz byl mel potrebu nekomu nadavat a obvinovat, meli by to spis byt lide, co systemd pustili do jednotlivych distribuci

[lenny]

mna uz ten linux nebavi... a nielen linux proste je to system ktory nikdy nebude siroko podporovany ked vyvojari budu riesit s prepacenim take pikoviny ako systemd a na*ierat uzivatelov. pozrite si ale vazne terazs vsak ste ludia ktory maju sudnost. ak poviem ze revolucny vyvoj nie je naskodu pretoze niekedy je potrebne urobit razny krok preto evolucia nestaci. ale prosim vas preco vsetk yveci v linux sa v poslednych sca 5-7 rokov akoby poblaznili system d je len spicka ladovca , gnome3, kde4, xorg->wayland, ubuntu fUc. unity a podobne. proste tento pan hore ja mu nevidim do hlavy ale myslim si ze nie je to o hrani ale proste len chce nieco co mu da akusi stabilitu co sa tyka vyvoja a pritom si bude moct pouzivat vsetky vychytavky ake mu linux doteraz ponukal.

a linux na 'uplne vsechno'. ano jasne vcera si tak pocuvam jedno nemenovane lokalne radio a redaktor tak kecaaaa nasa apka bezi na vsetkych OS ako Windows, Mac OS, Android a isos, jasne ze o linuxe nikto nezavadi kedze tento nas OS sa stale patla na poli vyvojarkych prerabok. inac vazne pozrite sa take drbnute OpenBSD pomaly dobieha linuxu aj za cenu toho ze ho pomaly vykrada ale je to tak.

[Vantomas]

Když už vytahujeme ty auta, opravdu je tam ta modularita taková? Co třeba takové řídicí jednotky pro motory, je úplně běžné, že jsou stejné napříč několika modely (a u koncernů dokonce napříč značkami), kde si automobilka může akorát tak upravit nějaké konstanty v logice. Jeden možná řekne, že je to modulární, protože to může být všude, ale druhý spíš řekne "je to tam stejný kvůli tomu, že někdo řekl, že to bude stejný, jestli chcete jiný užití, přiohněte si to!"

Já bych to tak nepřeháněl, popravdě nechápu, že nevidíte ty výhody kolem systemd, kde díky jednotnému API je spousta věci usnadněna. Třeba jen tak, jaké existovalo do doby systemd API pro správu služeb v distru? V klikátku jsem si chtěl zaškrtnout, že nechci spouštět apache při bootu. Co mi na to mohli udělat programátoři od GNOME? Od KDE? Ahá, v Mandraku se používal nějaký drakconf-, v Debianu přes update-rc.d.... Popravdě doufám, že až přestanou kvůli tomu všichni vidět rudě, tak hlavně ty výhody přiznají a třeba ať si klidně tříští síly ve vývoj kompatibilní věci, která bude klidně v bashi.

[Ondrej]

nepouzivam cups ale lpd (LPRng). Ja vim, ze si tim dost dovoluji, protoze 'komunita' se rozhodla, ze vsude bude cups a distributori se tim ridi. Ale ja jeste porad verim tem pohadkam od Stallmana a chci vyuzit tech svobod a proto si vzdycky prelozim ten LPRng packet a podle toho, kde se to nasadi zkopiruji do /etc/init.d ten predpripraveny init script.

Protoze to ted se systemd bude vsechno mnohem jednodussi, tak bych Vas poprosil, abyste prepsal v tom LPRng ten lpd daemon tak, jak so to pan Poettering predsatvuje (zejmena tu socket interface). Jak pisete, je to vse jednodussi a ja jsem zrovna u zakazniku pod tlakem.

Dekuji.

[Josef Kufner]

Ten initscript nahraď tímto:

[Unit]
Description=Lprng Printer Daemon
After=network.target

[Service]
Type=forking
ExecStart=/usr/sbin/lpd
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process

[Install]
WantedBy=multi-user.target

(zdroj)

[Ondrej]

smysl Vasi odpovedi jsem nepochopil. Systemd umi nacist stavajici init-scripty a mozna to dokaze lepe nez to editovat rucne (viz checkpc volani ve stavajicich scriptech, ktere kupodivu neni v tom noven systemd scriptu zohledneno).

Jeste jednou, kde je ten patch pro ten lpd daemon?

[Jendа]

Počkej, jakej socket interface? To se normálně spustí a pak to poslouchá, ne?

[Josef Kufner]

V jednoduchém případě, kdy jen veme ten service soubor a stávající lpd, tomu tak je. Ale systemd (a není jediný) má takovou drobnou vychytávku, že poslouchající socket otevře systemd ještě před spuštěním lpd. Ke spuštění lpd a předání již otevřeného socketu pak dojde až při prvním příchozím spojení na tento socket. Je to docela elegantní způsob jak řešit paralelní start služeb, kdy se v prvním kroku připraví všechny sockety a v druhém se spustí všechny služby najednou. V podstatě socket activation v systemd funguje podobně jako inetd, ale spouští démona při prvním požadavku namísto procesu pro každý požadavek.

V případě cups, který má autodetekci a rozesílá broadcasty o dostupných tiskárnách, aby se ostatní počítače nemusely ručně konfigurovat, je potřeba, aby démon běžel hned, neboť jinak by ho nic nenašlo. I tam ale má takový přístup smysl, neboť program, který potřebuje cups, se k němu může připojit dřív, než cups nastartuje a začne obsluhovat socket. Tím se eliminují různé race-conditions, kdy démon musí říct initu, že už je připraven a závisející služby mohou startovat.

[rastos]

Ale systemd (a není jediný) má takovou drobnou vychytávku, že poslouchající socket otevře systemd ještě před spuštěním lpd. Ke spuštění lpd a předání již otevřeného socketu pak dojde až při prvním příchozím spojení na tento socket.

To mi, prosím, vysvetli, ako môže program A vyrobiť socket a odovzdať ho programu B bez toho, aby bol na to program B pripravený a navyše, aby bol program B s nastaveniami toho socketu spokojný.

[biolog]

Program A soket může vytvořit hned a později, až program B nastartuje, mu ho předat (file deskriptory a sokety jdou předávat přes lokální unix pipe). Jaké parametry soketu program B potřebuje (číslo naslouchacího portu, adresa na D-Busu atd), musí popsat v konfiguračním souboru pro A. Mám pocit že většina parametrů se dá (někdy musí) konfigurovat po vytvoření.

[rastos]

To ale znamená, že program B (mylittlenetworkservice) musí byť napísaný, tak by spolupracoval s programom A (systemd). To pri tradičnom init systéme nie je nutné. Ak existuje možnosť (čo afaik existuje), aby systemd nevyžadoval od iných služieb, aby mali v sebe podporu pre systemd, tak sa systemd stáva "optional". Ako tak ale sledujem dianie, tak systemd (/Lennart/RedHat) maká na tom, aby optional nebol.

[Josef Kufner]

Ten socket si může program B vytvořit sám a systemd ho může spustit stejně, jako každý jiný init. Těch věcí, kde se vytváří závislosti na systemd není zas tak mnoho.

Běžné démony si vystačí se závislostí na malé knihovně, která implementuje API pro systemd, ale která nemusí být používána (a podpora nemusí být zakompilována). A to jen v případě, že chce podporovat nějaké pěkné vychytávky.

[biolog]

Ano, program B na to musí být dělaný, zapomněl jsem to napsat. Ve vašem příspěvku "bol na to program B pripravený" jsem pochopil jako "dostatečně nastartovaný", ale mohlo to znamenat "má naprogramovanou podporu". Tu podporu v aplikacích systemd nevyžaduje a asi nikdy nebude moci vyžadovat, protože mu vždy bude možno zatajit, že ta služba nějaké sokety používá.

Spíše by mne zajímalo, proč vznikají závislosti aplikací na systemd. To je tak dobrý? Je to jeho vina že na něm aplikace mohou záviset? Je pravda, že Poettering by mohl počkat, až rozhraní k té knihovně standardizuje třeba freedesktop.org, aby bylo vidět, že je reimplementovatelná. Ale slýchám, že jedou svižným tempem, tipuji že se báli zdržení.

[pavlix]

Spíše by mne zajímalo, proč vznikají závislosti aplikací na systemd. To je tak dobrý? Je to jeho vina že na něm aplikace mohou záviset?

Protože jejich tvůrcům nic jiného nezbývá. Dosud závisely na jednotlivých balících, které poskytovaly jednotlivá rozhraní (consolekit, polkit, upower), teď už ty balíky z distribucí mizí a nahrazují je komponenty systemd. Pokud tvůrci aplikací chtějí na novém systému zajistit stejnou funkcionalitu, musejí podporovat systemd, ale už nemusejí podporovat ty starší projekty.

až rozhraní k té knihovně standardizuje třeba freedesktop.org

Já myslel, že freedesktop.org je v podstatě Lennart, a toho žádná reimplementovatelnost nezajímá, pokud to nepotřebuje použít jako argument.

[Ondrej 'SanTiago' Zajicek]

Já bych to tak nepřeháněl, popravdě nechápu, že nevidíte ty výhody kolem systemd, kde díky jednotnému API je spousta věci usnadněna.

Rozdil je v tom, ze namisto aby doslo k nejake standardizaci na ktere by se dohodli stavajici projekty, implementovali ji, a ktera by byla konceptualne nezavisla na konkretni implementaci (priklad: _NET_WM hinty pro window managery, ktere vicemene kompatibilne implementuji nejruznejsi window manageri), tak tady k jednotnemu API doslo tim, ze se 'zakazaly' vsechny alternativy.

[Petr Tomášek]

Já bych to tak nepřeháněl, popravdě nechápu, že nevidíte ty výhody kolem systemd, kde díky jednotnému API je spousta věci usnadněna. Třeba jen tak, jaké existovalo do doby systemd API pro správu služeb v distru? V klikátku jsem si chtěl zaškrtnout, že nechci spouštět apache při bootu. Co mi na to mohli udělat programátoři od GNOME? Od KDE? Ahá, v Mandraku se používal nějaký drakconf-, v Debianu přes update-rc.d.... Popravdě doufám, že až přestanou kvůli tomu všichni vidět rudě, tak hlavně ty výhody přiznají a třeba ať si klidně tříští síly ve vývoj kompatibilní věci, která bude klidně v bashi.

Jenže právě když mi nevyhovovalo, jak to dělá Mandrake, tak jsem mohl přejít k Debianu. Teď budu mít smůlu. A to vůbec nemluvím o tom, že tahle tzv. „roztříštěnost“ linuxu fungovala jako dobrá obrana proti různým virům a rootkitům, anžto to každá distribuce měla jinak

Jo a to s těma programátorama GNOME a KDE jsem fakt nepochopil. IMHO by se oni do systémových věcí neměli vůbec srát a měl by se starat o ty svoje grafický potvory...

[Josef Kufner]

Tahle roztříštěnost má docela vysokou cenu v podobě nepřátelskosti vůči komerčním aplikacím, kde se tím znatelně prodražuje vývoj a komplikuje testování. V lepším případě si pak výrobce vybere jednu nebo dvě nejrozšířenější distribuce, v horším se na to vykašle úplně. Pokud většina distribucí poběží na Systemd, situace se pro ně značně zjednodušší a přinese to více peněz i příležitostí linuxové komunitě a opensource celkově.

[Hans1024]

Pokud temi "komercnimi aplikacemi" myslite proprietarni SW, tak ten necht si jeho vyvojari strci do zadnice.

[kavol]

tak nevím, zda to mám nazvat slušně falešným dilematem, anebo na plnou hubu totální píčovinou ...

[Heron]

+1

[Heron]

Ještě než dám kavolovu příspěvku +1, tak se zkusím zeptat, jak systemd "značně zjednoduší" komerční aplikace. Opravdu by mě zajímalo, jaký sled myšlenek může vést k takovému závěru.

[JS1]

Systemd ne, spis jeho adopce. Kdyby se byly byvaly Linuxove distribuce sjednotily pod jinym systemem, melo by to podobny efekt.

[Heron]

1) Nevidím souvislost mezi init systémem a komerčními aplikacemi (nebo i těmi open source). Ve spoustě návodů na různý software se vůbec neřeší jak danou službu restartovat pomocí libovolného z init systémů, ale naopak se vždy uvádí, jak se daná služba ovládá sama o sobě. apachectl, pg_ctl apod. To, že si to konkrétní admin v konkrétním případě přeloží na: /etc/init.d httpd, service httpd, systemctl httpd.service, je podružné a pro ten návod samotný nezajímavé.

2) Ten, kdo volá po sjednocení by si měl v první řadě uvědomit, proč došlo k tomu rozdělení. Jestli to náhodou není proto, že ono předchozí řešení někomu nevyhovovalo a proto to rozdělil.

[JS1]

ad 1. V podstate rikas, kazdy vyrobce si to musi resit po svem. Mozna by byli radeji, kdyby na to existovala nejaka dohodnuta infrastruktura? A mozna nechteji resit problemy spojene s tim, jak si to konkretni admin prelozil?

ad 2. Ja myslel, ze to rozdeleni je dane historicky. Proste probehla nejaka evoluce, vymyslela se ruzna reseni, no a ted se to konsoliduje (tak jako se to pred mnoha lety na Unixech zkonsolidovalo do Sys V initu). Co kdyz zadny z tech dvou procesu neni vyhodnejsi nez ten druhy, proste jen tak probiha vyvoj?

[kavol]

no, především kolik těch komerčních aplikací potřebuje interagovat s initsystémem? - můj VueScan určitě ne ... nějaký ten CAD pro Usámu, když pořád nemá free náhradu?

proto jsem mluvil o falešném dilematu, jestliže jsme stavěni před volby buď sjednotit initsystém anebo přijít o podporu - ve skutečnosti je ale další možnost, že na tom initsystému(*) prachnic nezáleží

(*) resp. i spoustě dalších věcí, které systemd integruje - dokud nezintegruje úplně celý systém včetně například libusb a knihoven pro X, což je to co VueScan využívá (ovšem nejsem si jist, jestli si značnou část netahá s sebou staticky slinkované ...)

[Bedňa]

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[=^..^= AmigaPower®]

Mně se to taky nelíbí a to vim o linuxu velmi málo, až smradlavý hovno, jak praví Velký teplý Al Kotyz... Je to přesně o tý modularitě i když bych to popsal malinko jinak, protože takhle by to šlo snadno vyvrátit Wehrmachtem u Stalingradu, kterej dojel na německou pověstnou inovaci a tim že každejch 14 dní modifikovali součástky, nakonec byly v piči díky nekompatibilitě náhradních dílů u jednoho typu výzbroje, díly z vraků nešly použít...

[Bedňa]

Jj si to trafil systemd nieje kompatibilné so žiadnym nástrojom ktoré používam. Čo ma fakt sere, že koľko ľudí začalo utekať od Linuxu. Pritom na to nieje dôvod, tak napr. v Ubuntu nebude skôr ako za dva roky a dovtedy sám umrie na svoje choroby.

[pavlix]

Uvidíme. Za dva roky si na mě vzpomeň, můj osobní odhad je, že systemd neumře a že se 90% těch utečenců do té doby k linuxu vrátí.

[Bedňa]

Za dva roky si na mě vzpomeň, můj osobní odhad je, že systemd neumře

Môže sa ale stať, že ostane len vo Fedore. Debian, Ubuntu, Gentoo... majú ešte stále dosť času na to aby prípadné výhody systemd aplikovali do dnešných riešení.

90% těch utečenců do té doby k linuxu vrátí

Na inom portáli som (nie sám) za pár mesiacov so začiatočníka spravil celkom slušného užívateľa Linuxu, mno a odchádza k BSD a mám pocit že už nečíta ani moje príspevky, tak uvidíme. Teda túto vlnu odlivu sledujem na viacerých portáloch.

Ja som roky spokojný užívateľ Linuxu a na niečo takéto si nespomínam.

[=^..^= AmigaPower®]

Abych pravdu řek, začínám nějak pokukovat po widlích, systém je intuitivní, stabilní, nemusel bych furt kvůli každý píčovině ležet v googlu, ve KDE už se pomalu přestávám orientovat nemluvě o ostatních desktopech, polovina věcí co šla před pěti, šesti, sedmi lety nastavit dneska nejde, jen ty jejich aktualizace... to je síla... brrrrr

[Bedňa]

Tak ja mám teraz v práci Win7 a ide to rovnakým trendom, stále menej možností si niečo nastaviť, aj rozloženie klávesnice blbne.

Už sosť dlhý čas mám na Linuxe IceWm, tak až by si chcel skúsiť napíšem ti skript aby si sa s tým nemusel jebkať a mohol odskúšať.

[,]

min chlastat

[=^..^= AmigaPower®]

Jo, asi bys měl míň chlastat a víc používat diakritiku...

[Grunt]

Přesně. Já si pamatuju jak se Linuxový systém hroutil přesně před rokem a dnem, když se podobně modularizoval GRUB při přechodu z GRUBu 1.0 (nebo 0.95 nebo kolik) na GRUB2. To bylo taky nářků jaký je to konec a když ne celého tak aspoň toho Linuxového světa a dnes? Kdo si vůbec na nějaký GRUB dneska vzpomene a je si vědom že tam nějaký GRUB má? Se systemd to bude podobné. Lidi ani nebudou vědět, že nějaký systemd tam někde v pozadí je.

[Bedňa]

GRUB2 hravo nahradíš čím len chceš, nesere sa do aplikácií a dokonca ani Gnome3 nemá na ňom závislosť (to je dúfam dostačujúci dôkaz).

[Grunt]

Ano přesně takhle to před rokem znělo. A před rokem a půl o PulseAudio a před tři-čtvrtě rokem o Waylandu… a pamatuju když ještě plně fungovalo OSS a končil přechod na ALSu jak se nadávalo jak teď budu Linux fongovat když už nebude přístup ke zvukovce skrze jeden soubor (tak jak je v UNIXu kde je všechno soubor tradicí). Akorát těch keců nebylo tolik.

[Bedňa]

Myslel som si že som dostatočne vysvetlil rozdiel medzi tým možnosť komponentu nahradiť, ale mýlil som sa.

A před rokem a půl o PulseAudio

Časom sa utriaslo dostalo do použiteľnej podoby a je zaujímavé že za posledný mesiac sa množia nadávky na PA. Fakt neviem čím je to spôsobné, možno hardcoded s systemd, ale aj mne začalo PA blbnúť, Prestalo si pamätať nastavenie hlasitosti aplikácií, master hlasitosť spadne z prednastavených 130% na 100% a už sa nevie cez master vrátiť späť. Občas z niektorej aplikácie nejde zvuk, hádže to chybové hlášky a podobne.

Ale stále sa dá nahradiť napr. OSS, čo pokladám na Linuxe stále za najlepší sound systém.

a před tři-čtvrtě rokem o Waylandu

Je to zas len alternatíva Xiek, takže sa dá použiť Xorg, alebo Mir.

[FrostyX]

Navíc u PA se sice hodně flejmovalo, ale nakonec, kdo ho nechtěl, prostě ho jedním příkazem kompletně odinstaloval, dál používal alsu a drtivá většina aplikací s tím neměla žádný problém.

[Bedňa]

Tak, tak, rovnako to bolo aj s nástupom ALSA, páč chlapi napísali niečo ako ALSA-legacy (to len triafam možno ALSA-OSS-Legacy) a zvuk z aplikácií pre OSS sa naďalej dal používať.

[Grunt]

Ok, co dál? KDE4, GNOME3… jestli chceš můžu ti napsat i nějaký list rakoviny a zkázy Linuxu jestli chceš.

[Bedňa]

KDE4 je fakt pomalá šmejďárna, ale dá sa nahradiť. Gnome3 osekalo užívateľovi možnosti, ale dá sa nahradiť.

[=^..^= AmigaPower®]

KDE je hnus, ale nahradit čim? LXDE je fajn, ale jak Grunt kterej ví všechno jistě nezapomene napsat, je to nedodělek... o dalších se nemá ani cenu bavit, sou nepoužitelný...

[Grunt]

Grunt který ví všechno používá MATE a pokukuje po GNOME Shellu (a píská si)… LXDE je hnus.

[Bedňa]

Dáme niekedy o tom reč, ja sa idem venovať svojmu koníčku

[=^..^= AmigaPower®]

Ty k tý flašce jednou přirosteš

[Bedňa]

A prídeme mi to užitočnejšie ako presviedčať niekoho že blbý nápad je blbý nápad

[FrostyX]

Já vím, že zkáz a rakovin linuxu už tu bylo nepočítaně. Každý půlrok nějaká. Spousta z nás je konzervativních a nelíbí se nám novinky, které nám narušují život . Proto se flejmovalo když přišlo PA, KDE4, Gnome3, Wayland a já nevím co ještě.

U systemd je jiné to, že na rozdíl od předchozích "rakovin" mění kde-co se vývojářům zachce. Předchozím "rakovinám" se dalo vyhnout, případně se jich velmi snadno zbavit. "Nelíbí se ti KDE4? Nainstaluj si libovolné z více než pěti dalších desktopových prostředí, nebo jeden desítek WM". Stejně tak jednu dobu koloval známý workaround na opravení nefunkčního zvuku - odinstalovat balík PA a reboot. Stejně tak šlo řešit všechno ostatní. Jenže systemd se tak snadno zbavit nedá, protože zasahuje do spousty systémových věcí.

Když řeknu, že nechci používat PA, dostanu odpověď "odinstaluj ho, všechno bude fungovat jako předtím". Když řeknu nechci používat systemd, dostanu obdobu některé z následujících odpovědí:

• Přejdi na jinou distribuci popř jiný OS
• Spravuj si vlastní init skripty
• Drž hubu a krok

To už tak jednoduché není.

[Grunt]

Jo a když už jsme u toho tak si také ještě vzpomínám na kecy o roztříštěnosti Linuxového světa a o jeho nejednotnosti. Heslem nového milénia je jednotnost nadevše ale keců ještě o dva pytle navíc… já už fakt ještě nevím coby a už to nenajdu ani v OBI.

[Rezza]

:D.

[Grunt]

Myslel som si že som dostatočne vysvetlil rozdiel medzi tým možnosť komponentu nahradiť

Nevysvětlil jen si málo pamatuješ. ALSA byla podobný nenahraditelný mor, PA zas myslím bylo všude se rozlézající rakovina. To je pořád nějaký intergalaktický mor nebo mimozemská bitevní loď na oběžné dráze nebo smrtící paprsek, který může zničit svobodný Linuxový svět, ale pokud mají uživatelé GNU/Linuxu žít šťastně, nesmí se to dozvědět!

Ale stále sa dá nahradiť napr. OSS

Donedávna byl OSS proprietární…to jen tak pro zajímavost.

[Bedňa]

Ale dá sa nahradiť, to je dôležité a ako som písal vyššie pre podporu OSS v ALSA bol napísaný aj plugin.

Inak OSS malo dvojité licencovanie. Nebudem zachádzať do podrobností aby ma niekto nezjebal že som napísal blbosť, ale bolo slobodné a potom komerčné pre drahé muzikantské HW vecičky.

[Grunt]

Systemd je proprietární sr*ka zabudovaná do proprietárního systému která se z něj nedá vypárat. Vzhledem k nedostupnosti zdrojových kódů a nemožnosti sestavit si vlastní systém s alternativním zavaděčem služeb není možnost jak mu uniknout. Je toto tvrzení pravdivé?

[Bedňa]

Nie, všade tvrdím, už sa na tu sračku teším.

[Grunt]

No to vidím…

[Bedňa]

Ako ju pošlem do hajzlu z každého distra ktoré mám rád,.

[Grunt]

To na konci měl být otazník?

[Bedňa]

Ee, bug :)

[AsciiWolf]

+1

[Gilhad]

No, zatím jsem se bez PA i Waylandu obesel dobře a GRUB 0.97 mi taky slouží k plné spokojenosti. Systemd jsem nenainstaloval a jediné problémy co mám jsou s udev a tam už jsem se naučil, které soubory rutinně mazat, aby to neprudilo tolik. A které parametry předat kernelu, abych měl pořád eth0 a ne nějaké píčoviny. Ale nevylučuju, že se jednoho dne konečně vzteknu a přejdu na nějakou alternativu.

[Petr Tomášek]

Popravdě řečeno, ten příspěvek, na který bedňa reaguje vnímám jako daleko sprostější (obsahově), než onu věta se slovem „kokot“.

[Bedňa]

[Petr Tomášek]

To nebyl vtip :-P

[Jack Hokus]

Zdravím,

Linux používám jako pracovní nástroj. Ne jako hračku. Ta doba, kdy jsem měl každou chvíli "rozinstalovanou" mašinu, protože jsem testoval nějaké distro.

Na mé nechuti k SystémuD není nic iracionálního ani staromileckého. Je dána spíš obavami z toho, aby se z Linuxu nestal jakýsi monolitycký systém složený z prvků, kterým krom jejich autora nikdo, nebo téměř nikdo nerozumí.

Ptáte li se, jaký problém chci vyřešit, pak tedy má odpověď zní "zachovat naučitelnost Linuxu".

Jedna z prvních knížek o Linuxu, kterou jsem četl byla od Stefanie Teufel, tuším Linux a KDE. Autorka tam definuje rozdíl mezi Linuxem a Windows slovy, že Windows jsou jako kuchyňský robot a Linux je sada dobrých nožů. Jenže dnes začíná Linux připomínat spíš toho robota. Ve vší úctě.

A to, že s FreeBSD není jednoduché, už jsem ho několikrát zkoušel a nedopadlo to dobře, proto jsem systém nehodil hned na železo a testuji ve virtuálním prostředí.

[Grunt]

Linux používám jako pracovní nástroj.

No a to je problém tak asi od roku 1992 nebo kdy. Ještě není dodělaný kompletní operační systém a nikdo neví jak se bude jmenovat, ale uživatelé už dávají dohromady instalace, firmy distribuce, ideologie-neideologie, licence-nelicence, flák to sem, flák to tam, nastavit si skipty hlavně ať to funguje a dá se z toho těžit. A bum. Žádné skripty, žádné etc, po dvaceti letech si nějaká firma rozhodne že si to chce udělat jinak a už je oheň na střeše.

[JS1]

Mne je to jedno, jestli v tom mas jasno - ja si jen myslim, ze nemas.

Ptáte li se, jaký problém chci vyřešit, pak tedy má odpověď zní "zachovat naučitelnost Linuxu".

Potiz je, ze pred timhle problemem stoji kazdy realne pouzitelny system (nejen operacni). Kazdy realne pouzitelny system bude mit spoustu vlastnosti, ktere jdou proti jeho jednoduchosti a "naucitelnosti". Protoze realny svet je komplikovany. A naopak, kazdy system, ktery se vedome rozhodne byt "naucitelny", bude muset nektere svoje moznosti vedome omezit, a zustat tak jen "hrackou".

U Linuxu v podstate tenhle proces (smerem k nizsi naucitelnosti a vyssi maturite) probiha neustale, od jeho zrodu. V tuhle chvili zasahl init, a proto se to tebe osobne dotklo, protoze to je zalezitost, kterou se zabyvas. Ale kdybys treba delal jadro, tenhle pocit bys mohl mit uz nekde u zrodu 2.6 nebo i driv.

Co se vyroku te Stefanie tyka, myslim, ze na Linuxu pracuje spousta chytrych lidi, a to mu umoznuje drzet si iluzi "sady dobrych nozu" dele nez u Windows. Proto se ten vyse uvedeny nevyhnutelny problem projevi o neco pozdeji.

Ale uvidime. Ja si myslim, ze pravdu ma Grunt, kdyz pise, ze za nejakou dobu se se systemd drtiva vetsina dnesnich odpurcu smiri. Coz jen potvrdi vyse uvedene.

[Ondrej 'SanTiago' Zajicek]

Kazdy realne pouzitelny system bude mit spoustu vlastnosti, ktere jdou proti jeho jednoduchosti a "naucitelnosti". Protoze realny svet je komplikovany. A naopak, kazdy system, ktery se vedome rozhodne byt "naucitelny", bude muset nektere svoje moznosti vedome omezit, a zustat tak jen "hrackou".

To jsou takove obecne reci, ktere jsou v obecnosti mozna pravda, ale je treba si uvedomit, o cem se bavime. Vzdyt tu jde o init, ne o kompilator ci software resici AI problemy z realneho sveta. Init je v zasade trivialni zalezitost, nebot prakticky veskerou komplexitu jiz davno osetril kernel nebo stavajici tooly. Navic je prirozene dekomponovan na oddelene podproblemy zpusobem, ktery uz je vyzkouseny.

Pri navrhu software je vzdy mozne resit komplexni problem tim, ze se navrhne jedno vseobjimajici nepruhledne reseni. Malokdy je to dobry tah z dlouhodobeho hlediska.

Co se tyce namitek proti systemd, tak strucne jen par bodu:

- prilis uzka vazba ci dokonce nedostatecna separace mezi koncepcne oddelitelnymi komponentami. Separace a volna vazba je dobra hned ze dvou duvodu. Zaprve prispiva transparentnosti a tim moznosti tvarit se jako 'sada dobrych nozu', zadruhe umoznuje evolucni vyvoj tim, ze jednotlive komponenty jsou nezavisle vymenitelne za produkty z jinych projektu. Na to prvni staci jasna separace, na to druhe se krom separace take hodi dostatecne volna vazba.

Tradicni init ma minimalne tri prirozene separovane komponenty, ktere byly do ruzne miry splacnute v systemd: 1. zakladni boot OS (distribucni skripty), 2. samotny manager demonu (init), 3. supervize a monitoring demonu (ruzne runit, daemontools a pod.). Tuto separaci je mozne (a IMHO i velmi uzitecne) zachovat.

- prilis uzka vazba na aktualni kernel. Zatimco samotny init ma velmi volnou vazbu na kernel a funguje vicemene nezavisle na moznych volbach v kernelu, takze bez jakychkoliv uprav v podstate prezil mnoho zmen, ktera se za ta leta v kernelu stala (napr. staticke nodes -> devfsd -> udev -> devtmpfs), systemd vyzaduje konkretni kombinaci kernelich voleb (napr. devtmpfs a cgroups), bez kterych nenabootuje, a da se cekat (protoze podobne to bylo s udevem maintainovanym stejnymi lidmi), ze nove verze systemd budou zaviset na novych featurach kernelu.

A to jsou zatim jen technicke argumenty, pak je tu nekolik nemene dulezitych politickych argumentu.

[JS1]

Pises zajimave veci, proto moje pozdni odpoved - premyslel jsem nad tim, i kdyz jsem nakonec nazor moc nezmenil.

To prvni je zajimavy argument. Daemontools (a runit) jsou urcite zajimavy pocin, jako vsechno od DJB. Musim rict, ze ja taky uplne nesouhlasim s "deklarativnosti" v systemd. Myslim, ze obecne deklarativni konfigurace jsou problem. Ale zda se, ze evolucne vitezi spis systemd ..coz je skutecne trochu zahada. Trochu mi cela ta diskuse pripomina "worse is better", ale tak nejak obracene.

Jinak si ale stale nemyslim, ze ta separace je az takove terno. Nekdo nekde musi rozhodnout, jak to bude cele fungovat. Tou separaci se to proste jen hazi na uzivatele/implementatora. Minimalne potrebujes nejaka dohodnuta API - a je uz celkem jedno, jestli prejdes na systemd nebo na runit, zmena to bude v kazdem pripade. Mozna by bylo opravdu nejlepsi, kdyby se preslo na runit nebo podobny system; jenze do toho se nikomu nechtelo (protoze to znamena zmenit API), a tak nakonec zvitezil systemd proste proto, ze mel nakonec nejvic ostatnich vyhodnych vlastnosti pro velke distribuce.

To druhe mi az tak nevadi. Ja myslim, ze eventualne muselo dojit k tomu, ze se i Linuxovy userspace bude vyvijet vlastnim smerem. Ja jsem proti interpretaci OS jen jako jadra, myslim, ze to je cely ekosystem.

Ze se systemd dostal do te role podle mne spis ukazuje na Lennartovu genialitu (v jistem smyslu, mozna je proste jen jednooky mezi slepymi) nez na nejakou politiku. Jak Rezza nedavno zminil, Lennartovy vynalezy desi vic RH management nez kohokoli jineho.

[Josef Kufner]

Myslim, ze obecne deklarativni konfigurace jsou problem.

Co je na deklarativní konfiguraci špatného?

[JS1]

Prijde mi, ze je nakonec vzdycky nejak omezujici, ze proste v extremnich pripadech nejakeho nasazeni je turingovska uplnost konfigurace dost uzitecna.

A to konfiguracni API musi byt navrzene dobre. To je casto obtizny pozadavek. Spatne navrzenou TU konfiguraci muzes dost casto obejit prave diky tomu obecnemu programovani. S nesikovne navrzenou deklarativni konfiguraci jsou jen problemy.

Dobry priklad takove situace je CSS.

Ale i TU konfigurace ma svoje negativa. V praxi jsou ale spis teoreticka, protoze ty potencialni vyhody deklarativnosti - napr. jakousi kontrolu toho, co se stane - je obtizne splnit; vetsinou je to prilis pracne.

[Josef Kufner]

Deklarativní konfigurace umožňuje vytvořit spolehlivý grafický editor a programově konfiguraci upravovat. U TU konfigurace narazíš s první nevhodnou ruční úpravou.

Docela pěkný přístup je použít generátor, vytvořit deklarativní konfiguraci a tu předhodit konfigurovanému programu. Ještě lepší je mít možnost vzít výstup programu místo konfiguračního souboru (či jeho části), například použít popen() namísto fopen(). Pak můžeš mít výhody obojího.

CSS není až tak úplně deklarativní, záleží totiž na pořadí jednotlivých pravidel. Je to tak napůl cesty.

[JS1]

Deklarativní konfigurace umožňuje vytvořit spolehlivý grafický editor a programově konfiguraci upravovat. U TU konfigurace narazíš s první nevhodnou ruční úpravou.

To je pravda, ale s tim generovanim (coz je typicka Javovska obsese) je to jeste horsi - tam to rucne nezmenis. Proto jsem spis zastance pouziti makrojazyka, kdyz uz musis neco generovat.

Pritom tenhle problem lze snadno obejit - definovat ne-TU podmnozinu, kterou ten editor zvlada. A ty casti, ktere nejsou napsane v te podmnozine, by ten editor mel radeji ignorovat.

[kralyk z abclinuxu]

Prijde mi, ze je nakonec vzdycky nejak omezujici, ze proste v extremnich pripadech nejakeho nasazeni je turingovska uplnost konfigurace dost uzitecna.

Kdyby se TU konfigurace používala skutečně jen pro ty tebou zmíněné extrémní případy, nebyl by problém, to se ale v případě tradičního initu nestalo.

Zajímavé je imho v tomhle ohledu porovnat init skripty např. s pkgbuildy v Archu. Pkgbuildy si udržely relativně velkou deklarativnost, init skripty byly už od začátku zdivočelý... Důvody jsou imho ty, že po pkgbuildech se požadovala automatizace zpracování (pro sestavovací stroje a zpracování v AURu) a vysoká uživatelská přivětivost (pkgbuild napíše skoro kdokoli). U init skriptů ani jeden z těchhle požadavků nebyl.

Takže TU konfigurace může být, ale pod podmínkou, že dokážeš zajistit, aby se pokud možno vždy použil deklarativní zápis a imperativní/programovací pouze tam, kde to je skutečně potřeba. Jinak to půjde do kytek.

[JS1]

Takže TU konfigurace může být, ale pod podmínkou, že dokážeš zajistit, aby se pokud možno vždy použil deklarativní zápis a imperativní/programovací pouze tam, kde to je skutečně potřeba. Jinak to půjde do kytek.

To se podle me zajisti tim, ze das k dispozici dostatek primitiv (a dalsich prvku, ktere mohou byt klidne i makry nad temi primitivami v tom TU jazyce).

Coz v pripade initu myslim mohlo nastat, kdyby se napriklad ujal prave ten daemontools pristup. Ale holt ta situace byla takova, ze se nikomu do zadne zmeny nechtelo - a to ukazuje i povyk kolem systemd.

[biolog]

+1 za "Linux pouzivaji na jinou praci a zda je komponentni je jim sumak" a hraní si.

Většina lidí (i já) si systém nechtějí konfigurovat, chtějí aby fungoval sám a rovnou a sám se nerozbil. Když už něco konfigurují, očekávají že důsledky voleb budou zřejmé, atd. A zdá se mi, že systemd to bude splňovat lépe, než alternativy.

[kavol]

... očekávají že důsledky voleb budou zřejmé, atd. A zdá se mi, že systemd to bude splňovat lépe, než alternativy.

ROFL

[TM]

Váš příspěvek je dán hlubokou neznalostí toho o čem píšete. Ale OK, podle nicku se asi zabýváte něčím jiným o čem vím prd zase já.
Když však vidím "moudra" od některých lidí, které bych mohl považovat za kolegy, nemůžu se zbavit dojmu, že se definitivně zbláznili

[biolog]

Můžete upřesnit tu neznalost? Takhle jste jen řekl, že je to jinak, aniž byste řekl, jak to je.

[Bubak]

Hm, a nedivil by ses, ze by na ty tvoje "trosku" pozmenene sachy brblali? Mohli by zahodit desitky let zname postupy, vsechno, co se naucili by prestalo byt jiste, ze funguje - tedy spis by bylo jistejsi, ze to fungovat nebude, protoze tam vstupuje novy prvek, o kterem nikdo nevi, kde vsude se projevi...

[Jardík]

Adobe Readeru, Flash playeru a Skypu

Na co? K Adobe Readeru existují slušné alternativy. Platformě závislý web vyžadující Flash player nestojí za návštěvu a Skype je stejně špehovací šmejďárna.

[ewew]

Odporúčam ti aby si vytvoril podobnú službu, ktorá bude splňovať tvoje požiadavky. Ale nepusti ju na zlom internete.Vytvor rovno vlastnú infraštruktúru s vlastným zakázkovým hw vlastnoručne vyrobenom.

[kralyk z abclinuxu]

Z boycottsystemd.org:

Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it.

Zajímalo by mě, co teda považují za ten správný init (To nemá ironická poznámka, opravdu by mě to zajímalo...).

The OpenBSD Foundation is currently developing OS-agnostic, BSD-licensed replacements, which will likely prove the most viable.

To vypadá docela dobře.

[pavlix]

Dále se hodně mluví o "prázdném /etc/". Tenhle přístup se zdá opravdu zcestný. Třeba takové xorg už nějakou dobu fungují bez konfiguračního souboru. Nicméně pokud potřebujete nějaké speciální nastavení, třeba k instalaci ovladačů grafické karty, tak stejně musíte ten xorg konf vygenerovat. Na Rootu jsem našel tento článek Co se systemd… a Linuxem a nezbývá mi nnež s autorem souhlasit.

Osobně zatím po možnosti provozovat systém s prázdným /etc nijak zvlášť netoužím, na druhou stranu bych ale rád porozuměl tvému argumentu. Osobně nemám momentálně potřebu konfigurovat Xorg jinak než za běhu (pomocí xrandr, xinput apod). Navíc podpora běhu s prázdným /etc ti nijak nebrání používat tvůj systém s dokonale vyladěným obsahem tohoto adresáře.

První z nich navrhuje použít nějakou distribuci s dlouhodobou podporou a počkat až se to celé nějak usadí, nebo přežene.

Zastánci druhého proudu navrhují přechod na některou verzi systému BSD.

Třetí a poslední možnost je asi nejradikálnější, jedná se o tvorbu vlastních startovacích skriptů.

Nezapomněl jsi na možnost použití systemd se všemi jeho plusy a mínusy? Na možnost upravovat systém se systemd směrem k (relativní) spokojenosti? K používání systemd, dokud se neobjeví a nevyladí nějaký nový projekt (jako třeba ten již zmíněný)? Podle mě tyto patří mezi validní řešení stejně jako tři výše uvedená.

[jadd]

Možná se nedivím, těm co ho kritizují na debianu/ubuntu, protože je to něco jiného než na fedoře. Není tam žádné systemctl a nějaké dh_xxxxxx

[cew]

Nevím jak jinde, ale v Arch Linuxu je systemctl...

[pavlix]

Já se nedivím kritice v souvislosti s libovolnou distribucí. Musím přiznat, že si nejsem vědom žádných specifik v Debianu, ale zásadním rysem systemd je pokud vím důraz na upstream a unifikaci mezi distribucemi, takže bych se divil, kdyby se tento trend nedotkl i Debianu.

[jadd]

jadd@Livuntu:~$ man -k systemd
deb-systemd-helper (1p) - subset of systemctl for machines not running systemd
deb-systemd-invoke (1p) - wrapper around systemctl, respecting policy-rc.d
dh_systemd_enable (1p) - enable/disable systemd unit files
dh_systemd_start (1p) - start/stop/restart systemd unit files
loginctl (1)         - Control the systemd login manager
pam_systemd (8)      - Register user sessions in the systemd login manager
systemd-hostnamed (8) - Hostname bus mechanism
systemd-hostnamed.service (8) - Hostname bus mechanism
systemd-localed (8)  - Locale bus mechanism
systemd-localed.service (8) - Locale bus mechanism
systemd-logind (8)   - Login manager
systemd-logind.service (8) - Login manager
systemd-timedated (8) - Time and date bus mechanism
systemd-timedated.service (8) - Time and date bus mechanism
systemd-udevd (8)    - Device event managing daemon
systemd-udevd-control.socket (8) - Device event managing daemon
systemd-udevd-kernel.socket (8) - Device event managing daemon
systemd-udevd.service (8) - Device event managing daemon

Ubuntu 14.04 Gnome 3.10 systemd kompletní.

[cew]

Arch Linux, man -k systemd:

init (1)             - systemd system and service manager
journalctl (1)       - Query the systemd journal
loginctl (1)         - Control the systemd login manager
lvm2-activation-generator (8) - generator for systemd units to activate LVM2 volumes on boot
machinectl (1)       - Control the systemd machine manager
netctl.special (7)   - Special netctl systemd units
pam_systemd (8)      - Register user sessions in the systemd login manager
sd_booted (3)        - Test whether the system is running the systemd init system
systemctl (1)        - Control the systemd system and service manager
systemd (1)          - systemd system and service manager
systemd-activate (8) - Test socket activation of daemons
systemd-analyze (1)  - Analyze system boot-up performance
systemd-ask-password (1) - Query the user for a system password
systemd-ask-password-console.path (8) - Query the user for system passwords on the console and via wall
systemd-ask-password-console.service (8) - Query the user for system passwords on the console and via wall
systemd-ask-password-wall.path (8) - Query the user for system passwords on the console and via wall
systemd-ask-password-wall.service (8) - Query the user for system passwords on the console and via wall
systemd-backlight (8) - Load and save the display backlight brightness at boot and shutdown
systemd-backlight@.service (8) - Load and save the display backlight brightness at boot and shutdown
systemd-binfmt (8)   - Configure additional binary formats for executables at boot
systemd-binfmt.service (8) - Configure additional binary formats for executables at boot
systemd-bootchart (1) - Boot performance graphing tool
systemd-cat (1)      - Connect a pipeline or program's output with the journal
systemd-cgls (1)     - Recursively show control group contents
systemd-cgtop (1)    - Show top control groups by their resource usage
systemd-cryptsetup (8) - Full disk decryption logic
systemd-cryptsetup-generator (8) - Unit generator for /etc/crypttab
systemd-cryptsetup@.service (8) - Full disk decryption logic
systemd-debug-generator (8) - Generator for enabling a runtime debug shell and masking specific units at boot
systemd-delta (1)    - Find overridden configuration files
systemd-detect-virt (1) - Detect execution in a virtualized environment
systemd-efi-boot-generator (8) - Generator for automatically mounting the EFI System Partition used by the current boot to /boot
systemd-fsck (8)     - File system checker logic
systemd-fsck-root.service (8) - File system checker logic
systemd-fsck@.service (8) - File system checker logic
systemd-fstab-generator (8) - Unit generator for /etc/fstab
systemd-getty-generator (8) - Generator for enabling getty instances on the console
systemd-gpt-auto-generator (8) - Generator for automatically discovering and mounting root, /home and /srv partitions, as well as discovering and enabling swap partitions, based on GPT partition type GUIDs.
systemd-halt.service (8) - System shutdown logic
systemd-hibernate.service (8) - System sleep state logic
systemd-hostnamed (8) - Host name bus mechanism
systemd-hostnamed.service (8) - Host name bus mechanism
systemd-hybrid-sleep.service (8) - System sleep state logic
systemd-inhibit (1)  - Execute a program with an inhibition lock taken
systemd-initctl (8)  - /dev/initctl compatibility
systemd-initctl.service (8) - /dev/initctl compatibility
systemd-initctl.socket (8) - /dev/initctl compatibility
systemd-journal-gatewayd (8) - HTTP server for journal events
systemd-journal-gatewayd.service (8) - HTTP server for journal events
systemd-journal-gatewayd.socket (8) - HTTP server for journal events
systemd-journal-remote (8) - Stream journal messages over the network
systemd-journald (8) - Journal service
systemd-journald-dev-log.socket (8) - Journal service
systemd-journald.service (8) - Journal service
systemd-journald.socket (8) - Journal service
systemd-kexec.service (8) - System shutdown logic
systemd-localed (8)  - Locale bus mechanism
systemd-localed.service (8) - Locale bus mechanism
systemd-logind (8)   - Login manager
systemd-logind.service (8) - Login manager
systemd-machine-id-setup (1) - Initialize the machine ID in /etc/machine-id
systemd-machined (8) - Virtual machine and container registration manager
systemd-machined.service (8) - Virtual machine and container registration manager
systemd-modules-load (8) - Configure kernel modules to load at boot
systemd-modules-load.service (8) - Configure kernel modules to load at boot
systemd-networkd (8) - Network manager
systemd-networkd-wait-online (8) - Wait for network to come online
systemd-networkd-wait-online.service (8) - Wait for network to come online
systemd-networkd.service (8) - Network manager
systemd-notify (1)   - Notify service manager about start-up completion and other daemon status changes
systemd-nspawn (1)   - Spawn a namespace container for debugging, testing and building
systemd-path (1)     - List and query system and user paths
systemd-poweroff.service (8) - System shutdown logic
systemd-quotacheck (8) - File system quota checker logic
systemd-quotacheck.service (8) - File system quota checker logic
systemd-random-seed (8) - Load and save the system random seed at boot and shutdown
systemd-random-seed.service (8) - Load and save the system random seed at boot and shutdown
systemd-readahead (8) - Disk read ahead logic
systemd-readahead-collect.service (8) - Disk read ahead logic
systemd-readahead-done.service (8) - Disk read ahead logic
systemd-readahead-done.timer (8) - Disk read ahead logic
systemd-readahead-replay.service (8) - Disk read ahead logic
systemd-reboot.service (8) - System shutdown logic
systemd-remount-fs (8) - Remount root and kernel file systems
systemd-remount-fs.service (8) - Remount root and kernel file systems
systemd-resolved (8) - Network Name Resolution manager
systemd-resolved.service (8) - Network Name Resolution manager
systemd-rfkill (8)   - Load and save the RF kill switch state at boot and shutdown
systemd-rfkill@.service (8) - Load and save the RF kill switch state at boot and shutdown
systemd-run (1)      - Run programs in transient scope or service units
systemd-shutdown (8) - System shutdown logic
systemd-shutdownd (8) - Scheduled shutdown service
systemd-shutdownd.service (8) - Scheduled shutdown service
systemd-shutdownd.socket (8) - Scheduled shutdown service
systemd-sleep (8)    - System sleep state logic
systemd-sleep.conf (5) - Suspend and hibernation configuration file
systemd-socket-proxyd (8) - Bidirectionally proxy local sockets to another (possibly remote) socket.
systemd-suspend.service (8) - System sleep state logic
systemd-sysctl (8)   - Configure kernel parameters at boot
systemd-sysctl.service (8) - Configure kernel parameters at boot
systemd-system-update-generator (8) - Generator for redirecting boot to offline update mode
systemd-system.conf (5) - System and session service manager configuration file
systemd-sysusers (8) - Allocate system users and groups
systemd-sysusers.service (8) - Allocate system users and groups
systemd-timedated (8) - Time and date bus mechanism
systemd-timedated.service (8) - Time and date bus mechanism
systemd-timesyncd (8) - Network Time Synchronization
systemd-timesyncd.service (8) - Network Time Synchronization
systemd-tmpfiles (8) - Creates, deletes and cleans up volatile and temporary files and directories
systemd-tmpfiles-clean.service (8) - Creates, deletes and cleans up volatile and temporary files and directories
systemd-tmpfiles-clean.timer (8) - Creates, deletes and cleans up volatile and temporary files and directories
systemd-tmpfiles-setup-dev.service (8) - Creates, deletes and cleans up volatile and temporary files and directories
systemd-tmpfiles-setup.service (8) - Creates, deletes and cleans up volatile and temporary files and directories
systemd-tty-ask-password-agent (1) - List or process pending systemd password requests
systemd-udevd (8)    - Device event managing daemon
systemd-udevd-control.socket (8) - Device event managing daemon
systemd-udevd-kernel.socket (8) - Device event managing daemon
systemd-udevd.service (8) - Device event managing daemon
systemd-update-done (8) - Mark /etc and /var fully updated
systemd-update-done.service (8) - Mark /etc and /var fully updated
systemd-update-utmp (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp-runlevel.service (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp.service (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-user-sessions (8) - Permit user logins after boot, prohibit user logins at shutdown
systemd-user-sessions.service (8) - Permit user logins after boot, prohibit user logins at shutdown
systemd-user.conf (5) - System and session service manager configuration file
systemd-vconsole-setup (8) - Configure the virtual console at boot
systemd-vconsole-setup.service (8) - Configure the virtual console at boot
systemd.automount (5) - Automount unit configuration
systemd.device (5)   - Device unit configuration
systemd.directives (7) - Index of configuration directives
systemd.exec (5)     - Execution environment configuration
systemd.index (7)    - List all manpages from the systemd project
systemd.journal-fields (7) - Special journal fields
systemd.kill (5)     - Process killing procedure configuration
systemd.link (5)     - Network device configuration
systemd.mount (5)    - Mount unit configuration
systemd.netdev (5)   - Virtual Network Device configuration
systemd.network (5)  - Network configuration
systemd.path (5)     - Path unit configuration
systemd.preset (5)   - Service enablement presets
systemd.resource-control (5) - Resource control unit settings
systemd.scope (5)    - Scope unit configuration
systemd.service (5)  - Service unit configuration
systemd.slice (5)    - Slice unit configuration
systemd.snapshot (5) - Snapshot unit configuration
systemd.socket (5)   - Socket unit configuration
systemd.special (7)  - Special systemd units
systemd.swap (5)     - Swap unit configuration
systemd.target (5)   - Target unit configuration
systemd.time (7)     - Time and date specifications
systemd.timer (5)    - Timer unit configuration
systemd.unit (5)     - Unit configuration

[jadd]

Aha tak je to jinak, to gnome nepoužívá systemd ale taky upstart. https://wiki.ubuntu.com/systemd#systemd_-_An_alternative_boot_manager

[kavol]

Dále se hodně mluví o "prázdném /etc/". Tenhle přístup se zdá opravdu zcestný. Třeba takové xorg už nějakou dobu fungují bez konfiguračního souboru. Nicméně pokud potřebujete nějaké speciální nastavení, třeba k instalaci ovladačů grafické karty, tak stejně musíte ten xorg konf vygenerovat. Na Rootu jsem našel tento článek Co se systemd… a Linuxem a nezbývá mi nnež s autorem souhlasit.

Osobně zatím po možnosti provozovat systém s prázdným /etc nijak zvlášť netoužím, na druhou stranu bych ale rád porozuměl tvému argumentu.

no, "ten argument" by mě také zajímal, za sebe si tipnu, že třeba obava, že časem si software vůbec nemusí poradit s nějakou možností konfigurace, budoucí schopnost/ochota vůbec nějaké /etc řešit?

jinak mně to přijde jako šaškárna - prostě se konfiguráky přesunuly z /etc do /usr/... - no, to je teda výhra ... :-/

z jednoho hlediska je to jen kosmetika, ať říkáme hovno nebo lejno, furt to smrdí stejně

na druhou stranu v tom vidím zase další znepřehlednění administrace -

pokud mám default v /usr/... a místní nastavení v /etc, tak oproti verzi vše v /etc například budu mít problém při upgradu, když jsem si v konfiguráku udělal nějaké změny, a tyto třeba nejsou s novým defaultem kompatibilní, tak se o tom nedozvím, neboť se jen potichu změní kdesi cosi v tom /usr/..., namísto aby na mě vyběhla hláška, že se mám podívat do .rpmnew a mergnout změny

[pavlix]

no, "ten argument" by mě také zajímal, za sebe si tipnu, že třeba obava, že časem si software vůbec nemusí poradit s nějakou možností konfigurace, budoucí schopnost/ochota vůbec nějaké /etc řešit?

To musí být vtip.

jinak mně to přijde jako šaškárna - prostě se konfiguráky přesunuly z /etc do /usr/... - no, to je teda výhra ... :-/

Ať už si o tom myslíme cokoliv, myšlenka, že výchozí konfigurace a instalované skripty budou v /usr je přinejmenším konzistentní a u software, který je takto řešen to udává hranici mezi instalovanými defaulty a uživatelskou konfigurací.

[kavol]

no, "ten argument" by mě také zajímal, za sebe si tipnu, že třeba obava, že časem si software vůbec nemusí poradit s nějakou možností konfigurace, budoucí schopnost/ochota vůbec nějaké /etc řešit?

To musí být vtip.

tak nevím, jestli se chci zeptat "proč" anebo raději "co"?

Ať už si o tom myslíme cokoliv, myšlenka, že výchozí konfigurace a instalované skripty budou v /usr je přinejmenším konzistentní

otázka úhlu pohledu; konzistentní s čím, s dalším takovým software?

a u software, který je takto řešen to udává hranici mezi instalovanými defaulty a uživatelskou konfigurací.

s doposavadním stanovením této hranice jsem neměl problém ... což samozřejmě neznamená, že problém neexistuje, ale pak by mě zajímalo, jestli to není jenom "problém"

[Jendа]

Nestartuje xorg, takze nejde pouzit runtime, a chci ho nastartovat s vesa driverem.

[Petr Tomášek]

Osobně nemám momentálně potřebu konfigurovat Xorg jinak než za běhu (pomocí xrandr, xinput apod).

Řekl bych, že se to dramaticky změní ve chvíli, když např. budeš chtít nakonfigurovat X server jako multiseat tak, aby každý monitor měl pevně přiřaznou klávesnici/myš a uživatel to nemohl rozesrat, atd.

První z nich navrhuje použít nějakou distribuci s dlouhodobou podporou a počkat až se to celé nějak usadí, nebo přežene.

Zastánci druhého proudu navrhují přechod na některou verzi systému BSD.

Třetí a poslední možnost je asi nejradikálnější, jedná se o tvorbu vlastních startovacích skriptů.

Nezapomněl jsi na možnost použití systemd se všemi jeho plusy a mínusy? Na možnost upravovat systém se systemd směrem k (relativní) spokojenosti? K používání systemd, dokud se neobjeví a nevyladí nějaký nový projekt (jako třeba ten již zmíněný)? Podle mě tyto patří mezi validní řešení stejně jako tři výše uvedená.

Ta tvoje poslední možnost má tu nevýhodu, že se člověk stává spolupachatelem zločinu proti genetické rozmanitosti linuxu.

[pampam]

FreeBSD je na server, nema tak odladeny a podporovany desktop jako linux. Raci se nauc SystemD, nez resit dependency hell v desktop verzi FreeBSD. Fedoru 20 (s KDE) povedena a pokud nebudes vedet, co roupama delat, muzes prejit na rawhide.

[pampam]

*Fedora 20 (s KDE) je povedena...

[----]

kravina, moderní HW je podporovaný dobře, pkgng je kvalitní balíčkovací systém, žádný problém.

běží mi desktopové freebsd na i7-4770, H97, gtx 760, vč. grafiky, tiskárny, skeneru, webkamery, optickýho výstupu zvukovky, a vpodstatě všeho ostatního.

[martin]

pkgng je kvalitní balíčkovací systém

http://www.reddit.com/r/BSD/comments/2ap7nr/how_the_nsa_is_destroying_foss_unix_xposted_to/

:)

[----]

už jsem chtěl napsat tl;dr, ale pak jsem si to nakonec přecejen přečetl a většina těch věcí, co tam uvádí, nejsou pravda (a jde to vidět i na upvotes/downvotes)

[martin]

souhlas, me to pobavilo z jineho duvodu

[pampam]

Nebavim se o hw, ale kdyz jsi to nakousl - jak ti funguje suspend, jede out of box?

Bavim se o nedostatecne testovanem sw. Hodne vetsich baliku se testuje stylem kompilace probehla. Novym portum trva i pres 3 tydny, nez jsou z nich binarky. Configy jsou nastaveny na minimal. A nejhorsi je, ze nektery sw nebyl ani spusten a je automaticky zarazen do stable.

Poudriere nerad pouzivam, protoze nemam SSD nebo dostatecne velky ram disk na vlastni rebuild a jsem vdecny za veci typu Copr.

FreeBSD mam rad, pkgng se povedlo (a v10 taky), ale Fedora je porad o krok napred aspon co se desktopu tyce.

[----]

suspend jsem zkusil jen jednou a fungovalo to. Na desktopu obvykle suspend nepoužívám.

S tím SW jsem na nic takového nenarazil. Všechno je testováno a rozbité porty se správně označí. Třeba Chromium je momentálně označeno jako Forbidden kvůli bezpečnostním chybám.

[pampam]

Netrvalo to ani mesic a mame tu hned dva krasne priklady chyb globalniho charakteru http://svnweb.freebsd.org/ports/head/UPDATING?view=markup&pathrev=367735

[Grunt]

Upřímně řečeno (a klidně mi příspěvek zcenzurujte)?: Běž s tím už do prdele.

To zas bude flame tak o min. o 400 příspěvcích bez nějakého validního řešení, který stejně nebudu číst. Pokud se ti nelíbí, odpoveď máš v levém sloupci(a bylo to naznačeno i v článku). Postav si svoji svobodnou distribuci se svobodným init systémem. Já jsem s Lennartwarem spokojený a až nebudu, tak je tu několik alternativ, které si můžu postavit sám.

[pavlix]

To zas bude flame tak o min. o 400 příspěvcích bez nějakého validního řešení, který stejně nebudu číst.

Tak v čem je problém?

[Grunt]

Že zbytečně zabíjíte čas a já znám výsledek (poněvadž vím úplně všechno). Stačí se zeptat a může být o 300 zbytečných příspěvků míň.

[=^..^= AmigaPower®]

Vyzkoušíme...

Kolik bradavek má PL*ATINIUM Equilibrium?

[Grunt]

3

[=^..^= AmigaPower®]

Špatně

[Grunt]

Lžeš.

[=^..^= AmigaPower®]

Porušuješ copyright!

[Grunt]

To je copyleft vole. To si nemůžeš copyrightovat nebo tě FSF s PT zažalujou.

[=^..^= AmigaPower®]

PT tě zažaluje...

...rači hádej bradavky šmudlo

[Grunt]

A jednu díru do prdele…

[kavol]

Já jsem s Lennartwarem spokojený a až nebudu, tak je tu několik alternativ, které si můžu postavit sám.

ty umíš cestovat časem?

[Grunt]

Jasně. Vždyť já umím všechno. A taky krom toho umím ještě číst zprávičky.

[kavol]

hm, zato po sobě číst neumíš

to, že tu je něco teď, je tak jaksi nevypovídající o tom, co tu bude, až nebudeš spokojený s lennartware

[Grunt]

Zatím jsem v klidu. GNU a Stallman tu budou na věky…

[----]

no a? je to tvůj čas? tak s tím jdi do prdele sám.

[frdrx]

Radím radovat se z výhod systemd a vyprdnout se na pseudoproblémy.

[Heron]

A máte už také svůj časopis? Něco jako "Strážná věž"?

[=^..^= AmigaPower®]

ROFL!

[frdrx]

Časopis netřeba. Všechno je v gitu.

[Grunt]

Když ti odpovím, slíbíš mi že se nebudeš smát?

_{Jen si nejsem jistý jestli je to náráka na to na co si myslím, že je…}

[----]

takže jo?

[R]

To bude asi nieco tvrdsie ako casopis. A bud sa to fetuje alebo picha.

[kralyk z abclinuxu]

A máte už také svůj časopis? Něco jako "Strážná věž"?

_{(Možná se v některých věcech ohledně initu neshodnem, ale tenhle byl dobrej...)}

[Ondrej]

to proste musi bejt:

V kostele pod sochou Krista,
mrtvý pavouk křižák leží,
umlátil ho Jehovista,
srolovanou Strážní věží.

[Seraph]

Osobně, o systemd se více nezajímám a linux beru pouze jako pracovní nástroj. Není na něm bohužel, co k obdivování. Přesto jsem ale zaznamenal zajímavou věc. Systemd si ... začíná definovat vlastní filozofii kterou se sere do filozofie unixu/linuxu. A to je podle mne špatně. Ale jak už jsem řekl, je mi to více méně jedno. Linux už z čisté unixové cesty stejně sešel.

[frdrx]

Patrně to nebyla není nejlepší cesta.

[kralyk z abclinuxu]

Přesto jsem ale zaznamenal zajímavou věc. Systemd si ... začíná definovat vlastní filozofii kterou se sere do filozofie unixu/linuxu.

Imho bude dříve či později nevyhnutelně zUNIXován, minimálně do určité míry.

Linux už z čisté unixové cesty stejně sešel.

Opatrně, říct "microkernel" na některých místech na internetu může být jako říct "Slavie!" v některých hospodách...

[PavelC]

Jj, taky me to stve a *BSD beru jako zadni vratka. Dlouho uz jedu na Slackware a zatim nic nenaznacuje na revoluci v initu a sprave systemu.

Na neprijimani systemd nevidim nic iracionalniho. Naopak jako ciste emotivni povazuju nazory, ze zmena initu byla obecne nutna a vyzadovana. Beru ze pro urcite nasazeni se muze hodit, ale podobne muzou dostatecne poslouzit treba s6, runit, perp nebo daemontools. Ale jinde se da bez problemu porad pouzivat sysv-init. Kdyby byl systemd jako vyse jmenovane volitelny a nevytvarely se na nem zavislosti ktere pred tim neexistovaly (zurnal, sprava zarizeni, login, gnome, linux, ...), nikdo by imho nerekl ani popel. Zavislost znamena ztratu volby nebo hodne zkomplikovanou. Ale ta zjevna tendence pohltit vsechno na urovni systemu je jasna a je otazka casu kdy pribudou trvde zavislosti i pro dalsi komponenty (site, sprava napajeni, tisk, planovac uloh apod).
Jen pro ilustraci, baliky ktere aktualne zavisi na systemd v Archu. Velka cast jich jde rucne sestavit i bez systemd, ale jako ukazka trendu integrace to je nazorne.

Nestahoval bych kalhoty, kdyz brod je jeste daleko. Porad tu je Slack nebo source-based distribuce jako Gentoo, se kterymi bude doufam jeste hodne dlouho mozne pouzivat upstream od pricetnych vyvojaru. RH Gnome se odepsalo uz davno.

[Jiří Rožnovský]

+1

[Creckx]

Na rozdíl od většiny z vás jsem systemd začal používat co přilezl do Arch Linuxu a neměl jsem čas o něm diskutovat na internetu. V Archu nebylo na výběr. S jeho příchodem se zrychlil boot systému, zjednodušila se správa služeb nebo i nastavení locale. Reálný dopad na systém je třeba dobře vidět u Raspberry Pi, kde není výkonu na rozdávání a kde systemd připraví systém během pár sekund, zatímco initd skripty se chroustají desítky sekund. Ono to chvilku trvá, než se provede půl mega BASH omáčky.

To vám init skript opravdu nepřipadá jako hnus? Opravdu se musí třeba Apache startovat téměř 8kB skriptem? Nebo co se děje v těch 3 kB init skriptu pro cron? Nic! Jen se spustí crond. Systemd se možná stará o víc než by měl, ale jsou to věci, které nemusíte používat. Nemusíte používat journald ani networkd, dokonce ani fstab vám to nenahradí dokud na to nepřipravíte partišny na disku a ani pak to fstab nepřestane ignorovat.

Systemd nechcípne, to spíš ten iracionální odpor těch, kterým teď brnká na konzervativní strunu. Naopak se rozšíří, spoustu věcí zjednoduší a hlavně sjednotí. Service pro Fedoru bude úplně stejný jako pro Debian nebo Arch Linux a přidají se další distribuce. A ty co se nepřidají budou mrhat drahocenným časem nejen na odstranění závislostí, ale i na věci, které systemd řeší. Užijte si ten boj

[kralyk z abclinuxu]

+1

Teda krom toho journald, nejsem si jist, jestli se skutečně dá používat systemd bez něj.

[Heron]

iracionální odpor

a hlavně sjednotí

Správně, stejně tak je potřeba sjednotit motory a pneumatiky na automobilech, protože je hrozně iracionální na traktor dávat jinou gumu než na formuli. Přece auto jako auto, no ne?

Ten, kdo volá po sjednocení by si měl uvědomit, proč se ty věci kdysi rozdělily. Rozdělily se proto, že někomu se ta stávající věc nehodila na jeho nové podmínky provozu. TOP 500 superpočítač je něco jiného než pracovní stanice, ta je něco jiného než chytrý mobil. Mezi jednotlivými provozy strojů ze stejné kategorie jsou také propastné rozdíly.

Tohle nejde sjednotit. Ne za cenu těžkých kompromisů.

[Creckx]

Jak je možné vést nějakou rozumnou diskusi, když si vybereš z tříodstavcové reakce 5 slov a přes ně se snažíš napadnout celý text? Používáš silná přirovnání, která ale visí ve vzduchu a tak nezbývá než se zeptat, proč je systemd špatné pro mobily nebo pracovní stanice? Proč by superpočítač v TOP 500 nemohl používat systemd? Zabije mu to výkon a už nebude v TOP 500? Já třeba nevidím žádný zásadní rozdíl mezi distribucemi jako je Fedora, Debian, Ubuntu, CentOS. Ty rozdíly, které popisuješ, to jejich zaměření, se vůbec netýká systemd, ale způsobu, jak je řešená podpora, jak jsou zkompilované balíčky nebo pro jaké to je platformy.

[Heron]

Proč by superpočítač v TOP 500 nemohl používat systemd?

To je taky fakt. Každý správný superpočítač nutně potřebuje řešit věci jako je backlight settings. Bez toho nemůže žádný správný TOP500 fungovat. Dále je opravdu "vhodné" mít na každém uzlu v síti vlastní dhcp server. To stabilitě sítě výborně pomůže.

Problém vidím v tom, že tzv příznivci systemd velmi často argumentují tím, jak úžasný je to init systém. Což pro některé účely může být pravda.

Tzv. odpůrci ne moc často napadají ten init systém, ti většinou argumentují tím, jak rozlezlý ten systém je a jak zasahuje do všech částí OS bez možností výměny jednotlivých komponent (aneb klasická otázka jak odstraním journal, když je to tak strašně modulární, jak se někteří snaží tvrdit).

Tedy každý argumentuje na úplně jiném poli.

[Creckx]

Zase sis vybral pár slov a argumentuješ s tím proti celému textu. Tohle nemá smysl.

[Jendа]

Napsal, proč je pro superpočítač (a desktop a další…) systemd zbytečně bloated. (Já tomu nerozumím, nevím, jestli ten dhcp server nejde třeba zakázat při kompilaci.)

[martin]

dhcp server hlavne neni vubec soucasti systemd (jako initu). takze opsal par FUDu a doplnil to malym rantikem. proste klasika :)

[Jendа]

Takže v distribuci budu mít balíčky jako systemd a systemd-dhcpd a budu si moct ten druhý nenainstalovat?

[pavlix]

Já mám takový dojem, že systemd žádného samostatného DHCP démona neobsahuje, takže by se spíše jednalo o balíček systemd-networkd. Zda to tak bude se budeš muset svého distributora, nikdo jiný o tom rozhodnout nemůže.

[kralyk z abclinuxu]

Zda to tak bude se budeš muset svého distributora, nikdo jiný o tom rozhodnout nemůže.

Ehm... upstream do toho taky jaksi může mluvit

[pavlix]

Upstream distribucím do rozdělení do podbalíků zpravidla nekecá.

[kralyk z abclinuxu]

Jasný, ale šlo mi o to, že upstream musí prvně to rozdělení vůbec umožnit, jinak s tím distra nic neudělají (ne bez nějakého většího zásahu).

[pavlix]

Vzhedem k tomu, že je networkd samostatná binárka plus nějaké věci okolo, nevidím co více by pro to ještě měl upstream dělat.

[kavol]

Vzhedem k tomu, že je networkd samostatná binárka plus nějaké věci okolo, nevidím co více by pro to ještě měl upstream dělat.

asi jako systemd-journald je samostatná binárka?

[pavlix]

Nemyslím si, že je systemd-journald jen samostatná binárka, na které nic nezávisí.

[kavol]

Nemyslím si, že je systemd-journald jen samostatná binárka, na které nic nezávisí.

no právě ... což za prvé tak trošku popírá "distributora, nikdo jiný o tom rozhodnout nemůže" (právě ve smyslu toho, co namítá kralyk), a za druhé navozuje otázku, jak dlouho ta samostatnost networkd vydrží

[pavlix]

Oba dva dobře víte, že se v této oblasti zabývám současnými fakty a nikoliv hádáním z hvězd. Kdyby byli odpůrci systemd do k čemu, tak jsme něco takového vůbec nemuseli řešit. Jenda se sice ptal v budoucím časě, ale to si ještě nebyl vědom toho, že samotná otázka vychází z nesprávných či nesprávně interpretovaných informací.

[pavlix]

A vůbec, dost bylo prázdných keců. Jenda se zeptal, já jsem mu odpověděl, pokud vás to zajímá, zkuste tu informaci ověřit a nějak s ní naložit. Tohle nemá žádnou úroveň.

[m.]

to sjednoceni mi pripomina jeden citat od soudruha marxe: kazdy neco chce, kazdy chce neco trochu jineho nez kdokoliv jiny a kdyz se toto chteni da dohromady vznikne neco co vubec nikdo nechtel.

[Petr Tomášek]

[kavol]

Na rozdíl od většiny z vás jsem systemd začal používat co přilezl do Arch Linuxu a neměl jsem čas o něm diskutovat na internetu.

tady se ovšem nabízí otázka, jestli je mezi tím příčinná souvislost

[martin]

ani ne, ono je to uz dlouho a vetsine diskuteru tehdy jeste nikdo nevysvetlil, ze systemd znici linux a tak tehdy nadavali na jine veci, ktery znicej linux...tehdy bylo tusim v kurzu GNOME3

[kavol]

hm, no, ono když ve špajzu visí salám a zmizí jedno nebo dvě kolečka, málokdo si všimne ... když přijdeš hladovej a visí tam už jen prázdný očko, tak to docela nasere

[PanZvedavy]

Po dlouhe dobe jsem se diky odkazum v tomto zapisku dostal k zajimavemu cteni... http://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/

KONECNE! to nekdo popsal, tak jak to je.

"…a lot of the fear and uncertainty over systemd may not be so much about systemd, but the fear and loathing over radical changes that have been coming down the pike over the past few years, many of which have been not well documented, and worse, had some truly catastrophic design flaws that were extremely hard to fix."

"...Should we be concerned that a kernel developer, obviously a very qualified computer user (an MIT graduate in his 40s), has trouble understanding and using policykit and systemd to configure his own system? Where does that leave the average Linux user in handling these atrociously complex and built-to-be-broken technologies?"

"... Red Hat is a billion-dollar corporation with deep ties to the US military (their largest customer), and thus inevitably the NSA (a military security organization), etc. Adding to the conflict of interest, they have as direct corporate partners Google, Apple, and other too-large-to-imagine corporations with their hands in slime. Red Hat developers dictatorially control the core engineering of Linux, including components such as udev, udisks, xorg, dbus, systemd, etc., used by every major Linux distribution, as well as other common desktop components such as GNOME and GTK. (As Ts’o put it, “we have commit privs and you don’t”.) These are simple facts, though curiously never discussed. In many developers’ views, these Red Hat developers have consistently introduced closed, overly complex, security-breaking technologies to Linux for years, and have a long and tired history of sabotaging kernel development, creating unending bugs and problems for kernel developers, which they often categorically refuse to address. Linus knows them well – or does he?"

[martin]

az na to, ze ignorat guru je takovy ekvivalent petra hajka. ale kdyz chces byt pan zmateny, tak si klidne cti treba ac24...

[Jack Hokus]

Vážení,

právě jsem si prošel diskusi, která se rozpoutala pod mnou publikovaným postem. Dost mnou zamávala. Napsal jsem jen to, že se mi nelíbí SystemD a přístup lidí, kteří jej prosazují. Nijak jsem tuto komponentu ani lidi kolem ní nenapadl.

Jediné co jsem napsal, bylo, že se rozhlížím po možné alternativě a hledám lidi, kteří to vidí podobně.

Pravdou je, že že plnohodnotný přechod na jiný operační systém, je i přes mnohé společné prvky docela obtížný proces. Nejedná se o něco, co by se dalo "zmáknout" za týden.

Proto bych chtěl navrhnout všem, kdo taky uvažují o FreBSD jako o možné alternativě, zda by nebyli ochotni napsat něco o tom, jak postupují jejich přípravy a s jakými problémy se setkávají.

Můj záměr byl vyvolat věcnou diskusi o jedné z možných alternativ (FreeBSD).

Dalším záměrem bylo a stále je, aby o sobě lidé, kteří to vidí podobně věděli a neřešili již vyřešené a spolupracovali na řešení problémů příliš náročných pro jednotlivce.

Když jsem psal, že se mi na na SystemD něco nelíbí, samozřejmě jsem věděl, že z toho bude nějaký flame, ale čekal jsem, že se krom flamerů ozvou i lidé, kteří problematice rozumí a věcně proberou rozdíly mezi starým a novým řešením, aby ten kdo si tu diskusi pročte měl alespoň nějaký základ pro další hledání informací a vytvoření vlastního názoru. To se na vzdory stovce příspěvků pod blogem zatím nestalo. A myslím si že je toho třeba-

Už při psaní původního textu jsem podobný článek hledal, ale nenašel, proto jsem tam dal alespoň ty dva odkazy, s tím, že se z diskuse vynoří něco relevantnějšího.

[Grunt]

To se na vzdory stovce příspěvků pod blogem zatím nestalo.

A to je vážně překvapivé, že? Projdi si libovolnou jinou diskusi o sD v minulosti, která z nich kdy byla věcná a bez aut, Hitlerů a nadávek. Kdybych to nevěděl, tak bych asi podezříval Luboše, že vás platí za to abyste tyhle zápisky a zprávičky o sD psali, protože pak jez toho vždycky půltisícový flame a tuna downloadů za reklamu…

[PavelC]

Nahodit tema takhle mlhave a obecne a cekat vecnou diskusi ? To snad ne.

Napriklad jsem se vubec nedovedel, proc tu alternativu hledas. Pokud vim, tak u Debianu je podpora u wheezy min. do 2016 a jessie podporuje sysvinit i upstart a bude mit updaty min. do 2018. Pak tu byla zminena i dalsi distra ktera sysvinit nadale podporuji. Netusim co resis.

[kralyk z abclinuxu]

Nicméně pokud potřebujete nějaké speciální nastavení, třeba k instalaci ovladačů grafické karty, tak stejně musíte ten xorg konf vygenerovat.

Nevím, jak v tvé distribuci, ale v Archu na tohle stačí vytvořit celkem kraťoučký soubor v /etc/X11/xorg.conf.d/ ...

[mimi.vx]

xorg.conf.d funguje vsude , obrovsky xorg.conf je decaprated

[----]

Postavil jsem před pár dny nový desktop (miniITX kostku) a nainstaloval FreeBSD 11.

Hardware:

Intel i7-4770 16GB RAM Intel H97 nvidia GTX 760 250GB SSD (Samsung EVO 840) + 1TB HDD WD Black

K tomu mám pár periferií - multifunkční tiskárnu Samsung CLX-4195FW, webkameru Logitech C270, zesilovač s DACem NAD D 3020.

A překvapilo mě, jak dobře všechno funguje - nainstaloval jsem a v podstatě vše fungovalo out of box. Akorát grafiku jsem musel nainstalovat (oficiální ovladače od nvidie), a povolit TRIM na SSD (to byla volba v instalátoru)

tisk funguje, skenování funguje, webkamera funguje, přenos z Androidu přes MTP funguje, optický zvukový výstup funguje, USB zvuk funguje, kvalitní resamplování s minimálním využitím CPU (o dost níž než PulseAudio), Netflix funguje (přes Pipelight)

nový balíčkovací systém je taky dost dobrý, oproti starému způsobu dost zlepšení.

Bohužel nefungují videohovory přes Google Hangouts - není plugin... řešení by byl Firefox ve Wine, ale já našel lepší, prostě používám webrtc přes appear.in.

A kompletní desktop: http://ftp.octaforge.org/q66/random/bsd.png

[PanZvedavy]

vypada to dobre...vyhledove planuji prechod take, co je potesujici je, ze fbsd podle popisu funguje i na novem zeleze. Jak je na tom 11-ctka se stabilitou?

[----]

žádnou nestabilitu nepozoruju - nainstaloval jsem ze snapshotu... šel jsem do 11, protože 10-release neměla podporu pro všechen můj HW (10-release vyšla před tím, než se začal můj HW prodávat) - 10-stable by ale asi fungovala - já přesto šel hned do 11.

[jadd]

Měl bych dotaz jako na odborníka,

E1X tam nefunguje, že tam je xfce, nebo přestalo vyhovovat?

Pulseaudio se nedá už nastavit lépe aby splnilo požadavky?

[----]

e17 funguje, e18 funguje, e19 funguje, ale má problémy (protože to nikdo netestoval) a líp se debuguje, když to prostředí zrovna neběží jako hlavní.

pulseaudio tam je, ale nikdo ho nepoužívá a nepotřebuje, protože OSS funguje bez problémů a má všechny potřebné funkce.

[TM]

Mohl by mně někdo z obhájců "pokroku" už konečně odpovědět na jednoduchou otázku?
Rozumíte opravdu věcem jako je/byl console kit, policy kit, systemd-logind a některé další, kterými jsou dnešní distribuce doslova promořené a které si tam žijí vlastním životem? Máte je pod kontrolou, víte přesně, co dělají? Nebo jen tak kecáte jako Lojzové na zive.cz?
Nezajímá mě odkaz na povrchní dokumentaci z freedesktop.org. Zajímají mě konkrétní znalosti, detailní postupy, zkušenosti...
Přesně toho se totiž ta debata týká. Podobných věcí a podivného přístupu jejich autorů a "advokátů." Opravdu zdaleka nejde o init sytem - to je věc poměrně jednoduchá a snadno nahraditelná...Horší je to s podivnostmi, kterým často ani pořádně nerozumí jejich správci v jednotlivých distribucích.

[pavlix]

Asi mě nelze označit za obhájce „pokroku“, ale tomu, co dělají zmíněné komponenty rozumím včetně některých jejich problémů a s dalšími se seznamuju dle potřeby. Pravda je, že správci balíků v distribucích jsou touhle dobou pozadu a vývoj jako by se jich netýkal, probíhá bez nich a oni se jen pomalu přizpůsobují.

[Jardík]

Všechno jsou to zbytečnosti. ConsoleKit i PolicyKit jsou k ničemu, logind je k ničemu. Na hotplug stačí bohatě mdev, který vytvoří zařízení a nastaví skupinu, o zbytek se postarají správně přiřazené skupiny danému uživateli. Na zbytek tu je su(do). udisk(2), HAL a spol. jsou taky zbytečnosti, stačí monitorovat /dev a ukázat ve správci souborů třeba nově připojený externí disk a jestli ho smí připojit, o to se postará správná skupina. Na co proboha nějaká šmejďárna typu *Kit.

[pavlix]

Všechno jsou to zbytečnosti. ConsoleKit i PolicyKit jsou k ničemu, logind je k ničemu.

Linux je taky k ničemu.

[pavlix]

Mimochodem tohle je přesně důvod, proč se tradicionalisti nemůžou účastnit na dalším vývoji Linuxu, a tedy i důvod, proč ten vývoj probíhá tak jak probíhá.

[----]

za tradicionalistu se rozhodně nepovažuju, ale jsem zastánce kvalitního softwarového designu (což zahrnuje několik věcí včetně jednoduchosti a přenositelnosti) a zrovna ten policykit kvalitně navržený není - třeba ta obskurní konfigurace v XML... logind by ušel, ale tam zas chybí ta přenositelnost. No, třeba v OpenBSD vytvoří na platformě nezávislou implementaci - ale samozřejmě Lennart & co mají kompletní kontrolu nad referenční implementací, takže něco takového spravovat zrovna nejjednodušší nebude. a pak je tu HAL vs libudev - HAL potřeboval náhradu, ale poskytoval celkem dobrou abstrakci, ale dnes je trend používat libudev přímo, což je zas součást systemd, a kromě toho specificky linuxová. Ve FreeBSD ale dělají na libdevq, což by měla být obecná knihovna s podobnou funkcionalitou.

[pavlix]

za tradicionalistu se rozhodně nepovažuju

Pak ten komentář nebyl o tobě. Je zajímavé, jak se najednou mluví o tom, co vše se v *BSD řeší včetně reimplementace částí systemd, přitom měl kdokoli dávno možnost přijít se sadou nástrojů, které by poskytovaly multiplatformní řešení odpovídající kvality.

[Jardík]

libudev vůbec používat nemusíš, můžeš přímo použít netlink a dostaneš info o zařízení přímo z pana kernela. Link tu. Libudev je jen další zbytečnost, aby aplikace mohly mít jednu extra závislost, nebo se rozbýt, když jiní chcou třeba mdev z busyboxu. Přínosy různých *Kitů ani nestuduji, logind taky ne. Na co mít nějakýho login démona (nebo k čemu to vlastně je)? Vždyť od věků mi init skript nastartuje nějaký (a/m)getty a tím se přihlásím. Nebo mě přihlásí kdm/gdm, nebo něco jinýho. Na co tedy potřebuju logind, když jsem ho doteď nepotřeboval, jaký je jeho přínos?

[TM]

Přesně. To co je na tom linku bych doporučil jako povinnou četbu pro lidi, kteří rádi vymýšlejí hovadiny a vytvářejí problémy, které by bez nich nikdy nevznikly.
Je to odvěký problém Linuxu. Kernel je pevně v rukou lidí, kteří mají rozum, to co je v userspace je směs věcí ověřených časem s produkty podivných myšlenkových pochodů lidí, kteří k tomu přišli příliš pozdě na to, aby pochopili o co v tom Unixu vlastně jde. Je to škoda.

[pavlix]

Kernel je pevně v rukou lidí, kteří mají rozum

A proto je tam hromada sraček, které tam nemají co dělat, popřípadě jsou i nekonzistentní a špatně implementované. Zrovna v síťové oblasti není problém na takové narazit.

[TM]

Ale o tom to není. Sračky v zákoutích velkého projektu najdete všude. Fulltime je pro mě už nějakou dobu software pro řízení některých klíčových komponent v autech a ačkoliv je výrobce nepochybně světová špička, na co tam člověk občas narazí, to by jeden plakal. Jenže jako celek to funguje spolehlivě a udržovatelně aniž by to někoho sr.alo, což se o moderních kurvítkách v distribucích Linuxu ani náhodou říci nedá. Nicméně kernel z pohledu uživatele a admina prostě funguje a neotravuje.

[pavlix]

Nicméně kernel z pohledu uživatele a admina prostě funguje a neotravuje.

Z pohledu uživatele a admina kernel většinu doby neexistuje a pokud je s ním nějaký problém, podle mých zkušeností se z toho obviní nějaká userspace služba.

[----]

tahat to z kernelu je ještě míň multiplatformní, než libudev. Chce to knihovnu, která je přenositelná mezi systémy.

[TM]

Ale udělat nad tím tenkou vrstvu s jednotným rozhraním pro "uživatele" dostupným na všech platformách a vespod jen měnit to co je platformě závislé, to by asi nebyl problém. Proč ale vymýšlet různé obskurní Kity...

[----]

no, to má AFAIK být libdevq... obecná, ale tenká vrstva nad tvým device managerem (tzn. devd na *BSD, udev na linuxu), s API celkem podobným libudev (zatím toho mají tolik, aby to mohlo nahradit udev v Mese)

[Jardík]

Tahat to z kernelu je stejně málo multiplatformní, jako linux-only libudev, nehledě na to, že můžu místo udevu používat - již zmíněný - mdev a libudev mít nebudu. Taháním z kernelu to bude fungovat v obou případech, takže já preferuji tahat z kernelu. Ve FreeBSD (třeba) nebude fungovat ani jedno, tam je nějaký fifo od devd démona a netuším, jestli je něco přímo na tahání z kernelu, nestudoval jsem to.

[kralyk z abclinuxu]

Na co mít nějakýho login démona (nebo k čemu to vlastně je)?

Afaik kvůli podpoře multiseat.

Jinak homepage longind tvrdí: This is a tiny daemon that manages user logins and seats in various ways.

[kralyk z abclinuxu]

_{Inbefore "To nepotřebuju!!!"}

[Jardík]

Afaik kvůli podpoře multiseat

Co to je? Např. pro wayland je jakýsi set vstupních zařízení 1 seat. Proč by nějaký login démon spravoval vstupní zařízení? (možná kdybych nebyl línej hledat nějakou logind dokumentaci).

[Kvakor]

Afaik kvůli podpoře multiseat.

Hmm, takže kvůli vlastnosti, která se občas používá ve školství a možná i ve firmách (i když tam bych čekal spís tenké klienty nebo terminály), budu mít na svých strojích, jejiž jsem jediným uživatelem, software, jehož jedinou vlastnost, kterou má navíc oproti svému předchůdci, stejně k ničemu nevyužiju (leda že bych se z toho docela a kompletně zbláznil a v důsledku disociativní poruchy identity si vypěsoval několik nových osobností ).

[sigma]

Multiseat use-case může být také při vzdáleném připojení. Tedy když dám někomu remote desktop na můj stroj, tak aby např. neměl přístup k lokálním USB diskům.

[JS1]

Nebyly podobne argumenty slyset i v diskusi (v 90.letech) o tom, zda ma smysl mit viceuzivatelsky operacni system?

[Petr Tomášek]

Hele, pouč mě, co to znamená „rozbýt“?

Asi jsem už dlouho nebyl v ČR .

[TM]

Přesně to si, chtě-nechtě, myslím taky, kdykoliv se v tom hnoji jako admin musím hrabat.
Tedy až na HAL. Ten mně trochu připadal jako dobrá myšlenka, kterou ale zabila divoká a svérázná implementace.

[TM]

Dá se tedy dostat k nějakým dokumentům mimo toho mála, co je běžně dostupné? Já vím, jsou zdrojáky, ale na to, pokud pracujete i na jiných věcech, prostě nemáte jako admin čas.
Mám na mysli něco jako třeba dokumentace od RedHatu k cgroups (příklad toho, jak je pokrok někdy skutečně neoddiskutovatelně užitečný) - jasné, stručné, přehledné, v rozumné míře vyčerpávající.

[pavlix]

Nemám přístup k ničemu, co by nebylo běžně dostupné.

[TM]

Hmm, pak tedy dostatek času na experimenty. Nebo fakt nevím, ale to co je dostupné(nebo jsem špatně hledal) mně prostě přijde málo. Co takhle článek na to téma nebo aspoň zápisek v blogu? Já bych to tedy ocenil. Nedá vám zaměstnavatel nějaký čas "na osvětu", když už nás těmi věcmi tak obšťastňuje?

[pavlix]

Osobně dostatek času na experimenty mít musím, vzhledem k tomu, že mě Red Hat platí za práci na platformě, jinak by nemělo smysl tu práci ani dělat. Ale samozřejmě to neznamená dostatek času experimentovat úplně se vším, každý člověk se nějak specializuje. Zápisek do blogu ohledně systemd jsem teď jeden pouštěl a plánuju zas někdy napsat článek pro Fedora.cz.

[sonma]

Experimenty konci i jinde nez v tyhle sracce ? Doufam ze ne.

[pavlix]

Obávám se, že jsi trochu mimo.

[Heron]

K celému příspěvku +1.

Podobných věcí a podivného přístupu jejich autorů a "advokátů."

Upřímně řečeno tohle je něco, co mi v posledním roce vzalo poslední zbytky chuti se linuxem a IT vůbec dále zabývat. Lidé, vývojáři, kteří nedovedou odpovědět na otázku proč v systému něco je, ale hlavně doporučují to tam nechat a mít zapnuté. Jen proto, že je to součástí binární distribuce. Opravdu "profesionální" přístup. Nevím co to je, co to dělá, a tak to nechám zapnuté. WTF?

Správný přístup je přece přesně opačný. Nainstaluji pouze a jen to, co potřebuji. To, co instaluji, bych měl znát. Pokud se něco instaluje jako závislost, měl bych se zamyslet nad tím, zda tu závislost opravdu chci, tím, že se doučím, co to je a co to dělá. A pokud nechci, mohu se rozhodnout tam nemít ani tu závislou komponentu. Implementací čehokoliv je více.

V minulosti jsem se tu ptal na messagebus, dbus, hal. Tyto komponenty jsem vždy vypínal (mimo jiné) jako první po instalaci, protože bez nich fungovalo vše dle potřeby. Z tohoto pohledu jsou ty komponenty zbytečné. Dnes je to, jak správně píšeš, například *kit. Z trochou (s více trochy) snahy se i toto dá odpárat a vše funguje. Další zbytečná komponenta. dbus se projistotu dostává do jádra (kdbus), asi aby bylo složitější ho vypnout.

Upřímně řečeno jsou to všechno věci přicházející z jedné strany. Spousta z nich je obsolete dřív, než si vytížený člověk vůbec zjistí, proč se v těch systémech vůbec instalují a defaultně spouštějí. (Když se dají bez problémů vypnout, tak motivace ke zjištění, k čemu vlastně jsou je poněkud nízká.)

[pavlix]

Upřímně řečeno tohle je něco, co mi v posledním roce vzalo poslední zbytky chuti se linuxem a IT vůbec dále zabývat.

Každý má někdy krizi. Za sebe můžu doporučit v tom nešlapat a nevylévat si svoji krizi do diskuze o oblasti, které se ta krize přímo týká. Lepší je vypnout a zabývat se něčím úplně jiným.

[Heron]

Jasně, a potom se vrátit do Lindows 9, protože mezitím, co si všichni "v krizi" (žádnou krizi nemám) ze systemd "odpočinou" (v některých profesích se používá termín nucená dovolená, či "studijní" volno), budou mít systemdmáci volné pole na působení.

Mimochodem tohle je přesně důvod, proč se tradicionalisti nemůžou účastnit na dalším vývoji Linuxu, a tedy i důvod, proč ten vývoj probíhá tak jak probíhá.

A napadlo tě třeba někdy, zda je nějaký "vývoj" vůbec potřeba? Zda už to náhodou není dávno kompletní a zbývá jen údržba a odhalování chyb? Dost často každá práce dospěje do fáze, kdy přidání čehokoliv dalšího je jen na škodu. Velmi často naopak pomůže něco odebrat. Vývoj pro vývoj považuji za zločin.

[pavlix]

budou mít systemdmáci volné pole na působení.

Mluvíš, jako by ho teď neměli ;).

A napadlo tě třeba někdy, zda je nějaký "vývoj" vůbec potřeba? Zda už to náhodou není dávno kompletní a zbývá jen údržba a odhalování chyb? Dost často každá práce dospěje do fáze, kdy přidání čehokoliv dalšího je jen na škodu.

Nikdy jsem z linuxových systémů takový dojem neměl.

[Heron]

Mluvíš, jako by ho teď neměli ;).

Což je dost smutné.

Nikdy jsem z linuxových systémů takový dojem neměl.

No právě.

[pavlix]

Špatně se chápeme. Nikdy jsem z linuxových systémů neměl pocit, že by byly kompletní a hotové,

[Josef Kufner]

A napadlo tě třeba někdy, zda je nějaký "vývoj" vůbec potřeba? Zda už to náhodou není dávno kompletní a zbývá jen údržba a odhalování chyb? Dost často každá práce dospěje do fáze, kdy přidání čehokoliv dalšího je jen na škodu. Velmi často naopak pomůže něco odebrat. Vývoj pro vývoj považuji za zločin.

Důsledkem takového přístupu je pak například to, že nové mobilní telefony mají větší rozlišení než nové notebooky, neboť vývoj na desktopu se hodně zdržel kvůli Windows XP.

Dělat změny jen proto, aby se vykázala nějaká činnost je špatné, ale pokud takový přístup budeš prosazovat důkladně, zastavíš tím většinu vývoje. Čas od času je potřeba překopat základy a tím rozbít vše, co na nich stojí, aby bylo umožněno implementovat nové věci.

Rozumnou možností je dlouhodobá podpora ověřených verzí. Například KDE3 bylo udržováno celkem dlouho, než KDE4 dozrálo, i když jako oddělený projekt. Ale v případě, že jde o nekomerční nebo neziskové (vedlejší produkt komerční činnosti) projekty, tak se takový přístup nezaplatí a často na to nejsou prostředky. Takže by to příliš zdržovalo další vývoj.

Navíc v případě software slovo "hotové" většinou jen znamená "zvykli jsme si na stávající chyby".

[Heron]

No jako ono se to netýká jen IT.

První komerční jaderný reaktor v USA byl postaven za 4 roky. Ti lidé v roce 1958 používali logaritmická pravítka, papír a rýsovací prkno. Neexistovaly žádné superpočítače schopné simulovat procesy uvnitř reaktorové nádoby. Vše si dělali sami a poprvé. A za 4 roky hotovo. A měli tam všechno, co najdeme v elektrárně dnes, stroje pro zavážení paliva, vše pod vrstvou vody, bazén na vysloužilé palivo, vodní kanály apod. Až mě překvapilo, jak moc je to těch 50 let stejné a jak málo (relativně) se změnilo.

Dnes se jaderná elektrárna staví klidně 20let. Souhrnné zkušenosti s provozem jaderných reaktorů se počítají na desetitisíce let. Přesto, s moderními cad systémy, se simulacemi, se vším co dnes máme k disposici, to trvá 20 let.

Já jako nechci vynášet žádné "generační" soudy apod, dnešní věda a technika je rozhodně mnohem dál, než byla před těmi 50 lety, ale přes to bych čekal spíše zkracování, než pětinásobné prodloužení.

Dnes vývoj IT systémů, co v 80letech běhaly na pomalu osmibitech trvá několik let, je k tomu potřeba 100GB paměti a půl miliardy korun. (Nehledě tedy na to, že ty projekty jsou spíš účelové jako penězovod do kapsy někomu.)

[Josef Kufner]

(Nehledě tedy na to, že ty projekty jsou spíš účelové jako penězovod do kapsy někomu.)

Tohle bude ten hlavní problém. Další je, že do toho kecá moc lidí. Když stavěli tu první elektrárnu, tak nikdo krom pár vědců netušil o co jde, takže si to prostě v klidu postavili.

Jsem si celkem jist, že kdyby byla motivace, tak se to dnes postaví přes léto. Ale to by pak nebylo moc příležitostí k vycucnutí několika pěkných dotací a podojení rozpočtu na další rok.

[martin]

kdyz staveli tu prvni elektrarnu, tak to bylo za studeny valky a tudiz byl politicky tlak to dokoncit co nejrychleji bez vetsich ohledu na bezpecnost. ted - po katastrofach v rusku a japonsku - je naopak politicky tlak to udelat co nejbezpecneji, bez vetsich ohledu na cas a penize

prijde mi to docela logicke, nic fundamentalniho bych v tom nehledal...

[kralyk z abclinuxu]

například *kit. Z trochou (s více trochy) snahy se i toto dá odpárat a vše funguje. Další zbytečná komponenta.

Dejme tomu, že chce škola nasasdit linux. Požadavkem je, aby mohl student přijít k PC (se svým neprivilegovaným účtem), a např. si připojit flashku nebo po sobě vypnout PC. Jak tohle umožníš?

[Heron]

Obojí se dá dosáhnout i bez *kit.

Uživatel může připojit fs, pokud je uvedeno ve fstabu s parametrem user, stejně tak se dal vypnout počítač příkazem poweroff, pokud byl daný uživatel v příslušné skupině, nebo třeba v sudoers.

To se tady budeme zkoušet z jednotlivostí a až nějaká ze stran nebude vědět, tak prohrála nebo co?

[kralyk z abclinuxu]

To se tady budeme zkoušet z jednotlivostí a až nějaká ze stran nebude vědět, tak prohrála nebo co?

Ne, to byl příklad, k čemu je polkit.

[Heron]

A evidentně se v tomto konrétním bodě dá obejít bez něj.

[kralyk z abclinuxu]

Dá (a asi i lépe než přes fstab - funguje ještě pmount?). V polkitu jde o to, že si tyhle věci můžeš nastavit na jednom místě a detailněji. Nesnažím se tě přesvědčit o nutnosti používat polkit, jen jsem chtěl říct, že není úplně zbytečný, to je vše

Mně se na tom nelíbí to xml (což je ale způsobené v zásadě pouze tím, že nemám rád xml celkově spíš než jeho konkrétní použití v polkitu)

[Heron]

Nesnažím se tě přesvědčit o nutnosti používat polkit, jen jsem chtěl říct, že není úplně zbytečný, to je vše

Ale jistě. Pokud někdo polkit, nebo jakoukoliv další komponentu, pro své účely potřebuje, tak ať si ji nainstaluje, nebo ať si vytvoří distribuci (třeba i s dalšími programy například pro školství, jak tu bylo naznačeno). To je poměrně standardní a dosytosti používaná cesta. Já jen nevidím žádný důvod, proč tato a další komponenty musí být nejen nainstalována jako závislost, ale dokonce i spuštěna, v podstatě každé dnešní distribuci. To je jako kdyby já nutil všechny instalovat PostgreSQL server jen proto, že mě dělá skvělou službu a mám tento software v oblibě.

[rastos]

To je jako kdyby já nutil všechny instalovat PostgreSQL server jen proto, že mě dělá skvělou službu a mám tento software v oblibě.

Zlý príklad si si vybral. Správne to malo byť takto:

To je jako kdyby já nutil všechny instalovat MySQL server jen proto, že ho potřebuje akonadi, kterého používá půlka programů v KDE ... oh, wait ...

[kralyk z abclinuxu]

MySQL a AFAIK ani PolKit k provozu KDE4 potřeba nezbytně nejsou.

[sigma]

Uživatel může připojit fs, pokud je uvedeno ve fstabu s parametrem user

To hrubě nestačí, a nevidím ani moc jenoduchou cestu, jak to tradicionalisticky obejít. Statická konfigurace tady těch věcí už tolik neodpovídá reálnému světu jako v době klasických UNIXů. Vždyť já nevím, jak se budou jmenovat všechna možná bloková zařízení - a jejich partitions, které by uživatel mohl chtít připojit. Ani nevím, jaký filesystem tam bude mít.

Další věc je, že uživatel může mít na stroj zároveň i ssh přístup - třeba takovou počítačovou učebnu může využívat ke spuštění nějakých výpočtů mimo provozní dobu. Ale pak třeba nechci, aby ty počítače mohl vypnout, a aby si mohl připojit flash disk, který tam někdo zapomněl.

[Jardík]

Pokud má zařízení správnou skupinu, není problém, aby na něj uživatel s takovou skupinou přistupoval (pravidlo pro mdev či udev, nebo na pevno, to je jedno). Nepotřebuju na to *Kit.

[Josef Kufner]

To neřeší zabránění přístupu k zapomenuté flashce při vzdáleném přístupu, nebo odposlouchávání okolí počítače z mikrofonu a streamování zvuku po ssh. Totéž s vypínáním počítače, když na něm někdo zrovna pracuje – nějaký dobrák by takle mohl vyřadit výuku klidně na celý den.

[biolog]

Obojí se dá dosáhnout i bez *kit.

To je ten problém, jde to dosáhnout, což nestačí. Externí média, vypínání, atd je běžná činnost, zejména u desktopů. Přijatelný návod by byl nanejvýše: "zaštrtněte tenhle checkbox a pak několikrát zmáčkněte Next nebo OK". Není třeba se vzájemně zkoušet, už to, že lidmi běžně chtěné věci potřebují několik kroků každá (dobře, skoro každá), je prohra.

[biolog]

V nainstalovaném systému je přes 10k balíků. Není v silách člověka ani přečíst si jejich názvy, natož jejich popis nebo ospravedlněnost.

Uživatel volí distribuci podle toho, zda rozhodnutí jejich autorů dávají veskrze smysl. Lidi z distribucí volí defaultně instalované programy, které programy řeší problémy jejich uživatelů (typicky který je pohodlnější). Ani oni neznají vše. Distribuce mají lidi kteří se specializují na kernel, lidi na libc a základní utility, lidi na X a desktopová prostředí, atd.

Pár procent lidí zná o jejich systému hodně. Pár set jedinců na světě zná svůj systém komplet, protože se jim vejde na 4 diskety. Mainstreamoví uživatelé svůj OS neznají, leda pár pidi kousíčků, které je zajímaly, nebo jejichž selhání museli obcházet. Ale to je OK, protože od svého OS nic zvláštního nepotřebují.

A co vy? Měnili jste si nastaveni např Youtube? Já někdy přepínám na HD, ale obvykle to pozná z mé linky sám. Přepl jsem ho na HTML5, protože jsem ochotný tolerovat občasné problémy s přehráváním pokud to pomůže odladění otevřených formátů. Ale streamování videa má stovku jiných parametrů, které jsem neměnil, nebylo potřeba.

[Heron]

V nainstalovaném systému je přes 10k balíků.

Tak jsme si zapřeháněli ... (Nebo má ta tvá distribuce poměrně vysokou granularitu balíčků.)

• Debian Jessie, pracovní stanice s xfce4: 1300 balíčků z toho 650 knihoven.
• Debian Jessie, virtuálka (abych tu měl po ruce linux) na ntb (kde mám jinak W7): 245 balíčků z toho 91 knihoven.
• Debian Jessie, domácí file, db, webserver, minecraft, prostě domácí server na všechno: 650 balíčku z toho 300 knihoven.
• Debian Wheezy, ostrý soukromý webserver: 437 balíčků z toho 200 knihoven.
• CentOS 6, pracovní ostrý webserver: 496 balíčků z toho 70 knihoven. (Upřímně řečeno, tady by bylo hodně co odinstalovávat, ale nejsem v práci sám.)

Pár set neustále se opakujících balíčků, z nich většina je prostě jen stále se opakující základní závislost nemůže být pro admina problém. A naopak, jsem přesvědčen o tom, že admin by měl svůj systém znát.

[Josef Kufner]

Můj notebook s Debianem má nainstalováno 3161 balíčků a domácí server 1068. Přeháněl jen o malou multiplikativní konstantu

[biolog]

Ok, zmýlil jsem se 5x.

Ubuntu 14.4 (asi Raging RMS, nevím) 2580 balíků, fakultní Gentoo 3600 balíků. Porozumění funkci balíku trvá řekněme 5 minut. Pamatujme na to, že projekty na web stránkách říkají jak program či projekt uvnitř funguje, ne k čemu je dobrý a očekává, že člověk o řešeném oboru ví a že jej zajímají detaily a novinky. Že se ten homework měl zvědavec udělat už doma. (Popisky balíku v repozitáři jsou stěží dobré na úvod.) Takže 2580 balíků / 12 je 215 hodin. Nemožné. Leda jako koníček.

Admin by měl znát jak obecně počítače fungují. Uživatel by měl znát to, co se musí projevovat navenek (musíte to mít propojené správnými kabely, musíte občas instalovat záplaty, nemusíte se starat o defragmentaci nebo co je defragmentace). (Obvykle mu nezbývá než vědět i nějaká ta střeva, ale to z toho nedělá správnou věc).

[Heron]

Takže 2580 balíků / 12 je 215 hodin. Nemožné. Leda jako koníček.

Jestli je pro tebe projekt, který jsi odhadl na časovou náročnost 215h, nemožný, tak se asi nemáme o čem bavit. 215h je ve skutečnosti velmi malý projekt.

Jen pro představu, je to přibližně 10% z ročního fondu pracovní doby. Daleko více se vyčerpá na různých režiích, prostojích apod.

[Josef Kufner]

215 hodin (cca měsíc práce na plný úvazek) na to, abych si nainstaloval operační systém je sakra hodně. Teoreticky se to zvládnout dá, takže to není "nemožné", ale stále to je naprosto nereálné.

[Heron]

abych si nainstaloval operační systém

Ne, na to, aby ses něco naučil. 215h hodin na to, aby ses něco naučil se sakra málo. A pokud se to dotyčný naučí dobře, tak mu to může přinést daleko větší úsporu nejen v té instalaci samotné, ale i v používání a pochopení principů fungování. To je přece obrovský přínos.

[Josef Kufner]

Co se naučíš z popisů balíčků?

[Heron]

A co vy? Měnili jste si nastaveni např Youtube?

Když tam ještě nějaké nastavení bylo, tak ano. Teď je pro mě důležité odstranit reklamy (naštěstí to umí AdBlock) a beztak si zajímavá videa a celé kanály stahuji pomocí youtube-dl, protože mají tendenci mizet (například z takových závažných důvodů, jako že ve videu o práci s kovem na soustruhu je v pozadí skoro slyšet "autorsky chráněná" hudba). youtube-dl jsem měl nastaveno na stahování nejvyšší kvality, dneska už je to default. Tím získám offline dostupné video bez reklamy a v nejvyšší (YT) dostupné kvalitě.

[biolog]

A co vy? Měnili jste si nastaveni např Youtube?

Když tam ještě nějaké nastavení bylo, tak ano.

Tohle by mohl být zajímavý protiargument, kdybyste napsal, jaká nastavení to byla. Pak by mne zajímalo zda jste to tak jenom chtěl (např nemám rád XYZ), nebo zda byla chybná obecně (třeba že nedetekoval dostupné kodeky).

odstranit reklamy ...

Ano, to zapnutí AdBlocku bylo nutné, protože to Google dělá z důvodu peněz. Pro reklamu není technický důvod. Chtěl jsem ukázat, že skoro každá věc se dá napsat nastavená tak, aby vyhovovala 99% lidí (obyčejných, ne linuxáků).

celé kanály stahuji pomocí youtube-dl ...

Dokážete používat ne-defaultní programy. Gratuluji. To nemá vliv na to, že web rozhraní lidem stačí. (Stahování offline Google lidem nechce usnadnit, přestože to jde, takže stále platí to, že věci jdou tak dobře, že nepotřebují štelovat.)

[Radek Hladik]

Jen tak pro představu, víš, jaký init systém má FreeBSD, když "utíkáš, před systemd"?

Odpověd: téměř žádný Přiznávám, že nemám rád FreeBSD a poslední verze, co jsem viděl, je asi rok stará, ale situace ohledně managementu služeb je tam poměrně tristiní a lepší se jen pomalu... Většinou se jedná o nějaké "rc" skripty, které leckdy ani neberou parametr a prostě udělají "start", o nějakém "restart", "status", atd... ani nemluvě.

Přidám "vtipnou" historku. Asi před 10-ti lety jsem měl na Linuxu problém, že u zákazníka občas zůstal při bootu server viset s tím, že potřebuje zkontrolvat disk. A protože se to špatně řešilo po telefonu, tak jsem si napsal skript, který nastaví síť, spustí dropbear (SSH server) a pošle mail. Pak jsem potřeboval něco podobného na FreeBSD servery a co jsem nezjistil? Init je tam normálně jedna binárka a když napíše takovéto "vyberte shell nebo dejte enter pro /bin/sh", tak opravdu musím pracovat na lokální konzoli.... Nebo bych si musel init upravit a znovu přeložit...

[----]

píšeš blbosti. FreeBSD má a vždycky měl dependency based init systém, služby se povolí v rc.conf a init si mezi nimi pořeší závislosti.

Služby se ovládají příkazem "service", tzn. třeba "service apache22 start", "service gdm restart", "service rsyncd stop" nebo "service cupsd status". Tyto základní příkazy jako start/restart/stop/status/apod a pár dalších podporují všechny rc skripty. A takto to bylo vždycky.

[Radek Hladik]

Tak jsem se tedy na to podíval a máš pravdu, init je tam už opravdu nějakou dobu dependency based. Problém je v tom, že většína init skriptů, se kterými jsem se postupně potkal, na to nebyla uzpůsobená, ale když se na to teď koukám pořádně, tak to byla spíš smůla, protože hodně jich je dobře.

Příklady: ještě na FreeBSD 6 byl skript pro OpenVPN jednoduchý skript, který naloadoval tun/tap modul. Na 8.2 jsem teď našel dva skripty, které " no start|stop|restart supported" a rovnou spustí danou službu: echo "rc script not working (unknown reason) -> manually starting /usr/local/sbin/in.imapproxyd ...."

Ale to, že v nějaké té verzi 7 byl init monolitická binárka, která dělala dost věcí sama a nedalo se to naskriptovat, za tím si stojím. Dokonce jsem to tehdy řešil v nějakém fóru...

[Milan Jurik]

Drobná technická, FreeBSD 6 je z roku 2005, verze 7 vyšla v roce 2008, 6 let zpět. Velmi přínosný komentář znalce. V roce 2005 teprve začali lidé okolo Linuxu pokukovat po takových modernostech, jako je btrfs (ZFS), systemtap (dtrace) nebo systemd (SMF). Některé nezvládli zkopírovat dodnes, přitom FreeBSD je převzalo a úspěšně rozvíjí už mnoho let.

[Petr Tomášek]

A teď ještě tu o perníkové chaloupce, prosím...

[----]

a argumenty by nebyly?

[Milan Jurik]

Můžete uvést, co z toho, co jsem napsal, byla "pohádka"? Kde chybí fakta?

[Milan Jurik]

Také pomalu migruju směrem k FreeBSD. Pravda ale z jiného OS než Linux a to z OpenIndiany. Přece jen mne přestalo bavit být tím jediným, který udržuje celý vehikl okolo GUI a který se pohybuje v prostředí operačního systému, kde hlavní tvůrci mají nulový zájem o desktop. Volného času mi moc nezbývá. FreeBSD jsem si zvolil proto, že po těch letech jsem si zvykl na ZFS a dtrace a stavu, kam se Linux ubírá, celkově po těch mnoha letech nějak už nerozumím. Některé věci tam chybí stále, desktop na OI byl uživatelsky přívětivější, ale to se časem poddá.

Odpor k systemd chápu, do značné míry je to Solarisí SMF na steroidech a je zvláštní shoda náhod, že architekti obou těch systémů jsou zcela bezohlední vůči svému okolí, mající jediní oni pravdu ve své genialitě. To, že z nich vypadává nedotažená věc, je netrápí, až je přestane bavit, jdou za jiným projektem a výsledky jejich práce mají nepříjemné důsledky, se tak nějak vedoucími ignoruje. Pánové Lennart Poettering a Stephen Hahn jsou snad dvojčata (věkově spíše tedy syn a otec).

A teď k FreeBSD - doporučuji jít směrem z Gnome 2 na Mate, chová se docela pěkně, předkompilované je, zatím jsem nenašel důvod, proč zůstat u Gnome 2. Skype jde nainstalovat přímo z ports, po instalaci mi běhá pěkně až na problém se zvukem, dosud jsem jej nerozchodil, ale protože Skype jsem na Solarisu opustil někdy okolo roku 2008, kdy mne přestalo bavit udržovat si Linuxovou zónu, tak i jen chat Skype je posun pro mne do dnešního světa Firefox - standardně se nedistribuuje s lokalizací, třeba u Solarisích buildů na Mozilla ftp chybí. Dříve pomáhalo doinstalovat cs.xpi balíček z Linuxového buildu, ale posledních pár měsíců nefunguje toto řešení a protože lokalizace webového prohlížeče není zrovna pro mne nutností, neřeším více.

Celkově je vidět velký posun proti uplynulým rokům. Zkoušel jsem i PC-BSD, ale tam jsem měl problémy se stabilitou systému, přitom základ je podle všeho ten samý.