Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Jo, protože pro nic lepšího nemají. Ta disklessová technologie je totiž můj nápad. V době, kdy jsem ji použil nic podobného neexistovalo, což se dá hravě dokázat. Nikdo si to tím pádem nemůže patentovat jako svůj původní nápad a rýžovat na licencích.
Jinak podobná infrastruktura se používá i jinde, jen o tom nemáš potuchy. Např. distribuované desktopy co poskytuje např. CITRIX jsou v podstatě to samé. Ovšem to, co mé disklessové infrastruktuře dodává ten punc elegance - dynamický ramdisk - zatím ještě nikdo jiný nepoužívá.
Ales vynalezl ohen, kolo a bezdiskove stanice…
Nevynalezl, ale na rozdíl od tebe ty technologie umím využívat ve svůj prospěch.
Nevymyslel jsem diskless, ale disklessovou technologii, která ho využívá. Kdyby ses obtěžoval pátráním po netu, tak bys zjistil, že teprve overlay umožnil zcela „odstřihnout” disklessový operační systém od lokálního blokového zařízení. To bylo technologicky možné až kolem roku 2011 a to moje prvenství spočívá v tom, že jsem na tom v roce 2012 postavil celou infrastrukturu. Nejde tudíž jenom o ty pracovní stanice, které jí využivají, ale i servery, které ji zajišťují.
Až se tedy posereš, tak se zkus schválně podívat, kdo kdy a kde prvně nasadil do produkce technologii, která se obejde bez iSCSI, AoE či lokálního blokového zařízení. Já se totiž – na rozdíl od tebe – po těch informacích pídil. Takže pokud něco věrohodného dohledáš.
To na co odkazuješ, je pouze jedna stránka věci, která pochopitelně patří do té skládačky protože bez toho, že by ten systém byl schopný fungovat přes NFS by to nešlo.
Problém spočíval v tom, že každý takový stroj vyžadoval, přinejmenším pro adresáře do kterých si ukládal své specifické soubory, na serveru vlastní vyhrazený adresář. Obcházelo se to různými způsoby. Můj nápad, je kombinace disklessové technologie s virtualizací.
obe technologie miri podobnym smerem - trh nezajima, jake jsou mezi tema dvema rozdily, on jde proste presne obracenym smerem
To teda ani omylem. Terminál je závislý na konektivitě. Typ disklessu mohu libovolně zvolit. Na konektivitě je plně závislý pouze Full-Diskless, pokud ten stroj najede jako autonomní Half-Diskless, funguje i bez ní. Problém je pouze s uživatelským profilem, protože se sdílí z centrálního úložiště na které se bez funkční VPN nedostane. Obejít se to dá přes lokálního uživatele guest, jenže ten má veškerá data jen v RAM, ale můžeš použít něco alá dropbox.
Také lze ten autonomní Half-Diskless nabootovat ve virtuálu, pokud si někdo sebou táhne vlastní zařízení, jak psal ňouma RealJ výše. Stačí vyrobit virtuální stroj – úplně jedno v čem, kterému se předhodí virtuální disk, ať se to má kam nakešovat. Podmínkou je, že ten virtuál musí napíchnout do laboratorní sítě a nabootovat přes PXE. Normálně najede a NIC se nemusí instalovat. Dokud ten virtuál nevypneš a budeš ho jen uspávat, tak to pojede – i offline. To u terminálů, ani jiných disklessových technologií nelze. A právě v tom je moje know-how.
Problém mu ovšem nastane pokud se to pokusí restartovat bez nastavené VPN mimo školní síť – nestáhne se mu konfigurace.
Píšu o tom úplně dole.
V čem je výhoda, že tam není? Jak ses ho zbavil? A tak...
To je jenom jedna z mnoha výhod. Když přijde někdo s tím, že mu zlobí notebook, první věc co uděláme je, že to píchnem na laboratorní síť a přes PXE najedem laboratorní systém, kde je k dispozici přehršel nástrojů, které umožní o tom stroji něco zjistit, aniž bys mu hrabal na disk. A pokud něco chybí, není problém to doinstalovat. Také to můžeš odzálohovat do nějakého forensního formátu a zkoušet různé kejkle, aniž by hrozilo, že se to ještě víc rozesere. Nemusíš řešit žádné bootovací USB, CD mechaniku a já nevím co ještě. U nových křápů co nemají ethernet to můžeš najet přes USB ethernetový adaptér.
Výhoda, kterou slepičí mozky zdejších anonymů nikdy nepochopí, je také v tom, že pracuji přímo s FS. Nepotřebuji žádné opičárny k tomu abych něco dohledal. Je to jenom pár adresářů exportovaných v read-only módu přes NFS. Takže to nejde hacknout. Nejrychlejší oprava je reboot. Ovšem to je až ten poslední krok.
A jak jsem se ho zbavil? RAM0 + virtuální disk (soubor) exportovaný přes NFS, stejně jako zbytek. Má to jediné slabé místo - firewall, ale to už je věc, kterou má pod palcem SVTI. Ta infrastruktura ho nepotřebuje, protože uvnitř se to baví přes virtuální switch.
Proč bys něco kopíroval do ramdisku? Tam se natáhne jen soubor, který změníš. Když spustíš find, nakešuje se jen adresářová struktura. Samozřejmě se dá vytáhnout všechno do ramdisku. Ale proč bys to dělal?
Half-Diskless pracuje s keší, ale podobně.
Už nic, protože se spouští hotový sendvič. A ten může být sestaven z více zdrojů. Z jakých, to je dáno konfigurací. Můžeš kombinovat NFS, lokální bloková zařízení, squashfs, distribuované souborové systémy, iSCSI, atp. Z pohledu uživatele je to jeden adresář.
Nakešování se využívá u vrstev co se často nemění. Není nezbytně nutné, ale významně snižuje traffic. Máme laborku, která je před rekonstrukcí. A tam je tak mizerná kabeláž, že některé stroje jedou jen 100 Mbit. Díky kešování se po síti honí jen data sdílená z uživatelského profilu v centrálním úložišti.
Proč? Víš jak funguje paměť v mozku? Je to stejný princip. Ten /
je stejný bod, k jakému dojdeš když se pokusíš dobrat k tomu kde jsou uložena data "kontejneru", který ti vyšrotil tenhle dotaz. Ten mimo data vybalená z RAM, rovněž zpracovává vstupy z fyzických zařízení a souběžně data sdílená.
Ve stejné době, kdy jsem se dostal k internetu u nás vyšla kniha Frederica Vestera Myslet, učit se - a zapomínat?, která mne velice zásadně ovlivnila a vývoj se, pro mne zcela nepřekvapivě, ubírá k bodu poznání, že skutečná umělá inteligence sebou přinese stejné nedostatky, jaké má lidský mozek. Když ho během vývoje nenaučíš filtrovat a zapomínat blbosti, tak ve fázi, kdy ho budeš krmit převážně blbostma, ztratí schopnost učení.
Konec konců, rozhlédni se kolem sebe. Dřív bylo informací málo. Ne každý se k nim dostal. Ale když už, existovala velká pravděpodobnost, že ho někam posunou, protože vysoké náklady na jejich publikaci představovaly primární filtr, který bránil publikování volovin. To se ovšem v průběhu 20. století změnilo. Dnes se naopak publikuje tolik volovin, že je velice obtížné mezi nimi najít validní informace. Už nestačí jen sehnat a přelouskat několik knih.
Mohu být konkrétní. Obvykle si na cestu vlakem kupuji nějakou knihu co mne zaujme. A tentokrát jsem si koupil knihu "Kronika zániku Evropy (1984 - 2054)". Zaujal mne název a jméno autora se mi spojilo s jinou sérií knih. Svůj omyl jsem zjistil velice brzy - prvních deset stránek, a bylo jasno že tenhle autor je úplně jinde než jsem čekal. Nicméně, přečtu si to, protože kniha vyšla v roce 2019, takže již mám možnost srovnání. I když z té úvodní kapitoly mi je už teď jasné, co je autor zač. Ostatně, letmý pohled do ostatní produkce svědčí o zálibě ve fabulaci a svévolné manipulaci s fakty. Jako že konání osoby A je spojováno s osobou B, jen aby se osoba B jevila coby osoba hodna opovržení. A naopak.
cat /proc/mounts
?
overlay / overlay rw,relatime,lowerdir=/tmp/opt12:/tmp/opt11 :/tmp/opt10:/tmp/opt9:/tmp/opt8:/tmp/opt7:/tmp/opt6:/tmp/opt 5:/tmp/opt4:/tmp/opt3:/tmp/opt2:/tmp/opt1,upperdir=/tmp/unir w/over,workdir=/tmp/unirw/work 0 0
/tmp
je předpokládám ramdisk. Co jsou ty /tmp/opt*
? Jen adresáře na tom ramdisku?
/tmp/opt...
může být cokoliv. Jsou to mount-pointy, všimni si, že jdou kontinuálně za sebou.
Je tam popsaný princip. Distribuční ramdiskový skript nfs
, je napsaný tak, že vyžaduje parametry předané jádru při zavádění, což je dost limitující. A pokud je něco špatně, zůstane viset ve smyčce, kdy se tvrdošíjně snaží namountovat z NFS serveru sdílený adresář, kde je systém. Příčin, proč se to nepodaří, může být mnoho. Jenže je kvůli výše uvedenému chování nemáte šanci odhalit.
Velké množství parametrů předáváných jádru zas komplikuje konfiguraci zavaděče. Obzvláště v prostředí kde je obsluhováno větší množství subnetů a kde mají stroje rozdílné HW vybavení.
Mým cílem bylo maximálně zjednodušit konfiguraci zavaděče a zároveň skrýt skutečnou konfiguraci před potenciálními všetečky. U klasického disklessu stačí ke zjištění zdroje cat /proc/cmdline
. V rámci mé infrastruktury je vidět pouze sada přípojných bodů, na které byly namountovány v ramdisku jednotlivé vrstvy, ovšem v jakém pořadí a odkud, může zjistit pouze lokální root. Ani nevím, kolik těch vrstev overlay ustojí. Musel bych se podívat do kódu. Klasický diskless podporuje pouze jednu.
Vrstvený OS ani koncept virtuální laboratoře není můj "patent", inspiroval jsem se starším projektem Lablink, kvůli němuž jsem se vůbec na ČVUT ocitnul. Ovšem s ním má naše disklessová infrastruktura společnou právě jen tu ideu.
V podstatě ano. Až na to, že stroje v autonomním Half-Diskless módu natahují nakešované soubory (jádro + ramdisk). Pak následuje fáze, kdy se ověřuje dostupnost ethernetové sítě (podle toho jádro pozná jestli může rovnou pokračovat, nebo zda-li má pokračovat konfigurací wi-fi). A po ní teprve následujuje stažení konfigurace a všech potřebných ramdiskových skriptů.
Shrnuto. Mezi „natáhne jádro včetně ramdisku” a „pomocí overlay namountují jiné FS” je 3 a více fází (podle konfigurace) které se postarají o to, aby na těch mountpointech něco bylo. Nevík kolik těch mountpointů může být, našel jsem zmínku, že historicky jich mohlo být jen 127. A systémových vrstev může být použito také více než jedna. Původní sendvič, používaný do roku 2019 vyžadoval, aby byla systémová vrstva na pozici první. Od roku 2019 lze naopak s výhodou prostřednictvím pozice vrstvy ovlivnit co z toho vyleze. Potenciálně nebezpečné vrstvy – tj. takové do kterých byl mohl někdo zapsat soubor, kterým by ohrozil bezpečnost, jsou dole. Naopak ty klíčové, které se starají o finální konfiguraci jsou nahoře. Systémová vrstva je generická. Jako když si nainstaluješ systém přes debootstrap. Většina problémů co se řeší jsou prkotiny dané konfigurací. Chybějící symlink, překlep v konfiguraci, atp. Zablokování aplikace? Stupidně prosté. Přeplácneš ji symlinkem.
A kdyby byl takový požadavek, mohu tímhle triviálním způsobem zajistit i to, aby se uživatel dostal jen do svého kontejneru. Zadání však bylo jiné – udělat blbuvzdorný systém co se nedá rozbít, i když zná uživatel heslo roota.
Člověče, nasadil jsi mi brouka do hlavy a tak jsem rovnou vyzkoušel, z kolikati vrstev se ten overlay dá skutečně sestavit. Teoreticky je možné seskládat „jedním tahem” větší množství vrstev, ale díky tobě jsem zjistil, že existuje limit, který je dán maximálním počtem znaků, který je schopen sežrat příkaz mount v rámci jednoho parametru (max. 257). To v reálu znamená, že při mé současné konvenci pro zakládání mountpointů je max. 23 vrstev, ovšem triviální úpravou skriptu to mohu vytáhnout na 67, což je maximální počet, jakého lze dosáhnout v rámci jednoho příkazu mount. Pak už by se muselo splácat více overlayů.
Teoretické maximum zdrojů se může pohybovat v řádu desetitisíců, pokud by se zdroje připojily na mountpointy /<znak><znak>/<znak>
a sestavené sendviče na mountpointy /<znak><znak>
. Ale obávám se, že to už bychom nepochybně narazili někde jinde.
Nicméně, přečtu si to, protože kniha vyšla v roce 2019, takže již mám možnost srovnání.
OT: Přes veškerou snahu jsem to nedal.
Dokousal jsem se ke straně 130 a dál už to nešlo. Přemýšlel jsem co s tou bichlí. Do kontejneru, ani na hranici, knihy ze zásady nehážu tak jsem alespoň vepsal na titulní list, pod autorovo upozornění že jde o literární fikci, co si o to myslím s datem a douškou aby čtenář skočil rovnou na stranu 400, aby si mohl udělat přestavu o kvalitách „prognostika” o kterém autor píše. A pak to pohodil dole v baráku, doufaje že si ta kniha najde nového vlastníka, který pro ni bude mít využití.
Už jsem na to prostě neměl žaludek. Ta relativizace podílu komunistických oportunistů na pokřivení morálky tohoto národa už byla neúnosná. Dějové schéma založené na klasickém rčení „po bitvě je každý generál” pochopitelně jen stěží mohlo předpokládat jak rychle vezmou za svá lidská práva, když je dav vyděšený. A tak se autor drží jak hovno košile katastrofické vize, kde Evropu ovládnou muslimové – proto také ten můj odkaz na stranu 400. Kde bujná fantazie autora vykouzlila na rok 2024 muslimské povstání ve Francii.
.. odmita pochopit, ze overlayfs prislo v dobe, kdy uz netboot nikoho nezajima, jinak by to tak proste delali uplne vsichni.
Tvoje interpretace reality je opravdu úžasná. Pro takové chytrolíny obvykle používám konstatování: „Blbý jak troky”. Nedávno použil kolega stejnou technologii v rámci akce, která se konala u nás na škole.
Na to, aby to dělali všichni by museli mít potřebné znalosti sami, nebo zaměstnávat lidi co ty znalosti mají. A jaká je situace tam, kde by se tohle hodilo nejvíc, tj. na školách a úřadech, je všeobecně známo. Já na úřadě pět let dělal a stále mám odtamtud informace z první ruky, takže si o tom myslím svoje. Bootování po síti v době kdy jsem tam dělal sice bylo možné, ale přesto se nepoužívalo, protože většina síťových prvků neměla dostatečnou propustnost. I dnes je to limitující prvek, což je nejlépe vidět v situaci, kdy se klonují v laborce ze serveru na lokální disk MS Windows.
A to se v zájmu bezpečnosti zavádějí ještě větší vypečenosti, které už hraničí s absurditou. Ale ti co na ně naráží se nechlubí s tím co musí řešit, aby nebyli za blbce. A úroveň IT na VŠ? Je to různé. Všichni jsou jak šneci zalezlí ve svých ulitách. Faktem ale je, že se nich vyskytují jak lidé schopní, tak i takoví co přijdou se zcela absurdním požadavkem, aby se pro jejich potřebu nakupovaly pouze stroje, které podporují už víc jak 7 let nevyvíjený software.
Zatimco typicky uzivatel linuxoveho desktopu pouziva polofunkcni softver, data ma lokalne a v pripade jakekoliv nenadale udalosti je proste v prdely. Diky tomuhle ne linux tak popularni a je nasazovan vsude na desktop.
Takhle se ztrapňovat v diskuzi, kde se hovoří o disklessu. A kampak by ten linuxový desktop asi ty data lokálně uložil, když žádný disk nemá?
Finalne k tomu napisu, ze netboot se squashfs+overlayfs se normalne pouziva - ale v datacentrech!
Jenže klíčové je od kdy. Sám ses tu usvědčil ze lži, protože jsem tohle řešení použil dříve než se ty datacentra začaly stavět. A pokud to chceš rozporovat, není nic snazšího. Uveden konkrétní datacentrum co to takhle využívá a od kdy.
Mezitim ale svet dneska cim dal vic kasle na centralni spravu _klientskych_zarizeni_, pryc jsou doby, kdy bylo osobni pocitani cenove nedostupny, takze proste lidi delaji na svym, plusminus par exot(ickych) setupu.
Kašlou na to ti, co se o ně nemusí starat. Ty sám jsi názorným příkladem hloupnutí, protože si nedokážeš představit náš use case.
protože jsem tohle řešení použil dříve než se ty datacentra začaly stavětjo, finalni potvrzeni, ze si na spicku nosu nevidis, ze to neni zadna nahoda, ze si fakt myslis, ze jsi to ty _vymyslel_, nemam dalsich otazek, ctihodnosti, pekne jste se uvarili
Krásná ukázka toho, jak z někoho udělat blbce recentním opomenutím klíčového slova. Diskless technologie, je postup který nějakým způsobem ten diskless využívá, ne jen pouhý diskless. A vím, že ho takhle nikdo jiný dřív nepoužil, protože se - na rozdíl od tebe - o ty technologie už 15 let zajímám, takže vím, kdy se technologie podobné tomu co používám objevily.
Nejhůř se zkoumá to, co se děje v ramdisku. Proto veškeré změny testuji nejdřív na virtuálu, jehož displej nahrávám přes vokoscreen. Uložené video si pak otevřu avidemuxu, kde ho mohu zkoumat snímek po snímku. U fyzického stroje je potřeba připojit monitor a klávesnici a pak si to buď nahrát na mobil, nebo opakovaně rebootovat, až se dostanu do bodu kde vzniká problém.A co ze v praci delas? Hackujes kamery ze sprch?
Přečti si laskavě co jsem napsal o něco výš. Pro mne je diskless systém takový, který ke svému běhu co nepotřebuje žádné blokové zařízení. V rámci serverové disklessové infrastruktury, která zajišťuje obsluhu dalších zařízení využívám virtuální blokové zařízení jen pro zavaděč. Jakmile stroj nastartuje, už ho nepotřebuje.
U pracovních stanic je to jinak a také to má jiný „use case”. Ty co jsou připojeny ethernetem kombinují diskless s lokální keší, protože se tím výrazně snižuje síťový traffic. A ty co jedou přes wi-fi, jsou plně kešované, aby fungovaly i bez konektivity.
Primárním cílem bylo sjednotit SW vybavení a zajistit, aby se operační systém na těch strojích nedal nabourat. Samozřejmě jsou ty stroje blbuvzdorné jen do mentální úrovně svého uživatele. Ten kdo k takovému stroji zasedne, aniž by ho předtím restartoval, nebo od něj odejde aniž by se odhlásil, nebo ho vypnul, si za případné problémy může sám.
Sorry, ale ty seš vážně korunovaný vůl.
Šlo o soubor asciinema-player.js
, v git repozitáři z března 2017. Já teda nevím jak ty, ale 7 let je docela dlouhá doba na to abych zapomněl, že jsem ten tehdy v tom repozitáři spouštěl nějakou kompilaci. Pochopitelně mi to pak došlo, když mi to žádné revize nevypsalo. Uvedl jsem to tu jen proto, že se to může stát i někomu jinému, pokud si např. rozbalí nějaký starší tarball s git repozitářem.
Má, ale image per stroj, což je úplně jinde než to co používáme my.
Naše disklessová infrastruktura žádné image nepoužívá. Každý stroj si na základě konfigurace složí svůj sendvič a podle toho pak vypadá výsledek. A to, jakou konfiguraci má použít lze ovlivnit několika způsoby.
Ta elegance řešení spočívá v tom, že aktualizace OS po vyladění spočívá v editaci jednoho řádku a v případě že se přeci jen objeví nějaký problém, který nelze vyřešit v rámci některé výše položené vrstvy je stejně tak snadné vrátit se k funkční verzi.
U Half-Diskless strojů je to ještě o level dál. Problém je pouze v případě, který jsem zmínil v blogpostu. Jenže to je dáno tím, že u Full-Disklessu nehrálo roli kolik se toho do nějaké vrstvy nasype. A fakt není šumák, jestli se souběžně přetahuje několik desítek strojů o soubor v řádu megabajt nebo v řádu gigabajt.
Tiskni
Sdílej: