Totální znechucení jménem systemd (diskuse)

[mess]

... ovládání je silně nepohodlné, zmatené, neznámé a nefunkční.

S tím dokáže pomoct příkaz man archlinux, je tam napsané, kde se co konfiguruje. Zase se rychle zorinetuješ.

[Ondra]

ale on prece pise, ze chce, aby system slouzil jemu a ne aby on byl otrokem prikazu man.

[jyrki]

Presne. Ja jsem silne konzervativni uzivatel. Mimo pacmana je prave jednoduchost a prehlednost bsd-like init scriptu duvodem proc jsem mel Arch.
Pardon, ale presne takove kotrmelce a zasadni zmeny jen podporuji teorie o uhrovitych hosicich co maji Linux protoze nemaji nic lepsiho na praci nez se jen rypat v Linuxu. Pardon za podraznene komentare, ale vidim rude.

[mess]

To chce klid a nohy v teple Já jsem zase zastáncem toho, že člověk by se neměl bát naučit se něco nového.

[gauri]

Ja jsem silne konzervativni uzivatel.

a proto pouzivas arch? hahaha

[skywaker]

to chce vyskusat CRUX (www.crux.nu)

[jyrki]

Mám v plánu taky vyzkoušet, ale trošku se bojím že budu muset všechno instalovat ze zdrojáků, balíčků v binární podobě jsem moc nenašel, přece jen je to distro zaměřené spíše na server

[luky]

prave jednoduchost a prehlednost bsd-like init scriptu duvodem proc jsem mel Arch.

BSD like init skripty ma i debian. Staci nainstalovat file-rc misto sysv-rc.

[jyrki]

Díky moc za tip, vyzkouším. Opravdu jsem o tom neměl ani tušení.

[Michal Fecko]

freedom of choice sa ale netyka teba ale ludi okolo tvojej distribucie ty si distro mozes ked tak zmenit za ine (ktore este nepreslo na systemd ci inu featuru ktora otravuje zivot - KDE4 ci GNOME3 a pod. ) alebo otrocky prekladat vlastne distro zo zdrojakov (a stale budes nuteny pouzit nejake funkcne a podporovane riesenia, takze ta sloboda tiez trosku odpada). tak a teraz ma ukrizujte p.s. tiez som zo systemd sklamany...

[jyrki]

...ty si distro mozes ked tak zmenit za ine (ktore este nepreslo na systemd...

Presne tohle jsem zminoval. Kde je ten freedom of choice? Drive nebo pozdeji prakticky vsechny distra skonci u systemd. A urcite mam lepsi praci nez instalovat kazdou chvili jine distro pote co to "moje" prejde "konecne" na systemd.

[Sešívaný]

Přechod Ubuntu na systemd je z politických důvodů ještě dlouho v nedohlednu a myslím, že takový Slackware jako takový typický zástupce konzervativnosti a KISS se init démona taky hned tak nezbaví.

[R]

V Debiane je systemd v testingu, ale podla wiki no nie je velmi funkcne, takze to ako default urcite dlho nebude (ak vobec niekedy).

Slackware som dlho pouzival, ale je cim dalej, tym nepouzitelnejsi. Ani posraty LibreOffice neexistuje ako balik v pouzitelnej verzii (bud je to stara verzia, kde nefunguje zoznam naposledy otvorenych dokumentov alebo nova, ktora pri praci s ODT stale ukazuje chybu "General error"). V distribucii nie je vlastne takmer nic, baliky od tretich stran su velmi pochybnej kvality alebo neexistuju vobec. Checkinstall na vyrobu vlastnych balikov je viac-menej nefunkcny. Balickovaci "system" (kopa hnoja v bashi) je brutalne pomaly a ked sa clovek do toho "kodu" pozrie, tak je mu na vracanie.

[Bubak]

To doufam (Teda za Slackware, samozrejme)

[kralyk z abclinuxu]

Já na systemd přešel před pár dny a celkem bez problémů, resp. stačila špetka toho RTFM. Bootování je teď o dost rychlejší (ne, že by na tom sešlo - úzké hrdlo je stejně načítání KDE4). A taky mi teď nefunguje fbsplash, ale ten mi rozumně nefungoval nikdy... Co mě štve je journal - ten je imho na hlavu. Ale naštěstí to není povinný.

[jyrki]

Sorry ale rychlost bootu me nezajima, nehonim setinky, realne to stejne nepoznas a tak casto nebootuju...a u systemd mi principialne vadi zpusob jeho ovladani. RTFM muzu, ale proc? Systemd se mi nelibi, nevyhovuje mi a nechci jej.

[kralyk z abclinuxu]

realne to stejne nepoznas a tak casto nebootuju...

Na mém stroji to je určitě reálně dost poznat. Ale, jinak souhlasim, moc na tom nesejde...

[pako]

Arch neznám, ale on je nakonec časově není takový rozdíl mezí BSD stylem u jednoduché distribuce (jako Slack) a systemd u něčeho mnohem komplexnějšího... protože se možná startuje sériově, ale málo služeb. ;)

[stativ]

U mě taky – boot se sytemd trvá déle, ale kvůli debilnímu NM nemám jinou možnost.

[pavlix]

Souvislost mezi systemd a NM by mě docela zajímala, zvláště pokud máš namysli NetworkManager.

[stativ]

Bez systemd se na Archu s novým NetworkManager jako uživatel nepřipojíš, protože oprávnění řeší pomocí systemd-logind místo ConsoleKit. Zatím se dá použití ConsoleKit nastavit jako compile-time switch, ale co jsem slyšel, tak z NM chtějí podporu CK vyhodit úplně.

[pavlix]

Bez systemd se na Archu s novým NetworkManager jako uživatel nepřipojíš, protože oprávnění řeší pomocí systemd-logind místo ConsoleKit.

Je tedy problém v debilním Archu nebo debilním NM? :)

Zatím se dá použití ConsoleKit nastavit jako compile-time switch, ale co jsem slyšel, tak z NM chtějí podporu CK vyhodit úplně.

Chtějí kdo? Na každé linuxové konferenci v česku říkám, ať se lidi vykašlou na drby a přijdou se zeptat mě, když chtějí o NetworkManageru něco vědět. Čtu každý commit, každou zprávu v mailing listu, a každý bugreport na komponentu 'general'.

Rozhodování v NetworkManageru se neřídí čtením myšlenek uživatelů Archlinuxu. Takže pokud maintainer svévolně vyhodil podporu pro ConsoleKit, je to jeho problém. A zřejmě ho to vůbec nezajímá, protože od něj žádný bugreport nevidím.

Předpokládám, když už nevidím bug report, že jsi problém zahlásil aspoň v tom „debilním“ Archu :).

Pokud bys nevěděl, komu posílat děkovné dopisy, že za tebe přesně toto řeší, tak si přečti toto vlákno na mailing listu NetworkManageru. A ani ten Luke Shumaker není z Archlinuxu, ale Parabola GNU/Linux, což by měl být nějaký derivát Archu, podle všeho.

Ne že by nás Archlinux nějak zvlášť zajímal (v NetworkManageru se pokud vím nijak neangažují, jejich problém), ale dokud bude Gentoo fungovat na OpenRC, tak tvrdá závislost na systemd nepřipadá v úvahu.

[stativ]

Je tedy problém v debilním Archu nebo debilním NM? :)

V debilním freedesktop, který se vykašlal na debilní ConsoleKit a v debilním GNOME, jehož některé části (už nevím jaké, protože GNOME je mi ukradené) měli bez ještě debilnějšího systemd nějaké problémy.

Chtějí kdo? Na každé linuxové konferenci v česku říkám, ať se lidi vykašlou na drby a přijdou se zeptat mě, když chtějí o NetworkManageru něco vědět. Čtu každý commit, každou zprávu v mailing listu, a každý bugreport na komponentu 'general'.

Co jsem trochu zjišťoval, tak Gnome bude řešit primárně systemd a consolekit bude fungovat jen do té doby, dokud bude poskytovat potřebná API. Vzhledem k tomu, že je CK mrtvý, dříve či později Gnome ekosystém, jehož je NM součástí, s CK nepojede.

[kralyk z abclinuxu]

Hm, takže chyba vlastne ani tak není v Gnome, natož v NM, ale prostě v tom, že FreeDesktop se od CK přesunul k systemd. Jinak kromě Gentoo používá NM např. i Ubuntu, a ti vypadaj, že NM maj celkem v oblibě, takže to vypadá, že non-systemd NM tu ještě minimálně nějakou dobu bude.

Jinak k systemd: Dělá to na mě dojem, že tenhle SW potřebuje jako prase drbání jednu věc: modularizaci. Obsahuje poměrně dost součástí (init systém, log systém, session management, udev, ...), které by mohly celkem dobře fungovat zvlášť na konfiguracích, kde někdo chce např. jiný init, jiný session manager, etc... Nevím, jak je na tom s modularizací dneska (asi nic buhví co), ale dobudoucna to vidím jako víceméně nevyhnutelné (v nějaké podobě), resp. čím dřív se to stane, tím líp. Je samozřejmě otázka, jak se k tomu vývojáři systemd postaví... Doufejme, že střízlivě.

[pavlix]

FreeDesktop se od CK přesunul k systemd

A veskutečnosti ani v tom. Protože FreeDesktop je pouze prostor pro cross-desktop spolupráci, ne nějaký rozhodovací orgán.

Jinak kromě Gentoo používá NM např. i Ubuntu, a ti vypadaj, že NM maj celkem v oblibě, takže to vypadá, že non-systemd NM tu ještě minimálně nějakou dobu bude.

A pokud by se vám někomu chtělo portovat NM na BSD a následně ho udržovat (!) do doby, než bude dostatečně významný na to, aby se ho vždy někdo ujal, tak si to můžete pojistit téměř natrvalo, vzhledem k nekompatibilitě mezi systemd a BSD jádry (a nekompatibilitě mezi systemd a BSD vývojáři).

[stativ]

A veskutečnosti ani v tom. Protože FreeDesktop je pouze prostor pro cross-desktop spolupráci, ne nějaký rozhodovací orgán.

Samozřejmě poslední slovo mají vývojáři, ale vzhledem k tomu, že CK jakožto freedesktop pseudo-standard spadá pod freedesktop, přišlo mi to jako vcelku přirozené označení.

[pavlix]

Jako mě to přijde velice vtipné, když uživatelé Archlinuxu kvůli chybám či nečinnosti maintainerů Archlinuxu nadávají postupně na šest různých jiných věcí, jenom aby nemuseli přiznat, že je problém v jejich milovaném projektu.

[stativ]

Zato to, že upstream maintainerům háže klacky pod nohy je zcela v pořádku.

[pavlix]

Jestli máš nějaké konkrétní obvinění, sem s ním. Pokud ne, budeš za hlupáka.

[stativ]

Co třeba spojení udev a systemd a vyjádření, že provoz udev bez systemd je nepodporovaný, ukončení vývoje ConsoleKit, už nějaké problémy s Gnome (které jak už jsem řekl přesně neznám, protože mě nezajímají)…

A jestli ti přijde, že používat něco, co sami vývojáři nepodporují/odrazují od toho je normální (a z hlediska budoucnosti udržitelné), tak nevím, kdo je tu hlupák.

[pavlix]

Co třeba spojení udev a systemd a vyjádření, že provoz udev bez systemd je nepodporovaný, ukončení vývoje ConsoleKit, už nějaké problémy s Gnome (které jak už jsem řekl přesně neznám, protože mě nezajímají)…

Dosud jsme se pohybovali v kontextu NetworkManageru. Za vývoj systemd žádnou odpovědnost necítím. A už jsem měl to dočinění s nimi něco řešit.

A jestli ti přijde, že používat něco, co sami vývojáři nepodporují/odrazují od toho je normální (a z hlediska budoucnosti udržitelné), tak nevím, kdo je tu hlupák.

Normální je ledacos včetně právě toho, co píšeš, takže pokud máš v tuhle chvíli potřebu mě označit za hlupáka, udělej to přímo :). Je to součástí toho práva na výběr a principů, na kterých stojí open source software.

Stejnětak je normální takový projekt přestat používat, ve chíli, kdy máš k dispozici alternativu, která ti vyhovuje a je aktivně vyvíjená.

[stativ]

Dosud jsme se pohybovali v kontextu NetworkManageru. Za vývoj systemd žádnou odpovědnost necítím. A už jsem měl to dočinění s nimi něco řešit.

V kontextu NetworkManageru ses pohyboval jen ty.

Já jsem schopen to vnímat i z globálního hlediska – jeden upstream projekt řekne – dělejte si co chcete, ale když budete mít problémy, vykašlem se na vás. Druhý řekne, balíme to, používejte něco jiného. Třetí řekne starý kód necháme, ale nedoporučujeme to, protože na to všichni kašlou. Tomu se říká svoboda volby? Nepřímo takhle nutí všechny používat to jediné správné řešení, protože málokdo v linuxovém světě má dostatek sil na udržování všech takových projektů.

[stativ]

V kontextu NetworkManageru ses pohyboval jen ty.

Ještě dodám jednu věc – je sice pěkné, že NM bezproblémově funguje s CK, ale ve chvíli, kdy desktopové prostředí víceméně vyžaduje systemd nemáš moc na výběr a holt musíš použít systemd i pro NetworkManager.

[pavlix]

ve chvíli, kdy desktopové prostředí víceméně vyžaduje systemd nemáš moc na výběr

Máš na výběr ostatní desktopová prostředí nebo dokonce nemusíš používat žádné desktopové prostředí, pokud nechceš.

a holt musíš použít systemd i pro NetworkManager.

Můžeš :).

[stativ]

Máš na výběr ostatní desktopová prostředí nebo dokonce nemusíš používat žádné desktopové prostředí, pokud nechceš.

A to i když jsi distribuce, která chce podporovat všechna hlavní desktopová prostředí, ale má jen dva vývojáře udržující init?

Můžeš :).

Dost možná je to prackama, ale pomocí KDE appletu, který používá ConsoleKit se mi nepodařilo připojit, když byl NetworkManager zkompilovaný se systemd. Ani bych se nedivil, kdyby to nešlo ani opačně (NM používající CK, applet používající systemd).

[pavlix]

A to i když jsi distribuce, která chce podporovat všechna hlavní desktopová prostředí, ale má jen dva vývojáře udržující init?

Maintaineři distribuce si můžou dělat, co chtějí, a začleňovat a používat to, co je k dispozici, za předpokladu, že jsou schopni to spravovat.

To už se mě můžeš rovnou zeptat, zda můžu svobodně založit novou distribuci s podobným počtem balíků jako má Gentoo, zadáš pár specifických pravidel. A já ti na to řeknu, že můžu, tedy nikdo mi v tom nebrání, nicméně na to nemám čas a i kdyby jo, tak se na něco takového můžu v jednom člověku vysrat (pokud to nebude mírně vylepšený derivát Gentoo).

Dost možná je to prackama, ale pomocí KDE appletu, který používá ConsoleKit se mi nepodařilo připojit, když byl NetworkManager zkompilovaný se systemd. Ani bych se nedivil, kdyby to nešlo ani opačně (NM používající CK, applet používající systemd).

NetworkManager jako systémová služba ConsoleKit, PolicyKit ani SystemD ke svému běhu vůbec nepotřebuje. Jenže NetworkManager poskytuje informační a konfigurační rozhraní a potřebuje se nějakým způsobem rozhodnout, co komu dovolí s ním dělat.

NetworkManager nedostane z D-Busu dostatek informací pro autorizaci, takže si musí zbytek dozjistit z nějakého jiného API. Ty třídy, co slouží pro zjišťování těchto informací z ConsoleKit nebo SystemD musejí implementovat asi čtveřici metod, takže fakt nic těžkého.

A jak tak na to koukám, tak se to bere navíc podle uid a ne pid, takže podle všeho ten modul umí odpovídat jenom na otázku, zda zda je uživatel přihlášen a zda je to přihlášení do aktivního sezení. Obojí podle username a podle uid. To jsou dohromady čtyři funkce vracející boolean a jako vedlejší efekt ještě překládají mezi uid a username.

Nevidím jediný důvod, proč by mělo v tomto případě nějak zvlášť záležet na tom, co používá druhá strana a zda vůbec něco takového používá. Takže bych problém na 99% hledal jinde.

Pokud to sám nevyřešíš, doporučuju reportovat:

1) Distribuce, protože to je místo, kde dochází k integraci všech nástrojů

2) KDE, protože máš problém specificky s KDE nástrojem

3) NetworkManager, kde je možné dělat takové kroky jako třeba používat jak systemd, tak consolekit, podle toho, co je na tvém systému skutečně v provozu

Je dobré mezi sebou bug reporty prolinkovat, protože každý nějak přispět k vyřešení.

[Martin Mareš]

Jenže NetworkManager poskytuje informační a konfigurační rozhraní a potřebuje se nějakým způsobem rozhodnout, co komu dovolí s ním dělat.

Ono by mimochodem vůbec nebylo od věci, kdyby se mu také dalo nastavit "nikoho se neptej a dovol každému všechno". To stejně většina uživatelů chce :)

[pavlix]

Splněno.

./configure --with-session-tracking=none

Potom ty funkce vypadají následovně:

gboolean
nm_session_monitor_user_active (NMSessionMonitor *monitor,
                                const char *username,
                                GError **error)
{
        return TRUE;
}

gboolean
nm_session_monitor_uid_active (NMSessionMonitor *monitor,
                               uid_t uid,
                               GError **error)
{
        return TRUE;
}

[Martin Mareš]

To je fajn, ale ještě by bylo hezké, kdyby to šlo za běhu.

[pavlix]

To by nebyl až takový problém. Už jsme předělali a předěláváme jiné konfigurační volby na volby běhové.

[pavlix]

Dobrá tedy. Nevím sice, jestli to myslíš přesně takhle, ale máš možnost bug report doplnit dle potřeby.

Doporučuju všem, kteří se o to zajímají se alespoň přidat do Cc.

[stativ]

Maintaineři distribuce si můžou dělat, co chtějí, a začleňovat a používat to, co je k dispozici, za předpokladu, že jsou schopni to spravovat.

A přesně o to mi jde – v Archu nejsou schopni dlouhodobě spravovat dva init systémy.

A když se má vybrat mezi dvěma systémy, kde oba stojí zanic, ale jeden z nich je všemožně protlačován i jinde, tak je volba vcelku jasná. Mám v plánu se pokusit initscripty nějakou dobu udržovat, až se na ně Tom vykašle. Nakonec stejně budu muset přejít na systemd i na desktopu, ale budu to oddalovat co nejvíce – jsem příliš paličatý.

NetworkManager jako systémová služba ConsoleKit, PolicyKit ani SystemD ke svému běhu vůbec nepotřebuje. Jenže NetworkManager poskytuje informační a konfigurační rozhraní a potřebuje se nějakým způsobem rozhodnout, co komu dovolí s ním dělat. …

Díky za popis, jak to funguje. Ještě se v tom povrtám a zkusím zjistit, kde je problém.

[pavlix]

A přesně o to mi jde – v Archu nejsou schopni dlouhodobě spravovat dva init systémy.

Je na jejich zodpovědnosti zvolit postup, který pro ně dává smysl.

A když se má vybrat mezi dvěma systémy, kde oba stojí zanic, ale jeden z nich je všemožně protlačován i jinde, tak je volba vcelku jasná.

Jsou i jiné volby, například OpenRC. A byla by škoda další volby vůbec nebrat v úvahu. Nebo lze teoreticky i zvolit to, na čem si Archlinux léta zakládal a čím se po celou dobu odlišoval od drtivé většiny ostatních distribucí. Dosud vám nevadilo, že všichni ostatní dávají přednost úplně jinému stylu initscriptů a jejich konfiguraci pomocí symlinků, update-rc.d, chkconfig a podobných.

Díky za popis, jak to funguje. Ještě se v tom povrtám a zkusím zjistit, kde je problém.

Povrtej se, a pokud můžeš, tak reportuj anglicky a zde.

[stativ]

Dosud vám nevadilo, že všichni ostatní dávají přednost úplně jinému stylu initscriptů a jejich konfiguraci pomocí symlinků, update-rc.d, chkconfig a podobných.

Nevadilo, mi to tak měli rádi. Ale bohužel nastala doba, kdy systemd v podstatě musí být podporovaný a na podporu druhého init systému není dostatek sil. Tím, jak začíná být systemd svázaný s jinými částmi systému, by se brzo muselo udržovat několik verzí různých balíčků (např. polkit-consolekit a polkit-systemd).

[pavlix]

Ale bohužel nastala doba, kdy systemd v podstatě musí být podporovaný

A co byste ztratili? Gnome? Sorry ale vývoj desktopu sleduju fakt latentně.

Tím, jak začíná být systemd svázaný s jinými částmi systému, by se brzo muselo udržovat několik verzí různých balíčků (např. polkit-consolekit a polkit-systemd).

Tak což o to, některé věci by šly řešit líp než je řeší současný upstream, a to buď formou patchů nebo nějakých forkovaných větví. Ale samozřejmě by do toho musel někdo jít :). Mně momentálně network management bohatě stačí :).

[stativ]

A co byste ztratili? Gnome? Sorry ale vývoj desktopu sleduju fakt latentně.

V budoucnu asi ano. Určitě by to ještě nějakou dobu šlo, ale záviselo by to na neudržovaném kódu, což není úplně dobré.

Tak což o to, některé věci by šly řešit líp než je řeší současný upstream, a to buď formou patchů nebo nějakých forkovaných větví. Ale samozřejmě by do toho musel někdo jít :). Mně momentálně network management bohatě stačí :).

Jedna z filozofií archu je patchovat, jen když je to opravdu nutné (typicky chyba, která si vysloužila CVE nebo oprava kompilace).

[pavlix]

V budoucnu asi ano. Určitě by to ještě nějakou dobu šlo, ale záviselo by to na neudržovaném kódu, což není úplně dobré.

Vývoj Gnome je natolik dynamický a proměnlivý, že by mohlo mít cenu to nějakou dobu držet a počkat, co na to ostatní.

Jedna z filozofií archu je patchovat, jen když je to opravdu nutné (typicky chyba, která si vysloužila CVE nebo oprava kompilace).

Jasně, to by měla být filosofie každé malé distribuce.

[pavlix]

Nevadilo, mi to tak měli rádi.

Mimochodem, Gentooisti mají OpenRC rádi ještě pořád, ne?

[Honza Jaroš]

V systému ho mám pořád. Naopak gnome-shell stále není v portage označen za stabilní (což mi vyhovuje, spokojeně používám Gnome2). Jak tak čtu místní diskusi, možná to spolu souvisí...?

[stativ]

Povrtej se, a pokud můžeš, tak reportuj anglicky a zde.

Tak to bylo rukama.

[pavlix]

To je ten lepší případ :).

[pavlix]

Já jsem schopen to vnímat i z globálního hlediska – jeden upstream projekt řekne – dělejte si co chcete, ale když budete mít problémy, vykašlem se na vás. Druhý řekne, balíme to, používejte něco jiného. Třetí řekne starý kód necháme, ale nedoporučujeme to, protože na to všichni kašlou.

Možná za slovem upstream místo jeho skutečného významu vnímáš nějakou konspiraci či co.

Tomu se říká svoboda volby?

Svoboda volby se říká tomu, že si můžeš vybrat. Ne tomu, že ať si vybereš cokoli, je to stejně jednoduché.

Nepřímo takhle nutí všechny používat to jediné správné řešení, protože málokdo v linuxovém světě má dostatek sil na udržování všech takových projektů.

Na LinuxExpo nám jednou přišel člověk, který svobodu vnímal tak, že my (přičemž nevím, koho všechno tím vlastně myslel) máme povinnost mu vše dodělat podle jeho představ.

Ale někteří lidé si to nenechají vysvětlit a nebo možná pro ně ten typ svobody, co open source poskytuje, nemá takovou hodnotu jako pro nás.

[Martin Mareš]

Tomu se říká svoboda volby?

Ano, říká. Máte svobodnou volbu mezi používáním věcí, jež udržují ostatní, a přiložením rukou k dílu. Nebo případně zaplacením někomu, aby to, co chcete používat, udržoval.

[stativ]

Já, jakožto jeden člověk nemám šanci tohle všechno udržovat. Budu rád, když krom svých projektů zvládnu udržovat initscripty, až na to dojde.

[Martin Mareš]

Já, jakožto jeden člověk nemám šanci tohle všechno udržovat.

Věřím, že lidí, kteří by něco takového chtěli, bude spousta. Jen se místo brblání snažit...

[pavlix]

+1

Dost lidí podle mě chápe, že musíme myslet i dopředu, protože autoři některých novot jsou známi tím, že si za svým projektem stojí jen po velmi omezený časový úsek. Pak už z nich nedostaneš ani větu na téma projektu, který už je nezajímá.

[kralyk z abclinuxu]

jeden upstream projekt řekne – dělejte si co chcete, ale když budete mít problémy, vykašlem se na vás. Druhý řekne, balíme to, používejte něco jiného. Třetí řekne starý kód necháme, ale nedoporučujeme to, protože na to všichni kašlou. Tomu se říká svoboda volby? Nepřímo takhle nutí všechny používat to jediné správné řešení, protože málokdo v linuxovém světě má dostatek sil na udržování všech takových projektů.

A jak se to liší od dřívější situace s BSD-style initscripty? Vzpomínám si, že jsem se tehdá zaobíral myšlenkou zkusit na svém Archu rozběhnout Upstart, ale když jsem viděl ten naktualizovanej bordel, tak jsem se na to vykašlal. Takže co se týče svobody volby, tak to imho je to samé v bledě modrém. Jedinej rozdíl je v tom, že dřívější "jediné správné řešení" se tobě osobně zamlouvalo, kdežto to současné ne.

[pavlix]

A jak se to liší od dřívější situace s BSD-style initscripty?

Tak, že systemd není jen init, ale celý ekosystém, který nabízí i další služby. Tudíž je používán nejen k rozběhnutí systému, ale poskytuje různá nesouvisející API dalším službám a aplikacím v systému.

Některé z nich pochopitelně toto API používají a spoléhají na něm a tudíž můžou být na systemd závislé.

Další problém je, že nejen že vývojáři systemd nepodnikají kroky, které by tuto závislost držely v rozumných mezích, ale spíše mi přijde, že podnikají kroky zcela opačným směrem.

[kralyk z abclinuxu]

No asi jsem měl napsat BSD-style initscripts + udev + syslog-ng + CK + ..., zkrátka, maintaineři stejně tak jako tak nabízeli jen jednu možnost.

Další problém je, že nejen že vývojáři systemd nepodnikají kroky, které by tuto závislost držely v rozumných mezích, ale spíše mi přijde, že podnikají kroky zcela opačným směrem.

Jó, k tomu +1, něco podobného jsem psal někde vedle s tou modularizací...

[pavlix]

Ale to se nějak dostává do obliby teďka, někteří lidi nás přesvědčují, že NetworkManager musí obsahovat vlastní implementaci DHCP klienta.

[stativ]

No asi jsem měl napsat BSD-style initscripts + udev + syslog-ng + CK + ..., zkrátka, maintaineři stejně tak jako tak nabízeli jen jednu možnost.

To proto, že na udržování X init systémů není dost sil. Muset měnit init za jiný mimo jiné proto, že pokud tak neudělají upstream hned několika velkých projektů, které by s initem neměli mít nic společného se na nás v budoucnu vybodne není dobré. Někde jsem narazil na návrhy vyměnit v Archu init za OpenRC (a jiné), ale nikdo to není ochotný udržovat i s ohledem na to, že by to sice byl lepší init, ale problém s podporou jiných projektů by přetrval.

[pavlix]

Pokud byste se uměji třeba spojit s Gentoo a vylepšit jejich build systém na tolik, abyste na něj mohli přejít, tak byste byli za vodou a udržovali byste si pouze změny oproti tomu, co udržují oni.

[stativ]

Já si na udržování OpenRC netroufám, a ani nikdo jiný se do toho nehrne. Zatím budu držet initscriptů, dokud se to nerozbije úplně. Nakonec stejně asi budu muset odhodit své ideje o jednoduchém initu a přejít na systemd.

[stativ]

To, že initscripty stály za nic jsem už tu myslím někde psal. Ale měnit něco špatného za něco jiného, ale také špatného nedává moc smysl. Krom toho initscripty dělaly jen to, co měly – init. Kdežto vývojáři okolo systemd evidentně trpí silnou formou Not Invented Here syndromu, a proto reimplementují spousty věcí, které s initem nemají společného vůbec nic. Jako klidně ať si dělají vlastní verzi chrootu, ConsoleKit, rm, ale laskavě by to nemuseli cpát do initu a nutit to všem.

Jinak co se týče neaktualizovaného bordelu – můžeš být trochu specifický?

[stativ]

Alespoň ale ty spousty zduplikovaných utilit jsou samostatné binárky.

Když se to tak vezme, systemd má oproti jiným moderním initům jen jednu, a to nezanedbatelnou, výhodu – jeho budoucí vývoj je, troufám si říci, zaručen.

[pavlix]

jeho budoucí vývoj je, troufám si říci, zaručen.

Krátkodobě ano.

[kralyk z abclinuxu]

Jinak co se týče neaktualizovaného bordelu – můžeš být trochu specifický?

Ta poznámka se týkala upstartu. Už je to ale dlouho, takže se nepamatuju, v čem byl přesně problém, ale nejspíš neexistence skriptů, v podstatě to je DIY.

[stativ]

Aha, špatně jsem tě pochopil. Myslel jsem, že mluvíš o initscriptech. Ono každý alternativní init je v podstatě DIY, svého času takový byl i systemd.

[pavlix]

V debilním freedesktop, který se vykašlal na debilní ConsoleKit a v debilním GNOME, jehož některé části (už nevím jaké, protože GNOME je mi ukradené) měli bez ještě debilnějšího systemd nějaké problémy.

Ale skvělý Arch, jehož maintaineři ani pokročilí uživatelé (jichž je tam jistě většina) nemají zájem se zapojit do vývoje open source software, který používají, ani ve formě povídání si s vývojáři v bugzille.

Co jsem trochu zjišťoval, tak Gnome bude řešit primárně systemd a consolekit bude fungovat jen do té doby, dokud bude poskytovat potřebná API.

Aha, odtud vítr vane. My nejsme Gnome a rozhodnutí, která padnou v Gnome nemají na NetworkManager přímý vliv.

[stativ]

Ale skvělý Arch, jehož maintaineři ani pokročilí uživatelé (jichž je tam jistě většina) nemají zájem se zapojit do vývoje open source software, který používají, ani ve formě povídání si s vývojáři v bugzille.

Kecy.

Aha, odtud vítr vane. My nejsme Gnome a rozhodnutí, která padnou v Gnome nemají na NetworkManager přímý vliv.

Díky za info. V tom případě jsem rád, že tomu tak je.

[pavlix]

Kecy.

Chápu, že je něco takového pro tebe nestravitelné.

Díky za info. V tom případě jsem rád, že tomu tak je.

Ale samozřejmě mají vliv nepřímý. Takže pokud se o vývoj NetworkManageru budou zajímat převážně Gnomácí, bude se NetworkManager samozřejmě řídit jejich světonázorem, protože žádný jiný nebude v rámci aktivní komunity existovat.

[stativ]

Chápu, že je něco takového pro tebe nestravitelné.

Samozřejmě, že je. Skoro není dne, kdy bych někde nějakou chybu nehlásil a ostatní trusted useři/developeři jsou na tom dost podobně.

[pavlix]

Aby bylo jasno, měl jsem v tomto případě namysli konkrétní projekt, démona pro síťovou konfiguraci jménem NetworkManager.

[stativ]

Tak to máš říct hned, nebo mi kup křišťálovou kouli. Krom toho – nenapadlo tě, že třeba nikdo z vývojářů s NM problémy nemá?

Když jsem teď narychlo projel bugreporty co se týče NM v Archu, jen jeden z nich je bug přímo v NM, a ten je v upstreamu reportovaný, zbytek se týká balíčku, nebo jsou to staré mizerné reporty, u kterých dotyčný nejspíš zemřel . A když projedu mailing list, tak jsou tu problémy způsobené špatným nastavením a v jednom případě zřejmě špatným HW.

[pavlix]

Tak to máš říct hned, nebo mi kup křišťálovou kouli.

Připadalo mi to zřejmé z kontextu, který jsi ty sám nastavil. I bez křišťálové koule.

Krom toho – nenapadlo tě, že třeba nikdo z vývojářů s NM problémy nemá?

Nikdo z vývojářů čeho? Já až tak moc neřeším, kdo je kdo. Každopádně ty se tváříš, jako by runtime výběr mezi ConsoleKitem a SystemD byla klíčovou vlastností a že „debilní“ NetworkManager to nezvládá. Já tě upozorňuju na to, že se nám teprve nedávno ozval první člověk, kterého to vůbec zajímá, vývojář jakési distribuce Panorama, o které slyším poprvé.

Což mimo jiné nese informaci, že existují lidé, kteří místo nadávání něco dělají.

Když jsem teď narychlo projel bugreporty co se týče NM v Archu, jen jeden z nich je bug přímo v NM, a ten je v upstreamu reportovaný, zbytek se týká balíčku, nebo jsou to staré mizerné reporty, u kterých dotyčný nejspíš zemřel . A když projedu mailing list, tak jsou tu problémy způsobené špatným nastavením a v jednom případě zřejmě špatným HW.

Výborně, takže už se bavíme o konkrétních věcech. Dobře, beru zpět, jeden bugreport se našel. Možná se najde i druhý. Ne že by to byla nějaká závratná aktivita.

Nicméně pořád platí to samé, v jakém duchu tu celou dobu píšu. Pokud chcete, aby byl NetworkManager pro vás použitelný, zapojte se alespoň do jeho plánování tím, že podstatné věci pošlete podle jejich povahy do bugzilly nebo na mailing list. Komu stačí, aby NM vyhovoval mainstreamu a pracoval s mainstreamovými nástroji, tak tuhle radu nepotřebuje.

[jyrki]

Jaky je rozdil ze to jde realne dost poznat? Ale opravdu, i kdyz bude start delsi o 10-30 sekund, je to fuk.

[pavlix]

Jak komu, jak u čeho.

[kralyk z abclinuxu]

No asi takovej, že stlačim power button na laptopu a chystám se udělat si čaj... a hele, von najednou Slim, a přitom jsem ještě ani nedal vařit vodu...

[Limoto]

Já jsem systemd nahodil taky pár dní zpátky a na první pokus všechno šlape, akorát hibernační hooky budu muset předělat. Ale štve mě, že tomu prostě nerozumím. Funguje to, ale ve chvíli, kdy to fungvat přestane, nemám páru, co kde hledat. Ty init skripty byly neprůstřelný. A taky krásný, když to teď vidím botoovat, není to pro mě Arch...

[lamka]

Aktuální zkušenosti se systemd:

• instalace rekonfigurovaného zavaděče lilo selhala, protože chyběla zařízení v /dev a systemd se odmítá spustit v chrootu Pomohlo až spuštění udevd z klasického initscriptu /etc/rc.d .
• Přes systemctl povolena služba pro laptop mode. Mezi tím balíček laptop-mode-tools odinstalován, systemd pokaždé řve že službu nemůže najít ale nenašel jsem způsob jak ji zase čistě zrušit, protože systemctl delete/disable selhává kvůli neplatnému symlinku, který si předtím sám vytvořil. Pomohlo až ruční smazání v /etc/systemd.
• Podle dokumentace správně nastavené klávesnice a font pro konzoli v /etc/vconsole.conf, ale font nabíhá defaultní který tam cpe KMS, který je mrňavý a na mým displeji skoro nečitelný. Jal jsem se vystopovat příčinu, leč snažení zastavilo následující:
  

  file /lib/systemd/systemd-vconsole-setup 
  /lib/systemd/systemd-vconsole-setup: ELF 64-bit LSB executable,
  x86-64, version 1 (SYSV), dynamically linked (uses shared libs),
  for GNU/Linux 2.6.32, BuildID[sha1]=0xb6e136b1347252538039ea6e7ea91e87d78dfb43, stripped

  
  Blob Normálně bych si pročetl shellový initscript, případě doplnil o trasovací výstupy do logu, ale shánět někde C zdroják a louskat ho je neskutečný opruz, na který kašlu.

Tak posílám jeden fakáč autorům systemd ...

[Jinan Dvoulaločný]

Podle dokumentace správně nastavené klávesnice a font pro konzoli v /etc/vconsole.conf, ale font nabíhá defaultní který tam cpe KMS

Tohle jsem řešil a vyřešil. Otevři si /etc/mkinitcpio.conf, do proměnné MODULES hoď modul pro svou grafickou kartu - bez toho ti pozdější inicializace KMS přepíše nastavení konzole. Do HOOKS přidej někam ke konci "consolefont" a rebootni.

[lamka]

Jj, díky. Do init ramdisku nacpat modul pro grafárnu, v mým případě intelácký i915. Už na to na arch forech taky někdo přišel. Ten hook na consolefont jsem tam už měl, tím to nebylo.

[pavlix]

Blob Normálně bych si pročetl shellový initscript, případě doplnil o trasovací výstupy do logu, ale shánět někde C zdroják a louskat ho je neskutečný opruz, na který kašlu.

Tvá distribuce nedodává kompletní zdrojové kódy v případě potřeby?

[stativ]

Rozhodně se ale lépe čte rm -rf /tmp/*, než zjišťování, co je v té pitomé stořádkové funkci, která má dělat to samé co rm -rf špatně, protože maže jen některé soubory.

[pavlix]

Rozhodně se ale lépe čte rm -rf /tmp/*, než zjišťování, co je v té pitomé stořádkové funkci

Pokud potkáš někoho, kdo na toto píše stořádkovou funkci, tak ho vem lopatou.

[stativ]

To bych nejraději udělal, protože jde o vývojáře systemd.

[pavlix]

To tohoto vlákna už nebudu dále přispívat, abych nebyl obviněn z navádění k trestnému činu.

[lamka]

Tvá distribuce nedodává kompletní zdrojové kódy v případě potřeby?

Zaprvé shánět zdojové soubory, které samozřejmě jsou u Archu k dispozici, _je_ práce navíc (abs <snad> core/systemd) a navíc se modlit, jestli je to opravdu ta samá verze/vydání ze který to bylo sestaveno. Zadruhé, a to především, je obecně nesrovnatelně složitější hledat chybu ve zdrojáku C/C++ než v shellscriptu.

[pavlix]

Zaprvé shánět zdojové soubory, které samozřejmě jsou u Archu k dispozici, _je_ práce navíc (abs core/systemd)

Ale samozřejmě. Já netvrdil, že to k člověku přiťape samo.

a navíc se modlit, jestli je to opravdu ta samá verze/vydání ze který to bylo sestaveno.

Tak verzování ve Fedoře docela zvládají, pokud je s tím v Archlinuxu problém, možná by se mohli něco přiučit.

Zadruhé, a to především, je obecně nesrovnatelně složitější hledat chybu ve zdrojáku C/C++ než v shellscriptu.

Je to obecně o něco složitější. Na druhou stranu to pořád může být jednodušší než hledat každou chvíli chybu v jiném initskriptu z jiného balíku. Je to něco za něco.

[lamka]

ad 2. odst.) Repozitáře Archu se rychle mění a není nepravděpodobný, že zdrojáky budou už k novějšímu releasu než mám nainstalovaný. Jistě že si to můžu ověřit, ale je to další opruz navíc.

ad 3. odst.) Podle zkušeností se SysV init/BSD init systémy i s kóděním v C/C++ toto považuju stále za nesrovnatelné. Pokud tomu dáváte ekvivalenci, nemá cenu se dál bavit.

[pavlix]

ad 2. odst.) Repozitáře Archu se rychle mění a není nepravděpodobný, že zdrojáky budou už k novějšímu releasu než mám nainstalovaný. Jistě že si to můžu ověřit, ale je to další opruz navíc.

Fedoří balíky mají v názvu verzi a build, stejně jako zdrojové balíky, tudíž se nelze splést, pokud si ty zdrojáky před lokálním buildem nepřepíšeš sám.

ad 3. odst.) Podle zkušeností se SysV init/BSD init systémy i s kóděním v C/C++ toto považuju stále za nesrovnatelné. Pokud tomu dáváte ekvivalenci, nemá cenu se dál bavit.

A jéje, nedej bože, abych si dovolil mít jiný názor :). Nedávám mezi to žádný druh rovnosti či nerovnosti, považuju to za nerozhodnuté. Ale obecně dávám přednost opravování chyb na jednom místě před opravováním chyb na padesáti. A stejnětak bych dal obecně přednost opravě padesáti krátkých konfiguračních souborů před padesáti free-form skripty. Což ovšem neznamená, že jedna vybraná zkušenost nemůže zanechat opačný dojem.

[Jendа]

instalace rekonfigurovaného zavaděče lilo selhala, protože chyběla zařízení v /dev a systemd se odmítá spustit v chrootu Pomohlo až spuštění udevd z klasického initscriptu /etc/rc.d .

mount -o bind /dev /mnt/windows/dev

[=^..^= AmigaPower®]

Agnieźka Chylińska anglicky... (yt)

[lokki]

So systemd som mal 2 skúsenosti. Prvú na Archu, ktorý som mal vtedy nainštalovaný a bola už možnosť systemd vyskúšať (nejaký rok a pol dozadu) a potom ešte na Fedore. Dojem som mal z toho taký, že keď to fungovalo, bolo to super. Keď som ale pátral prečo nejaká služba beží/nebeží bol som nahraný. Nič sa nedalo nikde zistiť. Dokumentácia už možno pokročila, ale aj tak mi príde ten systém uletený. Obetovať rýchlosť štartu za stratu jednoduchej a prehľadnej kontroly o tom, čo mi v systéme beží a štartuje je podľa mňa zlý obchod. Práve hľadám nové distro na pracovnú mašinu namiesto Ubuntu 12.04, ktoré je u mňa nestabilné (+ upstart ) a ako posledné z distier, ktoré sa držia starých princípov a sú aj stabilné sa mi vidí už len Slackware.

[alfons]

Ubuntu 12.04 je nestabilní? hm, tak to tedy netuším co máte za počítač. Stroje, kde jsem nasadil 12.04, tak se všechny jeví 100% stabilně včetně uspávání a práce. Můj pracovní notebook má nyní 6 dní uptime - 3.2GB paměti v RAM (celkem mám 8) zabráno, spuštěno od začátku Eclipse, Rhythmbox, množství oken s Nautilusem/Terminalem, FreeCAD a Blender na vedlejší ploše a sem tam BricsCAD, Gedit, nějaká okna v calcu/writeru a s tím, že do toho zapínám a vypínám Firefox. do toho někdy nějaký virtuální stroj ve virtualboxu např pro testování ERP/PLM a win v případě potřeby nějaké app.

V každém případě si myslím, že současné 12.04 je nejvíce stabilní vydání hned po 8.04 co se týče desktopu. Používám Unity a je vcelku použitelné a má plno vychytávek, na které si lidé okamžitě zvyknou.

Dle mého možná opravdu systemd má co nabídnout, ale doufám že se ubuntu zatím bude držet upstartu, který funguje v pohodě i s uspáváním.

[lokki]

Je to síce mimo misu ohľadom systemd, ale odpoviem na to Ubuntu 12.04. Používam ho na pracovnom stroji ako "developer workstation" pre javu (všetok hw je intel, 8GB RAM). Potrebný software funguje, ako píšete unity má pekné vychytávky a dalo sa naň zvyknúť. Ale niektoré aplikácie mi už neraz spôsobili zamrznute systému, kde pomohol len trvdý reštart (sqldeveloper, netbeans...). Je tam kopa drobností, ktoré pri dlhodobejšom používaní neskutočne otravujú: emapthy zvykne padať, občas divne zobrzuje/nezobrazuje okná s konverzáciami, unity je niekedy príšerne pomalé - napríklad zobrazovanie dash... nespomeniem si hneď teraz na všetko. Napriek tomu je to zatiaľ jediná distribúcia z tých čo som skúšal, ktorá je kompromisom stability a relatívne nového software a umožňuje mi robiť moju prácu. No nevzdávam sa a hľadám ďalej

[alfonz mucha]

no vím, že některé problémy, které se vyskytují s pomalostí unity se soustředí převážně na intel grafiku, jelikož na strojích, kde máme nvidie obvykle problémy s pomalostí/zatuhnutím/nějakým špatným překreslením (zejména hry, kde intel blbne) nejsou (může to na druhou stranu znamenat, že unity je náročné).

Ovšem to by nenaznačovalo tomu, že 12.04 mi zatím využívá notebook nejlépe co se týče výdrže na baterii a i výkonu.

Jinak již tak 7-10 den musím systém restartovat, aby se probudil .(dle mého to hlavně souvisí množstvím otevíraných a uzavíraných aplikací a uspáváním, případně nekvalitou grafických ovladačů)

Bohužel empathy nepoužívám, tak zde nedokážu odpovědět.

[stativ]

Pokud nepoužíváš něco, co natvrdo vyžaduje systemd, tak můžeš stále vesele používat initscripty. Sám bych je chtěl, až se na ně Tom s Davem vykašlou, udržovat co nejdéle to půjde.

A protože čekám, že se zase objeví nějaký blb, který bude obviňovat vývojáře z Archu za to, že se rozhodli používat systemd jen aby uživatelům trochu zavařili, znovu upozorňuji, že GNOME a NM systemd vyžadují natvrdo a vývojáři consolekit/polkit se rozhodli vykašlat na consolekit a používat systemd taky. Rozhodnutí se zaměřit na systemd je tedy logické vyústění toho, že vývojářů je příliš málo na to, aby udržovali dva init systémy.

Bohužel se mi vůbec nelíbí, kam linux směřuje. Mít systém bez systemd se stává čím dál tím obtížnější, protože třeba ti idioti co vytváří desktopové prostředí pro idioty si usmysleli, že budou vyžadovat systemd-logind. A bohužel nejde jen o systemd. Kde je ta doba, kdy jsem bez problémů provozoval systém s initNG a vedle Slackware s BSD-style initem.

[alfons]

máte nějaké bližší informace jak to bude se systemd vs GNOME a NM, jde mi teď hlavně o to, jestli se mám připravit, že brzo bude muset být i v Ubuntu a tedy následně bude Ubuntu muset vyhodit upstart?

[stativ]

Vzhledem k tomu, že Ubuntu GNOME nepoužívá, tak tam moc velký problém nevidím. NM se zatím dá zkompilovat s podporou consolekit, takže tady zatím problém také není. Ale až tu podporu vyhodí, což se dříve či později stane, tak budou muset patchovat.

[alfons]

Unity > Sledování systému (Systém) Vydání 12.04 (precise) 64 bit jádro Linux 3.2.0-32-generic GNOME 3.4.2

?? ale i tak to dále souvisí s udev/D-Bus a další... Myslím, že to bude asi brzo nutné převést na systemd...

[pavlix]

Ale až tu podporu vyhodí, což se dříve či později stane, tak budou muset patchovat.

Nebo by nedej bože museli předstírat, že je NetworkManager zajímá :).

[stativ]

Tím myslíš to, že NetworkManager nepoužívají, nebo že si s ním hrají na svém vlastním písečku?

[pavlix]

Tím myslím to, že ho pouze používají a neúčastní se vývoje ani tím, že by napsali blbej bugreport, zatímco z mnoha jiných distribucí nám chodí, světě div se, dokonce i patche.

[pavlix]

máte nějaké bližší informace jak to bude se systemd vs GNOME a NM

Moje informace jsou takové, že NetworkManager dodává svůj unitfile a používá volitelně systemd na pár dalších věcí.

[flame]Zda a v jaké formě budou k dispozici alternativy, závisí téměř výhradně na odborné části uživatelské komunity (tedy na lidech, jejichž technické znalosti umožňují používání bugzilly nebo mailing listu).[/noflame]

[jyrki]

Ne, nepouzivam nic co systemd vyzaduje, ale v budoucnu to asi bude jine viz DBus a udev.

[nyan]

Pokud nepoužíváš něco, co natvrdo vyžaduje systemd, tak můžeš stále vesele používat initscripty. Sám bych je chtěl, až se na ně Tom s Davem vykašlou, udržovat co nejdéle to půjde.

Taky jsem si myslel, nez jsem zkusil update Archu s vynechanim systemd. Odmitlo to updatnout skoro pulku KDE 4.9.2 na nake zavislosti (uz nevim ktere).

Jo btw bye bye syslog

[kralyk z abclinuxu]

Jo btw bye bye syslog

To se na Archu napraví takhle: systemctl enable syslog-ng

[stativ]

V KDE na systemd nic nezávisí. I pokud používáš testing – v tom případě ale bez systemd (nebo vlastní kompilace kdebase-workspace) nefunguje mountování pod uživatelem a NM applet.

Tedy pokud pokud jsi zakázal nahrazení udevu/systemd, tak možná nějaký problém bude. Ale to, že udev byl nahrazen systemd neznamená, že se systemd automaticky začne používat pro boot.

[pavlix]

NM applet.

K čemu KDE potřebují systemd pro jeden applet?

[stativ]

Tak na to nedokážu přesně odpovědět.

Zřejmě i ten applet potřebuje nějaká zvýšená práva, aby byl schopný nějak s NM mluvit, a to bud pomocí ConsoleKit nebo systemd-logind. Když jsem nabootoval pomocí klasického initu do KDE s odstraněnou podporou CK, applet zobrazoval, že není schopen komunikovat s NM. Když se systém nabootoval pomocí systemd, tak applet fungoval. Když se KDE překompilovalo s podporou CK a bootovalo se pomocí normálního initu, applet fungoval taky.

[Josef Kufner]

Pokud vím, Network Manager a všechny tyhle věci komunikují přes dbus právě proto, aby práva nepotřebovaly.

[stativ]

No, ale nějak se musí domluvit na tom, zda uživatel má vůbec právo komunikovat, ne?

[Josef Kufner]

To je v konfiguráku dbusu.

[pavlix]

Zřejmě i ten applet potřebuje nějaká zvýšená práva

Zajímavé, že originální nm-applet ani gnome-shell to nepotřebují. Nicméně tohle opravdu stojí za bug report na KDE a buď odkaz do NM mailing listu nebo zjistit více informací a případně zadat bug report i na NetworkManager.

[nyan]

V KDE na systemd nic nezávisí.

Ehm...

pacman -Qi libgbm
Depends On     : systemd-tools
Required By    : libegl

pacman -Qi libegl
Required By    : kdebase-workspace  libva

pacman -Si systemd
Provides       : libsystemd=195  systemd-tools=195  udev=195

Jiste, primo na nem nezavisi, akorat ho nejde updatnout bez instalace systemd...

[stativ]

Nezapomínej na to, že udev == systemd == systemd-tools.

[nyan]

Me jsou ty zavislosti jasne. A dekuji za tu rovnici, myslim ze dost jasne ukazuje, ze oba vase predchozi tvrzeni "Pokud nepoužíváš něco, co natvrdo vyžaduje systemd, tak můžeš stále vesele používat initscripty" a "V KDE na systemd nic nezávisí" totalni fikce (mluvime-li o Archu).

[stativ]

Pokud to bereš takhle, tak fikce je to úplně všude s výjimkou nějakých embedded systémů, které nepoužívají udev.

[nyan]

Ano, a pritom stacilo NEudelat takovou vec jako spojit tri balicky do jednoho. Vrele diky Archu..

[stativ]

Spíš vřelé díky upstreamu. To , že to dřív bylo rozděleno na tři balíčky byla věc specifická pro Arch.

[pavlix]

Neustále se tu omýlá jako výhoda Linuxu a open source - freedom of choice.

To vysvětli svým Archerům nebo přejdi na Gentoo :).

Dle trendů a provázanosti systemd s dalšími projekty se to vyvíjí že bude na výběr se systemd smířit nebo "zemřít".

Vše závisí na lidech. Pokud lidé být bez systemd nechtějí a tu provázanost přijmou, tak to pro ně dopadne tak, jak píšeš :).

Tak kde je ten freedom of choice?

Je na každém kroku. Například teď máš možnost zkusit se vyhnout systemd, najít distribuci, která na něm není závislá, seznámit se s jejím fungováním a zapojit se do vývoje.

Hlavním přínosem přechodu na systemd pro linuxové distributory je jednoduchost a jednotnost unitfiles oproti initscriptům. Pokud už nebude nikdo ochotný skripty udržovat, projekty se pravděpodobně o unitfiles postarají samy a distribuce si je jen v případě potřeby patchnou.

Tedy jsi přesně v té fázi, kdy se projevuje svoboda výběru :).

[jyrki]

To vysvětli svým Archerům nebo přejdi na Gentoo :).

Vysvetlit to Archerum jaksi nejde. Gentoo nechci, preferuji software v binarni podobe.

Vše závisí na lidech. Pokud lidé být bez systemd nechtějí a tu provázanost přijmou, tak to pro ně dopadne tak, jak píšeš :).

Uzivatelu se nikdo nepta, ve chvili kdy bez systemd nebude mozne pouzit DBus, udev, skonci u systemd vsichni at chteji nebo ne. A ktery desktop nepouziva DBus a udev?

[pavlix]

Vysvetlit to Archerum jaksi nejde.

To už je ovšem problém té které distribuce.

Gentoo nechci, preferuji software v binarni podobe.

Sabayon.

Uzivatelu se nikdo nepta,

Dobře, že sis toho všiml, to je první krok k úspěchu. Je jasné, že většina vývojářů nebude obcházet uživatele a kopat do nich, ať se zapojí.

Uzivatelu se nikdo nepta, ve chvili kdy bez systemd nebude mozne pouzit DBus, udev, skonci u systemd vsichni at chteji nebo ne.

Pokud máš pocit, že toto hrozí, tak se s tím buď smiř, nebo s tím něco dělej :).

[jyrki]

Díky za tip na Sabayon, vypadá dobře - openrc, rolling release, dostatek software v repozitari, aktualni soft...velmi slibna nahrada Archu

[pavlix]

Netušil jsem, že ho neznáš. Bylo mi potěšením.

[Dadam]

1. Používáš GNU/Linux. Odkdy ti v něm funguje něco, o čem si dřív nemusíš něco zjistit?
2. Používáš bleeding edge distribuci. I na stránkách systému (nebo wiki, to je jedno) najdeš, že vše nemusí za všech okolností dobře fungovat.

3. Systemd nechápu a nefunguje mi.

   Nemyslíš, že druhé plyne z prvního?
4. Jestli se ti Arch nelíbí, běž jinam, TO je svoboda volby. Nebo udržuj initscripty, to je taky svoboda volby. Nebo přejdi na LFS, tam nebudeš závislý na ničích rozhodnutích.
5. Přečti si Are We Removing What Defines Arch Linux?

Ze zmíněného článku si dovolím dvě citace:

When I was reading the old reviews, every time I saw mention of Arch Linux using the latest innovations in the Linux world, I started wondering why we are not using systemd already? Here I have only (partially) refuted the downsides of systemd, not pointed out what I can see are some quite substantial benefits. I personally think the historic rapid adoption of new features should continue in Arch Linux.

a druhá:

It is written by Lennart Poettering

I have no idea how this ever became a “genuine” argument against systemd, but almost any discussion involving systemd ends up being about Lennart also writing pulseaudio. Maybe we need an updated version of Godwin’s Law for this situation… Any time an argument reaches this point, I know all things technical are out the door and I stop following.

[Jinan Dvoulaločný]

Ten odkazovaný článek je pěkný, ale mně se víc líbí tenhle komentář pod ním.

ad 4) V případě LFS si sice distro sestavuješ sám, ale rozhodnutí upstreamu tě budou stejně svazovat. Dokonce víc, protože na to všechno budeš sám.

[gtz]

No my co máme Suse jsme byli systemd obštastněni již před nějakou dobou. Nadával jsem a pak jsem si zvykl.

[belisarivs]

Ja jsem zase zanadaval a utekl jinam.

Maji co chteli.

[gtz]

Jsem již moc navyklý na yast, zypper apod. a přemýšlel jsem o Fedoře, ale prozatím jsem to nechal tak jak je.

[jozka]

Ja si nezvykl. A mysql rozjet nemuzu porad

[gtz]

já to řešil u známého a tam mysql stále řvalo "missing service file" tak jsem to nastavil přes yast (služby/system services). V něm jsem dal "enable service" a pak "start service".

Popř. přímo

zypper install mysql-community-server mysql-community-server-client
systemctl enable mysql.service 
systemctl start mysql.service

[Begleiter]

Dnes jsem přešel na systemd (Arch Linux) a řešil jsem zatím jediný problém -- totiž, že obsah konfiguráku /etc/vconsole.conf "nebyl brán na vědomí". Projevovalo se to tak, že se v textovém režimu nepoužil mnou nastavený font, ale nějaký výchozí. Po přečtení jedné diskuse (bohužel nemám odkaz) jsem vyzkoušel přidat do "initramfs" jaderný modul "radeon" (mám grafickou kartu s čipy od AMD/ATI), a už to funguje!

[Begleiter]

A na notebooku HP ProBook 4530s to je jaderný modul "i915".

[kotyz]

Tohle "milovníky" systemd s Archem asi moc nepotěší: consolekit replaced by logind...

Any package that previously depended on it now relies on systemd-logind instead. That means that the system must be booted with systemd to be fully functional.

[kotyz]

Dobrá zpáva pro uživatele KDE: kdebase-workspace-consolekit 4.9.2-1...

kdebase-workspace with ConsoleKit support for non-systemd systems