Byla vydána nová stabilní verze 7.6 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 140. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 1.90.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.25.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
flatpak run --nofilesystem=home MyApp
) nebo trvale (flatpak override --nofilesystem=home MyApp
). Práva v manifestu jsou jen default, který si může uživatel upravit dle potřeby.
Kernel ABI != userspace ABIVe smyslu, ze "stable" distra neslibuji stabilni kernel ABI ale jen userspace ABI? Tohle je priklad, na ktery jsem narazil zrovna vcera, kdy slib stabilniho ABI nic neznamena. Pripady, kdy se neco podobneho povedlo klukum z flatpaku si budes muset najit sam (maji bugzillu pro runtimes?).
--device=dri
(doufám, že nekecám).
Pokud se ma aplikace spoustet po startu/ovladat pres init skripty, jak je toto vyreseno?Není vyřešeno. Pro takové aplikace není Flatpak určen.
/var/lib/flatpak
. To je daleko lepší situace než typické dilema AURisty, kdy WeirdAppA chce knihovnu libLegacyB která teď začala kolidovat s libNewVersionB, na které jako na potvoru závisí dalších patnáct balíčků a dokud to někdo nějak nevyřeší, nemohu instalovat aktualizace.
Pochopil jsem, že se ti koncept flatpaku nelíbí, okay, jak bys to tedy řešil ty?Dodrzovat ABI kompatibilitu. Pokud by mi abclinuxu nevracelo "413 Request Entity Too Large", tak bych vlozil jako prilohu build vimu, ktery pouziva dynamicke linkovani a bude fungovat na vsech normalnich distribucich od rhel5 po Ubuntu 17.10 - to znamena na vetsim mnozstvim distribuci nez flatpak. Navic diky tomu ze ma dynamicky linkovane libtinfo se i lepe integruje do systemu. Je mi jasne, ze to takto nefunguje pro gtk aplikace, protoze gnome "vyvojari" (narozdil od core knihoven) na to totalne kaslou. Sam mam takovou prihodu, kdy jsem resil velice neprijemny bug s gsettings v ubuntu. Resetovalo se nastaveni klavesovych zkratek po restartu. Tento bug tam vydrzel pres dva roky a minimalne jeden ubuntu maintainer o nem vedel, nastavil si workaround a neresil; po dvou letech me to nastvalo tak, ze jsem stravil tri dny v gdb a fixnul to za ne, ale ocenuji, ze pak aspon patch bez kecu prijali (na zaklade predchozich zkusenosti jsem patch ani nezkousel dostat do upstreamu gnome - to by proste vyhnilo v bugzille). Je mi jasne, ze naucit vyvojare s takovymto pristupem nerozbijet ABI je mimo realitu. Na druhou stranu, jine opravdove reseni neexistuje. Flatpak apod. jsou takove workaroundy, kde se povazuje za uspech, ze se aplikace povede spustit.
Ne, minimálně pro Flathub to je vyřešené tak, že do něj lze přidávat témata jako rozšíření runtimu.Jo to je presne ten "hack", ktery myslim, tzn. integrace nulova. Takze se nic nezmenilo, diky za info.
Neco jako treba:
# for LINE in $(rpm -qR httpd);do rpm -q --whatprovides $LINE; done | sort | uniq | grep -v "no package provides" apr-1.2.7-11.el5_6.5 apr-util-1.2.7-11.el5_5.2 bash-3.2-32.el5 chkconfig-1.3.30.2-2.el5 coreutils-5.97-34.0.1.el5_8.1 db4-4.3.29-10.el5_5.2 expat-1.95.8-11.el5_8 file-4.17-28 findutils-4.2.27-6.el5 gawk-3.1.5-16.el5 glibc-2.5-107 httpd-2.2.3-76.0.1.el5_9 initscripts-8.45.42-1.0.3.el5_8.1 libselinux-1.33.4-5.7.el5 mailcap-2.1.23-1.fc6 mktemp-1.5-24.el5 openldap-2.3.43-25.el5_8.1 openssl-0.9.8e-26.el5_9.1 pcre-6.6-6.el5_6.1 shadow-utils-4.0.17-21.el5 zlib-1.2.3-7.el5
Jsem si nevsiml ze by si to tahlo vsechny zavislosti sebou. A httpd je takova obvykla unixova aplikace pokud se nepletu. Instalace pres rpm/deb mi proste prijde k systemu cistejsi a obecne vzato i bezpecnejsi.
Co se klonování z gitu týče, jde uvést branch, tag i konkrétní commit, který se má použít.Aspoň, že tak.
Flatpak se IMHO nesnaží být "lepší balíčkovacím systémem" jako spíš rozumně kompromisní alternativou k nativním balíčkům. Jsem zvědavý, zda a kam se možnosti Flatpaku posunou.Obávám se, že nativní balíky budou postupně mizet. Tady je totiž problém v tom, že vytvořit správně balík třeba pro Debian není vůbec jednoduché a dostat ho do oficiálních repozitářů jakbysmet. Vývojáři ani uživatelé nechtějí čekat. Dnes se proto lze často setkat s „oficiálními“ upstream repozitáři (ať už provozovaných na vlastním serveru, nebo třeba jako PPA). To na první pohled vypadá jako dobré řešení, dokud není třeba řešit závislosti napříč těmito repozitáři. Balík foo z jednoho repozitáře může záviset na balíku bar z jiného repozitáře, který uživatel nemá přidaný. Konflikt pak musí vyřešit ručně on sám (v tomto případě nalezením a přidáním repozitáře, který obsahuje patřičný balík). V dlouhodobém horizontu se také můžou objevovat problémy se zanikajícími repozitáři. Nabízí se myšlenka, jestli by závislost neměla být specifikována jen jménem balíku, ale ještě zdrojem. To ovšem neřeší ty případné zanikající repozitáře. Nakonec by tedy asi bylo nejlepší něco jako IPFS, kdy balík bude specifikován jménem, verzí (viz dále) a nějakým podpisem – klasický checksum nelze použít, protože každá verze bude mít jiný. Co se týká verzí, bylo by ideální pevně odlišit verzi API od verze softwaru, nebo striktně dodržovat konvence. V praxi nevím, jaký konsenzus v případě schéma <major>.<minor>.<patch> panuje ohledně situací, kdy v rámci (security) bugfixu je nutné rozbít zpětnou kompatibilitu. Inkrementuje se jen patch a mávne se nad tím rukou s tím, že „správně napsané programy by to rozbít nemělo“? Takže by existoval jen jediný decentralizovaný repozitář (provozovaný např. na IPFS). Závislost by byla určená jménem balíku, podpisem, co nejméně restriktivní verzí (např. 1.2.*, pokud je garantováno, že API je stejné; alternativně lze také zavést další kvalifikátory, např. že patch musí být větší nebo roven nějaké hodnotě apod.) a dále referenční verzí, se kterou byl daný program původně testován. Pokud by v systémech existovalo cachování balíků (nebo způsob jak je rekonstruovat z instalovaných souborů a minimálních dat držených v cachi package manageru), šlo by za předpokladu, že by systémy byly do IPFS běžně zapojeny zajistit, že dokud lidé budou libovolný balík dané verze používat, bude k dispozici i ostatním. Referenční verze má spíše dokumentační význam: Pokud po upgradu nějaké knihovny přestane program fungovat, uživatel tuší, na jakou verzi by měl zkusit downgradovat (i třeba za cenu, že bude riskovat bezpečnostní zranitelnost – to už je jeho volba). Balíčkovací systém by s tímto případně mohl i automatizovaně pomoci. Prerekvizitou samozřejmě je, že balíčkovací systém bude umět držet více verzí stejně pojmenovaného balíku. Ostatně, v systému, který naznačuji, by název měl rovněž spíše dokumentační význam než cokoliv jiného. Závazný je spíše nějaký ten podpis. IPFS zmiňuji jen jako příklad, možná se na toto použití ani nehodí. Podstatná je ta myšlenka jednoho decentralizovaného depozitáře, ne konkrétní technické provedení.
215 text files. 215 unique files. 6 files ignored. github.com/AlDanial/cloc v 1.70 T=0.70 s (301.2 files/s, 26595.5 lines/s) ----------------------------------------------------------------------------------- Language files blank comment code ----------------------------------------------------------------------------------- C++ 88 2307 134 8636 C/C++ Header 100 1103 70 3633 Qt 20 0 0 2313 Prolog 1 22 0 270 Markdown 1 18 0 55 Windows Resource File 1 19 23 28 ----------------------------------------------------------------------------------- SUM: 211 3469 227 14935 -----------------------------------------------------------------------------------Takže kvůli cca 9k řádkům v C++ (dodám že to je počet který by Gentoo emerglo jedním příkazem snad dřív než by se ten Flatpak nainstaloval) bude sebou aplikace tahat co? Qwt, QT5, LEMNG, … GNUGMP? Pokrok prostě nezastavíš. Ještě by mě zajímalo kolik má kB vlastní binárka toho PeakMasteru a kolik vlastní balíček ve Flatpaku. Jako pro nějaké velké aplikace typu LibreOffice, GIMP (i když i ten mám přeložený svůj v několika verzích a přitom naprosto bez problémů) budiž, ale tohle kvůli nějakému grafickému bindingu na pár knihoven který by se hodil spíš do nějakého AppStoru?
Tiskni
Sdílej: