Organizace Video Games Europe reprezentující vydavatele počítačových her publikovala prohlášení k občanské iniciativě Stop Destroying Videogames.
Společnost Raspberry Pi nově nabzí Raspberry Pi Camera Module 3 Sensor Assembly, tj. samostatné senzorové moduly z Raspberry Pi Camera Module 3.
Cathode Ray Dude v novém videu ukazuje autorádio Empeg Car (později Rio Car) z let 1999–2001. Šlo o jeden z prvních přehrávačů MP3 do auta. Běží na něm Linux. Vyrobeno bylo jen asi pět tisíc kusů, ale zůstala kolem nich živá komunita, viz např. web riocar.org.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.7.
Wayland byl vydán ve verzi 1.24.0. Jde o menší vydání po více než roce. Více funkcionality bývá přidáváno v průběžných vydáních Wayland Protocols.
Textový editor Geany byl vydán ve verzi 2.1. Jde o udržovací vydání po bezmála dvou letech. Obsahuje drobná vylepšení vyhledávání, aktualizace podpory zvýrazňování syntaxe a dále převážně opravy chyb.
Byly zveřejněny videozáznamy, dostupné také s prezentacemi přímo z programu, a také fotogalerie z open source komunitní konference DevConf.CZ 2025 konané od 12. do 14. června v Brně.
Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
$ systemd-analyze Startup finished in 6.222s (kernel) + 18.942s (userspace) = 25.165s graphical.target reached after 18.937s in userspace
systemd-analyze
Startup finished in 3.674s (firmware) + 5.427s (loader) + 3.013s (kernel) + 9.739s (userspace) = 21.855s
graphical.target reached after 9.728s in userspace
Ubuntu Mate 20.04 sata SSD.
[1][root@max ~]# systemd-analyze Startup finished in 3.235s (kernel) + 5.979s (userspace) = 9.214s graphical.target reached after 5.978s in userspaceZdar Max
Startup finished in 4.144s (kernel) + 4.933s (userspace) = 9.078s graphical.target reached after 4.741s in userspaceK čomu to?
$ systemd-analyze bash: systemd-analyze: command not found
[dskola@lenovot420 ~]$ systemd-analyze Startup finished in 2.029s (kernel) + 6.547s (initrd) + 1min 51.931s (userspace) = 2min 508ms graphical.target reached after 1min 51.908s in userspaceLenovo T420, Core i5, Fedora 31
bash: systemd-analyze: command not foundOpenRC forever!
Startup finished in 4.681s (kernel) + 6min 22.281s (userspace) = 6min 26.963s graphical.target reached after 14.375s in userspaceVtipné. Bližší průzkum (
systemd-analyze plot
) ukázal, že to počítá i čas než jsem se vrátil ze záchoda a vyťukal jméno a heslo # systemd-analyze Startup finished in 3.700s (userspace) = 1d 1h 20min 58.153sAle vůbec nevím, co je to za tím rovnítkem. Man mlčí. Uptime to není, ten je mnohem větší. Je to nspawn kontejner, boot je 3.7s z toho PostgreSQL 3.2s + Apache 486ms (paralelně). Čistej boot bez služeb cca 200ms.
# systemd-analyze Startup finished in 18.024s (kernel) + 1min 37.876s (userspace) = 1min 55.900s graphical.target reached after 38.331s in userspaceMi přijde, že s pomalým 5400rpm diskem je to paralelní spouštění služeb je stejně k ničemu. Opravte mě jestli se pletu.
Startup finished in 17.874s (kernel) + 2min 2.353s (userspace) = 2min 20.228s graphical.target reached after 1min 19.786s in userspaceCPU i5-2520M 4x2.50GHz, 5400RPM HDD. Ubuntu 20.04 (Vek: 8 rokov):
Startup finished in 25.015s (kernel) + 1min 18.137s (userspace) = 1min 43.152s graphical.target reached after 1min 18.105s in userspaceTen rozdiel času približne zodpovedá pomeru otáčok diskov, len s 5% odchýlkou. Rozsah nainštalovaného SW je približne rovnaký. Ten starší stroj má naozaj rok výroby 2003, a novší je z roku 2012.
$ systemd-analyze Startup finished in 2.040s (kernel) + 10.155s (initrd) + 23.630s (userspace) = 35.827s graphical.target reached after 23.585s in userspaceFedora 32 na pracovním laptopu s Core i7 a NVMe SSD. Trochu mi to zpomalují různé custom unity.
~ systemd-analyze bash: systemd-analyze: příkaz nenalezen
Startup finished in 2.425s (kernel) + 7.185s (initrd) + 9.313s (userspace) = 18.924s graphical.target reached after 9.305s in userspaceRyzen 3600, Samsung 970 EVO.
systemd-analyze Startup finished in 9.631s (kernel) + 11.966s (userspace) = 21.598s graphical.target reached after 8.601s in userspaceAsi spatnej HW ...... AMD 3990X.
systemd-analyze time Startup finished in 4.748s (kernel) + 8.722s (userspace) = 13.470s graphical.target reached after 8.710s in userspace
systemd-analyze blame | head -n 10 7.144s systemd-networkd-wait-online.service 668ms dev-sdb1.device 645ms lightdm.service 634ms systemd-logind.service 369ms systemd-networkd.service 365ms systemd-modules-load.service 346ms systemd-resolved.service 321ms systemd-journald.service 294ms systemd-timesyncd.service 276ms mnt-backup.mount
systemd-analyze critical-chain The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. graphical.target @8.710s └─multi-user.target @8.710s └─hddtemp.service @8.693s +16ms └─network-online.target @8.690s └─systemd-networkd-wait-online.service @1.545s +7.144s └─systemd-networkd.service @1.163s +369ms └─systemd-udevd.service @1.121s +34ms └─systemd-tmpfiles-setup-dev.service @1.062s +22ms └─systemd-sysusers.service @966ms +41ms └─systemd-remount-fs.service @754ms +168ms └─systemd-journald.socket @460ms └─system.slice @168ms └─-.slice @168msZ nějakého prapodivného důvodu se čeká 7s na dostupnost sítě. Statická konfigurace. Ze 13s celkově je to docela zajímavý čas. Ale nemá to smysl řešit. Bootoje se jednou denně a třeba čas v POST (5s) a následně GRUBu (10s) je delší, než celý boot linuxu.
Niektoré distribúcie zvykli overovať či nakonfigurovaná IPka už náhodou nie je na sieti, a na tom to čakalo odhadom nejakých 5 sekúnd.Tohle řeší ARP / ICMPv6, na tom nemá co trvat 5s. Jinak celé tohle cvičení mě přivedlo k myšlence, zda lze jakýkoliv NM (interfaces, network-manager, systemd-network) prostě nahradit jednou oneshot unitou, ve které se prostě natvrdo síť nastaví sérií ip příkazů (tj minimálně
ip link dev set up; ip address add; ip route add default
). Tj pro staticky nastavované sítě (tj všechny moje) by to mohlo být takto jednoduché.
Tohle řeší ARP / ICMPv6, na tom nemá co trvat 5s.On je tam timeout na odpoveď, a tých 5s bolo u mňa reálne zdržanie v takom kroku. Ale človek si to všimol akurát tak na minimálnej inštalácii, bez GUI a s vypnutým bootsplash. Inak to mal perkryté.
systemd-networkd-wait-online.service
bezpečně vypnout. (Na serveru nikoliv, na online.targetu závisejí služby.) Takže bez zbytečných zdržovaček:
Startup finished in 4.729s (kernel) + 3.049s (userspace) = 7.778s graphical.target reached after 3.026s in userspaceCož celkem jde.
3.943845s kernel + x.org
Thinkpad T420, SSD, openrc, gentoo.
T420 nemá USB 3. USB3 expresscard?
Ešte prihadzujem video ako tá moja stará rachotina bootuje. Ako som spomínal je tam SSD (samsung evo 850), CPU i5-2520M, 16GB RAM, 1600MHz, integrovaná intel GPU a ešte výpis lspci:
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port Mobile SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) 0d:00.0 SD Host controller: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 05)
Fuu netuším ;)
dmidecode
ale ten vyžaduje UEFI. To je už štandard posledných vyše 10 rokov.
L1, L2, L3 majú u mňa Error Correction Type: Single-bit ECC. Akurát neviem, či je to dobré, alebo nie ;)
Tiskni
Sdílej: