Administrace komentářů

hodne experimentujem s Linuxom - Debian.

Tam čistota opravdu nehrozí. Na experimentování doporučuji solidní dostro, nikoliv nejhorší distro na světě.

Aby som tieto projekty rozbehal, je nutne nainstalovat kniznice a ine zavyslosti z repozitarov alebo kompilovane zo zdrojakov.

Na slušném distru se dá 99% tohoto ušetřit. Když zkusíš náhodných 20 projektů z GitHubu, aktuálních a udržovaných, prostě přeložit (dejme tomu) na současném Archu a závislosti si nainstaluješ ze standardních distribučních balíků, jak to má být, rozběháš těch projektů (dejme tomu) 18 z 20.

Na Debianu možná tak 5 z 20 a to budeš rád. Zbytek bude peklo, zastaralé verze, verze zmrvené pro Debian, a tak dále.

Nemluvě o tom, že na Archu je ultra-jednoduché udělat si PKGBUILD a všechno mít rovnou jako balíček (s korektní správou souborů a (od)instalací). Na Debianu je tvorba vlastních balíčků prakticky nemožná záležitost, pokud se tomu člověk nechce věnovat full-time.

Ako cas siel, z disku sa stalo jedno velke smetisko - cca 50GB projektov vlastnych aj cudzich proste bordel.

Zásda číslo 1: nikdy neinstalovat nic pod rootem přímo ze zdrojáků (stylem make install). Od toho je na slušných distrech fakeroot používaný balíčkovacím manažerem, už odnepaměti.

Záchrana číslo 1: prostě vyhledat ničím nevlastněné soubory mimo /home (leč bacha na /etc a na adresáře končící na .d atd.) a smazat je.

Dostal som sa do "dependency hell" stavu a problemy so zavislostami - rozbil som si Debiana.

Možná. V každém případě, Debian je rozbitý už sám od sebe, z principu.

Vysledok bol cisty reinstall a zahodenie vsetkeho balastu - ten bordel sa nedal ani rozumne vytriedit.

Ale ano, dal. Jenže na rozumném distru by především ani nevznikl.

Mal som supercisty zaklad na kancelarsku pracu s virtualboxom.

Proč takový šílený overkill? Pokud experimentuješ s několika instancemi téhož systému (stejná architektura, stejný kernel) a liší se jenom obsah souborového systému, od toho jsou LXC kontejnery.

Nejlepší tool na tohle je virt-manager a libvirtd. V jednom společném UI máš

• LXC kontejnery pro práci na stejném kernelu / architeture,
• akcelerované KVM+qemu virtuálky pro jiný systém na stejné architektuře a
• taky emulované qemu virtuálky, když chceš třeba ARM nebo RISC-V mašiny.

Ale problem bola obsluha - virtualka fullscreen - nevedel som si na to zvyknut, odozvy misi a klevesnice - bolo tam citelne mikrooneskorenie.

Když chci nativně fungující virtuálku (například FreeBSD jako virtuálku v Linuxu), dám té virtuálce přes virt-manager + KVM celou grafickou kartu přes VFIO, například celou tučnou NVidii v eGPU. A k tomu taky nějaký ten Thunderbolt USB hub (skrz PCIe + VFIO). Pak má prostě (de facto) nativní výkon.

Pokud jde o virtuálku v okně, zpoždění není tak hrozné, když si tam v KVM zprovozníš virtio, k tomu případně Spice, a k tomu taky (skrz virtio) grafickou akceleraci.

Nicméně tohle↑ je pořád o scénáři typu jiný systém / jiný kernel. Pro stejnou architekturu + stejný kernel, jenom jiné soubory, potřebuješ LXC kontejner. Pak všechny starosti s latencí zmizí.

Strata vykonu bola citelna aj ked som robil len v jednej VM.

LXC → Nulová ztráta výkonu.

KVM + libvirtd virtuálka + virtio balloon + rozumně nastavené SMP → Zanedbatelná ztráta výkonu.

Stačí si vybrat.

Mate nejake napady ako udzat cisty system, nerozbit si ho a popritom si skusat a ucit sa.

Není třeba mít nápady. Stačí používat standardní a desetiletími prověřená řešení (místo ad-hoc hacků všeho druhu):

1. Udržovat si Btrfs subvolume se základním, fungujícím a dobře udržovaným systémem (pouze standardní balíčky, vždy aktuální, atd.).
2. Z toho si odvodit (copy-on-write, klasika) subvolume pro každý experimentální systém.
3. Nastavit si automatické inkrementální (nebo klidně exkrementální) zálohy pro každý subvolume, na kterém záleží.
4. I mezi automatickými zálohami si to klidně klonovat a snapshotovat, jak je libo.
5. Subvolume potom použivat jako kořenové filesystémy pro různé LXC kontejnery, podle libosti. Nějaký subvolume pro /home mezi nimi třeba může být sdílený, pokud je to žádoucí. Nebo taky nemusí.
6. Když nějaký kontejner zastará nebo když se začne od originálu příliš lišit a nevyužívá už tím pádem copy-on-write tak, jak by mohl, vytvořit zkrátka nový, aktuální klon základu, přenést to podstatné, starý klon zahodit (a v automatických zálohách nechat jeho verze postupně vyhnít).

Hlavně je potřeba na takové věci trochu myslet předem, dřív než uživatel začne vytvářet bordel.