Keresés

Hirdetés

Új hozzászólás Aktív témák

  • Frawly

    veterán

    válasz Apollyon #22051 üzenetére

    Nem kamuból futnak, hanem szükség van rájuk, mert futó szoftverek függőségnek használják. A leggyakoribb az elogind, de én systemd maradványnak tekintem már az udevd-t is, erre még rájöhet at-spi2-registryd, meg még fene tudja mi, én se tudok konkrét, kimerítő, tényleges listát, mert attól is függ, hogy konkrétan milyen programokat használsz, azok mit húznak be függőségnek.

    Azt mondom csak, hogy erre figyelni kell, nézd át a processlistádat, nyomozd ki mi mire való. Könnyen fel fogsz fedezni olyan elemeket, amik a systemd részimplementációi. Így pedig igenis az van, hogy egyszer fut a saját init-ed, meg még rá systemd-maradványok, meg részimplementációk, és semmivel nem leszel előrébb, mintha magát a systemd-t használnád, se erőforrásban, se sebességben.

    Hidd el, én is anyázok emiatt. Erre már az Arch a korai időktől fogva rájött, azért nem mennek ezzel szembe. Rájöttek, ha olyan nagy disztró akarnak lenni, mint a Debian, Ubuntu, és sok csomagfenntartót és felhasználót akarnak, akkor systemd-ügyben meg kell magukat adniuk, különben rétegdisztróként eltűnnek a süllyesztőben.

    Ha a systemd-ellenes utat választották volna, azzal egy csomó felhasználó életét megnehezítik, akik systemd-re dependelő programokat használnak, meg a csomagfenntartóknak is külön küzdelem, hogy hekkelt csomagot csináljanak egy csomó mindenből, meg sytemd-pótlékokról gondoskodjanak egy csomó csomagnál. Erre idő sincs egy valódi, bleeding edge full rollingnál, mert mire fejlesztőke elpöcsölget az anti-systemd-s hekkelésekkel egy csomagon, addigra az adott csomag fejlesztői ágon előrelépett 3-5 verziót.

    Persze, lehet széllel szemben hugyozni, én meg is fogom próbálni, újra és újra, de az Archot megértem, amiért nem akarták. Nekem pedig tetszene, ha próbálkoznának, és lenne támogatva alternatív init, de nem akarnak szélmalomharcra erőforrást elpocsékolni. Azt meghagyják a Gentoo, Alpine Jóskáknak, meg a kőkorszaki verzióknál leragadni szerető Devuan, MX partizánoknak.

    Így meg az van, hogy alternatív init támogatását nem az Arch oldja meg, hanem Arch-forkok, lásd. Artix. Sőt, az Arch ezért dobta a 32 bites támogatást is, mivel full rollingnál megint nehéz azt csinálni, hogy külön 32 bites ágat gondozni. Ezt átvette végül az Arch32.

    De nem csak a systemd ilyen. Pulseaudio-t sem tudod kikerülni egy csomó mindennél. Lehet ugyan apulse-sal szórakozni, de elég nehéz szembemenni a PA-val. Persze, el is lehet kerülni, nagyon minimalista, ALSA only progikkal, de az is egy nagyon kínkeserves művelet, főleg, ha valami audiovizuális tartalom előállításával foglalkozol, vagy mondjuk gamer vagy, aki Steam melett nyomja Teamspeaken, Discordon, streamel is, és egyszerre több be/kiimenetet is használni akarsz, keverni, stb.. Lehetni mindent lehet, kérdés kinek mennyit ér meg.

    Én egyébként a 32 bites támogatás megnyirbálásának sem örülök. Én magam nagy ellenzője vagyok, mert sok ember feleslegesen futtatja a 32 bites OS-t, de másik oldalról a Linux egyik erénye, hogy gyenge gépeken is jól fut, és ott van egy rahedli 1-2 giga RAM-os régi gép, amire 64 bites Linux nem nagyon jó, azok meg most vagy XP-n ragadnak, vagy BSD-n, amin megint egy csomó dolog nem támogatott, meg nincs rá egy csomó driver. Szóval egy részről nyereség, hogy a 64 bit jobban terjed, meg a 32 bites, gyenge csotrogányokat kidobatják az emberekkel, és haladunk a korral, más részről viszont sok ilyen 32 bites gépben még lenne annyi miniimális potenciál, hogy Linuxszal még használhatók lennének. Persze 32 bit így is van, de van már jó pár olyan csomag, ami nem támogatja, meg hekkelni kell. Nem csoda, hogy mainstream disztrók nem akarnak ilyennel szenvedni, mikor még a 64 bites igényeket sem tudják lefedni, így is van egy csomó olyan csomag, ami nincs benne a tárolójukban, hanem külső tárolót kell felvenni, meg AUR-ból/git-ről forgatni. Akkor meg nem azzal fognak szórakozni, hogy a 32 bites őskövületek gazdáit is kiszolgálják.

Új hozzászólás Aktív témák