Elérhető a Devuan ASCII 2.0.0-s stable kiadása

Címkék

Elérhető a systemd-mentesített Debian fork, a Devuan 2.0.0-s stable kiadása. Részletek a bejelentésben.

Hozzászólások

A tökéletes linux. Már csak a pulseaudio-t kell kidobni belole...

--
robyboy

A Pulse-t bármiből ki tudod dobni, ha minimum netinstallal teszed fel, és nem telepítesz olyan DE-t vagy csomagot, ami függőségnek hozná.

Egyébként ez a Devuan mitől lett ASCII? Ez valami kódnév, vagy a default kódolása ez?

No keyboard detected... Press F1 to run the SETUP

Nekem sincs semmi bajom a systemd-el, sőt, azt jó ötletnek tartom hogy mindenféle random, félig összematyizott szolgáltatás helyett központosítsjuk azt, ami az oprendszer feladatai közé tartozik. Unpopular opinion. Persze ez nem követi a KISS elveket, bár a legtöbb ember elfelejti hogy a Linux sosem volt igazi Unix.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Miből gondolod, hogy a többi initrendszer "mindenféle random, félig összematyizott szolgáltatásból" áll? Egyszerűen csak részegységekre van bontva feladatonként és nincs agyonközpontosítva; a központnak (init) csak az indítás/leállítás a dolga.
A túlzott központosításnak, ha egy dolog felel mindenért, annak rengeteg hátránya van azzal szemben, ha egy adott részegység csak egy adott feladatért felel. Minél jobban túlbonyolítasz valamit, annál több hibalehetőséget és instabilitást teszel bele. És ez nem csak a UNIX-okkal van így, hanem mindennel. http://oscomp.hu/depot/systemd-can.jpg

Ez egy két éves hiba, emlékszem is rá egyébként. Én is meresztgettem a szememet. De láttam már nem egy local root explitot is (kernel), szóval ez nem érv semmi mellett vagy ellen. Maximum azt mondhatod hogy minek ide systemd, plusz komplexitást hoz be és vannak helyette 40 éves random toolok.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Az sem érv, hogy ez már régi hiba, mert ez is egy jele annak, hogy a systemd broken by design, az meg maradt, ha a hiba fixálva is lett. Az sem érv, hogy a kernelben is volt exploit, mert az sosem érv, hogy "a másik is". (És egyébként ez csak egy blőd bug volt, nézd meg, hogy még mennyi van...)

Ez a "40 éves random toolok" meg akkora fals és hatásvadász csúsztatás, hogy tanítani kéne valami bullshit kurzuson. Nem random eszközökről beszélünk, hanem céleszközökről, amiknek azt kell csinálniuk, ami a feladatuk. A korra való hivatkozás pedig nettó baromság; egy kiforrott, a feladatát tökéletesen ellátó céleszközt miért cseréljünk le? Csak, hogy baromi modernek legyünk? Haladás a haladás kedvéért, csak haladjunk, ha kell a szakadékba is? (PWP, az...) Dobjuk ki a kést, kanalat, villát is, mert ezek már többszáz éves eszközök és cseréljük le őket egy olyanra, ami mind a három funkcióját betölti? Egek, még szerencse, hogy a RedHate-es "mérnököket" nem engedik a konyhában is innovatívkodni, mert különben egy héten belül éhendöglenénk...

Hat igen. Ez mindenre igaz. Ha nem futottal meg bele X program hibajaba, akkor nem nagyon astad bele magad.

A systemd addig lett volna jo otlet, amig csak az init-et intezi. De hat mar a login, logging, udev, dbus, stb. is maga ala van gyurve es ez sem lenne gond, ha hasznalhato modon oldottak volna ezt meg. Meg nem egy Pocstering tervezte volna. O meg mar tobbszor bebizonyitotta, hogy egy kontar f@sz hatalmas egoval. :D

Aki azt hiszi, hogy a systemd jo, az tenyleg nem latott meg mas (parhuzamositott) init rendszert. Es ez meg csak az init rendszere, nem a tobbi szarsaga. :D

Az az igazság hogy gyakorlatilag minden fontosabb distro behozta, beleértve az enterprise világot is, úgyhogy lehet sírni, de ez van és kész. Lehet otthon Linuxozni a Devuannal, ha jól esik. :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Ertem en, de ez nem azt jelenti, hogy jo hanem azt, hogy kisebb a support koltsege, mivel nem kell szamos alkalmazast es azok integraciojat kezelnie a disztribucio kiadojanak.

Es nem nem sirok, mert az osszes nyugot megoldom ami vele kapcsolatban felmerul, amennyiben ez lehetseges a forraskod hozzanyulasa nelkul.

Ettol meg otvar nagy gany szar az egesz, akar tetszik akar nem "Az az igazság" :D

"Ettol meg otvar nagy gany szar az egesz, akar tetszik akar nem "Az az igazság" :D"

Ezt nem vitatom de a gyakorlati életben nem szokott konkrét problémákat okozni. Legyen a distrofejlesztők nyűgje. Azért tartjuk őket.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Nem volt bajom évekig a systemd-vel. Egészen mostanáig, kezd elmenni a fejlesztése kapkodásba, jönnek-mennek a bugok. Igaz én nem kényszerítek rá eth0-ás eszközneveket. Pedig maga a koncepciója jó lenne, hogy egyfajta service API-ként szabványosított réteget tol a kernel és a progik közé, csak a megvalósítása nem az igazi, főleg ez a kapkodás, amit mostanában kezdenek levágni.

Lehet nem szeretni, de minden dependel már rá, elég megkerülhetetlen. Az biztos, hogy Devuant nem használnék, egy túl konzervatív disztró még konzervatívabb ága. Ha valaki systemd nélküli rendszert akar, tegyen fel Archot vagy Gentoo-t, azokon is meg lehet oldani a systemd-mentességet, úgy, hogy a systemd-re dependelő csomagok is simán felmennek.

No keyboard detected... Press F1 to run the SETUP

Mint ahogy nem is releváns az UHU egyáltalán. A systemd-vel meg tényleg nem foglalkoztam behatóbban, csak user-ként ketyeg alattam és teszi a dolgát.

Nem is ez volt a mondanivalóm, hanem az, hogy a nem-ASCII betűkkel viszont már szívtam eszméletlen sokat sima felhasználóként, ezért rendkívül szerencsétlennek tartom egy olyan kódnév választását, amely tévesen akár arra is utalhat, hogy egy huszárvágással megszabadultak mindettől és visszatértek a mindösszesen 95 csodás nyomtatható karakter megbízható kezelésének atomstabil világába.

Én elhiszem, de ahol meg komolyabb dolgokat akarnak, ott meg megy vele a szívás. (A leggyakrabban egyébként tudtommal a logokkal van baj, mert a systemd mindent valami custom bináris formátumban loggol, ami néha sérül és használhatatlan lesz, ami egy szerveren nem vicces (persze másutt sem).)

Nem tudom, nekem ez meg sem fordult a fejemben, hogy ez azt jelentené, hogy kukásították a non-ASCII karaktereket. Szerintem egyszerűen csak a geek-factor miatt választották ennek a kisbolygónak a nevét.

Kösz, azt mi is tudtuk, hogy minek a rövidítése. Meg azt is, hogy a Devuan bolygókról kapja a kódneveit. Csak az nem állt össze, hogy egy bolygónak is van ilyen neve, ami szerintem elég hülyeség, ennyi erővel lehetne bolygókat Tesco Value, meg egyéb idióta neveket adni.

No keyboard detected... Press F1 to run the SETUP

Teszkógazdaságosnak hívni egy kisbolygót veszélyes játék, még a fejünkre esik... :P

De viccet félretéve mégis minek kéne szerinted hívni egy aszteroidát? Nem mindegy minek hívják? Úgyis a száma alapján lajstromozzák, a név mellékes, hívhatják akár Guybrush Threepwood-nak is...

Ki használ szerverként vagy desktopként Devuant Debian/Ubuntu helyett és mi a tapasztalata vele? Pl. biztonsági frissítések terén, vagy külső programok telepítése (amikből van 3rd party debian csomag) mennyire problémás?
--
Légy derűs, tégy mindent örömmel!

Jo kerdes. En nagyjabol stabilan ki tudtam/tudom kerulni a pötterixet debian alatt. Csak 1x volt olyan hogy amiatt nem bootolt be a laptop meg installalas utan kozvetlenul, de akkoris konnyu volt leirtani (installer boot, chroot, stb). Valahogy azt is meg lehet herketeni allitolag hogy a debootstrap se tegye mar fel, es akkor tenyleg nincs semmi problema.

Szoval jo kerdes hogy milyen gyakorlati kulonbseg van egy devuan es egy /etc/apt/preferences.d-benn megpinnelt systemd-s debian kozott. Elso kozelitesben semmi szerintem...

Akkor ezek szerint a Debianban a csomagokkal szállított init scriptek nem systemd specifikusak vagy van sysv init kompatibilis init script is a csomagokban?
Mintha anno az lett volna az egyik problémájuk, hogy nem akarnak többfélét karbantartani...
--
Légy derűs, tégy mindent örömmel!

Akkor ezek szerint a Debianban a csomagokkal szállított init scriptek nem systemd specifikusak vagy van sysv init kompatibilis init script is a csomagokban?
Igen, ugy nez ki mukodik. Meg nemreg egy vps-en kiserletkeppen frissitettem buster-re, es ott is jonak tunik az initrendszer. Remeljuk nem akarjak meg egy joideig megjavitani :)

> Szoval jo kerdes hogy milyen gyakorlati kulonbseg van egy devuan es egy /etc/apt/preferences.d-benn megpinnelt systemd-s debian kozott. Elso kozelitesben semmi szerintem...

Az a különbség, hogy a Debian csomagtárolóban boldog-boldogtalan dependel a systemd-re, vagy valamire, ami dependel a sytemd-re. Olyanok is, ahol semmi értelme nincsen. A Devuannál semmi nem függ tőle.

Az a különbség, hogy a Debian csomagtárolóban boldog-boldogtalan dependel a systemd-re, vagy valamire, ami dependel a sytemd-re. Olyanok is, ahol semmi értelme nincsen.
Jogos, igen, ilyesmi tenyleg mintha 1x elofordult volna velem is, legalabbis joideig nem ertettem miert irja ki hogy "van csomag de valami dependency ize miatt nem megy fel". Nem konkretizalta hogy pötterix, de valoban azon a rendszeren ki volt pinnelve kellemesen negativra minden ami systemd.

Na, ilyen a Devuanban nem fordulhat elő. És ez az értelme az egésznek, hogy megszabadulj a szartól. (Vagy legalábbis a nagyrészétől, systemd, pulse, gtk3, ezektől meg lehet, de sajnos van amitől nem tudsz, pl. a pkg-configtól majdnem lehetetlen.)
Meg egyben ez igazolás is a projektnek azokkal szemben, akik kárörvendően a bukását jósolgatták, már akkor, amikor elindult.

A Devuan biztonsági frissítéseiről az alábbi infót találtam. A használt "merged" repók hogy működnek, miben különböznek a Debian repoktól (mivel a main repo is merged és a Devuan még sem teljesen azonos a Debiannal)?

"Security updates isn't a problem for Devuan as their repositories are "merged" with the official Debian repos and as such both will have identical security updates."
http://murga-linux.com/puppy/viewtopic.php?t=108003&sid=0bb924e3930386d…
https://devuan.org/os/etc/apt/sources.list
--
Légy derűs, tégy mindent örömmel!

A lenti linkek alapján a következőképp működnek a Devuan repók és a frissítések.
A pkgmaster.devuan.org fő repóiban 2 könyvtár van:
- devuan/ : Csak a Devuan specifikus, általuk módosított csomagokat tartalmaz.
- merged/ : Az Amprolla script által egybeolvasztott Devuan+Debian repó. Ebben ha van Devuan csomag akkor az érhető el a Debiané helyett, egyébként pedig a Debiané.
2017 óktóberében Devuan könyvtár mérete kb. 8GB míg a teljes Debian mérete kb. 2TB volt.

A Debian biztonsági frissítések előszőr bekerülnek a sid, testing, stable, old-stable Debian repókba. Ha ezek nem Devuan specifikus csomagokhoz tartoznak akkor azonnal elérhetők, a merged repóban. Amennyiben Devuan specifikusak akkor csak azután lesznek elérhetők ha a Devuan fejlesztők elkészítették belőle a saját csomagjukat, vagy ha ez elmaradna akkor a frissített Debian csomag annak megjelenésétől számított 6 hónap után automatikusan elérhető lesz.

https://pkgmaster.devuan.org/devuan_mirror_walkthrough.txt
https://git.devuan.org/devuan-infrastructure/amprolla
https://sysdfree.wordpress.com/2018/04/10/194/
--
Légy derűs, tégy mindent örömmel!

Szakmai maszturbálásnak titulálom, de nem akarom lekicsinyleni senki munkáját. Én meg LineageOS for microg -t használok, azon is sokan nevetnek.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Gondolom, akik még a "Sarge" előtt kezdtek Debian-ozni, sokan kipróbálták már. A korral is jár, ki mit hajlandó befogadni. 60 felett már senki sem tudhatja, hány napot tölthet még viszonylagos egészségben az aktuális rendszerén. Most abból a "lehetséges kevésből" még újra és újra "járni tanulni"..., - átlagos Linux-felhasználónak lehet meggondolandó. (Tehát több tiszteletet érzek az Devuan-os "próbálgató", a "systemd"-t nem különösebben szerető, "előttünk-mögöttünkjárók" iránt, és a fejlesztői iránt is.)
:)

Ez most vicc? Nézd már meg, hogy hány bugot reportoltak és ebből hányat zártak le úgy, hogy az szerintük nem is bug. Szerinted pl. az nem komoly gond, hogy a systemd önhatalmúlag írhatóként csatolta fel az efivars-t és ki lehetett vele nyírni a gépet? Szerinted az sem komoly gond, hogy Poettering a saját szájíze szerint "megjósolhatatlannak" nevezze a sokévtizede megbízhatóan ugyanúgy eth# néven csatolódó hálózati eszközöket és önhatalmúlag 4 (!) másik elnevezési konvencióból válassza ki, hogy milyen néven csatolódjon, a júzer meg nézzen, hogy hova lett az eth0, mert meg se lett kérdezve, hogy ő ezt szeretné-e? Ki kérte ezeket a marhaságokat? A systemd pont ugyanolyan, mint a windóz 10: mindent összetúr, ami eddig teljesen jól ment, a készítői szájíze szerint tesz dolgokat a gépeden, teszi mindezt opt-out módon és leerőltetik a torkodon, ha beszarsz is...

De igen, a "haterek" elsöprő többsége szopott komoly gondokkal, csak bizonyos körökben sikkes fikkantani azokat, akik ragaszkodnának a bevált, működő megoldásokhoz. Az nem érv a systemd mellett, hogy a SysVInitnek minden baja van; egy tonna egyéb initrendszer van ezeken kívül is.

Aht oke akkor, vilagismero nagysagos ur. :D
En meg meg vagyok gyozodve rola, hogy Te nem szoptal vele, mert nem hasznalod komoly munkara ezek szerint.
En meg vagyok gyozodve rola, hogy semmilyen indoka nem lehet a systemd letezesenek a szamomra. Fel is tudok sorolni csomot az en szempontombol.

De nem vagyok akkora boszme, hogy ugy gondoljam az en meggyozodesem a helyes es mindenki mas hulye, vagy divatnyavogo majom.

Szakember ur! :D

pfffff...

Az én szempontomból vizsgálva a systemd-ekézés nettó energiapocsékolás, ez most már egy adott helyzet, megszoksz vagy megszöksz, punktum. Oké, van a devuan, meg néhány hippidistro, aki ellenáll, nyugodtan megtehetik, senki sem tartja a pisztolyt.

A gyakorlati életben számomra soha nem okozott problémát, persze az architekturális és kódolási problémákat nem lehet letagadni, de ezeket (ha lehet) javítják folyamatosan. Majd visszajövök ide elnézést kérni a jövőben, ha _valós_ élethelyzetben azt kell mondanom hogy "na bazzeg, a köcsög pottering x órányi pluszmunkát / y forint veszteséget / z darab kitépett hajszálat okozott nekem".

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Miután Wheezy-ről Jessie-re frissítettem, a következő változások álltak be, amik a systemd eltakarításával elmúltak:

1. A bootidő a felére csökkent. (Ez természetesen nem szívás, ezt csak a korrektség kedvéért mondom.)

2. Az addigi stabil rendszer néha random módon összeomlott.

3a. Na most, tudom, hogy syscrash után az fsck-t tarkónlőni az bad practice, de amikor épp rohadtul nincs 4-5 percem, mire végigszánkázik a merevlemezeken - mert pl. épp rohadtul csináltam valamit, amivel gyorsan meg kellett lenni - akkor rohadtul idegesítő, hogy a systemd nem hagyja lelőni. Ugyan van fsck.mode=skip kernelparaméter, de korábban még opció volt, hogy előtte megkérdi, hogy skippeljük-e vagy sem és menetközben is le lehetett lőni. Amióta viszont a systemd asszimilálta az fsck-t is, azóta ez az opció megszűnt.

3b. Az fsck néha beakadt, csak a reboot segített.

3c. Olyan is volt, hogy egyszer csak elkezdte azt, hogy minden bootnál fsck-zik, akkor is, ha nem volt crash. Aztán abbahagyta.

4a. A samba service restartra és startra is beugatott, hogy a szolgáltatás maszkolt, fityiszt az orromra. (Ezt mondjuk megtaláltam, hogy azért, mert átnevezték smbd-re, de mégis minek?)

4b. Újra kellett volna töltenem a samba configot, de a systemd samba service nem ismerte a reload parancsot. (Azóta állítólag ismeri.) Lehetett restartolni a szolgáltatást.

5. A szolgáltatások néha random módon elszállogattak.

6. Egyik (csak adatot tároló) meghajtó formázása után az fstab-ban elfelejtettem az UUID-et átállítani és boot után a systemd bereklamált, hogy nem tudja felcsatolni, kiírt egy raklap baromságot, majd bebootolt emergency módba. (Direkt kipróbáltam, ha nem systemd van, akkor csak szól, hogy nem tudja mountolni, skippeli és kész. Mint kiderült nem véletlenül, a systemd a mountból is sajátot szállít.)

Bonus: OrangePi-re raktam Armbiant és miután a systemd-t kitöröltem és felraktam a SysVInitet, a rendszer 3-4x reszponzívabb lett.

Azert ezt mind rafogni a systemd-re eleg eros. Termeszetesen mint minde szoftvernek ennek is vannak hibai, de az elonyei boven ellensulyozzak a hatranyokat.

Mindamellett akkor lenne teljesen egyertelmuen a systemd szamlajara irhato a dolog, ha nem dist upgrade-eltel volna hanem csak lecsereled egy futo rendszeren az init rendszert systemdre. Mivel kb hatmillio dolog valtozik egy dist-upgrade soran igy nem lehet egyertelmuen kijelenteni h ez mind a systemd hibaja.

2) Lasd az elobbiek
3a) Azert ez nem hatrany, es amint irod lehet allitani.
3b) issue # errol?
3c) issue # errol?
4a) Ez miert broken by design?
4) kill -HUP?
5) Aztan ujraindultak, ez a systemd feladata.
6) Meg nem volt ilyen elmenyem CoreOS alatt, pedig csesztem mar el az fstabot.

Hát akkor mégis mi, ha a systemd eltávolításával eltűntek a problémák? A "neked jó" nem érv, a pebkacot meg kifejthetnéd, hogy mégis mi volt, amit annyira elkúrtam? Az meg elég érdekes, hogy annyira érdekelt a téma, hogy mindennemű műszaki érv nélkül systemd-haterezz, de annyira már nem, hogy a worksforme-n kívül bármit is mondj, hogy miért is olyan jó ez...

Elmondom ismét itt, de már leírtam, hogy részemről ez nem systemd-pro érvelés, hanem systemd-hater-unalmasatéma érvelés. Én a magam részéről a distrokészítők kezébe adom a gondokat, azért vannak, én meg elvagyok. A laptopomon is, különböző ügyfélgépekkel is, fizikai és virtuális szerverekkel is. Megy-megy, oszt kész. Ha neked meg nem, és letörlöd, nekem az is jó.

Amúgy az hogy nálad 4x reszponzívabb lett az SBC kizárólag a systemd eltávolítástól, szerintem elég izgalmas ahhoz hogy kicsit bővebbben kifejtsd. Mi lett reszponzívabb? Desktop? Login? SSH-ban a gombok nyomkodása? Csak mert vannak raspberryk nálam, nas-mediaplayer-nextcloud témákra, és nem nagyon zavarja őket a systemd. (jessie/stretch).

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

> Elmondom ismét itt, de már leírtam, hogy részemről ez nem systemd-pro érvelés, hanem systemd-hater-unalmasatéma érvelés.

Nem, a systemd-ellenzők lehaterezése, meg a műszaki érveiknek az "unalmassággal" való lesöprése, az nem érvelés, hanem közönséges személyeskedés és fölényeskedés. Áruld már el: ha untat a "systemd-haterek" fröcsögése, akkor minek pazarlod egyáltalán az idődet arra, hogy kioktasd őket? Ha én egy témát, vagy a benne folyó flame-t érdektelennek/időpazarlásnak tartom, akkor nem írok bele, még akkor sem, ha amúgy lenne véleményem.

> Én a magam részéről a distrokészítők kezébe adom a gondokat, azért vannak, én meg elvagyok.

A Devuan is egy disztró. Akkor, ha a készítői a gondokat a systemd kiebrudalásával oldják meg, akkor az miért "szakmai maszturbálás"?

> Amúgy az hogy nálad 4x reszponzívabb lett az SBC kizárólag a systemd eltávolítástól, szerintem elég izgalmas ahhoz hogy kicsit bővebbben kifejtsd. Mi lett reszponzívabb? Desktop? Login? SSH-ban a gombok nyomkodása?

Az SSH-t nem figyeltem, de a többi az igen. Begyorsult a desktop, a programok indítása, a login, a kirajzolás, stb. Raspberry Pi hanyasok vannak nálad? Nálam RPi 1, meg OrangePi, ezek sokkal gyengébbek, mint pl. egy RPi 3.

Leírtam a legelején: a systemd eltakarításával a problémák megszűntek, tehát nem nagyon tudom másra fogni. Nem a dist-upgrade miatt van, most is ugyanazt a systemd-tlenített Jessie-t használom és ezen gondok egyike sincs. (Ráadásul a bonus pontban leírt lassúsági probléma egy másik hardware-n történt friss telepítésen jött elő és a systemd kiebrudalása után azonnal meg is szűnt.)

2) Dettó.

3a) Leírtam egyfelől, hogy a probléma az, hogy elvették az opciót, másfelől meg azt is, hogy az "állíthatóság" az kernel paraméter, tehát köze nincs a systemd-hez, nem ő adja a lehetőséget, ő csak elvette a másik, sokkal kényelmesebb lehetőséget.

3b) Milyen issue? Azt kérdezted, hogy én hol szívtam meg vele. Ez az én tapasztalatom volt, nem egy bugreport. (De tessék egy ticket. Nem tudom mennyire releváns az én problémámmal kapcsolatban, mert itt nondeterminisztikus módon akadt el vagy sem. Csak azért linkeltem be, hogy lásd: mások is szoptak ezzel; ha kuglizol kicsit, találsz még.)

3c) Dettó. (De tessék, itt van ehhez is egy ticket. Ugyanaz vonatkozik rá, mint az előző linkre is: nem tudom, hogy nálam ez a hiba volt-e, de ez a jelenség se csak nálam jött elő.)

4a) Nem mondtam, hogy ez is broken by design, ez csak egy váratlan átnevezés volt; azért volt felsorolva, mert szívtam vele egyet és neked ez volt a kérdésed.

4b) Ez most vicc? Most komolyan ez a válasz, hogy nem baj, hogy a SysVInit scriptben még volt reload, de a systemd unitban már nincs, mert ott a SIGHUP? Akkor minek egyáltalán az initscript vagy az unit, ha úgyis megkerüljük? Ennyi erővel akkor tényleg lehet hívogatni a binárist, meg tolni neki a kill parancsot, nem? A szolgáltatásokhoz nem véletlenül találták ki az initscriptet (vagy systemd esetén a unitot). Lehet, hogy tényleg csak egy SIGHUP az újratöltés, de lehet, hogy előtte/utána mást is kell csinálni, vagy nem is signallal van megoldva, hanem ahogy a perverz programozó kitalálta. Azt a mechanizmust pedig az odavágó initscript/unit/whatever implementálja.

5) Ez is most vicc? A systemd feladata, hogy a szolgáltatásokat random összeomlassza, majd újraindítsa? Egyáltalán nem kéne csak úgy összedőlniük és most systemd nélkül nem is teszik.

6) Jó neked. A kérdésed az volt, hogy én hol szívtam meg a systemd-vel, nem az, hogy te hol nem.

Szoval ott tartunk, hogy mivel neked nem okozott problemat, igy nem is letezik a problema, aki meg szopott vele mondjuk jo sokat az hipszter picsogo, mer divat szidni a systemd-t. Okes, ertem.

Igy tehat nem letezik mondjuk a graphite-web azon problemaja sem, hogy hatmilliard allomany olvasasakor es az azokbol kinyert adatok aggregacioja eseten az ember nem kap vissza semmit sem, mivel az 1TB RAM-ot is megteliti az oom killer meg kilovi. Nem letezik, hogy nalunk a load az egekben van az IOwait miatt, hiszen hatmilliard fajlt Te nem olvasol be a rendszeredbol.
Az ElasticSearch shard problema sem letezik gondolom.
Illetve valoszinuleg hagymazas almaimban kepzelek egy csomo problemat, ami valojaban nincs is, mert a Te univerzumodban nem leteznek.
Hajbi, Te vagy az????

Szakerto urasagnak koszonom az eszrevetelt. :D

"Szoval ott tartunk, hogy mivel neked nem okozott problemat, igy nem is letezik a problema"

Hát számomra nem.

"aki meg szopott vele mondjuk jo sokat az hipszter picsogo, mer divat szidni a systemd-t. Okes, ertem."

Aki szopott vele (és nem csak olvasgatta valahol a systemd-haterkedést) annak meg igen.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Nem próbáltam Devuan-t, mert a Refracta nevű kiadás nálam bevált egy nagyon gyenge gépen, amelyiken csak 700 MB a memória.
Egy (nem nagyon) erősebb gépen viszont MX fut (szintén Systemd nélkül), és még nem találtam olyan Linux-ot, amivel ne lett volna kevesebb bajom. :)
Lehet, hogy Systemd nélkül jobb a világ?

Jött egy egoista köcsög, aki ráeröltette az akaratát az egész világra.

Jött párhuzamosan egy kisebb raklap (*) egoista köcsög, akik ráerőltették az akaratukat az egész világra és utána úgy tűnik, egy megoldáson standardizálódott a Linux világ.

Fixed.

(*):
runit - 2004
Initng - 2005
SMF - 2005
launchd - 2005
Upstart - 2006
OpenRC - 2007
systemd - 2010
[tök jó, a Wikipedián van egy szép hosszú "Replacements for init" rész az Init szócikknél, hasznos...]

Nem lehet, hogy a SysV tényleg kiöregedett?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

1. Nem eroltettek ok semmit sem (runit openrc orul es virul koszoni szepen), plane nem nyeltek be olyan szolgaltatasokat amihez semmi koze egy init rendszernek (logind, idev, dbus, logging, stb, stb)

2. A sysV nem oregedett ki, hiszen teszi a dolgat. Mondhatod, hogy kioregedett a kerek, de mit hasznalnal helyette?

3. A kerek analogianal maradva, a systemd olyan kerek, ami kore az autot epitettek es nem az autohoz raktak a kereket. A kerekbe van beepitve nem csak a fekrendszer, de ha nincs kerek, nem tudsz indexelni, sot az ablaktorlo sem mukodik. Az ulesfutest is a kereken keresztul tudod elerni, de lassan tankolni is csak a kereken at lehet. :D

A kerék analógiánál maradva: a SysV egy fából készült kerék egy lovaskocsin. Tette a dolgát, idővel rájöttek, hogy ha egy fém gyűrűt tesznek köré, akkor biztosabb lesz (ez mondjuk az összes nem-pid 1-ként futó service monitor daemon, pl. pont az OpenRC is), megtanulták, hogy a küllőket milyen alakban/elrendezésben érdemes rátenni, ha sebességet akarnak, ha menetbiztonságot vagy ha a kerék tartósságát akarják. Semmi gond vele, faék egyszerűségű, kicsit zötyis vele az út, ennyit tud, kész.

Csak a lovak mellett elhúzott a világ egy modern autó képében, ami már nem gurul el fa kerekeken biztonságosan. Viszont a modern autóhoz ott van az (és innentől látszik, hogy fogalmam sincs az autókról :) ) alufelnis, dísztárcsás, választható téli és nyári gumikkal szerelt kerék, amin ott van a szelep, amin át fel lehet fújni, akár ott lehet a szivargyújtóra kötött kompresszor, hogy ha leereszt, az is orvosolható legyen stb.

És egyébként még legózható is az új kerék, a felnire olyan gumit teszel, amilyet akarsz, arra olyan szelepet, amilyet akarsz, olyan dísztárcsát, amilyet akarsz és olyan pörgős baszt (nem tudom a hivatalos nevét, az az idióta szar, ami pörög még egy sort a keréken, miután megálltál az autóval és semmi értelme nincs), amilyet akarsz; az más kérdés, hogy a legtöbben nem teszik, mert bőven jó nekik az, ahogy az kijött a boltból.

Az ulesfutest is a kereken keresztul tudod elerni, de lassan tankolni is csak a kereken at lehet. :D

Azok közül, amiket írtál, egyedül a journal az, ami nélkül a systemd, mint init rendszer nem megy. A többi mind a systemd ernyő-projekt alá tartozó komponens (így vannak közös kódrészei és egymás API-ját használhatják), amik mind opcionálisak és cserélhetők (logind helyett használhatod a ConsoleKit-et, udev helyett bármelyik udev replacementet, kdbus + systemd-bus-proxyd helyett a régi dbus-daemont, journalból mindent átirányíthatsz bármelyik syslog implementációhoz, alapból szerintem semmi nem szállítja engedélyezve a systemd-networkd-t, a systemd-ntpd-t, a systemd-resolvd-t, a .... A többi systemd-*d nagy része pedig D-Bus aktivált service, a letiltásukkal max. a rájuk dependelő dolgokat bukod, de azok meg mint a fehér holló).

semmi koze egy init rendszernek

Persze, mert a systemd projekt már rég nem csak init rendszer akar lenni, hanem egy komplett rendszer menedzser.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> A kerék analógiánál maradva: a SysV egy fából készült kerék egy lovaskocsin.

Egy érv a SysVInit ellen még nem érv a systemd mellett! Egy tonna egyéb init rendszer van rajtuk kívül...

> Persze, mert a systemd projekt már rég nem csak init rendszer akar lenni, hanem egy komplett rendszer menedzser.

Tehát egy "a SysVInit elavult" csatakiáltással lecseréltük az initrendszert egy "komplett rendszer menedzserre", amit a kutya nem kért, de legalább sokkal több baj van vele, mint azzal, amit felváltott...

Ha "azzal, amit felváltott" alatt továbbra is csak a SysV init-et, a systemd alatt viszont a teljes systemd ernyőprojektet (ezek expliciten külön vannak) érted, akkor valóban.

Ha azt nézed, hogy mi az, amit a systemd-vel, mint ernyőprojekttel ki tudsz váltani:
* syslog -> journald
* cron - > timer unitok
* inetd -> socket unitok
* ifupdown/NetworkManager/az-összes-többi-jobb-rosszabb-hálózat-menedzsert -> systemd-networkd
* dnsmasq (ha használod helyi caching resolvernek) -> systemd-resolved
* ConsoleKit [ez ugye már régóta nem aktív] -> systemd-logind
* ...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Ha azt nézed, hogy mi az, amit a systemd-vel, mint ernyőprojekttel ki tudsz váltani:

Megint abból indulsz ki, hogy bárki ki akart itt váltani bármit. Azonfelül minél több cucc lesz beleöntve, annál komplexebb és bug-prone-abb lesz.

> * syslog -> journald

Ezt nagyon nagy kár volt felhozni. A bináris loggolás egy agyrém, ami még Torvaldsnál is kiverte a biztosítékot, pedig ő direkt nem szállt bele a systemd vitákba. A logoknak pont az a lényege, hogy az ember is el tudja őket olvasni. Arról nem is beszélve, hogy a systemd logfájljai szeretnek korruptálódni, ami után teljesen olvashatatlan lesz az egész, a legkisebb sérüléstől is, míg a szöveges logoknál azért elég durva sérülés kell, hogy az egész olvashatatlan legyen.

> * cron - > timer unitok

A systemd timerek tényleg többet tudnak, mint a Cron (kivéve a mail on fail-t, fixme) és sok jó ötlet van bennük, de pont Cron alternatívákból Dunát lehet rekeszteni, mind az egyszerű-cronszerűekből (pl. FCron) - amik annyit tudnak, ami a legtöbb ütemezéshez kell - mind a bonyolultabbakból (pl. Mesos + Chronos) - amik még többet is tudnak, mint a systemd timerek. És ugye a systemd timerekhez, ha akarod, ha nem, kapod a teljes systemd-t...

> * inetd -> socket unitok

Miért kellett kiváltani az inetd-t? Hogy egyel több ok legyen betolni az egész systemd-t a rendszerbe?

> * ifupdown/NetworkManager/az-összes-többi-jobb-rosszabb-hálózat-menedzsert -> systemd-networkd

Ld. Cron, network managerből is Dunát lehet rekeszteni; miért pont a systemd, amikor vannak nála jobbak is, amik nincsenek tele buggal, meg marhasággal? Pl. olyanok, amiknél nem gond a DHCP lease meghosszabbítása, vagy nem borítják meg a DNS szerverek sorrendjét. A világmegváltó "az eth0 megjósolhatatlan" mantrából eredő iszonyatos katyvaszt már csak futólag említem meg...

> * dnsmasq (ha használod helyi caching resolvernek) -> systemd-resolved

Hát, aki azt használja, az meg is érdemli...

> * ConsoleKit [ez ugye már régóta nem aktív] -> systemd-logind

Ezt is nagy kár volt felhozni, mert Poettering ebbe is belegyúrta a világmegváltó és általában katasztrófákba torkolló nézeteit. Pl. logout után kinyírja a user által indított processeket és az IPC objecteket is, úgyhogy ez kb. úgy ahogy van kerülendő.

Szóval, summa summárum, a systemd nem csak mint init rendszer, de mint ernyőprojekt is egy katasztrófa. Ha van is benne jó dolog (pl. ebből a listából a timerek), akkor is kapod vele az egész problémahalmazt. És ezek után nyugodtan ki lehet jelenteni, hogy a systemd-vel, mint ernyőprojekttel is több gond van, mint azokkal a programokkal, amit kiváltott.

Ha nem tetszik a journal bináris formátuma, akkor egész pontosan egy konfig sor változtatás és áttolhatod bármilyen syslog implementációnak. (persze egy csomó hasznos meta-adatot így buksz, de kit érdekel, jó az úgy...)

A bármilyen cron-nal szemben szerintem a legnagyobb előnye, hogy ingyen megkapod a service-ek minden konfigurációs beállítását (a francba le lehet korlátozni egy-egy systemd service-t/unit-ot, mind biztonsági- mind erőforrás használat szerint).

Speciel a socket aktiválás azért kellett, hogy tisztábban kezelhetőek legyenek a service-ek közti függőségek anélkül, hogy tele kelljen pakolni mindent After= direktívákkal (a sockets.target aktiválásától [mielőtt service unitok indulnának] a systemd figyel a megadott socketeken, nem kell azonnal a démonnak is futnia). A D-Bus aktiválás miatt pedig triviálisan implementálhatóak on-demand induló, standard kommunikációs protokollt használó alrendszerek. (Persze, lehetne írni egy csomó démont, ami állandóan fut és figyel egy Unix socketen, hogy valaki beechozott-e neki egy "légyszi-légyszi csináldezt"-et, de...)

Network izé... ja, van egy raklap másik implementáció, és pont ezért AFAIK egyik disztró sem szállítja alapból engedélyezve. (triviális network setupokra viszont pont elég lehet, és kihúztál plusz néhány csomagot a rendszerből...). A DNS szerver sorrend meg nem a networkd, hanem a resolved. A network interface name meg szintén networkd előtti időkből származik, úgyhogy egyik sem érv a networkd ellen ;)

resolved... szintén alapból tiltott, nagyon-nagyon expliciten engedélyezni kell (a service-t, fel kell vinni az nsswitch-be vagy a resolv.conf-ba). Ha meg négy évvel ezelőtti CVE-kre is lehet hivatkozni, nagyon sok szoftver "aki azt használja, az meg is érdemli..." kategóriás ;)

logind és a kilépéskor kilőtt processek. Helyes, nekem pl. kifejezetten tetszik, hogy egy session lezárásakor garantáltan ki vannak lőve a hozzá tartozó processek (kivéve, ha expliciten előre engedélyezed [enable-linger] vagy systemd-run-nal futtatod); szvsz. ha valamit user session-ből kell indítani, de utána is futhat, ott valami félre van tervezve; ha meg valamiért _tényleg_ mégis kellene, van rá megoldás.

Ha van is benne jó dolog (pl. ebből a listából a timerek), akkor is kapod vele az egész problémahalmazt.

Nem. Szabadon választhatod meg, hogy melyik problémákkal akarsz küzdeni [kivéve a journald bináris logjai, de arra van workaround :)], de az valóban igaz, hogy ha magasabb szintű (networkd, resolved, logind, machined, ...) problémákkal akarsz szívni, akkor kell alá a systemd, mint init. :)

(off: nem tudom, milyen rendszeren használod elsősorban, de pl. a Debiannál én is szívtam egy-két systemd-specifikus dologgal, náluk nem lett... tökéletes a bevezetés, de szinte mindig kiderült, hogy a SysV init kompatibilis init script volt elb... és systemd-natív unitra cserélve megoldódott. CentOS-en és Süsü-n a systemd-vel általában annyi bajom volt, hogy láttam az újabb verziókban megjelent feature-öket és hiányoltam őket a rendszeren levőből :) )

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> Ha nem tetszik a journal bináris formátuma, akkor egész pontosan egy konfig sor változtatás és áttolhatod bármilyen syslog implementációnak. (persze egy csomó hasznos meta-adatot így buksz, de kit érdekel, jó az úgy...)

Tehát baromi jó, de ha mégsem, akkor legalább forwardolni lehet, hogy ugyanazt kapjam, mint nélküle, tehát semmi értelme az egésznek. A meta-adatokat meg szöveges fájlokban is meg lehet jeleníteni.

> (Persze, lehetne írni egy csomó démont, ami állandóan fut és figyel egy Unix socketen, hogy valaki beechozott-e neki egy "légyszi-légyszi csináldezt"-et, de...)

És ez a helyes megközelítés: nem kell, hogy mindenhova a systemd telepedjen, mert minél több dolgot csinál, annál több bugja lesz.

> Network izé... ja, van egy raklap másik implementáció, és pont ezért AFAIK egyik disztró sem szállítja alapból engedélyezve.

Akkor nagy értelme van. :P

> A DNS szerver sorrend meg nem a networkd, hanem a resolved. A network interface name meg szintén networkd előtti időkből származik, úgyhogy egyik sem érv a networkd ellen ;)

Akkor azt benéztem (bár a problémák továbbra is systemd specifikusak, max nem networkd), de a lease még maradt (meg ha túrunk egy kicsit a neten, akkor lesz még több is) és a kérdés is, hogy mitől volt ez annyira nélkülözhetetlen, hogy ennyire kellett...

> Ha meg négy évvel ezelőtti CVE-kre is lehet hivatkozni, nagyon sok szoftver "aki azt használja, az meg is érdemli..." kategóriás ;)

Bocs, de "a másik is rossz", az nem érv az egyik rossz mellett. Nem mindegyik az és lehet mást is választani. Továbbá nem a CVE kora számít, hanem az aktualitása és tudtommal, ezzel a CVE-vel a systemd fejlesztői nem is foglalkoztak, a bejelentésre a mai napig nem jött válasz, tehát hiába négy éves, még mindig aktuális. És ez elég rossz fényt vet a projektre.

> Helyes, nekem pl. kifejezetten tetszik, hogy egy session lezárásakor garantáltan ki vannak lőve a hozzá tartozó processek (kivéve, ha expliciten előre engedélyezed [enable-linger] vagy systemd-run-nal futtatod); szvsz.

Ez a melegvíz feltalálása, csak hideg húggyal... Logoutkor eddig is minden a user által futtatott folyamat SIGHUP-ot kapott és neked kellett a NOHUP vagy a & használatával explicit megadnod, hogy nem szabad kilépéskor bántani azt a processzt. De a systemd kérdés nélkül kilő mindent, kivéve amit rajta keresztül deklaráltak, mint "bennmaradót", felrúgva sok évtized működési konvencióját, mert ők már megint jobban tudják; a lényeg, hogy a systemd ismét megkerülhetetlen legyen.

> Nem. Szabadon választhatod meg, hogy melyik problémákkal akarsz küzdeni [kivéve a journald bináris logjai, de arra van workaround :)], de az valóban igaz, hogy ha magasabb szintű (networkd, resolved, logind, machined, ...) problémákkal akarsz szívni, akkor kell alá a systemd, mint init. :)

Igen? Mégis hogy tudom a systemd timereket használni a systemd nélkül?

> (off: nem tudom, milyen rendszeren használod elsősorban, de pl. a Debiannál én is szívtam egy-két systemd-specifikus dologgal, náluk nem lett... tökéletes a bevezetés, de szinte mindig kiderült, hogy a SysV init kompatibilis init script volt elb... és systemd-natív unitra cserélve megoldódott. CentOS-en és Süsü-n a systemd-vel általában annyi bajom volt, hogy láttam az újabb verziókban megjelent feature-öket és hiányoltam őket a rendszeren levőből :) )

Debianon, Ubuntun és CentOS-on is próbáltam, de most már kerülöm, mint a pestist, úgyhogy már nem használom semmilyen rendszeren. (Az Ubuntut (16.04) speciel PowerPC-n próbáltam és ott aztán meg tényleg iszonyat instabil volt a systemd. Foglalkoznak a systemd fejlesztők az x86 és ARM archokon kívül mással is?)

„Persze, mert a systemd projekt már rég nem csak init rendszer akar lenni, hanem egy komplett rendszer menedzser.”

Pont ezt írtam én is az egyik fenti szálban. A systemd már rég túlnőtt azon, hogy kiváltsa a régi initrendszert. Sokkal inkább már egy a kernel és a userland réteg közé ékelt, újabb szabványosított réteg, nem csak a rendszert indítja. Persze el lehet vitatkozni rajta, hogy erre mennyiben van szükség, de a linuxos világ már elég rég eldöntötte, hogy ebbe az irányba mennek, nem hinném, hogy valaha is visszafordulnak.

No keyboard detected... Press F1 to run the SETUP

Az lett, mióta szinte minden disztró azt használja. Egy újabb réteg, ami próbál egységességet hozni az ezer disztró különbözőségébe. Előtte csak a kernel volt egységes, hacsak szénné nem reszelték.

Nyilván nem úgy értem, hogy hivatalos szabvány, hanem gyakorlati. Ahogy az asztali PC-k világában a Windows, azt sem szabványosította senki, de minek utána a gépek 98%-án az fut, így nem kérdés, hogy mindenki szabványként épít rá.

No keyboard detected... Press F1 to run the SETUP

> Jött párhuzamosan egy kisebb raklap (*) egoista köcsög, akik ráerőltették az akaratukat az egész világra és utána úgy tűnik, egy megoldáson standardizálódott a Linux világ.

Ki erőltette rád bármelyik init rendszert is? Egyik sem volt kötelező. Az meg mindenkinek szíve joga, hogy init rendszert írjon, ha ehhez van kedve. Ez persze Poetteringre is vonatkozik, de egyfelől az említett "úriember" "terméke" már rohadtul nem csak egy init rendszer, mert már a fél Linuxos szoftvervilágot asszimilálta, másfelől meg egyedül a systemd volt az, amit szinte minden mainstream disztróban letoltak az userek torkán (respect a Slackware fejlesztőknek, hogy ők nem).