Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
Hackintosh to třeba nadetekuje tak že nebootuje ale výběrem položky v biosu to funguje takže z grubu ho vždy mažu.
No nebootuje na sdb ale snaží se zavést jádro osx a to vytuhne na ovladačích protože se z mbr nenabootovale clover a nehacknul hw tak aby to jádro osx sežralo.
menuentry "Windows 7 1/0" {
set root='hd0,msdos1'
insmod part_msdos
insmod ntldr
insmod ntfs
insmod chain
chainloader (hd1,0)/boot/sda_safeboot.mbr
}
menuentry "Windows 7 1/1" {
set root='hd0,msdos1'
insmod part_msdos
insmod ntldr
insmod ntfs
insmod chain
chainloader (hd1,1)/boot/sda_safeboot.mbr
}
menuentry "Custom Super Bootloader 0/0 + 1" {
insmod part_msdos
insmod chain
chainloader (hd0,0)+1
}
menuentry "Custom Super Bootloader 0/1 + 1" {
insmod part_msdos
insmod chain
chainloader (hd0,1)+1
}
menuentry "Custom Super Bootloader 0/0" {
insmod part_msdos
insmod chain
chainloader (hd0,0)
}
menuentry "Custom Super Bootloader 0/1" {
insmod part_msdos
insmod chain
chainloader (hd0,1)
}
menuentry "Custom Super Bootloader 0" {
insmod part_msdos
insmod chain
chainloader (hd0)
}
menuentry "Windows 7 BIOS MBR" {
insmod part_msdos
insmod ntldr
insmod ntfs
ntldr (hd0,msdos1)/bootmgr
Vysledkem je to,ze mi bud nahlasi, ze takova partice neexistuje (chapu, dal jsem tam i zjevne nesmyslene kombinace) a nebo ze nerozpoznal souborovy system.
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-722A-7552' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 722A-7552
else
search --no-floppy --fs-uuid --set=root 722A-7552
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
set timeout_style=menu
if [ "${timeout}" = 0 ]; then
set timeout=10
fi
### END /etc/grub.d/30_os-prober ###
set root='hd0,gpt2' je oddíl s fat kde jsou zavaděče uefi a pomocí chainloader se vybere windows.
Asi by chtělo vědět kde je ten správný zavaděč pro windows.
Tohle nemusí nutně být řešitelné GRUBem. Firmware u leckterých počítačů zpřístupní GRUBu pouze jeden jediný (zvolený) bootovací disk a nic jiného. Takže ostatní disky začnou být přístupné teprve tehdy, až nabootuje kernel, načte ovladač od řadiče disku a zprovozní řadič „řádným“ způsobem, nikoliv pomocí spartánského přístupu před EFI nebo jiný firmware.
Spálil jsem se na tomhle hodněkrát. Například GRUB umí už dávno pradávno bootovat z Btrfs RAID 0, 5 i 6. Jal jsem se to tedy vyzkoušet a … ne. Ani náhodou. Viděl totiž jenom jeden disk, takže zahlásil, že hledaný Btrfs sice našel, ale že od něj nemá dost disků. Jediná konfigurace, kde měl dost disků, je — ach, jak překvapivé — Btrfs RAID 1. Je to smutné, ale je to tak. Od té doby bootuju třeba server tak, že má (řekněme) 6 disků s Btrfs RAID 5 přes (skoro) celé disky, ale na každé disku je taky malý Btrfs RAID 1 oddíl pro /boot. Takže /boot je replikovaný a server mi nabootuje kernel z kteréhokoliv (jednoho jediného) disku, tak jak ho GRUB vidí, a jakmile je u moci kernel, umí si už zprovoznit všechny disky a otevřít ten velký Btrfs RAID 5.
Viděl jsem v jednom (jednom!) nastavení firmwaru na nějakém Dell bladu, že se dalo GRUBu zpřístupnit víc disků než jeden. Ale nějak to nepomáhalo, možná jsem význam té volby špatně pochopil atd., zkrátka, GRUB viděl všechny disky, aspoň co se auto-completion týká, ale jakmile na nějaký sáhl, ostatní už pak číst nemohl. Nevím, kde byla chyba, jestli v GRUBu nebo jinde, ale beztak jsem chtěl mít stejné rozvržení na všech strojích, takže jsem to vzdal ve prospěch toho replikovaného Btrfs RAID 1 /boot oddílu.
Což tedy samozřejmě u multiboot konfigurace nepomáhá ani trochu. :-P
Tiskni
Sdílej: