Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Luboš Kocman, Release Manager openSUSE Leap, oznámil, že verze 15.2 linuxové distribuce openSUSE Leap vstoupila do beta fáze. Připojit se lze k testování a hlásit chyby. Aktivní testeři mohou získat tričko. Finální vydání openSUSE Leap 15.2 je plánováno na 7. května 2020.
Tiskni
Sdílej:
Jako nostalgické muzeum v Linuxu vždy sloužil Debian, nevidím důvod s ním na tomto poli soutěžit...
Mě prostě hlava nebere, proč se někdo rozhodne vydat 3 po sobě jdoucí release (15.0, 15.1, 15.2) distribuce se stejnou verzí "koncové desktopové aplikace", přesto, že ta samá aplikace v "testovací" verzi téže distribuce mezitím doiterovala o 36 verzí dál...
Nejpravděpodobnější vysvětlení je, že nikdo nesubmitnul novější verzi. Primárně by to měl udělat maintainer toho balíčku, pokud usoudí, že by tam novější verze být měla. Tak jsem zkusil podívat, kdo to je:
mike@unicorn:~> osc maintainer gpxsee Defined in package: graphics/gpxsee bugowner of gpxsee : - maintainer of gpxsee : tumic mike@unicorn:~> osc whois tumic tumic: "Martin Tůma" <...>
Zajímavá shoda jmen…
No shoda jmen tam sice je, ale je to skutečně správce toho balíčku? Měl jsem za to, že do Leap chodí balíčky z Factory a tam je IMHO správce Dominique Leuenberger (dimstar_suse), nebo obecně někdo ze SUSE. Pokuď je vývojový model takový, že by lidé, co submitují balíčky do Factory měli řešit i balíčky v Leap, bylo by vhodné to explicitně někde zdůraznit, protože jak se ukazuje, není to vůvec zřejmé (Popravdě mám za to, že takový request - z Factory do Leap vůbec nemůžu udělat, pokuď nejsem správcem toho balíčku ve Factory).
Každopádně i kdyby tomu tak bylo, tak bych očekával, že před release někde proběhne kontrola verzí a někdo začne pátrat po tom, proč se verze za tři release Leap nezměnila zatímco ve Factory je verze extrémně vyšší...
Tak při pokusu o submit do Leap to píše: "You are about to bypass the devel project, please submit to graphics instead."...
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
25.2.2020 09:20
openSUSE:Factory z něčeho jiného než z devel projectu.
ale je to skutečně správce toho balíčku
Pokud není, mělo by se to opravit.
Měl jsem za to, že do Leap chodí balíčky z Factory
To je různé. Některé balíčky jsou převzaté ze SLE (především základ systému), některé z Factory, některé mají z různých důvodů svou vlastní verzi.
Pokud by někdo přišel s nápadem, že s novou verzí Leapu budou automaticky updatovat balíčky na verzi z Factory, budu první, kdo proti tomu bude velmi hlasitě protestovat, protože by to v podstatě zabilo původní myšlenku Leapu a vrátilo ho to k modelu, který jsme měli do openSUSE 13.2.
Představa, že tohle bude řešit Dimstar (nebo kdokoli jiný) pro celou distribuci, je nereálná. Různé balíčky mají svá specifika a maintainer by měl vědět nejlépe, jaký model je pro který balíček nejvhodnější. Modelový příklad: když vyšel Firebird 3.0, bylo logické, že nová verze šla do Factory co nejdříve, ale protože přinášela zpětně nekompatibilní verzi formátu souborů s databázemi (což v praxi znamenalo nutnost provést pro všechny databáze backup starou verzí a restore novou), nebylo žádoucí, aby nová verze šla i do Leap 42.3; proto tam zůstala verze 2.5 a 3.0 byla až v Leap 15.0. Nebo třeba iproute2 a ethtool budou v Leap 15.2 ve verzi 5.3, protože to odpovídá jádru, přestože Tumbleweed už má 5.5 a 5.4.
Popravdě mám za to, že takový request - z Factory do Leap vůbec nemůžu udělat, pokuď nejsem správcem toho balíčku ve Factory
Request může udělat kdokoli (a jednu dobu se dokonce běžně stávalo, že takový request klidně prošel, aniž by se o něm maintainer balíčku vůbec dozvěděl, natož se k němu mohl vyjádřit - což bylo hodně špatně). Ale maintainer balíčku je ten, kdo by to udělat měl. Protože, jak už jsem napsal, on je (nebo by aspoň měl být) tím, kdo má nejlepší představu, jaká verze je nejvhodnější.
Nepředstavuju si, že to pro celou distribuci řeší jeden člověk, ale přišlo mi tak nějak samozřejmé, že to obecně řeší lidé ze SUSE. Už jenom proto, že ta první a stále "aktuální" verze se do Leap 15.0 dostala, pokuď si dobře pamatuji, zcela bez mého přičinění (tzn. request Factory->Leap pro můj balíček tenkrát dělal právě někdo ze SUSE). Lidem co v SUSE pracují možná přijdou některé věci ohledně fungování vývoje openSUSE samozřejmé, ale někomu, kdo se k tomu balíčku dostal víceméně jako "slepý k houslím" to už tak samozřejmé přijít nemusí...
Možná alespoň nějaký mail před "feature freeze" Leap ve stylu: "Váš balíček je v Leap v jiné verzi, než ve Factory, je to správně? Pokud ne, udělejte to a to" by jste správcům balíčků posílat mohli.
Už jenom proto, že ta první a stále "aktuální" verze se do Leap 15.0 dostala, pokuď si dobře pamatuji, zcela bez mého přičinění (tzn. request Factory->Leap pro můj balíček tenkrát dělal právě někdo ze SUSE).
Na rozdíl od toho starého modelu, který tu byl do openSUSE 13.2, u Leapu záleží na rozlišení nové "major" verze a nové "minor" verze; už proto, že základem je SLE, kde je dost velký rozdíl mezi novou verzí (tj. kompletně novým codestreamem) a novým service packem (kde je version upgrade jen u balíčků, kde je k tomu důvod, a typicky je na to potřeba feature request (i když ho někdy založí maintainer toho balíčku)).
Proto u Leap 15.0 bylo normální, že balíčky, které se nepřebíraly ze SLE15, dostaly novou verzi z Factory, dokonce to snad IIRC dělal i nějaký skript. Oproti tomu u 15.1 a 15.2 by defaultem mělo být to, že balíček zůstane ve stejné verzi, pokud se někdo nerozhodne, že je pádný důvod version upgrade udělat. Tedy to aspoň byla původní idea toho, jak by měl Leap fungovat, mimo jiné proto, aby se minimalizovalo riziko různých nemilých překvapení, která s sebou version upgrade obvykle přináší. Postupem času bohužel tohle původní pojetí ustupuje do pozadí a čím dál víc se vracíme k tomu, jak openSUSE fungovalo před Leapem. Teď jsem třeba ke svému nemilému překvapení zjistil, že "split view" u konsole najednou funguje v 15.2 úplně jinak, než jsem byl zvyklý (a pro mne se tím tato funkce stala prakticky nepoužitelnou). Naštěstí to neplatí pro většinu balíčků převzatých ze SLE, což je základ systému, a hlavně pro jádro, u kterého byl ten starý model největším průšvih (i když se pořád ozývají hlasy "proč to, proboha, vydáváte s tak starým jádrem").
25.2.2020 22:20
xxx | skóre: 42
| blog: Na Kafíčko
Oproti tomu u 15.1 a 15.2 by defaultem mělo být to, že balíček zůstane ve stejné verzi, pokud se někdo nerozhodne, že je pádný důvod version upgrade udělat.Nechci byt jizlivy, ale jeste jsem nevidel workflow obsahujici osobu "se nekdo", ktere by fungovalo.
Ono to hlavně nikdy nemůže fungovat, když ten "někdo" ani neví, že je ten "někdo", protože automaticky předpokládá opačný model fungování - balíček vyjde v Leap ve stejné verzi jako je ve Factory, pokuď se někdo nerozhodne, že tomu tak být nemá...
Nechce se mi teď pátrat, jestli je to nějak podpořeno teorií grafů, ale odhadem bych řekl, že "koncových aplikací" na kterých nic nezávisí (a u kterých obecně bude žádoucí mít nejnovější verzi) bude ve stromu závislostí nejvíc. Navíc to bude samozřejmě žádoucí i pro spoustu knihoven. Proto bych prostě očekával, že výchozí politika to bude reflektovat.
To ale pro "lidi z ulice" v openSUSE očividně moc nefunguje, protože většina procesů tam počítá s tím, že ti maintaineři jsou součástí SUSE korporátu a mají informace/možnosti, které ostatní nemají. Vše v OBS nad rámec běžného vytvoření si balíčku je pro člověka "z venku" problém. Už třeba jenom to, kam reportovat bugy, protože OBS na Githubu je spíš pro OBS jako produkt, než pro jeho SUSE instanci s jejími pravidly a speciálními nastaveními.
No a pak je tu samozřejmě ta zcela nepřehledná změť pravidel a postupů (viz ten příspěvek od Luboše Kocmana), jak vzniká Leap. Poslední WTF, které jsem tady zažil - balíček z Factory nelze submitnout do Leap, protože jméno neodpovídá jménu ve specfile. Pod jménem ze specfile ten balíček ale nelze vložit, protože balíček s tímto jménem není ve Factory. Hlava XXII...
To ale pro "lidi z ulice" v openSUSE očividně moc nefunguje, protože většina procesů tam počítá s tím, že ti maintaineři jsou součástí SUSE korporátu a mají informace/možnosti, které ostatní nemají.
Tohle bych určitě netvrdil. Jsou sice oblasti, kde to tak do určité míry je, např. u jádra je to pro případného přispěvatele zvenku komplikovanější, ale řekl bych, že to je spíš důsledek toho, že zatím nebyla moc poptávka, takže nebyla ani potřeba to nějak řešit. Jinak jsou asi největší problém reference v logu na non-public bugy v bugzille, ale to u balíčku, který není ve SLE, nehrozí.
No a pak je tu samozřejmě ta zcela nepřehledná změť pravidel a postupů (viz ten příspěvek od Luboše Kocmana), jak vzniká Leap. Poslední WTF, které jsem tady zažil - balíček z Factory nelze submitnout do Leap, protože jméno neodpovídá jménu ve specfile. Pod jménem ze specfile ten balíček ale nelze vložit, protože balíček s tímto jménem není ve Factory. Hlava XXII...
Ze zkušenosti vás mohu ujistit, že podobnými problémy trpí přispěvatelé z řad zaměstnanců úplně stejně jako ti externí. Nebo možná spíš víc, protože se jich týkají i věci, na které externí přispěvatel ani nenarazí.
Ze zkušenosti vás mohu ujistit, že podobnými problémy trpí přispěvatelé z řad zaměstnanců úplně stejně jako ti externí. Nebo možná spíš víc, protože se jich týkají i věci, na které externí přispěvatel ani nenarazí.politovat nebo utratit?
Případně, pokud vás tak pohoršuje slovo "někdo", mohu to pro vás formulovat obráceně: pokud nikdo novější verzi nesubmitne, tak tam prostě zůstane ta stávající.
Horší problém je, že spousta lidí pořád žije v představě, že když v Leapu nebudou nejnovější verze všeho, bude to naprostá tragédie. Ale za prvé: Leap není a nemá být bleeding edge distribuce, pro dobrodružné povahy máme Tumbleweed. Pro mne je třeba mnohem větší problém, když se přijímají submit requesty nových verzí od náhodných kolemjdoucích, aniž by se řešilo, jestli se dotyčný o ten balíček taky hodlá starat. A za druhé: openSUSE nabízí velmi jednoduchou možnost, jak i v Leapu snadno používat novější verze balíčků, které v novějších verzích chci. Takže já jsem ještě před týdnem na jednom stroji měl 15.1, ale např. s jádrem 5.6-rc2 a gitem 2.25.
26.2.2020 14:54
xxx | skóre: 42
| blog: Na Kafíčko
Případně, pokud vás tak pohoršuje slovo "někdo", mohu to pro vás formulovat obráceně: pokud nikdo novější verzi nesubmitne, tak tam prostě zůstane ta stávající.
Na veky veku.
Horší problém je, že spousta lidí pořád žije v představě, že když v Leapu nebudou nejnovější verze všeho, bude to naprostá tragédie. Ale za prvé: Leap není a nemá být bleeding edge distribuce, pro dobrodružné povahy máme Tumbleweed.To chapu, ze to nema byt rolling distro. Na druhou stranu, tak jak je to popasano, to znamena, ze to je distro s nahodne starymy verzemi programu. Tedy pokud tam neni "nekdo", kdo pred vydanim Leapu pingne vsechny maintainery, zda-li jsou si jisti verzi.
Pro mne je třeba mnohem větší problém, když se přijímají submit requesty nových verzí od náhodných kolemjdoucích, aniž by se řešilo, jestli se dotyčný o ten balíček taky hodlá starat. A za druhé: openSUSE nabízí velmi jednoduchou možnost, jak i v Leapu snadno používat novější verze balíčků, které v novějších verzích chci. Takže já jsem ještě před týdnem na jednom stroji měl 15.1, ale např. s jádrem 5.6-rc2 a gitem 2.25.No ona asi jedina rozumna moznost je si to rozdelit do nejakych skupin, jako core, desktop, server, ... s definovanymi spravci, ktery si to pohlidaji, a ostatni baliky mit nekde v optional.
Na veky veku.
Ne. Jak už jsem napsal dříve, bude to do příští major verze.
26.2.2020 16:57
xxx | skóre: 42
| blog: Na Kafíčko
To je pořád dokolečka… Leap je - nebo by aspoň měl být - stabilní a konzervativní distribuce, kde by mělo být relativně bezpečné upgradovat na novou minor verzi. Proto je defaultem zachování stávající verze balíčku a je potřeba vyvinout aktivitu, aby se přešlo na novou. Pokud si maintainer konkrétního balíčku myslí, že v daném případě je žádoucí version upgrade udělat, tak ho má udělat, od toho je maintainer.
Sorry, že už se neudržím a řeknu to na plnou… ústa, ale pokud se maintainer balíčku není ochoten ani jednou za rok zamyslet nad tím, jestli do nové minor verze distribuce chce novou verzi nebo jestli bude lepší zůstat u stávající, jak mám věřit, že se o ten balíček opravdu stará a bude např. řešit bezpečnostní (a jiné) chyby?
26.2.2020 17:50
xxx | skóre: 42
| blog: Na Kafíčko
27.2.2020 13:26
xxx | skóre: 42
| blog: Na Kafíčko
Ale ten problém opravdu není v tom maintainerovi, ale v v tom byrokratickym bordelu jakým je Leap spravován. Ten, koho vy považujete za maintainera balíčku, vůbec nemusí tušit, že ho za něj SUSE považuje. A aktivní může být dost - například ve Factory updatuje ten balíček každých ~14dní. Pokuď ale do Leap ten balíček neposílal, jak má vědět, že bez jeho přičinění se ten balíček nadále updatuje jenom jednou za 4 roky?!
Když jsem psal, že se počítá s tím, že ti maintaineři jsou součástí SUSE, měl jsem na mysli právě takové "samozřejmé" informace, které někdo, kdo tam chodí každej den na 8h prostě pochytí, ale člověk z venku je vůbec nepředpokládá natož aby je aktivně vyhledával.
jak mám věřit, že se o ten balíček opravdu stará a bude např. řešit bezpečnostní (a jiné) chyby?
Přesně na to se ptám i já. Současný model bez jakékoliv kontroly/akce ze strany SUSE, kde výchozí politikou je "nechat hnít", právě znamená to, že okrajové balíčky budou s velkou pravděpodobností nefunkční/děravé aniž by to někdo řešil.
Především souhlasím, že stav, kdy je někdo maintainerem balíčku a neví o tom, je špatně. Nemám ale informace, jak k tomu ve vašem případě došlo, takže nemůžu posoudit, nakolik je to vaše vina a nakolik někoho jiného.
Co se týká bugů, očekával bych, že pokud není nastaven bugowner a jste jediný maintainer, případný bug stejně bude nakonec screeningem přidělen vám a o tom vám bugzilla pošle notifikaci.
Především souhlasím, že stav, kdy je někdo maintainerem balíčku a neví o tom, je špatně. Nemám ale informace, jak k tomu ve vašem případě došlo, takže nemůžu posoudit, nakolik je to vaše vina a nakolik někoho jiného.
Po submitu do graphics mi někdo ze SUSE nabídl, jestli se o ten balíček v graphics nechci starat, s čímž jsem souhlasil. Co z toho vyplývá dál za mašineri jsem ale do hloubky nezkoumal. Pro ilustraci - pro GPXSee někdo v graphics nastavil automatické přeposílání submitů do Factory. Pro další dva balíčky co tam mám tomu tak ale není. Je to záměr SUSE? Je to chyba? A stejně tak "magicky" se GPXSee objevilo v Leap 15.0. v aktuální verzi. Jak si z toho odvodit, že v 15.1 a 15.2 už v aktuální verzi nebude?
Co se týká bugů, očekával bych, že pokud není nastaven bugowner a jste jediný maintainer, případný bug stejně bude nakonec screeningem přidělen vám a o tom vám bugzilla pošle notifikaci.
Tohle mooožná platí pro kernel ve SLES, ale pro běžný SW nikdo bug reporty do distribucí nedělá, drtivá většina jich jde do upstreamu. Při srovnání přívětivost reportování do openSUSE s issue na GitHubu se ani není čemu divit. Koneckonců i samotné OBS má issue tracker na GitHubu... A o takových chybách se v SUSE bez nějaké snahy nikdo nedozví, i když uživatele openSUSE samozřejmě zasáhnou.
Pro ilustraci - pro GPXSee někdo v graphics nastavil automatické přeposílání submitů do Factory. Pro další dva balíčky co tam mám tomu tak ale není.
Těžko říct, zatím jsem nenarazil na balíček, kde by to tak nefungovalo. Kdykoli udělám update balíčku v devel projectu Factory a nepošlu submit request do openSUSE:Factory, za týden to udělá bot. Naštěstí se zle nastavit jako reviewer a pak mám možnost takový request zamítnout, pokud chci z nějakého důvodu ještě počkat.
A stejně tak "magicky" se GPXSee objevilo v Leap 15.0. v aktuální verzi. Jak si z toho odvodit, že v 15.1 a 15.2 už v aktuální verzi nebude?
Už jsem se to v této diskusi pokusil vysvětlit dvakrát nebo třikrát. Pokud to stále ještě nestačilo, nedělám si iluze, že další opakování na tom něco změní.
pro běžný SW nikdo bug reporty do distribucí nedělá
Pokud uživatel chybu nenahlásí, tak holt nemůže očekávat, že ji někdo opraví, to je jeho problém, ne maintainera. U security bugů, přinejmenším těch, které mají CVE id, se o to stará security team.
Na druhou stranu si ale myslím, že součástí role maintainera by mělo být i to, že sleduje upstream a opravy nejzávažnějších chyb bude opravovat proaktivně. Jsem si ovšem vědom, že s touto představou jsem v rámci openSUSE těžce v menšině.
Při srovnání přívětivost reportování do openSUSE s issue na GitHubu se ani není čemu divit.
Tady se asi nemáme šanci shodnout. Na githubu je určitě jednodušší založit issue, ale tím veškerá přívětivost končí. Pokud je postřeba další komunikace, bugzilla vede na plné čáře. Jako člověku, který se častěji pohybuje na druhé straně reportu, mi issue tracking na githubu rozhodně neimponuje.
Ostatně i ta snadnost založení issue je tak trochu dvojsečná, když se třeba podívám na "issues", která mi lidé zakládají k vmware-host-modules, tak mám pochybnosti, k čemu tam ten issue tracker vlastně je. Polovina reportů by vůbec nevznikla, kdyby se dotyčný obtěžoval přečíst INSTALL, další jsou problémy, které se na první pohled vůbec netýkají těch modulů, a i ten zbytek je, až na jednu nebo dvě výjimky, o tom, že reporter má buď rozbitý build environment, použil špatnou větev nebo ji nemá aktuální.
A o takových chybách se v SUSE bez nějaké snahy nikdo nedozví
Nepleťte do toho, prosím, pořád SUSE. Jakkoli nemám rád snahy předstírat, že openSUSE je v podstatě klasická komunitní distribuce (což není ani zdaleka), ne všechno kolem openSUSE je záležitost a zodpovědnost SUSE. A starání se o balíček je zodpovědnost jeho maintainera, ne SUSE.
Už jsem se to v této diskusi pokusil vysvětlit dvakrát nebo třikrát. Pokud to stále ještě nestačilo, nedělám si iluze, že další opakování na tom něco změní.
Já se ale neptám na to, jak to je, což tady padlo, ale na to, jak má "člověk z ulice" vědět, že to tak je. A na to tady odpověď stále nezazněla. Poukazuju tím na to, že chce-li SUSE zajistit kvalitu té distribuce, musí také věnovat nějaké prostředky na její kontrolu. Což v tomto případě znamená, že by měl někdo alespoň začít pátrat po tom, proč se verze balíčku v Leap za 3 verze Leap nezměnila, zatímco ve Factory se za tu dobu změnila víc jak 30x. A to by zákonitě mělo vést alespoň na kontaktování maintainera balíčku. Nic takového se ale očividně neděje.
ne všechno kolem openSUSE je záležitost a zodpovědnost SUSE. A starání se o balíček je zodpovědnost jeho maintainera, ne SUSE.
Samozřejmě, že SUSE má zodpovědnost za balíček, protože ten je součástí distribuce (ta distribuce koneckonců není nic jiného, než soubor balíčků). Nebo snad chcete tvrdit, že si společnost nechá své jméno "nalepit" na produkt, za který není zodpovědná a jehož kvalitu nedokáže ovlivnit? Když balíček nebude použitelnej, dopadne hněv uživatele na SUSE, ne na nějakého chudáka, kterého SUSE shodou okolností považuje za maintainera balíčku...
Což v tomto případě znamená, že by měl někdo alespoň začít pátrat po tom, proč se verze balíčku v Leap za 3 verze Leap nezměnila, zatímco ve Factory se za tu dobu změnila víc jak 30x.
Opakovaně - a, jak je vidět, stále marně - se vám tu snažím vysvětlit, že po ničem takovém není potřeba pátrat, to je prostě u Leapu defaultní chování. Je na maintainerovi, aby zařídil opak, pokud je přesvědčen, že je to žádoucí. A ano, kromě toho, co už jsem napsal, bych od maintainera očekával i to, že bude mít základní povědomí o fungování distribuce a o tom, jaký je rozdíl mezi major a minor verzí.
Nebo snad chcete tvrdit, že si společnost nechá své jméno "nalepit" na produkt, za který není zodpovědná a jehož kvalitu nedokáže ovlivnit?
Obávám se, že roli SUSE silně přeceňujete (což je svým způsobem opak toho, trendu, který poslední dobou se znepokojením pozoruji). Při množství balíčků v distribuci je nereálné, aby každý balíček v distribuci hlídal někdo ze SUSE. Předchozí chairman boardu dokonce s oblibou operoval statistikou, podle které asi dvě třetiny balíčků v openSUSE nemaintainují zaměstnanci (přičemž takticky zamlčoval, že není balíček jako balíček a že u těch podstaných by ten poměr vycházel úplně jinak). Většina lidí, kteří dělají review, jsou sice zaměstnanci, ale ti řeší spíš formální náležitosti a není v jejich silách hlídat kvalitu práce maintainera v tom smyslu, jak si ji představujete vy.
Ty balíčky sice nemají komerční support, ale:
SUSE Approved. While the packages from the SUSE Package Hub are not officially supported by SUSE, SUSE Linux Enterprise Server remains supported and supportable when using these packages.
To je poměrně silné spojení se SLES, zvlášť když člověk uváží, jak omezený je výběr SW ve SLES.
Nicméně nemyslím si, že je nutné tady slovíčkařit na téma: "proč by firma neměla srát na kvalitu vlastních produktů". openSUSE je prostě produkt SUSE (ač s přispěním komunity) a jako takový prostě o této firmě ledacos vypovídá a dělá jí reklamu (ať už dobrou, nebo špatnou). No a zákazník si pak samozřejmě položí otázku: když za hovno stojí openSUSE, proč by tomu mělo být u SLES jinak?
A stejně tak je produkt SUSE SUSE Package Hub. Po pravdě řečeno, jak si to teď znova čtu, nechápu, že takovou otázku - "proč by managera ze SUSE měl zajímat SUSE Package Hub" - může někdo vůbec myslet vážně...
28.2.2020 21:42
xxx | skóre: 42
| blog: Na Kafíčko
FAQ je pro ty, co neví, co znamená „community“ v komerčním newspeaku, a pro právníky, aby tě setřeli, kdybys chtěl SUSE hnát k zodpovědnosti. Je to tam přesně pro ty lidi, co si myslí, že, když něco je na doméně suse.com, tak to nemůže být nějakej shit.
Ve vašem druhém odstavci je klíčové slovo zákazník. To je v newspeaku slovo duální ke community member. Je to někdo, se kterým mám smlouvu, ve které je přesně stanoveno, za co ručím. A pokud je vaše firma jen trochu větší než jedna garáž, tak vám v zájmu vašeho zdraví nedoporučuji se do takové smlouvy dívat, protože jinak ztratíte veškeré ideály.
Za takovéto nedorozumění se nemusíte stydět. Dějete to dnes a denně a problém, jak oddělit komerční a nekomerční nabídku tak, aby zákazníci přesně věděli, na čem jsou, a nepodléhali dojmům, je z obchodního hlediska velmi palčivá. Špatné dojmy totiž nejen že vytváří špatný mediální obraz, ale především představují náklady, protože firma musí zákazníky slušně posílat do … a to spotřebová zaměstnance a tedy peníze a žádný zisk z toho není.
Já pracuji ve stejném oboru jako pan Kubeček. Když jsem začínal, tak jsem byl natěšený, jak střelhbitě opravím každou nahlášenou chybu a tím pomůžu jak zaměsntavateli, tak i zákazníkovi a tedy i sobě, ale realita mě vyléčila. Naštěstí open source produkt nevzniká ve vakuu, takže zaměstnavatel dotuje rozvoj produktu v komunitě, takže se můžu realizovat tam a hřeje mě vědomí, že tam výsledky mé práce zůstanou dostupné i po té, co můj zaměstnavatel přestane být mým zaměstnavatelem.
