Red Hat nebude spravovat RPM balíčky pro LibreOffice

Matthias Clasen z Red Hatu oznámil v diskusním listu vývojářů Fedora Linuxu, že tým Red Hat Display Systems se zaměří na Wayland a podporu HDR na Linuxu a přestane spravovat RPM balíčky pro LibreOffice. V další major verzi RHELu už LibreOffice nebude. Pokud se nenajde správce balíčků pro Fedora Linux, zůstane pouze LibreOffice ve Flatpaku.

2.6.2023 19:55 | Ladislav Hagara | Komunita

Komentáře

[--]

Hodně zvláštní a nelogické rozhodnutí.

[Ilfirin]

Zvláštní možná, ale nelogické? Logicky tlačí Flatpak na desktop aplikace.

[_]

Na tom není nic logického, to je čistá demence.

[hm]

hele nejakej kedar tady na mne nekde kricel ze luniks je bezproblemovy tak proc delate paniku vzdyt luniks s tim nebude mit problemy takze pohodicka klidek tabacek kedar rekl jennom verte luniksu a problemy vas obejdou protoze luniks neni problemovy

[X]

Nezustane, proste si je stahnes ze stranek LibreOffice.

To je takové správné Windows řešení.

[hm]

+1 konecne to nekdo po tech 50 let pochopil cojz se o nekterich luniksaku neda rict dokonce i dnes

Já to nemyslel jako pozitivum. Ale ano, máš pravdu, že způsob distribuce softwaru na Windows se za těch 50 let, od doby CP/M, výrazněji nezměnil.

Jestli mi na Windows něco (kromě všudypřítomného šmírování a v 11 i nucení online účtu) skutečně vadí, pak je to i v roce 2023 nutnost shánět software (či jeho aktualizace) různě po webu. Možnost "sideloadovat" aplikace by samozřejmě měla být v každém dnešním OS, ale neměl by to být běžný stav. Apple tohle pochopil již před lety, Microsoft se pokoušel prosadit svůj Store, nicméně dodnes se mu to nepodařilo a nová verze Store slouží (stejně jako winget) de facto jako pouhý stahovač *.exe instalátorů. Což je dost smutné vzhledem k tomu, že technologie Microsoft měl již před lety - např. MSIX pro pohodlnou a bezpečnou distribuci sandboxovaných aplikací.

Čímž netvrdím, že mi nevadí spousta věcí na desktopovém Linuxu (tam je ta kvalita v čase výrazně proměnlivá, zatímco Windows je tak nějak konstantně stejně špatný). Nicméně zrovna moderní způsoby distribuce aplikací jsou něco, v čem má Linux již delší čas výrazně navrch.

[Ivan3]

No prave. Ja jako vyvojar chci uzivatelum nabidnout aktualni SW s aktualnima featurama. Uzivatele taky chteji aktualni SW. Mezi mnou a uzivatelem je ale spravce baliku v distribuci, ktery se obe strany snazi presvedcit, ze pouzivat 5 let starou verzi aplikace je uplne normalni, a z jedine chyby ktere se smi opravovat jsou ty bezpecnostni.

Takovy zpusob distribuce SW se ale hodi pro server, a ne pro desktop. Pokud se ma Linux prosadit na desktopu, tak musi mit i balikovaci system vhodny pro desktop.

[AsciiWolf]

Třeba Fedora má u většiny balíků aktivního maintainera a jejich nové verze většinou vydává i pro starší (podporované) verze Fedory. Debian Stable má zase Backports repozitář, kde je k dispozici spousta softwaru v nových verzích. Problém je v tomto ohledu s Ubuntu, kde většina balíků v Universe nemá aktivního maintainera, jsou pouze syncnuté z Debianu před vydáním nové verze distribuce a nadále již nejsou aktualizované a v případě LTS jsou často několik let rozbité.

Pak tady samozřejmě máme "moderní způsoby" distribuce softwaru jako je Flatpak či Snap, které specificky cílí právě na distribuci softwaru třetích stran, jeho pravidelné aktualizace a bezproblémový běh na různých distribucích a softwarových konfiguracích.

[xkucf03]

Např. v Ubuntu založeném na .deb balíčcích si můžeš vybrat Javu verze 8 až 20 a dokonce jich mít nainstalovaných víc současně. Klasický balíčkovací systém tomu tedy tak úplně nebrání. Totéž by šlo dělat i pro jiné aplikace nebo knihovny. Kdo chce používat pět let starou verzi, ten může. A kdo chce novější, ten by si ji mohl nainstalovat klidně i do LTS distribuce.

[kralyk z abclinuxu]

Takovy zpusob distribuce SW se ale hodi pro server, a ne pro desktop. Pokud se ma Linux prosadit na desktopu, tak musi mit i balikovaci system vhodny pro desktop.

+1, nicméně ono to ani není až tak moc o tom balíčkovacím systému jako takovém, to je technikálie. Je to o procesu. Všelijaké Deb, RPM a další balíčky se klidně dají sestavovat automatizovaně. Problém je, že publikace balíčků do distribucí má nejasná pravidla, je tam spousta byrokracie, free-form komunikace, ruční práce... Je to taková Česká pošta linuxového ekosystému.

No a samozřejmě problém pak je taky neexistence uceleného konzistentního prostředí, od takových základů jako je kompatibilita libc a dalších knihoven až po high-level featury, třeba takové věci jako přizpůsobovat se světlému vs tmavému motivu prostředí, reagovat na změny displaye/HDPI, zobrazovat notifikace, přistupovat na síť (což zahrnuje takové věci jako TLS certifikáty nebo třeba lokální sítě s mDNS), přehrávat video a audio, interagovat s HW...

Tohle linux ekosystém nemá vyřešeno nějakou ucelenou, obecně fungující / předvídatelnou formou, a tudíž by naprosto nemělo být překvapivé, že je na desktopu neúspěšný.

Vím samozřejmě o různých iniciativách tohle zlepšit a ono se to postupně semtam zlepšuje, ale pomalu a je to všechno strašná bolest. Když vemu v úvahu, jaké množství svatých válek a dalekosáhlé pozdvižení vyvolalo už jen systemd...

[xkucf03]

a tudíž by naprosto nemělo být překvapivé, že je na desktopu neúspěšný.

Tohle je dost podivná úvaha. Většinu uživatelů odradí, že 1) koupili počítač s předinstalovanými MS Windows, 2) pokud už jim někdo GNU/Linux nabízel, tak dost možná ztroskotali na to, že jejich oblíbená aplikace/hra je dodávaná jen pro MS Windows. Téměř nikdo z nich se nedostal tak daleko, aby narážel na detaily, které popisuješ výše.

[kralyk z abclinuxu]

Nepochopils, detaily, které popisuješ výše jsou právě přesně příčina toho, že že jejich oblíbená aplikace/hra je dodávaná jen pro MS Windows.

[xkucf03]

Pořád se na to díváš moc pohledem vývojáře. O tom, zda podporovat další platformu rozhodují manažeři. A v lepším případě rozhodují na základě nějakých statistik nebo průzkumů - jaký podíl má daná platforma na trhu, kolik procent našich stávajících uživatelů ji používá atd. Na nějakou diskusi ohledně pracnosti implementace nebo o tom, kam v GNU/Linuxu budeme ukládat certifikáty, vůbec nedojde. Manažer to prostě hodí přes palubu proto, že mu nějakých „pár procent“ desktopového trhu přijde příliš málo než aby nad tím vůbec přemýšlel.

I kdyby tu podporu přidali vývojáři po večerech jako jakousi partyzánskou akci, aniž by to měli zadané jako úkol, tak se to těžko dostane do oficiální distribuce a získá oficiální podporu. Pokud by se do toho ti vývojáři sami pouštěli, tak opravdu záleží na jiných věcech, než jsou ty detaily o kterých píšeš - hlavně na jejich odvaze a ochotě dělat něco navíc. Jak dobře to bude fungovat na HiDPI displeji nebo jestli se na tmavém desktopu nezobrazí světlá aplikace, hraje asi tu nejmenší roli.

Ono by někdy úplně stačilo dodat dokumentaci nebo lehce upravit kód, aby aplikace např. nepadala pod Wine. Ale ono je dost těžké se zvenku k těm kompetentním lidem dostat – následně pak i přemýšlení nad tím, zda ti dokumentaci můžou poskytnout nebo ne, stojí čas, který někdo musí zaplatit nebo za který někdo dostane pojeb, že ho propálil, i když se to po něm nechtělo. Totéž nějaké úpravy v kódu - ty opět nikdo shora v té firmě nenařídil, oficiálně se na nich pracovat nemá, a bylo by potřeba je někam vmáčknout nebo dělat ve volném čase.

A pak je otázka, co má být vlastně cílem a jaký to má celé smysl. Osobně o provozování proprietárních aplikací na GNU/Linuxu ani moc nestojím. Takové věci jsou pro mne nedůvěryhodné a stejně bych je nejspíš zavřel do nějaké virtuálky. Jestli k tomu přibalím jako „běhovou knihovnu“ i nesvobodný operační systém, je už skoro jedno (licence bohužel nějaké vlastním, protože jsem je dostal jako nechtěný „dárek“ při nákupu HW, případně lze levně sehnat bazarové licence). Z mého pohledu by tedy dávala větší smysl integrace hypervizorů s desktopem (bezešvá/seamless, což už před lety některé produkty uměly).

Další věc je, že spousta aplikací se přesunula na web nebo na Electron, což jsou sice hnusy, ale pozitivní na tom je, že to zbavuje lidi závislosti na MS Windows resp. proprietárním OS obecně (vzniká tu závislost na Chromu resp. Chromiu, což je sice šílený moloch, ale aspoň pod svobodnou licencí). Co se týče proprietárních her a tam zase existuje Steam/SteamOS/SteamDeck, ve kterém toho funguje tolik, že už si nejde stěžovat ani na ty hry. Podpora hardwaru se taky obrovsky zlepšila za těch posledních dvacet+ let.

Za mne je to tedy teď věc té setrvačnosti, předinstalovaných MS Windows na noteboocích nebo podpory Microsoftu skrze úřady a školy (deformace trhu).

U svobodného softwaru to portování na jiné platformy bývá mnohem jednodušší, často je tam už v základu… a hlavně to mnohem líp škáluje, protože podporu svojí oblíbené platformy si může přidat ten, kdo ji používá, nikoli nutně původní autor programu.

P.S. Ještě je dobré se podívat, co dokáží někteří nezávislí vývojáři po večerech nebo malé týmy - balíčky třeba pro dvacet distribucí, podpora několika architektur atd. Zatímco velké firmy se vymlouvají, jak na to či ono nemají peníze a kapacity. Totéž platí i pro různé hostingy webu, zdrojáků, komunikačních nástrojů atd. - když se chce, tak je to i v silách jednotlivce si tyhle věci provozovat nezávisle. A když se nechce, tak se i velký korporát stane závislým na proprietárním softwaru, službách a cloudu.

[kralyk z abclinuxu]

Pokud by se do toho ti vývojáři sami pouštěli, tak opravdu záleží na jiných věcech, než jsou ty detaily o kterých píšeš - hlavně na jejich odvaze a ochotě dělat něco navíc. Jak dobře to bude fungovat na HiDPI displeji nebo jestli se na tmavém desktopu nezobrazí světlá aplikace, hraje asi tu nejmenší roli.

Stejná otázka jako ploštěnkovi: To trdíš na základě jaké zkušenosti? Všechno, co píšu, je založené na reálných zážitcích s vývojem cross-platform svoboné desktop aplikace používané mnoha lidmi dodávané firmou. A ta zkušenost je, že když nebude dobře fungovat např. to HiDPI, tak ti začnou uživatelé psát na bugtracker a customer support, že se ta aplikace špatně používá (protože UI není použitelné) a že by to chtěli opravit, na což mají jako zákazníci nějakým způsobem nárok. Samozřejmě nemají nárok na úplně jakoukoli kravinu, ale tyhlety podle tebe "nepodstatné" problémy s HiDPI nebo tmavým/světlým motivem způsobovaly, že UI bylo špatně použitelné, např. tmavý text na tmavém podkladu nebyl vidět apod. To samé třeba to TLS, to snadno způsobí nepoužitelnost. Když ti někdo něco takového nareportuje, napíšeš mu, že řeší kraviny a důležitá je odvaha? Odvaha ty problémy nevyřeší, ty řeší čas vývojářů a testerů, který je omezený a drahý.

No a když je těchto problémů moc na malý market share, tak je celkem pochopitelné, že management vyhodnotí, že se nevyplatí danou platformu podporovat. Právě proto by linuxový ekosystém tu bariéru pro vstup aplikací měl mít pokudmožno nízkou, ne ji naopak ještě zvyšovat.

Za mne je to tedy teď věc té setrvačnosti, předinstalovaných MS Windows na noteboocích nebo podpory Microsoftu skrze úřady a školy (deformace trhu).

Uf, už jsem se bál, že obligátní obvinění státu nepřijde (Co třeba to vnímat tak, že tržní i státní rozhodování byly deformovány velkou firmou, která získala monopol? Ne? Ok, no nic, aspoň zkusit jsem to musel...)

Ještě je dobré se podívat, co dokáží někteří nezávislí vývojáři po večerech nebo malé týmy - balíčky třeba pro dvacet distribucí, podpora několika architektur atd.

Ale jistě, ono to jde. Nám se většinou taky nějak podařilo ty problémy vyřešit (čti: workaroundovat, ochcávat). Já něřkíám, že to nejde. Říkám, že to je bolest, komplikované a nákladné, což odrazuje.

[xkucf03]

Předpokládám, že mluvíš o Slic3ru, že? V Ubuntu mám slic3r i slic3r-prusa (standardní distribuční balíčky). A zrovna tohle je nástroj, bez kterého se pro danou činnost vlastně neobejdeš a budeš ho používat, i kdyby vypadal hnusně nebo trpěl nějakými mouchami nebo sis tam musel něco dodělat sám. Pro uživatele je většinou lepší, když dostane aspoň nějakou podporu než žádnou. A to, že si na fóru stěžuje, ještě neznamená, že ten celkový přínos pro něj není kladný. Obecně si lidi spíš stěžují než chválí a děkují – zvlášť tady u nás. Takže tím se člověk nesmí nechat zdeptat. Znám např. člověka, co používá dost drahý CAD. Kdyby chodil na GNU/Linuxu, tak by to bylo super. Hlásil bych autorům chyby, když mu s tím budu pomáhat? Hlásil. Ale to neznamená, že bych za tu podporu (byť s chybami) nebyl rád!

Kdybys viděl jaký komerční/zakázkový software firmy používají, navzdory tomu, že je v něm hromada chyb… platí za to spousty peněz a stejně jsou rádi, že to mají. Osobně mám taky tendence k perfekcionalismu a spousta nedokonalostí mě rozčiluje a deptá… Ale v praxi je potřeba přijmout fakt, že většina lidí nemá software na to, aby se kochali jeho krásami, ale aby pomocí něj řešili nějakou úlohu, udělali kus práce a šli dál. Jasně, že mě ty chyby štvou a snažím se jim předcházet (mimochodem, jedna část z té snahy je Sane software manifesto, to je takový ten trochu perfekcionistický pohled, nebo série článků o komplexitě softwaru), ale někdy máš třeba jako vývojář podporovat starý software, který jsi ani nepsal, nebo jako uživatel přijdeš k zavedenému softwaru a musíš s ním nějak vyjít… Dneska používám minimálně jeden program, který má na mém 4K monitoru některé ikony a písma divně velké/malé. Vadí mi to? Vadí! Ale přesto je celkový užitek z toho softwaru kladný a jsem rád, že ho mám.

Určitě jsou i případy, kdy by špatná podpora a příliš velká chybovost zkazila reputaci a je lepší, když uživatel začne ten software používat později, než ho teď znechutit a ztratit (nebo je lepší, když ten software nebude používat vůbec a nebude o něm všude rozhlašovat, jak je na nic). Tam bych s tebou souhlasil. Ale to platí jen někdy, takže bych to zase tak nepřeceňoval a nezobecňoval.

P.S. S těmi certifikáty jsi měl jaký problém? Vím, že jak .deb, tak .rpm distribuce kolem toho mají sadu skriptů, která vezme .pem certifikáty důvěryhodných CA z určitého adresáře, zkompiluje je a zaindexuje a generuje z nich i cacerts pro Javu (symlink na /etc/ssl/certs/java/cacerts používaný všemi verzemi distribuční Javy). Tohle je věc, která funguje líp než na MS Windows. Běžné aplikace postavené nad OpenSSL, curl, wget, Javě atd. pak používají stejnou databázi CA. Jestli si někdo zkompiluje aplikaci (staticky?) tak aby hledala důvěryhodné CA jinde, tak to už je pak ale jeho problém – distribuce se naopak snaží, aby to bylo na jednom místě.

[kralyk z abclinuxu]

Pro uživatele je většinou lepší, když dostane aspoň nějakou podporu než žádnou. (...)

To asi jo, ale nejsem si jistej, jestli chápu návaznost... Ano, dalo by se to pojmout tak, že ta (relativně) vysoká cena té podpory se dá snížit tím, že člověk nebude moc dělat nároky na kvalitu. To asi jo no. Nejsem si jistej, jestli to je úplně dobře.

Běžné aplikace postavené nad OpenSSL, curl, wget, Javě atd. pak používají stejnou databázi CA. Jestli si někdo zkompiluje aplikaci (staticky?) tak aby hledala důvěryhodné CA jinde, tak to už je pak ale jeho problém

Ano, pro statické buildy to je problém, respetive je potřeba udělat to, co dělá Gočko (afaik) - projít ty obvyklé lokace a na jedné z nich snad budou...

[plostenka]

Je to o procesu. Všelijaké Deb, RPM a další balíčky se klidně dají sestavovat automatizovaně.

+1

kompatibilita libc a dalších knihoven

Vtipne od propagatora Rustu, ktery neni kompatibilni ani s knihovnama n+-1.

přizpůsobovat se světlému vs tmavému motivu prostředí

To si ma aplikace tahat z motivu prostredi - umelo to uz gnome 2.

reagovat na změny displaye/HDPI

Wtf? To je zalezitost Xorg, aplikace o pixelech nema (za normalnich okolnosti) ani vedet.

zobrazovat notifikace, přistupovat na síť (což zahrnuje takové věci jako TLS certifikáty nebo třeba lokální sítě s mDNS), přehrávat video a audio, interagovat s HW

To vsechno dela kazde linuxove livecd uz asi tak... no... 20 let?

Tohle linux ekosystém nemá vyřešeno nějakou ucelenou, obecně fungující / předvídatelnou formou, a tudíž by naprosto nemělo být překvapivé, že je na desktopu neúspěšný.

Nesouvisejici. Povidej mi o tom, jak jsou zrovna tyhle veci na majoritnim systemu predvidatelne. Vzdyt audio a video neumi Windows Media Player prehravat dodneska, sitovani je uplna tragedie, interakce s HW stoji a pada na xxx MB driverech k uplne vsemu, nektere parametry a moznosti xrandr jsou uplne bez konkurence...

[kralyk z abclinuxu]

Vtipne od propagatora Rustu, ktery neni kompatibilni ani s knihovnama n+-1.

Což je související s tématem asi tak jako ... vůbec.

To si ma aplikace tahat z motivu prostredi - umelo to uz gnome 2.

Neumělo, mohl jsi hádat z palety, která může být dost nejednoznačná, typicky na Ubuntu. Teprve až v poslední době existuje ten prefer dark příznak, iirc. A pak samozřejmě zábáva s tím, že se různě chová gtk2, gtk3, gtk4, qt5, qt6,...

Wtf? To je zalezitost Xorg, aplikace o pixelech nema (za normalnich okolnosti) ani vedet.

Aplikace o pixelech potřebuje vědět, pokud např. kreslí 3D grafiku a v ní nějaké UI, případně jiný custom rendering.

To vsechno dela kazde linuxove livecd uz asi tak... no... 20 let?

Jo, ale každé jinak. Jsi vývojář aplikace, která potřebuje udělat TLS spojení, třeba HTTPS. Odkud načteš CA certifikáty? Na Debianu a spol. /etc/ssl/certs/ca-certificates.crt, na Fedoře /etc/pki/tls/certs/ca-bundle.crt, Suse, Gentoo, BSDčka a další dost možná ještě někde jinde... Jo a chystáš používat openssl, libressl, gnutls, nebo nss? Jo a Chrome s Firefoxem používají (IIRC) svoje vlastní trust stores na linuxu, takže pak ti chodí bugreporty typu "V prohlížeči mi jde otevřít HTTPS adresa XY, proč to nejde i ve vaší aplikaci? Opravte si to." Inb4 "Ale to je chyba těch prohlížečů!" - jasně, dobře, tak se prosím běž posadit na customer support, ať to můžeš lidem říkat každý manday a počítat šťastné reakce plné pochopení a setrvalé loajality ke tvému SW...

Nesouvisejici. Povidej mi o tom, jak jsou zrovna tyhle veci na majoritnim systemu predvidatelne.

Tak dobře: Cílit na majoritní systémy je snažší, předvídatelnější. Jasně, jsou s tim taky problémy, třeba lokalizace na Windows je značně retardovaná/nepředvídatelná. Ale na spoustu věcí (třeba to TLS nebo UI zaležitosti) existují systémová API, která fungují stabilně desítky let napříč instalacemi a nemusíš řešit, jestli když něco funguje na Ubuntu+Wayland+Gnome+GTK3, jestli to bude fungovat taky na Fedora+X.Org+KDE+Qt5 (hint: nejspíš ne).

[Jendа]

Nesouvisejici. Povidej mi o tom, jak jsou zrovna tyhle veci na majoritnim systemu predvidatelne.

Co majoritní… Podívej se na masox. To má zpětnou kompatibilitu 3rd party aplikací snad horší než Linux - jak postupně změnili architekturu (z Poweru na x86), pak dropli emulátor, pak přešli na x86-64, pak dropli podporu x86-32 aplikací, pak přešli na ARM (zatím mají x86-64 emulaci), do toho každou chvíli čtu jak něco přestalo v další verzi fungovat protože se změnilo API/začal enforcovat signing/…

[kralyk z abclinuxu]

S nekompatibilitou API jsme na masoxu problémy iirc moc neměli. Signing byla nepříjemná změna, asi hlavně protože ty tooly na to nebyly/nejsou moc dokumentované...

[Ivan]

přizpůsobovat se světlému vs tmavému motivu prostředí

To si ma aplikace tahat z motivu prostredi - umelo to uz gnome 2.

Takhle jednoduche to bohuzel neni. Gtk3 rezignovalo na zpetnou kompatibilitu, a QT to nema vyreseny dodnes. Problem je treba knihovna Scintilla bez ktere neudelate poradny textovy editor - navic ma tahle knihovna ruzna jmena na ruznych distribucich a jeji detekce je extremne komplikovana(libQscintilla muze byt kompilovana pro QT5 anebo pro Qt6 v zavislosti na tom jakou distribuci mate).

https://stackoverflow.com/questions/35879025/how-to-recognize-that-an-application-is-running-in-dark-theme-on-linux

reagovat na změny displaye/HDPI

Wtf? To je zalezitost Xorg, aplikace o pixelech nema (za normalnich okolnosti) ani vedet.

Podpora pro HDPI pribyla v toolkitech relativne nedavno a spousta aplikaci ma nekde hluboko zadratovane nejake nejake pozicovani pomoci pixelu.

Tohle ale poradne nefunguje ani na Windows, treba Management tooly pro MS SQL Server od Microsoftu nefunguji na HDPI dodnes.

[Peter Golis]

Podpora pro HDPI pribyla v toolkitech relativne nedavno a spousta aplikaci ma nekde hluboko zadratovane nejake nejake pozicovani pomoci pixelu.

Tá podpora tam bola ešte pred nasadením HiDPI displejov. Ale v rámci spätnej kompatibility s MS Windows sa vytratila. Teraz sa vracia nazad v (ehm) forme škálovania displejov z predpokladaných 96 DPI. Toolkit sa má zariadiť podľa fyzickej hustoty zobrazovacieho adaptéra (monitor, tlačiareň, ...) a má kašlať na mágiu s rescalingom z 96 DPI. Teraz aby človek pozeral na písmo o hrúbke jedného obrazového bodu, namiesto jedného typografického bodu. Pri HiDPI displejoch je to ozaj príjemné.

[kralyk z abclinuxu]

Problem je treba knihovna Scintilla bez ktere neudelate poradny textovy editor - navic ma tahle knihovna ruzna jmena na ruznych distribucich a jeji detekce je extremne komplikovana(libQscintilla muze byt kompilovana pro QT5 anebo pro Qt6 v zavislosti na tom jakou distribuci mate).

+1, to je přesně ten druh problému, o kterém mluvim. Na takovéhle problémy člověk narazí po celém ekosystému.

Tohle ale poradne nefunguje ani na Windows, treba Management tooly pro MS SQL Server od Microsoftu nefunguji na HDPI dodnes.

To je nejspíš tím, že se nikdo v MS nenamáhal ty aplikace na HiDPI portovat. Fůra aplikací i od MS to tak má. Aplikace musí systému sdělit nějakým flagem, že umí HiDPI, případně dynamické DPI. Pokud to neudělá, systém celé UI aplikace na HiDPI displayi naškáluje, aby byly v pořádku proporce.

Je to takhle mj. i kvůli rastrové grafice - různé ikonky a další rastrové assety.

[~]

Tak zas v serverovne se HiDPI displej jen tak nevidi a ve virtualu jumpservra ti to muze byt jedno Nebo nejake prase tady spousti MSSQL tools primo u sebe na desktopu a cela security je v pic.. v prd.. proste neni?

[xkucf03]

Od kdy bezpečnost spočívá v tom, že se GUI aplikace spouští někde na serveru?

[xkucf04]

Odjakziva? Nebudes snad data tahat pres sit na lokal kdyz nemusis ne?

[kralyk z abclinuxu]

jj a na ten server ses připojil telepaticky...

[J]

Je videt, ze jsi odbornik pres slepice ale do pocitacu a security by jsi mluvit nemel…

[petr_p]

Za neportovatelnost Scintilly si může autor sám, protože nechce normální dynamickou knihovna nezávislou na toolkitu.

[petr_p]

Všelijaké Deb, RPM a další balíčky se klidně dají sestavovat automatizovaně. Problém je, že publikace balíčků do distribucí má nejasná pravidla, je tam spousta byrokracie, free-form komunikace, ruční práce...

Překvapivě obě věty jsou pravdivé. Můžete sestavit balíček automatizovaně. Jenže v tom smysl balení není. Smyslem balení je integrace za použití pravidel jednotných pro danou distribuci tak, aby všechny balíky měly stejné vlastnosti. Jsou umístění souborů do standardních cest, odstranění konfliktů mezi balíky, podpora pro všechny architektury, kompilace s bezpečnostními funkcemi, existence a použitelnost zdrojových kódů, správně svobodná licence, použití systémových knihoven, dodržení kompatibility, podepsání atd. byrokracie a ruční práce? Ovšemže. Někdo tu psal, že autor programu jej zná nejlépe, a proto bude nejlepší, když balíček bude dělat on. To by bylo ideální, kdyby měl v malíčku všechnu tu byrokracii a jeho kód pravidlům vyhovoval. Pak by opravdu bylo možné generovat balíky automaticky. Realita je ovšem úplně jinde.

Technicky nic nebrání autorům programů zkompilovat relokovatelný program do jednoho adresáře i se všemi závislostmi, zabalit adresář do archivu, obalit jej třeba shellovým skriptem. Uživatel si takový kompilát.sh stáhne z náhodného serveru, spustí. Odvážnější můžou ujíždět na poslední verzi stylem curl …/kompilát.sh | sh - . Proč to ale asi ti uživatelé nechtějí?

[Ivan]

Proč to ale asi ti uživatelé nechtějí?

Ale chteji. IMHO se to pouziva cim dal casteji. Bud doslova jako "curl ... | sh -" anebo jako "docker pull".

[xkucf03]

Windowsáři jsou odjakživa zvyklí stahovat EXE z různých pochybných webů (dříve FTP) a nebojácně je na svém počítači pouštět (ideálně pod administrátorských účtem). Takže dělat totéž na jiných platformách jim nedělá vůbec žádný problém. Dneska dělá admina serverů kde kdo a je docela smutné pozorovat, jak tyhle zlozvyky pronikají i na platformy, kde se to tradičně řešilo líp. MITM útok těm lidem nic neříká a bezpečnost jsou pro ně otravná vyskakující okna, která je potřeba co nejrychleji odkliknout.

[plostenka]

Jsou umístění souborů do standardních cest, odstranění konfliktů mezi balíky, podpora pro všechny architektury, kompilace s bezpečnostními funkcemi, existence a použitelnost zdrojových kódů, správně svobodná licence, použití systémových knihoven, dodržení kompatibility, podepsání atd. byrokracie

Tohle vsechno se udela jednou, kdyz se aplikace pridava do repozitare. Pro vsechny dalsi verze app--distro uz se jen spousti odladeny build script.

Nechat zavislosti na balickovacim nastroji je mnohem jednodussi nez psat vlastni instalator/detektor/updater/odinstalator. Nazorny priklad je yt-dlp, ktere se nedavno rozhodlo ze nestaci python3.x, ale je potreba aspon python3.7. Balickovac by se postaral, curl|sh updater skoncil na "python call dumpu".

[kralyk z abclinuxu]

Tohle vsechno se udela jednou, kdyz se aplikace pridava do repozitare. Pro vsechny dalsi verze app--distro uz se jen spousti odladeny build script.

Tak určitě...

Nechat zavislosti na balickovacim nastroji je mnohem jednodussi

Jednodušší pro koho? Mně přijde, že stále argumentuješ spíš z pozice uživatele, což není moc relevantní. Pro dostupnost aplikací je klíčové, jak to je/není jednoduché pro vendora...

[plostenka]

Vendori jsou profesionalove, a udelat balicek je v porovnani s celym vyvojem malickost. Uzivatel voli svym casem - co neni v repu s vyresenyma zavislostma, to "neni", curl|sh- je vyssi divci, a nastavovani dockeru nebo ln -s libfoo.so.6 libfoo.so.5 je cerna magie.

Takze klicova je snadna instalace.

[kralyk z abclinuxu]

Vendori jsou profesionalove, a udelat balicek je v porovnani s celym vyvojem malickost.

Na základě jaké zkušenosti toto píšeš?

[~]

Vzdyt mas na to pajpu v jenkinsu ne? Jo pan je amater a o CI/CD nema ani paru co?

[kralyk z abclinuxu]

Vzdyt mas na to pajpu v jenkinsu ne? Jo pan je amater a o CI/CD nema ani paru co?

O CI/CD ani o samotném aktu sestavování balíčku to není, to píšu už na začátku (#33).

Je to o tom, že ten balíček musí být sestaven správně, to znamená, že musí být v první řadě vůbec ta věc kompilovatelná pro dané distro v dané verzi, tj. s danou množinou dependencí, tak jak je diktuje ta která verze toho kterého distra. Což vyžaduje mj. také aktivní práci vývojářů, která začíná vůbec prvně rešerší, jaká jsou omezení různých distribucí a jejich verzí, následně zásahy do kódu, protože knihovny v různých verzích dister kolikrát nejsou ani source-compatible nebo obsahují různé bugy a je potřeba v různých verzích aplikovat různé workaroundy. Dále to vyžaduje práci na build systému a enumeraci dependencí (což je také často netriviální, viz Ivanovo komentář). Dále to samozřejmě také vyžaduje práci testerů a customer supportu. A všechna tato práce je kontinulání, protože distribuce se průnběžně mění, mění se dependence, staré bugy se fixují, nové bugy se objevují atd.

Problém je, že té práce je poměrně hodně (= je to drahé), disproporčně vůči ostatním OS a disproporčně vůči počtu uživatelů, které to získá.

[pimprle]

A co maji ty dependence a workaroundy spolecne s buildovanim balicku? Vzdyt se launchne virtual konkretniho distra a spusti v nem configure a make. Dependence resi proaktivne vyvojar jak kodi - kdyz mu nejaky build spadne - treba protoze starsi ci chybejici knihovna v distru.

[plostenka]

Prebalovani (patchnutych) programu jako mutt nebo finch pro dev releasy Devuanu.

[xkucf03]

vendor != programátor

Viz můj předchozí komentář. Je to zpravidla firma a firmy bývají řízené shora a manažery, kteří tyhle detaily vůbec nechápou a neřeší – rozhodují se na základě jiných věcí. Vývojář samotný sice může něco udělat či neudělat, ale naprostou většinu práce mu musí nejdřív někdo zadat a někdo schválit.

[David Heidelberg]

Zdá se že nikdo není odvařený z balíčkování obřích projektů jako LO. Odhaduji, že většina firem používá nějaké online řešení (jako třeba Collabora Office, založené na LO.... nebo Gůglí či M$ produkty)

[trekker.dk]

A narozdíl do multimilionové společnosti jako Debian je Red Hat malá firmička, která ty balíky nezvládá vyrobit.

[stabilita]

Doba RPM a DEB konci. Na desktopu do roka a do dne vsichni prejdou na immutable core a flat/snap balicky. Jina cesta neni. MacOS tak funguje 20 let a nic lepsiho se vymyslet neda.

[Luky]

Koncept dobry do roka a dna aj ubuntu core desktop bude cele v snapoch bez deb. Ja pouzivam kde sa da onlyoffice desktopeditors.

[________]

Tak ještě že na světě jsou vizionáři a myslitelé, kteří ví, že se vždy najde něco lepšího.

A také tu zatím stále bude koexistence "běžných" OS.

[David Ježek]

Nebude to už minimálně 10 let, co tuhle ideu prosazovali vývojáři BSD s PBI balíčky v PC-BSD? Ono to až taková novinka není a je to vývoj, kterému se prostě nevyhneme. Nakonec budou flatpakovat všichni, stejně jako všichni už dávno systemdmují a relativně nedlouho waylandují (čest všem výjimkám).

[raspberr]

Jako BSD vize muze mit, ale nema desktop takze o tom se v podstate nikto nema sanci neco dozvedet.

[kuba77]

Desktopové BSD tu jsou - GhostBSD, NomadBSD, HelloSystem, ravynOS... ale zmiňované PC-BSD už ne.

[raspberr]

Sekce humor je pod komixem, ne tady. Jeste jednou - BSD Desktop neexistuje. Ty demoverze na uzce specifizovane mnozine obstarozniho hardwaru nikdo nebere vazne.

Ty demoverze na uzce specifizovane mnozine obstarozniho hardwaru

Máš na mysli Mac?

[hefo]

To, že macOS vychádza z BSD, ešte nedáva fanúšikom BSD právo prsiť sa, že existuje nejaký všeobecný (a open/free už vôbec nie) BSD desktop...

[Arch3olog]

To je nedorozumeni. macOS ma kernel Mach. Z BSD pouziva(l) jen network stack a par utilit.

[David Heidelberg]

I ty proroku. Sice immutable core je zajímavá myšlenka, ale z praxe nevidím, že by firmy ztráceli zájem o DEB/RPM based řešení...

Lomikare, do roka a do dne bude rok linuxového desktopu...

[koroptev]

firmy?

ty nic takoveho nezajima a delaji to pro web..

[David Heidelberg]

Debian je maintanovaný převážně dobrovolníky (taky mám svůj balíček ), ale prostě pokud se máš jako korporace rozhodnout do čeho budeš sypat peníze, tak řekneš ‒ není v tom business, kašlem na to.

[trekker.dk]

Chápu, ale bral bych to jako záležitost prestiže - když to zvládnou dobrovolníci v Debianu, Red Hat by mohl taky.

[Ruža Becelin]

Ona to neni sranda a faktem je, ze nejvic softwaru rozumi ten, kdo jej vytvari, takze zlata stredni cesta by byla vzit RPM/DEB od LOorg a zkontrolovat, jestli jsou OK.

Immutable baliky by byla dobra cesta, pokud by se nejrozsirenejsi distribuce dohodly na JEDNOM formatu, ktery by se zacal prosazovat do hlavni, a ne, ze si hraji na vlastnim pisecku. V tomhle ma bohuzel maslo na hlave hlavne Canonical s temi jejich snapy.

Co jsem se tak dival, tak na desktopu pouzivam par AppImage veci (rssguard treba), ale flatpak a snap leti pryc hned po instalaci.

[kralyk z abclinuxu]

Immutable baliky by byla dobra cesta, pokud by se nejrozsirenejsi distribuce dohodly na JEDNOM formatu, ktery by se zacal prosazovat do hlavni, a ne, ze si hraji na vlastnim pisecku. V tomhle ma bohuzel maslo na hlave hlavne Canonical s temi jejich snapy.

IMO víceméně za to může celý linuxový ekosystém taknějak kolektivně...

No, v tomhle konkrétně nese největší vinu skutečně Canonical se svým NIH syndromem. Mir vs Wayland byl svého času stejný případ.

[________]

Náhodou jsem o této historii nedávno četl. Ne že bych si pamatoval takové blbosti, ale jedno mi v hlavě zůstalo. Bylo to trošku jinak, než si většina lidí myslí. A bylo to tam dobře vysvětleno proč tak a proč ne onak. Potom to začalo dávat smysl.

Ale to tak bývá, když člověk nevidí za oponu a třeba soudí knihu jen dle obalu.

[J]

Jako producent desktopoveho softveru bych se na linux vyprdnul, udrzovat 200 ruznych formatu distribuce softveru ne neudrzitelne. Linuxova komunita se neumi domluvit.

[AsciiWolf]

Dnes je to prakticky jen Flatpak vs Snap, dříve RPM vs DEB. Případně se můžete inspirovat společností Valve, která distribuuje Steam jako *.deb balík pro Ubuntu + poskytuje generický *.tar.gz pro ostatní a dovoluje jeho repackaging/redistribuci.

[ondra05]

Nebo můžete být jako úžasný Petr Mrázek z MultiMC který si nějak změní licencování, myslím že loga, aby mu to nikdo jiný nebalil.

[Jendа]

Dnes je to prakticky jen Flatpak vs Snap

Já teda těch pár věcí co používám mimo distribuci (Gqrx, Electrum -- protože to je v Debianu permanentně rozbité, Drawio) mám jako appimage. Flatpak ani Snap jsem nikdy neměl.

No a pak tu jsou gigantické komerční bazmeky (CST Studio, Vivado, Quartus) co se distribuují jako „instalátor“ co to plácne někam do /opt nebo home, a kupodivu v dnešní době unifikovaného systemd má i funkční init skripty (unity) napříč distribucema.

[m]

komercni jsou v pohode, to nekdo totizi testuje, ne jak open bordel

[Jendа]

Já to používám na „nepodporovaném OS“ (Debian; poslední dobou podporují alespoň příbuzné Ubuntu, ale kdysi byl oficiálně podporovaný jen RHEL a SLES).

[AsciiWolf]

co se distribuují jako „instalátor“ co to plácne někam do /opt nebo home

Uf, tyhle prasárny se dnes ještě používají?

[Jendа]

Mně to nepřijde jako nějaká extra prasárna… Je to jeden adresář v /opt + jedna unita + občas něco ve /var. Jako jo, můžeš si ty soubory posbírat a udělat si z toho pseudobalíček, ale nevím moc k čemu by to bylo pro takovouhle jednorázovku.

[AsciiWolf]

Já myslel spíše ten způsob instalace z binárního blobu. Takový loki_setup (MojoSetup) měl alespoň jako jeden z mála standardizované přepínače pro extrahování souborů a další akce. Ale stejně jsem byl rád, že tento Windows-like způsob instalace softwaru na GNU/Linuxu časem víceméně zanikl.

[antinazi]

Co se do toho sere nacek. Co na to amerikanci. Redhat je prece americka firma, nebo ne?

[J]

A jak se to vylucuje? V US je diky svobode slova mozne hajlovat, sice budete za debila ale tu moznost mate. V takovem demokratickem Nemecku je to basa natvrdo. V Nemecku ani wolfenstein nemohli mit legalne s vlajeckami.

Každý stát je citlivý na něco jiného ze své historie. V USA zase blbnou s černochy a otroctvím, a politickou korektností ad absurdum.

[J]

Rozdil tady je. Po nedelni msi muzes v klidu jit di sve lokalni party KKK a budou te ledat tak sledovat federalove. Zkus nekdy jit v Nemecku do sve lokalni party Hitler Jugend.

[skunkOS]

Zlatej Arch.

[zlatej gentoo]

Jo zlatej, updatne ti knihovnu ani nevis kdy a pulka veci jde do kytek Arch tak na desktopove hrani ale na server ani nahodou.

[kralyk z abclinuxu]

Co to je zas server, že na něm použíšá LibreOffice?

(A jinak ano, Arch je desktopové distro.)

[mandzare]

A kdo se tady bavi o LibreOpici? To byl jen clickbait redakce protoze vi ze se tu strhne mela. Debata je, ze balickovaci systemy jsou pase a kdyz chce linux prezit tak musi jit cestou immutable core + snap/flat/appimg.

Archiste jsou v tehle debate nekde na uplne opacne strane barikady protoze proti stabilite bojuji idelologii, telem i dusi Navic kdyz na tohle obdrzim odpoved tak nez ji napises tak ji jiste 3x prepises a aktualizujes, ze jo?

[kralyk z abclinuxu]

Debata je, ze balickovaci systemy jsou pase a kdyz chce linux prezit tak musi jit cestou immutable core + snap/flat/appimg.

Myslíš to, co napsal nějakej anonym tady? Tak možná by bylo lepší reagovat tam, pokud nesouhlasíš...

[Want]

Neanonym je nějaká kasta mudrců nebo co?

[kralyk z abclinuxu]

Ano.

[xkucf03]

Co to je zas server, že na něm použíšá LibreOffice?

LibreOffice/OpenOffice můžeš pouštět v --headless režimu bez GUI, pak je to služba běžící na pozadí a naslouchající na TCP portu. Na serverech se to používá pro různé konverze dokumentů, generování PDF, tisk atd. Klienti to volají přes UNO - síťové/distribuované objekty… docela zajímavá technologie.

[koroptev]

no a co? na serverovym OS zadnej office balik neni potreba..

[Max]

S tvým přístup můžeš rovnou říci, že na serveru není potřeba ani GUI.
Pokud budeme řešit terminálový přístup, tak potřeba je. Pokud budeme řešit korporátní služby jako Alfresco DMS apod., tak Libreoffice chceš (jako službu na pozadí), případně lepší alternativu (OnlyOffice) atd. atd. atd.
Zdar Max

[Max]

Knock, knock...
Kdo tam?
IBM.
Zdar Max