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.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
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.
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: