Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Rád bych se zeptal na jednu věc. Zajímalo by mě, který model distribuce softwaru pro Linux je výhodnější a v čem? Mé laické postřehy bych shrnul asi takto. Distribuce s RPM balíky mají většinou menší repozitáře, a větší počet repozitářů. Kvůli závislostem nejen na balících, ale i na souborech se s rozšiřováním softwarové zásoby zvyšuje i počet konfliktů, protože repozitáře nejsou vždy plně kompatibilní a závislost na samostatných souborech tomu taky moc nepřidá. Distibuce s DEB balíky mají většinou obrovské jednotné repozitáře a nemají závislost na souborech. Pokud už je nějaký externí repozitář, většinou je ve 100% souladu a člověk konflikty řešit nemusí. Je skutečně pravda, že s DEB distry má člověk jednodušší správu softwaru a mnohem větší výběr balíků?
Tiskni
Sdílej:
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.