Dotaz: Ako si zachovat cisty Linux

[CistyDisk]

Ahojte,

hodne experimentujem s Linuxom - Debian. Casto skusam nove programy, ci uz aplikacie z repozitarov alebo priamo z zdrojakov na Github-e, ucim sa programovacie jazyky, sem tam poslem pull request do nejakeho projektu. Aby som tieto projekty rozbehal, je nutne nainstalovat kniznice a ine zavyslosti z repozitarov alebo kompilovane zo zdrojakov.

Ako cas siel, z disku sa stalo jedno velke smetisko - cca 50GB projektov vlastnych aj cudzich proste bordel. Dostal som sa do "dependency hell" stavu a problemy so zavislostami - rozbil som si Debiana. Vysledok bol cisty reinstall a zahodenie vsetkeho balastu - ten bordel sa nedal ani rozumne vytriedit.

Mal som supercisty zaklad na kancelarsku pracu s virtualboxom. V kazdej virtualke som si drzal prisposobene prostredie. Bolo to celkom dobre - bordel sa mi nerozliezal po disku. Ale problem bola obsluha - virtualka fullscreen - nevedel som si na to zvyknut, odozvy misi a klevesnice - bolo tam citelne mikrooneskorenie. Strata vykonu bola citelna aj ked som robil len v jednej VM.

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

Dakujem.

---

---

Odpovědi

[/]

druhy pocitac na hrani?

[Peter Golis]

Občas to na tom sandboxe preinštalovať, a viesť si denník čo k čomu človek potrebuje a čo k tomu je benefit (napr. knižnice ktoré poskytujú voliteľné benefity pre dané appky).

[Peter Golis]

Poprípade sa naučiť aj CI/CD pipeliny ktoré mu umožnia eho kód aj otestovať, hoci aj v nejakom kontajneri.

[Silverhead]

btrfs/zfs snapshoty?

Hypervisor and everything in a VM and snapshots again?

[X]

Kontejnery, ma to nizsi rezii. 50c

[Andrej]

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.

[Aleš Kapica]

Na Debianu je tvorba vlastních balíčků prakticky nemožná záležitost, pokud se tomu člověk nechce věnovat full-time.

Sorry, ale plácáš blbosti. Práce na full-time je to za předpokladu, že chceš svoje balíky dostat do oficiální distribuce. Pokud si děláš balíky jen pro svou potřebu, tak není problém.

Ten člověk v tom má evidentně guláš, takže si stadiem zabordeleného systému projde bez ohledu na distribuci. Debian mu ale naopak nedovolí ten systém rozesrat totálně. Jenom se musí naučit číst. APT je docela ukecaný a většinou se i snaží poradit co dál.

[Andrej]

Debian mu ale naopak nedovolí ten systém rozesrat totálně.

Ano, to mu skutečně nedovolí, neboť Debian je totálně rozesraný už sám od sebe v momentě instalace.

Možná by se to dalo přirovnat k onomu prazvláštnímu způsobu obrany před šířením požárů, kdy se cíleně vypálí pás pole nebo lesa, aby se potom přes spáleniště nedostal větší požár… Leč soudě podle tazatelovy nespokojenosti s výsledkem, tohle přirovnání nejspíš nesedí. (Spáleniště nepomohlo.)

Nelze než doporučit vyhnout se Debianu. Uživatel může nadělat spoustu chyb s každou distribucí, to bezesporu, ale není důvod si situaci od začátku komplikovat tou nejhorší distribucí.

Debian je totálně rozesraný už sám od sebe v momentě instalace.

A proto je to jedna z nejpoužívanějších linuxových distribucí na serverech.

[k3dAR]

Tradicni tve lži a demagogie...
Arch by pri stejnem pouzivani rosesral mnohem drive a casto i bez tech jeho pokusu...

Naopak pouziti kontejneru a nebo kvm virtualu mu pomuze jak v Debianu tak v Archu v podstate stejne...

Ale jinak Virt-Manager je urcite dobra rada, narozdil od jeho VirtualBoxu...

[=]

tak-tyvole-urcite

[!!!]

A četl jsi to, co odkazuješ? Jak tam na to nadávají?

A zkoušel jsi to v praxi? Nezkoušel.

[\]

virt-manager je sracka oproti cemukoliv, doporucovat mrtvej software, to musis bejt asi fakt expert, ale tak jako do tyhle mistni verbeze docela zapadas, to je cajk

[k3dAR]

Sam si mrtva sracka ;⁠-⁠)
https://github.com/virt-manager/virt-manager/commits/main

[!!!]

Ta mrtvá sračka, jak ty říkáš, krásně funguje. Na rozdíl od té tvé živé sračky, která má všechny závislosti, jako ta mrtvá, ale ještě bambilión dalších, kterými si akorát zasereš server a ve výsledku to, co dostaneš, nesahá té mrtvé sračce ani po kolena.

[---]

jo a taky se jeste podivej, z jak starych nazoru si ty delas ten svuj nador na mozecku, tyvole

[!!!]

Ten odkaz jsi postoval ty.

Nepotřebuješ silnější prášky?

[k3dAR]

5let stare hlody kdy virt-manager byl ve verzi 2.x, pritom 4.1 je z 2022/08 ;⁠-⁠)

[\]

to je ale hromada blitek napsat, ze strasne chces, aby ostatni vedeli, ze jsi totalni kokot, jde i kratsim zpusobem

Ty kreténe, radši napiš něco, v čem nemá pravdu.

[+]

ve vsem, dyt mele akorat agresivni agitacni hovna, kazatel viry, co o tom prakticky ale vi picu :D

Hulíš blbej matroš.

[-]

vic tam nemas? treba nejakou dalsi zarucenou radu?

Ještě se dá používat systemd-nspawn, "chroot na steroidech". Ve spojení s btrfs je to na některé věci dobrá volba.

[mikrom]

Zasadne veci zvyknem odskusat najprv na VM a az potom ak je to ok, tak to nasadim na pc. Pri instalacii aplikacii uprednostnujem SNAP ak je k dispozicii. (Debian pouzivat nemusim)

[Aleš Kapica]

Vy snad neumíte číst. Tazatel mastí do systému páté přes deváté, protože netuší jak ten bordel udržet v mezích a vy byste od něch chtěli aby používal technologie o jejichž existenci nemá drtivá většina uživatelů šajna.

[Bugsa]

Nainstaluj si Fedora Silverblue - immutable distro s kontejnerama a budeš to mít pořád čisté jak lilie.

[_]

Jj - kdysi jsem taky jednou slyšel o kamarádovi, co měl známého, který mu vyprávěl o příbuzném, kterému fedora fungovala - celé tři minuty v kuse!!!

[_]

Vo kilo ze rozmrda i Silverblua!

[frufru]

tak která je ta nejlepší distribuce? debian, ubuntu, fedora, manjaro, mxlinux, suse??

[IV]

NIX OS ?