FEX, tj. open source emulátor umožňující spouštět aplikace pro x86 a x86_64 na architektuře ARM64, byl vydán ve verzi 2512. Před pár dny FEX oslavil sedmé narozeniny. Hlavní vývojář FEXu Ryan Houdek v oznámení poděkoval společnosti Valve za podporu. Pierre-Loup Griffais z Valve, jeden z architektů stojících za SteamOS a Steam Deckem, v rozhovoru pro The Verge potvrdil, že FEX je od svého vzniku sponzorován společností Valve.
Byla vydána nová verze 2.24 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia online tabulky Proton Sheets v Proton Drive.
O víkendu (15:00 až 23:00) probíha EmacsConf 2025, tj. online konference vývojářů a uživatelů editoru GNU Emacs. Sledovat ji lze na stránkách konference. Záznamy budou k dispozici přímo z programu.
Provozovatel internetové encyklopedie Wikipedia jedná s velkými technologickými firmami o uzavření dohod podobných té, kterou má s Googlem. Snaží se tak zpeněžit rostoucí závislost firem zabývajících se umělou inteligencí (AI) na svém obsahu. Firmy využívají volně dostupná data z Wikipedie k trénování jazykových modelů, což zvyšuje náklady, které musí nezisková organizace provozující Wikipedii sama nést. Automatické programy
… více »Evropská komise obvinila síť 𝕏 z porušení unijních pravidel, konkrétně nařízení Evropské unie o digitálních službách (DSA). Vyměřila jí za to pokutu 120 milionů eur (2,9 miliardy Kč). Pokuta je podle názoru amerického ministra zahraničí útokem zahraničních vlád na americký lid. K pokutě se vyjádřil i americký viceprezident: „EU by měla podporovat svobodu projevu, a ne útočit na americké společnosti kvůli nesmyslům“.
Společnost Jolla spustila kampaň na podporu svého nového telefonu Jolla Phone se Sailfish OS. Dodání je plánováno na první polovinu příštího roku. Pokud bude alespoň 2 000 zájemců. Záloha na telefon je 99 €. Cena telefonu v rámci kampaně je 499 €.
Netflix kupuje Warner Bros. včetně jejích filmových a televizních studií HBO Max a HBO. Za 72 miliard dolarů (asi 1,5 bilionu korun).
V Las Vegas dnes končí pětidenní konference AWS re:Invent 2025. Společnost Amazon Web Services (AWS) na ní představila celou řadu novinek. Vypíchnout lze 192jádrový CPU Graviton5 nebo AI chip Trainium3.
Firma Proxmox vydala novou serverovou distribuci Datacenter Manager ve verzi 1.0 (poznámky k vydání). Podobně jako Virtual Environment, Mail Gateway či Backup Server je založená na Debianu, k němuž přidává integraci ZFS, webové administrační rozhraní a další. Datacenter Manager je určený ke správě instalací právě ostatních distribucí Proxmox.
, ale na ten se nepráš. Takže za mě volím DEB
určitě se to dá. Různou kombinací aptitude upgrade, dist-upgrade, install -f, odinstalací balíčků a podobně ... je to porod, ale většinou se povede.
můžete mi vysvětlit proč je rozbitý systém závislostí s DEB problém?
Je to proto, že APT není nijak zvlášť výkoný solver? Zazněl tady názor, že u RPM to takový problém nebývá, což mě vede k doměnce, že systém APT/DEB staví na perfektní propracovanosti vztahů mezi balíky a kdžy se něco pohnojí tak neví co s tím.
A proč je to problém pro Apt to vyřešit? Já to zažil asi 3x u rpm a solver mi dal na výběr jak to chci řešit, a prostě to dal dokupy. moc nerozumím tomu, jak seto může"rozbít" do stavu, že to nejde opravit.
problém bude v tom, že DeltaRPM používá IMHO pouze Suse a to jenom pro balíky z repozitáře "updates". Takže se jedná o tak málo dat, že je to výhoda jen na papíře.
Většinou se závisí na jaderných symbolech u kernelových modulů, nebo na nějakých so souborech v případě normálních binárek.
Zbytek závislostí nebývá většinou registrován automaticky. Nehledě na to, že se automatická registrace závislostí dá úplně vypnout
a proč teda řešení závisostí v opensuse je tak náročné a tahá s takové obrovské kvantum dat? Apt co se týče schopností řešit asi nebude žádná sláva, ale když se podívám na debian, tak se z internetu stahuje úplné minium. IMHO na Apt nejsou kladeny žádné výkonostní nároky, a velmi mu poháhá koncepce DEB balíků a repozitářů.
to je vše?
problém bude v tom, že DeltaRPM používá IMHO pouze Suse a to jenom pro balíky z repozitáře "updates". Takže se jedná o tak málo dat, že je to výhoda jen na papíře.
můžu mít OT:
Co používáš na serveru (pokud nějaký máš) ?
No testuju pro svůj komunitní server různé distribuce a rozhoduju se co na to nasadím. Zatím mi na každé něco nesedí. Co za verzi Opensuse tam máš a jsou nějaké problémy se serverovým nasazením?
používáš dm RAID? a které partitions?
DM raid ? Proboha proč ? To je jenom zoufalý způsob, jak se dostat k datům na Windows-only fake RAIDu.
Proč nepoužít léty ověřený softwarový RAID (md) ?
ebuild ......
Radsi nepouzivam distribuci rizene zavislosti.... nikdy jsem s nimi nesouhlasil a veskery soft si kontroluju podle sveho.... (ale je pravda ze instaluju jen na jeden pocitac)
Kdy už vám dojde, že je úplně jedno, jestli to je DEB nebo RPM, že záleží jenom na tom, jestli se ten balík udělá dobře nebo špatně ?
Ani RPM, ani DEB nechybí žádná kritická vlastnost, která by zabraňovala vytvořit dobrý balíček, který bude radost instalovat. Já používám RPM distribuci, vytvářím RPM balíky, s DEB moc zkušeností nemám, ale nedovolil bych si tvrdit, že je horší než RPM. Je prostě jiný.
Nezáleží na tom čím se to udělá, ale jak se to udělá.
Mě šlo spíše o stav, kdy RPM má spoustu repozitářů, a když si jich člověk přidá tolik kolik potřebuje, tak jsou mnohdy v konfliktu. DEB mívá jeden velký a občas nějaký doplněk.
Ale to nemá nic společného s RPM nebo DEB. Moje distro třeba používá RPM a má jeden jediný repozitář s různými sekcemi.
Určitě existují i DEB distribuce, které mají spoustu repozitářů. Nezáleží na formátu balíčků, záleží na distribuci.
Máte naprostou pravdu. Formát balíčku je podružná záležitost, důležitá je *kvalita* balíčků (aktuálnost balíčků, závislosti, patch politika, možnost paticipace, build service, contrib repoziáře, korektní popisky, smyslupné pojmenovávání a třídění,..).
Já bych si dokonce dovolil tvrdit, že rpm a deb svými vlastnostmi z pohledu uživatele moc neliší. Pravda, deb má například suggested packages (něco jako nepovinné závislosti) ale to by asi nebyl problém doimplementovat do rpm a tak to bude podobně s osotatními drobnými featurami.
Skoro zbytečný luxus mít dva tak velmi podobné formáty pro binární distribuce.
Pravda, deb má například suggested packages (něco jako nepovinné závislosti) ale to by asi nebyl problém doimplementovat do rpm a tak to bude podobně s osotatními drobnými featurami.Ale to v RPM je samozřejmě také... minimálně v tom susím.
Vida jak se to vše vyvíjí že to ani nestačí jeden sledovat! Jakou verzi RPM má Suse? 4.x nebo 5? Podporuje tuhle vlastnost nějaký klient, Yast? Něco ve smyslu kliknu na balíček A a nabídne mi to, že by možná bylo přínosné nainstalovat i B, C a D ať si vyberu které? Synaptic a Apt (pro RPM) tedy ne (PCLinux a hádám ani Mandriva).
marek@ww010757:~> rpm -qv rpm rpm-4.4.2.3-20.3 marek@ww010757:~>
apt v PCLOSu navrhované balíčky nabídne (zmíní se o nich), v Synapticu je volba "Instalovat automaticky navrhované balíky", ale aby to bylo funkční, musel jsem ho trochu upravit.
Jiná věc je, že v repozitáři není jediný balíček, který by obsahoval tagy "Suggests" nebo "Recommends".
Když je tu už taková pěkná diskuze o balíčcích, tak se zeptám. Používám Ubuntu a když si nainstaluji nějaký program, tak si zjistí podle závislostí, co je zapotřebí a nainstaluje to. Problém je v odinstalování. Odinstaluje se jen program, ale ostatní knihovny (které už nepotřebuju) tam zůstávají. Dá se s tím něco dělat?
autoremove
autoremove is used to remove packages that were automatically installed to satisfy dependencies for some package and that
are no more needed.
deborphan, viz uryvek z jeho man stranky:
deborphan finds packages that have no packages depending on them. The default operation is to search only within the libs and oldlibs sections to hunt down unused libraries.Vetsinou staci pouzit
apt-get delete `deborphan` a je to.
remove, ne delete
dpkg -l | awk '$1 == "rc" {print $2 " purge"}' | dpkg --set-selections
Samozřejmě
Jestli jsem to správně pochopil tak vy i někteří komentátoři vyzdvyhujete minimalistické závislosti jako výhodu. Opravdu je tomu tak?
Ponechám stranou technicky nesprávné tvrzení, že samotný deb systém nějak ovlivňuje jestli bude mít bohaté nebo minimalistické závislosti, budu to číst jako „správci repozitářů distibucí založených na systému DEB inklinují spíše k minimalistickým závislostem“ s tímto výrokem už souhlasit lze.
A teď k pointě. Minimalistické závislosti ale nemusí být výhodou! Příklad z nedávné
Updatoval jsem u kamaráda nedávno jeho Knoppix, což je distribuce založená na deb a používající balíčky z Debianu. Nebyl čas updatovat všechno hromadně, tak jsem zvolil jen pár balíčků co jsme v tu chvíli potřebovali, mezi nimi i udev a dbus. Bohužel jsem zapomněl na hal. Po rebootu okamžitě pád do příkazové řádky, skoro nic nenaběhlo, zejména ne desktop a internet. Stará verze halu zjevně nespolupracovala s novějším udev a-nebo dbus. Užil jsem si pernou hodinu vzpomínání na ruční příkazy k nahození wireless internetu a práce s apt. Pak ještě ten detail najít co to vlastně způsobilo, naštěstí jak mnoholetý uživatel internetu mě hal napadl poměrně záhy. Pro začátečníka nebo méně poročilého by tohle byl konec a linux by se asi stěhoval z disku úplně.
Nevím, jestli to byl jen bug Knoppixu a tu závislost tam jen zapoměli, chyba se může stát každému v každé distribuci, ale po zběžném prozkoumání několika dalších balíčků Knoppixu bych skoro řekl, že je to projev systematické politiky této distribuce.
Závislosti mají být hlavně *správně*, tj. všechny potřebné aby se neopakovala situace výše popsaná.
Osobně zastávám názor, že raději o něco víc než míň, v dnešní době disků o stovkách GB nemá cenu meditovat nad několika možná zbytečně ztacenými MB. Můj čas je mnohem dražší než místo na mém disku. Programy i tak zaberou jen zlomek toho co data, zvlášť pokud pracujete s fotkami nebo videem.
Nebyl čas updatovat všechno hromadně, tak jsem zvolil jen pár balíčků co jsme v tu chvíli potřebovali, mezi nimi i udev a dbus. Bohužel jsem zapomněl na hal.Tak tohle je pochopitelně bug... Pokud daná aplikace nefunguje se svými závislostmi, pak je problém u maintainera... Pokud to takhle Knoppix dělá všude, tak Debian ne...
A co klasika tar.gz, tar.bz2, ...?
V poslední době narážím u některých aplikací na problém, že jejich zdrojové kódy jsou poskytovány pouze jako zdrojový rpm nebo deb balíček. Klasika jako tar.gz je zcela ignorována. Proč si mám doinstalovávat rpm, deb nebo další pomocné nástroje jenom proto, abych se dostal ke zdrojovým kódům? Samozřejmě to platí i u binárních archivů. Závislosti může pohlídat nejenom rpm nebo deb. Například sorcery.
Je to od nich ošklivé, ale v SRPM ten tar.gz uvnitř nakonec je, a aby ses k němu dostal, postačí ti jednoduchá utilitka jako rpm2cpio. I tak je to opruz, ale kdyby všechno mělo takhle jednoduché řešení ...
jako zdrojový rpm nebo deb balíček. Klasika jako tar.gz je zcela ignorována.Jen pro zajímavost. Co je poskytováno pouze jako zdrojový rpm, nebo deb balíček? Tu první variantu si dokážu představit, protože rpm2cpio je potřeba, ale u zdrojového Debianího balíčku snad žádné zpeciální nástroje potřeba nejsou, ne?
Co je poskytováno pouze jako zdrojový rpm, nebo deb balíček?Zdrojový DEB balíček? To někdo na světě používá? Debian odjakživa zdrojáky distribuuje jako .tar.gz + diff + dsc.
Tiskni
Sdílej: