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 »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Myslím, že každý linuxový admin čas od času narazí na problém, který v danou chvíli překoná tím, že něco oprasí aby mohl pokračovat dál, než aby se zdržoval dohledáváním postupu „jak onu situaci vyřešit správně”. Takže raději oprasí blbě napsaný postinstalační skript. A je to vůbec chyba? Jo kde jsou ty časy, kdy bylo možné nějaký operační systém možné považovat za stabilní.
Nikoliv stabilní v tom smyslu, že by nepadal. Ale v tom, že se u něj stabilně vyskytovaly chyby, které se daly dokumentovat. Dnes je doba překotných změn. Kdo by ztrácel čas dokumentací chyb, které už jsou možná opravené? Jenže co když opravené nejsou, protože se projeví jako chyba jen za určitých okolností? Dnes chtějí všichni všechno hned a nepřemýší nad tím, že ten nejnáročnější úkol pro admina není něco rozběhat, ale udržet to při životě. Už minule jsem tohle téma naťuknul přes takovou malou alegorii.
Prasení, které umožní rychle překonat nenadálou situaci, je cesta do pekel. Ale má své opodstatnění, pokud se potřebujete dostat dál, abyste mohli něco vyzkoušet. Problém je, že se to špatně dokumentuje. Obzvláště v prostředí disklessových strojů co používají overlay, kde se při restartu všechno zahodí.
Právě takové stroje jsou však ideální, pokud si chcete vyzkoušet co se bude dít, když chcete otestovat neznámý software, vyzkoušet instalaci neznámou distribuce, nebo prozkoumat stroj o kterém vůbec nic nevíte.
Užitečnou aplikací je v takovém případě asciinema. Umožňuje totiž zaznamenat a zpětně přehrát vše co se dělo na konzoli. Díky ní lze do detailu zaznamenat celý průběh aktualizace, takže není problém zpětně analyzovat i komplikace, které se při tom vyskytly, včetně toho, co a jak bylo nutné oprasit aby bylo dosaženo cíle.
Když připravuji novou vrstvu nebo testuji software, který není distribuční, pomáhám si tím, že obsah z overlaye ukládám do speciální vrstvy sdílené přes NFS a než to smažu, prozkoumám jaké změny nastaly. A co jsem spouštěl zjistím ze souboru .bash_history.
U headless strojů s overlayem využívám dynamický ramdisk, který stahuje a spouští skript debug Ten posílá log na server. A když se vyskytne nějaký problém, dá se díky tomu zpětně zjistit co akdy ho způsobilo. Kromě toho máme díky tomu přehled o tom, jak často jsou ty stroje využívané a když by to bylo nutné, víme i kdo na nich zrovna v tu dobu pracoval.
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.
Naše laboratorní disklessová struktura je postavená na Debianu – především kvůli jeho balíčkovacímu systému. Ale používáme i software, co není distribuční. V minulosti, než se do jádra dostal modul overlay, který umožnil sendvičovat více vrstev (2016), se takový software instaloval do adresáře /opt který se pak přesunul do samostatné vrstvy. Od roku 2019, se instaluje takový software do samostatných vrstev.
Oddělením distribučního software od nedistribučního do samostatných vrstev se proces administrace disklessu výrazně usnadnil. Chtěl jsem jít ještě dál a rozdělit distribuční vrstvu na systém, který by byl nezávislý na softwarovém balastu, který sebou další aplikace, používané v desktopovém prostředí, ale už na to nebyl čas. Snížil by se tím objem dat, co se honí po síti v okamžiku spuštění disklessového systému a zjednodušil proces aktualizace.
V současné době probíhá aktulizace tak, že udělám snapshot distribuční vrstvy, který vyexportuji přes NFS pod novým fsid. Ten připojím do výše zmíněného virtuálu. Přepnu na něj přes systemd-nspawn, zaktualizuji, a pak v konfiguraci onoho virtuálu přepnu systémovou vrstvu a ověřím, zda-li je vše OK. Pokud ano, nahradím v ostré konfiguraci původní vrstvu za novou, přes budíka nastartuji všechny laboratorní stroje a obejdu laborky abych zjistil co žije a nežije.
Pak následuje období, kdy čekám zda-li někdo přijde s tím, že má problém. Většinou se to dá vyřešit na počkání, ale pokud někdo přijde, v době kdy běží výuka, s tím, že chce doinstalovat či aktualizovat nějaký distribuční balík představuje problém. Ne kvůli tomu, že by to byla velká komplikace, ale proto, že je potřeba najít vhodné časové okno, kdy je to možné realizovat. Pro mnoho lidí je těžko pochopitelné, proč dělám takové drahoty, když chtějí doinstalovat pouze jeden balík, jenže v současné době má distribuční vrstva téměř 11GB, které je potřeba po takové aktualizaci znovu nasypat do keše. A to sežere nějaký čas. Obzvláště když nahodíte současně tolik strojů. Pokud bych měl už základní systémovou vrstvu oddělenou, nebyl by to až takový problém ale teď je to "zábava" na celý večer. Obzvláště když ji "zpestří" studenti tím, že vyškubou některé laboratorní stroje ze zásuvek.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
apt full-upgrade nebo apt-get dist-upgrade?Musím říct, že jsem si oblíbil systemd-nspawn. Většinu aktualizací dělám v disklessovém prostředí s jeho využitím. Také jsem začal ve větší míře vyžívat apt. Ale už jsem se s těmito nástroji dostal i do šlamastiky, ze které mi pomohl chroot na straně NFS serveru a starý dobrý apt-get.
Způsobil to příkaz apt full-upgrade, který se zacyklil při aktualizaci systemd.
Mimochodem ví někdo, jak docílit toho, aby postinstalační skript grub-pc.postinst vynechal grub-probe, když se ten balík instaluje na systém, který žádný disk nemá?
Nedávno jsem narychlo potřeboval upravit na jednom stroji skript, na který jsem už delší dobu nesáhnul. Byla to jen drobnost, kterou jsem ale pochopitelně chtěl promítnout do aktuálního kódu. Jenomže ten se od doby, co jsem ten skript nasadil do produkce docela hodně změnil. Potřeboval jsem tedy zjistit, od které revize bych se měl odpíchnout.
Vytvořil jsem si tedy nejdřív seznam revizí onoho souboru, s jejich kontrolními součty:
user@stroj:~/git_repo$ for i in $(git rev-list --all -- soubor.sh); do echo -n "$i " && git show $i:soubor.sh | md5sum ; done > /tmp/revize
Otestoval, zda současná verze souboru má kontrolní součet stejný jako v posledním commitu:
user@stroj:~/git_repo$ md5sum soubor.sh 7ed0f6f3be657a1b31c3307071608f59 soubor.sh user@stroj:~/git_repo$ grep -n 7ed0f /tmp/revize 1:3ec4bc4a75d751863129346caab3c1bb96469a95 7ed0f6f3be657a1b31c3307071608f59 -
Bylo to ok, takže jsem podle kontrolního součtu verze, co ještě neobsahovala onu úpravu dohledal commit, od kterého jsem se mohl odpíchnout.
user@jinde:~$ md5sum soubor.sh.orig ca921b50be87709890028bb8c653bcd4 soubor.sh.orig
user@stroj:~/git_repo$ grep -n ca921 /tmp/revize 3:a55692c515c1dc7f13690afc73cdff9069b5683b ca921b50be87709890028bb8c653bcd4 -
Chtěl jsem tenhle postup použít i při jiné příležitosti, ale git tentokrát žádnou revizi nevypsal. Trochu mě to zaskočilo, než jsem si uvědomil, že je soubor co mne zajímal součástí adresáře uvedeného v .gitignore
Tiskni
Sdílej:
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á.
velmistr je v dojmu, ze VYMYSLEL diskless, jeho napad, nic takovyho neexistovalo
asi by ti to proslo, kdybys twl nepsal na portal, kde TLDP cetli asi vsichni, tam je popsanej diskless od kdy, ty borecku
senilnis nam dedecku, kdyby aspon do roztomila...
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áš.
ze ty to tak nevnimas, ze si to pred sebou nejak zas okecas... holt realita kope
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í.
kolik treba zbylo z toho slavnyho terminalovyho byznysu, co nam tady cpali kdysi horem spodem? celej svet sel proste jinudy... uz svita, nebo porad nic?
nebo fakt nechapes psanej text?
ale s tim "ocividne", cece, to asi neklapne, ocividny je jen to, ze ti to proste nepali, ze ti doba utekla a ze jsi akorat rozmrzelej starej dedek, kterej uz si nic podstatnyho sam o sobe neprizna tak si tu svoji nadutost vezmi s sebou klidne do hrobu
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.
https://www.novinky.cz/clanek/internet-a-pc-muskuv-neuralink-narazil-na-problem-pacientovi-se-zacal-odpojovat-cip-od-mozku-40471172
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.
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. Proste nehrozi tuny klientskyho zeleza, kde ma cenu resit netboot. To. Fakt. Nikoho. Nezajima. A uz ani zajimat nebude.
8.5.2024 00:45
xkucf03 | skóre: 49
| blog: xkucf03
otevri oci a sleduj realnej svet, misto svyho klasickyho dumani nad necim, co je mimo realitu jo vlastne to zrovna ty vytrvale demonstrujes, ze vubec neumis, tak to nic, to sorry vy jste tady na sebe borecci fakt zbyli, to je dobra show demence
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
ukladam si link na tuhle diskuzi, tady je krasne videt, jaci mentalni atleti poslali abclinuxu do hrobu 
od ceho zbylo abicko? aby bylo kam chodit trollit takovyhle debilky, co jsou tak moc mimo realitu, ze kdyz jim to nekdo naznaci, tak delaji takovy vyvrtky, aby zustali ve svy verzi vnimani reality, ze jsou to primo mentalne akrobaticky kousky coz ovsem nemuze nikdo, kdo chce rozumne diskutovat, vubec potrebovat, takovejhle odpad - za mne je jasno, kdo tu z toho nadelal zumpu. Takovahle demence. Pocit vlastni vyjimecnosti, s kterym se neda hnout.
Ty si pokracuj ve svy linii, jak potrebujes. Napsano je tady toho az prilis, aby z toho bylo az moc jasno. To uz nespravis Muzes ze sebe udelat akorat jeste vetsiho debila. Sanci vylepsit obrazek o svy zbytecnosti uz jsi mel Pozde.
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.
