Nejnovější X.Org X server 21.1.17 a Xwayland 24.1.7 řeší 6 bezpečnostních chyb: CVE-2025-49175, CVE-2025-49176, CVE-2025-49177, CVE-2025-49178, CVE-2025-49179 a CVE-2025-49180. Nils Emmerich je nalezl koncem března a dnes publikoval detaily.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.4 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
UN Open Source Week 2025 probíhá tento týden v sídle Organizace spojených národů v New Yorku. Středeční a čtvrteční jednání bude možné sledovat na UN Web TV.
Byla vydána nová verze 2.50.0 distribuovaného systému správy verzí Git. Přispělo 98 vývojářů, z toho 35 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Infrastrukturu pro chatovací aplikaci Telegram provozuje člověk s vazbami na ruské zpravodajské služby. Upozorňují na to investigativní novináři z redakce iStories. „Vedneev dodává služby ruskému státu včetně jeho jaderného institutu nebo zpravodajské službě FSB,“ říká v podcastu Antivirus novinář Jan Cibulka. Uživatelům, kteří si chtějí své informace chránit, doporučuje Telegram vůbec nepoužívat, a raději zvolit jednu z alternativ, WhatsApp nebo Signal.
The Trump Organization spustila ve Spojených státech mobilní síť Trump Mobile s neomezeným tarifem The 47 Plan za 47,45 dolarů měsíčně a představila vlastní značku telefonů The T1 Phone s Androidem za 499 dolarů.
Vývojáři KiCadu se na svém blogu rozepsali o problémech KiCadu v desktopových prostředích nad Waylandem. KiCad běží, ale s významnými omezeními a problémy, které podstatně zhoršují uživatelský komfort a vývojáři je nedokážou vyřešit na úrovni KiCadu. Pro profesionální používání doporučují desktopová prostředí nad X11.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
[python] python.install = True python.install-dir = C:\somewhere [conan] conan.install = True conan.cache-settings = "some_parameter" ...Plus, že by byl rád, aby si uživatel mohl tvořit vlastní klíče (s těmi ale nebudeme nějak pracovat, prože je nebudeme znát). Viděli jsme v tom jasnou tečkovou notaci klíčů a navhli jsme to tak, abychom dodrželi předchozí požadovaný vzor, že uživatel si klíče bude dělat ve stejném formátu, jako je zbytek klíčů. Tedy že první část před tečkou je vždy oblast kam klíč patří (python.cokoliv patří k Pythonu, ...). Příklad uživatelských klíčů by tedy byl:
[python] python.install = True python.install-dir = C:\somewhere [conan] conan.install = True conan.cache-settings = "some_parameter" [user] user.some-key = "some_string" user.another-key = FalseProduct owner nám řekl, že to je totální blbost, že uživatel(é) chce klíče "totálně volné" a že nás s tím pošle do někam. Jeho varianta by tedy vypadala:
python.install = True python.install-dir = C:\somewhere conan.install = True conan.cache-settings = "some_parameter" some-key = "some_string" SOME_KEY = "another_value" cokoliv.jineho.klidne.s.teckou = False ANI_by-nevynucoval&povolené+znaky = "coz mi prijde trochu zvlastni"Nám je to v zásadě jedno, implementovat volné klíče není moc složité (i když variantu user.some.key už máme hotovou), jen nám přišlo fajn to trochu limitovat a třídit, dát tomu nějaký řád, aby to bylo přehlednější a aby bylo na první pohled poznat, který klíč je ten uživatelský a tím aby to trochu lépe zapadalo do celého formátu konfiguračního souboru (primárně TOML). Znovu říkám, jde o trivialitu, uživatelské klíče nejsou nic kritického, jen by mě zajímalo, jak se na to kouká více lidí. V zásadě o tom nechci rozvíjet diskusi, jen prosím, pokud se vám chce, tak zahlasujte v anketě.
Tiskni
Sdílej:
Jako první bych se zamyslel nad tím, jestli se vám opravdu chce znovuvynalézat a vyvíjet kolo a nepoužít už existující package manager, který ve windows je (winget), soukromé repozitáře AFAIK umí. Chápu, že si bez problémů umíte nadefinovat vlastnosti, které winget nemá, ale opravdu jsou tak bezpodmínečně nutné, že vyváží náklady na vývoj vlastního řešení i nevýhody jako že nejprve stejně budete muset nějak nainstalovat ten váš package manager?!
Co se týče formátu toho INI souboru, tak duplikovat jméno sekce v každé položce mi přijde jako nápad někoho, kdo místo pro uživatele píše ten software pro sebe a svojí potřebu onanovat nad formalismy...
Nám je to v zásadě jedno, implementovat volné klíče není moc složité (i když variantu user.some.key už máme hotovou), jen nám přišlo fajn to trochu limitovat a třídit, dát tomu nějaký řád, aby to bylo přehlednější a aby bylo na první pohled poznat, který klíč je ten uživatelský a tím aby to trochu lépe zapadalo do celého formátu konfiguračního souboru (primárně TOML).Nechápu. To je nějaký superset TOMLu?
sekce/klíč=hodnota
, místo klíč=hodnota
. K čemu je dobrá ta duplikace názvu sekcí do klíčů? Proč sekce/sekce.klíč=hodnota
? To už rovnou můžete používat .properties soubory nebo jiný formát podporující jen mapu klíč=hodnota
.
Pro naši firmu vyvíjíme interní software pro rychlejší instalaci některých programů (z těch známých je to např. Python nebo Conan, pak nějaké další interní). Představte si to jako takový interní package manager se speciálními požadavk
vidim tam windowsovovou cestu C:\, pro windows existuje ňákej takovej baličkovací manager chocolatey hele, python a conan tam v u nich repozitařích vidim hele, vyrobit vlastní baliček by asi jako taky mělo jít hele :O ;D
disclaimer: neznám to a nepouživám, k čemu taky když mužu mit poctivej apt třeba :D ;D