openSUSE Leap 42.1

Vychází openSUSE Leap 42.1. Zcela nová verze známé komunitní distribuce, která je nyní založená na úzkém propojení s komerční distribucí SLE. Oficiální uvedení na konferenci SUSEcon je naplánováno na cca 14:00 včetně otevření všech zrcadel. Některá zrcadla jako karneval již otevřela.

4.11.2015 11:44 | lertimir | Nová verze

Komentáře

[Jardík]

Škoda, že to distro je od americké společnosti, která může dostat tajný soudní příkaz, aby špehovali uživatele, měli tam backdoor a pod.

[Ruda]

Firma jejíž domény spravuje Bruce Wayne nemůže být špatná!

[randy]

Americka? :) Ved SUSE je uz rok britske (Micro Focus) :D

[Ruda]

No to si pomohl. NSA a GCHQ jsou jedna ruka :D

[Nuphar]

Jo, a hlavní vývoj se odehrává v Norimberku (kde sídlí SUSE) a v Praze... Takže odkud to tedy je? Reálná práce se odehrává v jiných zemích, než kde sídlí vlastník...

[randy]

Tak oni pod nich patria, ale kto vie ako potom je to s legislativou, ci ju musia zdedit z rodica, ci si ziju svojim zivotom. Ale ked uz v podstate nic nemaju z US, tak by sme v zuzke mohli mat aj kodeky :)) Ci nie?

[Miška]

Coz nic neznamena, protoze libovolna distribuce muze byt pod natlakem kohokoliv. Proto pouzivame opensource, aby pripadne bezpecnostni problemy byly videt a mohly byt opraveny. A pokud se ti nelibi binarky co pro tebe nekdo zkompiloval, muzes si celou distribuci prekompilovat sam

[Jardík]

Oni právě být vidět nemusí, jak mám vědět, že poskytnutý binární balíček je skutečně zkompilovaný ze stejného zdrojového RPM, které mi dávají.

[Miška]

Dyt rikam, pokud se ti nelibi co pro tebe nekdo (kdokoliv, jedno jestli SUSE nebo sousedovic Franta) zkompiloval, zkompiluj si to sam. Ale hadam ze budes mit tezky najit kompilator kterymu bys moh verit ze nevklada pri kompilaci skodlivy kod.

[Jardík]

No budu si muset asi nějaký napsat přímo ve strojovém kódu, ale co když mi tam něco podstrčí současný OS, nebo třeba procesor, vždyť já jsem z toho vyřízenej.

[Miška]

Nejjistejsi bude vratit se k dernejm stitkum, tam to clovek na prvni pohled vidi kdyz mu to neco prozere

[lertimir]

Pak ale nesmí zakopnout s krabicí štítků nebo už je nikdy neuspořádá.

[Jirka]

...aby pripadne bezpecnostni problemy byly videt a mohly byt opraveny...

Jak dlouho že to trvalo u bash bugu?

[Vojtěch]

Paranoia je vážně hrozná. Jak můžete žít, člověče? Třeba si takhle jdete nakoupit a pokladní tuší, co budete mít k večeři. To musí být strašné.

[co tuší]

co tuší - ale může do ní i něco přidat!!!

a nebo mu může třeba prodat nevodivý alobal a pak by nefungovaly ani čepičky !!!

[Jardík]

Počkat počkat, to jako že mi nemusí fungovat moje čepička? Musím to jít radši vyzkoušet .... ále funguje.

[Miška]

To se ti jen zda, oni tam ted delaj maly dirky aby to nebylo videt a abys to tolik nepocitoval, ale Astarova flotila te pres to porad dokaze sledovat

[co tuší]

jj, přeci každý ví, že se dělá dírka nad levým uchem (tak kde má každý člověk narozený po roce 1960 hned od narození implantovaný GPS čip) a pak přesně na vršku lebky (kde je schovaná anténa od dálkového ovládání) a pak třetí vzadu nad prvním obratlem kde je vnější rozhraní čtečky myšlenek!!!

[Miška]

Jinak 20.11. pokud se chcete o Leapu a openSUSE obecne dozvedet vic, bude se v prazskem SUSE konat od 16:30 release party (akce ceka v systemu na schvaleni).

[bill]

Debian stable a openSUSE, jedine distribucie co za nieco stoja ♥

[jiri.one]

+1

[Marek]

a co Mint, nebo dokonce LMDE??

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

Způsob instalace je poněkud nešťastný.

[Laco]

openSUSE je hlavne zosobnenim bloatware, plny balastu a predinstalovanych aplikacii a cele to korunuje absolutne debilny, nezrozumitelny spravca balikov. Nie je vobec jednoduche odistalovat niektore aplikacie s ich nezmyselnymi zavislostami a patternami. Lahkost s akou dokazu zadrbat taky gnome desktop balastom je doslova umenie. V porovnani s takou Fedorou ktora je cista bez zbytocnosti a nainstaluje sa do 5 min. openSUSE to uz davno malo zabalit. Akosi tu nefunguje prirodzeny vyber..

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

... jestli on jen nebude problém mezi klávesnicí a židlí? OpenSUSE pochopitelně jde nainstalovat přesně podle potřeb uživatele a s ničím navíc. To s bloatware je jen hloupý kec. Srovnávat s Fedorou to nechci, protože oba systémy jsou zaměřené na jinou cílovou skupinu a jsou tam rozdílné vize.

[lertimir]

Zajímalo by mne jaké vidíš hlavní rozdíly v cílové skupině a vizi.

[henrik]

fedora je víc pro geeky a techniky (pokud tedy nejsou na debianu), opensuse je spíš pro manažerský týpky a jiná bfučka

[marek_hb]

no nevím - geek a technik nejsem, ale třeba tv kartu jsem pod opensuse prostě nerozjel... - na debianu a pak archu v pohodě...

[bill]

To su nezmysly. Spravca balikov zypper je jeden z najlepsich spolu s YaST nadstavbou. Velmi presne dokazes odinstalovat co nepotrebujes vratane zavislosti. Ktore ine distro vydava plne otestovane rolling release ako Tumbleweed ? Arch/Gentoo urcite nie.

[_]

plne otestovany neni ani SLES, natoz tumbleweed .D

[Miška]

Myslis ten spravce balicku jehoz jadro prevzali do te tve Fedory, jelikoz se ukazalo, ze klasicky yum nema smysl dal trapit? A ze si neumis rozmyslet co chces nainstalovat, tomu se rika nerozhodnost, ne bloatware

[Dan]

On má asi na mysli grafickou nástavbu, která je fakt příšerná. Samotný zypper je v pohodě.

[Michal Kubeček]

Určitý problém se závislostmi existuje, ale ten se dá celkem snadno vyřešit tím, že člověk okamžitě po instalaci nastaví solver.onlyRequires na true. Tohle je ale bohužel rada, která se z pochopitelných důvodů na dostatečně viditelném místě dokumentace nejspíš nikdy neobjeví.

[mchf]

No pracuje se na tom a yast-packager od verze 3.1.74 vylepsuje chovani v pripade jiz nainstalovaneho systemu.

Bohuzel co se tyce instalatoru tam se resi politika kolem patternu a do release Leapu se to vyresit nepodarilo.

[Michal Kubeček]

Problém, který jsem měl na mysli, není v YaSTu, ale už v samotném principu toho, jak se vyhodnocují závislosti mezi patterny a balíčky a mezi balíčky.

Jde o to, že "příslušnost" balíčku do patternu je implementovaná stejnými třemi úrovněmi závislostí (requires, recommends, suggests), jaké se používají mezi balíčky. Pokud má pattern nějaký balíček jako requires, znamená to, že nemůžu (bez porušení závislostí) daný balíček vyhodit, aniž bych vyhodil i ten pattern - a to během instalace určitě nechci. Proto jsou jako requires jen ty naprosto základní balíčky a výrazná většina "obsahu" patternu je jako recommends. Proto je během instalace potřeba mít zapnuté automatické přidávání recommended balíčků.

Pokud se to tak ale nechá i v nainstalovaném systému, znamená to, že se budou automaticky instalovat všechny recommends závislosti i dál, což uživatel s trochou zkušeností téměř nikdy nechce, protože maintaineři občas s recommends ztrácejí soudnost (). Jenže kdyby to byl default, budou neznalí uživatelé prskat, že ten a ten (podle nich) nezbytný balíček se nenainstaloval, když si o něj neřekli. Koneckonců se stačí se podívat na absurdní diskusi z minulého týdne, kde i relativně zkušení uživatelé křičeli a dupali nožičkama, že přeci absolutně nepřichází v úvahu, aby pattern "Minimal Server" neobsahoval YaST.

Současný model tak vede k tomu, že mi nezbývá než během instalace jen navolit patterny a zásadně do výběru nijak nezasahovat, aby se mi automaticky nezačaly přidávat další hromady zbytečností. Po instalaci okamžitě zapnout solver.onlyRequires a pak teprve začít výběr upravovat. Ono i když si člověk udělá vlastní pattern (což jsem kdysi dělával pro automatické instalace systémů na školení), tak je pak frustrující podívat se na rozdíl mezi tím patternem a tím, co se opravdu nainstalovalo (řešil jsem to post-install skriptem, který všechno navíc zase odinstaloval, ale stejně mne to štvalo).

Bohužel netuším, jak z toho ven. Leda snad začít opravdu používat Suggests, umožnit (těm, kdo chtějí všechno a ještě něco navrch) automatickou instalaci balíčků na základě Suggests a naopak nemilosrdně ořezat Recommends závislosti. Ale moc reálné mi to nepřipadá.

[Michal Kubeček]

maintaineři občas s recommends ztrácejí soudnost ()

Tady mi vypadl příklad: před pár dny jsem v jednom virtuálu spustil "zypper install git" a mimo jiné se nainstalovaly i balíčky subversion, cvs a xhost. A našly by se ještě absurdnější příklady.

[lertimir]

A někdy je to i obráceně. Před asi 4 lety jsem odstraňoval něco, co jsem považoval za obyčejný program na konci stromu knihoven. (Nepamatuji si přesně, ale funkčně to byl buď file manager nebo mail klient) Závislosti byly takové, že se odinstalovalo celé grafické prostředí.

[kyknos]

to se mi stalo x-krát :) staci chvilka nepozornosti, a komplet gui je pryc :)

[ET]

jak je to s initem? na wiki pisou, ze v 12.x je sD volitelnej, ale o dalsich verzich uz nic

[Miška]

Systemd, jedina konkurence ktera jeste nebyla vyhlazena je OpenRC v Gentoo a i na to casem dojde. Odpor je marny, vsichni budou asimilovani

[ET]

thx, je na case drtit BSD

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

... u BSD už jsem též zaslechl hlasy, že je třeba něco udělat s initem ... :-/ Jednoduchost se nám prostě hroutí a nastává planeta Opic, proto se vymýšlejí opičárny!

[ET]

tak uvidime, snad to panove vezmou za lepsi konec a nebudou vsude tlacit nedodelanej bastl

[Pavel Čejka]

Není 32bit

OpenSuse jsem provozoval na starších strojích, kde se mi nechtělo kompilovat Gentoo (a mnohé ani nemají 64 bit CPU, ani víc než 2G RAM) a pod... takže sbohem Suse, nejspíš přijde Debian .. nebo prostě něco jiného. Přinejmenším někde.

[Miška]

32bit casem snad bude, neni to uz primarni architektura ale je to komunitni port, podobne jako 32bit arm. Jinak Tumbleweed porad jeste je i 32bit a pokud jinde mas Gentoo, tak se jiste rolling distra nebojis

[bill]

Zatial sa mi to nedari stiahnut. Skonci to bud v 1/4 alebo 1/2 stahovania. Mate aj vy podobny problem ?

[bill]

Nainstalovane, odskusane predvolene KDE5 je bohuzial rozbite a zabugovane rovnako ako na ostatnych distrach. Ako sa tento nedorobok mohol dostat do stabilneho LTS vydania je mi zahadou

[Miška]

Bugy je treba hlasit Stabilni je hlavne zaklad - kernel, systemd, gcc, glibc, ... KDE tym povazoval KDE5 za dobre fungujici a pridanou hodnotu pro uzivatele, tak je zvolili. Ale zrovna KDE stack je urcite jeden z pripadu ktere se casem dockaji upgradu, dost mozna i na novou verzi.

[Michal Kubeček]

Za sebe můžu říct, že mi Plasma 5 přijde v daleko lepším stavu, než bylo KDE4 v době, kdy ho na sílu natlačili do openSUSE rovnou jako default (dokonce i v lepším stavu, než když v další verzi odstranili KDE3). Ale uznávám, že to není moc vysoko nastavená laťka. :-)

[TM]

Je jednoduchá možnost volby KDE4? Zatím jsem neměl čas to zkoumat, ale pokud opět vnucují do stabilní verze nedodělané KDE, je to spíš skandální než na pochvalu za LTS verzi

[_]

simply suse

[Miška]

KDE tym je komunitni

[TM]

Tak to taky vidím.
Jestli toto KDE tým považoval za dobře fungující a ještě přidanou hodnotu, nechápu duševní pochody takového týmu.
Uběhla léta a tak moc se nezměnilo. Schopnost poučit se z chyb stále nízká... Uživatel až na posledním místě, což je v případě LTS šokující.
Tak holt Leap tak někdy za rok. Díky bohu za verzi 13.1.... Sakra já bych za to distro zaplatil, aby se něco změnilo, kdyby bylo komu...

[kyknos]

nic jsi z toho nedelej, dusevni pochody nekterych manazeru v suse jsem nepochopil ani za deset let :)

[xyz]

Řekl bych, že tvá nechopnost pochopit ostatní lidi úplně nesouvisí s kvalitou KDE.

[kyknos]

ja bych rekl, ze v tomto pripade docela ano :)

[xyz]

Ale zas to alespoň částečně vysvětluje to tvoje off-topic nadávky na SUSE

[kyknos]

skoda ze se tihle korporatni trolove nemaji aspon odvahu podepsat :)

ale jestli ti prijde opensuse v cajku, neres to :)

[Miška]

Zalezi od use-case. Nekdy pred rokem to nekde psali, ze KDE5 je uz v ok stavu pro workflow co maj vyvojari a ze potrebujou aby s tim uzivate zacali delat vylomeniny a zjistili co z jejich pohledu nefunguje.

[TM]

Myslíte, že je rozumné dát UI v takovém stavu do distribuce, která se snaží tvářit jako stabilní a dlouhodobě podporovaná? Do distribuce, od které si řada uživatelů slibovala pravý opak toho, co se dělo v minulosti a zjevně stále děje?
Uživatel distribuce tohoto typu není a nechce být vaším testerem.

Kolik let je těm, kteří vydávají taková rozhodnutí? Já bych to dokázal odhadnout tak na 20, nulová praxe.... A to asi přeháním jen poměrně málo... Je to rozumné?

[kyknos]

vekem to nebude :)

[TM]

Mladé a divoké dokážu pochopit.
Ale pokud za tím nejsou, pak už jde o něco, co se sem ani neodvažuji napsat.
Dát do stabilního distra cosi, co neumí ani udržet základní souborový manažer(Dolphin) ve stabilním stavu, to musí dát strašně práce... A to je jen příklad.

[kyknos]

co k tomu rici, nez ze jsem si tam obcas (a cim dal casteji) pripadal jako v blazinci

[marek_hb]

KDE5 na archu je prosím aspoň u mě nerozbité

[Miška]

Vono to urcite bude nerozbite i na tom openSUSE pro spoustu uzivatelu vcetne vyvojaru z KDE teamu, jen kazdy ma veci nastavene jinak

[bill]

Problem je ze padaju zakladne veci ako dolphin ked das right click na nejaky adresar/subor, padaju systemsettings, segfaulty, rozsypany kwin atd... ako to mohlo prejst do noveho oSUSE ktore malo byt vychytane a stabilne, bohuzial vysledok je ze v pripade KDE sa s tym neda pracovat. To tam radsej nemali davat volbu instalacie tohto prostredia.

[advancing in the sun]

jenže GNOME na tom není o moc lépe

[Václav "Darm" Novák]

Osobně to tak mám taky, ale psal bych spíš „pro mě nerozbité“. Pro některé lidi bude třeba příští verze opravovat jednu rozbitou věc která mi nijak nevadí – system tray ikonky pro aplikace co na ně používají xembed. A trochu mi vadí že ještě pořád nefunguje appmenu.

[mimi.vx]

tak znamy problem KDE5 je ze nedela opravy za ostatni komponenty , napriklad gnome3 obsahuje dost workaroundu na ovladace intelu , zatimco KDE na to celkem spravne kasle protoze primarni problem neni u nej.

[Pepan]

I tohle je od února nerozbité??? https://bugs.kde.org/show_bug.cgi?id=344119 Na nb s ovladačem od Nvidie ZCELA nepoužitelné. Přitom konzole v Ubuntu je ok

[TM]

Klid, vývojáři z KDE týmu prý říkali - viz. výše - že pro ně je to prý už OK. Takový typický vývojář Konsoli přece nepotřebuje, na co byste ji potřeboval vy...

Ne, vážně. Je to k breku.

[Michal Kubeček]

Já třeba vývojář jsem (ne KDE), konsoli používám denně (mnoho instancí), ale nemám potřebu zaneřádit si systém closed source drivery, takže jsem na tenhle problém ještě nenarazil.

[Pepan]

To ale není řešení. Kdyby byl problém v Nvidia driveru tak to pochopím, ale proč visící konzolí trpí jenom KDE? Myslel jsem si že konzole v tomhle os je velice důležitá. Takhle je třeba výdrž baterie na NB velice malá a KDE je jako šnek. Přece není normální po každém použití konzole hlídat a ručně zabíjet tento proces i když byl korektně ukončený...

[Michal Kubeček]

Kdyby byl problém v Nvidia driveru tak to pochopím, ale proč visící konzolí trpí jenom KDE?

Opravdu si neuvědomujete, že úplně stejně logicky se lze zeptat obráceně: "Kdyby byl problém v konsoli, tak to pochopím,a le proč se ten problém projevuje jen s closed source NVidia driverem?" Mně tam opravdu chybí odpověď na zcela zásadní otázku: na základě čeho reporter a další automaticky předpokládají, že chyba je v konsoli. Možná je, ale z toho, co je tam napsáno, to ani zdaleka není jasné. Tím spíš, že se hned v úvodním komentáři píše, že skoro všechen čas se spotřebovává v jakési NVidia knihovně…

[Pepan]

jsem jenom obyčejný bfu ale proč tedy ve stejné distribuci tím trpí jenom kde a nejsou dotčena jiná prostředí? V OS a ve Fedoře není přímo nabízený uzavřený ovladač, ale např. (K)ubuntu je uživatel přímo vybízen k jeho instalaci.

[Michal Kubeček]

Z toho pořád ani zdaleka neplyne, že je na vině KDE nebo konsole. Rozhodně ne do chvíle, než se někdo podívá, co konsole z té knihovny volá a jak, a ukáže, že dělá něco, co nemá. Nebo se podívá do toho NVidia driveru… aha, nepodívá…

[Nuphar]

A jak to tedy v této situaci vyřešit? Každopádně to nefunguje. A jak zjistit, kde přesně je problém, když ovladač nemá zdrojáky?

[Michal Kubeček]

A jak to tedy v této situaci vyřešit?

Zkuste si pozorně přečíst příspěvek, na který reagujete. Píšu tam, co by se dalo udělat.

A jak zjistit, kde přesně je problém, když ovladač nemá zdrojáky?

Já třeba právě tohle považuju za problém.

[kyknos]

je celkem jedno, zda za to muze konzole nebo kde, odpovednost ma tvurce distribuce a pokud to neumi vyresit, musi zvolit jinou kombinaci sw

ale samozrejme, suse je suse

[Michal Kubeček]

Je-li to bug v konsoli (poskytované jako součást distribuce), tak je to zodpovědnost distribuce. Je-li bug v third party driveru, který si uživatel do distribuce doinstaloval, pak rozhodně nemůžu souhlasit s názorem, že by autoři distribuce měli nést zodpovědnost za všechny možné i nemožné drivery, které by si uživatel mohl někde sehnat a nainstalovat.

ale samozrejme, suse je suse

Vážně? Já tam vidím bug reportovaný na KUbuntu a komentář, že je to nejspíš duplikát jiného, který byl pozorovaný na Fedoře. V žádném z těch dvou bugů se řetězec "SUSE" (v jakékoli kapitalizaci) vůbec nevyskytuje.

Mimochodem, já vůbec neobhajuju rozhodnutí do Leap 42.1 dát (jen) Plasma 5. A netajím se tím, že kdybych já byl tím, kdo o tom rozhoduje, tak by to tak nebylo. Ale pokud někdo jako ukázku toho, jak je to prostředí strašně rozbité, uvede bug, u kterého není ani trochu zřejmé, jestli jde opravdu o bug v KDE (a spíš to zatím vypadá že ne), tak to prostě není dobře zvolený příklad.

[kyknos]

tak graficky driver neni jen tak nejaky sw, ale celkem predpokladatelna komponenta, na kterou by se melo testovat, pokud to ma byt spolehliva distribuce pro bezne uzivatele

[Michal Kubeček]

Však to také s drivery, které jsou v distribuci, funguje…

[bill]

Prave s nouveau a plasma5 v suse ale aj inych distrach su najvacsie problemy. A teda je to problem distribucie ze zvolila takto neodladene prostredie ako vychodzie. O to vacsi pruser je ze to malo byt najodladenejsie distro z oSuse, ukazuje sa ze je to najvacsia katastrofa.

[kyknos]

melo by to fungovat se vsemi beznymi drivery

[Michal Kubeček]

Ne, tohle prostě neberu. Je-li bug v distribučním balíčku, je to problém distribuce. Je-li bug v driveru, který si uživatel kdesi našel a do distribuce doinstaloval, nemá s tím distribuce nic společného a měl by si to řešit výhradně uživatel s tím, kdo mu ten driver poskytnul.

Distribuce je distribucí proto, že poskytuje ucelenou a otestovanou sadu software. Nemůže nést zodpovědnost za bugy v software, který si do ní uživatel doinstaluje z jiných zdrojů.

[kyknos]

jenze opensuse vzhledem k ruznym politikam neobsahuje ucelenou sadu balicku

[lertimir]

Co je ucelená sada balíčků? Ty které jsou GNU? Nebo ty které mají jakoukoliv licenci, ale "uživatelé je chtějí"?

[kyknos]

ty, ktere umoznuji beznou praci se systemem - graficky ovladac je docela podstatna soucast, stejne tak schopnost prehrat bezna media

[Miška]

jn, ale to se neda nic delat, odtud asi politiku USA nezmenime Nemluve o tom ze proprietarni graficke drivery jsou o licenci ne o patentech. I kdyz ta licence bude takova jaka je pravdepodobne kvuli patentum.

[kyknos]

1) politiku USA nemusime menit, ale take se ji nemusime ridit

2) i kdyz neni mozne balicek prilozit na dvd (popravde receno nechapu, v cem je rozdil, pokud je na dvd nebo se musi dotahnout z netu), je mozne ho otestovat

[Pepan]

Já vás chápu máte pravdu že se do nvidia driveru nepodívá. Jenom jsem myslel že někdo znalý by se mohl podívat proč to zůstane viset i po uzavření. Vždyť např. minulé vydání Kubuntu 15.04 tím netrpělo. Pozoruji to od února kdy to začalo při jedné aktualizaci KDE. Od těch dob byla v KDE konzole mnohokrát, ale bohužel tenhle problém vyřešen do dnešního dne není vyřešem co mě mrzí nejvíc, že je stále unconfirmed Dokonce se mi podařilo úspěšně naprasit nahrazením a přejmenováním přímo soubor konzole z z Gnome do KDE. Fungovalo to několika úpravách dokonce bez chybových hlášení ani jednou proces nezůstal viset. Asi jsem netrpělivý, ale vzdal jsem to a po několikaleté spokojené práci v KDE utekl ke Gnome-shellu který se mi moc nelíbí, ale je celkem funkční. Mějte se zdravím z centra MB na Slunečnou.

[Michal Kubeček]

Už jsem viděl spoustu bugů, které tiše existovaly roky, než se někomu podařilo trefit tu správnou konstelaci, při které se projevily - a pak se mu najednou začaly projevovat naprosto systematicky.

[Václav "Darm" Novák]

Předtím byl bug v Intel driveru a jediná věc o které vím že měla problém byla Plasma. Bez přepnutí ze SNA na UXA plasma padala každých pár vteřin. (ovladače jsou dnes již opravené)

Takže vážně by bylo tak překvapivé kdyby jiná součást desktopu padala kvůli bugu v Nvidia driverech?

[Václav "Darm" Novák]

/padala/blbla

[TM]

Skvělé. Uživatel hardwaru od Nvidie bude kvůli pomatencům, kteří podivným způsobem lepí distra, používat polofunkční a zabugované ovladače jen proto, že jsou otevřené. Přesně kvůli tomuto přístupu a způsobu uvažování je linuxový desktop tam kde je. Poslední verze OpenSuse je jen špička ledovce. Jak je vidět, už 10 let se to plácá pořád na místě bez naděje na poučení.

[Michal Kubeček]

Uživatel hardwaru od Nvidie bude kvůli pomatencům, kteří podivným způsobem lepí distra, používat polofunkční a zabugované ovladače jen proto, že jsou otevřené.

To je jeho volba, jaký driver použije. Ale pokud použije driver mimo distribuci, nemá žádné právo očekávat, že distribuce bude vymýšlet workaroundy na bugy v něm. Ty ať si řeší s tím, od koho ten driver má. Já třeba používám VMware Workstation a ani na vteřinku by mne nenapadlo požadovat od distribuce, aby patlala workaroundy na případné bugy v tomto software. A nevidím jediný důvod, proč by to s closed source drivery od NVidie mělo být jinak.

Za sebe to ovšem řeším tím, že je-li open source driver špatný a jedinou alternativou je closed source driver od výrobce, tak se prostě GPU této značky vyhýbám. Jejich volba, moje volba.

Poslední verze OpenSuse je jen špička ledovce.

Ani vy jste si nevšiml, že žádný z těch dvou reportů nebyl hlášen z openSUSE a že tedy není vůbec jisté, jestli se ten problém Leap 42.1 vůbec týká?

[lertimir]

Naprostý souhlas. Distra se dávají dohromady různým způsobem a konkrétně openSUSE je velmi open v GNU smyslu. Tedy že žádný propritární a licenčně omezovaný soft nemá ve standardních repozitářích. Pokud to někomu nevyhovuje ať si najde jiné distro s jinou politikou směrekm k uzavřenému kódu. Napřiklad, když jsem před léty zkoušel Sabayon, tak už při startu live se ptal, jestli bych chtěl použít uzavřené drivery. A takové distro se o workaround bude asi více starat, tak uživatel může zvolit je.

[bill]

Sranda bude ked za 1.5 roka vyjde debian 9 slavnostne s plasma 5.4 a vsetkymi jej bugmi. Dufam ze rovnaku chybu nespravia.

[doron]

Pokud si někdo nechce hrát s KDE Plasma 5 na openSUSE Leap, tak je cesta již dnes, jak se vrátit ke KDE 4, aniž by bylo nutné si kompilovat vlastní balíčky. Je to repozitář s aktuální verzí KDE 4 pro SLE 12 (na kterém je Leap postavený).

http://download.opensuse.org/repositories/KDE:/Current/SLE_12/

[Petr]

Zdravím, Mohl byste sem hodit návod, jak přejít ke KDE 4? Klidně i návod pro instalaci openSUSE ze sítě z přidáním podpory KDE 4. Děkuji ;)

[doron]

zypper addrepo http://download.opensuse.org/repositories/KDE:Current/SLE_12/KDE:Current.repo

zypper refresh

Takto přidáte repozitář, pak použít grafický YAST, a nainstalovat potřebné balíčky. Tím zrušíte Plasma 5 (některé balíčky jsou konfliktní). Podrobný návod nemám, dnes jsem se vrátil ke KDE5, tak bych si mohl zaznamenat postup. Není to ale dokonalé řešení. Stále tam zůstávají dvě konfigurační centra pro KDE (některé kcm moduly pro KDE4 chybí). Tak snad to udělá někdo pořádně (mám zkušenosti s backportováním rpm jen pro vlastní potřebu, openSUSE Buildservice neovládám).

Dost možná se brzy vrátím zpět ke 13.2 a vydržím s ní až do konce (tedy Leap mám pouze na pracovním PC, jinak doma 13.1 a 13.2 a v práci na ostatních PC co spravuji také).