A Red Hat nem szállítja a LibreOffice-t a jövőbeli RHEL kiadásaiban

LibreOffice, OpenOffice.org

Több forrás - LWN, Phoronix - is arról számol be, hogy a Red Hat nem szállítja a LibreOffice-t a jövőbeli RHEL kiadásaiban, sőt a LibreOffice támogatás jövője a Fedora-ban is kétséges:

A Red Hat-os Matthias Clasen írta:

The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.

The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.

Részletek itt és itt.

( Raynes | 2023. 06. 03., szo – 19:54 )

Ja, ezt pont most írtam az egyik Snap-Ubuntu-CUPS témába. Kiderült közben az oka is, az LO-n dolgozó két fejlesztőt, aki csomagolt is, menesztették, budget cut. Jó lesz mindenkinek a Flatpak gyerekek, alapon. Meg olyan kifogással is jött valaki a Red Hat oldalán, hogy de izé, az RHEL egy szerverdisztró, nem deszktop, nem kell arra Office, meg különben is ott vannak a webes online Office-ok, meg a Flatpakk. Ész megáll, hogy még magyarázzák is a szegénységi bizonyítványt. Ráadásul nem csak az RHEL-esekkel csesznek ki, hanem mindenkivel downstreamben, ami rájuk alapoz, Fedora, CentOS, Alma, Rocky, Euro, stb.. Meg ez a szöveg is nevetséges, hogy trade off, mert kellenek a fejlesztők, hogy Waylanden, HDR-en dolgozzanak, persze, mert a HDR az fontosabb, mint egy irodai törzsalkalmazás. Vallják be, hogy spúrok, és nem érdeklik őket a felhasználók, nem lenne ennyire kínos, mint magyarázkodni. A másik mostani tangójuk meg ez a jövő kiadásokban már nem akarják a X.org-ot szállítani, nyírjuk ki, aha. Ez ráadásul rosszabb lesz, mikor immutable alapra váltanak a jövőben.

Kolléga a másik topikban meg kérdezi, hogy érdemes-e inkább a Debian-nal ismerkedni. Abszolúte. Nem viccből használok én se Archot, nem csak a btw. hatás, meg a friss verziók miatt, hanem közösségi, és nincsenek benne ezek a corporate hülyeségek.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Azért ez a duma, hogy a RHEL szerverdisztró, az nekem ellentmondásban van a Wayland és HDR iránnyal. Egyrészt a szerver adminisztrációjához nem szükséges grafikus környezet - mert ott a CLI és a szkriptgyűjtemény, másrészt ma már minden szart webböngészőből akarnak adminisztrálni, tehát  megint csak nem szükséges a szervernek grafikus környezet.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Azért ez a duma, hogy a RHEL szerverdisztró, az nekem ellentmondásban van a Wayland és HDR iránnyal.

Ha ki kell herélni valamit, ami eddig jól működött (LibreOffice) és meg kell valamivel indokolni, akkor szerverdisztró™.

Ha ki kell herélni valamit, ami eddig jól működött (X.Org) és meg kell valamivel indokolni, akkor a biztonságot™ és a HDR™-t előtérbe helyező desktop-disztró™.

A GNOME, a GTK3-4, a pulseaudio (most már pipewire, mert még egyszer fel kellett találni), a Wayland és a Red Hat vállalati arroganciája és felforgató tevékenysége együtt akadályozzák a Linux desktop elterjedését. Egy szóval, a Red Hat a Linux desktop felhasználásának a legnagyobb akadálya.

Az X.org pedig nem szar, hanem egy stabil, működőképes valami, ami 20 éve működik. A Wayland még éppenhogy csak kezd működni. Az erőltetésével pedig kibabrálunk megannyi power userrel, akik pont azt szerették a Linuxban, amit nem szerettek más desktopokon, de a Wayland torkokon lenyomása majd elhozza.

A wayland nincs lenyomva senki torkán. Fedorát használok Xorg-gal. A Fedoráról meg higgyük el, hogy igen közel áll a Red Hat-hez. A pulseaudio rossz volt, így szükség volt a pipewire-re. Ráadásul ez utóbbi többet tud, hiszen szállítja a video stream-et is. Mindezt kevesebb erőforrás felhasználásával, jobb minőségben.

GTK4-ről nem tudok nyilatkozni, egyszer írtam alkalmazást vele és nagyon szenvedtem, de ez az én hibám, mert szokatlan az, ahogyan szervezik az egészet. Ráadásul C-ben közelítettem hozzá, miközben a GTK4 ojjektum-orientált, ez sem tette barátságossá, de ez az én hibám.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A wayland nincs lenyomva senki torkán.

Még nincs. Idő kérdése és indul az X.Org-ellenes FUD propaganda és a Wayland egyeduralkodóvá erőltetése.

Fedorát használok Xorg-gal.

Egészségedre.

A pulseaudio rossz volt, így szükség volt a pipewire-re.

A pulseaudio-ról is ezt mondták, hogy szükség™ van™ rá™. Aztán olyannyira szükség™ volt™, hogy lenyomták a torkokon. Azokén is, akik számára semmi hozzáadott értéke nem volt, mert jól elvoltak az ALSÁ-val.

Jó, de a pulseaudioval sem lett volna semmi baj, ha nincs elrontva az implementáció. Mivel el lett, ezért lett a pipewire. ALSA interface-e mindkettőnek van, tehát nyilván azzal van bajod, amikor az alkalmazásnak csak pulse interface-e van a szerver felé. Jó, de van hozzá eszköz, a pipewire.

Amúgy wayland alá is kell a Xorg, ha hálózaton szeretnéd - pl. ssh -X - használni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó, de a pulseaudioval sem lett volna semmi baj, ha nincs elrontva az implementáció.

Az ALSÁ-val sincs semmi baj és nem is volt elrontva az implementáció, csak bonyolult volt input-output configfájlokat írni hozzá és a doksi is szűkszavú volt. Egy hozzáírt pavucontrol-szerű konfigurátor megtette volna, külön audioszerver helyett.

tehát nyilván azzal van bajod, amikor az alkalmazásnak csak pulse interface-e van a szerver felé

Azzal van, amikor a létező ALSA interface-t a pulseaudio kedvéért eltávolítják (Firefox), így a felhasználónak nem marad választása, mint a Red Hat instabil, szarul-húgyul implementált audioszerverét használni.

Jó, de van hozzá eszköz, a pipewire.

Félresikerült újrafeltaláltkerék esetéből véletlenül sem az a tanulság, hogy nem kell újrafeltalálni a kereket. Hanem az, hogy fel kell találni harmadszorra is. Igen, tudom, hogy te ilyen pipewire-influenszer vagy itt, és hogy "nem jó" embernek mondom. Változatlanul ez a véleményem.

Amúgy wayland alá is kell a Xorg, ha hálózaton szeretnéd - pl. ssh -X - használni.

Ugyan™ ki™ használja™ úgy™.

Az ALSA és a pipewire nem ugyanaz a réteg, így elég nehéz értelmezni azt, hogy az ALSA-val nincs semmi baj. Amúgy még szerencse, mert ha lenne, a pipewire-nek sem lenne hangja. Nekem kicsit olyan, mintha üsszekevernéd az IP-t a TCP-vel, s azt mondanád, felesleges a TCP, mert milyen jó az IP. Persze, csak a TCP IP fölött van, más a feladata. A pipewire tud egy rakás dolgot, amit szerintem az ALSA nem. Például nem tudom, lehet-e ALSA-val dinamikusan, audio lejátszás közben stream-et lokális hangszórókról bluetooth kliensre tenni, miközben egy másik kliens hálózaton játszik le hangot más mintavételi frekvenciával. A pipewire ezt tudja. Vagy teszem azt, a jobb és bal oldalt valós időben megcserélni, mert megfordulsz a forgószékeddel a szobában.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Úgy értettem, hogy nincs vele baj, hogy amire való, azt tudja. Az IP-re sem lehet mondani, hogy vacak, csak ne várjuk tőle azt, mint a TCP-től, mert nem arra való, sőt, az IP kell, mert szállítja a TCP-t. Mint ahogyan az ALSA kell a pipewire, pulseaudio alá, mert meg kell oldani a driver szintű illesztést a hardware-hez.

Nem ellentmondtam, mert egyetértünk. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

X.Org-ot (eredetileg X11-et) 1984-ben kezdték fejleszteni. Wayland-ot 2008-ban.

Úgy értetted a kérdést ugye, hogy megnéztem-e, hogy egyik projekt 15 év fejlesztés után és/vagy fősodorba kerülés előtt bloat-abb-e a másiknál? Tehát az 1999-es X11 bloatabb-e, mint a 2023-as Wayland?

EDIT: de ha neked jobban tetszik, valaszolhatsz az 1999-es XFree86 release alapjan is.

A kérdés csak így releváns, különben almát a körtéhez hasonlítasz.

A Wayland bloat-abb (több erőforrást igényel és zabál el), mint az 1999-es X11. És ha most valamiben kevésbé bloat, mint a 2023-as X.Org, egy évtizeden belül bloat-abb lesz.

Az X.Org architekturaja alapvetoen hibas. Amikor azt terveztek gyakorlatilag nem leteztek GPU-k es a GPU render (compositor) ugy van bele hackelve. Ma gyakorlatilag nincs CPU render (mert baromi lassu nyilvan), ezert ez az egesz ugy kuka ahogy van. A kodrol ne is beszeljunk, egy szarra ifdef-elt fos, tele mindenfele unsecure fuggvenyekkel. A wayland celja, hogy ezt a felesleges koztes reteget kiszedje es az alkalmazasok kozvetlenul a compositorral kommunikaljanak.

Meg iszonyatosan komplex is. Tobbszaz olyan hivas van benne, amit maximum az x11perf hasznal (pl olyan rajzolasi primitivek, mint: ferde, csonka ellipszis-cikk kitoltve tile-olt bitmaszkolt mintaval vagy antialias-olt paralelogramma lekerekitett sarkokkal es szaggatott korvonallal stb stb). Mikozben kb minden alkalmazas sajat lib-bel csinalja meg a renderelest es maximum egy PutImageXY-t hasznal az X11-bol. Sajat fontszerver amit csak az Xterm-szintu alkalmazasok hasznalnak (csak bitmap font tamogatassal), mindenki mas libfreetype-al renderel az X-szerveren kivul. Sajat resource elnevezesi es lookup rendszer (sok *-os es kotojeles jeloles, ma mar kb teljesen idegen minden rendszertol). Sajat wire protokol es szerializalo/deszerializalo logika, garantalt security sebezhetosegekkel. Regen raadasul az osszes grafikus driver is benn lakott az X szerver hasaban, emiatt nem eleg, hogy root kellett, de tobb (amugy nagyon problemas) kernel ABI hivas is kifejezetten az X szerver kedveert lett bevezetve. Kozvetlen hozzaferes _fizikai_ memoriacimekhez userspace-bol, fizikailag osszefuggo blokkok allokalasa, lapozas kikerulese, IO-port iras-olvasas, interrupt callback userspace-bol. A KMS egy megvaltas volt, de az X architekturaja nyilvan nem lett atalakitva, csak kikapcsoltak a szuksegtelenne valt reszeket belole. Ezert gondoltam, hogy eleg nagy ongol az 1999-es XFree86-ot elovenni, dehat ha Hajbi ragaszkodik hozza... :)

De ha csak azt nezed mekkora a csomag merete (hajbinal ez az utlimate bloat(tm) metrika), akkor is a Wayland messze nyer az X-el szemben.

Régóta vágyok én, az androidok mezonkincsére már!

Az, hogy az alkalmazások mind pixmapokat küldözgetnek az X-nek, mintsem kihasználnák rendesen a rajzolási primitíveket, nem az X ellen szóló érv, hanem a kényelmeskedő babzsákfejlesztők ellen szóló érv, akik saját libbel rajzolnak, mert hát mindenkinek kell egy saját lib, nehogy véletlenül meg kelljen ismerni az X-et.

Mi van egy weboldalon? Betűk, képek, videók. Ezenkívül vannak vektorgrafikus ábrák (SVG, egyéb canvas-re rajzolások), keretek, határolóvonalak, amiket nagyon szépen le lehet renderelni az X rajzolási primitívjeivel. Chromium korábban így is csinálta, amíg a SKIA-idealizmust ki nem fejlesztették™ a Google-milliárdokból, a "legyen nekünk is sajátunk" égisze alatt.

Egyáltalán tud úgy renderelni az X, hogy az a határvonal, ami részben megy át a pixelen, területarányosan teszi adott intenzitásúvá az adott pixelt? Nem tudom a nevét, most nem jut eszembe, de enélkül borzalmasak a fontok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

X11 core-nak nincsenek. Annak még a vektorgrafikus fontok is problémát okoznak, tudtommal csak az alap bitmap fontokat kezeli.

Az Xft már erre egy hack, ami a vektoros fontot átalakítja elemi X rajzolási primitívekké. Ebben speciális agyrém, hogy az alkalmazást futtató kliens és szerver külön gép lehet, és nem feltétlen ugyanazok a fontok vannak telepítve. Ezért kell az Xft-nél a kliens oldalon lebontani rajzolási műveletekké, hogy a szerveren ne kelljen meglennie a fontnak. _Talán_ az Xft tud valamiféle antialiasing-ot, de az biztos, hogy korrket subpixel renderelés nem lesz.

A "rendes" antialiasolt és RGB subpixelt kihasználó font renderelést már kliens oldali libek (tipikusan freetype, fontconfig és társai) csinálják. Ez természetesen pixmap-be renderel és azt küldi át az X szervernek, semmilyen szinten nem dependál az X font kezelésére.

Régóta vágyok én, az androidok mezonkincsére már!

Kiváló! Ha már így szóba hoztad a vektorgrafikus ábrákat... miből is állnak tipikusan? B-spline-okkal határolt területek, kitöltve egy színnel vagy színátmenettel, esetleg áttetszően. (Lehet vitatkozni rajta, hogy most B-spline vagy Bézier-görbe, nem ugyanaz a kettő, de a renderelési algoritmusa elég hasonló.) Mesélj róla, hogy lehet X11 (pontosabban xcb) drawing primitve-ekkel ezt megoldani? Segítek, itt egy doksi hozzá. Ha azt akarod, hogy a renderelt shape ne windows 3.1-stílusban nézzen ki (törtvonalas közelítés elég finom legyen, a gradient ne 8db diszkrét színsávból álljon stb), akkor becsüld meg kb, hogy hány darab hívást kell a kliensnek az X szerver fele elküldenie.

Átlátszóság? Kíváncsi vagyok hogy oldod meg, tekintve, hogy a drawing primitive-eknél csak bináris bitmaszk van. Persze vannak hack-ek, 32bites display esetére - amire nem mindig számíthatsz, ezért kell fallback megoldásodnak is lennie - és ráadásul ez a megoldás is pixmap-ek piszkálására épít.

És akkor nézzük miből is áll egy hívás:

Kliens alkalmazás:

1. összerakja a paramétereket egy struct-ba

2. szerializálja wire protokolra (xlib vagy xcb közül valamelyik library csinálja meg neked)

3. elküldi IPC-n (socketen vagy shared memory-n)

X Server:

4. fogadja az IPC-n

5. deszerializálja

6. végrehajtja a rajzolást

7. összerakja a választ

8. szerializálja a választ

9. elküldi IPC-n

Kliens alkalmazás:

10. fogadja IPC-n

11. deszerializálja

12. készen van, kliens megkapta a visszatérési értéket

Ebben van alsó hangon 4db kontextusváltás. Shared memory-val valamelyest kevesebb az overhead, nem kell socketen másolgatni, de szinkronizálás miatt kontextusváltás akkor is van.

Mi ez, ha nem bloat?

Egy shape kirajzolásához ezt kb 100-as nagyságrendben fogod pörgetni. Ehhez képest, ha a kliens saját libbel, saját pixmapbe maga rendereli az egészet, akkor csak a "végrehajtja a rajzolást" c. művelet ismétlődik sokszor, kontextusváltások, IPC, szerializálás/deszerializálások nélkül. Aztán a végén 1db PutImage-el átpattintja az X szervernek az egészet. Nagyságrendekkel gyorsabb.

A Wayland pedig meg tudja oldani, hogy mindenféle kerülőutas hack nélkül a kliens alkalmazás pixmap-je már kapásból a GPU memóriájában jöjjön létre, és a kliens library tudjon GPU gyorsítva rajzoltatni bele.

Régóta vágyok én, az androidok mezonkincsére már!

Akár még ki is próbálnám a wayland protokollt, de amikor ezer éve megjelent Fedorában, esett-kelt szegény, így túl nagy vonzalmat nem érzek iránta, bár gondolom, ma már sokkal jobb.

A másik: minden hardware-nek és minden grafikus libnek, környezetnek, alkalmazásnak van wayland támogatása? Szóval ez annyi, hogy elindítok mondjuk valami daemont, és lőn wayland használat, vagy hirtelen meg van kötve a kezem, hogy akkor leszek kedves Gnome-ot és gnome-os alkalmazásokat használni, szokjak le az Xfce-ről, de mi van a 3rd party alkalmazásokkal - pl. Microchip MPLAB X IDE -, továbbá mi a helyzet, ha távolról futtatom a Claws Mail-t, és szeretném látni az ablakát ssh tunnelingen - ssh -X ?

Wayland fölött megy a compiz és az emerald?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ránézésre az MPLAB X IDE egy java-s cucc, ami egyelőre XWayland-dal vagy valami hasonlóval megy, de találtam cikket hogy már masszívan dolgoznak rajta hogy pure Wayland-dal is működjön:

https://www.phoronix.com/news/Java-Native-Wayland-Progress

https://cr.openjdk.org/~prr/javaone/2022/wakefield/wakefield_bof.pdf

Ez viszont számomra azt jelenti, hogy a waylanddal nem lehet lecserélni az X11-et, a wayland csak korlátozottan használható. Tehát maradok a Xorg-nál.

Igen, az MPLAB jav-s (netbeans) förtelem. Hol megy, hol nem, hol exception-nel indul, hol jól, hol működik a syntax highlight, hol csak azután, hogy legalább egy karakternyit módosítok a forráskódban. Néha belefagy a saját forráskód analízisébe, bezárás után nem lép ki, kill paranccsal kell kinyírni a java process-t. Ezektől eltekintve egész jól használható. :D

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Pont az a lényeg hogy nem kell csak X11-et használni, hanem használj wayland-et amivel a legtöbb standard gnome-os (vagy KDE-s) alkalmazásod gyorsítva lesz és használd az Wayland-X11 wrappert a maradéknak.

Ahogy nézem a java-s cuccok is előbb-utóbb menni fognak wayland-en, és van rá akarat is, de ez nem 2 hét múlva lesz.

Meg ha óriási a kommunikációs overhead a szerver és a kliens között, akkor elvész az X képességének minden előnye, mégha van is.

Megfigyeltem, hogy ssh -CX esetén is használhatatlan egy böngésző, ha 1 MB/s körüli a sávszélesség kliens és szerver között. Tehát nyilván kínosan nagy az overhead.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Munkahelyemről otthoni gépemet bekapcsolva, otthoni gépem Claws Mail kliensét elindítva simán meg tudom nézni a leveleimet. A Claws Mail egy GTK-s alkalmazás, elfogadható válaszidőt produkál ssh -CX kapcsolókkal. A Firefox viszont valóban használhatatlan így.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én sem tapsolok a Red Hat döntésének, de fel lehet ezt másképp is fogni, például megköszönni, hogy 12 éven át fenntartottak egy LibreOffice fejlesztőcsapatot úgy, hogy ebből lényegében semmi anyagi hasznuk nem származott. Öt fővel indultak, Calán McNamara, David Tardon, Eike Rathke, Michael Stahl és Stephan Bergmann.  Mindannyian nagyon magas szinten vannak, ütőképes csapat volt. Javítottak belsős rhbz# hibákat, flatpackoztak, de azért legyünk őszinték, főleg upstream fejlesztést végeztek. Jófejség volt ez a RedHattól, hogy ezt szponzorálta, ilyen sokáig. A SUSE, ha emlékszünk, már 2013-ban meglépte azt, hogy profiltisztítás keretében leépítette a LibreOffice csapatát, 6 ember maradt és más feladatot kapott, 6 ment a Collaborához, és folytatta a LibreOffice-ozást. A hazánkban közönségkedvenc Ubuntu kiadója, a Canonical, a csúcson 1 db LibreOffice fejlesztőt foglalkoztatott, ma már 0-t. Természetesen ezért is köszönet jár. Az ingyenes LibreOffice-on ezek a Linux disztributorok nem tudtak pénzt keresni. Voltak/vannak support szerződések, de a mérleg másik serpenyőjében a fejlesztők horror fix költsége van. A Red Hat pár évvel ezelőtt lefelezte a csoportot. Michael Stahl átment a CIB-hez (nem a bank), később a CIB-ből kivált a LibreOffice csoport, és lett az allotropia. David Tardon más feladatot kapott, Eike Rathke félidőben LO-zott. Most meg azt történt, hogy még jobban leépítették a csoportot, talán teljesen. Caolán átment a Collaborához, így a LibreOffice projekt számára nem veszett el egy kulcsember. Azt nem tudom, hogy mi van Eikével és Stephannal, de tippem szerint nekik már közel a nyugdíj, életkorukat figyelembe véve. Lehet, hogy még elkaristolnak a Red Hatnál egy kis ideig más feladatokon, aztán annyi. 

Köszönöm az összefoglalót, kintről az ember kevésbé lát bele.

A fentiekkel azt is mondod, hogy a Redhatnek nem származott semmi előnye a fejlesztésekből?

Sok mindenben benne van és fejleszt a redhat, pl. a virtuálizáció terén, közvetlenül a kernelbe és más fontos toolokba is.
Bár valóban jófejség, de ezekhez érdeke is fűződik...

Nekem csak azt magyarazza el valaki, hogy a Microsofton kivul hogy a p*csaba nem sikerul senkinek se penzt csinalnia az office-bol?

Most gondoltam veszek 20db office-t a cegnek, 4.15MFt(!)-ert vesztegeti a microsoft hivatalos web store-ja. (20db-nal valamifele engedmenyt elvarnek, de nem ad).

Mindenki balfasz, csak a microsoft csinalja jol?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

És minek vennél ilyet? Microsoft 365 megfelelő (nem legalacsonyabb) kategóriájú előfizetéshez jár az Office desktop alkalmazás (meg sok minden más is), 20 embernek éves előfizetéssel ez 2800 euró, havi előfizetéssel pedig 280 euró havonta. 4.15M forintból kb. 4 évnyi előfizetést tudsz venni.

És jár hozzá az Office desktop appokon kívül sok minden más is: https://www.microsoft.com/hu-hu/microsoft-365/business/microsoft-365-bu…

https://support.microsoft.com/en-us/office/end-of-support-for-office-20…

Már lejárt a támogatása.

És amúgy az Office-ban vannak azért komoly biztonsági hibák, például: 

https://www.cvedetails.com/cve/CVE-2022-21841/

https://www.cvedetails.com/cve/CVE-2021-1716/

Úgy évente találnak 1-1 súlyos Remote Code Execution hibát az Office termékekben.

Mindenki balfasz, csak a microsoft csinalja jol?

Szerintem annyi a megoldas, hogy ahol van 200k egy Office licencre, ott olyan igenyek* is vannak melle, amit nem sokan tudnak kiszolgalni.

* nem feltetlenul szigoruan valamelyik Office app feature-je szintjen, hanem mondjuk legyen hozza ilyen

Nyílt forrásnál nem működik ez a recept. Ha bárki lemásolhatja, csomagolhatja, terjesztheti, akkor valami nagyon ütős hozzáadott érték kell, hogy valaki fizessen érte. És még ekkor is, miért éri meg fejleszteni? Fejlesszen más, én meg megpróbálom lenyúlni és eladni, ez a szokásos stratégia.

Nalunk egy dolgot nem tudott az ms office, ami miatt ra vagyunk kenyszeritve, ez pedig a korrektura. Kuldenek egy kormanyzati anyagot, belejavitva, visszakuldjuk szinten belejavitva, es ezt a libreoffice nagyon nem tudta (a korrektura szinet nem vette at, nem latszodott, hogy ki javitott bele,stb,stb).

 

Namost maga az office egy eleg nagy informatikai tetel. Nem hiszem el, hogy valami fel-felhos dologba ezeket a konkret usecase problemakat kijavitva nem lehet erte penzt kerni.

Egy-egy konkret cegnel bevezetni, ugy hogy az o szamara fontos feature-oket beletenni.

 

En se tudom a megoldast, de egy 0-4.15MFt kozott eleg nagy a mozgaster. Sot a havi 8-12EUR/fo/ho -bol is van mit a tejbe apritani:)

De mind a google, mind a microsoft ezeket az office megoldasait emailhez koti. Es vastagon szedik meg magukat.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Egy-egy konkret cegnel bevezetni, ugy hogy az o szamara fontos feature-oket beletenni.

 

En se tudom a megoldast, de egy 0-4.15MFt kozott eleg nagy a mozgaster. Sot a havi 8-12EUR/fo/ho -bol is van mit a tejbe apritani:)

Látod, itt fizeted ki azt, hogy a cégek számára fontos feature-öket fejlessze a Microsoft. Nincs ingyen ebéd, valakinek ki kell fizetnie a dolgot. A Microsoft szétteríti a fejlesztés költségét az összes felhasználójára. 4 M forint az egy fejlesztő 2 havi bruttó bére Magyarországon (Amerikában meg mondjuk inkább 1 havi se), szerinted 1 fejlesztő két hónap alatt tud annyi egyedi fejlesztést csinálni neked, ami miatt megéri 4 évig használnod a szoftvert? Szoftvert fejleszteni NAGYON drága dolog., 4 M forintért lófasz mennyiségű egyedi fejlesztést kapsz.

ebből lényegében semmi anyagi hasznuk nem származott

Tehát a fizetős RHEL vállalati ügyfelek egyáltalán nem használtak LibreOffice-t a súlyos pénzekért megvásárolt enterprise rendszereken, ezt pedig multiék valamilyen telemetriával vagy RPM-letöltési statisztikával alá is tudják támasztani?

Nem érted. Nem azért vettek RHEL-t, mert csak ott tudtak volna LibreOffice-t használni azok, akiknek LibreOffice használat kell a munka során.

Nem volt olyan ember, akinek az volt a döntése, hogy húha, LibreOffice-t kell használnom, ezért RHEL licencet fogok venni, mert az jó! Vagy szerinted aki LibreOffice-t akar használni, az döntsön úgy, hogy vegyen RHEL-t?

Nem érted. Nem azért vettek RHEL-t, mert csak ott tudtak volna LibreOffice-t használni azok, akiknek LibreOffice használat kell a munka során.

De értem. Timar kollégáddal együtt felszopkodtátok multiékat, úgy beállítva őket, hogy ők ingyen™ és bérmentve™ (profitorientált nyelven: veszteséget™ termelve) jóindulatból támogatták™ a™ közösséget™ a LibreOffice karbantartásával. Egy nagy lófaszt. A LibreOffice a piacon gyakorlatilag egyeduralkodó full-featured MSOffice-alternatívaként az egyik húzóága volt az RHEL irodai alkalmazásra való eladásainak, egészen addig, amíg a cloud-os office megoldások (pl. O365) át nem vették a helyét úgy általában az összes lokálisan futó office-nak. Most már az irodai programcsomag amolyan "jó ha van, de nem baj az se, ha nincs, böngészőben megoldom" tendenciát követ. Ergo, a Red Hat már nem tud annyi profitot realizálni a LibreOffice benttartásán, amennyit szeretne (ez még mindig nem jelenti azt, hogy veszteséges lenne). Ennyit arról a bizonyos jó™ indulatról™. A Red Hat Linux-tájékon az Oracle után a legönzőbb, legprofitéhesebb, legarrogánsabb multi. Majd pont ők fogják a közösséget jóindulatból támogatni - azt a közösséget, amit évente felforgatnak és szembeköpnek a Linux elvindózosításával. Hát persze.

Nem volt olyan ember, akinek az volt a döntése, hogy húha, LibreOffice-t kell használnom, ezért RHEL licencet fogok venni, mert az jó!

Olyan se volt, akinek az volt a döntése, hogy irodában szeretné használni az RHEL-t, ezért azt választotta a Microsoft Windows + Office kombó helyett, igaz? Ja dehogynem, csak ha valaki nem specifikusan LibreOffice-t vesz multiéktól, akkor már nem™ érte™ meg™ fejleszteni.

Vagy szerinted aki LibreOffice-t akar használni, az döntsön úgy, hogy vegyen RHEL-t?

Nem, szerintem csak fel kéne fognod, hogy bár egy operációs rendszert senki nem fog egyetlen rajta lévő csomag miatt megvenni, de az egyes csomagok képviselhetnek akkora hozzáadott értéket, ami miatt valaki adott fizetős OS mellett teszi le a voksát, egy másikkal szemben. A LibreOffice pedig képviselt ilyen értéket.

"az egyik húzóága volt az RHEL irodai alkalmazásra való eladásainak" Szerinted a RedHat bevételeinek mekkora része származik a desktop/irodai környezetben használt RHEL licenszekből, és mekkora részt jelent benne a szerverekre eladott licensz, illetve az egyéb szoftverekből illetve support tevékenységből származó bevétel?

 

> De értem. Timar kollégáddal együtt felszopkodtátok multiékat, úgy beállítva őket,

 

Azert ovatosan a magas lorol. Nem tisztem senkit megvedeni, de Timar mar jo par eve tetemes kodmennyiseggel hozzajarul a Libreoffice-hoz, igy elegge kozelrol latja az esemenyeket, foleg ugy, hogy a libreoffice korul egyetlen piaci alapon mukodo ceg van, az pedig a Collabora, es annak a munkavallaloja (a pontos titulust nem tudom).

Ha o azt mondja, hogy a RH tetemes mennyisegu emberi munkaoraval jarult hozza a LibreOffice kodjahoz, akkor azt kar ketsegbe vonni, mert ugy van.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem vitattam Timar munkásságát, egy másodpercig sem. A Red Hat felszopkodását vitattam.

Attól még, hogy Timar nagyszerű programozó és maintainer, ugyanúgy szenvedhet Red Hat általi Stockholm-szindrómában és én ezt Timar legnagyobb tisztelete mellett is kimondom, mert a Red Hat önző, mohó üzleti idealizmusból szünteti meg most a támogatást. Ahogy önző, mohó üzleti idealizmusból támogatta eddig.

Ha o azt mondja, hogy a RH tetemes mennyisegu emberi munkaoraval jarult hozza a LibreOffice kodjahoz, akkor azt kar ketsegbe vonni, mert ugy van.

Ezt nem is vonta senki kétségbe.

a Red Hat önző, mohó üzleti idealizmusból szünteti meg most a támogatást. Ahogy önző, mohó üzleti idealizmusból támogatta eddig.

Saját magadnak mondasz ellent. Előbb még azt állítottad, hogy a LibreOffice képvisel akkora üzleti értéket, ami miatt a felhasználók RHEL-t vettek, és ezért támogatta eddig a Red Hat a LibreOffice-t. Ezek szerint a LibreOffice olyan szar szoftver lett, hogy mégsem képvisel már üzleti értéket, ezért a Red Hat dobja?

Hol a Red Hat mohósága most? Hiszen ha rád hallgatnak, akkor még jobban támogatniuk kéne üzleti mohóságból, hiszen licencbevételt hoz a LibreOffice állításod szerint. Tehát nem mohóság az, ha lemondanak a LibreOffice-ból eredő licencbevételekből, hanem éppen az ingyenes disztribúciók felé terelik a felhasználókat. Köszönjük meg a Red Hatnak, hogy lemondanak a LibreOffice miatti bevételeikről, milyen kedvesek.

Nem azért vettek RHEL-t, mert csak ott tudtak volna LibreOffice-t használni azok, akiknek LibreOffice használat kell a munka során.

Azt ugye vágod, hogy nem azért vesznek RHEL subscriptiont a népek (cégek), mert valamit csak azon tudnak megcsinálni. Vagy más megközelítésben: a subscriptionért cserébe ami elsődlegesen jár az előfizetőnek, az a support. Hogy minek a supportja? Hát ami éppen benne van az RHEL-ben! Tehát amikor benne volt a LO, akkor azért fizettek, hogy - többek között - arra is kapjanak supportot.

Jelen esetben ahol a LO supportra van igazából igény, a RHEL maradék részének supportjára meg nincs, na ott majd szépen áttérnek Rocky Linux meg Almalinuxra, és inkább előfizetnek LO supportra.

Miért nem jó neked a hivatalos LibreOffice RPM build a jövőben? Amiatt dobni egy egész disztrót, mert egy olyan third-party-t nem fog ezentúl szerepeltetni a csomagtárolójában, aminek amúgy van hivatalos RPM buildje, eléggé értelmetlennek tűnik nekem.

Mondjuk ez pont nem az a portál, ahová jellemzően szilárdtestfizikusok járnak főleg (persze biztos vannak itt olyanok is, mert vannak átfedések). Egy tanszéki tanárral egyszerre vettünk kedvezményes árú memóriát a HajdúComp-on, én adtam le neki a drótot :D

"...mit is csinál még az IBM, mert nagyon nincs szem előtt..."

Oké, a SOHO piacon valóban nem botlasz bele, de kb. a pénzügyi szektor kétharmada lehúzhatná a rolót, ha az IBM egyik napról a másikra megszűnne. Nem csak a midframe meg a mainframe, hanem a különböző szoftveres megoldások is... A Tivoli is ott van jópár helyen, és a Content Manager is csak párszáz millió dokumentumot pörget egy-egy nagyobbacska banknál vagy biztosítónál. Nem is beszélve egy halom olyan cégről, amit az IBM megvett tokkal-vonóval, és megtartotta az önálló brandet Csak akkor derül ki, hogy IBM-é a cég, ha direkt utánanézel, vagy ha a sales az orrod elé tolja a brosúrájukat a szép kék IBM-es sormintával minden oldal alján.

Jogos. Alaposan átalakított a tevékenységi köreit, pontosan ebből a célból. Egy tőzsdei vállalatnak nem lehet más célja és ha azt Ginni Rometty hajtja végre, akkor semmihez sem fognak nyúlni amiből nem lesz garantáltan profit valahol. Most a libreoffice ment a kukába,a többi még hoz a konyhára.

Kolléga a másik topikban meg kérdezi, hogy érdemes-e inkább a Debian-nal ismerkedni.

Csak nehogy pár év múlva Debian-éknak is fontosabb legyen a csiligány HDR Wayland-ot keresztülerőszakolni a disztrón, mint a Libreoffice megtartása, csak mert a GNOME már nem lesz hajlandó X.Org-gal elindulni.

( kisg v | 2023. 06. 03., szo – 21:14 )

Szerkesztve: 2023. 06. 03., szo – 21:17

Én már 1997-ben éreztem, hogy ez a RedHat nem lesz jó, pedig először azt raktam fel valami Chip CD-ről. Ezért kezdtem végül Slackware-rel, majd upgradeltem Debian irányba. :)

Viccen kívül:

Nem érzem azt, hogy mindenáron mindent a disztróknak kéne csomagolni. Én Chrome-ot használok, amit a Google csomagból teszek fel. Ha friss LibreOffice-t akarok az Ubuntu LTS-emre, akkor is felrakom vagy ppa-ból, vagy valami Flatpak / AppImage / Snap megoldásból. Kicad, Blender, FreeCAD mind hasonló módon kerülnek a gépemre.
 

> Én már 1997-ben éreztem, hogy ez a RedHat nem lesz jó, pedig először azt raktam fel valami Chip CD-ről

nekem 97-ben nem sikerult a redhat telepitesd, mar nem emlexem pontosan de mindig elszallt valami hulye hibaval.

a Salak bezzeg felment siman, elsore, igy azt hasznaltam utana egy evtizedig :)

Hahaha! Én is Red Hat-et telepítettem Chip CD-ről, nekem sikerült, csak a frissítés során az RPM mindig hibákat írt ki és összeomlott. Aztán mandrake-t, suse-t is próbáltam, azokkal sem voltam elégedett. Végül debian-t telepítettem és sokáig használtam, de kb. 10 éve az arch linux a kedvenc OS desktop-on.

Szintén. Előtte meg Slackware-t az első Chip CD-ről (3,5" CD), amiatt cseréltem le az SCSI kártyámat, mert nem volt a kernelben hozzá driver. Annyi helyem nem volt a HDD-n, hogy rajta is maradjon (kellett a hely a Warp meg a Win95 kipróbálására), úgyhogy eljutottam addig, hogy elindult az X, aztán egy darabig nem volt Linux, utána jött a RedHat, az már elketyegett addig, amíg a Chip különszáma nem hozta a Bo-t. Onnantól lett állandó Debian meglehetősen sokáig.

Fiatal versenyző :-)  1994, SLS, néhány doboz 3.5"-os flopiról, egy 486-os gép, talán volt benne 8MB RAM (de lehet, hogy csak négy...), aztán ősztől már oktattam... Telepítés, fájlrendszerben mi, merre, boot/init folyamat, OS általános felépítése, processzek kezelése, minimális hálózat, shell, ed/sed, awk, aztán a végén némi X11-es "kóstoló"...
Emlékeim szerint '93 őszén már volt kalóz Linux a pécés gépterem néhány gépén a Windows-os partícióból lecsípett területen, amit lilo-s flopiról lehetett elindítani baromi nagy titokban...

( hajbazer v | 2023. 06. 04., v – 15:37 )

Szerkesztve: 2023. 06. 04., v – 15:53

Igen, ez az a szélsőségesen idealista Matthias Clasen, akit joggal nevezhettünk a Red Hat második Lenart Pötteringjének, az alapján, amit a desktop (GNOME3/GTK3) vonalon művelt eddig. Ő az elsőszámú ember ezen a világon, akinek a desktop Linux lebutítását, kiherélését és gyakorlati hanyatlását köszönhetjük. A File Chooser kiherélése, a GTK3 API folyamatos eltörögetése, a GNOME3 tapicskoló-tablet-idealista okostelefonbuzi lebutítgatása és a desktop Linux megannyi korporatokrata idealizmusokkal való megerőszakolása. 

focusing on gaps in Wayland, building out HDR support

Ami lyukakat 10 éve képtelenek befoltozni, pedig alig várják, hogy az X.Org ellehetetlenítése mellett lenyomják a torkokon az újrafeltalált kereküket. Szóval egy eleve koncepcionális trágyadomb további tákolgatására szánják inkább az erőforrást, amit majd nagyvállalati arroganciával és hatalmi visszaélésekkel szeretnének lenyomni a Linux-világ torkán. Nem inkább arra, hogy az egyetlen használható office suite megmaradjon Linuxra.

building out what’s needed for color-sensitive work

Amire egyébként soha a büdös életben nem fognak Linuxot használni, de még Windows-t sem. Linuxot többek közt azért sem, mert kollégájával, a Red Hat harmadik Lenart Pötteringjének joggal nevezhető Peter Hutterer-rel együtt sokat tett azért, hogy az egyes beviteli eszközöket csak kezdetlegesen, kényelmetlenül és az ergonómiát megcsúfolva lehessen csak használni (újrafeltaláltkerék libinput erőltetése, evdev és synaptics és más független input driverek kiherélése vagy kiebrudalása).

A Gnome-ot én sem szeretem. Bloat és buta. De legalább nem olyan bughalmaz, mint a KDE lett. A Wayland szerintem jó cucc, gyorsabb, mint a X.org, nekem tetszenek, neked is ajánlom kipróbálásra (Hyperland, Sway, sovány Gnome desktop sallangok nélkül, Wayland session-ként, gnome tweks-szel beállítva), mert kevesebb ms. alatt rajzol ki, mint a X.org meg az XP GDI, bár azt nem tudom, hogy a te integrált retró ATi GPU-d, amit az ősi radeon kerneldriver elvileg hajtani képes, az mennyire tetszik neki. Ezt te tudod kipróbálni, a legújabb Arch iso alatt beröffented az arch-install szkriptet és pikk-pakk felnyomatsz egy ilyen rendszert, akkor megoldódik a rejtély.

Amit én nem szeretek, hogy a X-et máris ki akarják nyírni, pedig közös nevező a sok unixlike rendszer között, meg egy jó legacy fallback opció, több WM, DE érhető el rá, mint Waylandre, több az X-es alkalmazás is (jó ezekre ott van az Xwayland), könnyebb rá WM-et írni, többféle drivert támogat (nem csak az Nvidiával áll jobban, hanem ilyen Matrox, Voodoo, stb. is), stb.. Tehát meglennének az előnyei, ha nem nyírják ki azonnal a fősodratú, idealista babzsákfejlesztő mérnök urak a profitmultiknál. A HDR is biztosan van, akinek fontos, de biztosan kevesebb ember, mint akinek egy normális, natívra csomagolt Office-csomag fontos.

A file chooser/picker megoldások a Linuxnak, DE-knek általános gyenge pontja. Nem is az, hogy lebutítják, hanem fixre van drótozva, és nem tudod hatékonyabb saját megoldásra lecserélni. Pedig én nagyon szeretném, hogy a terminálos Vifm-et vagy a saját, fzf-es scriptem tudjam filepicker-ként is használni, de ez nem lehetséges. Hiszen a filepickerek lényegében semmit nem csinálnak, csak a GUI-s programnak átadnak néhány full path-t, pl. /bla-bla/random_folder/whatever /other/stuff/here, stb..

Ezt a Matyikát, akit emlegetsz, nem ismerem, nem hallottam még róla, de Pöcsteringet becsüljük és szeretjük. Átváltott a MS-hoz, de továbbra is tolja bele a Linuxba a hülyeségeit, mindenki megelégedésére. A Vörös Kalapékat is tiszteljük, polkorrekt CoC, hadd jussanak esélyhez a transgenderek, melegek, stb. is., nehogy már az kódoljon, aki nem pozitívan diszkriminált, hanem a programozáshoz ért ténylegesen és jó szakember, csak azt nem illik, tiltsuk be, mert fasiszta mind. Meg ugye mesterségesen avultatnak el szépen mindent, amiben az a baj, hogy néha az is, amit nem kéne. Bizalomgerjesztő banda a javából.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Igen, de ha retróbb hardveren akarsz akármit is futtatni, akkor támogatni kell. Nem is ez a két kártya csak a példa, hanem hogy az X akármin megy. Ez az, amit a Red Hat nem ért meg, hogy kicsit túlmutat az ő mostani corporate Linuxukun. Mondom, nincs baj a Waylanddel, szerintem már egy ideje elég jól használható, nekem tetszik is, csak azt kell érteni, hogy nem annyira elterjedt, hogy a majdnem 40 éve jelen levő, mindenütt működő X-et akkor elföldeljük mától vagy holnaptól. Igen, ki lehet vezetni, csak nem ilyen túlzással. Egy ilyen hosszú múltú, ennyi helyen technológiát nem tudsz ilyen gyorsan szanálni.

Az még oké is lenne, ha mondjuk új feature nem jön bele, teljesen rendben van, ha HDR, VR, fractional scaling, stb. támogatás nem lesz rá, aki X-et használ, annak úgyse ez a fontos. De legalább azt oldják meg, hogy valaki azért tartsa karban, a súlyos bugokat, sechole-oket azért javítsák időnként, hogy a mostani szinten használható legyen. Nem kötelező szeretni, használni, de akinek kell, annak elérhető legyen. El sem hiszed, hogy hány unixlike rendszer van, ahol a Wayland még nem játszik, és mennyi olyan X legacy app, ami a Waylandből amúgy sem profitál, és még nincs waylandes párja. Mondom, korai nagyon még temetni. Főleg, hogy arra még bőven jó, hogy kitalálták, meg különböző korú és unixlike OS-ű vasak között közös nyelv maradjon, ami a GUI-t illeti.

Persze, én értem a waylandeseket meg a Red Hat-ot, hogy próbálják az újat tolni, hogy ezzel az új technológiával se az legyen, mint anno az UEFI boottal, meg az IPv6-tal, hogy mindenki még a legacy megoldást nyomja helyettük, és lusta váltani. Próbálják kényszerrel lenyomni mindenki torkán.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Az összes cég (és függetlenül attól hogy kekszet vagy sw-t gyárt) mindig megcéloz magának egy piacot. Ez az Ubuntu és a Redhat esetén szerintem viszonylag jól be van lőve, és ebben a piacba nincsenek benne a 20-25 éves retró gépekkel, illetve mindenféle egzotikus platformokkal dolgozók. Ha ők szeretnének maguknak valamit, akkor majd megoldják, pont úgy, ahogy ezt a C64-es közösség is megoldotta.

Amiről te beszélsz, azok nem tömeges piaci igények. Értem hogy vannak emberek akik a zúzdából mentett Solaris rendszerre akarnak linux alól grafikus felületre belépni. Nem célközönség.

Ami viszont valós igény az egy gyors, nem bloat, nem security rémálom grafikus alaprendszer amely a videókártya funkcióira épülve gyorsan, hatékonyan, kevés energia felhasználásával kiszolgálja a keretrendszereket (QT, GTK, stb.) amiben a valós fejlesztés történik.
 

De legalább azt oldják meg, hogy valaki azért tartsa karban, a súlyos bugokat, sechole-oket azért javítsák időnként, hogy a mostani szinten használható legyen

De miert valaki mas oldja meg? :)

Nekem kb. teljesen mindegy, hogy az X vagy a Wayland, mert ami linuxos gepeim vannak, azokon nincsen GUI, de ha valakinek hianyzik egy feature, patch, stb. az X-bol, akkor egesz nyugodtan csinalja meg maganak. Ez lenne az open source egyik lenyege, nem? 

De legalább nem olyan bughalmaz, mint a KDE lett.

Csak várj. :)

kevesebb ms. alatt rajzol ki, mint a X.org meg az XP GDI

GDI-nál biztosan nem.

Tehát meglennének az előnyei, ha nem nyírják ki azonnal a fősodratú, idealista babzsákfejlesztő mérnök urak a profitmultiknál. A HDR is biztosan van, akinek fontos, de biztosan kevesebb ember, mint akinek egy normális, natívra csomagolt Office-csomag fontos.

Megjelennek, majd egyszer. Amikor majd elkezdik fejleszteni a ReinventedWayland2.0-át. A Red Hat-tal sosem az volt a probléma, hogy alternatív initrendszert, audioszervert, widget libraryt, vagy éppen grafikus környezetet fejleszt, a közösségi irányt és a Linux alapkoncepcióit kódsoronként szembeköpve. Hanem az volt (és az most is), hogy korporatokrata erőszakkal nyomkodja le a szarát a Linux-világ torkán, influenszerekkel, zsarolási pozíciók arrogáns kihasználásával, döntési csapdák megteremtésével, kényszerkompromisszumokkal, invazív fejlesztési és terjesztési módszerekkel.

A Wayland-del az a probléma, hogy jelenleg is egy béta minőségű szoftver. Az X.Org kiállta az idő próbáját, a javítható hibái javítottak, a javíthatatlan hibái ismertek, nagyrészt workaroundoltak és jelenleg teljes mértékben stabilnak tekinthető. A Waylandról ez nem mondható el. Early adopterek próbálgatós játszótere, tele buggal. Semmi más.

jó ezekre ott van az Xwayland

Tele kompatíbilitási hibákkal, amivel az ég világon senki nem fog foglakozni, mert a Matthias Clasen félék elvárják az egész világtól, hogy írják újra a szoftvereiket a Red Hat aktuális újrafeltaláltkerekére.

A HDR is biztosan van, akinek fontos, de biztosan kevesebb ember, mint akinek egy normális, natívra csomagolt Office-csomag fontos.

HDR is biztosan fontos, csak nem Linuxon.

Nem is az, hogy lebutítják, hanem fixre van drótozva, és nem tudod hatékonyabb saját megoldásra lecserélni.

Egyre kevesebb dolgot tudsz hatékonyabb, saját megoldásra lecserélni. Ha pedig a Red Hat-en múlik, akkor egyre inkább így lesz.

Ezt a Matyikát, akit emlegetsz, nem ismerem, nem hallottam még róla

Pedig hozzád intézett válaszokban is elég sokat emlegettem.

Átváltott a MS-hoz, de továbbra is tolja bele a Linuxba a hülyeségeit, mindenki megelégedésére.

Van helyette 2 másik, akik most betöltik az űrt és folytatják a Linux-világ szisztematikus felforgatását.

Hat nem tudom, van amikor az eroltetett kiszedes a jo dontes. Lasd sysVinit -> systemd migracio. Mostansag volt dolgom sysVinit-es rendszerrel, hat igy utolag egy kalap szar. Mostansag mar a nehany megas embedded Linuxok is systemd-vel mennek.

Pont most futottam bele, hogy felraktam a normal laptopomra egy Suset (KDE-vel), hogy ez a rohadvany X nem tud olyat, hogy a kulonbozo monitorokon kulonbozo a scaling. Mikozben az 5-6 eves laptopok is fullHD kijelzovel jottek.

( zeller | 2023. 06. 04., v – 23:09 )

Szerkesztve: 2023. 06. 04., v – 23:11

A Linux Desktop éve eljön... Majd. Valamikor... De hogy nem a Red Hat vagy a SuSE vagy épp a Canonical hozza el, az már szinte biztos... WSL-ben jó lesz Linuxozni, de Office-nak ott lesz a natív Windows-os build vagy épp a Microsoft Office.
 

A Linux desktop evek ota jol hasznalhato, nalam ugy 2002-2003 korul jottt el. Ha 4k-s monitorod van, akkor jelenleg a KDE jobban is mukodik, mint a bugos Win10-esek (olyannyira, hogy egyszerubbnek lattam visszavaltani fullHD-re amig hozzaszoknak az ottani fejlesztok, hogy je, ilyen is van).

A strange game. The only winning move is not to play. How about a nice game of chess?

Miért visszalépés? Meggyorsítja a szoftverek frissen tartását, és terjesztését ez.

A szoftver készítője csinál egy Flatpaket/AppImage-t/Snapet és bárki azonnal használhatja.

Nem kell megvárni, amíg PPA lesz belőle, AUR lesz belőle, COPR lesz belőle, vagy éppen direktben beemelik a csomagkészítők a disztró tárolóiba.

Igazából ezek nem mások (mivel van bennük ugyanúgy függőségkezelés is), mint crossplatform csomagformátumok a disztró-specifikus rpm/deb helyett. Tekints úgy, mintha a disztródba nemcsak .rpm csomagkezelőd lenne, hanem .flatpak csomagkezelőd is van mellé. Mi ezzel a visszalépés? Szerintem eléggé menő, hogy egyszerre egy disztróhoz többféle csomagformátumot is fel tudok telepíteni, anélkül, hogy szétbasznám a rendszert.

Van elonye is, de teleszemeteli a filerendszert, memoriat, df/mount kimenetet, plusz lassabb, es a szokasos frissentartast hatraltatja (nem eleg mondjuk az apt-vel frissiteni mindent, hanem a snap/flatpack es tarsaival is kell).

A strange game. The only winning move is not to play. How about a nice game of chess?

- "de teleszemeteli a filerendszert" - miért is? minden snap/flatpak jól definiált helyen van a fájlrendszerben, nem pedig úgy, mint egy csomag, ami ezer helyre írhat az fs-en

- "teleszemeteli a memóriát" - ezt mégis hogyan? Igen, valóban húz be libeket pluszban. Az egész dolog olyan, mint egy konténer - egy különálló process tree.

- "df/mount kimenetet" - eleve LVM és magasabb absztrakciók, virtuális fájlrendszerek korában ez számomra nem jelent problémát. Ha a fizikai diszkek foglaltságára vagy kíváncsi, akkor arra megadhatod a df-nek, hogy milyen típusú fájlrendszerket hagyjon ki a -x használatával. Csinálhatsz is rá aliast

"plusz lassabb" a snap lassú, mert szar az implementációja, az AppImage és a Flatpak nem.

Ha van a rendszerben mondjuk egy adott verzioju libc vagy glibc, egyszer foglal helyet, es a memoriaban is egeszen addig 1 peldanyban van, amig szukseg van ra (utana 0). Ez a jo a shared libekben. A processzek persze a sajat cimterukbe mappelve latjak, szamukra olyan, mint ha sajat peldanyuk lenne. Forditaskor persze PIC-kent (position independent code)-kent kell forditani a libeket, pont azert, mert nem fix helyen lesz a cimterben, de ez egy esszeru kompromisszum (minimalis sebesseget veszithetsz vele a statikus esethez kepest). A kulonbozo verziojuk libeket persze meg kell oldani, de ez Linuxon eleg jol mukodott eddig (winen sem lattam dll hellt mostanaban).

Ha 20 peldanyban lenne (mind a filerendszeren, mind a memoriaban, snap-stilusban), akkor no a helyfoglalasa ezeken a helyeken. Ez persze nem feltetlenul baj (pl. dockernel is redundans dolgok vannak), de ha a tobbszoros memoriafoglalas nem ad indokolhato elonyt, az nem jo. Itt tobben azon a velemenyen vagyunk, hogy nem ad.

A strange game. The only winning move is not to play. How about a nice game of chess?

Glibc eseten nem kritikus. Random grafikus (gtk vagy qt) alkalmazas eseten nem ennyi lesz a plusz felesleg ha 0-rol butan lemasol mindent. Persze lehet trukkozni vele, csak nem biztos, hogy megeri a klasszikus deb/rpm-et levaltani erre, ha nem ad erte annyi pluszt.

A strange game. The only winning move is not to play. How about a nice game of chess?

winen sem lattam dll hellt mostanaban

Nézz utána a WinSxs könyvtár funkciójának. Minden gyakrabban használt dll gyakorlatilag több tucat verzióban létezik WinSxs mappában, mert olyan h. shared legyen egy dll, szerintem vista óta nem jellemző. Minden program megkapja a saját dll-jét, nincs közösködés sem memóriában, sem a storage területen.

A shared libeknek vannak elonyeik, valoban, azonban a DLL hell, a mindenfele inkompatibilitasok es tarsaik megmutattak, hogy sokszor nagy problemat is jelentenek. Nem kell elmagyarazni, mik azok a shared libek. Van, hogy tobb problemat okoznak, mint amit megoldanak.

Peldaul te telepithetsz egyszerre ket glibc verziot a rendszeredre ugy, hogy minden menjen out of the box? Mert mondjuk a disztro szallitoja 2.x-es glibc-vel adja a disztrot, de neked egy szoftverhez 2.y kell, mit csinalsz?

Nyilvan lehet LD_LIBRARY_PATH-tal mokolni - de akkor ugyanugy eszi a processz a plusz memoriat, mint a Flatpak stb eseteben. Gyakorlatilag a flatpak egy nagyon jo kis automatikus LD_LIBRARY_PATH basztato eszkoz, megcsinalja helyetted azt, amit kezzel kene csinalnod. Es ugyanugy vannak benne definialt runtime-ok, verziozva, fuggosegkezelve stb. Peldaul nem lesz 4x feltelepitve a Gnome 40 runtime, ha 4 flatpak app fugg tole.

Nem is akkor van gond. Hanem az alkalmazás újabbal van linkelve, de a disztró régit szállít.

Például Red Hat Enterprise Linux 8-at használok, amiben glibc-2.28 van. Azóta azért került be egy s más a glibc-be, például Unicode 13 (glibc 2.32) támoagtás,  jó pár új függvény POSIX támogatás miatt.
De mondhatnám a glibc 2.34-et, amit a Red Hat Enterprise Linux 9 szállít, azóta azért jött ki 3 új release, benne Unicode 14 támogatás, C.UTF-8 locale támogatás, stb.

Mit tegyek, ha ezeket szeretném használni?

 

Amúgy a probléma nem glibc specifikus, bármelyik más libraryre is fennáll, amelyik vagy kompatibilis visszafelé/előrefelé, vagy nem. Lehet ez freetype, fontconfig, pipewire/pulseaudio/alsa/vdpau/libva, bármi más.

"Mit tegyek, ha ezeket szeretném használni" - Fordulj meg a nyeregben. Az OS szállít adott funkcióhalmazt, adott verziókat. Ha az adott környezetre akarsz fejleszteni, akkor arra fejlessz, ne másra. Igen, a fejlesztők - bár az ilyeneket én kódgányolóknak hívom - szeretnek a "holnapi" verziókkal dolgozni mindenből _is_, kivéve, ha valamiből az x éve nem támogatott verzió a kedvezőbb a számukra.  Hobbiból fejleszthetsz bármilyen alapokat összelegózva, de ha üzleti igényt akarsz kielégíteni, akkor ott azért jóval szűkebbek a határok, ott van egy "étlap", amiből válogathatsz. vagy "B" tervként adod konténerben, amiben az összes(!) komponensnek a frissítéséért (rendszeres és rendkívüli frissítések, sérülékenységekre adott megkerülő megoldások implementálása, hardening) te felelsz - a konténerbe telepített csomagok/sw-komponensek mindenkor aktuális listáját, verziószámokkal együtt természetesen átadva a megrendelőnek.

 

Ácsi. Nem fejleszteni akarok, felhasználó vagyok most éppen (erről szól a topik). Használni akarom a LibreOffice-t, VLC-t, Spotify-t, Chrome-ot, stb.

A LibreOffice stb. fejlesztője mit csinál? Hát mit, konténert, ezt hívják desktopon Flatpaknak, snapnek, AppImage-nek. Sokan ágálnak ellene, pedig jó dolog, terhet vesz le a fejlesztő, az OS gyártó és a user válláról is, nem is beszélve az újrabuildelések, csomagolások overheadjéről. Mennyi tárhely, sávszélesség, energia megy el csak arra, hogy deb/rpm/aur/apk formátumban meglegyen minden.... totál pazarlás.

Lóf...t vesz le terhet... Eddig volt egy csomagkezelő, amivel frissült minden _is_ ezzel meg lesz n+1, plusz a jóég sem fogja tudni, hogy az így bezsákolt mindenféle lomból összelapátolt alkalmazás mennyi lukas sz@rt hoz magával...

"Mennyi tárhely, sávszélesség, energia megy el csak arra, hogy deb/rpm/aur/apk formátumban meglegyen minden.... totál pazarlás." - Ezek helyett lesz n-szer nagyobb csomaghoz 3rd party repó, amiből nem csak azt kell lehúzni, ami nincs meg már az OS részeként, hanem mindent _is_. Minden végfelhasználóhoz...

Én ha így lesz, dobni fogom a Linuxos LO-t, használom majd Windows-on, a FF-ot felváltotta/felváltja Linuxon (is) az Edge (csomagból), a spotify, vlc, zoom, viber ilyesmi szintén teljesen jól mennek a géphez kapott Windows-on, a Linux-only dolgok szépen mennek WSL2-ben futó Linuxon, az X410-zel a gui-s dolgokkal sincs gond...

Ez a lépés, hogy mégbloatabb lesz az LO az rpm-alapú rendszerekben, újabb szög a linuxdesktop koporsójában...

Azok a libek, komponensek, amik nem azonosak az OS-ben és ezekben a bloatokban, azok bizony n-szer le lesznek húzva - jó esetben csak kétszer, rosszabb esetben az x meg az y alkalmazás fejlesztője miatt háromszor, vagy épp annyiszor, ahány egybecsomagolt motyóba belezuttyantották.

"ugyanúgy frissül egy flatpak is automatikusan." - Ez nekem nem tűnt úgy... Kézzel rányomva igen, egyébként meg nem...

Azok a libek, komponensek, amik nem azonosak az OS-ben és ezekben a bloatokban

ahogy ha valaki statikusan linkelt dolgot csomagol rpm/deb/anyámkínjába, úgy ott is. egy igazi fejlesztő minden nyelven tud fortran kódot írni egy igazi maintainer minden technológiával tud szar csomagot készíteni.

Ezzel csak az a baj, hogy ahany OS ahany verzioja, annyifele layer. Ehhez nem fogsz igazodni, ha beleoszulsz sem, felteve, hogy nem 1-2 libet hasznalsz, vagy raksz a dev melle meg X db package maintainert is, akik majd szepen megkuzdenek az osszes disztro majmaival, hogy mit/hogy/miert NE, mikor mit mire akarnak megvaltoztatni. Ezert sem lesz soha "linuxdesktopeve".

Az appimage es tarsai pont azert _is_ marhajo dolog, mert a kedves user mindenfele OS ganyolas nelkul, user joggal tud alkalmazast frissiteni, torolni. Tudhato hol van, paraszt uti F8-cal el is takarodott es meg az ottmarado fuggosegek sem fogjak teleszemetelni a rendszered. (az is vicces mikor egy par distupgrade utan lesz a libjeidbol X verzio, amit aztan vagy bator vagy es mered kukazni, aztan esetleg szepen tori a dolgokat, vagy sem.)

Nekem eddig ez az irany tetszik a legjobban. De elegge "black magic" es abszolut nem r=1 endusernek valo.

"az is vicces mikor egy par distupgrade utan lesz a libjeidbol X verzio, amit aztan vagy bator vagy es mered kukazni, aztan esetleg szepen tori a dolgokat" - Ha törik, akkor ami eltört, annak a karbantartóját kell rugdosni, mert a csomagfüggőség nem volt korrekten kezelve...

"ahany OS ahany verzioja, annyifele layer." - Ha mindenre _is_ ki akarod hozni az alkalmazásodat, akkor igen. Viszont ha megnézed, van 2-3 fő disztribúciós irány, darabonként 2-3 vagy négy támogatott verzió - legyünk nagyvonalúak, és mondjuk azt, hogy van 12-15 target - amik között forrás/használható komponensek terén igen sok átfedés van, úgyhogy worst case 4-5 küönböző "ágat" kell maximum karbantartani - ami ugyan még mindig több, mint a snap/flatpak/appimage miatti legalább három - de nem sokkal, viszont azzal, hogy jóval kevesebb komponens van, amit hozzá kell csomagolnod a motyódhoz (mert a snap/flatpak/appimage alap layereiben nincs benne, vagy nem az van benne, amit használni szeretnél), azaz kevesebb függőség miatt kell rendszeresen újraépítened a motyót, új verziót kiadni belőle...

mert az os layereiben mi van? amit az os karbantartoi eppen kitalaltak. es sohasem ugyanaz. a flatpakbe/appimage-be meg az lesz amit beleteszel es nem fuggsz az os baromsagaitol. nem olyan rocket science ez.
az, hogy nem jon default a libjoskapista sec. fix os csomagokbol, az meg vagy jo vagy nem, attol fuggoen ki tudja eppen hamarabb befoltozni (es a user melyiket fogja hamarabb befrissiteni)

Adott OS-re kell fejleszteni, nem bele a vakvilágba, aztán lesz@rni, hogy a "fejlesztésedhez" csomagolt 1234, akkor az upstream-ben elérhető legújabb komponenst darabonként 234 alkalommal frissítették, mert neked zsenánt 1234 komponenst követni, minden, az upstream-ben megjelenő javításnál új verziót kiadni... Ha az egybecsomagolt bloatware-edben van lukas komponens, akkor téged foglak ütni, hogy ASAP javítsd, és adj új verziót, ha meg az OS-hez szállított komponens sz@r, akkor az OS gyártóját/összeállítóját.

"nem fuggsz az os baromsagaitol." - Inkább függök egy nagyobbacska disztribúció "baromságatól", mint a jóskapista által összecsomagolt, a jóég, se tudja, miből mit tartalmazó, meddig támogatott, milyen frissítési ciklussal, milyen hibajavítási vállalásokkal (illetve azok nélkül) kiadott bloattól.

Hát nem tudom... A Collabora Online-t elkezdtem csomagolni Ubuntu LTS-ekre, Debianokra, Redhat 7 és 8-ra, és SUSE 15-re. Ez elég sok, és két évente jön új Ubuntu LTS, jön új Debian, már régóta van Redhat 9, ráadásul rendszeresen jön a kérdés, hogy a FaszomLinux 9.4-en mennek-e a csomagok stb. Mondanám, hogy fogalmam sincs, próbáld ki, de udvariasnak kell lenni, illetve úgy kell tenni, mint aki természetesen hallott már a FaszomLinuxról.  Azt találtam ki, hogy a következő főverzió statikusan lesz linkelve, és disztrófüggetlen lesz. Ez négy libet érint. Az egyik a Poco, ezt eleve sok disztró nem is csomagolja, vagy csak valami régi verziót. A második a libpng, azt a LibreOffice (amit használunk, mint backend) is statikusan linkeli, onnan vesszük, tehát friss lesz. A harmadik az OpenSSL, ezt is statikusan linkeli a LibreOffice, igaz nem sok mindenre használja, de szintén frissen van tartva. A negyedik a libzstd. Eleve gyakran van release, 3-4 hetente, az esetleges biztonsági hibákat így tudjuk javítani. Aki beragad egy régi verzión és nem frissít, az így járt, az OS frissítés nem fogja megmenteni. De a kockázat/haszon elemzés nekem azt hozta ki, hogy ez a helyes út. 

Ha nem "mindent is egybe" csomagoltok, csak azt, amit az OS nem szállít vagy ott van, de a frissítési/javítási ciklus tudhatóan hosszabb, mint amit ti tudtok adni, akkor jó is lehet - pláne, ha az upstream is így működik - és a normál csomagkezelésbe bele lehet szuszakolni, nem pedig egy n+1. módon települ. (Anno azzal köpködte a Linuxos világ a Windows-osokat, hogy van csillióegyféle szoftvertelepítési mód, aztán kövesse az ember, mit, mivel hogyan telepített, mi mikor frissül - egyáltalán mi van telepítve, mi mihez tartozik - aztán mire a Windows eljutott oda, hogy midnen, ami értelmes, az msi, és alkalmazásbolt, addigra a Linuxok meg elkezdenek n+1 féle telepítési megoldást használni... :-)

Anno azzal köpködte a Linuxos világ a Windows-osokat, hogy van csillióegyféle szoftvertelepítési mód, aztán kövesse az ember, mit, mivel hogyan telepített, mi mikor frissül 

Köpködte, mellette meg csodálkozott, hogy hogyan nem jön el a Linux desktop éve, miért nincs elterjedve a Linux, a gyártók miért nem adnak ki rá szoftvereket. Nincs új a nap alatt, az ISV-k számára kurva nagy szopás támogatni egy ennyire fragmentált platformot.

Aztán megjelent a snap/flatpak stb, és láss csodát, megjelent jó pár ISV terméke Linuxra.

A nagyok még tartják magukat, a Microsoftnak, Googlnek van erőforrása arra, hogy kiadja RPM/DEB formátumban a csomagjait (APK, Pacman stb nincs támogatva ott sem, mert arra már nincs idő). Spotify meg kiadja snapként és kész, nem fog szarakodni. 

A nagyok még tartják magukat, a Microsoftnak, Googlnek van erőforrása arra, hogy kiadja RPM/DEB formátumban a csomagjait 

Es ugye neha ott is benne van az aprobetuben, hogy jo, hat vegulis van DEB, de az csak Ubuntu 20.04.1-en mukodik, de csak ha egy ejfelkor levagott kakas verevel jelolod meg a CPU-t.

Tenyleg, mennyivel jobb ez, mintha egy kontenerben jonne az app, es uram bocsa' ket olyan szoftver is megferne egy gepen, ami egyebkent kizarna egymast.

Nem tetszik, nem kell hasznalni. En csak amulok ezen a threaden, hogy mennyire nem vagytok kepben, mekkora valos effort az SDLC egy ennyire fragmentalt platformon. 

Vagy hat a B opcio, hogy a fejleszto kiadja a cuccot kizarolag mondjuk Ubuntu 22.04-re, te meg eldontod, hogy kell-e vagy nem.

és amíg ez nem változik, addig jönnek a gányolások és a szétaprózott erőforrások

En nem gondolom, hogy ezt a problemat az alkalmazas-vendoroknak kellene megoldania. Pont azzal lehet elkerulni a ganyolast, ha azt mondjak, hogy itt a kontener, benne van minden, ami kell, hasznald egeszseggel.

Hogy ennek mi az optimalis implementacioja, Snap vagy valami mas, azon mar lehet gondolkodni, de ez a problema akkor sem kezeheto a vendor szintjen.

Igy van, pont azzal aprózódik el az erőforrás, mert minden nyomorult linux disztribúció összes major verzióján végig kellene tesztelni a szoftvert. Erre nem hogy egy kis pár fős projekten nincs erőforrás, de egy nagyon sem. Úgyhogy marad a flatpak, snap, és a többi.

Az ilyenektől mentsen meg a mindenható... Aztán a belegyógyított lib kritikus sérülékenysége benne is marad, amíg nem hajlandó új verziót kiadni - de nem fog, mert lusta újrabuildelni, sőt nem is érdekli, mert nem követi az összes komponensének a sérülékenységeit/javításait/verzióit...

Nem lustaságról szól csak ez. A szoftvercégek tök ugyanolyanok, mint minden másik cég - nem örökéletűek. Kiadtál egy binárist, hurrá, majd megszűnik a cég. Mi lesz a szoftvereddel? Elkezd avulni. Ha minél több dolog van statikusan belefordítva, akkor elindul, működik - igen, lehet, hogy biztonsági kockázat, de működik.

Tedd a szívedre a kezed: hány olyan, általad készített szoftver van, ami működik, élesben használják, de nem a legkurrensebb libeket használja, ami elérhető?

A Linux desktop éve akkor jön el igazán, amikor az ISV-k nyugodt szívvel készíthetnek erre a platformra szoftvereket úgy, hogy tudják, 2-3-4 év múlva is működik a szoftverük gond nélkül. A Flatpak, AppImage és társai erre adnak megoldást.

" hány olyan, általad készített szoftver van, ami működik, élesben használják, de nem a legkurrensebb libeket használja" - Az upstream-ben vagy az adott alkalmazást futtató OS-ben legfrissebb? Minél több komponenst "gyógyítok bele" kvázi statikusan egy alkalmazásba, annál több függőséget kell követnem, annál több komponensnek a hibajavításait kell prezentálnom a felhasználó felé. Nem fogom az xyz perl/php/python/whatever modul/lib adott verzióját hozzácsomagolni az alkalmazásomhoz, hanem azt mondom, hogy az abc.1.2.* vagy frissebb verzió szükséges a működéshez.
Ettől persze követnem kell az abc motyó verzióváltásait, de a frissen tartása _nem_ az én feladatom, és ha korrekten verzióznak, akkor tudható, hogy az adott OS-ben annak életciklusában az abc.1.* ott lesz, maximum ha 1.2.*-ról 1.3.*-ra mennek, akkor lehet szükség a kódom módosítására.
Az, hogy bizonyos disztrók életcikluson belül is mennek előre főverzióban is akár, az nagyon nem jó - igen, persze, backportolni kifejezetten sok meló, meg "minekaz" - csak épp így az OS, mint platform stabilitását dobják a kukába.
Lehet fújni a Red Hat -re, hogy milyen régi verziók vannak benne x, meg y meg z csomagokból -  de a másik oldal az, hogy ezek fixek, ha RHEL8-ra csináltál egy alkalmazást az ott elérhető eszközökkel, akkor az alól a RHEL8 életciklusának a végéig nem fogják kirántani az egyes komponenseknek az induláskori főverzióit. És ez igaz nem csak a libekre és egyéb hasonló függőségekre, hanem alkalmazásokra is - így esett, hogy RHEL5-ben rsyslog (v3) volt, amit külön trükkösen lehetett rsyslog5-re lecserélni.

Viszont ha meg a Flatpakok által szállított rétegektől függesz (pl. Gnome 42-től, csak egy példa), akkor neked tök mindegy, hogy RHEL8, RHEL9, Ubuntu 23.04, Debian 11 vagy mi az OS. Van egy olyan runtime, amire fixen építhetsz, és elérhető minden OS-re. Sokkal egyszerűbb vele több OS-t támogatnod.
Ha egy ISV-nek azt mondja a Linux/opensource közösség, hogy kedves ISV, neked aztán kurva sok dolgod van, mert kéne támogatnod Archot, Ubuntut, Debiant, Fedorát, Red Hatot, OpenSuse-t, SLES-t, CentOS-t stb. akkor néz, hogy neki miért van ennyi dolga ezzel? Csinál egy flatpaket és kész, jó mindenhova.
ÉS ne feledjük, nem arról van szó, hogy te egy klasszikus bérgyártásban dolgozó szoftverfejlesztő vagy, aki egy cégnek csinál egy custom megoldást, ahol előírhatja, hogy a megrendelő milyen OS-t adjon alá, hanem egy desktop piacra szánt szoftvert készítesz. Mondjuk LibreOffice-t, Spotify klienst, böngészőt, videolejátszót, stb.,  ahol érdekedben áll a minél szélesebb OS támogatás.

"Miért visszalépés? Meggyorsítja a szoftverek frissen tartását, és terjesztését ez." - Maximum a terjesztését, mert a frissen tartását nem igazán, a dupla "csomagkezelés" miatt. Plusz mivel mindent _is_ "hoz magával", így a mérete (sávszélesség igény, tárhely) is több - és ezt a többletet szorozzuk fel azzal, ahányan használják... Mindjárt csúnyább lesz a kép - nem is kicsit...

( trey | 2023. 06. 08., cs – 10:31 )

Még ~ 25 év után is meg tud lepni a HUP.

Itt van ez a hír, amire azt hittem, hogy a kutyát nem fogja érdekelni, majdnem ki se tettem, erre 111 komment, több ezer lekattintás, viszi a hetet .... Máskor meg azt hiszem egy hírre, hogy na ez majd mekkorát megy, aztán semekkorát ....

trey @ gépház

( asch v | 2023. 06. 08., cs – 11:41 )

Az új Ubuntun snap-ből van Libreoffice. Egyrészt a gamer PC-men várakozni kell mire kinyílik, másrészt pedig a home folderben nem tudja kinyitni a fájlt, csak szubfolderekben! Elképesztő bug, fogalmam sincs, hogy hogy lehet ilyet benne hagyni. Itt megtaláltam a neten dokumentálva is, nekem is pont ezt produkálta: https://ask.libreoffice.org/t/ho-to-solve-the-lock-file-could-not-be-cr…

Éljen a snap!

Nekem az, hogy nem tud függőségkezelést, és így tényleg benne van minden az image-ben. Flatpak esetén van olyan, hogy Gnome Platform 42, Gnome Platform 40 stb. Ezeket egyszerre mind feltelepítheted, és amelyik alkalmazásnak Gnome 40 támogatása van, az is működni fog, meg aminek Gnome 42, az is. Gyakorlatilag a Flatpak nem más, mint egy nagyon okos filerendszer és LD_LIBRARY_PATH absztrakció, ami kezeli neked azt, hogy egy adott libből fent van több verzió is (és nem csak az az egy, amit amúgy a csomagkezelő feltesz). Arról nem is beszélve, hogy a rendszer csomagkezelőjétől függetlenül működik, ezért lehet neked RPM/DEB/whatever alapú disztribúciód, menni fog. Gyakorlatilag a flatpak a crosspaltform csomagkezelő, ami tud függőségeket kezelni, és tud egyszerre egy csomagból több verziót is telepíteni. Az egész mögött az OSTree áll: https://ostreedev.github.io/ostree/introduction/

AppImage esetén meg minden alkalmazás magával hozza MINDEN függőségét.

Én ezt már nem akarom érteni, csak használni. A másik a TuxPaint volt (szerintem szintén sznap). Felraktam a gyerekeknek, kalap kabát, örülés. Rajzolgattak vele egy darabig majd rágni kezdték a fülemet, hogy valamit ki akarnak nyomtatni belőle. Mondom jó, persze semmi akadálya, ingyen van a színes tinta, mi baj lehet? Odamegyek nagy mellénnyel nyomtatni és... nem sikerült. A vége az lett, hogy az egész család már aludt amikor még próbáltam megfejteni, hogy kell bekonfolni a nyomtatást TuxPaintből. Végül inkább feladtam szégyenszemre.

( rope | 2023. 06. 09., p – 19:27 )

Akkor sem fogom lecserelni az OSS-t ALSA-ra!! :)