Linuxový desktop: Co vám chybí

Jiří Eischmann z desktopového týmu Red Hatu se v příspěvku Linuxový desktop: Co vám chybí na svém blogu ptá, co uživatele na Fedora Workstation a na linuxovém desktopu obecně trápí a co by desktopový tým mohl zlepšit. Pokud máte nějaké podněty, napište mu je do komentářů.

25.4.2017 11:11 | Ladislav Hagara | Komunita

Komentáře

[BFU]

sysvinit

[Daniel]

+1

[mica]

+3,14159265

[run]

ses

[mica]

Nebudu přece troškařit, ne?

[AlYoSHAa]

+1

[Tomáš Bžatek]

+1

[jiri.one]

+1

[Conscript89]

Ten tam uz hodne dlouho nebyl, Fedora pouzivala afaik upstart.

[Pavel 'TIGER' Růžička]

A co to má společného s odpovědí na otázku?

[martin.k]

jenze ho nepouzivala jako upstart, ale jako sysv init...

[GeorgeWH]

+1

[GeorgeWH]

ale nie, robim si srandu. este stale pouzivam debian wheezy.

[Daniel]

#sysvinitstillrules

[Lolik]

sysvinit je mrtví, tak už to konečně příjměte.

[Pavel 'TIGER' Růžička]

Bude mrtev teprve tehdy, až bude mít lepší náhradu.

[pet I.]

Ta je: OpenRC.

[Pavel 'TIGER' Růžička]

Pravda, ale nevidím důvod, proč by měl sysvinit být mrtev, když žije minimálně jedna slabší varianta.

[lnykryn]

Teda mozna se pletu, ale OpenRC neni init, ale v podsate nahrada za klasicke initscripty. Dokonce na gentoo je myslim defaultni setup sysvinit+openrc.

[antisračk]

jdi svinit něco jiného

[Petr Tomášek]

+1

[ika]

+1

[cezz]

Ja som naopak vdacny za kazdy den kedy nemusim riesit nefunkcny init.d skript. Dnes ho vacsinou prinajhorsom prepisem z niekolko stranoveho bash monstra do 10 riadkov konfiguracie..

[ika]

Přepíšu 10 řádků konfigurace. A pak se jen divím, že je služba mrtvá, přestože si systemd myslí, že je živá. A do toho se motají logy plné kryptografických hlášek, podivné timery, desítky služeb, které dělají bůhví co, posílají cosi kamsi, natahují kernelové moduly neznámé, nezdokumentované nebo zbytečné funkce. A dokumentace k těm services, sockets, paths a timers nula nula nic. Moloch, který ovládá celý systém a který normální admin nemá pod kontrolou. A arogantní parta fedoráckých redhatistů, kteří ostrakizují každého, kdo si dovolí protestovat.

[GothiqueNoir]

presne ako vo Windowse

[ika]

Bohužel podobnost není náhodná.

[lin]

Je možné, že linux byl před deseti lety méně uživatelsky příjemný. Muselo se více nastavovat v konfiguračních souborech.

Na druhou stranu, pokud jsem nastavil xorg.conf a zapnul PC bez monitoru, nic se nedělo. Dnes s autodetekcí systém bez monitoru ani nenajede.

Jako uživatel CentOS jsem rád za dokumentaci od RH.

Jenomže tato dokumentace je ve skutečnosti "mýdlová opera", vata, výplň papíru, obecné plky.

Takže bych uvítal skutečně dobře zpracovanou dokumentaci.

Nejhorší je to u systemd a k SELinuxu a sssd a...

Obojí je zřejmě těžce utajováno.

[Boguš]

Že by? Jsem myslel, že Red Hat utajuje jen bugy a tu svoji bázi znalostí (tam teda stačí k odtajnění zaplatit).

[kolemjdouci]

No vždyť. A vzhledem k tomu, že plná dokumentace k systemd není ani po zaplacení, tak je jasné, do které kategorie spadá.

[Kamil Páral]

Určitě jste se díval do manových stránek? Protože systemd mi přijde jako nejlépe zdokumentovaný nástroj v celém běžném systému. Ty manové stránky jsou rozsáhlé, mají příklady, je jich kopa, a jsou logicky napsané. Aktuálně mám v systému 157 manových stránek začínajících na systemd.

[Rezza]

A to si dovolujes napsat jako clen arogantní party fedoráckých redhatistů, kteří ostrakizují každého, kdo si dovolí protestovat?

[martin.k]

vtip je ten, ze s rozumnym initem neni potreba 157 man stranek, dokonce ani 57 a vetsina lidi v zasade nepotrebuje zadnou...

[sid]

ano chrobak truhlik to da aj dva riadky. Milujem ludi co v zivote sa nicoho nechytili na tejto urovni ale aj formulu 1 by postavili za maximalne mesiac ved su to len 4 kolesa predsa

[martin.k]

mate v zasobe jenom trapne osobni utoky, nebo i nejaky argument? podle me by mel byt init system jednoduchy a pruhledny. systemd neni bohuzel ani jedno. s initem kdyz funguje, nevim o nem, kdyz se neco polame, dokazu to debugovat a spravit/workaroundovat se znalosti bashe a standardnich nastroju. se systemd, kdyz fnuguje, nevim o nem, kdyz se neco polame, muzu casto tak leda nadavat protoze do te cerne magie nevlezu i kdybych precetl vsech 157 man stranek a par lennartovych blogpostu k tomu.

[smazáno]

https://github.com/systemd/systemd/issues/5644 mluvi za vse

[TM]

To je známý Poetteringův troll. Klid...

[k3dAR]

jako bacha, zadnejch 157man stranek, ale 157man souboru s tim ze kazdy ma nekolik az nekolik desitek stranek ;) takze budes cist tak 1000 terminalovejch stranek rekneme 120x50znaku ;) a pak zjistis ze abys vyresil problem s initem tak to preinstalujes cele a vratis data ze zalohy :)

[Prohnutá nudle]

+1

[chrono]

Linux používam už dlho na nepamätám sa, kedy som mal naposledy problém s nejakým init skriptom.

Len tak mimochodom, mohol by si ukázať nejaký viac stránkový bash init skript, ktorý si prerobil na 10 riadkový systemd konfiguračný súbor?

[Bedňa]

Len tak mimochodom, mohol by si ukázať nejaký viac stránkový bash init skript, ktorý si prerobil na 10 riadkový systemd konfiguračný súbor?

Tieto rozprávky sú novou urban legend.

+1 za sysvinit.

Že koľko zo žiadostí bude vyslišaných? V RH tak 0% No a ešte tie vyhodené prachy za Wayland. Xká už za desatinu mohli robiť to o čom sa Waylandákom sníva a manažér mohol mať z ušetrených prachov barák.

Sa čudujem, že do takýchto zbytočných vecí Jiří ešte púšťa, keď vie že sa nič nezmení.

[Robert Smol]

Zkuste s tou zmenou zacit u sebe.

[Bedňa]

Zkuste s tou zmenou zacit u sebe.

Nemám s tým problém, kde mám začať?

[smazáno]

ale to zase jo - staci, kdyz chces pustit 2 instance nejakeho demona (treba apache nebo nginx)

[Bedňa]

Ďalší urban legend. Už si videl Firejail?

[cezz]

Len tak mimochodom, mohol by si ukázať nejaký viac stránkový bash init skript, ktorý si prerobil na 10 riadkový systemd konfiguračný súbor?

Tak narychlo som zagooglil:

uTorrent init skript (cca 200 riadkov) vs 9 riadkov systemd konfiguracie.

Nie je to uplne fer, lebo ta systemd verzia spusta nejaky extra skript, ale ked sa na ten skript pozries, dal by sa integrovat priamo do service konfiguracie s nejakymi 3 extra riadkami.

Alebo napriklad taky monit. Tam uz ten rozdiel vo velkosti konfiguracie nie je az taky velky, ale so sytemd viem, ze ked stopnem service, tak urcite sa ukoncia vsetky procesy. Tiez sa mi postara o restartnutie v pripade, ze service padne s nejakou chybou. Proste je tam out of the box o dost viac funkcionality ktoru nemusim explicitne definovat.

[little.owl]

+1

[Heron]

Tak ona je otázka, zda by ty rc skripty nešly napsat lépe a zda by pouhé jejich přepsání nepřineslo značnou úsporu. Protože u některých kreací skutečně zůstává rozum stát. Třeba jako u toho utorrentu.

U normálních věcí člověk jen definuje start a stop a je to. Dva řádky, nebo jeden, pokud se při stopu nic extra nemusí dělat. Takže náročnost na napsání rc.v a systemd unity je asi tak stejná (prostě se definuje start / ExecStart).

To, že ty skripty jsou často 200 řádkové cosi vypovídá spíš o kvalitě tvůrců toho software.

Za příklad bych mohl dát třeba minecraft server. To je vyloženě udělané tak, aby to nikdo na serveru nespustil. Léta se to řešilo zavíráním do tmux / screen a posíláním kláves do tohoto prostředí. No a teď z tohoto monstra udělejte službu...

Já jsem to "vyřešil" tak, že mám systemd unitu, napojený unix socket jako stdin a když tomu potřebuju poslat příkaz, tak ho pošlu do socketu. Funguje to, ale že by to bylo bůh ví jak pěkné, to není. Přičemž samozřejmě nejlepší řešení by bylo ten server napsat jako server + klientský ovládací program.

[hypvofxy]

Za příklad bych mohl dát třeba minecraft server.

Kdysi jsem neskutecne ragoval, kdyz mi nejaka starsi verze Minecraft serveru (spustena z jineho adresare) zapsala data primo do ~.

[Heron]

No takovéto věci se pouští buď za samostatného uživatele nebo ve vmku / kontejneru. Ale je to děs. Nemohu se zbavit pocitu, že tyhle programy hřeší na to, že "on to někdo vyřeší".

[Kate]

Ten pocit je nejspíš správný. Minecraft server třeba jen tak nenahradíš, lidi to nějak rozběhnout potřebujou a tak to nějak udělají. A vzhledem k tomu že to nějak funguje, konkurence (prakticky) neexistuje… Proč by se snažili? Co by je motivovalo?

[Kate]

Tedy, existuje. Neexistují už nějakou dobu oficiální servery? To by mě zajímalo, jak to provozují.

[hypvofxy]

Jo, rikaji tomu tusim Realmy.

[little.owl]

Tak ona je otázka, zda by ty rc skripty nešly napsat lépe a zda by pouhé jejich přepsání nepřineslo značnou úsporu. Protože u některých kreací skutečně zůstává rozum stát.

Na to bylo X let v Y ruznych distribucich, a nejak se nedarilo, a pak prisel systemd a mame to na par radcich, chodici na vsech distribucich, ktere ho pouzivaji.

[Bedňa]

a pak prisel systemd a mame to na par radcich,

A máme prvý init ktorý dokáže spadnúť. Tie hacky aby niečo chodilo sú len presunuté zo skriptov v tom blobe, takže sa problém len presunul. Nedejú sa tu žiadné zázraky a ani sa nevyrába hmota z ničoho. Má to jeden problém, že to namiesto komunity ostalo na pár ľuďoch a stojí to za kulové.

Všetky tie hacky sú za roky v init skriptoch a nemusíš ich nijak riešiť a písať 200riadkové bash skripty, stačí ich použiť.

Ďalší Urban Legend.

[hypvofxy]

Aniz bych se vyjadroval k init systemum jako takovym, tve tvrzeni je zcela v rozporu s tim, co je v softwarovem inzenyrstvi povazovano za dobrou praxi. V tomto pripade prenaseni zodpovednosti (vc. pripadnych hacku) na jedno misto:

Tie hacky aby niečo chodilo sú len presunuté zo skriptov v tom blobe, takže sa problém len presunul. Nedejú sa tu žiadné zázraky a ani sa nevyrába hmota z ničoho. Má to jeden problém, že to namiesto komunity ostalo na pár ľuďoch a stojí to za kulové.

A dale:

Všetky tie hacky sú za roky v init skriptoch a nemusíš ich nijak riešiť a písať 200riadkové bash skripty, stačí ich použiť.

Oboji je zcela v poradku danym zpusobem resit. Jestli tam nedoslo k jinym chybam, to uz je druha otazka. Ty zde ovsem nekritizujes konkretne systemd, presto, ze je to tvym zjevnym zamerem, coz tak nejak vypovida o kvalite toho prispevku.

[Heron]

co je v softwarovem inzenyrstvi povazovano za dobrou praxi

Asi nechápu úplně přesně co přesně je v tomto případě považováno za dobrou praxi. Opravdu se někde učí, že je dobré všechny hacky (míněno v negativním slova smyslu) naházet na jednu hromadu?

Já za dobré inženýrské řešení považuji takový návrh, který hacky buď nepotřebuje, a nebo na ně včas a velmi důrazně upozorní. Tj že třeba takový program prostě nepojede, dokud ho někdo neopraví.

Protože ten první postup vede ke stavu, který je například u her, které zcela v rozporu se specifikací pracují s D3D nebo OGL a dohánějí to potom ovladače GPU, které odhadují, co asi tak ta hra chce vykreslit. Bohužel se to dostalo do stavu, kdy autoři software ty chyby ani neřeší a rovnou to hází na bedra vývojářům ovladačů, kteří si ovšem nemohou dovolit to neřešit (což by bylo správné řešení), protože na konkurenční kartě to jede.

Totéž se dělá u toho MC serveru, který je zvykem pouštět v ramdisku (world data), protože ten datový model je tak zprasený, že na normálním disku to nestíhá seekovat. Tím, že se to od počátku vráželo do ramdisku se celý problém jen oddálil.

A toto je třeba důvod, proč nemám rád systemd. Protože může vyvolat velmi nedobré návyky. Však on to systemd vyřeší. Simple nejede, namlátím tam fork. Pošlu tam pipe. Samo to restartne můj proces po pádu, proč se štvát s robustností. Atd.

[hypvofxy]

Vychazim jen z toho, co psal Bedna. Nezminoval zadne konkretni hacky, ktere se drive v init skriptech bezne objevovaly a ted je jednotne (?) resi systemd, a snazil se obhajovat, ze je v poradku, aby ta logika byla rozplzla do Bashovskych skriptu.

Ja tu diskuzi pozoruju jako outsider. Nerozumim Linux internals dost dobre na to, abych si troufl mit v tomto smeru nejak zvlast vyhraneny nazor kterymkoliv smerem. O to vic bych ale ocekaval, ze ti, co ten nazor vyhraneny maji, budou schopni jej podlozit kvalitnimi argumenty.

Ke tvemu komentari:

Opravdu se někde učí, že je dobré všechny hacky (míněno v negativním slova smyslu) naházet na jednu hromadu?

To zalezi. Pokud ho potrebujes na nekolika ruznych mistech (tj. v ruznych init skriptech), tak je lepsi ho presunout na jedno misto a dobre ho zdokumentovat.

Já za dobré inženýrské řešení považuji takový návrh, který hacky buď nepotřebuje, a nebo na ně včas a velmi důrazně upozorní.

Takove reseni by bylo nadrazene mnou uvedenemu reseni (a postupny vyvoj to, v nekterych pripadech, muze umoznit; nejprve hack presunes z N ruznych mist na jedno misto, a pak jej i z toho jedineho mista odstranis uplne).

Zajimaji me fakta, nikoliv neci subjektivni emoce. V predchozim prispevku, na ktery jsem reagoval, ty fakta nevidim. Vidim jen emoce a nedostatecne kvalitni prispevek, ktery otevira prostor pro spekulace (coz jsem presne udelal, abych vyprovokoval kvalifikovanou odpoved). Uvidime, zda se mi ji dostane. O ktere konkretni hacky se jedna? Jsou ty hacky specificke pro systemd, nebo se to tyka i Upstartu a treba OpenRC? Etc.

Muj subjektivni dojem ze systemd je negativni, protoze (razeno dle dulezitosti): 1/ se domnivam, ze projekt takoveho rozsahu/vyznamu je prilis mlady na pouziti v produkcnich systemech (zejmena me nemile prekvapilo zarazeni do konzervativniho Debianu), 2/ vidim/slycham nepekne veci o pristupu autoru, a v neposledni rade, 3/ jsem musel do noci/rana louskat manualove stranky pri migraci naseho serveru z Upstartu na systemd (a neustale jsem narazel na nejake problemy, kde dodnes nevim, nakolik to bylo stresem/nevyspalosti a nakolik nedostatecnou presnosti manpages; v ramci objektivity nezbyva nez predpokladat primarne prvni variantu).

Nicmene, jak jsem rekl, tohle je subjektivni dojem, nikoliv informovany nazor, ktery bych si rad udelal, ale nedostava se mi ho. Subjektivni dojem neni hodny verejne publikace, zvlast ne v pripadech, kdy by cilem mela byt konstruktivni diskuze. Pisu to jen pro uplnost, protoze jinak me nekdo za chvili zacne stavet do role obhajce systemd a bude se dozadovat argumentu, ktere mu vsak nemuzu poskytnout.

[Heron]

Zajimaji me fakta, nikoliv neci subjektivni emoce.

Jenže ony i ty emoce jsou v životě velmi důležité. Člověk není stroj, člověk se nerozhoduje racionálně (potom by byl označen za psychopata), člověk je tvor racionalizující (tedy své rozhodnutí zpět tu lépe tu hůře dokáže obhájit).

A pokud někoho, kdo má zrovna tu smůlu, že na rozdíl o těch ostatních s tím systémem každodenně pracuje, naserete, tak už se s ním jen těžko pohne.

Problém je, že diskuse o sd jsou velmi často čistě emoční. Přijde tam admin, který s tím má nějaký problém (kupodivu proto, že sd používá, nikoliv proto, že chce jen hatovat) a odpovědí je mu buď NOTABUG WONTFIX, nebo v případě české diskuse výsměch o tom, že se nechce učit nic nového. A celá diskuse jde do kopru. Admin na to přijde sám, ale ta pachuť zůstane.

Já nevím, jaké konkrétní hacky má kdo na mysli. To musí odpovědět on. Sám za sebe, používal jsem léta letoucí rc.v a no problemo. Používám na FreeBSD ten jejich systém a no problemo ještě o řád víc (je to čistější, přehlednější, jednodušší).

Používám systemd a už jsem odhalil několik bugů. Nic z toho nebyl show stopper, jako admin si poradím. Ale nad některými bugy zůstává rozum stát. Jak to, že si toho nevšimla kontrola? Jak to, že si toho nevšiml autor? Chci dál používat takový systém? Mám vlastně na výběr?

Protože admin nežije ve vakuu, admin má zkušenosti s mnoha předchozími systémy. Já mám zkušenosti dneska už prakticky desítky milionhodin z běhu různých služeb (stovky systémů, tisíce služeb, hromada let). Ty služby se nějak chovají, nějak (ne)napadají, autoři k nim mají nějaký vztah. Ano, je to opět o těch emocích, spíše bych řekl o šestém smyslu. Prostě se ti do mozku zažere, ok, takhle je to dobře, takhle se to má dělat. Šestý smysl se tvoří zkušeností a na něm je postavené řemeslo.

Potom přejdeš (z donucení) na systém, o kterém ti všichni tvrdí, jak je skvělý a jak je úžasný, ok, tak si něco vyzkoušíš a okamžitě narazíš na problém. A ptáš se, jak je možné, že na to ještě nikdo nenarazil? A potom se jen pročítáš bugreporty a nestačíš se divit, co vše bugzilla snese.

[hypvofxy]

To zaciname sklouzavat uplne jinym smerem, ale budiz.

Jenže ony i ty emoce jsou v životě velmi důležité. Člověk není stroj, člověk se nerozhoduje racionálně (potom by byl označen za psychopata), člověk je tvor racionalizující (tedy své rozhodnutí zpět tu lépe tu hůře dokáže obhájit).

Asi taky zalezi jak ktery clovek a do jake miry. Predevsim jsem ale mluvil o teto diskuzi, kdy me opravdu nezajima, jaky z ceho ma kdo pocit. Ne o tom, ze si pri poslechu hudby zakazuji prozivat emoce.

A pokud někoho, kdo má zrovna tu smůlu, že na rozdíl o těch ostatních s tím systémem každodenně pracuje, naserete, tak už se s ním jen těžko pohne.

Jeho problem.

Já nevím, jaké konkrétní hacky má kdo na mysli. To musí odpovědět on.

Nic jineho neocekavam.

Sám za sebe, používal jsem léta letoucí rc.v a no problemo. Používám na FreeBSD ten jejich systém a no problemo ještě o řád víc (je to čistější, přehlednější, jednodušší). Používám systemd a už jsem odhalil několik bugů.

Pak uvedeni tech bugu muze byt argument proti systemd. V idealnim pripade i s odkazy na GitHub issues. Ostatni si pak muzou udelat objektivni nazor.

Chci dál používat takový systém? Mám vlastně na výběr?

Zase nevidim, k cemu to smeruje. Prirozene chces pouzivat to nejlepsi. Pokud neco nefunguje (a pritom to driv fungovalo), tak je to proste problem toho daneho reseni a muzes jej za to opravnene kritizovat (stejne jako rozhodnuti distribuce takove spatne reseni pouzit).

Ano, je to opět o těch emocích, spíše bych řekl o šestém smyslu. Prostě se ti do mozku zažere, ok, takhle je to dobře, takhle se to má dělat. Šestý smysl se tvoří zkušeností a na něm je postavené řemeslo.

Jaky sesty smysl? Proste mas zkusenosti, tj. znalost moznych reseni a to, cemu se rika hands-on experience. Muzes objektivne posoudit vyhody a nevyhody kazdeho reseni a rozhodnout, ktere je pro dany ucel nejlepsi. Pokud to nejde zcela rozhodnout exaktne formalnimi metodami (coz nejde), bude to zatizene temi emocemi a subjektivnim vnimanim, ale ta odchylka by nemela byt zvlast vyznamna.

Potom přejdeš (z donucení) na systém, o kterém ti všichni tvrdí, jak je skvělý a jak je úžasný, ok, tak si něco vyzkoušíš a okamžitě narazíš na problém.

Proto me zajimaji spis ty fakticke informace nez neci nazor, ze je to skvele a uzasne, popr. to vyzkousim sam. Pokud narazim na konkretni problemy, pak je lze opet pouzit jako protiargumenty. Nevidim, v cem je problem.

[Heron]

Na to bylo X let v Y ruznych distribucich, a nejak se nedarilo

Tak otázkou je, jestli nebylo jen potřeba pořádně prásknout do stolu a konečně nedonutit lidi, aby na tom začali makat. Ten impuls přišel se systemd, ale to nemusí být nutně jeho zásluha.*

Když srovnám rc skripty v FreeBSD a v linuxu, tak tam jistý rozdíl pozoruji. Konfigurace celého systému v jednom souboru, jednotlivé skriptíky jednoduché a čitelné. Vše v bashi (nebo v tom jejich csh).

a pak prisel systemd a mame to na par radcich

Jo OK. Ale taky je potřeba vidět těch pár desítek tisíc řádků v C za tím.

*) Ono taky je asi dobré se zamyslet nad tím, jak tato situace vznikla, protože rc.v skripty v linuxu co si pamatuji z konce 90 let, tak taky nebyly nijak brutálně složité. Takže něco nastalo časem, co tam přineslo ten balast.

[hypvofxy]

To je aspon konstruktivni pohled na vec. Ne se tvarit, ze mit v celem systemu nejake Bashovske bastly je naprosto v poradku.

[martin.k]

nojo, ale treba na bsd init skripty vypadaji tak, ze se nadefinuje do promenne cesta k demonu s parametrama a sourcne /etc/rc.d/rc.subr:

#!/bin/sh # # $OpenBSD: ftpd,v 1.3 2011/12/21 09:26:29 ajacoutot Exp $

daemon="/usr/libexec/ftpd -D"

. /etc/rc.d/rc.subr

rc_reload=NO

rc_cmd $1

krasne, jednoduche, elegantni. proc by tohle nemohlo byt na vsech distribucich, ptam se ja.

[cezz]

No lenze to je jednoduchy, idealny pripad. Co ak napriklad potrebujem definovat zavislost na inej sluzbe?

Povedzme, ze aplikacia zavisi na DB. Systemd ti toto automaticky osetri a vie napriklad korektne zastavit aplikaciu pred tym ako stopne DB. (A opacne, vie spustit DB predtym ako nastartuje aplikaciu)

Ono init skripty sa daju vo vela pripadoch naozaj napisat krasne a na par riadkov, ale potom su tu taketo pripady a zrazu je init skript niekolko stranovy skript v tom lepsom pripade v tom horsom su tam veci ako sleep na 10s kedy dufas, ze sa dovtedy nejaka ina sluzba pri boote nastartuje.

[Heron]

Povedzme, ze aplikacia zavisi na DB. Systemd ti toto automaticky osetri a vie napriklad korektne zastavit aplikaciu pred tym ako stopne DB. (A opacne, vie spustit DB predtym ako nastartuje aplikaciu)

Tohle je sice moc krásné, ale v životě nastávají i složitější situace. Například db a aplikace na jiném stroji. Síť může vypadnout. Databázi je nutno restartovat. Apod.

To znamená, že ta aplikace tak jako tak musí počítat se situacemi, kdy tu db prostě nemá. Buď ji ještě nemá, nebo ji už nemá, nebo ji za chvíli opět bude mít.

Takže nakonec je úplně jedno, jestli db nastartuje dřív jak aplikace, nebo naopak.

Nehledě na to, že systemd nepozná, zda už je ta db nastartovaná a zda může přijímat dotazy. Některé db mají velmi dlouhý recovery proces (nebo check proces) a může trvat klidně i desítky minut, než db připustí první připojení.

Takže systemd tohle sice řeší (a řeší to poměrně elegantně), ale z principu nemůže vyřešit všechny problémy a ta aplikace s těmi problémy stejně musí počítat.

[cezz]

Bol to iba priklad. Samozrejme, ze aplikacia by si mala osetrit nefunkcnu DB. Ked chces, mozes si namiesto DB ako zavislosti predstavit napriklad primountovany filesystem, nastartovany Xserver, alebo nieco podobne. Tu ide o princip, ze take veci sa deju pomerne casto.

Nehledě na to, že systemd nepozná, zda už je ta db nastartovaná a zda může přijímat dotazy. Některé db mají velmi dlouhý recovery proces (nebo check proces) a může trvat klidně i desítky minut, než db připustí první připojení.

To sa da riesit viacerymi sposobmi, ale sluzba vie systemd oznamit, ze je plne nastartovana. Dokonca si vies takto poriesit aj watchdog prostrednictvom ktoreho vie systemd pravidelne kontrolovat stav sluzby.

[Heron]

Tu ide o princip, ze take veci sa deju pomerne casto.

No a v každém konkrétním případě se dá najít lepší řešení bez systemd.

ale sluzba vie systemd oznamit

No, ehm, ale to zase vytváří další zbytečnou závislost na systemd. Aby služba dokázala sdělit systemd, že už je naběhlá, tak musí implementovat minimálně tu notifikační část. Takový plíživý vendor lock in. Nehledě na to, že ta služba může být sice naběhlá, ale ze pět minut sletí a proces zůstane vyset třeba v nekonečném čekání. Takže systemd bude happy, jak mu krásně všechno běží a jak se služby poctivě ohlásily po startu, ale funkční to není.

Apropos, proč jsem si na to po týdnu vzpoměl:

root@rss:~# systemctl status                  
● rss
    State: running                                    
     Jobs: 0 queued                                                                                                    
   Failed: 0 units                         

root@rss:~# systemctl --failed
0 loaded units listed. Pass --all to see loaded but inactive units, too.

Takže všechno krásně běží no ne?

No kdyby všechno krásně běželo, tak bych se s tím komentářem ani nepsal. Takže:

root@rss:~# systemctl status ttrss.service
● ttrss.service - ttrss_backend
   Loaded: loaded (/etc/systemd/system/ttrss.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Sat 2017-05-13 20:15:08 CEST; 16min ago
  Process: 148 ExecStart=/var/www/html/update_daemon2.php (code=exited, status=0/SUCCESS)
 Main PID: 148 (code=exited, status=0/SUCCESS)

May 13 20:15:04 rss systemd[1]: Started ttrss_backend.
May 13 20:15:08 rss update_daemon2.php[148]: PHP Warning:  pg_connect(): Unable to connect to PostgreSQL server: FATAL:

Super ne? code=exited, status=0/SUCCESS

Služba sice havarovala, protože nastartovala o 1s dřív, než se inicializovala databáze, ale prostě SUCCESS.

Ten autor se ani neobtěžuje správně používat návratové kódy procesu. Asi je to moc zastaralý koncept a je potřeba vyvinout exitcodesd-ng, aby to chvíli zase někdo používal.

Ne, problém opravdu není v initu.

[cezz]

No a v každém konkrétním případě se dá najít lepší řešení bez systemd.

Nejaky priklad by nebol? Lepsie riesenie v com? Ze okrem initu budes mat milion dalsich rovnatiek na ohybatka aby si kazdy konkretny pripad osetril?

Takže systemd bude happy, jak mu krásně všechno běží a jak se služby poctivě ohlásily po startu, ale funkční to není.

V tom pripade vies pouzit watchdog, ktory systemd tiez podporuje a ked sa sluzba po dlhsej dobe neozve je povazovana za failed. Osobne si myslim, ze toto uz by mal riesit nejaky monitoring a nie init system - ak teda nie je zlyhanie sluzby sucastou beznej prevadzky. (ak sa teda nebavime o desktope, tam samozrejme BFU nebude prevadzkovat monitorovaci system, ze?)

Rad by som videl tu systemd konfiguraciu pre ttrss, pretoze toto vyzera, ze je (okrem teda zleho navratoveho kodu) aj zle nastavena sluzba. Pokial ma bezat sluzba stale, tak by mala byt nastavena tak, aby ju systemd restartoval aj v pripade, ze sa ukonci s nulou. A opat podotykam, ze systemd umoznuje aby ttrss pockal kym bude databaza ready, cize k takejto situacii vobec nemuselo dojst, keby boli sluzby dobre nastavene, nepripada mi to ako problem systemd.

Ja nevravim, ze systemd je bez chyby, ale 99% problemov co tu ludia pisu je bud zlym nastavenim sluzby, tym, ze ludia nevedia o systemd ani uplne zaklady, alebo ide o chyby ktore sa objavia vo vyvojovej vetve systemd , ale hned je o tom tisic clankov, pretoze "zle zle systemd" generuje vela klikov..

[smazáno]

https://github.com/systemd/systemd/issues/5644#issuecomment-290345033 kvalitka

[cezz]

Tak ten je husty Bolo to v stable release systemd?

Ale inak take bugy sa stavaju, svojho casu napriklad Steam zmazal vsetky uzivatelske data.

[smazáno]

o ten bug nejde, jde o tu lennartovu reakci

[cezz]

Tak ta reakcia bola trochu od veci, to je pravda. Co sa tyka PR nie je Lennart prave genius.

[smazáno]

o to ze byla od veci nejde, jde o to ze nema problem takto lzive odmitnout validni bug report

to se pak clovek uz nedivi, ze systemd je takovy odpad

[cezz]

Nehladal by som za tym umysel, lebo je pravda, ze ten glob naozaj expanduje aj na .., akurat, ze rm ma tieto pripady specialne osetrene a odmietne .. vymazat.

[smazáno]

Je mi jasny, ze ti to nevysvetlim, ale ...

BUGREPORT: systemd mi smazal /

LENNART: NOTABUG. To neni problem.

Po te bouri reakci ze jediny, kdo se takto na unixu chova je systemd proste LP zavre diskusi bez omluvy.

Nastesti to dopadlo tak, ze originalni reporter toho bugu sam napsal fix a pripravil PR a ma byt jako rad ze mu ho zamerguji?!

[Heron]

Hmm, systemd-tmpfiles. To tam, pravda, ještě chybělo... A vlastní implementace rm-rf. Proč ne. Ach jo. Hlavně že mají bugy z 2012.

[Heron]

Ze okrem initu budes mat milion dalsich rovnatiek na ohybatka aby si kazdy konkretny pripad osetril?

Jaká rovnátka na ohejbátka?

Osobne si myslim, ze toto uz by mal riesit nejaky monitoring a nie init system - ak teda nie je zlyhanie sluzby sucastou beznej prevadzky.

Ano, to si myslím, také, potom ovšem nepotřebuji, aby init systém monitorovat běh té služby. Stejně o ní nic nezjistí.

Rad by som videl tu systemd konfiguraciu pre ttrss, pretoze toto vyzera, ze je (okrem teda zleho navratoveho kodu) aj zle nastavena sluzba.

Asi jsem to napsal nevhodně. Já v tomto nepodezřívám systemd. Ten se zachoval správně. Proces se spustil, po chvíli se ukončil s exit code 0 a systemd to správně vyhodnotil jako success. Služba prostě stojí, vše je v pořádku.

Jinak ta unita je trivka:

[Service]
User=www-data
ExecStart=/var/www/html/update_daemon2.php

[Install]
WantedBy=multi-user.target

Na tom není co řešit. Problém je v tom update_daemon2.php, který si naforkuje childy a v každém z nich se pokouší pracovat. Problém je, že jak spadnou childy, tak se hlavní proces ukončí jako exit code 0. Prostě špatně napsané. To už by bylo lepší, kdyby ty workchildy byly volány jako unita Type=oneshot a přes systemd.timer. (Jenže to by zase nesměl být v systemd bug s logováním rychle běžících úloh. Už od roku 2012.)

To, co jsem chtěl tímto příkladem ukázat je to, že pokud se autor ani neobtěžuje vracet správně návratové kódy, tak to stejně žádný systemd nevyřeší.

Pokial ma bezat sluzba stale, tak by mala byt nastavena tak, aby ju systemd restartoval aj v pripade, ze sa ukonci s nulou.

Což považuji za chybu, že tam ta možnost vůbec je. Jen to dále sníží tlak na to, psát ty programy správně.

Lepsie riesenie v com?

Lepší řešení v tom, že autoři budou psát robustní software. Co jsme v diskusích často četli, jako hlavní plus systemd? Snadné psaní unit. Autorům se prostě nechtělo psát "složité" init skripty. Jenže ty init skritpy nebyly složité "prostě proto", ale z toho důvodu, že ten jejich software prostě něco zanedbal.

Nevím jako kdo, ale já si prostě občas něco pustím jako program -d - neřeším ani unitu, nic, prostě jen tak program -d. A ono to běží.

Tzn. fakticky jediné, co má init řešit, je spuštění definovaných programů. To, že to nejde, ukazuje na problém. Ten problém ovšem nevyřeší systemd. Za 10 let se bude řešit totéž.

Třeba to, proč existuje něco jako exit codes a proč tím autory někdo otravuje. Už jsem podobných nářků slyšel několik.

[cezz]

Jasne,teraz uz ta chapem. Je to vec pohladu. Mne sa napriklad zda cudne, ze by si mal program riesit nieco ako "-d". Od toho mam predsa init system, aby mi spustil veci na pozadi. (a to uz ani nehovorim o programoch, ktore proste nedokazu bezat normalne na popredi, lebo autor stravil cas reimplementaciou initu namiesto toho aby proste napisal sluzbu)

Co sa tyka tlaku na autorov, tak je to podla mna proste tak, ze skutocny tlak je deadline ktory ma a nie aby init skripty krasne fungovali. Mali sme uz roky aby sa tieto veci opravili a co tu mame? Mame tu runbook kde sa pise, ze ked spustis /etc/init.d/something stop, tak tam mas ako dlasi bod kontrolu s ps ci neostali bezat nejake procesy. Tolko z praxe.

Systemd mi v tomto pride trosku realnejsi, ze ti umozni aj zle napisany kod spustit s relativne jednoduchou konfiguraciou a nehra sa na to, ze budes v inite spustat iba perfektne napisany kod. Lebo proste nebudes. Kym si bude kazdy implementovat polovicu initu, tak proste bude vela pripadov, kedy ta funkcionalita bude hrozna.

Podla mna mas vacsiu sancu s tym, ked ten tlak na developerov uvolnis, povies im, ze nech sa vykaslu na init a napisu to co maju - teda samotnu sluzbu a par riadkov konfiguracie ako ju spustit. To ti aspon dava ake take standardne rozhranie.

Uz len fakt ze si viem overridnut cez service.d subory jednotlive nastavenia sluzby bez toho ze by som musel menit distribucne init skripty mi pripada ako velky krok vpred. Jasne v idealnom svete nahlasim bug, autor to opravi a ideme dalej. Ale v praxi to znamena, ze sa to cele opravi po deadline kdesi za par rokov, alebo vobec, lebo bug je velmi specificky pre moj use case..

Tak to beriem ja. Je systemd dokonaly? Ani zdaleka. Ale ziaden kod nie je dokonaly a systemd dokaze ten ubohy kod jednotlivych sluzieb aspon ako-tak spustit a ked pride na to aj udrzat v behu a o to ide.

[Heron]

Od toho mam predsa init system, aby mi spustil veci na pozadi.

nohup program &

nebo ještě snadněji:

daemon -u user -c pwd program

Ono navíc hodit program na pozadí (tj odpojit se od control terminalu) není žádná raketová věda.

Co sa tyka tlaku na autorov, tak je to podla mna proste tak, ze skutocny tlak je deadline ktory ma a nie aby init skripty krasne fungovali.

No já se bavím o FOSS. Pokud si někdo soukromě chce mastit svůj produkt a zanechávat si problémy do budoucna, tak je to jeho rozhodnutí. Ve FreeSoftware žádné deadline nejsou.

Mali sme uz roky aby sa tieto veci opravili a co tu mame? Mame tu runbook kde sa pise, ze ked spustis /etc/init.d/something stop, tak tam mas ako dlasi bod kontrolu s ps ci neostali bezat nejake procesy.

Systemd mi v tomto pride trosku realnejsi, ze ti umozni aj zle napisany kod spustit s relativne jednoduchou konfiguraciou a nehra sa na to, ze budes v inite spustat iba perfektne napisany kod.

Ano, tohle je přesně to, kam jsem chtěl dojít. Takže vy máte vadný program. Víte o tom, že je vadný. Dnes to řešíte tím, že po stop se ještě díváte na ps. Systemd to "vyřeší" tak, že po stop zabije celou grupu. Ve skutečnosti není vyřešené nic, ten program je stále vadný, jen to není tolik vidět. Gratuluji.

Podla mna mas vacsiu sancu s tym, ked ten tlak na developerov uvolnis, povies im, ze nech sa vykaslu na init a napisu to co maju - teda samotnu sluzbu a par riadkov konfiguracie ako ju spustit.

Ok, tomuto rozumím, ale je potřeba si stále uvědomit, že na tu službu to stále klade nemalé nároky. Viz příklad s tím minecraft serverem výše. Někomu přišlo hrozně fajn přijímat příkazy na stdin. Už jen taková blbost způsobí, že je poměrně těžký problém to korektně zaslužbovat. Tzn stále se nelze vykašlat na všechno a systemd sebral část problémů, ale rozhodně ne všechny.

Uz len fakt ze si viem overridnut cez service.d subory jednotlive nastavenia sluzby bez toho ze by som musel menit distribucne init skripty mi pripada ako velky krok vpred.

Souhlasím.

[bsd ~]# cat /etc/rc.conf |  grep postgres
postgresql_class="postgres"
postgresql_enable="YES"
postgresql_data="/tank/db/postgres/data96"

Pro nastavení konkrétních parametrů skutečně nemusím měnit distribuční init skript. Ale můžu se do něj podívat, protože na počátku obsahují nápovědu, co lze nastavit:

# Add the following line to /etc/rc.conf to enable PostgreSQL:
#
#  postgresql_enable="YES"
#  # optional
#  postgresql_data="/var/db/postgres/data96"
#  postgresql_flags="-w -s -m fast"
#  postgresql_initdb_flags="--encoding=utf-8 --lc-collate=C"
#  postgresql_class="default"
#  postgresql_profiles=""

(Zrovna včera jsem řešil, jak na FBSD přesunout postgresql jinam, otevřel jsem jeho init skript, abych se podíval, jak vlastně volá pg_ctl a jaké tomu předává pamatery, protože v confu data_directory neřeší. A čekalo na mě tohle milé překvapení.)

[cezz]

Ve FreeSoftware žádné deadline nejsou.

Heh. Keby to tak bola pravda. Mozno nemas ciaru na kalendari (a vela vacsich projektov nieco take ma aj ked su OSS), ale mas len limitovany cas a ten ako developer mozes investovat bud do znovuvynaliezania kolesa, alebo si mozes povedat, ze ta init netrapi a cas vyuzijes efektivnejsie.

Ono navíc hodit program na pozadí (tj odpojit se od control terminalu) není žádná raketová věda.

V tom sa zhodneme. Napriek tomu pre skoro kazdy service ktory mi na serveroch bezi autori povazovali za nutne implementovat nejaku formu daemonizacie..

Ve skutečnosti není vyřešené nic, ten program je stále vadný, jen to není tolik vidět.

Tu nejde o to, ci to je alebo nie je vidiet. Ide o to, ze vahu toho problemu prenasam z programu kde je ukoncenie child procesov len vedlajsia cinnost nepodstatna pre samotne fungovanie sluzby na init system, kde je korektne (alebo aspon spolahlive) unoncenie sluzby sucastou zakladnej funkcionality.

K prikladu s Postgres len tolko, ze kolko takych sluzieb mas v systeme, kde mas aku-taku konfigurovatelnost vs tych, kde proste neostane ine ako prepisat init skript k svojmu obrazu? Lebo u systemd tak vies override-nut kazdu sluzbu a autor pre to zvycajne nemusel ani pohnut prstom.

Mne to proste pride ze si vyberas medzi systemd, kde az na vynimky v praxi takmer vsetko funguje hoci teoreticky je to hrozny bordel alebo inou init sluzbou, kde sice teoreticky mozes mat vsetko krasne a funkcne, ale v praxi je to hrozny bordel. Mne sa proste nechce cakat dalsich 20 rokov na idealne riesenie napriek tomu, ze sa za poslednych 20 rokov nic nezlepsilo, skor naopak.

Mozno je to tym, ze Linux pouzivam aj profesionalne a potrebujem sa zivit tym, co funguje teraz, nie ty co by mohlo fungovat niekedy v buducnosti bez deadline. Myslim, ze ty si na tom pracovne rovnako, takze je to mozno proste iny pristup k veci. Mozno som mensi idealista.

Nic v zlom, samozrejme. Budem s tebou nesuhlasit az do krvi, ale som presvedceny o tom, ze treba zastancov za obe strany.

[Heron]

Ide o to, ze vahu toho problemu prenasam z programu kde je ukoncenie child procesov len vedlajsia cinnost nepodstatna pre samotne fungovanie sluzby na init system, kde je korektne (alebo aspon spolahlive) unoncenie sluzby sucastou zakladnej funkcionality.

Ukončení procesů, které si sám forknu, není moje starost?

K prikladu s Postgres len tolko, ze kolko takych sluzieb mas v systeme, kde mas aku-taku konfigurovatelnost vs tych, kde proste neostane ine ako prepisat init skript k svojmu obrazu? Lebo u systemd tak vies override-nut kazdu sluzbu a autor pre to zvycajne nemusel ani pohnut prstom.

To byl příklad, který měl ilustrovat to, že pro konfiguraci služby nepotřebuju přepsat rc skript. Stačí k tomu běžné prostředky shellu, není k vůli tomu potřeba systemd. A může to být velmi přehledné.

Jo, systemd override je dobrá věc a sám to používám pro doplnění některých unit. S tím souhlasím. Ale ono to jde i jinak.

Mne to proste pride ze si vyberas medzi systemd, kde az na vynimky v praxi takmer vsetko funguje hoci teoreticky je to hrozny bordel alebo inou init sluzbou, kde sice teoreticky mozes mat vsetko krasne a funkcne, ale v praxi je to hrozny bordel.

Tak bordel. No možná proto dávám příklady z freebsd, jako takový trolling vůči linuxu a jako ukázka, že když se chce, tak v tom žádný bordel být nemusí.

Mozno je to tym, ze Linux pouzivam aj profesionalne a potrebujem sa zivit tym, co funguje teraz, nie ty co by mohlo fungovat niekedy v buducnosti bez deadline.

Mě administrace linuxu živí už asi 11 let.

Myslim, ze ty si na tom pracovne rovnako, takze je to mozno proste iny pristup k veci.

Spousta věcí, které zde (tj na abclinuxu) píšu, tak vychází z mé praxe. Sice nepíšu přímo o problémech, co mám v práci (to jsem si zakázal), ale snažím se hledat ilustrativní příklady, které to popíšou.

Jedním z nich je třeba to, že není dobré maskovat vadné programy, protože ono to nakonec vybublá na povrch někde, kde to klasicky napáchá nejvíc škody. Naopak, na vadné programy je potřeba hlasitě upozorňovat, aby je už nikdo nikde nepoužil. Nebo alespoň ne na mých serverech.

[cezz]

Ukončení procesů, které si sám forknu, není moje starost?

Jasne, ze to je tvoja starost, ale ked nieco zlyha, tak je casto hrozne zlozite taku situaciu riesit interne, tam je jednoduchsie to riesit "zvonku" systemom, ktory tu sluzbu spustil. Prakticky priklad: Plex odmieta nastartovat, lebo si naposledy po sebe neupratal pidfile. Keby autori neriesili somariny s PID a spolahli sa na to, ze funkcny init nespusti plex 2x sucasne, tak taky problem nemam.

A může to být velmi přehledné.

Moze, ale v praxi vela sluzieb takych nebude. Prax vs. teoria.

Mě administrace linuxu živí už asi 11 let.

Detto.

Naopak, na vadné programy je potřeba hlasitě upozorňovat, aby je už nikdo nikde nepoužil.

Problem je, ze ja si nie vzdy mozem vybrat ake programy budeme pouzivat. Legacy veci, rozne komercne platformy alebo OSS programy, ktore proste nemaju lepsiu alternativu. Mozem nahlasit bug (a casto tak urobim), ale bezat to musi uz vcera. :-/ Ak to mas inak, tak ti zavidim.

[Heron]

Problem je, ze ja si nie vzdy mozem vybrat ake programy budeme pouzivat.

No já jsem naštěstí v pozici, že můžu kecat do návrhu našich systémů po stránce použitých technologií (samozřejmě v rámci možností, nejsem tam sám), takže nakonec adminuju jen to, co jsem si sám nadrobil. Mě baví zkoumat nové technologie a zjišťovat, na co by to šlo použít a snažím se o tom informovat i ostatní.

Už jsem to chtěl napsat k předchozímu komentáři, ale adminovat systémy, kde si nemůžu vybírat, bych fakt nechtěl a tu práci bych nedělal.

Samozřejmě i u nás se stane, že tam jsou některé systémy poněkud déle, než by se nám líbilo a z poněkud divných komponent, ale to nakonec používám jako argument u dalšího návrhu, že takto tedy ne, pánové.

[cezz]

Tak to mas fajn. My tu mame kopu legacy systemov, takze tam som za tu trochu luxusu so systemd vdacny. Co sa tyka novych veci, tak samozrejme mame nejaky vplyv na vyber technologii, ale stare systemy ktore zarabaju peniaze tu proste su..

[cezz]

Tak ono vela tych rc skriptov by urcite slo napisat lepsie, ale problem je, ze niektore rc skripty by boli v bashi tak ako tak sialene komplikovane ak by mali riesit aspon cast toho, co riesi systemd by default.

Pre vela sluzieb je to iba jednoduchy start-stop skript a tam si viem predstavit, ze sa v pohode blizis tym 10 riadkom systemd. Ale potom zacnes riesit veci typu "co ak si daemon neuprace po sebe vsetky svoje procesy?", alebo "co ak je v pidfile zly PID?" a zrazu aj tie jednoduche start-stop sluzby zacinaju mat sialene komplexny rc skript, alebo sa zacnes spoliehat na to, ze "to sa predsa nemoze stat".

Systemd podla mna riesi vela tychto problemov pomerne elegantne a bez toho ze by nejako vyrazne komplikovala konfiguraciu jednoduchych sluzieb. Obcas pri tom fatalne zlyha, ale to je proste dane povahou problemu ktory riesi a vo vacsine pripadov sa tie zlyhania daju riesit systemovo namiesto toho aby si to na urovni rc skriptu riesil kazdy sam a s inymi chybami.

[GeorgeWH]

tak urcite http://www.abclinuxu.cz/poradna/linux/show/425256

[AsciiWolf]

+1

[Bill Gates]

+1

[little.owl]

K tomuhle vam desktopovy tym opravdu nepomuze.

[paralen]

-1

[Daniel]

-2

[Peter Fodrek]

sieťovo transparentný Wayland- Viem, že sa na tpm pracuje, pokiaľ to nie je hotové som odkázaný na X protokol.

1 x host HP Proliant z roku 2006 a 21 x X-terminál. už ani kdm ani gdm ani lightdm nejdú po sieti- potrebujú doplnky, čo nie sú sieťovo transparentné napr. openGL- ostáva mi len xdm a lxde/ openbix

[little.owl]

sieťovo transparentný Wayland-

Stacila by radna integrace se SPICE protokolem.

[Peter Fodrek]

To nie je dobrý nápad na výučbu IPC primitív, lebo pri virtuálkach môžu mat rovnaké kľúče pri shmget, msgget, semget...

To práve nechcem..

[Petr Tomášek]

Já nejraději nechci žádný Wayland!

[little.owl]

Poradne zdokumentovat jak psat Gnome Shell extensions.

[smazáno]

a za 6 mesicu zase

[Bedňa]

+1 to je fakt prasárna

[ohoho]

Extensions? WTF? To jako prodlužováky? Nebylo by lépe poslat zkracovák (Gnome's hell) i ty jeho prodlužováky k vodě? Přestat tlačit do maistreamu merginální úlet a zeptat se uživatelů, jaký dm si vlastně přejí?

[Petr Tomášek]

Např. možnost nastavit, co se stane, když zavřu víko od laptopu nebo když je baterie skoro vybitá...

(Tohle bylo už v Gnome 1, ale zrušili to, protože prý jsem jako uživatel moc blbej na to, abych si tohle mohl sám rozhodnout. Debilové!)

[Kamil Páral]

gnome-tweak-tool nebo /etc/systemd/logind.conf

[Bedňa]

A uvarím si v kapse na obed rezne, ďakujeme systemd. To bol posledný deň keď som ho používal.

[sid]

dost dobre nechapem vas trolling tu, je to tu o desktope a zasierate normalne polozene otazky svojou averziou voci systemd.

[Pavel 'TIGER' Růžička]

Podle mne to trolling není. Desktop může být sebelepší, ale bude mu to k ničemu, pokud to, nad čím běží bude špatné. Dalším měřítkem mohou být aplikace, což je všeobecně dlouhodobý problém linuxu. Prostě je jich málo. K čemu nám tedy bude kvalitní desktop, když pro něj bude naprostý nedostatek aplikací. Neustálé přepisování funkčního tyto nedodtastky neodstraní.

[sid]

ano a co s tym ako ma desktop team? Ked sa budu hladat vylepsenia pre Qt tak im nezabudnite reportovat preco pouzivaju registry. Ohladom aplikacii, da sa s tym suhlasit ale zase najlepsie vediaty udia co na to robia ci tie problemy boli take ako napr v X kde proste cez nieco neprelezies

[Pavel 'TIGER' Růžička]

Již tři roky jsem nic nereportoval, neposlal žádnou opravu a nic nenapsal. Postrádám v tom jakýkoliv smysl, jelikož se zůstává u kola se kterým se neustále otáčí, ale nikam se to neposouvá.

[PetrHL]

Díky, že se zajímáte!

Nevím jestli to nějak ovlivníte, ale velmi by pomohlo neměnit API každou chvíli. Týká se to jak extensions, tak i GTK3 samotného.

Dále by bylo fajn mít předinstalováno nějaké téma, které nemá tak obrovské mezery mezi ovládacími prvky. Mám T420 s rozlišením 1600x900. Gnome3 neskutečně plýtvá místem.

[Robert Smol]

Muzu se zeptat jak konkretne? Na mem desktopu GNOME zabira asi tak 0,7cm místa lišta nahoře. Zbytek je k dispozici pro aplikace které používám. Nebo je problem s vetšíma top barama?

[PetrHL]

Ano, myslel jsem topbar oken. U editoru je tam ulozit, zavirt. Stacila by bohate polovicni sirka, pripadne jeste mene.

Zkusím téma Minwaita. Snad bude fungovat i v pristi verzi.

[Bedňa]

Prečo sa GTK3 témy rozbíjajú v desatikových a prečo GTK3 prebíja WM?

[kuba77]

Doporučuji téma Minwaita, vychází z výchozí Adwaity a maximálně šetří místem, snižuje i výšku headerbarů.

[PetrHL]

Zkusim, diky za tip.

[k3dAR]

pripojim odkaz na jeho screenshot, kde je (teda hlavne v odkazu v komentari) videt ze tema je opravdy v topbaru pekne sporive :)

[PetrHL]

Mám nainstalováno na notebooku, kde dělám většinu práce. Nakonec se to docela dá, panel mi nechybí. Jen bojuji s některými klávesovými zkratkami. Snad se to časem poddá. Uvidíme co vymyslí Canonical.

[PetrHL]

Abych byl přesnější, mám nainstalováno Ubuntu Gnome. Víkend jsem musel víceméně strávit v posteli, měl jsem čas si s Fedorou pohrát. Vše mi tak nějak fungovalo, jen jsem nedonutil k fungování xdebug pro php. PhpStorm prostě nedostával žádná data. Strávil jsem s tím spoustu hodin, říkal jsem si, když už zkouším Gnome, tak ať je to distro, které je pověstné svým zaměřením na Gnome.

Vůbec mi nedošlo, jak může být Fedora na konfiguraci jiná proti Ubuntu. Konfigurace Apache a PHP naprosto jiná. Všechno jiné! Žiju na Ubuntu posledních 10 let a byl to docela šok .

[666]

prejit na KDE

[mirec]

Hodili by sa mi scrollbary, ktoré nemiznú pod kurzorom myši a GTK3 témy ktoré sa nerozbijú každou verziou (alebo jedna konzervatívna oficiálne podporovaná téma v ktorej fungujú scrollbary normálne a ovládzcie prvky nemajú kilometrové rozostupy).

[Selmi]

odkedy mam 2 monitory tak mi vadi ako to s nimi funguje. niektore okna otvara vzdy na na jednom, niektore na druhom, niektore tam kde ich ocakavam (ale mam ubuntu takze fedorom to pisat nebudem)

[koroptev]

mne chybi aby to nestalo cely za vylizprdel

[ika]

!!!

[Grunt]

Něco těžce experimentálního…