Ódákat énekelne a Void kicsi hardvere igényeiről, megbízhatóságáról és hasonlókról. Kérdésem azokhoz akik használnak is Void Linuxot: Valóban kisebb a ram igénye a Void-nak mint egy alap cinnamonos Linux Mintnek?
Mennyire stabil a Void? Az én elvárásaimnak például az Arch nem felel meg, mert bizony ott néha eltörik egy-egy csomag még Minten hasonló sokkal ritkábban fordul elő.
- 1051 megtekintés
Hozzászólások
Attól függ hogyan használod. Ha nagyon fullos DE-vel, akkor nem sokkal kevesebbet, nincs systemd, lényegében annyi csak az eltérés, helyette runit van, ami hagyományosabb, egyszerűbb. Tehát ha Cinnamonnal használod a Void-ot, akkor kb. a Mint fogyasztását fogja produkálni.
Ha viszont valami soványabb ablakkezelő, akkor jelentősebb lehet, bár ez meg megint Minten, Ubuntun is reprodukálható, mert arra is fel tudod tenni ezeket az ablakkezelőket, meg ki tudod belőlük gyomlálni a sallangokat.
Amondó vagyok, ha az Arch nem felel meg, akkor a Void nem lesz neked való, mert kb. ugyanaz, ugyanúgy rolling meg minimalizmusra gyúr, ha az egyiken gondod volt, a másikon is ugyanaz vár rád. Bár a Void egy kicsit óvatosabban pörgeti a verziókat, de a Mint-hez képest még mindig bleeding edge.
Félre ne érts, nem akarlak teljesen lebeszélni a Voidról, mert szerintem nem rossz, egy jó fél évig én is használtam. Nekem az volt a bajom, hogy kis disztró, kevés csomag van a tárolójában, az xbps-src sem váltotta ki az AUR-t, így egy csomó mindent kézzel kellett forgatnom, ami eléggé megszivatott. Ilyen Shitpak, Snap(sz), meg egyéb konténerizált szemetet meg nem akartam alá felpakolni.
Summa summárum, a rendszered fogyasztása leginkább a grafikus környezettől, és az általad használt programoktól függ inkább, mint a disztrótól. Ha kevés a RAM-od, bővítsd, ha nem tudod, akkor használj soványabb ablakkezelőt, WindowMaker, IceWM, JWM, Openbox, be lehet ezeket konfigurálni szépre, monderne, de ijesszen el, hogy alapértelmezésben rondák. Esetleg DE-kből megpróbálhatod a soványabbakat, LXQt, Trinity. Vagy a másik irány, tiling WM (i3wm, bspwm, stb.), de ahhoz kell megint egyfajta minimalizmus, meg haladó szint, hogy megtanuld értékelni, a tilinghoz egész másmilyen workflow kell, főleg terminálos-billentyűzetes, ha te még nem vagy azon a szinten, iszonyat frusztrálni fog.
A konténerizált csomagformátumos programok, meg az Electron appok is kerülendők, ha kevés a RAM-od, mert azok betöltik a saját függőségeiket, nem a rendszeren lévő-futó példányokat használják, meg webes bloat növeli a memóriaigényt az Electron-alapúek esetén, mert lényegében egy álcázott Chrome-ban futnak.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Arch-on időről-időre eltörik egy-egy csomag. Ilyen van Void-on is?
"Shitpak, Snap(sz), meg egyéb konténerizált szemetet meg nem akartam alá felpakolni."
Egyáltalán működik a snap void linuxszon?
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy más csomagokat használunk, én kb. 8 éve Arch-ot használok, és kétszer volt olyan eset, amikor nem volt teljesen egyszerű az upgrade. Az a két eset a honlapon le volt írva, mint ismert hiba. Kb. 20 perc volt a javítás. Ráadásul még AUR-t is használok (yay).....
- A hozzászóláshoz be kell jelentkezni
Persze, nekem sűrűbben volt, kb. 8 éve használom én is, évente kb. 2× kell beavatkozás, az is teljesen egyértelmű felülírás, körkörös függőség, aláírási kulcs felvétele/frissítése, és szinte mindig ki van írva a weboldalukon is.
Ráadásul én valami 5 éve Testing tárolókkal használom, úgyhogy duplán kísértem a szerencsét, és nincs belőle nagy baj. A Testing idáig 1-2× okozott gondot, de az sem volt nagy szám, kisebb kényelmetlenség, és nem is csomag bug volt, hanem a Testingben frissült egy csomag, ami egy másik csomagnak volt a normál tárolóban függősége, de az meg nem volt még felkészítve, hogy a függőségek hamarabb frissülnek, mint ő maga. Két ilyen csomag is volt, qBittorrent (ami a túl gyakran frissülő libtorrent-rasterbar) és keepass-cli (ami a Perl alapú Rijandel modul) függőségeiket nem voltak képesek lekövetni, rendszeresen fordul elő.
AUR-t is használom elég intenzíven, de yay helyett már vagy 5 éve paru-val. Azzal most volt egy gondom, mármint nem a paru-val, hanem az AUR csomagokkal. Egyes csomagok túl régen voltak fordítva (2+ éve), és pár fagyást okozott (alock, meg 1-2 alap X-es tool). Így a paru cache-ének törlése után újrafordítottam, újratelepítettem az összes AUR csomagot, azóta jó. Ilyenbe előtte nem futottam bele.
Az Arch mindössze csak kétszer tört el iszonyat durván, egyszer a sysvinit-systemd váltásakor, ekkor még nem használtam, meg most 1 éve volt egy nagyon durva GRUB eltörés, de ez sem érintett mindenkit, engem meg pláne nem, mert jóval egyszerűbb systemd-boot-ot használok helyette. Ilyen nagy ritkasággal, Ubuntu, Mint, stb. is el tud törni, ott is számtalanszor előfordul, hogy NV driver vagy GRUB lehal frissítéskor. Debian még rosszabb is, mert ott sokszor ha van valami bug, amit kiadás után fedeznek fel, azt csak a következő főkiadásban javítják, a jelen kiadásban kb. soha.
Ami még el tud törni, azok a nagyon komplex, túl sok függőségre támaszkodó szoftverek, a KDE hírhedt erről, de nem csak Arch-on, hanem bármin, ami nem kifejezetten egy készre csiszolt régi verzióval kiadott, kifejezetten KDE-s disztró.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Bár ezzel eltérünk a témától, de akkor már miért nem Gentoo Arch helyett?
Ott nemcsak forrásból lehet optimalizáltan fordítani, de számtalan patch is csomagkezelő szintjén use flagekkel kényelmesen állítható. Sokkal egyszerűbben mintha le kellene vadászni a patcheket majd feltéve az eredeti forráskódra lefordítani. Systemd-mentes rendszert is lehet csinálni Gentooval, meg systemd-set is.
- A hozzászóláshoz be kell jelentkezni
Azzal is próbálkozok időről-időre. Ami tetszik benne, hogy a systemd-t, pipewire-t, initramfs-t nem tolja rá az emberre, meg még egyszerűbb lehet a bootolása (efistub boot, mikor a kernel közvetlenül boot-ol), de nagyon nagy kín annyit fordítgatni, meg USE flag-ekkel sok függőséget ki lehet zárni sok programból (pl. a Firefoxból ki lehet hagyni ilyen szutykokat, mint Pocket, Orca Reader, Pulseaudio, stb.). Nagyon nehéz benne mindent működésre bírni. És minden hibánál fordítás, újrafrodítás, megint próba, megint nem jó, megint újrafordítás, és csak forog-forog a kód, míg az ember nem használja a gépet, egy idő után elege lesz. Mindegy, azért neki-nekifutok, hátha egyszer kinövök a normiságból. Mindenesetre annyit fordítgatni, nem fehér embernek való, és teljesen mindegy hány magos a procid, szívás hosszútávon, eszetlen nagy időtemető. Persze ha kitapasztaltad, kész, bejáratott make.conf-fal megy neki, meg csomaglistával, akkor csak egyszer fordul már minden, meg csak frissítésekkor. De addig eljutni elég nagy kín. A próbálkozásaim számát lelassítja nem csak az, hogy mostanában kevesebb időm van rá, hanem mikor van is egy kevés, az kell másik, félbe hagyott projektre, meg a FreeBSD felé is kacsintgatog egy próbagépen.
A másik, ami nem tetszett a Gentoo-ban, hogy a verziók nem olyan frissek, mint Arch-on, és bár ki lehet hekkelni -9999 végű csomagokkal, de azok meg rettenet instabilak. Ahogy dakota közmondások tartják: „Ubuntu is an ancient African word, meaning I can't configure Debian”, továbbá „Arch is poor man’s Gentoo”. Aki nagyon szerencsétlen, annak „Manjaro is the Ubuntu of Arch” vagy „Manjaro is Arch for human beings” :D
Persze nálam az is gond, hogy túl minimalista setup-ot próbáltam építeni Gentoo-ból. Ha bekapcsolja valaki rajta a systemd-t, meg fullos DE-vel telepíti, pl. KDE vagy Gnome, meg genkernelt használ, akkor könnyebb telepíteni, de akkor meg az értelme veszik el az egésznek, annyi erővel fel lehetne tenni egy akármilyen mainsteam disztrót.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Nekem csak Manjaro-m volt (van is, de régóta nem bootoltam), de egyszer megszívtam vele, hogy upgrade közben leállt és utána nem indult el és nagyon nehéz volt újraéleszteni. A Debian származékok úgy tudom viszonylag tranzakcionálisan csinálják az upgrade-et és nem nagyon lehet ilyen állapot. Jól tudom ezt, és van-e megoldás erre az Arch világban?
- A hozzászóláshoz be kell jelentkezni
Egyszer elszállt nálam egy mintupdate. Utána Ubuntuként be lehetett fejezni az upgradet, apt dist-upgradeddel. Rendesen működik és továbbra is Mint-nek képzeli magát. A kövi upgradehez honnan lesz új mindupdate az még nyitott kérdés.
- A hozzászóláshoz be kell jelentkezni
Nem rossz cucc a void, próbáltam egy darabig gyenge vason de a runit/systemd difi nem hoz akkor különbséget, annyi hogy a booton nyersz vele picit, cserébe jóval vékonyabb a csomagválasztékod.
Ha szeretnél egy olyan disztrót ami egy összegyűrt papírrepülőn is elfut akkor Q4OS trinity-vel. Egész korrekt XP feeling kinézetet ki lehet hozni belőle és tényleg olyan mint az olajozott villám. Viszont a trinity tényleg időutazás ennek minden előnyével és hátrányával, egy xfce/cinnamon hozzá képest űrhajó.
- A hozzászóláshoz be kell jelentkezni
Köszi a tippet!
- A hozzászóláshoz be kell jelentkezni