systemd nélküli 64 bites disztribúció

Fórumok

Sziasztok.

Létezik még rendes disztribúció normális bootolási folyamattal, amiben ha hiba keletkezik, az átláthatóan javítható?

Két napja küzdök, valamitől meghasalt egy AVLinuxnak nevezett, egy éve stabilan futó disztró. És nem tudok a hírhedt Ctrl-D után csinálni semmit, e2fsck megvolt pendrive-ról, fstab ok... és nem értem.

Hozzászólások

Én is gondoltam rá, hogy ilyen összefoglaló linket teszek be, de ezen van néhány olyan disztró, ami nem mindennapos használatra, daily drivernek való, hanem speciális felhasználásra (PCLinuxOS, Kiss, TinyCore, stb.). Én is beletettem a felsorolásba az Alpine-t, már az is durván határeset.

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.”

Debian 98%-ban tökéletesen használható sysvinit-tel, a fennmaradó 2%-hoz (főként desktop-related csomagokhoz) pedig ott a Devuan.

False.

Idén júniusban jelent meg a Debian 12 (Bookworm), ekkor a hozzá passzoló Devuan 5 (Daedalus) ugyan még csak béta volt, de azzal a pár csomaggal, ami kellett belőle, pont semmi baj nem volt béta stádiumában sem. Aztán, augusztus 15-én hivatalosan is megjelent a Daedalus. Nagyjából két hónapot kellett várni tehát ahhoz, hogy elmondhassuk, hogy abból is a "stable"-nek nevezett verziót használjuk.

Egyébként, csillió féle külső repót használok.

Semmi.
De ha kikapálod a systemd-t, akkor furcsa dolgok történnek a külső repokkal.
Például törött csomagok lesznek, vagy függéségek miatt visszamászik a systemd.

Ugyanis a külső repok jellemzően nincsenek felkészülve arra, hogy systemd nélkül próbálsz élni.

"A megoldásra kell koncentrálni nem a problémára."

Void Linux, Artix, Devuan, MX Linux, Alpine, Gentoo/RedCore, Slackware, Nitrux, Venom Linux, stb..

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.”

Ja, tőle ezt el is várjuk. Van vagy 3 felhasználójuk, így, hogy bzs mint-es áruló lett, így már csak ketten maradtak, ebből az egyik Volkerding.

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.”

Fentiek szerint vagy polesz, vagy árpi vagy nbalázs igazából Volkerding. a másik kettő pedig csak két külön nick ugyanahhoz az emberhez. Nekem polesz gyanús, az ő neve is P-vel kezdődik.

(Vagy még az is lehet, hogy Raynes szokásos baromságát olvashattuk.)

Nem, nem, igazam lesz, Volkerding közöttük lehet :D Viccen kívül én is elgondolkoztam már a Slackware-en, ami nekem nem tetszik benne
1) ritkán van belőle kiadás
2) ennek megfelelően a csomagok verziója dinoszauruszok korabeli
3) kevés csomag van a tárolójában
4) emiatt mindent forráskódból kell pörgetni, de akkor meg már minek a Slackware, annyi erővel Gentoo
5) annak a kevés tárolóban lévő csomagnak sem kezeli le a csomagkezelő a függőségeit.

Ahol viszont el kell ismerni a Slackware-t:
1) 30 éve megy, ami főleg úgy szép, hogy egy ember viszi lényegében
2) nem qrvlt el mindenféle üzleti meg normi irányokba
3) i586 támogat, ez már egyik másik bináris disztrónál sincs, egy kevés támogat már csak 32 bitet, de azok is i686 PAE only-k.
4) mivel sysvinit-es, ezért nincs benne erőforrás-zabáló systemd, ami megint nagyon jót tesz, ha az ember muzeális gépen linuxozna.

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.”

> 1) ritkán van belőle kiadás

de ott a current ami gyak. egy rolling release

> 2) ennek megfelelően a csomagok verziója dinoszauruszok korabeli

meglepo modon ez nem igaz, mivel nem olyan mint a debian/ubuntu vonal hogy ami verzio releasekor (vagy elotte 1-3 evvel :)) bekerul az marad az orokkevalosagig es backportolgatjak a bugfixeket, hanem a salakban mindig frissitik akar 10 evvel ezelotti verziohoz is a csomagokat. lasd patches/ konyvtar minden releaseben (meg 14.0-hoz is vannak mai napig ami tobb mint 10 eves)

persze emiatt siman jartam ugy anno, hogy egyszercsak frissult benne a php 5.2-rol 5.3-ra (ami azert erosen inkompatibilis) aztan pislogtam mint hal a szatyorba hogy miert nem mukodnek az oldalak...

> 3) kevés csomag van a tárolójában

de ott a slackbuilds ahol minden is van hozza

> 5) annak a kevés tárolóban lévő csomagnak sem kezeli le a csomagkezelő a függőségeit.

hat ez neha jo neha rossz. en mondjuk "imadtam" anno a debianba hogy felraksz egy mc-t es felhuz melle egy X-et is meg masik 150 csomagot. mikor nekem csak egy file commander kellett... de ez a mai napig benne van a debian vonalba, hogy minden opciot bekapcsolnak forditaskor aztan felrak mindenhez 100+ libet fuggosegbe, pedig az userek 99%-anak nem lesz azokra sose szuksege.

persze salakon meg siman ugyjartam hogy frissitettem a pppd-t, aminek lett egy uj fuggosege amirol ugy enem tudtam, nem rakta fel, aztan reboot utan elerhetetlen lett a gep (mivel pppoe-n logott)

Azért azt halkan megjegyezném, hogy az apt-nak van olyan kapcsolója, hogy --no-install-recommends, ennek hatására tényleg csak azokat a csomagokat teszi fel, ami valóban kell is a program működéséhez, az összes többi 'javasoltat', ami a csomag készítője szerint 'úgyis biztos kell', azokat nem. Ezzel a kapcsolóval egyes csomagok esetén radikálisan csökkenthető az automatikusan fellapátolt egyéb csomagok száma.

igen, ismerem, hasznalom, de a tapasztalat azt mutatja hogy viszonylag keves csomagnal van haszna, a legtobb esetben semmit vagy csak 1-2 tenyleg nagyon idiota fuggoseget lehet csak megsporolni vele. talan azert is, mert az ilyen nem kotelezo fuggosegeket a normalis csomagoknal eleve kulon -extras pkg-be rakjak.

Akkor válaszolok a nem tetszik érveidre az én szemszögemből nézve:

1) ritkán van belőle kiadás

Ez a stabilitás egyik alapelve. Kiszámíthatóság, tervezhetőség, lehet rá építeni.
Mai rohanó világunkban kifejezetten megnyugtató, hogy nincs fél évente új release, aminek aztán fél év a maintenance ciklusa és 1 év a security fix ciklusa - lásd például: https://wiki.samba.org/index.php/Samba_Release_Planning#General_informa…
Autót se cserélek 2-3 évente.

2) ennek megfelelően a csomagok verziója dinoszauruszok korabeli

Tévedés. Ez nem Debian. Release kiadásakor elég aktuálisak a komponensek. Később currentről is frissíthető.
Ha pedig valaki "vér slackwares", akkor simán letölti a source-t, kicseréli a komponenst újabbra és újrafordítja a csomagot. Csináltam párszor. Simán működött.

3) kevés csomag van a tárolójában

Ez nem Debian / Ubuntu. :) Nem akarok 23 féle levelező programot, 15 féle WM-t, 50 féle text editort.
Ha a gyári kevés, akkor ott a Slackbuilds - ahogy arpi_esp is írta.

4) emiatt mindent forráskódból kell pörgetni, de akkor meg már minek a Slackware, annyi erővel Gentoo

Pont ez a fő előnye a Slackware-nek: Megteheted a forráskódból pörgetést, de nem akarod az egész rendszert így üzemeltetni. Egyszerűen fárasztó és nem marad idő az érdemi munkára, feladatokra.

5) annak a kevés tárolóban lévő csomagnak sem kezeli le a csomagkezelő a függőségeit.

Debian / Ubuntu és társai itt veri ki nálam súlyosan a biztosítékot security szempontból. Miért kell olyan komponenseket felrakni, amik igazából egy másik szoftverhez tartoznak és a másik szoftver lyukas, mint az ementáli? Tudom, marha nehéz meghúzni, hogy hol van a függőségi határ, de ezt a Slackware jól csinálja.
Konkrét példa: Ubuntu 20.04. A gép szerver gép. Vim telepítés miért ránt magával hangfájlokat, Alsa hangrendszert?! Ismétlem: egy szerveren.
Egy gépre az, és csak az legyen feltelepítve, ami feltétlenül szükséges. Se több, se kevesebb.

Könnyen lehet, hogy visszatérek a slack-szálra, mivel már áttértem 64 bitre nagy nehezen. (Lusta voltam 70eft felett gépre költeni.)

Már nem vagyok Mint-es, most AVLinuxom van, lehet szapulni... A hálózatkezelője egy agyrém, amúgy multimédiában ebben a pillanatban fullos.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

ja, biztos a systemd-vel van a gond, nem a noname pistike disztróval, aminek még egy rendes weboldala sincs.

A baj nem a noname distroval van itt, hanem a hasznalojaval, aki ha nem bootol a rendszer fsck-zik, meg ilyenek. Azert pont a linux eseteben elegge egyszeru a layereken vegigszaladni es megnezni mitol is nem bootol be. Dmsg es minden telefossa logokkal a rendszert, de mga az initrd is verbosolhato, stb stb

MBR / UEFI? Initrd? kernel? init? hol all le, mit ir ki, stb stb.

Raadasul ujra lehet huzni mindent veszteseg nelkuk ha az ember okosan arrebb rakta a home-ot. A root meg a kutyat sem erdekli, ha kell naponta ujrahuzom :D ...a csomaglistakra meg ilyenekre meg vannak eszkozok. De akar egy ansible lokalisan vagy pul-ban is szepen visszarak mindent, stb stb. 

No de mindegy is 

Sajnos most túl összetetten szutykoltam a rendszeremet, nincs külön home, /user/local stb.

Egy új disztrónál előbb szándékosan szétkúrom a rendszert, hogy utána tudatosan megint felhúzzam, ha van időm. Utolsó érvágásoknál meg még kísérletezek is rajta. Utána felpakolom rendesen. Logokat nézegettem, de nem voltidőm belemélyedni, maló van a gépen, ha megy, akkor azonnal használom.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Az mire jó, ha külön van a user local, meg szándékosan szétcseszed a rendszert? Ebből így nem fogsz tanulni. Tedd be az GRUB configot, fstab-ot, és az lsblk és blkid kimenetét. Abból okosabbak leszünk, hogy miért nem bootolt.

Azt gyanítom, hogy /dev/sdakármi formában hivatkoztál a meghajtókra, és elmászott az sda, sdb, stb. sorrend. Ezt úgy lehet kivédeni, hogy UUID-kkel, lehetőleg PART-UUID-kkel hivatkozol a partíciókra, azt adod meg az fstab-ban, meg kernel rootnak.

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.”

Haha, pont a napokban jött szembe, hogy egy 18.04-ről 20.04-re frissített Ubuntu szépen kicserélte a grub.cfg-ben a /dev/sda1 jellegű bejegyzéseket UUID=kriksz-kraksz-ra. (Az már csak hab a tortán, hogy cserébe valamin rendesen hanyattesett a frissítés X. fázisában, így alapból bootolásképtelen lett, régebbi kernelt kellett kézzel butulni, és befejezni a 4 milliárd csomag konfigurálását, hogy legalább elinduljon.)

Nekem is. Alapvetően balfék formátum, nehezen olvasható, agyrém, de szükséges rossz. Garantálja, hogy nem fog többet elmászni. Lehet használni LABEL-t is helyette, de az ugye elveszik formázáskor (mkfs) meg az UUID is. A PART-UUID viszont megmarad, én azért szoktam használni, az csak akkor változik, ha a partíciót törlőm és újra létrehozom, ami nem nagyon fordul elő nálam.

Szerintem is Windows registry érzés, olyannyira, hogy a registry tele van UUID-vel. Ez egy szabvány, nem a MS találta ki, meg nem a Linux.

Ez a /dev/sdakármi, meg még a /dev/nvme[x]-nél is tapasztalom, hogy elmásznak, szinte minden bootoláskor. Nemrég a wlp[x]s is megszopatott, mivel egy SSD-t tettem a gépbe, és mivel a Wi-Fi is PCIe eszköz, eltolódott az azonosítója, 3-ről 4-re.

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.”

Fejlemény:

az fstab-ban letiltottam a meghajtókat tartalmazó sorokat, azóta kissé rinyálva indul sosem látott üzenetekkel a rendszer, de elindul és utána stabil.

Csont lusta vagyok utánajárni, mi a hiba. Ha egyszer megy... 10 másodperccel lassabban bootol. A következő kernelfrissítéskor megint elkezdek szórakozni az fstabbal, lehet, hogy a vinyók UI-ja vagy mije át lett írva. Nem tudom...

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.