Byl vydán Mozilla Firefox 156.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Vestavěný prohlížeč PDF se nyní spouští o 45 % rychleji. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 156 bude brzy k dispozici také na Flathubu a Snapcraftu.
Článek na Raspberry Pi představuje nový vzhled desktopu operačního systému Raspberry Pi OS v aktuálním vydání 2026-09-15.
Nové verze Roundcube Webmailu 1.6.19 a 1.7.4 řeší několik zranitelností.
Na Kickstarteru běží kampaň na podporu hloupého (jenom volání a SMS) tlačítkového DIY telefonu MAKERphone 2.0 od společnosti CircuitMess postaveného na ESP32-S3 a volitelně také s hodinkami MAKERband. S možností psaní vlastních aplikací. S volitelnými HW rozšiřujícími moduly.
Byla vydána nová verze 10.7 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyly balíčky HomeBox a Scrypted.
OpenRGB (GitLab) dospěl do verze 1.0 (YouTube). OpenRGB (dříve OpenAuraSDK) je svobodný multiplatformní software umožňující nastavení podsvícení celé řady různých „herních“ komponent a periferií.
Dnes startuje prodej headsetu Steam Frame. Počínaje dneškem se tedy můžete zapsat na seznam pro jeden z následujících modelů: Steam Frame 256 GB za 1 049 EUR a Steam Frame 1 TB za 1 279 EUR.
Vládní CERT upozorňuje na kritickou zranitelnost v GitLab Community Edition (CE) a Enterprise Edition (EE). Zranitelnost CVE-2026-85706 typu path traversal v Repository Commits API dosahuje skóre CVSS 10.0. Kvůli nedostatečnému omezení cest a chybějícímu vynucení autentizace může za určitých podmínek neautentizovaný útočník číst libovolné soubory ze serveru GitLab, a získat tak přístup k citlivým datům a konfiguraci instance.
Linux může běžet nativně na ESP32-S3 – bez emulace a rovnou s 9,7″ e-paperem.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 7.0.0. Pro sandboxing se na Linuxu nově používá Landlock místo Bubblewrap. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
. Hele dá se to udělat celkem jednoduše i tak, že nabootuješ distribuční modulární jádro, pomocí lsmod si zobrazíš moduly který si to načetlo, ty si poznamenáš, pak vezmeš ten distribuční konfig a ořežeš to jenom na ty moduly který sis vypsal. Já se teda ještě zbavuju initramfs tím, že všechny moduly pro filesystémy který používám nekompiluju jako moduly ale přímo do jádra.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
make localmodconfig
13.1.2010 16:06
/proc/config.gz. Jestliže běžící jádro poskytuje svou konfiguraci a neexistuje ještě .config, vezme se jako výchozí právě konfigurace právě běžícího jádra.
/proc/config.gz
Toto jsem vyzkoušel, ale s tímto konfigurákem systém nenajede.Kvôli čomu? Zbuilduješ a nainštaluješ aj moduly?
make localmodconfig a make localyesconfig a je to.
Jádro má 6MB a nic víc nepotřebuje.
14.1.2010 10:30
michich | skóre: 51
| blog: ohrivane_parky
/boot/config-$verze).
Ale výsledek se dostaví poměrně brzo.
Jo a použít distribuční config z /boot nebo z /proc nemá cenu protože tam právě bude všechno zaškrtnuté.
…protože to ovladače zakompiluje natvrdo do jádra a nemusíte řešit initramfs.
To už dnes taková výhra není, protože initial ramdisk se hodí i z mnoha jiných důvodů.
Kořenový filesystém na LVM nebo softwarovém RAIDuSW RAID není bez initramfs problém. Co mám zkušenost, je s tím dokonce míň problémů.
S využitím autodetekce RAIDů jádrem by to asi šlo...asi to používám na třech strojích. Jediný problém se objevil, když se změnilo pořadí mezi autodetekcí RAIDu a detekcí swapovacího oddílu, ze kterého se má probouzet TuxOnIce - probouzení ze swapu na MD přestalo fungovat, protože v době detekce swapu oddíl ještě neexistoval.
ale ta je nešťastná sama o soběNevidím, co je na tom nešťastného. Starat se o SW RAID má na starosti jádro, tak ať se taky stará o to ho sestavit. Nevidím důvod, proč k tomu vyžadovat nástroj v userspace.
Pokud se tedy o něm dá vůbec mluvit jako o "zlu".- zapomeneš sestavit nový při aktualizaci jádra - nenabootuješ (a to šlo o update mezi 2.6.32.2 a 2.6.32.4, přesto nešel načíst ovladač pro raid) - chybně sestavíš startovací skripty a následně použiješ probouzení - sbohem, data A zatím ještě nenarazil na jedinou věc, kterou bych potřeboval a bez initramfs se to nedalo udělat.
Jediný problém se objevil, když se změnilo pořadí mezi autodetekcí RAIDu a detekcí swapovacího oddílu, ze kterého se má probouzet TuxOnIce - probouzení ze swapu na MD přestalo fungovat, protože v době detekce swapu oddíl ještě neexistoval.
To je právě jeden z problémů - nemožnost ovlivnit, kdy přesně se bude RAID inicializovat (co musí být předtím a co musí být až potom). Další potenciální zdroj problémů nastane v okamžiku, kdy se zboří systém a budu ten RAID potřebovat připojit k jinému počítači, abych z něj dostal data. Nebo dojde k poškození dat a já budu potřebovat, aby se RAID automaticky nenastartoval a nezačal syncovat, protože tím by data definitivně pohřbil.
Další možný problém vidím v situaci, kdy ten RAID nebude složen z oddílů, ale z celých disků. Funguje i potom jaderná autodetekce?
Starat se o SW RAID má na starosti jádro, tak ať se taky stará o to ho sestavit. Nevidím důvod, proč k tomu vyžadovat nástroj v userspace.
Např. mi to umožní ovlivnit, jestli se má opravdu sestavit a kdy se to má stát. Síťová komunikace (po transportní vrstvu) je také realizována jádrem, ale konfiguruje se userspace nástrojem.
A zatím ještě nenarazil na jedinou věc, kterou bych potřeboval a bez initramfs se to nedalo udělat.
Co ty dva příklady, které jsem uváděl výše - kořenový filesystém na LVM a persistence jména zařízení (modelový příklad: počítač má pouze dva disky připojené přes USB a kořenový filesystém je na jednom z nich). Případně mne napadá ještě šifrovaný kořenový filesystém nebo bezdiskové stanice bootující po síti.
Další možný problém vidím v situaci, kdy ten RAID nebude složen z oddílů, ale z celých disků. Funguje i potom jaderná autodetekce?IMHO ano, protože disk bez oddílů se jeví v Linuxu obecně jako jeden oddíl.
IMHO ano, protože disk bez oddílů se jeví v Linuxu obecně jako jeden oddíl.
Nic takového jsem nikdy nepozoroval, pořád platí, že nerozdělenému disku odpovídá zařízení (např.) /dev/sda (s minor číslem dělitelným šestnácti), zatímco oddílu /dev/sdan, kde n je (nenulový) zbytek minor čísla při dělení šestnácti.
md: md0 stopped. md: bind<hdd> md: bind<sda1> md: bind<hde1> md: bind<hdf> raid5: device hdf operational as raid disk 0 raid5: device hde1 operational as raid disk 3 raid5: device sda1 operational as raid disk 2 raid5: device hdd operational as raid disk 1 raid5: allocated 4208kB for md0 raid5: raid level 5 set md0 active with 4 out of 4 devices, algorithm 2 RAID5 conf printout: --- rd:4 wd:4 disk 0, o:1, dev:hdf disk 1, o:1, dev:hdd disk 2, o:1, dev:sda1 disk 3, o:1, dev:hde1 md0: unknown partition table XFS mounting filesystem dm-0 Starting XFS recovery on filesystem: dm-0 (logdev: internal) Ending XFS recovery on filesystem: dm-0 (logdev: internal)(ano, to je auto config)
Nebo dojde k poškození dat a já budu potřebovat, aby se RAID automaticky nenastartoval a nezačal syncovat, protože tím by data definitivně pohřbil.Ne že bych za to byl ochoten dát ruku do ohně, ale mám ten dojem, že sestavené pole je označené jako active(auto-read-only) a to do té doby, než na to pole něco zapíše (a teprve pak se začne syncovat) Ale i tak - když si nebudu jistý, tak tam buď můžu disky strkat po jednom a kopírovat z nich data pryč, nebo je připojím až po nastartování systému (pokud jsou SATA)
Další možný problém vidím v situaci, kdy ten RAID nebude složen z oddílů, ale z celých disků.Přiznávám se, že nevím, nikdy by mě nenapadlo něco takového udělat.
Síťová komunikace (po transportní vrstvu) je také realizována jádrem, ale konfiguruje se userspace nástrojem.I v případě, že se bootuje ze sítě? Konfigurační volba nazvaná "kernel level autoconfiguration" naznačuje, že tvoje tvrzení není vždy pravdivé. (Mj. je to reakce i na druhou polovinu poslední věty tvého příspěvku.) Takže v případě, že jádro ví, co chci udělat (nahodit síť, použít DHCP, nabootovat), může klidně nakonfigurovat síť bez userspace. To samé, když jádro ví, co chci udělat (nahodit MD pole a připravit je k práci), může to udělat taky. K poslednímu odstavci - jak jsem psal, ještě jsem nenarazil na jedinou věc, kterou bych potřeboval a bez initramfs se to nedalo udělat.
I v případě, že se bootuje ze sítě? Konfigurační volba nazvaná "kernel level autoconfiguration" naznačuje, že tvoje tvrzení není vždy pravdivé. (Mj. je to reakce i na druhou polovinu poslední věty tvého příspěvku.)
Při "normálním" bootování ze sítě není důvod, aby to dělalo jádro. Prvotní nastavení a první fázi bootu provede BIOS (jádro těžko, tohle se musí udělat dřív, než se jádro vůbec stáhne). Podruhé už to klidně může provést userspace a má to i tu výhodu, že je to konfigurovatelné. To, co popisujete, se používá pouze v jednom specifickém případě (nfsroot) a i tam to lze řešit jinak - právě díky initial ramdisku.
Další příklad je třeba IPsec: protokoly ESP a AH jsou implementovány jádrem, ale nastavení SAD nebo SPD se provádí z userspace, buď ručně příkazem setkey, nebo to dělá automaticky racoon podle toho, co si dohodne s protistranou. Nebo třeba netfilter, také je realizování jádrem, ale konfiguruje ho userspace.
Tiskni
Sdílej:
