Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
OpenBSD 5.5 vyjde 1. května. Oficiální píseň je už ale k dispozici. Nejnovější hudební hit z produkce OpenBSD je věnován problému roku 2038: Řekněte mi doktore, jaký bude rok, 1901 nebo 2038? OpenBSD 5.5 přijde s 64bitovým time_t na všech platformách. Píseň s názvem Wrap in Time lze stáhnout ve formátech MP3 a OGG.
Tiskni
Sdílej:
time_t
ať si upravjí, jak se jim zlíbí: pokud jim to nic nerozbije, tak proč ne...
Zoufalé. Kdyby raději přišli s kernelem bez Giant Locku. Na 64-bitový time_t
je čas, zatímco kernel s Giant Lockem do 21. století nepatří. Totéž platí o naprosto zastaralém zabezpečení.
OpenBSD's security model is more about -- as I phrase it -- keeping the bastards out, not controlling them (or hoping to control them) after they are in. Making life difficult for attackers once they get into your system is usually not going to be overly productive, and usually makes administration of the system much more difficult, which often creates NEW security problems of their own. While people like to talk about "Defense in depth" -- and it is not a bad idea -- your best goal is to keep the bastards on the outside of your systems, as once they are in, they can utilize anything you don't have perfectly bolted down to accomplish their goals (and yes, that statement puts me opposite a lot of people making a lot of money chasing down bad guys AFTER they inflitrate systems). In the Real World: First thing most people do on an SElinux system is disable SELinux. At that point, all the RBAC "features" are now just pure glossy advertising -- worthless. For fear of breaking things, the Linux people have chosen to put a big on-off switch on SELinux...and so given a choice between fixing applications and turning off the switch...people just turn off the switch. ANY claimed benefits of SELinux are ONLY there if it is enabled and used properly.
REAL security is not a list of features, even if used. The OS is just the tip of the security iceberg...or maybe more accurately, the base of it. You don't typically run an OS to run an OS. You run the OS to run applications, and if those applications are poorly written or poorly designed, there are limits to how much (if at all) the OS can help. The best OpenBSD can do is give you a good starting foundation.Par reakci na uvadeny "odborny" rozbor vedouci k nutnosti ACL v systemu: Sometimes the "add-on" security enhancements directly weaken system security ACL, SELinux velmi trefne
In the Real World: First thing most people do on an SElinux system is disable SELinux.
Tohle je nějaká fikce. Nikdy, ani jednou a ani omylem mě nenapadlo vypnout SELinux. Proč bych to dělal? To by pak opravdu zabezpečení spadlo skoro až na úroveň OpenBSD. Pokud někdo vypne SELinux, dobře mu tak.
Je vtipné, jak se advokáti OpenBSD zoufale snaží obhájit absenci klíčové funkcionality, která v moderním systému prostě má být, v ostatních BSD variantách většinou je a pouze OpenBSD ji ze zásady nemá. Nejhorší případ je ovšem ten Giant Lock. Je úplně jedno, že to tu a tam funguje dobře i s Giant Lockem. Na router s několika 10 Gb/s síťovkami to zkrátka nemusí stačit, přestože každý jiný systém s rozumným (tj. ne tak extrémně blokujícím) kernelem by totéž zvládl v pohodě.
Ono to SMP praci zvlada pomerne dost dobre, ze treba firewall vyuzije jedno CPU a I presto zvlada to na co jinde potrebuji hromadu CPU je na zamysleni v tech jinych projektech.
Tohle by chtělo odkaz na konkrétní benchmark, který to dokazuje, nebo zkrátka nějaké rozumné podklady pro taková tvrzení. SMP práci zvládá OpenBSD „dobře“ pouze v userspace. Jakmile dojde na cokoliv, co by měl dělat kernel, například složitější routování s fitrováním a s několika sítovými kartami, pokročilé souborové systémy (které OpenBSD nemá), použitelnou virtualizaci (kterou OpenBSD nemá) nebo softwarový RAID (který OpenBSD téměř nemá), v podstatě všechny ostatní systémy (Linux, FreeBSD, Illumos/OpenIndiana) natrhnou OpenBSD prdel už jen tím, že příslušnou funkcionalitu zkrátka mají, pokud ne přímo výkonem. Ovšem ani u toho výkonu bych si nebyl tak jistý, že má OpenBSD navrch a že je důvodem k zamyšlení pro ostatní projekty. Ještě jsem neviděl benchmark, ve kterém by OpenBSD porazilo Linux, ať už na jednoprocesoru nebo na SMP.
Nikdy, ani jednou a ani omylem mě nenapadlo vypnout SELinux.Co napadlo a nenapadlo tebe není úplně relevantní v tvrzení o "most people"
Na router s několika 10 Gb/s síťovkami to zkrátka nemusí stačit, přestože každý jiný systém s rozumným (tj. ne tak extrémně blokujícím) kernelem by totéž zvládl v pohodě.. U klientu bezi Cisca i vlastni routery nad OpenBSD a nezaznamenali jsme zatim zadne vykonnostni problemy ani pri zatezovych testech. Na extra vytizenych uzlech jsou Junpery, ale ten rozdil je v jednotkach procent.
Jasně, kdo má někde na půdě nebo ve sklepě starý jednoprocesor, ten asi ví, co „to“ dokáže.
Je obrovský rozdíl v tom, co stačí pro dané konkrétní nasazení a čeho lze v nejlepším případě na daném hardwaru dosáhnout. Mícháte tu nějak podivně obojí dohromady.
Jasně, údajně jste nezaznamenali výkonnostní problémy při nějakých blíže nedefinovaných zátěžových testech. A co z toho vyplývá? Řekl bych, že vůbec nic. Kdyby například výstupem toho zátěžového testu byl maximální dosažený throughput a OpenBSD by na stejném hardwaru dosáhlo výsledků srovnatelných s Linuxem, pak by celé tvrzení bylo relevantní pro tuto diskusi. Takhle to ale nedává smysl. Říkáte, že nějakému klientovi někdy někde stačilo OpenBSD. Vůbec neříkáte, jak jste síť testovali, jaký měla throughput, jestli se opravdu podařilo využít maximální dosažitelný bandwidth a tak dále.
Upřímně řečeno, jedna věc je jasná: Giant Lock vždy prohraje. Že OpenBSD někdy jednou někomu stačilo, tomu rád věřím, ale jakéhokoliv moderního hardware je pro něj škoda. Doba jednoprocesorů už je pryč.
If you think micro benchmarks are worth anything you have a micro
understanding of the problem. -- Marco Peereboom
The biggest flaw with all those great benchmark articles is that their
often flawed and the people behind them are biased to show whatever they
like to prove. In the end many of fefe's test programs did not actually
measure what he assumed they would. -- Claudio Jeker
In the end it boils down to measuring the different OS on the hardware
you will use for the task they should fullfill, nothing else matters in
the end.
A obrazek na zaver. Od Netflix, ktery ".... uses if_lagg in their CDN – 32% of North American Traffic flowing through driver based on trunk(4) . Interne pouzivaji FreeBSD, ktere ma v sobe i Dtrace, to vzniklo v Sun, jeho autor pak delal v Joyent kde to dost posunul pro SmartOS, Illumos a FreeBSD a ed presel do Netflix. Spoustu zajimaveho se deje a Google (ten uz 3 roky po sobe jako top), Facebook a dalsi velci hraci nejsou jen tak pro nic za nic sponzori OpenBSD static const char rnd_seed[] = "string to make the random number generator think it has entropy";
What a benchmark !!! Testing sci-fi instead of reality :D
Ale nekterym lidem to proste nevysvetlite. Kde chybi rozum, nahrazuji ho pocity a symboly, se kterymi by identifikovali svoje predstavy.
Btw. hlavne po udalostech z posledni doby nechapu jak nekdo dobrovolne nasadi SELinux. Jedine ze by si ho sam zauditoval, ale u tak komplexniho bazmeku to povazuju za prakticky nemozne. A pak jeste hlidat updaty.
m
. (strana 122 a dál) Tomuto lze zabránit buď volením m
náhodně (tento postup se již v praxi opakovaně neosvědčil) nebo použitím digestu podepisované zprávy jako m
(nebo jeho zamixováním do entropy poolu, což je nejspíš to, co se odstraněný kód snaží dělat - předpokládám, že dgst
je to, co jdeme podepisovat). To vede na deterministic dsa signature. Po aplikování diskutovaného patche podle mě hrozí leaknutí klíče skrze stejná m
, pokud se nepodaří dostatek entropie nasbírat odjinud.
Tomuto lze zabránit buď volením m náhodně (tento postup se již v praxi opakovaně neosvědčil)V obou případech šlo o chybu v PRNG. Nejsem znalec OpenBSD, ale myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.
nebo použitím digestu podepisované zprávy jako m (nebo jeho zamixováním do entropy poolu, což je nejspíš to, co se odstraněný kód snaží dělat - předpokládám, že dgst je to, co jdeme podepisovat).Je už sice skoro půlnoc, ale řekl bych, že mixováním dgst do m ztráciš právě tu náhodnost, proto ta úprava. Pokud nemáš dostatečnou entropii, jak ti pomůže zamíchat do ní známou hodnotu?
Nejsem znalec OpenBSD, ale myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.Nevěřím :)
Je už sice skoro půlnoc, ale řekl bych, že mixováním dgst do m ztráciš právě tu náhodnost, proto ta úprava. Pokud nemáš dostatečnou entropii, jak ti pomůže zamíchat do ní známou hodnotu?Jenže mně nejde o to, aby
m
byla náhodná, nepredikovatelná nebo tak něco - mně jde o to, aby byla pro každou různou zprávu jiná.
myslím, že veškeré jejich úpravy stojí právě na tom, že mají kvalitní a otestovaný PRNG.No, a já zase myslím, že veškeré jejich úpravy jsou k hovnu, protože podobným stylem se prostě nedá pracovat. K čemu mi bude forknutá knihovna, která spoléhá na specifické implementace něčeho v OpenBSD? Jako vyházet podporu všech OS, co se mi prostě nelíbí, a přepsat to tak, že to bude (možná) fungovat pouze v OS, který používá (když budu optimistický) tak pár desítek tisíc lidí, to je opravdu úžasný přístup k vylepšování něčeho, co má být univerzálně použitelné. No, hlavně že si TdR užil několika orgasmů při sepisování těch commit messages.
Ty dva odkazy na PRNG faily se týkají generování klíčů.Ne, ten bitcoinový je leak klíče přes podepsání dvou transakcí. Btw. zajímalo by mě, jestli měl Debianí bug taky vliv na DSA podepisování, moc se o tom nemluví.
RAND_seed is now DEPRECATEDTo bude slušnej matroš, patrně rovnou z Amstru.