Nejnovější X.Org X server 21.1.25 a Xwayland 24.1.14 řeší 12 bezpečnostních chyb.
Google Chrome 155 byl prohlášen za stabilní. Přináší podporu JPEG XL (.jxl). Opraveno bylo 247 bezpečnostních chyb.
Konference OpenAlt 2026 hledá přednášející. Přihlásit přednášky lze do neděle 11. října. Konference proběhne o víkendu 7. a 8. listopadu na půdě Fakulty informačních technologií VUT v Brně. Témata konference jsou: Otevřený a svobodný software, IoT a Hnutí tvůrců, Vzdělávání, Bezpečnost a soukromí, Otevřená společnost, komunity a data, OpenMobility a další.
Byla vydána nová verze 10.6 sady aplikací pro SSH komunikaci OpenSSH. Přináší řadu důležitých bezpečnostních oprav, vylepšení funkcí a oprav chyb. Povoluje hybridní postkvantový podpisový algoritmus ssh-mldsa44-ed25519.
Americká společnost Reflection AI světu představila Beam, open-weight model s 501 miliardami parametrů (z toho 23 miliard aktivních), určený především pro programování a práci autonomních agentů. Podle autorů jejich model nabízí výkon srovnatelný s většími modely při výrazně nižších nárocích na výpočetní výkon. Beam nyní ještě prochází závěrečným testováním, na stránkách Reflection AI se však lze zaregistrovat a získat předběžný přístup. Váhy modelu, dokumentace a nástroje pro vývojáře mají být zveřejněny v průběhu tohoto měsíce.
OpenCourant je komunitní fork OpenRadioss, tj. open source softwaru pro simulace havárií, nárazů a vysoce nelineárních dynamických dějů metodou konečných prvků. Společnost Siemens v loňském roce dokončila akvizici společnosti Altair Engineering, jež před čtyřmi lety uvolnila open source verzi OpenRadioss svého proprietárního softwaru Radioss. Minulý týden Siemens OpenRadioss pohřbil. Integroval jej do svého softwaru Simcenter, webovou stránku OpenRadioss přesměroval na Simcenter a repozitář OpenRadioss na GitHubu odstranil.
Pořadatelé devátého ročníku komunitního setkání správců nejen českých a slovenských sítí – CSNOG 2027, které se uskuteční 20. a 21. ledna, vyhlásili Call for Abstracts. Náměty na vystoupení mohou zájemci přihlašovat do 31. října na webu akce a vybírat mohou ze tří sekcí – správa sítí, legislativa a regulace a akademické projekty. Zveřejněny byly také Call of Partners určené sponzorům a partnerům setkání, kteří by například chtěli mít na
… více »Strata je open-source inferenční engine, který umožňuje lokálně provozovat rozsáhlý čínský model Qwen3.8-Flash-Next, který by jinak nejspíše vyžadoval serverovou infrastrukturu, na běžném herním počítači s alespoň 12 GB VRAM, 32 GB RAM a dostatkem místa na SSD. Nároky na paměť a rychlost generování se liší s použitou variantou modelu Qwen. Zdrojový kód je dostupný na GitHubu, pod licencí MIT.
Americký prezident Donald Trump oznámil vznik federální Jednotky pro superinteligenci (Super Intelligence Force), která má koordinovat postup vlády, technologických firem, náboženských organizací a dalších institucí v oblasti rychle se rozvíjející umělé inteligence (Trumpem oficiálně nazývanou superinteligencí). SIF, podřízená přímo Trumpovi, má pomoci Spojeným státům udržet v oblasti SI technologický náskok nad světem a
… více »Klient je e-mailový klient pro GNOME s nativní podporou Proton Mailu, PGP a spamfiltrem řízeným AI. Napsaný je v Go s GTK4 a libadwaita. Připojuje se přímo k Proton Mailu (bez Proton Bridge), ke Gmailu, k Seznam.cz a k libovolné schránce IMAP/SMTP. Každou novou zprávu nejdřív posoudí spamfiltr a teprve potom ji ukáže a ohlásí. Rozhraní je česky a anglicky.
Ohledně balíčkovacích systémů jsem tzv pole neorané. Přečetl jsem si tisíc flamů po internetu, desítky popisů v encyklopediích a různých wiki, ale odpověď na mou otázku jsem nedostal. Dnes jsem narazil na tento slade: RPM benefits
Jako uživatel suse a ubuntu znám rpm a deb pouze z uživatelského hlediska. Porovnám-li ubuntu/deb a suse/rpm, pak jedine prakticke závěry, ktere jsem schopen vyvodit jsou, ze v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.
Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm. Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva. Což je další výoda pro deb.
Jedina vyhoda, kterou jsem u rpm zaznamenal je delta-rpm, ovšem to je asi susí specialitka, mimo to update suse je i tak mnohem zdlouhavejší nez update ubuntu.
Zajímalo by mě tedy, v čem jsou takové výhody rpm, že jej využívá mnohem více distribucí než deb?
Asi jsem natvrdlý, neb mi to nějak nedochází, a nebo je to absencí praxe, kterou ovšem nevyčtu po manuálech.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czrpmrebuild, ale používá na to /usr/bin/build
2. Pokud dojde k problému při x86_64 s přeinstalováním půlky systému tak je to prostě na bugzillu.
3. To že v závislostech debianích balíčků by byl menčí bordel kvůli tomu, že by záviseli jen na balíčcích samotných je pěkná hloupost 
Výhoda debianu je v tom, že má policy takové jaké má a tedy, že v jeho repositářích může růst každý balíček a nedochází tam tak k situacím jako například v openSUSE, kdy polovina balíčků roste v Packmanovi, který neumí při změně závislosti libA přebuildit všechny aplikace které na libA závisí. Proto musí aktualizace hlídat balíkáři, kdyby byly ty balíčky součástí distribuce, tak by si to ohlídal autobuild a balíčky by tak byly konzistentní. A ani závislosti jen na balíčcích k ničemu nepomůžou... Mimochodem ono se to automatické registrování závislostí dá vypnout a pak to může být přesně jako v debianu... 
v deb balíčcích je menší bordel, protože závisí jen na balíčcích a z toho taky vyplývá, že musí balíčkovač stahovat méně dat a celý proces není tak náročný na solver. - výhoda pro deb.Na druhou stranu možnost souborových závislostí zase zjednodušuje práci vývojáře. Výhoda není tak jednoznačná na jedné ani druhé straně.
Dalším postřehem je, že v rpm/suse lze mixovat i586 a x86-64 baliky, a kdyz je v zavislosti nejaky problem, balíčkovač je schopen navrhovat výměnu půlky systému z x86-68 na i586 bez mrknuti oka. deb/ubuntu se na i586 a AMD64 díva jako na rozdilné architektury a běžně balíčky nemichá (pouze na vyslovne vynuceni adminem přes dpkg). Takže pouze 32bit baliky jako wine maji baliček pro i586 a AMD64 v ubuntu zvlášť v suse stačí jeden. Což je dalsi vyhoda pro deb.Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.
V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.Já jsem četl pravý opak. Sám dělám ale pouze RPM balíčky, takže nemůžu srovnávat.
Nebudu hodnotit strukturu balíku, neb tomu nerozumím, ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.Ne, žádná taková potřeba neexistuje, to by byla pitomost.
Mně přijde jako výhoda mít systém 64bitový a v něm bez problémů pár 32bitových balíčků, u kterých je to potřeba. Čili spíš výhoda pro RPM.Ony ty nejpoužívanější 32bit balíky mají verzi pro architekturu AMD64. Rozdíl je IMHO v tom, že Debian udělá změnu AMD64->i586 pouze na výslovné přání uživatele. RPM distro tu změnu na výslovné přání neudělá. Výsledek je de-facto stejný, jen mi přijde, že RPM musím kvůli tomu více hlídat pokaždé, když něco instaluju.
ale potřeba cpát před zabalením data do /usr/.../Redhat složky mi přijde nejen absurdní, ale i nepraktická, protože k tomu potřebu administrátorská práva.To je naopak velmi nedoporučované. Vše v RPM samozřejmě závisí na uživatelském nastavení, žádné takové "absolutní povinné cesty" neexistují.
V diskuzích jsem se dočetl, že tvorba deb balíčku je mnohem prehlednejsi nez tvorba rpm.Nevím, ve vytváření deb balíčků se nevyznám. Nicméně k vytvoření RPM vám stačí jeden .spec soubor (něco jako recept na sestavení) a jeden soubor se zdrojovými kódy (tarball). To mi připadá velmi přehledné.
Je třeba mít na paměti, že množina distribucí používajících RPM je značně heterogenní. DEB balíčky byly donedávna výsostnou doménou Debianu, to spoustu věcí zjednodušuje. K výhodám RPM: co třeba rollbacks ? To se může docela hodit.
22.9.2008 15:35
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
22.9.2008 21:46
belisarivs | skóre: 22
| blog: Psychobláboly
Mne na rpm chybi urovne zavislosti jako v Deb. Cili neco jako - depends, recommends, suggests.Škoda, že máme každý jiné suse :D Software Management/Dependencies
23.9.2008 10:03
belisarivs | skóre: 22
| blog: Psychobláboly
22.9.2008 14:22
22.9.2008 14:38
23.9.2008 08:23