Fedora plánuje zaviesť offline aktualizácie

Fedora od verzie 18. plánuje nasadiť offline aktualizácie. To znamená, že reštart bude nutný nielen po upgrade kernelu, ale aj niektorých vybraných balíkov.

22.6.2012 21:29 | wht | Zajímavý článek

Komentáře

[pol128]

najprv si podpíšu systém microsoftom a potom sa bude reštartovať po update sw. pekne, pekne... :)

[Rezza]

Jen Gnome spin! Nerikejte Fedora!!!

[Migi]

Vykašlete se na to, prodejte to mrkvosoftu.

[Lol Phirae]

To se nedá prodat ani MS. Wokna minimálně od Visty dělají jeden reboot (aktualizace se nainstalují při vypnutí a zbytek se udělá po restartu před tím, než naběhne přihlášení (netlogon). Zatímco takhle Lennartovina je ještě horší, viz:

Are we actually doing 2 full reboots (incl. BIOS and grub) or will systemd only change to the special update target?

2 reboots. Lennart was in favour of the extra separation we gain by installing updates in a clean, minimal, freshly booted system. And we want to reboot after installing the updates to ensure that all the newly updates components are actually used

[little.owl]

Tak to uvedte cele nez zacne bucet:

The "first" reboot is super quick, and we boot straight into system-update.target. Getting to system-update target and back to rebooting takes me a fraction of a second. Posting the BIOS is the longest bit, but that only takes me a couple of seconds.

Tedy onen prvni boot bude velmi rychly.

Dual boot, kdy se v prvnim kroku aktualizuji kriticke komponenty, pak se system restartuje a updatuje se zbytek je u cely rady systemu, kde se vyzaduje robustnost updatu, bezny standard. U automotive ci podmorskych tezebnich systemu to jde tak daleko, ze ona kriticka cast ma dve kopie, updatuje se jedna a pokud restart selze, pouzije se predchozi funkcni kopie. Pokud je to uspesne, updatuje se i kopie a potom i vlastni applikace.

Lennart je ma evidentne vetsi prehled nez mate vy a jeho reseni je dobre.

[Lol Phirae]

Ano, je to prostě báječné. A podmořské těžební systémy jsou opravdu relevantní příklad.

[little.owl]

Je to priklad systemu, kde musi byt update rock stable, jinak pripadne naklady na opravu jsou astronomicke.

Vam dela problem rychly restart, kdy zpozdeni je dane predevsim inicializaci BIOSu (muj UEFI BIOS potrebuje ~2s), pokud to prinese zvyseni bezpecnosti aktualizace?

[Lol Phirae]

Ano, jinými slovy je to příklad úplně nesmyslný. Asi tak 99,99999% uživatelů neprovozuje embedded systémy několik set metrů pod mořskou hladinou.

A opravdu mi vadí, že mi někdo ve jménu "pokroku" nesmyslně vnucuje dvojitý reboot systému tam, kde asi tak 20 let nebyl potřeba reboot žádný (s kexec ani v případě aktualizace jádra.) Ať si celý ten Lennartův krám přejmenují konečně na Gnome OS a tam se v tom vrtají na vlastním písečku a přestanou s tím zaplevelovat do nedávna normální distribuce.

[little.owl]

Automaticky dvojity restart vam prinese rekneme <10s zpozdeni pri updatu a na stranu vyssi bezpecnost updatu.

V cem tedy mate problem?

Posledne jste tu ohnil u Lennarta proti systemd a pomalejsi start vam nevadil.

[Lol Phirae]

Problém mám v tom, že kdybych chtěl opakovaně restartovat systém kvůli "bezpečnějšímu" (citation/proof needed) updatu, tak si tam nechám Widle.

[little.owl]

Restart vam prinese jen male zpozdeni, nejedna se o plny restart do GUI, ale dvoufazovy update. V cem je problem, krom ideologie?

Dual update a boot s kopiemi u systemu nasazenych v kritickych prostredich je industrialni standard, od aut po automatizaci a neni slozite si domyslet jak to zvysuje bezpecnost, zejmena u remote updatu.

[Lol Phirae]

Jo, zejm. u remote updatu je to několikaminutové čekání, jestli se k těm Windows ještě připojím nebo ne, opravdu "k nezaplacení".

[little.owl]

Utikate od podstaty diskuze.

[Lol Phirae]

Jak od ní utíkám? Vždyť to je úplně to samé. Pokud budu dělat ten podle Lennarta a spol. "bezpečnější" remote update nějakého stroje a ten se restartuje to jakéhosi offline singleuser update režimu, tak už s tím případným nepovedeným updatem neudělám prostě nic. Krom toho, ty příklady v onom blogpostu a wiki uváděné nemají nic společného s bezpečnější aktualizací systému, mluví tam o Firefoxu a Chrome a že s tím mají problém. No, to je opravdu důvod jak hrom zásadním způsobem překopat filosofii aktualizací Linuxu.

[little.owl]

Tam jde hlavne o to, co se oznaci za "klicove" casti systemu, po jejichz updatu system bude restartovan. Nacpat tam i xulrunner mi prijde uz pritazene za vlasy, i kdyz je fakt ze jeho update firefox a thunderbird casto nepreziji ve funkcnim stavu.

To prekopani neni tak zasadni jak se zda. Pokud to neni kriticky/security update, system se updatuje pri vypnuti/startu, update po startu je dvoufazovy, napred klicove casti systemu, rychly restart, pak zbytek a boot do GUI. Nemam s tim problem a pockal bych na implementaci; moznost manualniho [ne]updatu je zachovana.

Remote update je slozitejsi, nemyslim, ze to ted resi, nicmene v kombinaci se UEFI biosem je moznost to vyrazne zlepsit.

[Lol Phirae]

Za xulrunner si distribuce můžou samy, upstream už to jako samostatný balík nijak nepodporuje. Jinak jak jsem již níže linkoval vysvětlení spoluautora této "featury", záměrem je offline realizovat většinu aktualizací (jinými slovy prakticky vše).

[Lol Phirae]

A ještě k tomu remote updatu - představa, že se takto "bezpečně" realizuje např. notoricky problémová aktualizace bootloaderu (grub2), to je teda fakt feeling jak stehno.

[little.owl]

Tak Grub2 je podle mne slepa ulicka, velky omyl, obstacle na ceste k UEFI bootu. Na[ne]stesti vsechny me systemy ted maji UEFI a grub2 se tam jeste nedostal.

[little.owl]

To by bylo trochu ustrelene, akceptovani faktu, ze plno aplikaci je tak blbe napsanych, ze online update je muze za chodu rozsypat.

[Lol Phirae]

To ovšem vycházíme z toho, že motivací je skutečně problém se stávajícími online aktualizacemi. Já tomu prostě nevěřím, fakt nikde nevidím ty tisíce a tisíce bugů způsobených mícháním starých a aktualizovaných knihoven apod. Navíc celá řada serverových věcí s takovou situací výslovně počítá, viz např. apache - viz apachectl -k graceful. Podle mě je to zase další maniakální Lennartovina a pokus vnutit něco "cool" nového za každou cenu.

Jinak ta citace a odkaz tady.

[little.owl]

U serveru bych problemy moc necekal, aplikace jsou vetsinou napsane tak, ze to neni problem; ostatne tahle zmena se dotkne hlavne desktopu.

[Ondrej 'SanTiago' Zajicek]

akceptovani faktu, ze plno aplikaci je tak blbe napsanych, ze online update je muze za chodu rozsypat.

Ony ty aplikace nejsou blbe napsane - pokud je program komplikovanejsi a sklada se z vice komponent, tak je zcela prirozene, ze bezici stara verze programu se bude pristupovat k novejsim komponentam (ktere mu mezitim instalator vymenil pod rukama) a kvuli nekompatibilite rozhrani to zhavaruje. Pri bezpecnostnich updatech by k tomu dochazet nemelo, protoze tam ty zmeny byvaji byt tak male, aby pomichani starych a novych komponent nevadilo.

Co je ale padle na hlavu je to navrhovane reseni - abychom se nahodou vyhnuli riziku padu nektere aplikace po upgradu, tak pro jistotu dopredu schodime vsechno. Pritom existuje hned nekolik alternativ v ruznych kombinacich jednoduchosti a elegance.

Nejjednodussi workaround je proste dat moznost a doporucovat delat upgrade z logovaci obrazovky (bez prihlaseneho prostredi). Tim by odpadlo pripadne riziko u uzivatelskych aplikaci. U demonu by s tim nemel byt problem, nebot je balickovaci system pred upgradem stejne postupne vypne a nasledne zapne. Vyhoda proti rebootu je v tom, ze demoni, kteri s tim pocitaji, mohou byt na to pripraveni a fungovat nepretrzite (napr. ssh, kde hlavni demon je sice restartovan, ale stavajici spojeni nejsou prerusena).

Pokrocilejsi reseni je vyuzit napr. snapshoty z Btrfs a umoznit udelat upgrade do noveho snapshotu s naslednou moznosti pri bootu vybrat snapshot. Pripadne propojit to s namespaces a delat to same s jemnejsi granularitou - aby uzivatel/aplikace dobehli ve starem snapshotu (pro /usr) a po opetovnem prihlaseni/spusteni by se spustila upgradovana verze programu v novem.

[little.owl]

Ony ty aplikace nejsou blbe napsane - pokud je program komplikovanejsi a sklada se z vice komponent, ....

Ano, tady jsem ustrelil, vychazeje z toho, ze Fedori updaty jsou v podstate jen bugfixy.

Nejjednodussi workaround je proste dat moznost a doporucovat delat upgrade z logovaci obrazovky (bez prihlaseneho prostredi).

To presne dela tato zmena, vcetne budouci moznosti atomickeho rollbacku, kdyz neco selze. Ale plno lidi zde ma s takovou moznosti problem.

Pokrocilejsi reseni je vyuzit napr. snapshoty z Btrfs a umoznit udelat upgrade do noveho snapshotu s naslednou moznosti pri bootu vybrat snapshot.

Coz ulehcuje udelany presun z /bin/* do /usr/bin/*, proti cemuz byl u minule Fedory podobny rev.

[Petr Ježek]

Sovičko, mně se online aktualizace xulrunneru ani jednou nestala vrahem jiných apps nebo snad systému. netuším, které bezpečné a spolehlivé distro provozujete, ale tohle právě o dobré práci vývojářů a maintainerů nesvědčí. Nebo že by to vlhko v Brghtonu? :) A propos, Rock-stable systémy jsou efektivní právě a jen tam, kde jde o jinak neřešitelné riziko počítané peněžně. Na světě v tuto vteřinu běží miliony serverů, jejichž dlooouhý nepřerušený běh nesvědčí o pudding-instable systémech, které na nich běží. Tak jako si malá firma nebude ke zvýšení efektivnosti, produktivity a bezpečnosti kupovat SAP R4, stejně tak nedává smysl, aby si miliardy domácích uživatelů pořizovali jakýkoli trollware pod jakoukoli marketingovou nálepkou.

[little.owl]

Aktualizace xulrunneru na pozadi muze byt fatalni pro bezici firexfox nebo thundibird a neni, jak bylo spravne vyse poznamenano, podporovana vyvojari firexfoxu ci thundibirdu a je uplne jedno jakou distribuci pouzivate. Pokud jste se s problem nesetkal, mel jste jen stesti, nic vice. Nicmene, pokud byste cetl dalsi muj prispevek, vsiml byste si, ze xulrunner bych zde nezahrnoval do "klicovych" casti systemu.

Pokud dana zmena zvysi bezpecnost updatu za cenu mirneho zpozdeni pri startu, kdy se instaluji updaty a pokud muzete updatovat system "starym" zpusobem, nemam s touto zmenou problem.

A propos, Rock-stable systémy jsou efektivní právě a jen tam, kde jde o jinak neřešitelné riziko počítané peněžně.

Zmenseni rizika problemu pri updatu ma smysl vzdy, pokud by selhani mohlo zpusobit komplikace uzivateli, a bez ohledu na to jedna-li se o toaster ci zarizeni za miliony, zejmena pokud vas to fakticky nic nestoji (analogie se SAP R4 je tudiz nesmysl).

[Bubak]

Treba to, ze mi to zbytecne shodi veci, ktere s tim vubec nesouvisi?

[Michal Kubeček]

A opravdu mi vadí, že mi někdo ve jménu "pokroku" nesmyslně vnucuje dvojitý reboot systému tam, kde asi tak 20 let nebyl potřeba reboot žádný (s kexec ani v případě aktualizace jádra.)

To je trochu zavádějící. Po takovém updatu glibc (nebo třeba i jen OpenSSL) vám v podstatě stejně nic jiného nezbývá.

[little.owl]

+1

[kavol]

To je trochu zavádějící. Po takovém updatu glibc (nebo třeba i jen OpenSSL) vám v podstatě stejně nic jiného nezbývá.

co prosím?

- nějak jsem si během posledních dvou updatů glibc na Fedoře nevšiml, že by mi nic jiného než rebootovat (a ještě k tomu dvakrát) nezbývalo ...

[Michal Kubeček]

Pokud se rozhodnete ignorovat to, že vám prakticky všechny programy v systému dál používají starou verzi, pak samozřejmě rebootovat nepotřebujete. Pak se ovšem nabízí otázka, proč jste vlastně updatoval…

V OpenSuSE naštěstí máme 'zypper ps', takže člověk názorně vidí, jak se věci mají.

[little.owl]

Fedora:

yum install yum-plugin-ps

[R]

A nedaju sa nahodou vsetky beziace programy restartovat bez restartu celeho OS? "lsof -n | grep DEL", pripadne v Debiane checkrestart...

[Michal Kubeček]

Ne vždy, třeba takový X server by vyžadoval shození celého desktopového prostředí, což v mém případě není o moc lepší než restartovat rovnou celý systém. U některých démonů bych nejdřív musel dohledat, který skript je vlastně kdy spustil, a co všechno na nich závisí.

[R]

Ano, da desktope to je problem. Ale na serveri sa da vsetko (okrem jadra) updatovat bez restartu. Vypadky jednotlivych sluzieb v dlzke niekolkych sekund su urcite lepsie ako vypadok celeho serveru v dlzke niekolkych minut. Uz len preto, ze programatori serverovych BIOSov sa riadia heslom "cim viac enterprise, tym dlhsie bude trvat POST".

checkrestart v Debiane tie skripty vyhladava automaticky.

[kavol]

Pokud se rozhodnete ignorovat to, že vám prakticky všechny programy v systému dál používají starou verzi, pak samozřejmě rebootovat nepotřebujete.

již bylo zodpovězeno, dá se řešit

Pak se ovšem nabízí otázka, proč jste vlastně updatoval…

v naprosté většině případů prostě proto, že ten update byl k dispozici - nevybavuju si, že by někdy v glibc byla oprava, u které bych potřeboval/chtěl, aby se projevila ihned

když dám z lenosti yum update, tak neřeším, že bych měl z updatu vyjmout glibc, protože je tam pouze oprava nějakého bugu, který se projevuje jenom na nějaké obskurní architektuře za úplňku přestupného roku, a tudíž já konkrétně ten update nepotřebuju, prostě odprásknu aktualizaci všeho

[Käyttäjä 11133]

U automotive ci podmorskych tezebnich systemu to jde tak daleko, ze ona kriticka cast ma dve kopie, updatuje se jedna a pokud restart selze, pouzije se predchozi funkcni kopie.

:D Takhle to dělá snad každé rozumné diskové pole.

[little.owl]

Hezke. Rekl bych, ze to dela kazdy rozumne navrzeny system, kde se vyvojari zamysleli jak udelat relativne robustni update.

[Jezekus]

To je zajimave, takze tyto "restartovaci seance" se budou tykat pouze Gnome spinu?
Jak se bude chovat treba instalace z netintall media?
Velice rad toto pouzivam a mivam s timto typem instalace mnohem mene problemu + v soucasne dobe jsem premigroval z Gnome's Hellu na XFCE.
Dotkne se tato zmena i mne?

[vain]

Hádám, že se to má týkat GNOME jako takového a je jedno, jestli si ho nainstaluješ z DVD, netinstallu nebo z CD GNOME spin. Navíc, pokud to tak je, tak se to bude v budoucnosti týkat všech distribucí s novým GNOME 3.

[Rezza]

Bude to jenom Gnome spin, zatim. Ve Gnome ta featura znamena jen, ze nabidne restart s updaty. Jinak je to PackageKit featura, ten Gnomacky proste zataji, ze jsou aktualizace, stahne je automaticky a pak se jen zmeni to menu. A nekdy se pak pusti v systemd target, ktery udela ten update. S velkou pravdepodobnosti na to prejdou i ostatni Gnome distra (jsou jeste nejake?) a bavil jsem se s Danttim a az bude mit cas, tak to dopise do Apperu. Pak to bude moct byt i v KDE distrech.

[Lol Phirae]

proste zataji, ze jsou aktualizace, stahne je automaticky a pak se jen zmeni to menu. A nekdy se pak pusti v systemd target, ktery udela ten update.

Chce se mi zvracet... Tomu říkám opravdu pokrok.

[heh]

Jojo Fuck of Fedora

[Jezekus]

Diky za objasneni. Co mi to jen pripomina...
Ach jo

[vain]

No vida, zase o něco chytřejší, taky děkuji za popis funkčnosti.

[little.owl]

Pokud vim, budete mit moznost restartovat/vypnout system bez pozadavku updatovani a pak udelat manualne.

[David Jaša]

To se mi líbí, pokud to půjde vypnout. Mě by to překáželo, ale u některých mnou instalovaných systémů to je rozdíl mezi updatovaným a zanedbávaným systémem.

[little.owl]

Tak prave pro zanedbane systemy je to vyborne reseni, nebot update pres X revizi u Y baliku vam nikdo poradne neotestuje a pokud mate offline update muzete rozumne implementovat atomicky rollback. Atomicky rollback byl IMHO jeden z duvodu, proc to resi jak to resi.

[DiGiT]

Tak ono to částečně dává smysl, ale raději bych viděl, kdyby se prostě v rámci releasu změny formátů datových souborů nedělaly. A nebo tedy flagovat releasy konkrétně, podle toho, jestli opravdu problém hrozí.

[michich]

Doporučuju přečíst si raději popis u Fedory, než převyprávění na druhou, čímž je tato zprávička.

[Ondra]

relevantni blogpost

[kavol]

ještě jsem nečetl, ale ke zprávičce, "převyprávění na druhou" je dost velký eufemismus

buď to vezmeme tak, že po instalaci nového kernelu není nutné restartovat, akorát prostě bude do restartu běžet ten starý, takže zprávička kecá, anebo tedy to uplatnění změny, aby se natáhla nová verze, za "nutnost" považovat budem, a pak ta zprávička opět kecá v tom, že by to byl jenom kernel, balíků, co vyžadujou restart, je víc

[Lol Phirae]

At the moment, the new updater application doesn't use this data from bodhi at all as most updates are going to be done offline. --rhughes 07:15, 16 June 2012 (UTC)

Přeloženo, víceméně žádné aktualizace bez dvojitého rebootu. Juch!

[little.owl]

+1

Zase obvykly rev bez precteni relevatnich informaci a zamysleni se.

[heh]

V poslední době mě už několikrát napadlo, že vývojáři Fedory zešíleli. si to bude nějaký trend.

Nedávno oznámili, že Yum nahradí novým package managementem. Použili SAT solver knihovnu z Opensuse (protože to je bez diskuze nejmocnější dependency resolver v Linuxu). Ale místo aby rovnou použili Libzypp/zypper, který je už odladěný, co do funkcí packge managementu nemá konkurenci a pozor dokonce používá formát repozitářů YUM!!!, tak ve fedoře budou znovu vynalézat kolo (DNF), s naprosto nejistým výsledkem a znovu závislém na Pythonu.

Proč to tu zmiňuju? Protože Zypper umí identifikovat procesy ovlivněné instalací, upgradem nebo deinstalací balíčku, a není tak problém restartovat jen postižené procesy. Ale ve Fedoře jsou evidentně tak zaslepení, že raději budou zbytečně vynalézat DNF, a 2x restartovat systém při upgradu, není to první příklad co si oblíbili Microsoft way.

[Pavel Stárek]

Proč mi připadá, že někteří lidé asi naschvál nedočítají text, nebo ho nechápou.

As covered in the original article, the Fedora Engineering & Steering Committee approved "DNF" for Fedora 18. DNF is the new package manager for Fedora 18 that's forked from Yum 3.4. Yum will continue to be the default package management solution for Fedora 18, but DNF will live alongside the "Yellowdog Updater, Modified" as a new experimental solution.

[Lol Phirae]

Proč mi připadá, že někdo reaguje na něco, co vůbec nepochopil? Kritizováno bylo především to, že někdo znovuvynalézá kolo (rozuměj, DNF) místo použití podstatně kvalitnějšího nástroje (Zypper). Mimochodem, tahle rebootovací lennartovina je jedním z důsledků.

[little.owl]

Otazka zni, zdali DNF bude pouze replikovat zypper, pokud ano, je samozrejme nesmysl psat to znovu.

[heh]

Tipnul bych si, že funkcionalitě Zypperu use to nepřiblíží ani z rychlíku a vzhledem k závislosti na Pythonu to bude méně odolné a více paměťově náročné. Kdyby místo toho vyjádřili ochotu zapojit se do vývoje Zypperu/libzyppu, mohli zajistit rozšíření funkcionality, kterou by případně potřebovali. Opensuse má dlouhodobě snahu udržovat Libzypp kompatibilní s YUMem, takže z druhé strany by asi zájem o spolupráci byl.

[Michal Kubeček]

Pokud jsem dobře pochopil ten shrnující článeček, tak hlavní důvod, proč se rozhodli použít libsolv, ale už ne libzypp, byl ten, že se jim nelíbilo, že je libzypp v C++.

[little.owl]

Tot argument, python yes, C++ no.

[michich]

hawkey (knihovna, na které je DNF postavené) je v C, nikoliv v Pythonu.

[little.owl]

Diky. Ja o teto diskutovane zmene moc nevedel a mel jsem pocit, ze nekdo chce psat neco z nuly, coz jak se ukazuje neni pravda.

[little.owl]

+1

Zypper a veci kolem se openSUSE povedli, klidne bych to ve Fedore rad pouzival.

[Pavel Stárek]

Ne, druhá věta zápisku zní Nedávno oznámili, že Yum nahradí novým package managementem., což ale není pravda.

[heh]

Ale oni deklarují zájem ho nahradit, jen to nebude hned.

Preview the next-generation Yum package manager, using hawkey/libsolv for backend.

In the future if DNF gets accepted as the main package manager of the platform, yum plugins will have to be updated for the new API and so will Anaconda. I am prepared to assist in this effort with documentation and patches.

Nakonec je to vlastně úplně jedno. I kdyby projekt DNF zkončil neúspěchem, je to naprosto zbytečné úsilí promrhané na vynalézání kola.

[Pavel Stárek]

Jistě, nějaká deklarace ještě nutně neznamená, že to bude rovnou ve Fedoře 18, ono to může být až klidně ve Fedoře 20, nebo třeba vůbec. Akorát je potřeba nebýt hned vyděšený z nějakých rozhodnutí fedora board A nakonec, vždy jde přejít jinam. A až to tam (ve Fedoře) bude, tak to tam prostě bude - jako jiné věci (PulseAudio atd.). Na druhou stranu Yum možná není nikterak rychlý a ten resolver asi taky není bůh ví co, ale zaplať bůh za něj. Ano, mohlo se přejít třeba na apt, ale asi prostě nevyhovoval, a teď si nejsem jistý, zdali v době prvního uvedení Yumu do Fedory existoval ve Fedoře nějaký podobný nástroj.

Na druhou stranu mne taky mrzí, že se plýtvá silami na nějaké pochybné projekty, například místo toho, udržovat nějakou jednu LTS verzi Fedory s tím, že by ale do ní proplouvali upstream verze některých balíků (LibO, Thunderbird, FF, atd.) a knihoven.

[heh]

Situace s Aptem není srovnatelná. Dokonce vznikl Apt4Rpm, ale prakticky nikdo to už roky nepoužívá. Apt je totiž dost přeceňovaný správce balíků, který nikdy jinde než v Debianu ani pořádně nefunguje - aktuálně ho používá pouze Debian a ti co mirrorují jeho repozitáře. V řešení závislostí je to hodně slabý nástroj.

[okko]

vypadá to, že po destiletí s Fedorou končím. Změnila se v pomalý, nespolehlivý a nestabilní bastl. Asi tak od verze 12 se začala měnit v něco, co nejspíše tak připomíná kompost. Její vývojáři, kteří sobě bůhví proč říkají "komunita" jsou arogantní a nereflektují zájmy uživatelů, a bohužel to platí i pro české členy. Bohužel já na linuxu pracuji a od OS potřebuju i něco jiného než naleštěný ale blbě fungující desktop. U Fedory jsem byl dosud jen proto, že jsem odrostl na redhatu a nemohu si zvyknout na debianovské systémy. Poradíte někdo slušnou distribuci?

[Lol Phirae]

Zkus Mint Debian Edition, nejlépe s Xfce.

[Bystroushaak]

S Mintem můžu souhlasit. Verze s Mate je dost fajn a trochu to připomíná zlaté časy Ubuntu, protože když jí u mě viděl kolega z práce (jinak windowsák), do druhého dne si jí hned hodil na disk taky a ku mému podivu jí i používá.

To už jsem já na notebooku, netbooku, otec a kolega, kteří si na Mint/Mate nemůžou stěžovat.

[little.owl]

Myslite to XFCE, ktere vam na pozadi nainstaluje cele Gnome?

[Lol Phirae]

Ne, já tady v LMDE Xfce Edition na pozadí žádné Gnome nemám. Jediný pozůstatek té hrůzy (GDM3) jsem nahradil lightdm. Ostatně, ani Mate tam žádné Gnome3 cpát nebude.

[little.owl]

Kouknete se na zavislosti XFCE na Gnome knihovnach a technologiich, nehlede k tomu, ze drive ci pozdeji to budou muset naportovat na Gtk3. Navic u Debianu jsem nepozoroval vyrazany rozdil mezi pametovymi naroky XFCE a Gnome3, to uz radsi Mint a Cinnamon.

[Lol Phirae]

Paměťové nároky jsou mi ukradené. Především netoužím po nejrůznějších Gnome shellech, Unity a dalších blbostech, které pouze zpomalují práci, snižují produktivitu a dělají z desktopu "líbivé" polofunkční omalovánky pro debily, kde někdo bude rozhodovat, jestli uživatel smí vidět čudlík Vypnout, Hibernovat nebo co bude systém dělat při zaklapnutí víka notebooku, protože tak to je "správné" a tak to má být a protože uživatel se neumí svéprávně rozhodnout.

[little.owl]

nejrůznějších Gnome shellech, Unity a dalších blbostech, které pouze zpomalují práci, snižují produktivitu

Silne individualni, me napriklad produktivitu prace Gnome Shell zvysil, uz treba diky skvelemu ovladani klavesnici a koncept mi spise vyhovuje.

[little.owl]

Změnila se v pomalý, nespolehlivý a nestabilní bastl.

Mohl byste to specifikovat a kvantifikovat? Jakou rychlost mate na mysli? Nestabilni? Pouzivam Fedoru od verze 1 stabilita se spise zlepsila - pouziti ABRT je znat.

Pokud chcete stabilitu, zkuste CentOS; pri prechodu jinam brzy zjistite, ze trava jinde neni zelenejsi.

[okko]

Mohu specifikovat, ale nechce se mi, jsou toho mraky. Např. systemd zůpsobil u některých mašin (boardy supermicro), že se služby startují dříve než síťový hardware a poté sůstávají viset v nefunkčním a nerestartovatelném zomboidním stavu. Nebo se spouštějí služby, které se rozhodně nemají spouštět a to kdykoliv v průběhu doby, jiné chcípnou a nefungují a přesto systemctl tvrdí, že běží. Hlášení bugů a posílání patchů jsem si už užil dost a dále to dělat nebudu, je to marná a zbytečná práce. Networkmanager je pro mé stroje nepotřebný a nepoužitelný, ale je tak zaháčknutý, že se nedá totálně zrušit. Zbytečná trojice (potřebná jen pro omalovánky při startu), totiž grub2-plymouth-systemd prodlužuje start systému a způsobuje tucty zbytečných problémů (např. nefunkční zadávání hesla během startu). A to ještě nekomentuji poslední novinky týkající se bootu (M$). ACPI je ve nových kernelech totálně podělané. No a gnome3 - to je supershit. Nikdy mi nezhavaroval desktop manager (twm, mwm, fvwm, fvwm2, afterstep, enlightenment, kde, gnome, gnome2, xfce) - teď končí gnomeshell tuhý s rozšklebeným ksichtem skoro každý den. Ve fedoře se zásadně věci nedotahují do konce, místo oprav hlášených bugů se v maniakálním tempu zavádějí další a další nesmysly, které si chce pár nejmenovaných šílenců vyzkoušet. Nic bych proti tomu neměl, kdyby to dělali na nějaké své experimentální distribuci. Jenže oni tím znepříjemňují život normálním uživatelům.

Centos na některých počítačích používáme, ale na desktop se mi s tím moc nechce. Co scientific linux? Zkoušel to někdo?

[Lol Phirae]

No já už to ale přestávám pomalu chápat - Fedora byla pokud vím používána jako "testbed" pro RHEL. O takovéhle šílenosti, co se poslední dobou zkoušejí, ale teda určitě firemní klientala absolutně nemá zájem, tak nějak nevím, co by je dál mělo motivovat k financování podobných experimentů a slepých uliček???

[little.owl]

Nikoliv, RHEL je postaven na Fedore a Fedora je komunitni distribuce, kde se Linux vyviji a pokud ji nekdo pouziva i ve firme, vi do ceho jde.

[Lol Phirae]

Doporučuju vyhledat ve slovníku slovo "testbed"...

[little.owl]

A vy se kouknete na termin "bleeding edge" v kontextu s riziky v produkcniho nasazeni.

Ja Fedoru roky vicemene spokojene pouzivam, neb vim co od ni cekat a jak ji pouzivat, na ostatni veci mam CentOS.

[Lol Phirae]

Co je prosím tak nepochopitelného na spojení "testbed pro RHEL"? A na tom, že opravdu nechápu, o co z těch "bleeding edge" technologií by asi tak měla firemní klientela zájem a proč by takovéto pokusy měl RH financovat? Ach jo.

[little.owl]

Vzhledem k tomu, ze veci sleduji, mam pocit, ze Redhat do deni ve Fedore zase tolik nezasahuje; spise mozna mene nez by mel. Fedora, tim ze adoptuje rychle nove technologie, je testbed pro vsechny, nikoliv jen pro RedHat a se svym pristupem ma smysl a sve misto. Take it or leave it.

[Lol Phirae]

Vzhledem k tomu, ze veci sleduji, mam pocit, ze Redhat do deni ve Fedore zase tolik nezasahuje; spise mozna mene nez by mel.

No ano, přesně. Tohle přece pro ně nemůže plnit příliš rozumnou funkci.

[little.owl]

Vy stale vychazite z predpokladu, ze Fedora je alpha RHELu. Nicmene ocekavam, ze jak se bude blizit RHEL 7, zacnou byt o neco restriktivnejsi a opet budou uplatnovat vice svuj vliv.

[nyan]

O takovéhle šílenosti, co se poslední dobou zkoušejí, ale teda určitě firemní klientala absolutně nemá zájem

Haha. Myslite ze Lenarta & spol zajima firemni klientela ?

[dustin]

To mě právě fascinuje, jak to nikomu v redhatu nevadí, přitom je živí jen a pouze firemní klientela. Proto si myslím, že si tam skupinky lidí dělají, co chtějí, a ve vedení to nikdo neřeší, protože zřejmě mají jako v každé pořádné korporaci úplně jiné starosti.

[little.owl]

A myslite si ze systemd neni pro ne zajimavy? Ci bezpecny update s moznosti atomickeho rollbacku?

[frEon]

naopak, jim to prave vyhovuje. Na fedore vyzkousi vsechny slepe ulicky aby tim nemuseli kazit Rhel...

[little.owl]

Scintific Linux je rebuild RHEL, tedy jako CentOS a pouzival jsem se ho nez vysel prvni CentOS 6.0. Ma vyrazne horsi QA nez CentOS.

Vetsina vasich pripominek smeruje na systemd, mam asi stesti, ale vse nam chodi a k puvodnimu init systemu bych se uz nechtel vratit.

že se služby startují dříve než síťový hardware a poté sůstávají viset v nefunkčním a nerestartovatelném zomboidním stavu.

Chybne napsane unity a specifikovane zavisloti, pokud se to stane u defaultnich sluzeb, reportujte bug.

Nebo se spouštějí služby, které se rozhodně nemají spouštět a to kdykoliv v průběhu doby

Pak je to bug v systemd nebo v unite, ale zatim se mi nic takoveho nestalo.

jiné chcípnou a nefungují a přesto systemctl tvrdí, že běží.

Chyba sluzby. Tady se systemd nelisi od SysV a jeho moznosti detekovat stav jednou zpustene sluzby jsou minimalni, zejmena pokud nepouzivaji systemd interface. Viz dokumentatce.

Networkmanager je pro mé stroje nepotřebný a nepoužitelný, ale je tak zaháčknutý, že se nedá totálně zrušit.

Na serveru ho aktivne nemam, ale zavislosti jsou znacne. Co delate, ze je na vasem serveru absolutne nepouzitelny?

ACPI je ve nových kernelech totálně podělané.

Ne, spise ACPI v novem HW je totalne podelane, zejmena UEFI biosy. Linux vetsinou dobre implementuje ACPI standard.

No a gnome3 - to je supershit. Nikdy mi nezhavaroval desktop manager (twm, mwm, fvwm, fvwm2, afterstep, enlightenment, kde, gnome, gnome2, xfce) - teď končí gnomeshell tuhý s rozšklebeným ksichtem skoro každý den.

Ted pisi z Gnome 3, ktere bylo zpusteno pred tydnem (mel bych updatovat). Krom memory leaku - lepsi se to - zadne problemy - Fedora 17, vlastne mi od Fedory 15 Gnome Shell spadl jen trikrat - a vzdy problem s drivery graficke karty. Pokud se vam to sype kazdy den mate problem spise s HW. Kde to presne pada? Tady by opravdu stalo za to nareporovat bug, ztahnout debug info a poslat dump. Mate nejaky odkaz v bugzille? Prekvapive, i v minulosti mi obcas havaroval desktop, vcetne vami zminovaneho okenniho manazeru fvwm2, ktery jsem dlouho pouzival, ale u Gnome3 se stabilitou problemy nemam.

Ve fedoře se zásadně věci nedotahují do konce, místo oprav hlášených bugů se v maniakálním tempu zavádějí další a další nesmysly.

Fedora pouziva upstream baliky a problemy v jejich vlastnich balicich a implementaci resi.

Nic bych proti tomu neměl, kdyby to dělali na nějaké své experimentální distribuci. Jenže oni tím znepříjemňují život normálním uživatelům.

Fedora je a vzdy byla bleeding edge distribuce, pokud chcete neco jineho pouzijte treba CentOS ci Debian Stable.

Celkove mam pocit, ze najit vhodnou distribuci pro vas nebude jednoduche, mate atypicke mnozstvi problemu.

[nyan]

Ne, spise ACPI v novem HW je totalne podelane, zejmena UEFI biosy. Linux vetsinou dobre implementuje ACPI standard.

Souhlas - az na to, ze u Supermicro bych rekl, ze jde o jednu z mala firem, ktera nedava svuj bios psat cinskym stredoskolakum Osobne vazne uvazuji, ze pro pristi komp si poridim Supermicro nebo Tyan desku v rakousku (bez CZ prirazky).

Tady by opravdu stalo za to nareporovat bug, ztahnout debug info a poslat dump.

Uz ste to nekdy zkousel ? Mozna vas prekvapi, ale velice casta zkusenost lidi je: report bugu - nic se nedeje (resp. kolecka dotazu uz je to fixle - neni) - EOL fedora, hura, bug se magicky fixne komentarem bota.

Fedora pouziva upstream baliky a problemy v jejich vlastnich balicich a implementaci resi.

No, podle mnozstvi patchu co jsem vidaval v jejich baliccich, mi realita prisla trochu jina, ale mozna uz se zlepsili.

Fedora je a vzdy byla bleeding edge distribuce, pokud chcete neco jineho pouzijte treba CentOS ci Debian Stable.

Fedora neni bleeding edge. Treba F14 vysla s kernelem 2.6.35; v dobe kdy vysla F15 (o ~9 mesicu pozdeji), kernel v F14 byl furt 2.6.35, pricemz v F15 byl 2.6.38 - jaksi "zapomneli" updatovat tri stabilni kernel releasy.

Fedora se snazi byt bleeding edge a soucasne stabilni, a vysledek je to co vidite. Nerikam ze to nekomu nevyhovuje - ale ja si pod "bleeding edge" predstavuju neco jineho nez balicky tri major releasy pozadu za upstreamem.

[little.owl]

tri major releasy pozadu za upstreamem.

F17 mela kernel 3.3 a ted ma 3.4, plus obcas backportuji cele subsystemy.

bleeding edge

To znamena, ze ma vetsinou posledni stabilni release v dobe zmrazeni a snad s vyjimkou Arch je to nejaktualnejsi distribuce (rolling distra to maji jednoduzsi).

[Rezza]

Kteri cesti clenove? At si to s nima vyridim :)

[Pavel Stárek]

Akorát nechápu ten dvojitý boot, stáhnu, nainstaluju, a zrebootuju pouze jednou.

[Lol Phirae]

To nebylo pro Lennarta dost sexy widloidní řešení, čím víc rebootů, tím líp.

[Pavel Stárek]

Prosím Vás, nereagujte na jakékoliv moje příspěvky zde na Abc Linuxu. Děkuji.

[Bystroushaak]

Podivuhodný request. To jako že když na ně zareaguje, tak je nějak pošpiní?

[Pavel Stárek]

Ne, protože ten pán píše bláboly.

[Lol Phirae]

Hmmm, tak je nečti, on tě někdo nutí?

[Pavel Stárek]

Ne, tak je Vy nepište pod moje komentáře.

[Lol Phirae]

S dovolením si bude psát tam, kam to uznám za vhodné. Jestli vám vadí, že reakce na váš příspěvek jsou pod vaším příspěvkem, tak zkuste nějaké vlastní CSS, které vám z toho udělá patřičný guláš tak, aby vaše hodnotné příspěvky nebyly znesvěcovány sousedstvím mých blábolů. Jůůůů? Pá, brouku.

[Pavel Stárek]

No, alespoň jste přiznal to, že píšete bláboly.

[Bystroushaak]

To je otázka uhlu/ů pohledu. Pokud má člověk jen jeden vlastní, nejlepší správný, tak se mu zdá jako bláboly všechno, co s ním koliduje.

[Pavel Stárek]

Ne, já nemám TenJedinýSprávnýNázor(TM) a jsem otevřen rozumné a slušné diskuzi, ale nechce se mi číst chytré a duchaplné příspěvky typu:

To nebylo pro Lennarta dost sexy widloidní řešení, čím víc rebootů, tím líp.

které sem ten pán píše.

[Lol Phirae]

Rozumím. Hlásat názory v rozporu z oficiální linií strany... eeeh, totiž velikánů, kteří mají na svém kontě takové úspěchy, jako je Gnome OS, to je skutečně trestuhodné.

[Pavel Stárek]

Obávám se, že nerozumíte, ale to je jedno.

[Sid]

Obdivujem vasu namahu berte to tak, ze vzdy sa najde nejaky idiot co ma potrebu sebaprezentovania a pouziva dve zakladne pravidla 1) Jeho prispevkom musi koncit vzdy kazdy koncovy uzol diskusie co s nim vediete 2) V pripade, ze dojdu argumenty prejde sa bud a) na inu temu ktora s prvou vobec nema suvis b) ku kvazi ironickemu stylu o ktorom si iba autor mysli, ze sa kazdy pobavi c) k osobnym urazkam

[Lol Phirae]

c) k osobnym urazkam

Nazdar, jak plníte rezoluci OSN o porušování práv ovcí v Čobolstánu?

[Bystroushaak]

Hehe. 12abc dohromady. Dobře ty :)

[Pavel Stárek]

Jestli si myslíte, kdoví jak nejste vtipný, tak jste na omylu. Nejste.

[Lol Phirae]

Proč na mě reaguješ, když nechceš, abych reagoval pod tvými příspěvky? ))

[Sešívaný]

Hmmm... Taky se mi to nelibi od sameho zacatku, ale predpokladam/doufam, ze pujdou automaticke aktualizace pres PackageKit vypnout a pak mi bude stacit tradicni yum update. Mozna, kdyby byly aktualizace jednou do mesice, ale ve Fedore jsou kazdy druhy den! To se pos... v kine.

[little.owl]

Kazdy druhy den je optimisticke tvrzeni, mozna tak o vikendu. Myslim, ze yum update si nedovoli rozbit.

[okko]

Já myslel, že vy v Brně máte k Fedoře blíže a že nemusíte jen tak bez hlesu trpět, jako my v pražsku. Uf uf. No, hlavě že nám pan Sýček vysvětlil, co to znamená bleeding edge (uživatel krvácí z toho, že má každého půl roku v upgradu něco na hraně mezi šílenstvím a demencí).

[little.owl]

Na Linuxu je hezke, ze mate plno distribuci a kazdy si muze vybrat, co mu sedi.

[vain]

Přesně tak, používám Fedoru od prvopočátku jejího vzniku a fakt ani tohle mě nedonutí po tak dlouhé době (kolik, devět let?) změnit distribuci. Zvlášť když v tomhle

Installing updates will still be the users choice - if system updates are available, we will offer 'Restart and install updates' in addition to a plain 'Restart' in the menus.

opravdu nevidím problém.

[Sešívaný]

No, vetsinou to funguje tak, ze desktop tym jen oznami, na cem zase zacali makat, a do Fedory si to protlaci. Nicmene v posledni dobe uz je ostatni donutili aspon k nejakym ustupkum. A porad tu je ta moznost, ze bude mit Fedora jine vychozi prostredi. KDE a Xfce SIGy jsou hodne silne na to, aby to zvladly. Ac uzivatel GNOME, docela bych takove myslence fandil. Asi by to pomohlo.

[lib]

Když už jsme u těch různých desktopů - nevíte, není nějaká nová verze gnome nebo gnome-like like desktopu, která umí běžet bez zapnutého kompositoru, nebo jak se ten prevít, co dělá průhledná okna a žere mi polovinu FPS jmenuje? Na domácím počítači používaném na hry mám dosud gnome2 bez compizu, právě proto, abych mohl hrát hry se solidním FPS (nvidia blob). Bohužel gnome 3 a pokusy o retro jako např cinnamon mi dávají v glxgears asi 4/7 fps oproti čistému xorg.

[Lol Phirae]

Xfce.

[dustin]

Zajímalo by mě, jak v RedHatu určují priority, do čeho budou investovat mzdy svých zaměstnanců. Přijde mi, že ta firma už pár let v některých odděleních vyhazuje prachy z okna. Bohužel díky jejímu postavení v linuxové komunitě mají její "novátorské" projekty velké dopady. Jasně, korporace na burze, majitel žádný, centrální vedení žádné, prachy se od klientů sypou, manažeři se soustředí na své zájmy...

[little.owl]

Pokud pokladate tuto zmenu za vyhazovani prachu, tak v tom se neschodnem, nehlede k tomu ze naklady nejsou tak velke. Pokud jsou jejich projekty spatne, ostatni distribuce je nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni.

[dustin]

Mně se na opensource líbí, že vývojáři obvykle řešili své problémy a obvykle cestou minimálního odporu. Takže řešení byla jednoduchá a efektivní. Poslední dobou má řada lidí placenou pracovní dobu a hledají, co dělat, aby prokázali svou užitečnost. Včetně vrstvy manažerů nad nimi. A tak vzniká spoustu bloatwaru. Např. pulseaudio - původní myšlenka výborná, ale vylezl z toho obrovský moloch. Placené převážně redhatem. Nové desktopové nesmysly v ubuntu a gnome3 - RedHat + Canonical. Přebubřelé KDE4 - Nadace KDE. Nadace Mozilla - přijde mi, že do firefoxu a thunderbirdu už poslední dobou vymýšlejí spíš nesmysly, aby vykazovali nové verze. Všude nalezlí placení fulltime vývojáři a podle toho to poslední roky vypadá.

Mně se líbí třeba přístup oraclu - btrfs potřebovali pro sebe, tak si platili vývojáře. Nebo intel - má hardware, platí si vývojáře driverů do jádra. I ta nvidia nevymýšlí blbosti. Přijde mi, že i suse je tak nějak low-costové a soustředí se na užitečné věci.

Je to jako se státní správou - čím menší rozpočet bude, tím budou služby smysluplnější.

[little.owl]

Tak urcite by stalo vice veci dotahovat do konce, nez zacinat nove veci, ale vy k tomu tezko muzete nutit vetsinu neplacenych vyvojaru.

Nové desktopové nesmysly

Nesouhlasim, Gnome Shell je dobre reseni a spise je tam problem v nedostatku vyvojaru a rozhodne neni bloated - funkcionalita naopak spise chyby.

PulseAudio - moloch? V cem? Komplexni veci v realnem svete vyzaduji komplexni reseni a PulseAudio ma horsi povest nez je skutecnost. Co mu konkretne vytykate? Zde mate diagram, at se bavime trochu k veci.

Nadace Mozilla - přijde mi, že do firefoxu a thunderbirdu už poslední dobou vymýšlejí spíš nesmysly, aby vykazovali nové verze.

Musi drzet krok s Chrome a oslovit vetsinoveho Windowsiho uzivatele.

Mně se líbí třeba přístup oraclu - btrfs potřebovali pro sebe, tak si platili vývojáře.

RedHat dela to same, viz. jejich prace na kernelu, virtualizaci, selinuxu, opensdk ci treba i systemd; navic srovnani kulha, Oracle ani Intel nejsou ciste Linuxove firmy.

[Lol Phirae]

Nadace Mozilla - přijde mi, že do firefoxu a thunderbirdu už poslední dobou vymýšlejí spíš nesmysly, aby vykazovali nové verze.

Musi drzet krok s Chrome a oslovit vetsinoveho Windowsiho uzivatele.

Pokud si dobře vzpomínám, FF/TB vznikl proto, že z Mozilly se stal neuvěřitelný bloatware. No a hle, netrvalo to tak dlouho a ten bloatware tam nesmyslně cpou zpátky.

[little.owl]

Co byste zmenil a v cem se podle vas Firefox zhorsil?

[Lol Phirae]

Já myslím, že jsem dostatečně sdělil svůj názor na cpaní nesmyslného bloatwaru typu IM klient to TB/FF. Rovněž "miluju" kraviny typu ukradená startovací stránka z Chrome, která jen nesmyslně vytváří další databázi nejnavštěvovanějších/nejpoužívanějších stránek a nejde normálním způsobem vypnout. O jejich "zrychleném" vývojovém cyklu darmo mluvit, holt když si někdo myslí, že konkurenci doženu vyšším číslováním verzí, tak je to marný, marný a marný. Z uživatelských perliček ještě doplním nekonečné opruzování s "neplatnými" certifikáty. Zato CRL se pokud jsme si všiml stále defaultně nekontroluje. No co, proč taky. A to, že by FF měl používat systémové úložiště certifikátů, to evidentně nepochopí Mozilla nikdy, no ono je to výborný byznys, že, když tam přidávají takové "důvěryhodné" perly, jako je CNNIC.

[little.owl]

typu IM klient to TB/FF.

To tam fakt je?

[Lol Phirae]

TB 14, FF samozřejmě nesmí zůstat pozadu.

[little.owl]

Se po******, ja chci emailoveho klienta.

[dustin]

Wizard přidání nového účtu v TB je příšernost, která musela stát spoustu úsilí/peněz a je pořád naprosto nepoužitelná, která se akorát plete pod ruce. To je přesně příklad situace, kdy někdo řešil problém, který není. Nevěřím, že kdyby to dělal zadarmo, tak by se do takové obludy pustil.

Firefox - k čemu slouží permanentní přesouvání tlačítek stop/reload? To vše stojí peníze a užitek to nemá žádný.

[Lol Phirae]

TB už jsem vzdal. Tak je abych byl v obraze - ještě stále nelze nastavit SMTP server per-account normálním způsobem u nastavení každého účtu?

[little.owl]

Co pouzivate misto toho?

[Lol Phirae]

Claws Mail, i když v poslední době už spoustu pošty rovnou mažu, když dostanu notifikaci na mobilu.

[little.owl]

Firefox - k čemu slouží permanentní přesouvání tlačítek stop/reload?

To je prace na jedno odpoledne.

[dustin]

Funkce pulseaudia šly klidně zapracovat do userspace vrstev alsy. Není potřeba, aby běželo na windowsech ani na osx, to je další vrstva kompatibilit navíc. Tyto OS mají vlastní systémy. Spoustu z funkcí pulseaudia je duplicita nebo zpřehlednění alsy, bývalo by bylo lepší alsu dotáhnout, než dělat něco úplně nového. Ano, musí to být samostatný démon, knihovna typu dmix by už v tomto případě nestačila, ale to vše jde vyřešit. Původní cíl pulseaudia (flexibilní glitchfree playback šetřící baterii NTB, který umožňuje bez přerušení míchat streamy s různou latencí), byl zavalen mrakem dalších funkcí - viz právě ten link. Spoustu toho by se hodilo přímo do alsy jako pluginy. Teď je to tak, že přibývají userspace věci do alsy i do pulseaudia a nikdo už se v tom pomalu nevyzná, co kdy použít.

Gnome shell - upřímně nechápu vůbec, proč se nepokračovalo v gnome 2. Opravdu by gnome3 vzniklo bez vydatných finančních injekcí redhatu?

Ohledně redhatu - nesporně dělá spoustu užitečných věcí. Přijde mi, že to, co se týká jejich byznysu - serverové věci, to dělají výborně. Proto jsem psal, že se to týká některých oddělení RH. Podle mě to stále zapadá do původního tvrzení - když si to vyvíjejí pro svůj byznys, funguje to, když to dělají, protože na to prostě mají odněkud bokem prachy, je z toho moloch.

[little.owl]

Funkce pulseaudia šly klidně zapracovat do userspace vrstev alsy.

To je stale opakovany argument. PulseAudio je o level vyse a je jedno zdali vyvoj probihal v ramci alsy ci jako ted jako nezavisle v PulseAudio. Alsa mohla prijit s alternativou, neudelali to, meli na to nekolik let. Pamatuji si ten bordel pred PulseAudio a jsem rad ze to konecne ustalo.

byl zavalen mrakem dalších funkcí - viz právě ten link

Co byste tedy vyhodil a proc? Jak byste podobnou funcionalitu implementoval?

Gnome shell - upřímně nechápu vůbec, proč se nepokračovalo v gnome 2. Opravdu by gnome3 vzniklo bez vydatných finančních injekcí redhatu?

Nekdy je lepsi zacit znovu, s redukovanou zpetnou kompatibilitou, procistenou code base a s vyuzitim noveho grafickeho HW. Paradigma desktopu se zmenilo, nejde jen o nastup touch screenu. Vy vidite Gnome3 jako zlo, vyhozene penize, ja nikoliv; jen by mel byt jeho vyvoj rychlejsi.

[Bystroushaak]

Paradigma desktopu se zmenilo,

Paradigma desktopu je pořád stejné.

[little.owl]

Nikoliv.

[dustin]

V čem se tedy změnilo? Když přijdu do firmy, vidím, že lidé na PC pracují pořád stejně, možná trochu víc používají prohlížeč. To je z mého pohledu desktop, pracovní místo, ne zařízení na konzumaci obsahu typu tablet nebo smartphone.

[little.owl]

Tohle neni otazka radikalni zmeny, ale pomaleho posuvu, ktery bude patrny v pristich letech, ale znacneho na to abyste zacal narazet na limity stavajicich GUI a jak jsou aplikace ovladany. Krom zmineneho touch screenu se jedna o ovladani ala Kinect, treba v soucasnosti se investuje hodne penez do RGBD senzoru ci vyvoje systemu umoznujicich zjistit kam se na obrazovce divate ci hlasoveho ovladani (Microsoft koupil HTK a kupuje souvisejici patenty). Z hlediska obsahu, jedna se o a activity-centered desktop (cesky jak?), kdy je pracovni plocha vyscistena od vsecho, co by mohlo rusit a co nepotrebujete k vypracovani ulohy.

[Lol Phirae]

vyvoje systemu umoznujicich zjistit kam se na obrazovce divate

Na kozy a na <|>, to nemuseli investovat hodně peněz, stačilo se zeptat.

[dustin]

To jsou všechno věci pro domácí herní použití. Ve firmách nic takového není a hned tak nebude. Tam se musí koukat na produktivitu. Když přijdu na jednání, všichni mají normální notebooky, nejčastěji s winxp. A řeší špatnou wifinu, zasekanou poštu, malé povolené přílohy do pošty, nefunkční nebo omezený přístup na internet, atd. Pořád to samé, deset posledních let. A activity-based desktop? To normální uživatel vůbec nepochopí, kolik lidí přešlo z windows na linux a dodnes používá jenom jeden desktop. Kdo bude v těch firmách platit proškolení, když byznys přínos zcela jistě neobhájí? U ribbonu jim nic jiného nezbylo, microsoft jim to dal befelem. K čemu je to dobré redhatu?

[okko]

Bože, to jsou kraviny. Jedna větší než druhá. Kinect, hlasové ovládání a senzor toho, kam se koukám - k čemu to může být použitelné - mimo pár stupidních her a interaktivního porna?

[little.owl]

Zvysi to produktivitu prace a usnadni interakci s pocitacem, na server to nebude. Penize tam jiz smeruji a kdo to dotahne do pouzitelneho stavu a snizi chybovost na prijatelnou uroven, vydela.

[Michal Kubeček]

To mi připomnělo jednu stránku s přehledem různých předpovědí Billa Gatese na téma hlasového ovládání…

[little.owl]

To chapu. Ja tyhle veci trochu delam a tak jsem opatrny, vsechno funguje tak na 90% za idealnich podminek a to je malo. Zatim nejblize pouzitelnosti je rozponavani jednoduchych gest a sledovani kam uzivatel kouka, rekneme v rastru 16:9, coz by na ctverce ve Win 8 mohlo stacit, nicmene HW je stale prilis drahy.

[Lol Phirae]

rozponavani jednoduchych gest

Jako třeba "jednička"?

[Michal Kubeček]

Technická realizovatelnost je IMHO jen jedna polovina problému. Když se podívám na nějakou sci-fi z osmdesátých let, tak tam lidé zásadně komunikují videotelefonem. Dnes už by to po technické stránce nebyl nijak zásadní problém - ale ukazuje se, že o to uživatelé většinou nestojí.

Já jsem všeobecně dost skeptický k různým vizionářům a předpovědím, jak ta či ona technologie změní svět. Podle mne historie ukazuje, že ty skutečně revoluční technologie, které nějak zásadně ovlivnily svět techniky, většinou nebyly provázeny podobnými fanfárami a nadšenými předpověďmi. A naopak, ty, u jejichž kolébky stála velká očkávání a velkolepé předpovědi, máloky dokázaly tato očekávání naplnit.

[Lol Phirae]

Když se podívám na nějakou sci-fi z osmdesátých let, tak tam lidé zásadně komunikují videotelefonem. Dnes už by to po technické stránce nebyl nijak zásadní problém - ale ukazuje se, že o to uživatelé většinou nestojí.

Ten videotelefon by se občas hodil. Např. když otravuje nějaký agent s teplou vodou.

> Dobrý den, taky Josef Neodbytný, Česká zlodějská vzájemná pojišťovna. Neruším?

>> Ale vůbec ne, právě mám volnou chvilku. Ano, jistě že mám váš návrh smlouvy po ruce, právě se mi velmi hodí... (záběr na záchodovou mísu)

[little.owl]

Dnes už by to po technické stránce nebyl nijak zásadní problém - ale ukazuje se, že o to uživatelé většinou nestojí.

Protoze jim to s ohledem na vysokou cenu nic neprinasi a az bude HW stat par penny, bude to vsude.

[Michal Kubeček]

Protoze jim to s ohledem na vysokou cenu nic neprinasi a az bude HW stat par penny, bude to vsude.

Přes Skype to mají zadarmo a hardware stojí pár stokorun (v notebooku je často rovnou integrovaný). Přesto to využívá málokdo - většinou si to jednou nebo dvakrát vyzkoušejí a pak se na to vykašlou.

[little.owl]

Dovozovat na zaklade uzivani videocallu Skypu nezajem uzivatelu o nove technologie je zcestne, zejmena pokud tento predpoklad je nepravdivy a Skype kvuli tomu v posledni dobe lanaril embedded inzenyry se zkusenostmi s video steamingem po cele Evrope.

[kavol]

... komunikují videotelefonem. Dnes už by to po technické stránce nebyl nijak zásadní problém

mno ...

(pozornosti doporučuju zejména #811503)

ale ukazuje se, že o to uživatelé většinou nestojí.

většinou jako ve většině případů asi (nebo spíš určitě) ne, většinou jako většina uživatelů dost možná ano - třeba po nás furt někdo chce, abychom ukazovali dceru ...

[okko]

škoda, že neděláte na tom ovladači pro porno. Možná bych přispěl na vývoj. Abyste nemusel umřít v chudobě a opuštění.

[dustin]

Žádný bordel neustal, jenom audio aplikace implementovaly další sink navíc. Takže nyní místo alsy a jacku podporují ještě pulseaudio.

Řada modulů pulseaudia by bývala šla bez problémů jako pluginy alsy (síťování, hlasitost přes zdroje streamu, resamplování pro dvě a více zvukovek), stačilo vyčistit zdrojáky kernelu a nemuselo se dělat mapování spektra ovládacích prvků driverů na pár standardizovaných v pulseaudiu, které stejně často pořádně nefunguje, protože to pořád záleží na kódu driveru. Jasně že by z toho nakonec vzešla vrstva driverů, low-level lib typu libc a pak vrstva user-space knihovny včetně nějakého démona, pokud by lidi potřebovali glitch-free playback. Takhle je pulseaudio, které komunikuje s low-level alsou a vedle toho paralelně stále roste a rozvíjí se user-space alsa - pořád spolehlivější s nižšími nároky na zdroje.

Realita je taková, že nakonec za pár let user-space alsa zahyne úplně, protože za ní nestojí žádná firma, a všechno převezme nafouklé pulseaudio (RH plus canonical).

A gnome 3 - co mi přináší lepšího než gnome 2?

[little.owl]

Žádný bordel neustal,

Pak zijete v jinem svete. Problemy co jsem mel s alsou a oss, kdy mi nechodilo aplikace spolecne ci nesla poradne kontrolovat hlasitost jedne z nich, uz davno nemam, o problemech s bluetooth sety radsi nemluve.

Takže nyní místo alsy a jacku podporují ještě pulseaudio.

Staci kdyz podporuji PulseAudio a pak vam to chodi i na FreeBSD a jinde.

Řada modulů pulseaudia by bývala šla bez problémů jako pluginy alsy ...

Porad dokola, ano mohlo to byt v alse, alsa to nebyla schopna roky udelat, je to v PulseAudio.

ovládacích prvků driverů na pár standardizovaných v pulseaudiu,

Normalni pristup, aplikace potrebuji nejaky genericky interface.

a vedle toho paralelně stále roste a rozvíjí se user-space alsa - pořád spolehlivější s nižšími nároky na zdroje. Realita je taková, že nakonec za pár let user-space alsa zahyne úplně,

Trochu si zde protirecite.

A gnome 3 - co mi přináší lepšího

Nevim, co prinasi vam, ale mne se v nem lepe pracuje a vyhovuje mi ovladani klavesnici a mene preplacany desktop.

[dustin]

V alse už je defaulně nastavený dmix řadu let. Takže s blokováním aplikací žádný přístup už pár let není. Nastavení hlasitosti jedné konkrétní aplikace v alse nikdy nebylo, takže s ním problémy být nemohly. Upřímně - kolik lidí to v reálu používá? A navíc to dát do alsy by nebyl žádný problém.

Já netvrdím, že dnes nemá pulseaudio žádný smysl. Samozřejmě má a bude stále důležitější, protože vývoj vyšších vrstev alsy se defacto zastavil. Argument - to se zaimplementuje do pulseaudia. Proto předpokládám reálný vývoj, nemá smysl jít proti proudu.

Ovládám gnome 2 bez problémů klávesnicí, to je to první, co si nastavím. V čem konkrétním mi gnome 3 pomůže? Kdybych měl cash a rozhodoval se, do čeho jej vložím, určitě bych neplatil drahé vývojáře, aby znovu vybudovali něco, co už funguje. Nepokrytých oblastí je spoustu, např. si zkuste jednoduchou videokonferenci s kvalitní kamerou a HD televizí po internetu, dodnes není dotažené btrfs, spoustu aplikací pořádně nezvládlo přechod z V4L na V4L2, atd. atd.

[kavol]

... nehlede k tomu ze naklady nejsou tak velke.

[Citation needed]

Pokud jsou jejich projekty spatne, ostatni distribuce je nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni.

naše zkušenosti se dosti zásadním způsobem liší ...

[little.owl]

... nehlede k tomu ze naklady nejsou tak velke.

[Citation needed]

Odhadnete pocet clovekohodin a naklady na vyvojare, kolik lidi na tom pracuje vite.

Pokud jsou jejich projekty spatne, ostatni distribuce je nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni.

naše zkušenosti se dosti zásadním způsobem liší ...

To je objektivni fakt. Pokud RedHat/Fedora neco navrhne/naimplementuje, nikdo nenuti ostatni distribuce to pouzivat. V realu, vetsinu veci adoptuji. Chcete to poprit?

[kavol]

Odhadnete pocet clovekohodin a naklady na vyvojare, kolik lidi na tom pracuje vite.

nevím

vím tak akorát že prerekvizita pro tuto featuru konkrétně v našem týmu jen za minulý týden sežrala minimálně dva člověkodny navíc, a to byl jen jeden "drobnej" problémek s jednou komponentou, a to jich máme 351 ...

Pokud jsou jejich projekty spatne, ostatni distribuce je nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni.

naše zkušenosti se dosti zásadním způsobem liší ...

To je objektivni fakt. Pokud RedHat/Fedora neco navrhne/naimplementuje, nikdo nenuti ostatni distribuce to pouzivat. V realu, vetsinu veci adoptuji. Chcete to poprit?

ROFL

... nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni

vs

V realu, vetsinu veci adoptuji.

[little.owl]

vím tak akorát že prerekvizita pro tuto featuru konkrétně v našem týmu jen za minulý týden sežrala minimálně dva člověkodny navíc, a to byl jen jeden "drobnej" problémek s jednou komponentou, a to jich máme 351 ...

Tak jiste, integrace muze vyzadovat vice casu nez Lennartovi implementace. Ma to chlapik dobre vymyslene, slizne smetanu za design a vy to oddrete

... nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni

Negace se vztahovala k predchozi vete "Pokud jsou jejich projekty spatne, ....".

[kavol]

Negace se vztahovala k predchozi vete "Pokud jsou jejich projekty spatne, ....".

jistě, špatné jsou právě ty, které se nepřebírají, a ty co se přebírají jsou automaticky dobré, že?

[little.owl]

a ty co se přebírají jsou automaticky dobré, že?

Rekl jsem neco takoveho? Nicmene pokud by byla k dispozici lepsi varianta, spise by to toho nesli, nemyslite?

[kavol]

a ty co se přebírají jsou automaticky dobré, že?

Rekl jsem neco takoveho?

v tom případě jsou tedy ale dohady o to, že byla uvedena podmínka "Pokud jsou jejich projekty spatne", docela irelevantní ...

moje zkušenost je, že se bohužel přebírá každá píčovina, i když není dle mého názoru dobrá

tedy rozporoval jsem výrok, že "zkusenost spise ukazuje, ze [ty špatné se neadoptují]"

na což mi bylo odpovězeno, že je "objektivni fakt" (sic!) že "V realu, vetsinu veci adoptuji."

takže buď se stále bavíme v kontextu "pokud jsou špatné", a v tom případě reakce "vetsinu veci adoptuji" popírá původní tvrzení, anebo ne, a pak je taková argumentace, která většinu věcí označuje automaticky za dobré, protože se přebírají, tedy špatné jsou právě ty, co se nepřebírají, tak trošku na hovno - já mám tedy poněkud jiná kriteria na to, co považuju za dobré, než kolik kokotů se rozhodne dělat to samé (aneb, jak byla ta hláška, "jezme hovna, miliardy much se přeci nemohou mýlit, co je dobré"?)

Nicmene pokud by byla k dispozici lepsi varianta, spise by to toho nesli, nemyslite?

viz výše ... a také - co znamená "lepší"? ... může tady být výborné technické řešení, které prohraje s totální sračkou, protože tu sračku prostě klíčoví hráči protlačí, viz Betamax vs VHS, OS/2 vs Windows, FireWire vs USB, a teď nově upstart/openrc/launchd/... vs systemd

[little.owl]

Psal jsem:

Pokud jsou jejich projekty spatne, ostatni distribuce je nemusi adoptovat a zkusenost spise ukazuje, ze tomu tak neni.

=> Tvrdim, ze na zaklade vysoke miry adopce, jejich projekty nejsou vetsinou spatne.

Vy rikate, ze mate jinou zkousenost:

naše zkušenosti se dosti zásadním způsobem liší ...

a ja odpovidam:

To je objektivni fakt. Pokud RedHat/Fedora neco navrhne/naimplementuje, nikdo nenuti ostatni distribuce to pouzivat. V realu, vetsinu veci adoptuji. Chcete to poprit?

Vy z toho vyvozujete, ze rikam:

jistě, špatné jsou právě ty, které se nepřebírají, a ty co se přebírají jsou automaticky dobré, že?

A ja odpovidam:

Rekl jsem neco takoveho? Nicmene pokud by byla k dispozici lepsi varianta, spise by to toho nesli, nemyslite?

Smer me argumentace by snad mohl byt jasny.

moje zkušenost je, že se bohužel přebírá každá píčovina

Muze byt, nicmene Lennartoviny mi vetsinou prijdou podlozene, zdali to musi byt priorita je vec jina.

které prohraje s totální sračkou, protože tu sračku prostě klíčoví hráči protlačí, viz Betamax vs VHS, OS/2 vs Windows, FireWire vs USB, a teď nově upstart/openrc/launchd/... vs systemd

Nejlepsi technicke reseni nemusi vzdy vyhrat, jsou tam i jine vlivy, nicmene oznacit jakoukoliv z vyse zminenych technologii za totalni sracku bych si netroufl.

[kavol]

MUHEHE

Tvrdim, ze na zaklade vysoke miry adopce, jejich projekty nejsou vetsinou spatne.

vs

Vy z toho vyvozujete, ze rikam:

jistě, špatné jsou právě ty, které se nepřebírají, a ty co se přebírají jsou automaticky dobré, že?

A ja odpovidam:

Rekl jsem neco takoveho?

takže "nejsou špatné" neznamená, rozhodujeme-li se binárně a nemáme-li v možnostech zlatý neutrální střed, zhruba totéž, co "jsou dobré"?

hele, už mě to nebaví ...

[little.owl]

Nejsou spatne znamena, ze nejsou spatne, a rozhodne ne "automaticky dobré", jak jste si odvodil.

[Michal Vyskočil]

a teď nově upstart/openrc/launchd/... vs systemd

Vzhledem k tomu, že systemd je prakticky opajcnutý launchd bez XML konfigurace, mi to versus přijde trochu legrační

[pavlix]

systemd je prakticky opajcnutý launchd

Jestli je „opajcnutý“ tak, aby z toho byl dobrý výsledek, tak proč ne :). Klidně se může srovnávat s originálem.

bez XML konfigurace

Což bych v tomto konkrétním případě považoval za výhodu. Ta konfigurace není tak složitá, aby vyžadovala overkill typu XML. (Tím úplně nechávám stranou posouzení, zda je XML vhodné či nevhodné pro komplikovanou konfiguraci typu libvirt.)

[little.owl]

V podstate ano a ve FreeBSD maji launchd port, u Linuxu by asi byl problem s licenci.

[kavol]

V podstate ano a ve FreeBSD maji launchd port, u Linuxu by asi byl problem s licenci.

nikoli, u linuxu je problém s tím, že slovo Lennartovo je slovo boží

[pavlix]

Tak ho přestaňte poslouchat :).

[kavol]

jak dobře víš, to neříkáš tomu pravému, jsem ateista :-p

ale vážně - víš o nějakém jiném důvodu, proč nepoužít launchd, kromě nabubřelého ega, že si přeci musí napsat vlastní implementaci, že nebýt sám upstreamem (resp. zakladatelem projektu) nýbrž jen obyčejným přispěvatelem do jiného upstreamu, není pro Lennarta dostatečně cool?

Apache licence je pro použití ve Fedoře ok

problém zlého upstreamu lze eventuelně vyřešit forkem

tak wo co sakra go, proč se vynalejzá znova kolo, který je ale by design tak trochu šišatý, takže se pro něj staví vlnitý cesty, když už je kolo dávno vynalezený a stačí ho jen zkopírovat a trochu vypulírovat?

[pavlix]

ale vážně - víš o nějakém jiném důvodu, proč nepoužít launchd, kromě nabubřelého ega, že si přeci musí napsat vlastní implementaci, že nebýt sám upstreamem (resp. zakladatelem projektu) nýbrž jen obyčejným přispěvatelem do jiného upstreamu, není pro Lennarta dostatečně cool?

Vůbec netuším. Ani neznám launchd tak dobře, abych to mohl posoudit.

[pavlix]

Ale vždycky jsem měl za to, že systemd stojí na cgroups, což launchd nevím jak ty stejné věci řeší.

[little.owl]

Nejen cgroups, ale i SELinux; systemd je vice integrovan s Linux kernelem a s vecmi jako d-bus. Navic proc mit tak klicovou cast systemu pod kontrolou Apple.

[pavlix]

A CUPS se má nahrazovat ze stejného důvodu? :)

[little.owl]

CUPS je obycejny userspace daemon ....

[pavlix]

Jakoby systemd nebyl userspace :) a jako by to nějak souviselo s těmi důvody, proč se který z nich nahrazuje :).

[kavol]

Ale vždycky jsem měl za to, že systemd stojí na cgroups,

a to má být výhoda? - zkus se na toto téma, systemd a cgroups, zeptat interně

což launchd nevím jak ty stejné věci řeší.

hmmm ... a musí je řešit?

[little.owl]

a to má být výhoda?

Radsi bych mel vsechno jen v cgconfig.conf. Jaka je Lennartova argumentace pro integraci?

[pavlix]

Trošku nerozumím otázce. Poskutnutí skupiny každé systémové služby je snad jedním z hlavních smyslů systemd. Nějak mi úplně není jasné, jak do toho zapadá cgconfig.

[little.owl]

Nevyjadril jsem se presne.

Poskutnutí skupiny každé systémové služby je snad jedním z hlavních smyslů systemd.

Jednim ze smyslu. Radsi bych to tam nemel a kontroloval vse nezavisle pres libcgroups a nejaky tool, neb pokud jsem mel problemy se systemd, tak to bylo prave zde (trebas chovani ke skupine pri restartu sluzby).

[pavlix]

Já chápu, že jsi měl se systemd problémy, ale ono je potřeba vědět jaké a proč a jestli bylo možné je vyřešit. Já s ním momentálně závažné problémy nemám nebo si jich nejsem vědom. Jinak bych se s chutí pustil do kritiky. Jediné, co mi úplně 100% nevyhovuje je ovládání a výstup systemctl, takže bych byl docela rád, kdyby příkaz „service“ v nějaké podobě zůstal... a kdyby nikdo nevymýšlel cypoviny typu že některá služba bude .target a ne .service.

[little.owl]

systemctl mi nevadi. Vadi mi, ze treba pri restartu ssh mi systemd pres cgroups bonding zavre vsechny otevrene session, coz mi na podzim zpusobilo horke chvilky. Radsi bych tam tuhle ficuru nemel.

[pavlix]

a to má být výhoda?

Dle mého názoru je to nejen výhoda, ale klíčová vlastnost. Ale sám víš, jak často se naše názory liší :).

hmmm ... a musí je řešit?

Na tuto otázku jsem schopný odpovědět pouze pokud ji konkretizuješ. Tedy pokud napíšeš něco, co systemd řeší a přitom vůbec není užitečné to řešit.

[kavol]

a to má být výhoda?

Dle mého názoru je to nejen výhoda, ale klíčová vlastnost. Ale sám víš, jak často se naše názory liší :).

mno, můj názor je, že to výhoda být může a někdy ... nadšený pokec Honzy Šafránka ještě s Ivanou Vařekovou blahé paměti na toto téma jsem si vyslechl se zájmem, už si z toho nicmoc konkrétního nepamatuju, ale že by to bylo něco, co je potřeba nacpat všude a všude to bude přínosné, tento dojem z toho na mně neulpěl ...

co se týče názoru tvého ... už ses poptal?

hmmm ... a musí je řešit?

Na tuto otázku jsem schopný odpovědět pouze pokud ji konkretizuješ. Tedy pokud napíšeš něco, co systemd řeší a přitom vůbec není užitečné to řešit.

a které "ty stejné věci" jsi měl předtím na mysli ty?

[pavlix]

co se týče názoru tvého ... už ses poptal?

Nejsem v práci, netuším koho a ani to není moje priorita. Když už tam přijedu, mívám toho docela dost.

a které "ty stejné věci" jsi měl předtím na mysli ty?

Například právě to, aby bylo možné sestřelit službu a ohlídat si, že je sestřelená.

[kavol]

Například právě to, aby bylo možné sestřelit službu a ohlídat si, že je sestřelená.

a to se řeší přes cgroups? - měl jsem zato, že ne ... jak konkrétně to launchd řeší nevim, ale prej řeší, takže to není úplně dobrej příklad věci k tématu, co systemd umí "navíc" dík cgroups a umět by nemusel

jinak AFAIK kus funkcionality cgroups na BSD umí jail, byl by tak velkej problém to v launchd abstrahovat a používat backend podle toho, na kterým jádře to běží, případně pokud to nejde rozumně abstrahovat, tak pro příslušnou funkcionalitu mít dvě (a více, není jen Linux a BSD) větve, stálo by to víc úsilí než přepisovat celej launchd od nuly do systemd a udržovat různý dva projekty celý?

[pavlix]

a to se řeší přes cgroups? - měl jsem zato, že ne ... jak konkrétně to launchd řeší nevim, ale prej řeší, takže to není úplně dobrej příklad věci k tématu, co systemd umí "navíc" dík cgroups a umět by nemusel

Ty jsi chtěl příklad toho, co nevím, jak launchd řeší. Četl jsem, že cgroups se používají mimo jiné k tomu, aby byly známé všechny procesy, které jsou součástí služby a šlo tak například ohlídat, aby nějaký proces nezůstal. Takže máš příklad něčeho, co netuším jak launchd řeší.

jinak AFAIK kus funkcionality cgroups na BSD umí jail, byl by tak velkej problém to v launchd abstrahovat a používat backend podle toho, na kterým jádře to běží, případně pokud to nejde rozumně abstrahovat, tak pro příslušnou funkcionalitu mít dvě (a více, není jen Linux a BSD) větve, stálo by to víc úsilí než přepisovat celej launchd od nuly do systemd a udržovat různý dva projekty celý?

Opět... přinášíš zajímavou otázku, která napadla i mnohé jiné z nás. Zajímavější by pro mě osobně bylo, kdybys na ni znal i nějakou relevantní a dobře podloženou odpověď, i kdyby třeba obsahovala subjektivní závěr.

[kavol]

a teď nově upstart/openrc/launchd/... vs systemd

Vzhledem k tomu, že systemd je prakticky opajcnutý launchd bez XML konfigurace,

... zato se spoustou jiných übercool vychytávek (když se ti konfig v xml zdá složitej, tak co říkáš na binární logy?)

mi to versus přijde trochu legrační

a ten rozdíl je právě v tom "prakticky"

von třeba ten ohnivej drát a USB je taky "prakticky" to samý, nějaký blbý sériový rozhraní ... akorát když si to pak někdo prakticky vyzkouší, že na jednom, který má teoretickej limit 400 Mb/s dává skoro 50 MB/s s prstem v nose, a na druhým, který má teoretickej limit 480 Mb/s, dává s bídou nějakejch 20 MB/s, když má super procesor tak i možná ke 40 MB/s, ale to se mu z toho procesoru pěkně kouří, tak se nestačí divit, že ...