Portál AbcLinuxu, 7. května 2025 22:14
Diskuse byla administrátory uzamčena.
For developers, yes, this may be harder than making an AppImage. There will still be occasional bugs that crop up between library versions. There will still be occasional differences between distributions. These are things you can work around. It may be painful at first but it will be worth it: you will provide a much superior user experience by working around the issues with your users’ libraries rather than attempting to replace them.... no takže TL;DR si to maj vyžrat vývojáři, kteří mají investovat čas, energii a mentální zdraví do nekonečné série různých velmi zábavných nekompatibilit a chyb mezi X různými distribucemi, a když to neudělají, budou pranýřováni za technologicky "nečistý" přístup. IMO dokud bude tenhle přístup přetrvávat, nic se k lepšímu nezmění a FlatPaků, AppImagí atd. bude čím dál víc, i přesto že jsou to technicky hnusná řešení.
ten člověk víceméně pouze kritizuje a nenabízí žádné použitelné řešeníNeni za to placeny, pokud kritizuje neco v cem ma pravdu je pro vyvojare velmi cenne ovsem pokud se toho vhodne chopi. Neco podobneho udelal nedavno Linus a treba vyvojari KDE se toho chopili tak ze se snazili osetrit aby neslo pres Discovery odebrat pudu pod nohama. Ale mas pravdu je to jen o tom jestli si vyvojar dokaze sypat popel na svou hlavu, pokud by k tomu byl prokazatelny duvod. Nekdo treba nekdy prispel do nejakeho projektu a za to by pozdeji dostal horsi produkt nez mel, myslis ze pak mel duvod prispet znova? to by musel byt vul nebo fanatik
Neco podobneho udelal nedavno Linus a treba vyvojari KDE se toho chopili tak ze se snazili osetrit aby neslo pres Discovery odebrat pudu pod nohama.Tak zrovna Linus má na téma zprávičky podobný názor ...
Tahounem standardizace nikdy nebyl desktop, ale podnikové distribuce, pro něž desktop byl vždy okrajová záležitost.Ano, protože desktop, narozdíl od podnikových dister, nikdo nezaplatí.
Takže donést Qt a vzít systémové X knihovny nemusí být dobrá cesta. Ale když si doneseme i X knihovny, tak nemusí sedět proti stau akcelerací v jádře a driverech. Když se přidá závislost na integrovaném Python interpretru, tak se objeví další kartézský součin. Rozumná rovina řezu neexistuje.No jo no. Řešení by mohla být sada knihoven (což asi +- implikuje i balíčkovací systém) přenosná mezi distribucemi. Pak by stačilo tu integraci s distribucí vyřešit jednou a X aplikací by proti tomu mohlo linkovat etc. a nemusel by to řešit každej projekt samostatně. Něco takového tak trochu už dnes poskytuje balíčkovač Nix, tj. docela velkou sadu balíčků instalovatelnou na různých distrech, bohužel ale nemá vyřešenu tu integraci (a aplikace vyžadující GPU apod. jsou problém) a nevim, jak je na tom se zpětnou kompatibilitou. Takže možná by stačilo vzít Nix a vyřešit tyhle dvě věci.
No jo no. Řešení by mohla být sada knihoven (což asi +- implikuje i balíčkovací systém) přenosná mezi distribucemi. Pak by stačilo tu integraci s distribucí vyřešit jednou a X aplikací by proti tomu mohlo linkovat etc. a nemusel by to řešit každej projekt samostatně.Není to právě vlastnost Flatpaku a jeho runtime, který se aktualizuje pravidelně? Z něj pak mohu vycházet a na novější se přepnu až budu mít aplikaci odladěnou.
ten člověk víceméně pouze kritizuje a nenabízí žádné použitelné řešení+1
jsou to technicky hnusná řešeníTo je Tvůj názor.
Pak si balík vezmou do debianu a chodí mi, že balík vyřadí z distribude kvůli tomu, že se rozhodli přejmenovat balík, na které program závisí, ať si to prý opravím.
Od lidí z Debianu lze sice očekávat cokoliv (spousta z nich stále žije v roce 2000 s přístupem: "my jsme Debian, a ty si před náma sedni na prdel"), ale pokud tam máš nějaké (jmenné?) závyslosti, které by dávalo smysl řešit správně už v upstreamu, tak co jiného mají ty lidi dělat, než to do toho upstreamu reportovat? Většinou (s výjimkou Debianu, přirozeně) jsou lidé od distribucí celkem rozumní a jejich bugreporty mívají hlavu a patu.
Nevadí mi si program kompilovat ze zdrojáků, uživatelé mají smůlu. Balíčků se dočkají jednou za čas.
Tenhle přístup si můžeš dovolit buď pokud jsi a) totální autista, nebo b) pokud děláš SW pro úzkou skupinu geeků. Ham radio asi spadá pod b), ale i tak si i v kladných recenzích lidi stěžujou, že jim to na jejich strojích nešlo rozběhat. O "jednohvězdičkových" recenzích ani nemluvě...
Tak samozřejmě, dá se na to koukat i takto a v Debianu to tak asi i vidí.Nemyslim si... to mi přijde jako takové romantické vnímání, nejspíš na to prostě neměli čas...
Tak naposledy rozhodně měli čas na spoustu byrokratických požadavků, včetně nutnosti reakce člověka, co měsíce nereaguje na maily. Nebo požadavku na změnu .desktop souboru, co by rozbil buildy pro jiné distribuce, kde ten program roky funguje.
A to radši ani nezmiňuju, co si v Debianu navymejšleli při prvním pokusu, o kterej se tady trekker otírá...
Takhlen rozbite knihovny snad nikdo nepouziva.boost je docela používaná knihovna...
To je ovšem volba autora, že se rozhodne pro knihovnu, která s každou verzí mění ABI.Tím jsi asi chtěl říct, že máš rozepsanou knihovnu poskytující stejné fíčury, ale s lepší zpětnou kompatibilitou, a s ní pak půjdeš za tím autorem a navrhneš mu, že ji může použít, že? To je super, autor bude rád.
To je teoreticky hezké, ale prakticky to má problém, že autor vydá novou verzi, až když chce on. Kdežto uživatelé chtějí mít opravené knihovny nejlépe hned.Tohle je mýtus. Důvod, proč tohle distribuce můžou udělat, není ani tak shared linkování, ale hlavně to, že distribuce má 1) strojově čitelně specifikovaný dependence a 2) automatizovaný recept na sestavení toho SW. Tohle ale s moderními hipsterskými staticky linkovanými jazyky (typu Go, Rust) máš typicky už z v upstreamu, protože mají oficiální způsob, jak strojově čitelně specifikovat dependence (narozdíl od C/C++, který tohle ca. 2021 furt ještě nemá). Takže v případě FOSS softwaru můžeš mít poměrně hodně automatizovaný proces, který zareaguje na notifikaci o (kompatibilní) bezpečnostní aktualizaci depenendence a ten software sestaví, i když jeho autor zrovna spí nebo je někde na pláži... Další věc je, že ten shared-linking proces nefunguje moc pro věci, které se z podstaty shared-linkovat moc nedají, tj. např. silně generické knihovny (což je např. část toho zmiňovanýho boostu).
Tvůj mýtus ti vyvracet nebudu. Moje zkušenosti o tom, co je možné, co se skutečně dělá a proč se to dělá, říkají něco jiného.
K tvému snu o automatickém procesu: Kdyby závislost měla stabilní rozhraní, tak se především nic automaticky sestavovat nemusí, protože se ta závislost opraví jen jednou. A ne ve všech programech znovu a znovu.
Hipsterské staticky linkované jazyky vyrostli na skutečnosti, že z open source se stala komodita. Kdyby museli řešit kompatibilitu s proprietárními knihovnami tak, jako to bylo v případě Céčka před padesáti lety, tak po nich neštěkne ani pes, nebo budou umět dynamicky linkovat. Nejsou první, kdo má automatické sestavování. Perl ho měl dávno před nimi. Staticky linkované jazyky se používají především kvůli možnosti zamknout se konkrétní verzi závislosti. Automatický překlad je tomu nutnou podmínkou, protože najednou autor je si distribucí sám sobě.
Statické linkování je něco jako dockerový obraz. Akorát linkovaní je pod úrovní programu, kdežto obraz roste nad úroveň programu. Nebo se na to můžeš dívat tak, že statické linkování bundluje jen binární knihovny, kdežto obraz všechny soubory. Oboje v podstatě je o tom, kdo a jak to chce používat. Autor programu řekne, že statické linkování mu řeší jeho potřebu zamykat se na konkrétních verzích závislostí, co je uvnitř, nikoho nemá zajímat, a co je mimo jeho program, naopak nezajímá jeho. Autor dockerového obrazu zase bude tvrdit, že to řeší jeho potřebu zamykat se na konkrétních verzích programů uvnitř kontejneru, že co je uvnitř, nikdo nemá řešit, a obdobně že ho nezajímá, co je mimo jeho kontejner. Distribuce naopak pojímají všechny programy a knihovny jako koherentní celek, který prostě v dané verzi distribuce nemění rozhraní a komu se to nelíbí, ať použije jinou verzi distribuce.
Pro distribuce je dynamické linkování nutnost. Ony nemohou posílat uživateli s každou aktualizací stovky gigabajtů znovu a znovu. Povím ti vtipnou historku: Poslední dobou se při překladu statických molochů typu webový prohlížeč objevují problémy s překladem na 32bitových architekturách. Důvod je ten, že při linkování se všelijakými optimalizacemi a ladicími údaji nestačí 32bitový adresní prostor.
Kdyby závislost měla stabilní rozhraní, tak se především nic automaticky sestavovat nemusí, protože se ta závislost opraví jen jednou.Tohle funguje celkem dobře u něčeho jako
libpng nebo nějaká taková knihovna, na který závisí každej a jeho babička.
Jakmile to je ale něco míň profláklýho, tak se třeba taky stane, že aktuální verzi tý knihovny má Arch, RPM distra mají nějakou starou s aktualizací jednou za uherskej rok a Debian/Ubuntu to nevedou vůbec (nebo obráceně, to je jedno) ... no a pak celej tenhle model skřípe...
Dynamický a statický linkování se nevylučuje, můžeš třeba nalinkovat libpng dynamicky a tu druhou knihovnu staticky.
Nejsou první, kdo má automatické sestavování. Perl ho měl dávno před nimi.RIP
Autor programu řekne, že statické linkování mu řeší jeho potřebu zamykat se na konkrétních verzích závislostí, co je uvnitř, nikoho nemá zajímatTo je nepochopení. Zamknutí verze slouží k tomu, abys měl možnost sestavit program přesně stejným způsobem, jako to udělal autor/jeho build systém, je to takový certifikát "s timhle a timhle jsem to sestavil", ale nijak ti nebrání povýšit verzi kterýkoli závislosti na kompatibilní novější verzi a mělo by to fungovat (pokud autor knihovny není prase a nerozbil API v rozporu se SemVer nebo nějakým takovým standardem). Proto taky je lockfile typicky oddělěný od specifikace dependence. Oproti dynamickému linkování není o nic větší důvod, proč by tě nemělo zajímat, co je uvnitř, od toho to je open source a od toho jsou ty dependence čitelně specifikované... Mně naopak přijde, že ta transparence je lepší než u "tradičních" C/C++ věcí, tam kolikrát zjistit, na čem ta věc sakra závisí, je náročný; je to třeba napsané někde ve volném textu, místo verzí tam je třeba něco jako "fairly recent version of libfoo"... Sorry, ale to je hrůza. (Doufám, že mi teď někdo neřekne, že se mam podívat do distrobuce - na tyhle problémy jsem narážel např. právě když jsem se pro něco snažil vyrobit balíček.)
Pro distribuce je dynamické linkování nutnost. Ony nemohou posílat uživateli s každou aktualizací stovky gigabajtů znovu a znovu.Meh, jako jo, sice ty binárky jsou velký, ale stovky GB to fakt nejsou... A jak říkám, ty druhy linkování se dají kombinovat.
Povím ti vtipnou historku: Poslední dobou se při překladu statických molochů typu webový prohlížeč objevují problémy s překladem na 32bitových architekturách. Důvod je ten, že při linkování se všelijakými optimalizacemi a ladicími údaji nestačí 32bitový adresní prostor.Binárky pro 32b systému se dnes typicky cross-kompilují. (Ale souhlasim, že ty nároky na paměť jsou kolikrát celkem brutální.)
Ještě k tomuhle, ona taky ta "úspora" dynamickým linkováním může být záporná. Příklad:Pro distribuce je dynamické linkování nutnost. Ony nemohou posílat uživateli s každou aktualizací stovky gigabajtů znovu a znovu.Meh, jako jo, sice ty binárky jsou velký, ale stovky GB to fakt nejsou... A jak říkám, ty druhy linkování se dají kombinovat.
pandoc. Když u sebe zkusim nainstalovat pandoc, balíčkovací systém chce nasintalovat 131 balíčků haskell knihoven v celkové velikosti 430 MB. Staticky nalinkovaná binárka má 67MB.
Jasně, možná když pak nainstaluju pár dalších Haskell prográmů, tak by se to začlo vyplácet - tohle říká tradiční filosofie. Jenže otázka je, kolik bych jich musel nainstalovat a jestli to fakt udělám - myslim si, že nejspíš ne. Zkusil jsem pokusně nainstalovat ten dynamicky linkovanej pandoc a pak zkusit nainstalovat stack - sice to chce nainstalovat miň věcí než bez toho pandocu, ale i tak to chce dalších skoro 90 balíků a 100MB na disku. Dobře, nainstaluju stack a zkusim nainstalovat xmonad - chce dalších 5 balílů a 200MB na disku. To jsem na nějakejch 800MB. To je šílený.
V sumě; sdílený knihovny se vyplatí - z hlediska místa na disku, bezpečnosti i byrokracie / maintainer režie - až když tu knihovnu používá větší část SW.
Distribuce naopak pojímají všechny programy a knihovny jako koherentní celek, který prostě v dané verzi distribuce nemění rozhraní a komu se to nelíbí, ať použije jinou verzi distribuce.To zní jako Apple ekosystém
Gradle ci maven su proti peklu c++ prekladu neuveritelne inteligentne buildovacie tooly+1, Javu sice fakt nemusim, ale je náročné být v téhle oblasti tak špatný jako C/C++ ...
Také jsem toho názoru, že je potřeba udržet vývoj distribucí a je nutné mít i možnost provést bezpečnostní opravu knihovny pod aplikací bez update všechno, co na ní záleží. Docker je v pořádku pro distribuovaný runner z GitLabu, ale pro desktop je to buď jen prodloužení odkládání potřebných úprav na později nebo naopak způsob, jak předběhnout standardní výbavu distribucí a netestovat na nich.
Co se týče bezpečnosti, tak se mi také nelíbí sdílet svůj domovský adresář s nedůvěryhodnými aplikacemi jako je od počátku pandemie u nás na ČVUT nařízené sledování Temsů. Základní shlédnutí komentářů naštěstí chodí i pod Chromiem, ale i tak ta obluda mohla k mnoha mým datům, osobním, školním, firemním. Takže stejně jako autor, si myslím, že je potřeba takové aplikace a weby odstínit. Protože se zabývám spíš embedded tak jsem zvolil řešení, které podporovalo již PMDS-85 na jehož terminálech jsme se okolo roku 1988 hodně vyřádili.
Unixové systémy pro ochranu osobních údajů používají UID a oddělené domovské adresáře. Takže mám konto se samostatným přihlášením pro kritické bankovní operace a naopak další konta pro podřízené a nebezpečné aplikace, jako je Teams a i binárně stažený Telegram (k tomu sice zdrojový kód je, ale o zaručeném third party review stahovaného blobu nevím).
Aplikace spouštím přes tdesu, každý si jistě vybere správný ekvivalent pro svojí distribuci - gksudo, xdg-su, gksu, gnomesu, kdesu or beesu.
Založím pro uživatele "uziv" konto "uziv_res" pro omezený přístup. Do /etc/pam.d/su přidám řádky
+# Allow user uziv to substitute by user uziv_res
a mám lepší pocit, že obludě nenabízím vše. Má to nevýhodu, že pak soubory ke sdílení musím kopírovat do složky na příslušné konto, ale složku mám s takovými právy, aby k ní hlavní uživatel mohl. Zjednodušit si to lze symbolickými linkami ze svého účtu. Ještě to chce omezeným uživatelům přiřadit skupiny, aby nemohli koukat moc jinam a ohlídat, že můj adresář omezenému vstup nedovolí.
+auth [success=ignore default=1] pam_succeed_if.so user = uziv_res
+auth sufficient pam_succeed_if.so use_uid user = uziv
Ano, vím, že pokud zatím používám Xka, tak obludy mohou kdykoliv na klávesnici a udělat si screenshot jiného okénka, číst schránku atd... Ale toto oddělení nezabírá paměť duplikovanými sdílenými knihovnami a většinu blobů lze plně rozběhat proti nativním knihovnám. Doufám, že na to poslední vývojáři kvůli rádoby řešením s Flatpacky a Nixem a dalšími runtime duplikujícími technologiemi nezačnou zapomínat. (u Nixu si umím představit reálné usecase nebo jeho použití jako jednotnou distribuci)
Aplikace spouštím přes tdesu, každý si jistě vybere správný ekvivalent pro svojí distribuci - gksudo, xdg-su, gksu, gnomesu, kdesu or beesu.Nebylo by pohodlnější použít Firejail?
Ano, vím, že pokud zatím používám Xka, tak obludy mohou kdykoliv na klávesnici a udělat si screenshot jiného okénka, číst schránku atd... Ale toto oddělení nezabírá paměť duplikovanými sdílenými knihovnami a většinu blobů lze plně rozběhat proti nativním knihovnám. Doufám, že na to poslední vývojáři kvůli rádoby řešením s Flatpacky a Nixem a dalšími runtime duplikujícími technologiemi nezačnou zapomínat.Je to Flatpak, nikoliv Flatpack a neboj, vývojáři Flatpaků na to nezapomínají (X11 je u Flatpaku od začátku považován za legacy a insecure záležitost).
Ještě k tomu jak psát aplikace, trochu to opravdu bolí, ale i díky Suse to jde již celkem snadno https://build.opensuse.org/package/show/home:ppisa/qtmips. Ubuntu máme pod Launchpadem abychom pro jinou komerční firmu nezatěžovali Suse.
V současné době i za pomoci našich studentů máme v devel podporu i pro Qt6, s tím, že je udržená kompatibilita i pro Qt5 ve staré verzi na Ubuntu 18.
Myslím, že to je přístup, o kterém Nicholas Fraser hovoří.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.