Uživatelé komunikátoru Signal si mohou svá data přímo v Signalu bezpečně zálohovat a v případě rozbití nebo ztráty telefonu následně na novém telefonu obnovit. Zálohování posledních 45 dnů je zdarma. Nad 45 dnů je zpoplatněno částkou 1,99 dolaru měsíčně.
Server Groklaw, zaměřený na kauzy jako právní spory SCO týkající se Linuxu, skončil před 12 lety, resp. doména stále existuje, ale web obsahuje spam propagující hazardní hry. LWN.net proto v úvodníku připomíná důležitost zachovávání komunitních zdrojů a upozorňuje, že Internet Archive je také jen jeden.
Jakub Vrána vydal Adminer ve verzi 5.4.0: "Delší dobu se v Admineru neobjevila žádná závažná chyba, tak jsem nemusel vydávat novou verzi, až počet změn hodně nabobtnal."
V Německu slavnostně uvedli do provozu (en) nejrychlejší počítač v Evropě. Superpočítač Jupiter se nachází ve výzkumném ústavu v Jülichu na západě země, podle německého kancléře Friedricha Merze otevírá nové možnosti pro trénování modelů umělé inteligence (AI) i pro vědecké simulace. Superpočítač Jupiter je nejrychlejší v Evropě a čtvrtý nejrychlejší na světě (TOP500). „Chceme, aby se z Německa stal národ umělé inteligence,“ uvedl na
… více »V Berlíně probíhá konference vývojářů a uživatelů desktopového prostředí KDE Plasma Akademy 2025. Při té příležitosti byla oznámena alfa verze nové linuxové distribuce KDE Linux.
Byl vydán Debian 13.1, tj. první opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.12, tj. dvanáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Evropská komise potrestala Google ze skupiny Alphabet pokutou 2,95 miliardy eur (71,9 miliardy Kč) za porušení antimonopolní legislativy. Podle EK, která mimo jiné plní funkci antimonopolního orgánu EU, se Google dopustil protisoutěžních praktik ve svém reklamním byznysu. Google v reakci uvedl, že rozhodnutí považuje za chybné a hodlá se proti němu odvolat. EK ve věci rozhodovala na základě stížnosti Evropské rady vydavatelů. Podle
… více »Podpora 32bitového Firefoxu pro Linux skončí v roce 2026. Poslední podporované 32bitové verze budou Firefox 144 a Firefox 140 s rozšířenou podporou, jehož podpora skončí v září 2026.
Společnost Raspberry Pi nově nabízí Raspberry Pi SSD s kapacitou 1 TB za 70 dolarů.
Microsoft BASIC pro mikroprocesor 6502 byl uvolněn jako open source. Zdrojový kód je k dispozici na GitHubu.
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:
rpmrebuild
, 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 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.
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