DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Já bych grub legacy vůbec neinstaloval a nechal grub 2 zavádět oba systémy (jádra).
Taková možnost zatím neexistuje, bohužel.
Nemusí se tlouct. Nejlepším řešením je použít chainloading, tj. nechat GRUB 2 jako hlavní bootloader nainstalovaný přímo na úvodních blocích disku a poté nainstalovat fosilní GRUB od OpenIndiany přímo do oddílu (nebo do jednoho z oddílů), kde OpenIndiana bude. Měl by to být primární MBR oddíl. (Jak by to fungovalo s GPT, to jsem nezkoušel.) GRUB 2 pak může mít v menu položku pro chainloading toho fosilního GRUBu, který bude dobře fungovat s OpenIndianou, tj. bude ukazovat seznam dostupných BE a podobně.
Poněkud krkolomný návod je zde. Když jsem já instaloval dual boot ArchLinuxu a OpenIndiany, prostě a jednoduše jsem nainstaloval ArchLinux a jeho GRUB 2 a nechal jsem prázdný oddíl pro OpenIndianu. Při následné instalaci OpenIndiany jsem pak nenechal bootloader zapsat přímo do úvodních stop disku, ale do oddílu (resp. před oddíl, podle toho, jak se to vezme) s OpenIndianou. Stačilo už jen přidat do GRUBu 2 položku pro chainloading a vše bylo vyřešeno. Ani náhodou jsem nemusel provádět nějaké podivné zápisy pomocí dd
či něco podobného.
V podstatě jedinný důvod, kdy vidím oprávění dual bootu je situace, kdy nutně potřebuji přímý přístup k HW a to mě kromě hráčů her a jejich přistupu ke výkonu grafiky, nic nenapadá, co by požadavek na dual boot dělalo tak nutným.
Jako diplomovou práci jsem implementoval RCU pro kernel (UTS) OpenSolarisu. Takže přístup k hardware sice nebyl (přísně vzato) stoprocentně nutný, ale KVM tehdy v multiprocesorech příliš nevynikal (mírně řečeno) a pro jakékoliv seriózní ověření funkčnosti a praktických výhod toho RCU byl bare metal v podstatě nutností. To by mohl být příklad situace (byť ne úplně obvyklý), kdy virtualizace nevyřeší úplně všechno.
Dual boot se ovšem vůbec nevylučuje s virtualizací. V mém případě to fungovalo následovně: Když jsem nabootoval do ArchLinuxu, sestavil se lineární RAID, který sestával ze souboru (loopbacku) s fiktivním MBR, následovala skutečná partition s OpenSolarisem a na konci byl zase soubor/loopback s další partition (čistě pro formu, aby sedělo číslování disků, pokud si to dobře pamatuju). Takže se OpenSolaris dal spustit normálně v qemu-kvm
jako virtuální stroj s přímým přístupem na disk. Při přebootování systému se ovšem dal zvolit ten chainloading na fosilní GRUB a ten samý OpenSolaris z toho samého oddílu se tak dal nabootovat i přímo a bez virtualizace. Jenom se nesmělo zapomenout na touch /reconfigure
, kdykoliv bylo potřeba přebootovat OpenSolaris „z virtualizace na opravdový hardware“ nebo naopak. Byla to velmi užitečná konfigurace, protože se dalo pracovat s novějšími vývojovými nástroji a s virtualizací přímo na Linuxu a podle potřeby občas nabootovat Solaris na opravdovém hardwaru, když šlo o benchmarky.
Ovšem dlužno dodat, že to už je hodně dávno. OpenSolaris je už jen historie. Jenom se divím, že dodnes není pro takovou konfiguraci podpora v nějakém klikátku typu virt-manager, tj. možnost zvolit partition, ze které se má přímo nabootovat virtuální stroj, k té partition vygenerovat a lineárním RAIDem připojit fiktivní MBR nebo GPT a nakopnout z toho virtuální stroj.
Tiskni Sdílej: