Dění kolem XScreenSaveru v Debianu

Uživatel "staré" verze XScreenSaveru je na tuto skutečnost upozorněn. Co když je ale "starý" XScreenSaver součástí "nového" stabilního Debianu a jeho uživatelé jsou na "stáří" XScreenSaveru upozorňováni (Debian Bug #819703)? Odstranit upozornění ze zdrojových kódů je snadné. Co když si to ale autor Jamie Zawinski (jwz) nepřeje a pokud nebude XScreenSaver v Debianu pravidelně aktualizován, tak žádá o odstranění XScreenSaveru z Debianu? Dějí kolem XScreenSaveru v Debianu se věnuje v příspěvku na svém blogu také Matthew Garrett (mjg59).

6.4.2016 00:11 | Ladislav Hagara | Komunita

Komentáře

[pavlix]

Zase lidi řešej kraviny. Debian je stabilní distribuce. Distribuuje starý software. Nikoho to nepřekvapuje. Kromě autora jednoho konkrétního software, který s tím má problém a přeje si, aby ten jeho problém distributoři řešili podle jeho přání. To je stejné jako když lidi od SixXS překvapuje, že uživatelé chtějí startovat tunel automaticky.

[Jardík]

Neznám sice důvod, proč to autor nechce (jsem líný číst). Tuším ale, že to má co dělat s bezpečností. Prostě jsou v nové verzi opraveny a autor není rád, když jsou uživatelé "nuceni" používat starou verzi s chybami.

[trekker.dk]

Problém je v tom, že autor považuje všechny změny za opravy bezpečnostních chyb, protože xscreensaver je bezpečnostní software. Správci v Debianu s tím nesouhlasí, protože se mezi jiné jedná o změny typu "přidal jsem nějaké píšťalky a zvonečky" (což je něco, co bezpečnostní chyby neopravuje, ale může to naopak nějaké zavléct)

Opravy bezpečnostních chyb jsou - v rámci možností, jako vždy u distribuce spravované hlavně dobrovolníky - backportovány.

[Xerces]

xscreensaver je bezpečnostní sw? Já měl za to, že to je jenom kravinka pro hračičky "spořič" obrazovky.

[Michal Kubeček]

Záleží na tom, jestli se na to díváte jako na screen saver nebo screen locker. Troufnu si tvrdit, že nemalá část uživatelů ho primárně používá jako to druhé a pokud takový program kvůli chybě umožní odemčení bez znalosti hesla, je to vážný bezpečnostní problém.

[Xerces]

Hmm. No pro konzoli asi něco takového neexistuje, co? Příjde mi, že je lepší udělat logout když někam jdu a pak se zase přihlásit, než vymýšlet nějaký harakiri.

[Michal Kubeček]

Existuje: vlock (umí i zablokovat přepínání VT, takže není potřeba zamykat každý VT zvlášť).

[pavlix]

Používám physlock.

[Jendа]

Fakt se mi nechce při každém probuzení notebooku nebo po každém odběhnutí znovu spouštět všechny programy (terminály, SSHčka, dokumenty, Firefox startuje dlouho…).

[Michal Kubeček]

Ta poslední věta se IMHO týkala jen těch textových VT, na které se ptá předtím. Varianta, že by někdo pokaždé dobrovolně shazoval celou session desktopového prostředí, mi připadá příliš absurdní.

[Xerces]

Nevím. Já to tak dělám. Mám nastaveno obnovení session a buďto jdu jen na chvíli pryč a neodhlašuju se, nebo jdu na dýl a odhlásím se.

[pavlix]

Taky to považuju za absolutně nevyhovující. Už jen kvůli odhlášení VPN a všech možných komunikačních prostředků.

[Jendа]

Ano. Závisí na něm, jestli se útočník dostane do cizího počítače.

(btw. někdo mi tam radil, že KDE5 má screenlocker udělaný dobře. No… ne.)

[Xerces]

Chápu, dík. BTW: Nerad bych se dožil doby, kdy v Linuxu budou implementovány funkce jako u AŽD.

[Jardík]

Opravy bezpečnostních chyb jsou - v rámci možností, jako vždy u distribuce spravované hlavně dobrovolníky - backportovány.

Já bych jen dodal, že opravdu "v rámci možností". V debianu je dost softwaru, kde na backporty oprav prostě nemají lidi. Příkladem za vše budiž WebKit, kde prostě backporty ani bezpečnostních nezvládají.

[Rezza]

No ono je to opačně - tam kde jsou jen dobrovolníci, tam se těžko backportuje. Protože je to celkem časově náročná činnost a je jednodušší udělat rebase. Ve Fedoře se to tak dělá. Ale v komerčních distribucích, kde je kupa lidí, tam se backportuje, protože si za to platí zákazníci.

[ikar]

Ve Fedoře se nebackportuje, ve Fedoře se vydává každého půl roku nová verze se stejnými neopravenými chybami v aplikacích. Například dosbox je i v poslední Fedoře dodáván ve své 64 bitové verzi s chybou, na kterou je patch známý už přes dva roky. Jedná se o blbou emulaci FPU, která způsobuje nefunkčnost a havárii všech programů, které FPU používají. Přesto, že se jedná o pár řádek patche na jeden soubor, tak je to pro lidi z Fedory nepřekonatelný problém. Zřejmě proto, že mají plno práce s tím, jak do ní natahat tuny zbytečných kravin, které po nich nikdo nechce. Ani zákazníci RedHatu, btw.

[Rezza]

Jelikož je to distribuce, která stojí na dobrovolnících, není nic jednoduššího jak opravit chybu, než se stát contributorem . Prostě čím víc leaf balíček, který používá míň lidí a maintainer už ztratil třeba i svůj zájem, tím horší. To uznávám. Ale prostě pokud někoho z komunity baví vrtat do systemd, tak nebude vrtat do dosboxu. A pokud to není nějaká fakt důležitá komponenta pro release, tak je těžké někoho donutit, ať dělá to, co ho nebaví. Vždycky jde rozjet non responsive maintainer process, někdy to lidi donutí se starat nebo komponentu předat dál.

[koroptev]

takze je to vlastne takovy piskoviste pro deti, co si rady hrajou, a nektery - ty oblibeny - hracky jsou nalesteny a jiny (vetsina) lezej polorozbity polozahrabany v pisku

[Rezza]

Tak on se ani jinak software delat neda a je jedno, jestli komercni ci nekomercni. Hlavni je, udrzet pri sobe, co lidi vidi a co nevidi, to je vedlejsi. Bohuzel ani nekonecne mnozstvi lidi/zdroju a casu by asi neznamenalo lepsi vysledek (je to videt u mega korporaci, ktere maji neomezene prostredky a nekdy nejde poznat rozdil od poctiveho garaznika :).

[koroptev]

chlape, to jsou kecy jak vole hrozny kecy ale

zjevne ma vsechno nejakou miru, zjevne je nekde ta mira vetsi a nekde mensi.. hazet vsechno za hlavu s tim, ze stejne to musi stat z principu veci za hovno.. ok, beru to tak, ze tohle si myslite ve Fedore

[lazywriter]

Paneboze, jak vznikla ta prvni veta? Nejak tahle:

python -c "import random; print ' '.join([random.choice(['vole', 'kecy', 'hrozny', 'ale']) for _ in xrange(10)])"

?

[koroptev]

Ne, byl pouzit Perl

[Rezza]

Nerikam, ze me to neni lito. Kdyz jsem zaviral EOL bugy, kazdy release nekolik tisic, tak jsem se podival a byl jsem smutny, kdyz nekde byl patch prilozen a zavreno neaplikovano. Ale ono obcas i aplikovat patch, co nekde lezi, neni bez problemu. Proste kdyz se jedna o leaf vec, kde je jeden developer, jeden maintainer v distribuci a jeden uzivatel, tak to proste ma nizsi prioritu. Ale porad dame tem lidem sanci to mit v distribuci. Nejsme korporace, kde by se to okamzite z toho duvodu zabilo, protoze se to nezaplati :). Ten set balicku, kde se vice dba na funkcnost, je to, co se vydava a je soucasti nektereho z release blocking deliverables. Ano, mohli bychom to zase rozdeli na core a extras, ale...

[Michal Kubeček]

Trochu mi to připomíná situaci kolem 32-bitové verze openSUSE Leap 42.1. Na jedné straně obrovský poprask, jak si to Coolo představuje, jak k tomu přijdou ty tisíce uživatelů starých počítačů ve třetím světě atd. Ale na výzvu, ať ty image tedy někdo z těch, kdo je považují za tak nepostradatelné, udělá, se nenašel nikdo. Na rozdíl od aarch64 nebo ppc64…

[Rezza]

Jo, to je klasika :).

[ikar]

Jelikož je to distribuce, která stojí na dobrovolnících, není nic jednoduššího jak opravit chybu, než se stát contributorem

No fajn, jenže a) nejsem programátor b) jsem zaměstnaný a mám rodinu c) do linuxu jsem přispíval posledních dvacet let a už mě to fakt nebaví - už jenom to odstraňování hovadin, které tam přidávají nadšenci z "komunity" - takoví ti co je "baví se vrtat v systemd". Vidím, že to není jen problém Fedory, ale i třeba Debianu. Ale to, že jsou v distribuci balíčky s nefunkčními aplikacemi, táhnoucími se přes několik vydání, to je prostě ostuda. Ostuda toho, kdo takové distribuce vypustí do světa.

[tom]

Myslim, ze nebudu podporovat hrani deti(RHELL), kteri nevi co to je odpovednost.

[MaT]

Co je "RHELL"?

[Jendа]

Jelikož je to distribuce, která stojí na dobrovolnících, není nic jednoduššího jak opravit chybu, než se stát contributorem .

Ale ten patch existuje, stačí ho aplikovat…

[trekker.dk]

Kde existuje? (Takový patch, který opravuje jenom bezpečnostní chybu v xscreensaver - nebo závažnou chybu funkcionality - ale nepřidává další změny.)

[Lol Phirae]

Si ho musíš najít a vykuchat sám z releasu. Přece autor nebude měnit svoje zvyklosti a používat nějaké divné věci jako cvs, svn nebo nedejbože git.

[Jendа]

V tomto vlákně se řeší dosbox.

[Lol Phirae]

Sice nevím, proč se pod článkem o xscreensaveru řeší dosbox, ale ten problém s FPU je dávno opravený v upstreamu.

[pavlix]

Ve Fedoře se nebackportuje,

Vždyť to tvůj předřečník psal,

Například dosbox je i v poslední Fedoře dodáván ve své 64 bitové verzi s chybou, na kterou je patch známý už přes dva roky.

Jestliže je patch známý přes dva roky, proč není v upstreamu. Distribuce nejsou od toho, aby suplovaly upstreamový vývoj. Mimochodem, když už si potřebuješ postěžovat v diskuzi, připoj aspoň odkaz na konkrétní nahlášený problém.

[ikar]

Ve Fedoře se nebackportuje,

Vždyť to tvůj předřečník psal,

Ano psal. A?

Jestliže je patch známý přes dva roky, proč není v upstreamu. Distribuce nejsou od toho, aby suplovaly upstreamový vývoj. Mimochodem, když už si potřebuješ postěžovat v diskuzi, připoj aspoň odkaz na konkrétní nahlášený problém.

Proč není v upstreamu netuším, to se musíš ptát jinde. Proč bych měl dávat odkazy na něco, co není předmětem diskuse, kór když si to každý může během vteřiny najít na webu? Že 64 bit dosbox nefunguje je zmíněno dokonce i na wiki. Já jsem dosbox uváděl jen jako příklad aplikací, které nefungují/fungují blbě a tvŮrci distribucí se ani nezalamují tím, aby aplikovali známé patche.

[pavlix]

Proč není v upstreamu netuším, to se musíš ptát jinde.

No nevím. Házet špínu na jednotlivé distribuce kvůli tomu, že upstream dosud nezačlenil nějaký patch, to mi přijde dost mimo.

[ikar]

Letmý pohled do Googlu mi dal hned jako prvý odkaz https://bugzilla.redhat.com/show_bug.cgi?id=1049658, kde se dočítám, že chyba byla opravena už v lednu 2015, za dob Fedory 20. Distribuční 64 bit rpm ale dosud nefunguje (F22, F23) - stále používá 64 bit SSE tam kde má být 80 bitů FPU. Takže jsem špínu házel oprávněně. Nechápu, co tě nutí k tomu věčnému oportunismu.

[pavlix]

Oportunismu? Jsi si jistý významem toho slova? :D

Upstreamový bug je stále otevřený. Je tam sice komentář o opravě, ale zjevně mají důvod, proč to nezavřeli. Vydal upstream opravenou verzi?

Jinak maintainer ve Fedoře očividně nereaguje, ale na druhou stranu tam už dlouho není ani update od nikoho jiného. V takovém případě je dobré maintainera popohnat nebo vyměnit, což sice chvilku trvá, ale problém to řeší. Ovšem základem je mít v pořádku upstream, takže pokud nevydali opravnou verzi, neházel jsi špínu oprávněně.

[ikar]

Oportunismu? Jsi si jistý významem toho slova? :D

Pravda, ve tvém případě je to spíše odportunismus

zjevně mají důvod, proč to nezavřeli.

Mně to tedy zjevné není. Po aplikování uvedeného patche dosbox stabilně a normálně funguje i na 64 bitu, takže problém s kvalitou patche asi nebude.

Tvoji argumentaci neberu - viděl jsi někdy zdrojové balíky aplikací Fedory? Běžně jsou v nich i desítky patchů proti upstreamovým tgz. Mnoho programů, i zcela okrajových (kterýmž dosbox určitě není) má v každé verzi Fedory nové patche. Z toho mi plyne, že nejdůležitějším článkem je maintainer balíku, nikoliv nějaké "základem je mít v pořádku upstream". Ve Fedoře jsou běžně i balíky zkompilované z nestabilních verzí. Na druhou stranu jsou v ní i zahnilé mrtvoly. Souhlasíš, nebo zase ne?

BTW bych rád věděl, jak mám popohánět nebo vyměňovat maintainery. To je ale asi spíše otázka pro Rezzu.

[Michal Kubeček]

viděl jsi někdy zdrojové balíky aplikací Fedory? Běžně jsou v nich i desítky patchů proti upstreamovým tgz

Za prvé: zdaleka ne ve všech; mezi jednotlivými balíčky jsou obrovské rozdíly, ať už v tom, jak funguje upstream, kdo je maintainuje a kolik času jim může/chce věnovat. Za druhé: je velký rozdíl mezi backportem opravy z novější verze a patchem, který v upstreamu není a není ani důvod věřit, že se tam v dohledné době dostane. Udržovat takový specifický patch znamená zátěž navíc přinejmenším s rebasováním při každém upgradu, proto se distribuce snaží takových specifických patchů mít co nejméně.

Tím nechci říct, že tenhle konkrétní patch by si zařazení do distribučního balíčku nezasloužil. Jen že nelze automaticky argumentovat tím, že v jiném balíčku je sto patchů, tak tady na jednom nesejde.

Ve Fedoře jsou běžně i balíky zkompilované z nestabilních verzí. Na druhou stranu jsou v ní i zahnilé mrtvoly.

Já bych s tím souhlasil. S čím ale nesouhlasím, je ta představa, že nějaký všemocný distribuční bůh má po ruce kouzelný proutek, jehož mávnutím tu situaci napraví. V enterprise distribuci spravované komerční firmou takové páky samozřejmě jsou - a ani tam nejde vždycky všechno úplně hladce. V komunitní distribuci závislé na dobrovolných přispěvatelích je to mnohem složitější.

BTW bych rád věděl, jak mám popohánět nebo vyměňovat maintainery. To je ale asi spíše otázka pro Rezzu.

Kdyby šlo o openSUSE, tak bych viděl v podstatě dvě možnosti. Jednak můžete udělat submit request a když ho bude maintainer příliš dlouho ignorovat, je šance, že ho akceptuje maintainer příslušného devel projektu (abych pravdu řekl, spíš mívám problémy opačného rázu). A nebo pokud vám o ten balíček opravdu jde a máte pocit, že maintainer se o něj dostatečně nestará, můžete rovnou vytvořit maintainership request (jste-li připraven na to, že pak budou po fórech nadávat na vás). Jak přesně fungují příslušné procesy ve Fedoře, s tím nemám zkušenosti, ale předpokládám, že oboje bude mít svou obdobu.

[pavlix]

Pravda, ve tvém případě je to spíše odportunismus

Takže ne. Beru na vědomí.

Mně to tedy zjevné není.

Fajn, můžeš se upstreamu zeptat, proč nechávají bug otevřený, přestože v komentáři píšou, že se povedlo vyřešit.

Tvoji argumentaci neberu - viděl jsi někdy zdrojové balíky aplikací Fedory?

To se ti moc nepovedlo.

Běžně jsou v nich i desítky patchů proti upstreamovým tgz.

Já zase neberu jako argument to, že jsou některé balíky špatně udržované, jiné ty patche z důvodu složité integrace prostě potřebují a u jiných je potřeba backportovat opravy a upstream je příliš divoký na rebase v rámci pouhého update. To je zcela normální stav, podstaté je, aby byly opravy až na zvláštní výjimky v upstreamu, což je taky jedno z pravidel správy balíčků ve Fedoře.

Z toho mi plyne, že nejdůležitějším článkem je maintainer balíku, nikoliv nějaké "základem je mít v pořádku upstream".

Upstream first. Názory jsou od toho, aby se lišily, ale trvám na tom, že nemá smysl vinit distribuce z toho, že stojí upstream za prd.

Ve Fedoře jsou běžně i balíky zkompilované z nestabilních verzí.

Taky jsem se tohoto prohřešku už dopustil. :)

Na druhou stranu jsou v ní i zahnilé mrtvoly.

To je minimálně v případě rawhide chyba, kterou je potřeba nahlásit a řešit. Fedora pokud vím nemá obsahovat neudržované balíky. Buď je má někdo převzít, nebo se mají vyřadit.

BTW bych rád věděl, jak mám popohánět nebo vyměňovat maintainery. To je ale asi spíše otázka pro Rezzu.

1) V bugzille se musí něco dít, musí tam být čas od času update, už kvůli ostatním uživatelům. V případech, jako je tento, je dobré tam mít workaround a případně i opravený balík třeba z COPR, pokud to člověk umí.

2) Občas se dá zjistit na daného uživatele IRC nickname. Dá se mu poslat přímý e-mail nebo najít další způsoby, jak ho kontaktovat.

3) Dá se napsat na fedora-devel a oznámit, že maintainer nereaguje. V případě setrvání situace může balíček převzít nový maintainer, který má zájem se o něj aktivně starat.

Nic z toho samozřejmě není povinnost, jsou to jen způsoby, jak se aktivně zapojit do dění ve Fedoře, aby balíčky z oblasti tvého zájmu fungovali tak, jak by fungovat měly.

[ikar]

Ach Pavlixi, tohle vzdávám. Na diskuse s tebou je můj život příliš krátký. Balíčky v oblasti mého zájmu si stáhnu v SRPM, opatchuju a rebuilduju. Už nemám nervy na to, abych přispíval do redhatí bugzilly a pak si za půl roku přečetl, že se bug uzavírá, protože končí životnost vydání. Aniž by byly patche aplikovány. Howgh

[pavlix]

V pořádku. Každý se věnuje tomu, čemu se věnovat chce. Já mám tu výhodu, že je RH bugzilla součástí mojí práce.

[gorre]

taky vypadá podle toho. tak míň kecej a víc makej

[pavlix]

Posílejte smysluplné bugreporty na balíčky, o které se starám, a můžeme se o tom bavit. ;)

[Bill Gates]

Problém je v tom, že autor považuje všechny změny za opravy bezpečnostních chyb, protože xscreensaver je bezpečnostní software. Správci v Debianu s tím nesouhlasí, protože se mezi jiné jedná o změny typu "přidal jsem nějaké píšťalky a zvonečky" (což je něco, co bezpečnostní chyby neopravuje, ale může to naopak nějaké zavléct)

Opravy bezpečnostních chyb jsou - v rámci možností, jako vždy u distribuce spravované hlavně dobrovolníky - backportovány.

Zajimave ze spravci v debianu takhle neuvazuji o systemd, ktery prijali jak nic i pres znacny odpor, jsou to zmeny typu "pridali jsme ovladani navic, kterym neziskate nic vyrazne noveho, ktere vas zbrzdi a ktere k nicemu nepotrebujete ale my jsme systemd" a navic tim zavlekli tolik chyb a bugu do stabilni distribuce, nektere veci uzivatelum totalne rozbili, az to pekne neni.

[trekker.dk]

navic tim zavlekli tolik chyb a bugu do stabilni distribuce, nektere veci uzivatelum totalne rozbili, az to pekne neni.

Stabilní distribuce neznamená stejný software navždy. Ne že bych chtěl omlouvat způsob, jakým k rozhodnutí přejít na systemd došlo, ale stalo se tak mezi jednotilvými stabilními verzemi a tam při upgrade změny (a nutnost něco řešit) očekávat musíte.

[pavlix]

Aha, tak jestli se bavíme o upgrade, tak nevidím smysl to vůbec vytahovat.

[pavlix]

To je jednoduché. Správci systemd se zřejmě rekrutují s fanoušků projektu a tudíž se inspirují u jeho tvůrců, kteří nemají vztah k žádným pravidlům, která si sami nenastavili. Vzhledem k tomu, že Debian není jenom jeden člověk, rozpory v jednání se dají čekat. Navíc si myslím, že se rozhodnutí kolem systemd vždy dělají tak nějak pod tlakem.

[2def]

píšťalky a zvonečky... to už se ani nezmůžeš na analogické české výrazy, ty polovzdělaná fachidiotská opice?

To už radši piš anglicky úplně, než abys kurvil můj rodný jazyk!

[Conscript89]

Hezky vylev, opravdu. Nekam bych si ho mohl napsat a pokazde kdyz si budu chtit zlepsit naladu, tak si ho prectu :)

[Conscript89]

Pozor, at ti nerupne bedna :) potencionální

[Lol Phirae]

Pozor, at ti nerupne bedna :)

Říká se buď "ať ti nerupne cévka", nebo "ať ti nerupne v bedně". Píšťalky a zvonečky se mi jako překlad líbí mnohem víc, než klasická cingrlátka.

Já osobně bych to tedy v kontextu diskuse přeložil jako "autor přidal další zbytečné píčoviny", ale to by našeho strážce rodného jazyka asi taky neu(spo)kojilo.

[little.owl]

to už se ani nezmůžeš na analogické české výrazy, ty polovzdělaná fachidiotská opice?

Zacnete u sebe, treba vyraz "fachidiot" mi take neprijde moc cesky.

[pavlix]

Navíc to slovo zřejmě mimo nadávku v zásadě nic neznamená.

[mimi.vx]

fachidiot .. je v rakousku pouzivany pro cloveka ktery je velmi schopny v uzkem zamereni,  ale pro zbytek zivota nepouzitelny

[pavlix]

Captain Obvious, Google mi ještě funguje. :)

Nicméně přesně na tento význam narážím. U nás se většinou říká, že je ten člověk nepoužitelný pro život nebo tak něco. Slyšel jsem podobné věci říkat různé lidi o různých druhých lidech a můžu zodpovědně říct, že to opravdu nic neznamená. Každý má trochu jinou představu o tom, co by druzí pro ten normální život měli umět a většinou vychází ze svých zájmů, představ a zkušeností.

[pavlix]

Pokud je v Debianu bezpečnostní chyba, může ji autor nahlásit jako každý jiný a navíc může ukázat na konkrétní změnu, která ji řeší. Tak se to dělá, pokud člověk není mesiáš, co si myslí, že musí být všechno podle něj. Teprve pokud by Debian nechával bezpečnostní chybu neřešenou, má smysl se dál bavit.

[koroptev]

v kazdy diskuzi na abclinuxu musi bejt nejakej ideolog, vitej

[Jardík]

Ale třeba právě o chybách ve WebKitu vývojáři Debianu vědí. Před nějakou dobou o tom někde i psali, snad někde v dokumentaci k předchozí stable verzi. Že prostě není v jejich silách backportovat bezpečnostní aktualizace do WebKitu a jeho různých odnošů (gtkwebkit, qtwebkit, atp) a že to prostě dělat nebudou a veškeré prohlížeče, rss čtečky, email klienty a jiné aplikace, které knihovnu používají, nemáme považovat za bezpečné. Já samozřejmě vím, jak pracné je takové backporty dělat a někdy to ani není možné, protože se kolem změní takového kódu. V tomto případě by ale možná stálo za to prostě u takové na správu náročné komponenty prostě dát aktualizaci na novou verzi. Přeci jenom je to závislost řekněme 20 aplikací (a né třeba 500 u důležitějších komponent) a riziko nějaké nefunkčnosti závislých aplikací je menší. A pokud není zabita ABI kompatibilita, prostě to fungovat bude. Toto je můj názor na věc, který však vývojáři distribuce nesdílí, a já mohu jen jedno - prostě distribuci nepoužívat.

[pavlix]

Že prostě není v jejich silách backportovat bezpečnostní aktualizace do WebKitu...

To je docela problém. Ale co s tím? Mně jako nejlepší vychází se webkitu úplně vyhnout.

V tomto případě by ale možná stálo za to prostě u takové na správu náročné komponenty prostě dát aktualizaci na novou verzi.

Dobře, ale je to vůbec prakticky proveditelné? Kolik dalších balíčků by se muselo přizpůsobit nekompatibilním změnám?

Toto je můj názor na věc, který však vývojáři distribuce nesdílí, a já mohu jen jedno - prostě distribuci nepoužívat.

Nesmysl. Pokud je to tak jednoduché, jak tvrdíš, jistě není problém udělat si vlastní repo s aktualizovanými balíčky. Když je nabídneš veřejně a dobře zdůvodníš smysl aktualizací, tak to jednak bude moct pár lidí s důvěrou používat, jednak si to budou moci vyzkoušet vývojáři, aby viděli, že upgrade nebolí tolik, jak si mysleli.

Podle mě jediné, co v open source opravdu funguje, je to udělat a teprve s výsledkem přesvědčovat ostatní, že máš pravdu.

[Ruža Becelin]

On ma problem s tim, ze mu lide hlasi bugy, ktere jsou opravene, misto toho, aby kontaktovali spravce baliku, ve kterem ty bugy jsou. Takze ho plne chapu.

[little.owl]

Ano. Garrett to spravne vystihl:

An upstream author releases a piece of software under a free license. Debian distributes this to users. Debian's policies result in the upstream author having to do more work.

[pavlix]

To by si mohli takhle stěžovat všichni včetně autorů mnohem používanějšího a významnějšího software. Bugy v distribučních balících se mají hlásit v dané distribuci, pokud člověk nemá zjištěné, že se to týká i upstreamu.

[Ruža Becelin]

Presne tak. O tom taky cela tahle sranda je - bugy, co jsou v upstreamu opravene, jsou v Debian stable neopravene -> uzivatele posilaji bugreporty upstreamu...

[pavlix]

Takže je to celé o tom, že jsou uživatelé hloupí a neumějí správně hlásit bugy. A řešením je, že postupně vyházíme z Debianu všechen software, kde si na to upstream stěžuje, až zrušíme Debian úplně. Free software rulez!

[Ruža Becelin]

Ne, cele je to o tom, ze Debian maintainer nedela svou praci, tak se to autor snazil resit upozornenim v programu. Hystericke reakce pod nahlasenym bugem a navrh "reseni" dtto je kapitola sama pro sebe...

[pavlix]

Ne, cele je to o tom, ze Debian maintainer nedela svou praci,

Bug links or didn't happen.

[Ruža Becelin]

Mam zabugovat odkazy?

Bylo to popsane v tom odkazovanem ticketu mimochodem...

[little.owl]

Bugy v distribučních balících se mají hlásit v dané distribuci, pokud člověk nemá zjištěné, že se to týká i upstreamu.

To se u Debianu moc nedeje, a pokud reportovane bugy hniji v jeho bugzille bez odezvy roky, uzivatele proste zkousi upstream.

[pavlix]

Zpoždění za upstreamem se týká všech distribucí a není zase až tak podstatné, jestli jde o roky nebo měsíce. Ani ty roky se netýkají jenom Debianu. Jestliže uživatelé xscreensaver spamují uptream distribučními bugy, jistě to dělají i uživatelé jiného software, ne? Tohle jde snad řešit jedině vzděláváním uživatelů a v případě nouze registracemi, blacklisty a whitelisty.

[Ivan2]

Problem je taky v tom, ze spravci baliku si odmitaji priznat, ze na to co chteji proste nemaji kapacity. Pamatuju, kdyz byl v debianu remote exploit na Sambu 3 - ta uz ale nebyla v upstreamu podporovana. A tak trvalo vice nez rok nez nekdo udelal backport v verze 4. Podobne je tomu a FF, kde uz nikdo nezvlada backportovat bezpecnostni opravy.

Navic podle nejakych pravidel Debinu bezpecnosti oprava muze byt uvolnena az po te, co je otestovana na vsech podporovanych architekturach. Co kdyz ale spravce baliku nema pristup k takovemu HW? Dusledne lpeni na pravidlech tak casto vede k naprosto nesmyslnym dusledkum, unstable je stabilnejsi nez stable.

Komunikace se pravci baliku je cil dal tezsi, vsichni porad resi nejaky pravidla, politiku, a nedokazou poradne ani poslat patch, kdyz neco na jejich distribuci nefunguje.

[fish]

To je ovsem to co rika JWZ. V diskusi jsem nenarazil na konkretni priklad bezpecnostni chyby, ktera by ve stable nebyla backportovana. Bez toho ta jeho argumentace trochu kulha.

A pokud ho lidi kontaktuji kvuli funkcim nesouvisejicim s bezpecnosti, bude to mozna i tim, ze je primo v aplikaci odkazuje na svoje stranky, nikoli na stranky maintainera.

V tuhle chvili se autor snazi tlacit na to, aby vsichni pouzivali upstream verzi, coz se stable (at uz v jakykoli distribuci) nema nic spolecnyho. A ted se nebavime o jadnorazovym upgradu ve stable, protoze pristi rok by ta hlaska vyskocila znovu.

PS: osobne je mi ta hlaska pomerne ukradena. Clamav ma podobnou snad odjakziva, ale je pravda, ze neni tolik videt ;)

[koroptev]

jakoze by mel jwz vest v patrnosti seznam vsech maintaineru ze vsech linuxovych pseudodister?

nema se stable nic spolecnyho? ty vis, ze je to rozjebany? ze pridal vlastnost, ktera porusuje kompatibilitu uzivatelum predchozich verzi? ze se to chova jinak? jak to vis? jaktoze to vi nejakej cicmunda z nejakyho distra lip nez jwz?

nebo si na vsechny tyhle otazky odpovidas nalepkou "stable" a implementujes to tak, ze to na par let das k ledu?

sorry, to je ale nejaka otazka viry pak, ze to nejde delat jinak..

[fish]

jakoze by mel jwz vest v patrnosti seznam vsech maintaineru ze vsech linuxovych pseudodister?

Nevim, proc by to delal, a ani jsem nic takoveho nenapsal.

nema se stable nic spolecnyho? ty vis, ze je to rozjebany? ze pridal vlastnost, ktera porusuje kompatibilitu uzivatelum predchozich verzi? ze se to chova jinak? jak to vis? jaktoze to vi nejakej cicmunda z nejakyho distra lip nez jwz?

nebo si na vsechny tyhle otazky odpovidas nalepkou "stable" a implementujes to tak, ze to na par let das k ledu?

sorry, to je ale nejaka otazka viry pak, ze to nejde delat jinak..

Ano, verim, ze maintainer balicku mi v ramci aktualizace najednou do systemu neposle novou verzi, ktera se diky novy funkcionalite zacne chovat jinak. Nevidim duvod rucne udrzovat vsechny aplikace co pouzivam a sledovat changelog, jestli v nich nedoslo ke zpetne nekompatibilni zmene. Proto pouzivam distribuci a ne LFS.

[koroptev]

Ukazuje to na absurditu pojmu "stabilni" v pojeti dister jajo debian/rhel. Uzivatele chteji odladeny, s minimem chyb, bezproblemovy atd. Misto toho dostanou stary s argumentem - chyby jsou zname a nebudeme vas prekvapovat jejich opravami. Pravdepodobne soudi cely svet podle vlajkovych lodi linuxoveho userlanfu typu gnome/kde, kde nova verze = nove losovani zcela jinych bugu..

[trekker.dk]

Misto toho dostanou stary s argumentem - chyby jsou zname a nebudeme vas prekvapovat jejich opravami.

Tohle teda není oprava chyby, ale co? http://metadata.ftp-master.debian.org/changelogs/main/x/xscreensaver/xscreensaver_5.30-1+deb8u1_changelog

xscreensaver (5.30-1+deb8u1) jessie-security; urgency=medium

  * Add upstream patch for "xscreensaver aborts when unplugging second
    monitor" security issue (closes: #802914)
    http://www.openwall.com/lists/oss-security/2015/10/24/2

 -- Tormod Volden <debian.tormod@gmail.com>  Sun, 25 Oct 2015 11:35:52 +0100

[selajam]

urgency=medium

[Jardík]

To je asi chyba. abort() je většinou volán při nějaké fatální chybě, kdy není dodržen nějaký kontrakt funkce. A jestli je xscreensaver použit k zamykání obrazovky, tak abort() je jistě bezpečnostní riziko.

[koroptev]

to je zastupce podmnoziny (tzv. chyb hodnych opravy dle hodnoceni ideologa z viry debianu) chyb, ktere jwz opravil

ja bych se toho trosku bal, protoze nejaky clovek, ktery s xscreensaverem nema nic moc spolecneho, vyoperoval z nejakeho jwz commitu nejakej snippet a cut&pastnul ho do o x let starsi verze, cimz efektivne vzniknul nikdy neexistujici fork neposveceny vyvojarem toho softu, kteremu jedinemu verim, ze vi nejlip, co a jak ohledne xscreensaveru..

[trekker.dk]

Njn, když je autor pitomec a nedělá samostatné commity (nebo možná dělá, AFAIK zrovna xscreensaver nemá žádné veřejné read-only VCS, protože je to moc práce), tak holt nic jiného než chirurgická práce nezbývá. Software s příčetnými autory tenhle problém nemá.

[Conscript89]

Tak pouzivej LFS a budes (asi) happy.

[Grunt]

No to nevim.

[Conscript89]

Hmm, tak to asi nema potom moznost pouzivat zadnou GNU/Linux distribuci (podle tohoto snad ani kompilaci) ktera by splnovala jeho pozadavky?

[Grunt]

Jakože čistě vanilkový mainstream? Hmm…to nevim (rozhodně vím že ne Gentoo).

[Václav "Darm" Novák]

Arch se toho dost drží.

[pavlix]

Podle mě to ukazuje jen a pouze absurdní očekávání některých vývojářů open source. Stabilní distribuce tu jsou proto, že je po nich docela velká poptávka. A to naprosto chápu. V době sysadminování jsem používal stable debian i na laptopu.

Pravdepodobne soudi cely svet podle vlajkovych lodi linuxoveho userlanfu typu gnome/kde, kde nova verze = nove losovani zcela jinych bugu..

Tak ono to platí obecně, pokud se software aspoň trochu vyvíjí.

[mirec]

Čo je stabilné? Poznám softvér, ktorý v debiane vôbec nechodí, aj na stránke autora je upozornenie, že v debian stable je úplne nefunkčná verzia (je tam chyba v parsovaní argumentov, nie bezpečnostná, ale zabraňuje to akémukoľvek použitiu softvéru okrem vypísania helpu). No debianovska politika je taká, že opravujú len bezpečnostné chyby a vôbec ich netrápi, že v čase zmrazenia tam dali prakticky nefunkčný produkt, ktorý bol hneď nasledujúci deň opravený.

[Aleš Kapica]

Ano. A právě proto používám Debian unstable a pro kritické aplikace, jakými je pro mne Pacemaker a Qemu si raději dělám vlastní deb balíky.

[pavlix]

Čo je stabilné?

Ta distribuce.

Stabilita distribuce znamená, že se v rámci aktualizací k jedné release udržuje software víceméně stejný a aktualizace se provádí pouze ze závažných důvodů a pokud možno bez regresí. Cílová skupina stabilních distribucí jsou lidi, kteří když si na tom systému něco rozchodí, tak chtějí, aby to bez regresí běželo i po aktualizacích.

No debianovska politika je taká, že opravujú len bezpečnostné chyby a vôbec ich netrápi, že v čase zmrazenia tam dali prakticky nefunkčný produkt, ktorý bol hneď nasledujúci deň opravený.

Mluv konkrétně. Většinou se ukáže, že je produkt pro mnohé uživatele zcela funkční. Faktem zůstává, že absence funkcionality není pro uživatele stabilních distribucí zdaleka takový problém, jako ztráta funkcionality (regrese).

[koroptev]

" Faktem zůstává, že absence funkcionality není pro uživatele stabilních distribucí zdaleka takový problém, jako ztráta funkcionality (regrese)."

ty si nevidis na spicku nosu; stabilni v tom pojeti, ve kterem ho debian pouziva, nerovna se "postradajici funkcionalitu" ale "exhibujici 2 roky stare bugy"; alespon to je ten pripad, o kterem se ted bavime..

a obecne je to presne tak; delals nejaky pruzkum, jak si uzivatele cenni sw s fixlym bugem vs stabilni sw?

[Conscript89]

Neni bug jako bug. Stabilni system muze (a typicky znamena) system s chybami ktere jsou zname nekolik let ale nejsou zasadni a jdou resit mimo ten system samotny. Pokud je to ale security, nefunkcnost nebo zasadni usability chyba, tak ty by mely byt peclive (bez zavleceni nove chyby) opravovany.

[fish]

... ale "exhibujici 2 roky stare bugy"; alespon to je ten pripad, o kterem se ted bavime..

Omlouvam se, asi jsem to v diskusi prehledl, ale muzes prosim upresnit o kterem konkretnim bugu se bavime?

A jak uz nekolikrat psali ostatni. Debian stable je predevsim konzervativni. Udrzuje urcitou verzi, pro snizeni rizika zavleceni neznamych problemu nebo zmen v chovani a backportuje jen opravy security bugu (vyjimecne i funkcionalitu).

[pavlix]

ty si nevidis na spicku nosu

Anonymní pitomeček mě neurazí, takže klidně pokračuj.

a obecne je to presne tak; delals nejaky pruzkum, jak si uzivatele cenni sw s fixlym bugem vs stabilni sw?

Není potřeba. Průzkum si dělají uživatelé sami a podle toho volí distribuci, která co nejlépe vyhovuje jejich potřebám. Jestliže vycházíš z předpokladu, že Debian takovou distribucí prakticky pro nikoho není, tak je to natolik bezvýznamná distribuce, že se o ní tady ani nebavíme. QED.

Samozřejmě každá mince má dvě strany a existují i různé anomálie, ale většinou pro ně existuje nějaké vysvětlení. Takže mě zajímá, proč kritici považují Debian za natolik důležitou a zajímavou distribuci, když zároveň dávají najevo, že je vedena zcela špatně. Takový postoj přece musí jít nějak racionálně vysvětlit.

[JoHnY3]

Neni potreba delat pruzkum. Staci se zamyslet na tim jak se pouzivaji servery a jak na nich bezi SW.

Server se nainstaluje, nasadi se na nej pozadovana aplikace (mysleno SW vlastni provenience, nikoliv soucast distra), otestuje se to a vyresi pripadne bugy. Od tohoto momentu si vsichni preji, aby vsechno hlavne fungovalo. Chce to sysadmin, vyvojar aplikace i uzivatel. Pro tenhle jsou stav tri hlavni rizika: regrese/zmeny v distru, bezpecnosti bugy v distru a libovolne bugy v aplikaci samotne.

Presne tohle je duvod proc existuji stabilni distra. Minimalizuji regrese, blokuje nekompatibilni zmeny a soustredi se na bezpecnostni bugy tak, aby se vyvojar a sysadmin mohli soustredit na vlastni SW/HW a nemuseli resit disto. Pokud by se zdalo, ze je to dneska diky continuous deployment a virtualizaci jinak, tak je to omyl. Tam jen automatizace dovoluje rychleji iterovat a tim mit inkrementalne mensi kroky mezi verzemi aplikace a uvolnit si prostred.

[pavlix]

+1

Ale jak už jsem psal, jako sysadmin jsem ke spokojenosti používal stable Debian i na laptopu. Podle velmi podobného vzorce. Jednou si nahodím prostředí, tak jak ho potřebuju mít a od té doby ho jenom používám, a když řeším nějaký průser, nepřidá se mi k tomu průser na lokálním stroji.

[petr_p]

Jsou lidé, kteří chybě přizpůsobí svůj software a pak se rozčilují, že oprava rozbila jejich aplikaci.

[mirec]

Mluv konkrétně. Většinou se ukáže, že je produkt pro mnohé uživatele zcela funkční. Faktem zůstává, že absence funkcionality není pro uživatele stabilních distribucí zdaleka takový problém, jako ztráta funkcionality (regrese).

Konkrétne ide napríklad o program pngquant, ktorý prevádza png súbory na indexované. Problém v debiane oldstable (donedávna stable) je, že nie je možné dať ako argument cestu k súboru a nefunguje ani stdin ako vstup. Teda vlastne algoritmus je implementovaný, ale nie je možné príkazu pngquant určiť na ktorom súbore ho má vykonať. S politikou debianu neupdatovať to (lebo nie je to bezpečnostná hrozba) mám akurát tak rozbitý nástroj ktorý, nepoužije nikto.

[pavlix]

Zase ale chybí odkaz na bug report nebo jakoukoli komunikaci s maintainerem a vyjádření, co a proč se s tím chystá (ne)dělat. Takže se bavíme jenom teoreticky. Pokud je balíček zcela nefunkční, osobně bych se nebál ho vyhodit, ale třeba se to nedělá zase z jiného důvodu.

[little.owl]

v pojeti dister jajo debian/rhel

Zrovna v tehle oblasti se RHEL a Debian velmi lisi.

[pavlix]

Jak Debian tak RHEL/CentOS jsou stabilní distribuce složené ze zastarávajících verzí software a distribučních oprav. Jaký konkrétní rozdíl máš namysli?

[chsajarsa]

RHEL backportuje i vybrane funkce do stable vetve a to vcetne noveho software. Prikladem muzou byt treba cgroups nebo IPA ve verzi 6.

[R]

V Debiane sa to vola backports.debian.org

[pavlix]

RHEL backportuje i vybrane funkce do stable vetve a to vcetne noveho software. Prikladem muzou byt treba cgroups nebo IPA ve verzi 6.

Ano. RHEL skutečně backportuje vybrané funkce v rámci stabilní větve za spolupráce několika různých oddělení se stálými placenými zaměstnanci. Osobně za nejdůležitější v tomto procesu považuju quality engineering, kteří mají na starost právě zabránění regresím.

Rozhodně to nefunguje tak, že přijde Franta a řekne, že chce novou verzi tadytoho software, slyší to Pepa a udělá commit, a strčí se to zákazníkům. Kdo chce takovou distribuci, může sáhnout (mezi jinými) třeba po Fedoře, i když i ta se snaží zásadnější změny u důležitých balíků kumulovat do upgrade, ač s relativně krátkým cyklem.

Osobně považuju Debian za úžasnou distribuci v tom, že je to prakticky jediná nezávislá binární stabilní distribuce. A docela obstojně funguje. Že nemá prostředky na armádu testerů pro stabilní backporty a stabilní rebase, mi nepřijde na závadu. Na to je tu komerční RHEL a jeho nekomerční klon CentOS. Mám výhrady snad jenom k jejich balíčkovacímu systému.

Podle mě je na trhu celá škála distribucí, které pokrývají potřeby spousty různých lidí a pokud si někdo stěžuje na to, že je Debian stabilní distribuce s minimem aktualizací, není to chyba Debianu, ale chyba toho, kdo ho pro daný účel vybral.

[Jan Kundrát (jkt)]

RHEL backportuje pomerne agresivne -- viz treba to, ze v ramci RHEL7 doslo k upgradu z libxcb 1.9.x na 1.11.y, ktera ma jine ABI (samozrejme spolu se zavedenim patricneho compat- balicku).

[Michal Kubeček]

Obávám se, že si - stejně jako jiní před vámi - pletete maintenance update a service pack (u RHEL point release). Když si porovnám třeba SLE11 GA a SLE11 SP4, přijde mi to "v rámci RHEL7" poněkud úsměvné.

[Jan Kundrát (jkt)]

Myslim, ze si tykame :). Ano, mel jsem napsat, ze k upgradu doslo v ramci zmeny z 7.x na 7.x+1 (a ze to bylo na CentOSu). Abych se priznal, nejsem si zcela jisty, ze RHEL podporuje klienty, jez by se rozhodli zustat treba na 7.0 po celou dobu mnohalete podpory "RHEL 7".

Nicmene to dobre ilustruje to, ze rebase spousty veci probiha i v (tom usmevnem) ramci "RHEL 7". Debian to tak podle vseho z nejakeho duvodu nema.

[pavlix]

Na CentOS se ty rozdíly mezi point release stírají, a nemyslím si, že byses dopustil nějakého omylu.

[Conscript89]

Abych se priznal, nejsem si zcela jisty, ze RHEL podporuje klienty, jez by se rozhodli zustat treba na 7.0 po celou dobu mnohalete podpory "RHEL 7".

Viz https://access.redhat.com/articles/rhel-eus a konkretni data: https://access.redhat.com/support/policy/updates/errata/

[Rezza]

SLE moc neznam, jaky je rozdil mezi maintenance update a service pack? Odhad, ze u nas v 7.x.y by bylo prvni y (batche, bez asyncu) a druhe x?

[Michal Kubeček]

Podstata mého příspěvku byla v tom, že je zásadní rozdíl v tom, jaké změny lze očekávat v běžném maintenance update a jaké při přechodu např. mezi 7.1 a 7.2. A tady to IMHO někteří diskutující úspěšně zaměňují.

[pavlix]

To jsou IMHO prázdné kecy, pokud nenapíšeš, kteří diskutující to jsou a v čem konkrétně se mýlí. Ano, v RHELu se dělá rozdíl a je možné se držet například 7.1, například CentOS ale toto pokud vím zcela ignoruje.

[Michal Kubeček]

Tak jsem jich pár posbíral:

RHEL backportuje i vybrane funkce do stable vetve a to vcetne noveho software. Prikladem muzou byt treba cgroups nebo IPA ve verzi 6.

RHEL backportuje pomerne agresivne -- viz treba to, ze v ramci RHEL7 doslo k upgradu z libxcb 1.9.x na 1.11.y, ktera ma jine ABI (samozrejme spolu se zavedenim patricneho compat- balicku).

Třeba to, že RHEL/CentOS 7.2 má rebase celého desktopu. Z GNOME 3.8 na GNOME 3.14. To je dost zásadní změna, kterou v Debianu nikdy neuvidíš.

To jsou všechno příklady změn, které se nestanou jen tak v rámci běžného maintenance update. Od toho jsou service packy, ať už jim daná distribuce říká jakkoli. Tam se s většími změnami počítá - a mimo jiné i proto si někteří naši zákazníci platí výrazně dražší LTSS support, aby nemuseli přecházet na novější service pack.

Debian AFAIK takový koncept nemá, takže je logické, že se v něm takové změny až na řídké výjimky nedějí.

[pavlix]

Obávám se, že se opět neshodneme. V seznamu vidím jedinou zásadní faktickou chybu a tou je tvrzení, že v Debianu nenajdeš zásadní změnu, což podle mě vyvrací ten Firefox. Nejen na příkladu CentOS je podle mě více než jasné, že se lze za stabilní považovat celou hlavní verzi (řadu), tedy například RHEL/CentOS 6. Možná to jinde funguje jinak, ale Debian a CentOS mají podle všeho víceméně stejnou granularitu s tím, že RHEL nabízí něco navíc, což je celkem pochopitelné.

[Michal Kubeček]

tvrzení, že v Debianu nenajdeš zásadní změnu, což podle mě vyvrací ten Firefox

Firefox je extrémní příklad, to je balíček, u kterého už na standardní politiku ohledně updatů rezignovali prakticky všichni, tam se updatuje formou nových verzí i ve SLE10. Z toho bych opravdu žádné závěry nevyvozoval.

Nejen na příkladu CentOS je podle mě více než jasné, že se lze za stabilní považovat celou hlavní verzi (řadu), tedy například RHEL/CentOS 6. Možná to jinde funguje jinak, ale Debian a CentOS mají podle všeho víceméně stejnou granularitu s tím, že RHEL nabízí něco navíc, což je celkem pochopitelné.

Opravdu si chceš hrát na to, že jen proto, že RHEL má dost vývojářů na to, aby dokázal tomu jádru, které je v aktuálním RHEL6, stále říkat "2.6.32" jako na začátku, můžeme tvrdit, že mezi Debianem a RHEL/CentOS není vlastně žádný podstatný rozdíl? Jestli ano, tak už toho radši nechám, na další podobně absurdní debatu nemám sílu.

[pavlix]

Firefox je extrémní příklad, to je balíček, u kterého už na standardní politiku ohledně updatů rezignovali prakticky všichni, tam se updatuje formou nových verzí i ve SLE10. Z toho bych opravdu žádné závěry nevyvozoval.

Já ano. Minimálně bych z toho vyvozoval, že je Debian takové výjimky schopný a tudíž v krajních případech na své standardní politice netrvá.

Opravdu si chceš hrát na to, že jen proto, že RHEL má dost vývojářů na to, aby dokázal tomu jádru, které je v aktuálním RHEL6, stále říkat "2.6.32" jako na začátku, můžeme tvrdit, že mezi Debianem a RHEL/CentOS není vlastně žádný podstatný rozdíl?

To slova tvá jsou.

Jestli ano, tak už toho radši nechám, na další podobně absurdní debatu nemám sílu.

Přijde mi, že jedeš podle stejného modelu jako vždycky. Vymyslíš si nějaký zcela absurdní konflikt včetně názoru obou stran a prohlásíš, že na tak absurdní debatu nemáš sílu. Not my problem.

[Michal Kubeček]

Přijde mi, že jedeš podle stejného modelu jako vždycky. Vymyslíš si nějaký zcela absurdní konflikt včetně názoru obou stran a prohlásíš, že na tak absurdní debatu nemáš sílu.

Nepřekvapuje mne, že ti to tak může připadat. Doufám, že ani tebe nepřekvapí, že mně to připadá trochu jinak.

[pavlix]

Nepřekvapí.

[Rezza]

LTSS support je u nas EUS :).

[Frank]

Třeba to, že RHEL/CentOS 7.2 má rebase celého desktopu. Z GNOME 3.8 na GNOME 3.14. To je dost zásadní změna, kterou v Debianu nikdy neuvidíš.

[Ivan2]

Dobra zmena je i tohle:

On Redhat 7.2, systemd-logind service introduced a new feature to remove all IPC objects when a user fully logs out. The feature is controled by the option RemoveIPC in the /etc/systemd/logind.conf configuration file, see man logind.conf(5) for details. The default value for RemoveIPC in RHEL7.2 is yes. As a result, when the last oracle or grid user disconnects, the OS removes shared memory segments and semaphores for those users. As Oracle ASM and Databases use shared memory segments for SGA, removing shared memory segments will crash the Oracle ASM and database instances. Please refer to the Redhat bug 1264533 - https://bugzilla.redhat.com/show_bug.cgi?id=1264533

Na RHEL 7.2 by default, kdyz se uzivatel odhlasi tak systemd smaze vsechny shared memory segmenty. Pokud je tim uzivtelem oracle anebo PostreSQL, tak to sestreli vsechny bezici databaze. Oni to snad delaji schvalne.

[lnykryn]

Samozřejmě, že to nebylo naschvál. Tohle při rebasu vypadalo jako nová, užitečná fičura. Když se uživatel odhlásí (poslední instance), tak po něm logind uklidí. Uživatelů s UID nižším než 1000 (což jsou většinou uživatelé pro démony), se to samozřejmě netýká. Bohužel některé aplikace na to kašlou a vytvářejí uživatele s UID >= 1000, což by ještě úplně nevadilo, protože samotné spuštení démona nespouští žádnou sessionu. Průšvih nastal až v okažiku, kdy měl démon nějaké maintance skripty v cronu, protože cron sessiony vytváří. Ale i tak, hned se zveřejnilo, jak se tohle chování dá vypnout a od další verze bude explicitně vypnuté.

[Ivan2]

ok tak to beru. kdyz se k tomu prida ta podminka na UID >= 1000 tak to dava lepsi smysl. Myslim, ze ale mezi uzivateli Linuxu neni povedomi o tom, ze UID < 1000 se chova zasadne nejak jinak nez UID >= 1000. Problem s nekteryma demonama je, ze se daji nastartovat jak z init-u, ale i rucne. Napr. limits.conf dnes nastavuje limity procesu pouze pro systemd session ale ne pro demony. Pro demony se limity nastavuji zvlast. Tzn vsechny navody na internetu na instalaci Oracle jsou ted spatne a dokonce ani sam Oracle to jeste nema podchyceny. Takze ted uzivatel instaluje databazi nastavi limits.conf nastartuje db, vsechno funguje. Rebootuje a DB mu nenebehne.

Podobne se pred 15ti lety chovaly Win2000. Process spusteny z Gui mohl alokovat az 3GB RAM, zatimco ten samy process bezici jako service smel alokoval max. 512MB. I tehdy se tomu spousta lidi divilo, protoze je to nenapadlo a navic se takovy problemy dost tezko ladi.

[pavlix]

Problem s nekteryma demonama je, ze se daji nastartovat jak z init-u, ale i rucne.

Service manager jako je systemd konečně umožňuje startovat službu vždy stejným způsobem ve stejném prostředí. Do té doby se služby při bootu spouštěly přímo z initu a po startu už jenom ze shellu.

[Michal]

Tento bug bol opraveny vramci z-stream update-u systemd. Pre uplnost vsak treba uviest aj fakt, ze islo v prvom rade o chybu na strane Oracle a dalsich, pretoze systemova sluzba ma bezat pod uzivatelom s UID < 1000. V tomto pripade tomu tak nebolo. Kedze systemove sluzby bez ohladu na UID nebezia vramci PAM session, tak by k zamazaniu nedoslo. Problem nastal ak sa pustil nejaky skript z cron-u ktory zmenil svoje UID na UID beziacej sluzby. Po skonceni toho cron skriptu (ktory bezi vramci PAM session) sa zmazali tie shared memory segmenty.

[Ruža Becelin]

Ona je sranda, ze v ref. architekture Oracle doporucuje uid/gid >=54000, coz je silenost

[Rezza]

Kazdy release RHELu ma nekolik zivotnich fazi a k tomu se release prekryvaji. Takze nejak to pokryva potreby vsech - ze zacatku muze byt system trosku zivejsi, v produkci se stejne nasazuje min, protoze je potreba dostat funkcionalitu na nejaky level dle skutecneho feedbacku, pak se stabilizuje a nakonec se skoro zakonzervuje. Vzdy budou nejaky vyjimky, ale cca tak to je. Ja osobne jsem priznivcem te ruzne rychlosti a prekryvani se. Ve Fedore jsem bohuzel ale neuspel...

[Ivan2]

S tim souhlasim. Nema smysl uplatnovat stejny pravidla na core veci jako glibc/gcc a na desktop veci, ktery se rychle vyviji. Kdo by dneska dobrovolne pouzival X let stary FF? Po nejaky dobe se trunk a "stable" balik od sebe vzdali natolik, ze uz to nikdo nedokaze udrzovat, coz samo o sobe muze byt bezpecnostni problem. RHEL v tomhle ma vyhodu v tom, ze baliky udrzuji lide, kteri jsou za to placeni. V Debianu se stavalo, ze spravcem baliku byl nekdo, kdo uz na to nemel cas a nedokazal predat veslo nekomu dalsimu (mladsimu).

[pavlix]

Nezačal náhodou Debian aktualizovat častěji Firefox?

[Ivan2]

Zacal. Po nejake dobe pripustili, ze jejich pravidla se nedaji aplikovat uplne na vsechny baliky.

[pavlix]

Pak se obávám, že se zde nebavíme o principiálním rozdílu mezi distribucemi. Obě distribuce jsou stabilní a konzervativní. Obě distribuce mají výjimky. Akorát jedna z nich má daleko větší manpower na vybrané změny a je řízená odlišným rozhodovacím procesem.

[JoHnY3]

Jen bych dodal, ze RHEL ma taky vyrazne min balicku, takze se muzou fakt soustredit na jejich ladeni. Debian je skoro vseobsahujici a nekdy na to doplaci.

[omg]

to je soucasti "frekvencniho" vnimani stability vs. navratnost investice do stability samotne.

[omg]

priklad komunitniho nasili jak vysiteho podle definice WHO. zazalovat a potrestat autora kodu.

[Michal]

Vtipne je, ze s tou jejich policy, ze v stable se maji resit jen seccurity updaty vlastne tu hlasku odstranit neemuzou pac to neni security vec.

Leda ze to jsou pokrytci a udelaji vyjimku pro odstraneni komentare (misto aby udelali rozumnou vyjimku a updatli verzi toho softu coz by resilo problem take). Coz podle diskuze pod bugem jsou. A poradni.

[R]

Pri niektorych balikoch sa meni (minor) verzia aj v stable - napriklad PHP alebo kernel.

[koroptev]

Vtipne spis je, ze backportovani nejakeho security update clovekdm, ktery neni vyvojar toho daneho sw ale jen balicjovac, se povazuje za "cistou" operaci nemenici "stabilitu" toho sw; pritom ten balickovac vytvari zcela neexistujici vetev a potencialne onen security patch musi extrahovat z mnohem vetdiho commitu... Ale holt je to balickovac pracujici na levlu "angelic intentions" "backportujici security update" (tm) cili koser a nic se nemuze stat.

[pavlix]

Mně to nijak vtipné nepřijde, naopak to zcela odpovídá zkušenostem z vývoje a nasazování software, kdy je více než dobré mít při nasazení další oči. U slušného software se prostě použije upstreamový patch. U prasáckého software s překotným vývojem se holt extrahuje čistá oprava, ale to je důsledek, nikoli příčina.

[cezz]

+1

Jednak neposkytuje ziaden verejny VCS (hoc aj read-only) takze sa to musi riesit takto chirurgicky. (o poriadnom changelogu ani nehovorim)

A potom odmieta pouzivat bugtracker, alebo aspon nejaky emailovy alias a potom sa stazuje ze ludia pouzivaju jeho osobnu adresu na hlasenie bugov. (ci uz validnych, alebo nie)

jwz je nepochybne odbornik v tom co robi, ale styl jeho prace velku doveru nebudi a skor by som veril zbastlenej verzii v Debiane ako tomu jeho tvrdeniu ze posledna verzia je jedina spravna TM. Netreba zabudat, ze Debian Stable bol v case Heartbleed jedna z distribucii ktore neboli tymto bugom zranitelne, takze ten ich pristup zas nie je uplne zly.

[fish]

... (misto aby udelali rozumnou vyjimku a updatli verzi toho softu coz by resilo problem take). ...

A jak by se to tim vyresilo? Behem par mesicu vyskoci ta hlaska znovu. A prubezne menit verzi podle ustreamu popira smysl stable distribuce.

[Grunt]

A prubezne menit verzi podle ustreamu popira smysl stable distribuce.

Tak musí se jwz nechat že smyslem distribuce je software distribuovat aby se o to nemusel autor či uživatel starat, ne dělat přesný opak.

[Frank]

Pokud upstream vydává jen jeden typ vydání, kde je všechno - bugfixing a nové fíčury, tak je to samozřejmě na postoji distribuce. Průšvih je, když upstream má vydání, kde se jen opravují chyby, a distribuce na ně stejně kašle. Nechvalně známé je tím Ubuntu s universe, kde ty balíčky hnijí od doby zkopírování z Debianu až do EOL. Pro autory softwaru je potom hodně frustrující, že věnují dost času podpoře stávajících verzí a distribuce se na to stejně vykašle. Uživatelé v tomto případě zodpovědnost nejsou často schopní rozlišit a házejí chybu na autory softwaru místo, aby hledali chybu ve své distribuci. Tam myslím pramení ta frustrace, která je obsažená i v tomto článku.

[pavlix]

To se ale dá poměrně jednoduše řešit. Bug report lze zavřít s tím, že je to v upstreamu vyřešené. Dále lze u (subjektivně) významných distribucí založit bug reporty. Dále se na ně lze při každé příležitosti odkazovat a tím se zbavit vzniklé časové zátěže.

Nehledě na to, že uživatel stabilního Debianu typicky ví, že používá stabilní distribuci se zastarávajícím software. Pokud to neví, je potřeba ho na to upozornit jednou pro veškerý softare.

[Frank]

Nehledě na to, že uživatel stabilního Debianu typicky ví, že používá stabilní distribuci se zastarávajícím software.

Ona je právě důležitá ta definice slova stabilní, což ten článek taky řeší. Stabilní se dá definovat jako "bez chyb" nebo relativně "s málo chybami", tak to dle mých zkušeností chápe velká část uživatelů Debianu. A takoví uživatelé můžou dojít k tomu, že si řeknou: používám Debian Stable, takže mám ten software v "nejméně chybové podobě" a přesto funguje, jak funguje, to musí být pěkný šmejd. Přitom v upstreamu už to může být dávno opravené. Stabilita v podobě Debianu je ale definována spíše jako "neměnnost".

Ale tím se nechci nijak opírat do Debianu. Tam má aspoň každý balíček svého správce a pokud upstream vydává čistě opravné verze, snaží se je v rámci možností poskytovat. To universe v Ubuntu a na něm postavených distribucí je z tohoto pohledu čirá katastrofa.

[pavlix]

Ona je právě důležitá ta definice slova stabilní, což ten článek taky řeší.

Definice stabilní distribuce už i v této diskuzi několikrát padla a není to žádná rocket science.

Stabilní se dá definovat jako "bez chyb" nebo relativně "s málo chybami", tak to dle mých zkušeností chápe velká část uživatelů Debianu.

To nemá s definicí stabilní distribuce nic společného. To samozřejmě nevyvrací tvé tvrzení o většině uživatelů, ale do toho se ani pouštět nechci, to je záležitost dokumentace a osvěty. Uživatelé Debianu, se kterými se já vídám, význam stabilní distribuce a konzervativních aktualizací chápou.

Stabilita v podobě Debianu je ale definována spíše jako "neměnnost".

Přesně tak, stabilní distribuce znamená distribuce relativně neměnná, jejíž aktualizace jsou velmi konzervativní z hlediska rizika regresí nebo změny funkcionality. Se stabilitou software to má společného jen to, že to pomáhá ji společně s dalšími vlastnosti software během životního cyklu udržet.

[Grunt]

This version of XScreenSaver is very old! Please upgrade!

This version of xscreensaver is VERY OLD!

_{I know that the author has placed a Big Fat Warning in senescent_p() asking distro maintainers not to remove those warnings. However, as a user I find these warnings rude and obnoxious, and I wish my computer not to be obnoxious to me. Therefore, I ask that you disable the recency check, notwithstanding the author's request.}

Dovedu si představit tu frusraci na obou stranách (možná i více stranách). Říka někomu něco pojem žabomyší války?

[pavlix]

Já bych to odstranil s poznámkou, že až se autor uklidní, můžeme se bavit o nějakém inteligentním řešení. Je to jenom software. V případě aiccu jsem musel ustoupit z toho důvodu, že se ten software používá hlavně k přístupu ke službě a ta má holt svoje podmínky a není možné nacpat uživatelům úpravu software, která způsobí porušení těch podmínek, ať jsou sebestupidnější. Ale tady? Je to open source, tak ať si autor políbí.

[Grunt]

Co to bylo za funkcionalitu v iptables co měla být odstraněna každých pět minut to spamovalo v dmesg? Je fakt že spamování začíná být poslední dobou víc a víc v módě

[Ovocníček]

A až si políbí a dojde mu, že vyvíjet floss za buzeraci a trolling místo platu mu za nervy nestojí, tak se pak bude hledat novej maintainer, kterej by s těma autistickejma děckama měl zase pár let trpělivost (bonus points: znalost kódu), než taky vyhoří.

[Lol Phirae]

Nevidím jediný důvod k tomu prehistorickému bitrotu hledat maintainera.

[Grunt]

Zas na druhou stranu ta představa kdy BFU nainstaluje Debian a nějaká aplikace mu tam obřím písmem hlásí že si má updatovat systém a neotravovat a on chudák urputně a zmateně kliká na aktualizační tlačítko a nějaká aktualizace furt né a né naskočit…

[Ovocníček]

No a? Kdyby to tam nebylo, tak vesele používá starou verzi v případě reálných problémů o ničem neví. Thle není jediný software, který k tomuhle přistoupil, x254 třeba mělo detekce rozbitých knihoven nebo kompilátorů (specifika už si úplně nepamatuju) v distribucích. Někdy prostě ten autor ví co dělá, narozdíl od o řád míně erudovanýho maintainera, kterýho něco "uráží". Když si mám vybrat, na čí city tu srát, tak i z toho vyjde ten whiner maintainer.

[Lol Phirae]

Ano, autor ví, co dělá, a proto tam jsou takové perly, jako že to celé spadne při přehození monitoru. (Kdo by od autora screensaveru mohl čekat, že by ho snad napadlo přehodit monitory a kouknout, jak se to chová...) Autor ví, co dělá, a tak místo bug trackeru na svém příšerném webu radí hlásit chyby emailem, a pak se hrozně diví, že ho lidi otravují emaily, protože reportované bugy nejde nikde dohledat. Autor ví, co dělá, a tak VCS je pro něj sprosté slovo.

[Grunt]

Já spíš žeru možné řešení:

• Updatovat balíček v nějakém stable distru na mainstreamovou verzi a mít pokoj
• Vytvořit patch který požadované řádky s upozorněním vyhodí a buď ho proti autorově vůli rovnou aplikovat a nebo nechat uživatele ať si ho aplikují sami ale v konečném důsledku by to znamenalo pokoj
• Vyhodit balíček z distraa mít pokoj a kdo chce nech si ho dokompiluje jednotlivě nebo natáhne z nějakého neoficiálního repositáře

Současné řešení: Všechno nechat tak jak je a spustit žabomyší válku o tom co je a co není staré, jaký dopad to bude mít na ReproducibleBuilds, následně přesunout diskusi i na jiné portály a …pouze doufám že bude mít tahle válka nějaký konec ze kterého vyjde nějaké pozitivní řešení pro všechny. No kdo tohle v práci má?

[Grunt]

přesunout diskusi i na jiné portály

Zapomněl jsem dodat napsání několika blogů.

[pavlix]

Souhlasím s tebou ve všech bodech. :)

[Grunt]

Ještě mě napadlo politicky korektní řešení které by nebylo v rozporu s přáním autora a to ani po právní stránce ale které by v celém brajglu nadělalo ještě větší bordel:

• fork

Aplikace by se mohla jmenovat YAXScreenSaver nebo XScreenSaver2.

[pavlix]

V případě tak zbytečné aplikace (vzhledem k množství alternativ a přístupu autora) bych se klidně držel možnosti se s xscreensaverem úplně rozloučit. Fork by zcela jistě nebyl v souladu s přáním autora a navíc by to byla vcelku zbytečnost.

[Grunt]

Fork by zcela jistě nebyl v souladu s přáním autora

Jak to víš? Ty si někde našel licenci pod kterou je XScreenSaver vydaný?

[Ondrej Santiago Zajicek]

Když si mám vybrat, na čí city tu srát, tak i z toho vyjde ten whiner maintainer.

Jenze vyberna koho se vykaslat neni tu neni mezi vyvojarem a maintainerem, ale mezi vyvojarem a uzivateli. Bud se Debian vykasle na jwz a odmitne jeho pozadavek na vyrazeni XScreenSaveru, nebo jeho pozadavek akceptuje, cimz se vykasle na debiani uzivatele XScreenSaveru, kteri budou muset bud prejit na alternativy, nebo zacit stahovat XScreenSaver z jinych zdroju. Takze ten spor je vcelku jasny - urazene city jwz na jedne strane vs. realne problemy mnoha lidi na druhe. Maintaineri by vzdy meli myslet na to, ze mit dobre vztahy s upstreamem je sice pozitivni, ale primarni zavazek distribuce je vuci jejim uzivatelum.

[pavlix]

+1

[Lol Phirae]

Takhle hrůza s autorem zamrzlám cca v roce 1995 je součástí defaultní instalace?

[Grunt]

Že je starý a bez nových fíčur ještě neznamená že je nefunkční. Já si ani nejsem vědom že bych se ve svém životě s XScreenSaverem někde setkal ale očividně i po takové době od prvního vydání stále existují lidé kteří to používají. Jedním slovem: WOW.

[Grunt]

Jinak ten rok je 1992. To je kolik? 24 let?

[Lol Phirae]

Já bych to odstranil s poznámkou, že až se autor uklidní, můžeme se bavit o nějakém inteligentním řešení.

No, já bych to prostě odstranil. Tečka. Celá ta řešetoidní sračka je bez ohledu na "aktuálnost" verze od dob LCD zcela k ničemu.

[Jan Kundrát (jkt)]

Velmi caste pouziti je pro zamykani bezici session, ne pro setreni monitoru. Souhlasim, ze z hlediska zivostnosti a uspor energie je lepsi reseni SW vypnuti monitoru nez kresleni barevnych blbinek, jiste.

[Lol Phirae]

Ano, toto jediné alternativní využíti je děravé jako řešeto (viz nedávno např. shození odpojením monitorů) a řada podobných WTF bugů předtím. Krom toho, že to ve skutečnosti nic nezabezpečuje, to jako bonus navíc vypadá, jak když to vypadlo z dinasauří prdele, a to bez výjimky ve všech prostředích. A autor vypadá na podobného magora, jako byl ten týpek, co vyvíjel cdrecord. Fakt terno tohle mít v distribuci.

[pavlix]

Používám physlock a ten vypadá v klidu, nebo máš na to taky nějaký útok? Stejně ho používám hlavně kvůli company policy a případným vtipálkům.

[Lol Phirae]

Ne, já proti zamykání session nic nemám, jsem jen zásadně proti tomu, aby k tomuhle účelu sloužilo prehistorické zobrazovadlo kravin typu létající ovečky. (Pokud vím, i v Gnome už gnome-screensaver odpískali a zamykání se řeší před GDM).

[ikar]

Proč by si nemohl někdo nechat zobrazovat létající ovečky, pokud chce? Že sc vypadá jako z dinosauří prdele, s tím se dá souhlasit - autor tvrdil, že to je z důvodu bezpečnosti (!?) a taky jako obchodní značka (!?). Ale geniální programátoři a vizionáři z GNOME screensaver odpískali přes silný odpor uživatelů proto, že to neuměli implementovat (tak, aby to aspoň trochu fungovalo). A ne proto, že by se jednalo o překonanou a zbytečnou věc.

[Lol Phirae]

Jo, ať si je klidně nechá zobrazovat, nikdo mu v tom nebrání. Utilita, která má zamknout session, by měla mít maximálně jednoduchá s minimem kódu, ne sbírka létajících oveček, psychedelických animací, vztyčených penisů v podobě hada apod. kravin.

[Jendа]

Jestli koukám správně, tak nepoužívá PAM.

[Grunt]

A autor vypadá na podobného magora, jako byl ten týpek, co vyvíjel cdrecord. Fakt terno tohle mít v distribuci.

jwz:Please remove XScreenSaver from Debian.

Peter Nowee, please take your sanctimony and go fuck yourself with it.

To je dobrý řízek

[Grunt]

A tím že se kreslily nějaké krajinky a bůh víc co na CRT se nějak někde něco šetřilo?
Ono se to opravdu mělo jmenovat spíš XScreenLocker než XScreenSaver.

[Lol Phirae]

No, šetřilo se to, že se ti nevypálil statický obraz na monitor. Jak říkám, takhle věc prostě nemá žádný rozumný význam, a co se týče zamykání, očekával bych řešení zaprvé na úrovni X serveru, zadruhé v jednotlivých prostředích, ale určitě ne něco, co by jakkoliv vycházelo z téhle hrůzy.

[Grunt]

No, šetřilo se to, že se ti nevypálil statický obraz na monitor.

To jde? Resp. šlo?

[Honza Jaroš]

Šlo. Kdysi jsem na vlastní oči viděl v jednom rádiu okna zvukového softwaru, vypálená do luminoforu ve vyřazených CRTčkách.

[ikar]

"Vypálený" obraz - rámečky oken atd - tady máme i na starých TN LCD monitorech, kde byl 24/7 spuštěn nějaký monitorovací soft. Ale CRTčka k tomu byla náchylnější. Hlavně když staré monitory neměly žádné automatické uspávání. Dokonce i Norton Commander (i Volkov commander) spouštěly po nějaké době screensaver, takové hvězdičky, to aby se nevypalovaly obrysy panelů do luminoforu (v dobách MS DOSU s textovým rozhraním).

[Ovocníček]

"Hvězdná obloha". Kuzorem myši do horního pravýho roku - klasika :D A jak jsme pak žrali ve Win3.1, když se "simuloval průlet hvězdokupou", s možností nastavení počtu a rychlosti :) Tehdy ještě CPU neměly šetřící funkce, tak to nebylo tak škodlivé.

ělo to asi i klávesovou zkratku a time-out, to už si tak moc nevybavuju. NC už je dávno (cca 1994/5-1997).

[Jendа]

a co se týče zamykání, očekával bych řešení zaprvé na úrovni X serveru

To já bych taky čekal, ale bohužel to nikdo nenaprogramoval a mně se fakt nechce trávit večery přehrabováním se v kódu Xek a udržováním vlastního forku.

[Michal Kubeček]

Já bych to nečekal, X server jen poskytuje podporu pro to, aby někdo grabnul veškerý vstup (kromě věcí jako Ctrl-Alt-Fn). zobrazování nějakého dialogu a ověřování hesla, to je přesně typ úlohy, do které se X server neplete a přenechává ji někomu jinému.

[Jendа]

X server jen poskytuje podporu pro to, aby někdo grabnul veškerý vstup

Ale už neřeší, co se stane, když tento někdo spadne. (v minulé diskuzi se píše, že existuje způsob, jak zařídit, aby sletěla celá Xka, ale KDE5 to tak dělá a zjevně se mu to taky nedaří)

[Michal Kubeček]

Moje zkušenost z Tumbleweedu byla, že když se ten proces killnul, tak ho někdo okamžitě spustil znovu. Což bylo v daném případě docela praktické, protože tam byl bug způsobující, že občas nešel dát focus políčku pro zadání hesla. (Po restartu už to fungovalo.)

[Lol Phirae]

to je přesně typ úlohy, do které se X server neplete a přenechává ji někomu jinému.

... a podle toho to taky dopadá.

[Ivan2]

JJ. Viz Firefox a jeho featura drag-and-never-drop. Je neuveritelny, ze ve 21. stoleti staci klikout na obrazek, pohnout mysi a je kvuli tomu potreba restartovat cely pocitac. (CTRL-ALT-BACKSPACE je by default zablokovany)

[Michal Kubeček]

Nerozumím. Pominu-li, že jsem ve Firefoxu na problémy s dragováním obrázků ještě nenarazil (a to ho občas používám), mám to chápat tak, že vaše distribuce blokuje i Ctrl-Alt-Fn?

[Ivan2]

Jo to mate pravdu. Ctrl-Alt-Fn jeste blokovany neni. Restart Xserveru a reboot pocitace vyjde casove vice-mene nastejno. Nastesti jsem na tenhle otravny bug uz delsi dobu nenarazil nenarazil. Problem, je v tom ze aplikace na sebe presmeruje eventy, pak vytuhne a Xorg uz se z toho nevzpamatuje.

[Michal Kubeček]

Zatuhlý proces bude asi problém, ale pokud se ten Firefox odstřelí, X server by měl být schopen poznat, že je něco v nepořádku, podle toho, že dostane "broken pipe" při pokusu mu něco poslat, a uvolnit všechno, co pro něj držel. Ale netuším, jestli to opravdu dělá.

[Lol Phirae]

Například: https://bugzilla.mozilla.org/show_bug.cgi?id=511188

Problém je v tom, že ta banda umělců tohle a další podobné bugy vůbec nepovažuje za bug. Pro ně je prostě normální, že za sebou budu (třeba v tomhle konkrétním případě) tahat obrázek, dokud nezabiju prinejmenším ten prohlížeč. Jim je to prostě jedno, prý si to má opravit ten, kdo vytvořil danou stránku.

[Jendа]

OK, a co bys doporučil místo toho?

[kralyk z abclinuxu]

To se jistě vyřeší...

[Jendа]

Autor si stěžuje, že mu píšou lamy s bugy ve starých verzí. Mně pomohlo dát nad kontaktní adresu červený banner:

A5/1 cracking turned out to be a complicated task, at least for some. Unfortunately, I can't provide support with basic Linux and programming skills. These things include for example:

• Ability to read the installation manual and comments in configuration files.
• Understanding the concept of “files”, “directories”, “devices” and “addresses”.
• Understanding the concepts of “Makefile”, “compiler” and “JIT”.

Please don't take this as some meanness, I just started getting tons of emails from people who obviously don't follow. If you have found a real bug, have some improvement, or are just interested in technical discussion, you are welcome.

a zdá se, že to docela pomohlo. (dostával jsem záplavu mailů od lam, které nedokážou spustit make, nedokážou si přečíst první stránku dokumentace, spouští můj software na Ubuntu 10.04 a tak)

[jm]

Zboznuji takovou diskuzi. Alespon nemusim cist wikipedii a hledat co a jak se v Debianu (kdo to vubec z "novacku" muze pouzivat ?) dela. Prosim o vice takovych. Velmi poucne (Legraci si opravdu nedelam)....

[Xerces]

nováček = debil ?