SolveSpace (Wikipedie), tj. multiplatformní open source parametrický 2D/3D CAD, byl vydán v nové verzi 3.2. Přehled novinek v Changelogu na GitHubu. Vyzkoušet lze novou oficiální webovou verzi.
Organizátoři Dne IPv6, tradiční akce věnované tématům spojeným s tímto protokolem, vyhlásili Call for Abstracts. Na webu konference mohou zájemci přihlašovat příspěvky o délce 20 nebo 40 minut či 10minutové lighting talky a to až do 30. dubna. Tvůrci programu uvítají návrhy přednášek z akademického i komerčního sektoru, které mohou být technického i netechnického zaměření. Den IPv6 se letos uskuteční 4. června a místem konání bude i
… více »Euro-Office (Wikipedie) je evropský fork open source kancelářského balíku OnlyOffice. Za forkem stojí koalice firem IONOS, Nextcloud, Eurostack, XWiki, OpenProject, Soverin, Abilian a BTactic. Cílem je zajistit digitální suverenitu Evropy a snížit závislost na neevropských platformách. Projekt vznikl mimo jiné v reakci na nedávné uzavření cloudové služby OnlyOffice. OnlyOffice obviňuje Euro-Office z porušení licenčních podmínek. Na možné problémy upozorňuje i Collabora Online. Jednostranná změna licence není v pořádku.
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Během akce Arduino Days 2026 byl publikován Arduino Open Source Report 2025 (pdf) a oznámeno 7 nových produktů kompatibilních s deskou UNO Q (Arduino USB-C Power Supply, USB-C Cable, USB-C Hub, UNO Media Carrier, UNO Breakout Carrier, Bug Hopper, Modulino LED Matrix).
Google v pátek spustil v Česku Vyhledávání Live. Tato novinka umožňuje lidem vést plynulou konverzaci s vyhledávačem v češtině. A to prostřednictvím hlasu, nebo prostřednictvím toho, na co ukážou svým fotoaparátem či kamerou v mobilu. Rozšíření této multimodální funkce je možné díky nasazení Gemini 3.1 Flash Live, nového hlasového a audio modelu, který je od základu vícejazyčný, takže umožňuje lidem po celém světě mluvit na vyhledávač přirozeně a v jazyce, který je jim nejbližší.
Jsongrep je open-source nástroj, který efektivně prohledává JSON dokumenty (editovat je neumí). Kompiluje regulérní jazyk dotazu do podoby deterministického konečného automatu (DFA), díky čemuž prochází strom JSON dokumentu pouze jednou a je v tom tedy rychlejší než jiné nástroje jako jsou například jq, JMESPath nebo jql. Jsongrep je napsaný v programovacím jazyce Rust, zdrojový kód je dostupný na GitHubu.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
systemd-analyze Startup finished in 3.366s (kernel) + 5.577s (initrd) + 4.416s (userspace) = 13.360skernel + initrd skoro 9 sec. Přitom systém startuje ze SSD, jádro má po 6M a initrd pod 9M. Rychlosti SSD jsou
hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 11700 MB in 2.00 seconds = 5851.52 MB/sec Timing buffered disk reads: 632 MB in 3.01 seconds = 210.27 MB/sec #dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 záznamů přečteno 1024+0 záznamů zapsáno 1 073 741 824 bajtů (1,1 GB) zkopírováno, 2,52218 s, 426 MB/s # echo 3 > /proc/sys/vm/drop_caches #dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 záznamů přečteno 1024+0 záznamů zapsáno 1 073 741 824 bajtů (1,1 GB) zkopírováno, 2,83766 s, 378 MB/sProč startuje pár MB tak dlouho?
systemd-analyze plot nic nedá. kernel a initrd jsou atomické operace. Procesor je 4 jádro i5 s nezamčeným násobičem a možností jít až na 4GHz, takže pomalostí procesoru to také být nemůže.
Řešení dotazu:
# hdparm -Tt /dev/sda /dev/sda: Timing cached reads: 7434 MB in 2.00 seconds = 3718.63 MB/sec Timing buffered disk reads: 610 MB in 3.01 seconds = 202.78 MB/sec # dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 6,71549 s, 160 MB/s # echo 3 > /proc/sys/vm/drop_caches # dd if=tempfile of=/dev/null bs=1M count=1024 1024+0 vstoupivších záznamů 1024+0 vystoupivších záznamů 1 073 741 824 bajtů (1,1 GB) zkopírováno, 5,09127 s, 211 MB/sbtw: co je to za distro ? koukam ze mas cz preklad bez vší :)
systemd-analyze plot > soubor A moc nejsem si jist jestli bootchart je schopen rozebrat, co se děje přitom když se loaduje kernel a initrd.
Bootchart není součástí jádra, takže půjde spustit nejdřív z initramfs, no jednodušší bude přeložit si vlastní jádro se zabudovanými ovladači pro řadič disku a kořenový souborový sytém než upravovat skripty v initramfs. Pokud se systém nezavádí z diskového pole, a pokud na kořenový oddíl v zavaděči ukazuje přímo cesta k zařízení, nikoli jmenovka či UUID, mělo by to být schůdné.
Tak co nastavení grubu nebude tedy problém tam?+1 Kdysi jsem u grubu jako první vyhazoval vyhazoval z device.map řádek pro disketovku.
Jasně tady je to specifický požadavek a pokud půjde boot zrychlit tak zde to má význam.
systemd-analyze Startup finished in 4.660s (kernel) + 1min 42.862s (userspace) = 1min 47.522s
Proč?
Jeden stroj:
Startup finished in 3.527s (kernel) + 46.858s (userspace) = 50.385s
Druhej stroj
Startup finished in 5.465s (kernel) + 1.687s (userspace) = 7.152s
Třetí
Startup finished in 1.817s (kernel) + 1.398s (userspace) = 3.215s
Všechny tři časy jsou zcela v pořádku, ten třetí měl ještě před časem 400ms userspace.
(První stroj je server s hromadou služeb, druhý je fyzická pracovní stanice s nějakým HW navíc, třetí je virtuálka pro testy.)
Proč?Třeba protože je ta hodnota podezřele blízká 90 sekundám a je tam ještě pár vteřin na víc a zbytek bootu? Samozřejmě to může být náhoda, ale vzhledem k tomu, že je boot time jinak většinou podstatně nižší, což ukazují i tvoje výsledky, je takové podezření nasnadě.
Startup finished in 15.000s (kernel) + 2min 4.588s (userspace) = 2min 19.589s
Tiskni
Sdílej: