Organizace IuRe (Iuridicum Remedium) varuje před návrhem, který představilo belgické předsednictví Rady EU. Populární služby jako Messenger, WhatsApp nebo Signal by dle něj bylo možné plně používat až po odsouhlasení kontroly komunikace. Ta by měla zamezit šíření dětské pornografie. Podle IuRe by však taková kontrola přinesla hlavně závažný dopad na soukromí uživatelů.
NumPy (Wikipedie), tj. knihovna pro Python pro vědecké výpočty, byla po 18 letech vydána v nové major verzi 2.0.0. Přehled novinek v poznámkách k vydání. Důležité informace v průvodci migrací.
Vývojáři postmarketOS vydali verzi 24.06 tohoto před sedmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, KDE Plasma a Sxmo. Aktuálně podporovaných zařízení je 50.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Google Blog ČR informuje, že mobilní aplikaci Gemini a NotebookLM lze používat už také v Česku.
Byla vydána nová major verze 8 duálně licencovaného open source frameworku JUCE (Wikipedie, GitHub) pro vývoj multiplatformních audio aplikací.
Od 18. června bude možné předobjednat notebook DC-ROMA RISC-V LAPTOP II od společnosti DeepComputing s osmijádrovým 64-bit RISC-V AI CPU a s předinstalovaným Ubuntu.
Byla vydána verze 1.79.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Byly zveřejněny výsledky průzkumu (infografika) mezi uživateli FreeBSD.
Na konferenci DevConf.CZ 2024 je na stánku Furi Labs prezentován linuxový telefon FuriPhone FLX1. Jeho cena 499 dolarů.
Andrew McCall se v editoriálu na freshmeat.net pustil do autoconf utilit, které jsou používány distributory naprosté většiny zdrojového kódu na *nixových systémech.
V úvodu demonstruje nepraktičnost tohoto build systému úsměvným příběhem
o běžném, přiměřeně zdatném uživateli Linuxu, který se snaží prokousat
zdánlivě banální procedurou ./configure && make && make
install
. Naráží přitom na hromadu problémů, které je nutno řešit,
aby se člověk dopracoval kýženého výsledku - totiž zkompilovaného,
funkčního a nainstalovaného programu. Je sice pravda, že s některým z
popisovaných zádrhelů se pravděpodobně většina z nás také setkala, ale na
druhou stranu je také fakt, že Andrewův fiktivní uživatel působí malinko
natvrdlým dojmem. To však prvním několika odstavcům neubírá na
vtipnosti.
Pak se dozvíme, v čem podle autora tkví problém pro samotné vývojáře. Protože autoconf používá pro sestavování configure skriptů makro procesor m4, tak chcete-li opravdu porozumět tomu, co se pod kapotou děje, je třeba se v m4 orientovat. A to prý není žádná sranda. Říkám "prý", protože já sám takové ambice vůbec nemám, takže nemohu soudit.
Nakonec Andrew načrtne, proč si myslí, že v celém systému vládne takový zmatek (alespoň on to tak vidí...). Jádrem pudla jsou Makefiles. Abychom se předlouhých a komplikovaných Makefilů zbavili, je nutno nalézt efektivnější způsob řízení celého build procesu. Několik "řešení" také nabízí (SCons, CONS, A-A-P). Je si sice vědom jejich nedostatků (např. mizivé portability), ale soudí, že za pokus by jejich masovější rozšíření stálo.
Neméně zajímavé čtení nabízí kopec odpovědí na hlavní článek. Mohli bychom je rozdělit do dvou hlavních skupin. Převládají ti, kteří s Andrewem více méně souhlasí a také si stěžují na všelijaké zákeřnosti, které jim autoconf/automake, apod. provedly. Druhou partu tvoří názory těch, kdo sice netvrdí, že autoconf je dokonalost sama, ale že:
a) Nemáme nic, co by tomuto řešení sahalo alespoň po kotníky.
b) Kdyby se autor a ostatní trochu snažili se něco přiučit, poznali
by, jak silný nástroj to mají v rukou.
Článek najdete zde.
Již v lednu tohoto roku vyšel na serveru kuro5hin.org krátký článek o využití komprimačního algoritmu gzip pro identifikaci spamu. Nenajdete v něm žádná převratná zjištění, přesto je však myšlenka zajímavá.
LZ (Zip) a příbuzné kompresní algoritmy (gzip) v textu hledají opakované výskyty částí slov, celých slov nebo i frází. Každý takový opakovaný výskyt je nahrazen odkazem na první. Čím více se v textu nalézá totožných prvků, tím lepší poměr komprese získáme.
Této techniky lze využít ke zjištění podobnosti dvou různých textů. Tyto dva texty spojíme, zkomprimujeme a podle dosaženého kompresního poměru můžeme posoudit jejich podobnost. Je samozřejmé, že chceme-li mít možnost získanou informaci vyhodnotit, potřebujeme pro srovnání provést stejný pokus, při kterém jeden z textů nahradíme za jiný.
V případě identifikace spamu tedy postupujeme následovně: připravíme si blok textu, který lze považovat za jasný spam. Stejně tak vytvoříme "šablonu" pro ne-spam. Autor postupoval tak, že si opatřil příklady spamu a ne-spamu z archívu SpamAssassinu. Z takto získaných emailových zpráv odstranil hlavičky a sloučil je do souborů o velikosti mezi 1 a 2 megabajty. Posledním krokem je samotné porovnání. V článku je vyřešeno jednoduchými příkazy:
cat spam.txt text-nove-zpravy.txt |gzip - |wc -c
cat ne-spam.txt text-nove-zpravy.txt |gzip - |wc -c
Ačkoliv výsledky potvrdily hypotézu, že kombinace spamu a ne-spamu bude mít horší kompresní poměr (a naopak), nelze takový postup určitě považovat za odpověď na problém spamu. Nicméně v kombinaci s dosud používanými metodami (které využívají počítání slov a přidělují jim různou statistickou významnost) by tento nápad mohl zlepšit účinnost dostupných filtrů. Přečtěte si původní článek.
Na serveru LinuxWorld.com vyšel rozsáhlý čtyřdílný seriál zabývající se instalací software na Linuxu. Z nadpisu je patrné, že autor, Nicholas Petreley, se stávající situací není moc spokojený. Postupně proto vymezuje výhody a nevýhody balíčkového přístupu a nakonec se i snaží o navrhnutí změn, které by dané problémy mohly řešit.
Přestože spousta uživatelů by jistě pohotově vyzdvihla a na příkladech doložila, kterak jsou balíčky právě té jejich distribuce odpovědí na nářky ostatních (musím se přemáhat, abych sem sám nenapsal, jak je ta "moje" distribuce nejlepší...), Nicholas tvrdí, že žádný z již existujících systémů prosazovat nechce. Žádný není tak jednoduchý a bezchybný, jak by si představoval.
Jednotlivé díly se zabývají následujícími věcmi:
Přečtěte si celý seriál zde.
Opravdu se nenajde nikdo, kdo by se chtěl spolupodílet na vzniku těchto článků?
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Diskuse byla administrátory uzamčena