abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 06:11 | Zajímavý článek

    Man Yue Mo z GitHub Security Lab se podrobně rozepsal o již opravené zranitelnosti CVE-2023-6241 v Arm Mali GPU umožňující získání roota na telefonu Pixel 8 s povoleným MTE (Memory Tagging Extension).

    Ladislav Hagara | Komentářů: 0
    dnes 04:44 | IT novinky

    V San José probíhá vývojářská konference NVIDIA GTC 2024. CEO společnosti NVIDIA Jensen Huang měl dvouhodinovou keynote, ve které představil celou řadu novinek: NVIDIA Blackwell platform, NVIDIA NIM microservices, NVIDIA Omniverse Cloud APIs, Project GR00T, …

    Ladislav Hagara | Komentářů: 0
    včera 14:33 | Komunita

    Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.

    Ladislav Hagara | Komentářů: 10
    včera 13:33 | Pozvánky

    Od 21. do 23. března proběhnou Arduino Days 2024. Sledovat bude možné oficiální streamy. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.

    Ladislav Hagara | Komentářů: 0
    včera 12:11 | Pozvánky

    Letošní ročník konference LinuxDays se uskuteční o víkendu 12. a 13. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během letošního ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru, Facebooku nebo na Mastodonu, přidat se můžete také do telegramové diskusní skupiny.

    Petr Krčmář | Komentářů: 3
    včera 09:00 | Nová verze

    Byla vydána nová major verze 2.0.0 a krátce na to opravné verze 2.0.1 open source online editoru Etherpad (Wikipedie) umožňujícího společné úpravy v reálném čase.

    Ladislav Hagara | Komentářů: 0
    včera 08:00 | IT novinky

    Elonem Muskem založena společnost xAI otevřela pod licencí Apache 2.0 svůj AI LLM model Grok-1.

    Ladislav Hagara | Komentářů: 3
    včera 00:44 | Nová verze

    Matematický software GNU Octave byl vydán ve verzi 9.1.0. Podrobnosti v poznámkách k vydání. Nově je preferovaný grafický backend Qt a preferovaná verze Qt 6. V tomto vydání byly přepracovány funkce pro převod čísel z desítkové soustavy. Jako obvykle jsou zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.

    Fluttershy, yay! | Komentářů: 0
    17.3. 22:33 | Zajímavý článek

    Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu březnový souhrn novinek. Vypíchnout lze, že pracují na virtuálním asistentu PineVox a zatím bezejmenných sluchátkách na lícní kosti (bone conduction).

    Ladislav Hagara | Komentářů: 0
    17.3. 18:33 | Nová verze

    Hyprland, kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, je již dva roky starý. Při té příležitosti byla vydána verze 0.37.0 (a záhy opravná 0.37.1 řešící chybu ve vykreslování oken). Nově závisí na knihovně hyprcursor, která poskytuje škálovatelné kurzory myši.

    Fluttershy, yay! | Komentářů: 3
    Steam
     (25%)
     (28%)
     (13%)
     (10%)
     (25%)
    Celkem 310 hlasů
     Komentářů: 4, poslední 11.3. 21:45
    Rozcestník

    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


    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    2.6.2023 21:26 --
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Hodně zvláštní a nelogické rozhodnutí.
    Ilfirin avatar 2.6.2023 21:51 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Zvláštní možná, ale nelogické? Logicky tlačí Flatpak na desktop aplikace.
    3.6.2023 13:46 _
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Na tom není nic logického, to je čistá demence.
    4.6.2023 16:45 hm
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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
    2.6.2023 22:55 X
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Nezustane, proste si je stahnes ze stranek LibreOffice.
    3.6.2023 00:26
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    To je takové správné Windows řešení.
    3.6.2023 12:37 hm
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    +1 konecne to nekdo po tech 50 let pochopil cojz se o nekterich luniksaku neda rict dokonce i dnes
    3.6.2023 13:58
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice

    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.

    4.6.2023 12:41 Ivan3
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 4.6.2023 14:06 AsciiWolf | skóre: 40 | blog: Blog
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice

    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 avatar 4.6.2023 17:07 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    4.6.2023 17:25 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 4.6.2023 17:41 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    4.6.2023 20:54 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 5.6.2023 18:04 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    5.6.2023 20:08 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 :-D (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 avatar 5.6.2023 22:45 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Dokonalost softwaru, chyby, distribuce, SSL a CA
    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ě.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    6.6.2023 01:02 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Dokonalost softwaru, chyby, distribuce, SSL a CA
    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...
    4.6.2023 18:52 plostenka | blog: plstnk
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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...
    4.6.2023 21:45 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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а avatar 5.6.2023 00:03 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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/… :-D
    5.6.2023 13:40 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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é...
    5.6.2023 10:19 Ivan
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    5.6.2023 10:37 Peter Golis | skóre: 64 | blog: Bežné záležitosti | Bratislava
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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é.
    5.6.2023 13:35 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    5.6.2023 15:06 ~
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Tak zas v serverovne se HiDPI displej jen tak nevidi a ve virtualu jumpservra ti to muze byt jedno :-D Nebo nejake prase tady spousti MSSQL tools primo u sebe na desktopu a cela security je v pic.. v prd.. proste neni? :-D
    xkucf03 avatar 5.6.2023 17:49 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Od kdy bezpečnost spočívá v tom, že se GUI aplikace spouští někde na serveru?
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    5.6.2023 18:11 xkucf04
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Odjakziva? Nebudes snad data tahat pres sit na lokal kdyz nemusis ne?
    5.6.2023 19:26 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    jj a na ten server ses připojil telepaticky...
    6.6.2023 04:28 J
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Je videt, ze jsi odbornik pres slepice ale do pocitacu a security by jsi mluvit nemel…
    5.6.2023 18:43 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Za neportovatelnost Scintilly si může autor sám, protože nechce normální dynamickou knihovna nezávislou na toolkitu.
    5.6.2023 07:55 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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í?

    5.6.2023 09:57 Ivan
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 5.6.2023 18:40 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    5.6.2023 10:36 plostenka | blog: plstnk
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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".
    5.6.2023 12:37 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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...
    5.6.2023 14:05 plostenka | blog: plstnk
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    5.6.2023 14:21 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Vendori jsou profesionalove, a udelat balicek je v porovnani s celym vyvojem malickost.
    Na základě jaké zkušenosti toto píšeš?
    5.6.2023 14:55 ~
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Vzdyt mas na to pajpu v jenkinsu ne? Jo pan je amater a o CI/CD nema ani paru co?
    5.6.2023 16:06 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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á.
    5.6.2023 18:17 pimprle
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    6.6.2023 07:28 plostenka | blog: plstnk
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Prebalovani (patchnutych) programu jako mutt nebo finch pro dev releasy Devuanu.
    xkucf03 avatar 5.6.2023 18:08 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    David Heidelberg avatar 3.6.2023 00:13 David Heidelberg | skóre: 46 | blog: blog_
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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)
    3.6.2023 06:02 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    A narozdíl do multimilionové společnosti jako Debian je Red Hat malá firmička, která ty balíky nezvládá vyrobit.
    Quando omni flunkus moritati
    3.6.2023 07:45 stabilita
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    3.6.2023 09:45 Luky
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Koncept dobry do roka a dna aj ubuntu core desktop bude cele v snapoch bez deb. Ja pouzivam kde sa da onlyoffice desktopeditors.
    3.6.2023 10:01 ________
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 3.6.2023 10:19 David Ježek | skóre: 83 | blog: Mostly_IMDB
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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).
    3.6.2023 11:27 raspberr
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Jako BSD vize muze mit, ale nema desktop takze o tom se v podstate nikto nema sanci neco dozvedet.
    3.6.2023 19:35 kuba77 | skóre: 15 | blog: kuba77
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Desktopové BSD tu jsou - GhostBSD, NomadBSD, HelloSystem, ravynOS... ale zmiňované PC-BSD už ne.
    3.6.2023 20:15 raspberr
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Sekce humor je pod komixem, ne tady. Jeste jednou - BSD Desktop neexistuje. Ty demoverze na uzce specifizovane mnozine obstarozniho hardwaru nikdo nebere vazne.
    4.6.2023 14:10
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Ty demoverze na uzce specifizovane mnozine obstarozniho hardwaru
    Máš na mysli Mac?
    4.6.2023 14:59 hefo
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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...
    4.6.2023 17:45 Arch3olog
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    To je nedorozumeni. macOS ma kernel Mach. Z BSD pouziva(l) jen network stack a par utilit.
    David Heidelberg avatar 4.6.2023 18:59 David Heidelberg | skóre: 46 | blog: blog_
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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...
    5.6.2023 18:49 koroptev
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    firmy?

    ty nic takoveho nezajima a delaji to pro web..
    David Heidelberg avatar 4.6.2023 18:58 David Heidelberg | skóre: 46 | blog: blog_
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    4.6.2023 23:19 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    Quando omni flunkus moritati
    Ruža Becelin avatar 3.6.2023 11:55 Ruža Becelin | skóre: 40 | blog: RuzaBecelinBlog
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    3.6.2023 21:49 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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ě...
    4.6.2023 01:46
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    5.6.2023 14:32 ________
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    3.6.2023 12:25 J
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Jako producent desktopoveho softveru bych se na linux vyprdnul, udrzovat 200 ruznych formatu distribuce softveru ne neudrzitelne. Linuxova komunita se neumi domluvit.
    AsciiWolf avatar 3.6.2023 14:34 AsciiWolf | skóre: 40 | blog: Blog
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    4.6.2023 15:56 ondra05
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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а avatar 4.6.2023 16:09 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    4.6.2023 17:47 m
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    komercni jsou v pohode, to nekdo totizi testuje, ne jak open bordel
    Jendа avatar 5.6.2023 00:00 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 4.6.2023 21:24 AsciiWolf | skóre: 40 | blog: Blog
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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а avatar 4.6.2023 23:59 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 6.6.2023 13:32 AsciiWolf | skóre: 40 | blog: Blog
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    3.6.2023 20:40 antinazi
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Co se do toho sere nacek. Co na to amerikanci. Redhat je prece americka firma, nebo ne?
    4.6.2023 00:45 J
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    4.6.2023 01:43
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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.
    4.6.2023 18:04 J
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 avatar 5.6.2023 10:51 skunkOS | skóre: 27 | blog: Tak nějak
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Zlatej Arch.
    http://martinrotter.github.io
    5.6.2023 12:52 zlatej gentoo
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Jo zlatej, updatne ti knihovnu ani nevis kdy a pulka veci jde do kytek :-) Arch tak na desktopove hrani ale na server ani nahodou.
    5.6.2023 13:36 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Co to je zas server, že na něm použíšá LibreOffice?

    (A jinak ano, Arch je desktopové distro.)
    5.6.2023 15:02 mandzare
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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 :-D Navic kdyz na tohle obdrzim odpoved tak nez ji napises tak ji jiste 3x prepises a aktualizujes, ze jo? :-D
    5.6.2023 16:11 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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íš...
    5.6.2023 18:20 Want
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Neanonym je nějaká kasta mudrců nebo co?
    5.6.2023 20:09 kralyk z abclinuxu | skóre: 29 | blog:
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    xkucf03 avatar 5.6.2023 17:55 xkucf03 | skóre: 49 | blog: xkucf03
    Rozbalit Rozbalit vše LibreOffice/OpenOffice na serveru
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
    5.6.2023 18:51 koroptev
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    no a co? na serverovym OS zadnej office balik neni potreba..
    Max avatar 5.6.2023 21:07 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    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
    Měl jsem sen ... :(
    Max avatar 5.6.2023 21:09 Max | skóre: 72 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    Knock, knock...
    Kdo tam?
    IBM.
    Zdar Max
    Měl jsem sen ... :(
    6.6.2023 01:56
    Rozbalit Rozbalit vše Re: Red Hat nebude spravovat RPM balíčky pro LibreOffice
    :-D

    Založit nové vláknoNahoru


    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.