Google Blog ČR informuje, že mobilní aplikaci Gemini a NotebookLM lze používat už také v Česku.
Byla vydána nová major verze 8 duálně licencovaného open source frameworku JUCE (Wikipedie, GitHub) pro vývoj multiplatformních audio aplikací.
Od 18. června bude možné předobjednat notebook DC-ROMA RISC-V LAPTOP II od společnosti DeepComputing s osmijádrovým 64-bit RISC-V AI CPU a s předinstalovaným Ubuntu.
Byla vydána verze 1.79.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Byly zveřejněny výsledky průzkumu (infografika) mezi uživateli FreeBSD.
Na konferenci DevConf.CZ 2024 je na stánku Furi Labs prezentován linuxový telefon FuriPhone FLX1. Jeho cena 499 dolarů.
Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Po roce od vydání verze 15.5 bylo vydáno openSUSE Leap 15.6. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána nová verze 256 správce systému a služeb systemd (GitHub). Nově mimo jiné s run0 jako alternativou k sudo.
Když se někomu pokouším objasnit, v čem je naše disklessová technologie specifická, pokaždé se na ni snaží napasovat terminologii, kterou důvěrně zná. Takže se obvykle ptá na image a hlava mu nebere, že se žádnou nepracuje.
S pojmy kernel (jádro), ramdisk, image (obraz disku), stack (pro vrstvený systém), overlay (překrytí zapisovatelnou vrstvou), diskless (pro systém, který nepracuje s lokálním blokovým zařízením), tihle lidé běžně pracují, ale nerozumí tomu, že „Stack – a pile of things arranged one on top of another”, není totéž co „Sandwich – to put something between two other things”, i když že se v obou případech pracuje s vrstvami („Layers”).
Základem naší disklessové technologie je sendvič – ten flák masa mezi chleby je vrstva operačního systému a nemusí být jen jedna. Může jich být víc. Tak jako je pod ním salát a nahoře rajče, může být dole Buster a nahoře Trixie. Roli hraje co je výš a co níž. To je samozřejmě extrém, ale proč ne? Rozhodující je stejně ten plátek sýra nahoře – konfigurační vrstva.
Klasický kontejnerový „stack”, je ve srovnání s tím takový obložený chlebíček, jehož základem je ta veka dole, nad kterou se stohují další vrstvy – když ho obrátíš vzhůru nohama, tak ti to spadne. Osobně nevím, že by některá z kontejnerových technologií, které se stohováním vrstev pracují, umožňovala měnit jejich pořadí i když je to samozřejmě technicky možné. Ale třeba je někdo ve skupině zdejších anonymních diskutérů méně retardovaný a přidá místo blbých keců vůči mé osobě nějaký kloudný odkaz. Co vím, tak většinou je základem zkomprimovaný image, mountnutý přes nějaký loop, nad který se postupně vrší další vrstvy, do kterých se zapisují (přes overlay) změny.
Naše původní disklessové řešení vypadalo podobně. Také šlo o stack vrstev. Takhle vypadal kdysi záznam pro jednu laborku:
menu label DCE ^linux 4.6 vmware KERNEL boot/vmlinuz-4.6.0-0.bpo.1-amd64 boot=nfs root=/dev/nfs nfsroot=192.168.202.3:/srv/diskless/unstable-systemd-overlay-withoutsssd,ro,tcp,nocto,acregmin=60,acregmax=120,acdirmin=60,acdirmax=120,ac overlay=0 size=4/5 pause=0.1 INITRD boot/initrd.img-un7 APPEND TARGET=192.168.202.2 RHOME=open:lab_user_home/ layers=192.168.202.3:/srv/app;192.168.202.3:/srv/layers/vmware-player;192.168.202.3:/srv/vmware
Protože každá laborka má svůj subnet, bylo nutné pro každou z nich udržovat extra konfigurák a při kopírování položek v parametru layers=, vrstvených nad základní systémovou vrstvu, předávanou v parametru nfsroot=, bylo potřeba dávat pozor:
A když jsem udělal sebemenší chybu, zůstalo zavádění viset v nekonečné smyčce, což poněkud komplikovalo možnost zjistit, v čem je ta chyba. Navíc se ocitnul ve stavu, který se nedal vyřešit jinak, než k tomu stroji dojít a fyzicky ho restartovat. U sendviče se problematická vrstva jednoduše přeskočí, takže se ten stroj dostane přinejmenším do stavu, kdy najede ssh server.
Parametr overlay= jsem využíval při ladění, protože bylo možné přes něj zvolit pořadové číslo vrstvy z předaného stacku co se měla namountovat do systému mimo overlay v RW módu. Na to, aby probublaly změny sendvičem je jednoduchá finta a tak bylo možné dloubat spuštěnému systému „pod zadkem” do libovolné vrstvy ze stacku. Pochopitelně jen pokud měl ten stroj do onoho adresáře sdíleného z NFS povolen RW přístup.
Ale když jsem začal administrovat i laboratorní systém pro katedru kybernetiky (2016), reálně hrozilo, že mi to přeroste přes hlavu. V některých strojích byla grafická karta od Intelu, jinde NVIDIA. Některé stroje měly spolupracovat se SmartBoardem, jinde se zas měl využívat VMware. A někteří zas chtěli mít možnost hrabat do sdíleného kódu na straně NFS serveru.
Overlay nad NFS adresářem má totiž tu výhodu, že lze na všechny stroje, které ho sdílejí, propagovat v reálném čase stejný obsah. Jenže pokud jsou tyhle vrstvy výše stačí hrábnou kam se nemá a celé to zkolabuje. Jaderný modul "overlay" ale na rozdíl od dříve používaného "aufs" umožnil složení sendviče z více než dvou vrstev a to mne přivedlo na myšlenku rizikové vrstvy přesunout dolů a naopak ty konfigurační nahoru. A také jsem chtěl zjednodušit konfiguraci při zavádění jádra, abychom mohli místo již nevyvíjeného syslinuxu přejít na grub2.
Dnes tedy vypadá položka v zavaděči, pro všechny subnety podobně:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
menuentry "Linux Bookworm" --unrestricted {
linux /boot/vmlinuz-6.5.0-0.deb12.4-amd64 boot=nfs root=/dev/nfs name=lab-intel.bookworm
initrd /boot/initrd.img-6.5.0-0.deb12.4-amd64
}
menuentry "Linux Bookworm isolate mode" --unrestricted {
linux /boot/vmlinuz-6.5.0-0.deb12.4-amd64 boot=nfs root=/dev/nfs name=lab-intel-isolate.bookworm
initrd /boot/initrd.img-6.5.0-0.deb12.4-amd64
}
Parametr name= je pouze jednou z několika možností, jak předat jádru konfiguraci,kterou zpracuje dynamický ramdisk. Ten si stáhne konfiguraci a podle toho co v ní je, si dotáhne a zpracuje další ramdiskové skripty. Samotný generický ramdisk obsahuje jen nezbytné moduly a skript, který se u strojů co komunikují přes wifi stará o nahození sítě. Pak už to funguje stejně. A to je mimochodem další věc, o níž si nejsem vědom, že by ji někdo řešil podobným způsobem.
Když se objevil požadavek, jestli by se dal rozběhat stejný systém jako na laboratorních strojích i na turtlebotech, vyzkoušel jsem nejdřív full-diskless, jenže propustnost WiFi byla tak mizerná, že jsem musel začít věnovat pozornost tomu, kolik se během spuštění tahá dat.
Kontejner pro singularity, ve kterém bylo zabalené Ubuntu + ROS, mělo tehdy cca 1GB. Bylo nereálné, aby s tak velkým souborem studenti pracovali v režimu full-diskless přes WiFi. Ale když se vybalil do adresáře, chovalo se to jak normální diskless – data se nakešovaly do RAM a změny se ukládaly do sdíleného domovského adresáře. A když se aplikoval mcachefs, bylo to použitelné i přes WiFi.
Záludný problém se ovšem naplno projevil až při návratu k prezenční výuce, po skončení kovidové hysterie. Předtím totiž nikoho nenapadlo že by vyzkoušel co se stane, když na TurtleBodu v singularity kontejneru vyzkouší automatické doplňování příkazů ROSu. Nejrychlejším řešením nečekané situace bylo rozkopírování image kontejneru pro singularity na jednotlivé turtleboty, podobně jako se to dělalo s virtuály pro VMware. Na sofistikovanější řešení bohužel nebylo kdy.
Ta správná chvíle přišla až loni koncem roku, kdy k full-disklessovému skriptu overlay přibyl half-disklessový skript crypto, který umožňuje kombinovat NFS adresáře s kryptovanými bloby. Ten spolupracuje s úložištěm na lokálním disku – pokud ho má k dispozici. Pokud ne, použije se "overlay" a systém najede jako full-diskless.
Ale image disků v několika případech také využívám – startuji přes ně např. virtuální DHCP servery, ze který si stahují konfiguraci ostatní disklessové stroje. Jsou sdílené přes NFS (přes interní bridge) a je na nich jen zavaděč s jádrem. A jednu má k dispozici virtuální laboratorní stroje, s dedikovanou NVIDIA kartou, aby na něm fungovala stejná konfigurace jako u normálního laboratorního stroje.
Tiskni
Sdílej:
A co furt ty turtleboti? Já myslel že v sobě maj snad nějaký arduino nebo nějakej ořezanej linux a jenom si šahaj na server pro instrukce, proč potřebujou nějaký virtuály? ...a teda jako ty turtleboty si představuju něco jako takový ty berušky co si s nima hrajou děti ve školce.... jakože na nich natlapeš co maj dělat a oni to pak jedou akorátže trochu sofistikovanějš = že to netlapeš na šipky na krofkách, ale řeší to nějakej běžící server na základě telemetrie co mu boti pošlou... proč potřebujou teda ty sendviče?
Tady máš odpovědi na většinu tvých otázek stran turtlebotů řekl bych.
proč potřebujou teda ty sendviče?
Protože se tím všechno zjednodušilo. TurtleBot je šasi, na kterém jsou navěšené různé senzory s nimiž se studenti učí pracovat. Používají k tomu ROS. Ten je v kontejneru, který si buildí vyučující na gitlabu. A o to aby se stáhl, aby vše fungovalo, aby byly schopné ty stroje fungovat i bez připojení se stará jedna vrstva. Kterou jiné laboratorní stroje nemají.
Ta konfigurace co má v parametru isolate, si pro změnu natahuje vrstvu, která zajistí, že se student při zkoušce dostane jen tam, kam se dostat má. Na první pohled vše vypadá a funguje jako by se nic nezměnilo, ale po ověření se nepřipojí domovský adresář jako obvykle. Není tedy potřeba žádný image, protože vše zajistí jedna vrstva co má jen pár kilobajtů.
.., proč potřebujou nějaký virtuály?
Turtleboti žádné virtuály nepotřebujou. Ty potřebuji já, pro různé účely. Dva DHCP servery, dvě proxy, jeden testovací virtuál, přes který připravuji, upravuji a testuji jednotlivé vrstvy sendviče, než je vypustím na fyzický HW. Wiki, kde běží HTTP server, přes který se stahují soubory, co se kešují. Stroj, který dělá jenom to, že ověřuje a v případě potřeby zakládá uživatelské profily. A virtuální laboratorní stroj s dedikovanou GPU, který umožňuje studentům pracovat vzdáleně, tak jak si zvykli za kovidu. No a pak tam má svůj virtuál Pavel Píša.
Studenti na fyzických strojích využívají k plné virtualizaci qemu a kdo pracuje s kontejnery má na výběr mezi systemd-nspawn a singularity. Mám i vrstvu s VMware, jenom si nejsem jist, jestli se teď vůbec někde při výuce využívá ale pokud by si někdo přitáhl na flešce nějakou farmičku virtuálů, může si ji spustit. Proto nemá smsyl ztrácet čas s takovýma blbostma, o jakých píše plostenka.
Ten skript crypto, o kterém se zmiňuji v textu umožňuje používat kryptované bloby, ale prakticky se ukázalo, že i když to funguje jak má, je to zbytečné. A víš proč? Pokud se někdo dostane na systém, který z nich běží, tak si ho normálně zkopíruje a vůbec nic neřeší. Já to také neřeším, protože tam nic tajného není. Smysl by to mělo jen v případě, že bychom provozovali autonomní zařízení, které by mělo fungovat v utajení, mimo naši infrastrukturu. V takovém případě by totiž dostala konfigurace do sendiče ještě jednu vrstvu, která by zajistila že se do spuštěného systému nenabouráš, a po vypnutí by ti zůstaly na disku jen kryptované bloby bez hlaviček.
pokud by si někdo přitáhl na flešce nějakou farmičku virtuálů, může si ji spustit. Proto nemá smsyl ztrácet čas s takovýma blbostma, o jakých píše plostenka.Kdyz si pletes ne-sifrovani (at si klidne poctou, nic tajneho nemam) s ne-podepisovanim (at mi klidne podstrci fejkovy login screen) tak je to pak tezke.
Já na rozdíl od tebe pindale na kybernetickém cvičení byl, a můj tým by vyhrál, kdybych měl reálnou zkušenost s PostgreSQL. Jenže takový borec, abych znal všechny bezpečnostní díry, i u software se kterým jsem nikdy dřív nepracoval, to fakt nejsem.
ok no
..měl znalosti
Není totéž co "..znal všechny bezpečnostní díry, i u software se kterým jsem nikdy dřív nepracoval"
A je vidět, že žádnou podobnou zkušenost nemáš. To cvičení totiž vypadalo tak, že ses v pátek odpoledne seznámil s lidmi ze kterých byl sestaven tvůj tým. Pak jsi dostal několik hodin na seznámení s virtuálním polygonem. A druhý den od začátku do konce na tu infrastrukturu, kterou jsi den předtím viděl prvně v životě a teď jsi ji měl bránit, bušili studenti, kteří věděli o všech připravených dírách. Byl to mix aplikací a OS, jaký by nikdo příčetný na podobný účel nikdy nepoužil, ale budiž. Naším úkolem bylo přežít. No a na konec si nechali tu nejvypečenější díru, kterou ustál pouze jediný tým – podle mého názoru v něm byl člověk, který se na tom už v minulosti někdy spálil. Věděli, že tu situaci během zbývajících 5 minut nebude možné vyřešit a opravit.
a plácáš se v tom, dost tragédie
Ten už je dávno napsaný, sklerotiku. Skoč si do lékárny pro ginkgo a pij odvar nejmíň třikrát denně.
A prozradím ti jedno sladké tajemství.
Už za dob, kdy jsem dělal helpdeskáře na atlasu jsme zjistili, že minimálně jeden údaj mezi těmi fejkovými je vždy pravdivý. Takže i když se různí omezení mamlasové jako ty snažili sebevíc, blokli jsme je dřív než toho mohli zneužít. Tenhle server pod palcem nemáš, ale věř tomu, že bych tě tu zamáznul dřív než by si řekl švec.
Hýčkám si tě pro své pobavení. Jako papouška.
„Stack – a pile of things arranged one on top of another”, není totéž co „Sandwich – to put something between two other things”A jakej je v tom teda rozdíl? Myslím z pohledu těch definic. Mě to přijde topologicky ekvivalentní. Apriorně bych mohl předpokládat, že v sandwichi musí být ty dvě okrajové vrstvy identické, ale to se tam explicitně neuvádí.
Jak jsem uvedl v diskuzi k předchozímu blogpostu. „Náš zákazník, náš pán”. Chce-li se někdo seriózně o tématu bavit, není problém. A chce-li abych mu oplácel stejnou mincí, také s tím nemám problém.
Je to bohužel důsledek toho, jak se o tenhle portál starají jeho majitelé. Pokud by měli zájem na tom, aby si ten portál udržel nějakou úroveň, zaměstnávali by lidi, co by na ni dohlíželi. Jako neprivilegovaný uživatel nemám jinou možnost, než trávit ty, co neakceptují pravidla slušného chování trávit jejich vlastním jedem. Je to prostě o tom, koho to dřív přestane bavit. A tu radost, abych po mnoha letech na tomhle portálu tak jako mnoho jiných bloggerů, v tichosti rezignoval a zmizel, jim zkrátka udělat nechci.
Takže jsem jim nachystal takovou malou past. 
zkus tu jinou ip adresu ty detektive, taky jsem ti kliknul. Ty jsi dobra betaverze Kojaka, seknul ses jen o 200 km.