GNOME 3.34 is now managed using systemd

 ( nydn | 2019. október 2., szerda - 11:18 )

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem tudom milyen más rendszerre gondolsz. Windowson kb az os része a GUI ott tuti nem cseréled le, linuxon a nagyobb disztrók mind átálltak systemdre van még pár ami a széllel szemben próbál vizelni. BSD? Ha linux desktop penetrációja olyan ~2% körül van akkor a BSD kb 0.0002%. Ahhoz nagyon elvetemültnek kell lenni hogy BSD-t hasaználjon valaki desktopra, meg amúgy is fejlesztik rá a saját DE-t, ha jól tudom.
Nálunk a cégnél lehet linuxot használni annak ellenére hogy a win a fő támogatott rendszer. Kb 40 fejlesztőből szerintem 30 linuxon tolja már, de BSDt senki nem akart.
Lehet utálni a systemd-t de akkor is úgy néz ki hogy az lesz a linux like operációs rendszerek init rendszere az elkövetkező 10 évben, szóval érdemes lesz megszokni.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Ahhoz nagyon elvetemültnek kell lenni hogy BSD-t hasaználjon valaki desktopra

Miért is? Ha a "hardvert venni tudni kell" stimmel, teljesen jól használható.

meg amúgy is fejlesztik rá a saját DE-t, ha jól tudom

Lumina, amire gondolsz. Ezt az "egyik" BSD, a TrueOS használja, és egy "cég" fejleszti őket.

Lehet utálni a systemd-t de akkor is úgy néz ki hogy az lesz a linux like operációs rendszerek init rendszere az elkövetkező 10 évben, szóval érdemes lesz megszokni.

Amennyire tudom, az asztali környezeteknek eddig teljesen mindegy volt, mi az init rendszer: sysvinit, runit, initng, vagy bármi más. Most már nem mindegy?

A systemd nem csak egy init rendszer, hanem mindent (is) kezel :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Csak azt nem értem, hogy akkor miért kell hozzá Gnome :D

Haha, ez jó volt :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Ne aggódj, nemsokára a GNOME3-at is asszimilálni fogja a systemd; beépített desktop lesz... Freedesktop!

gnome3d :D

Hát most jön a homed (éljen!), ennyi erővel tényleg jöhet a desktopd, meg a gnomed.

A systemd már rég nem csak egy init rendszer, hanem egyfajta köztes mini OS, a kernel és az userspace között. Ebben tényleg az a szomorú, hogy ha ilyen ütemben folytatódik a systemd térnyerése, akkor a végén a kernelt is magába olvassza kerneld-ként, onnantól a Linux is átmegy GNU/Pöttyering Linuxd-be, Torvalds meg mehet is nyugdíjba, mi meg válthatunk BSD-re, hacsak nem implementálja az is a jövőben az OpenSystemD-t vagy LibreSystemD-t :D

A systemd elég bloat. Modern gépen ez nem szembetűnő, csak ha nagyon régi, kevés RAM-os gépre toljuk fel, ott látszik, hogy micsoda különbség van egy systemd-s és egy nem systemd-s disztró között.

A systemd-vel semmi baj nem lenne, ha megmaradt volna egyszerű init rendszernek, és semmi nem dependelne rá, úgy csak egy választható lehetőség lenne a többi között. De így, hogy mindenki és minden rá dependel, így túl egyeduralkodó és már mindent ural, ez pedig káros a Linux jövőjére nézve.


“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

+1

Megérjük vajon még az updated-et is, amikor már a rendszerfrissítést is a systemd fogja intézni? Meg a packaged-et, amikor a csomagkezelést? Meg az apocalypsed-et is, amikor a világvégét. :P

https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html

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

Úristen... Én csak vicceltem, de ezek itt meg komolyan megcsinálták. A következő tényleg az apokalipszis lesz vajon?

Nem, előtte még jön a csomagkezelés 2.0: http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html

(ha jön az apokalipszisd, azt is linkelem :P )

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

Egek, ez már kettő a háromból...

(Az a baj, hogy az apocalypsed az nem egy systemd komponens lesz, hanem az az eseménysorozat, amikor ez az egész össze fog omlani, magával rántván ipar szinten a jóég tudja mi mindent és akkor a "d" postfix nem a daemont fogja jelölni, hanem a múlt időt...)

apocollapseD :D

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

bármelyik másra a *nix világban, amelyik nem használ systemd-t?
és akkor most azért ne használjon valaki pl FreeBSD-n új Gnome-ot, mert ő csak az emberek "0.0002%"-ba tartozik?

szerinted akkor jó az az irány, hogy ilyen DE-t próbálnak összerakni, egy zárt ökoszisztémával?

a systemd utálatot pedig nem tudom miért kevered ide, egy szóval nem említettem.

Photoshopot sem tudsz használni mert az emberek azon 2%-ba tartozol akik nem windowst használnak.
Gnome úgy döntött neki nem éri meg systemd függetlennek maradnia azokért akik szembe akarnak menni az árral.
Gnomeot akarsz használj valamit amin megy, ha egzotikumot akarsz akkor meg nem kell sírni hogy nem megy rajta valami mainstream cucc.
Ha nagyon akarnak BSD-re gnomeot implementálnak neki egy systemd stubot és az megcsinálja bsdn amit kell, vagy implementálják a systemd-t BSD-re is.

Azt hiszem valamikor a 3as gnome kiadása után nem sokkal volt valami hogy nem ment bsdn a dbus miatt, megoldódott az is.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

> Photoshopot sem tudsz használni mert az emberek azon 2%-ba tartozol akik nem windowst használnak.

Hogy mi? És az OSX a maga ~8-9%-ával smafu? Csak mert PS oda is van.

> vagy implementálják a systemd-t BSD-re is.

Pontosítsunk: a systemd fogja asszimilálni a FreeBSD kernelt is, miután asszimilálta a Linux kernelt és majd felkínálja, hogy milyen kernelt futtasson, hogy futtassa saját magát, mint init!

A systemd-stub-al még az elején épp az volt a probléma, hogy nem igazán voltak ledokumentálva a systemd funkciói. Valamelyik (asszem) gentoo fejlesztő volt ezen kiakadva, hogy egyszerűen nem lehetett megtudni hogy a logind MIT CSINÁL?

Nem tudom, hogy mára mennyit javult a helyzet.

-1

A Solaris pl. egy élő és támogatott kereskedelmi UNIX és 11.4-től felfele (sajnos) a hivatalos desktopja (pkg install solaris-desktop) a GNOME3.
A piaci részesedés pedig egy teljesen lényegtelen dolog egy opensource projektnél; nem az a lényege, hogy "piacot" szerezzen. Szerintem. Viszont amihez systemd kell, az instant Linux-only lesz, márpedig nem csak a Linux létezik a világon. Igen, számítanak a FreeBSD-sek is a "0.0002%-os" részesedésükkel (honnan az adat, hogy kb. 14 ezren vannak?), a Solarisosok is a nemtommennyidekevés részesedésükkel, az OpenBSD-sekről, NetBSD-sekről, meg a többi mérhetetlenül kicsi táborról nem is beszélve. Mondom ezeket egyébként úgy, hogy én nem használok GNOME3-at, sőt semmilyen GTK3-dependens programot sem, de ettől még a non-Linux GNOME3 userek, most beszopták. <troll>Bár ki tudja, a GNOME3-at ismerve, lehet, hogy nekik a kényszerváltás megváltás lesz. :]</troll>

A számokat kb hasraütés szerűen írtam, a solaris meg nyílván váltani fog majd ha rákényszerül.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Nem az volt a lényeg, hogy mit fog tenni kényszerhelyzetben az Oracle (vagy az Illumos kernelű rendszerek fejlesztői), vagy, hogy pontosan hány ember használ BSD-t, hanem az, hogy nem csak a Linux létezik a világon.

> A piaci részesedés pedig egy teljesen lényegtelen dolog egy opensource projektnél; nem az a lényege, hogy "piacot" szerezzen. Szerintem.

Nem vállalkozom arra, hogy bármely open source projektről nyilatkozzak, pláne hogy a nevében beszéljek. Valószínűleg elképesztően bonyolult, hosszasan elemezhető, hogy hosszútávon merre haladnak a dolgok.

Évek óta rendszeresen fejlesztek egy bizonyos open source programon. Ha nagyon kíváncsi vagy, biztos rátalálsz, hogy melyik az. Talán még az is lehet, hogy a GNOME része, ki tudja. Csak a magam nevében beszélek: Jóval nagyobb eséllyel vetem bele magam egy olyan fejlesztésbe, ami felhasználók százezreihez, millióihoz jut el, mint olyanba, ami pár tucathoz, százhoz vagy ezerhez. És néha áldozatok is vannak ilyen téren, néha beáldozunk egy-egy kevés ember számára hasznos feature-t, hogy (akár közvetve, például felszabaduló fejlesztői erőforrásokon keresztül) másvalamiben sokak számára tudjunk jobbat adni.

Ha nem vagyok egyedül ezzel a hozzáállással, sőt, teszem azt, a fejlesztők jelentős részét hasonló érzések motiválják, akkor ez kimondatlanul is azt eredményezi, még ha ez nem is cél, hogy „magától” arrafelé halad a projekt, amerre piacot szerez magának.

Ez nem mond ellent annak, amit én leírtam: hogy nem a piacszerzés volt a cél.
Viszont itt nem egyszerűen valami feature lett beáldozva, amit kevesen használtak, hanem a felhasználók: a non-Linux GNOME3 userek összessége. Ez biztosan nem kevés ember azért.

hogy másvalamiben sokak számára tudjunk jobbat adni

Ez itt a kulcs. Én nem látom, hogy mi az a jobb, amit csakis és kizárólag ezzel a systemd-s fassággal lehet egy alkalmazásban elérni, ráadásul úgy, hogy ez a "jobbság" véletlenül sem tud opcionális lenni (--with-systemd). De nyilván majd valakik jól megmagyarázzák a bizonyítványt...

Én sem látom, hogy mi lett jobb, mivel nem ismerem a részleteket. De azt sem állítom, hogy nem lett jobb.

Az sem kizárt, hogy nagyon áttételes, hogy jobb lesz valami. Például egy adott változtatással a fejlesztőknek könnyebb lesz a dolguk, így több erőforrást tudnak valami attól teljesen független új feature-re fordítani.

Vagy az is lehet, hogy itt is csak az volt a cél, hogy egy újabb fontos mainstream projekt függjön a systemd-től.

nanana! A systems egy tökéletes válasz egy soha nem létező problémára!!! Mindent is tud, ami már addig is problémamentesen működött!!!! :)

Iwanabeguru! Ne beszélj hülyeségeket, mert gentoojedi is beguru' ám! Mi az H a nagyobb disztrók mind átálltak? Slackware - tessék!
Gentoo - opcionális ugyan, de tessék! Mellesleg ez a disztró a linuxok FreeBSD-je.
Debian - itt is opcionális,
/Szerk:az alternatív init rendszer az opcionális, de itt kettő is. A sysvinit és a gentoo féle openrc./

bár itt vannak kompromisszumok. Ha fontos a megbízható működés, akkor ott van a forkja a devuan.

A pclinuxos nem tudom mennyire számít nagy disztrónak. Annyira nem nagy ugyan, de állítólag független, de nekem úgy tűnik, mintha mandriva/mageia és Debian testing katyvasz lenne sysvinittel.
És akkor nem beszéltem a slacky meg gentoo származékokról.

A gentoot megértem, ott úgy rakod össze ahogy akarod, a Slack csak a széllel szemben próbál pisálni, Debianon is küzdhetsz aha akrsz de a szstemd a default ha jól tudom.
Úgyhogy a gentojedi nyugodtan begurulhat.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

"Úgyhogy a gentojedi nyugodtan begurulhat."

Nem fogok, mert teljesen akaratlanul sikerült benyalnod magad ezzel:

"A gentoot megértem"

"Debianon is küzdhetsz"

Ezzel tisztában vagyok, többek között ezért sem használok már pár éve saját gépre debiant.

Megkérdezném azokat akik folyamatosan a Gnome-systemd kapcsolaton nyafognak, hogy Gnome függők és Linux gyűlölők? (oké, nem elegáns a Gnome lépése, de nem kötelező használni, hálistennek van egy rakás másik DE).

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Ez egy tendencia, ami aggasztó. Így kezdődött a Linux disztrókkal is. Először csak a RedHat, meg a forkjai. Aztán a Debian, meg a forkjai. És így tovább. Manapság már kevesebb systemd mentes disztró van, mint systemd függő. Mi garantálja, hogy ugyanez a tendencia nem fog megismétlődni az asztali környezeteknél is? Mi lesz, ha holnap pl. a KDE kompánia kirukkol következőként ezzel a marhasággal, hogy systemdfüggő lesz a KDE5 (Plasma? Mittudomén...) Teccikérteni? Igen, van egy rakás másik nem-systemd-dependens DE is, még. De meddig?

Mindig lesz olyan DE, amihez nem kell systemd. Ha gondolod írásba adom neked.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Mi lenne ha leszállnál a magas lóról egy picit és helyette gondolkoznál, szintén csak egy picit.
systemd mentes Linux is van. De ettől még a régi sokak által ismert és használt Linuxok mind systemd fertőzötté váltak (respect a Slackware-nek, hogy ők nem). Aki pedig nem kért a systemd-ből, az bukta a rendszerét. És ez van a DE-kkel is, csak szteroidokon, mert a non-Linux rendszereken hótt irreleváns, hogy az illető user mit gondol a systemd-ről. Szerinted azokat az embereket, akik eddig GNOME3-at használtak BSD-n, vagy Solarison, vigasztalja, hogy van másik DE, amihez nem kell systemd? Csak azért, hogy átmenjen a lényeg, itt még csak nem is arról van szó, hogy az említett userek a systemd-függőség miatt protest-váltanak, hanem arról, hogy ha semmi bajuk sincs is a systemd-vel, akkor is megszívták, mert bukták a megszokott DE-jüket. Itt arról van szó, hogy egy kiterjedt userbázissal bíró cross-platform környezet egy mozdulattal kukásította a Linuxon kívüli rendszereket és felhasználóikat, csak azért, hogy systemd függő lehessen.

Ja, biztos lesz mindig systemd mentes DE, de ez nem fogja vigasztalni azokat, akiknek éppen borul a munkakörnyezete. Azonfelül nem tudom feltűnt-e, de elsősorban a mainstream cuccokra gyúrnak a systemd-nél, hogy azok legyenek systemd függők. Sokra fogunk menni, ha a létező non-systemd DE-k mind félkész, fapad vackok lesznek...

Az icewm pl. a mai napig tökéletes számomra. Ha frissen telepítek, mindig azt teszem fel második ablakkezelőnek. Első a twm :D

Különböző emberek, különböző igények. Az IceWM egyébként tényleg jópofa. Csak nehogy az Enlightenment WM sorsára jusson. :P

Az fvwm-mel sincs gond, tökéletesen műxik systemd nélkül, mint ahogy az elmúlt 20+ évben mindig tette :D

cat 2393016 | sed 's/Ice/FV/'

Értem a problémát, csak unom a hisztit, és inkább benyeltem a békát, és nem foglalkozom vele.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

> Értem a problémát

Ha értenéd, nem "nyelted volna be a békát".

> csak unom a hisztit

Neked minden ellenvélemény hiszti? Hiába sorol fel az ember húszezer műszaki érvet, neked az is hiszti?

> nem foglalkozom vele

Ehhez képest minden systemd topicba bejössz csak azért, hogy leírd, hogy téged mennyire untat az egész, mennyire nem érdekel, stb. Hogy is van ez?

Értem a problémát, de nem érint, mert nem vagyok GNOME és !Linux user, engem fikarcnyit se zavar hogy systemd van a gépemen, működik. A többiek lehet hogy rosszabbul jártak, de olyan ez mint a politika, nem lehet mindenkinek egyformán jó.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Ez kinek jó, a systemd developerein kívül?

Mondjuk a GNOME developereinek. Kevesebb rendszerhez, API-hoz kell igazodniuk így valószínűleg kevesebb erőforrást, munkát kell befektetniük ugyanahhoz a funkcionalitáshoz.
--
Légy derűs, tégy mindent örömmel

Hát az lehet, hogy megspóroltak valamennyi munkát, de így bukták a usereik egy részét, méghozzá véglegesen, mert systemd hiányában nem fog menni az érintettek rendszerein a GNOME3. Úgyhogy hosszútávon nekik sem biztos, hogy jó.

Ugyanitt pöccsering bárkinek szétcseszi a home-ját: https://www.phoronix.com/scan.php?page=news_item&px=systemd-homed
Érdemes nagy szemekkel nézni arra, amikor valaki bekérdez, hogy na de és akkor az SSH....hááát aztat nem tudom/nem fog működni a válasz :D
priceless

nagyon várom a systemd-gnomed-t :D

Eddig a systemd homeless volt, most már nem :)

A JSON-based lefagyasztott. Hát ha a Linux akar az új CelebOS (aka vindoze) lenni, sok sikert neki. systemd-fuckd ami még kellene nagyon, nem baj ha rossz és haszontalan, csak vegyék.
____________________
echo crash > /dev/kmem

Hal istennek a Linux el es virul csak a userspace hulyult meg teljesen. Az utibbi evekben mar lehet menetkozben kernelt cserelni onmaga alatt, de ujra kell inditani a gepet a systemd-XXXXd daemon miatt, mert azt aztan kiloni sem lehet. A systemd a Linux windowsa. Remelem az MS elorukkol valamivel Linux vonalon es akkor mar nyergelek is at oda, ha az systemd mentes lesz.

Microsoft Lindows, vagy Windolx pl.? Nem is tudom mitol sirjak jobban ;)
____________________
echo crash > /dev/kmem

MX Linuxot nézted? Valami systemd-kompatibilitási dolgot leszámítva systemd-mentes, és az utóbbi időkben nagyon dicsérik. (Distrowatchon 940 értékeléssel 9,0-ás átlaga van.) Én még csak laptopon kísérletezek vele; ha sikerül beállítani rajta a Mullvad VPN-t (mert természetesen a systemd nem találja a mullvad service fájlját), akkor már csak adatmentés kell, és jöhet a költözés. =)

Továbbá ott van még az antiX is, ami tudtommal az MX kistestvére. Némileg fapados (asszem JWM-et vagy IceWM-et használ alapból), de róla is sok jót mondanak.

- - -

Köszi ezt kipróbálom.
Szedem is lefelé az MX-et adok neki egy esélyt.

> pöccsering bárkinek szétcseszi a home-ját

Nekem munkatársam küldött róla linket; ha nem látom, hogy a systemd Git-wikijéből van, azt hittem volna, hogy valami troll írta, de nem.

> hááát aztat nem tudom/nem fog működni

Na, igen, Poetteringnél a "rosszul használod, wontfix, closed" válasz valószínűleg már billentyűkombinációra megy. =(

- - -

Nem védem a csávót, értem a problémákat. Viszont azt vegyük észre, hogy az észrevételek amire megoldást akar kínálni legalább részben jogosak. És nem látok jobb konkurens alternatívát a systemd-nél (nem mint ha az jó lenne).

Az egyik tábor megpróbálkozott valamivel (lásd upstart a Canonicalnál) és mindenki ekézte őket, minek feltalálni a spanyolviaszt, stb.

A másik tábor azt nyomja, hogy jó az ami volt, holott ez szimplán nem igaz. A systemd sok szempontból szar, bizonyos dolgok viszont jobbak, egyszerűbbek lettek.

Szóval értem én, ez nem jó. Csak azt nem értem miért csak mindenki fikázni tud, megoldást meg senki :)

Én annyit értek az egész systemd-es dologból hogy ugyan nálam "általában" működik, de mióta átállt rá jó pár eddig gyors és pici disztribúció, többszörös lett a méretük, a 3-4 másodperces hdd-ről bootolásból akár 20 másodperces boot van ssd-ről. Ha meg valami nem működik,a hibakeresés is sokkal bonyolultabb lett, ráadásul múltkor találtam valami olyan naplófájlt, ami csak valami gnome-os naplónézegetővel volt olvasható. 5-6 éve egy debian úgy elfért 5 gigán swappal, fullos xfce4-el, alap szoftverekkel, hogy semmit nem kellett a méreten optimalizálni. Ma ennek minimum a duplája szükséges. És nem, nem csak a szoftverek és a DE-k mérete nőtt meg.
Az alaprendszer mérete lett sokszoros és a systemd-el kapcsolatos függőségek rántanak be sok-sok dolgot és nő a méret.

Amíg a "régi" init rendszer volt,olyan gyorsan bootolt minden, öröm volt nézni, és olyan pici rendszereket lehetett összerakni, néha én magam is el-elcsodálkoztam mit nem sikerült megoldani. Ma meg...

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

systemd-analyze
Meg fogja neked mondani, hogy mi mennyi ideig tart, mi mire vár stb.

Idézet:
Ráadásul múltkor találtam valami olyan naplófájlt, ami csak valami gnome-os naplónézegetővel volt olvasható.

Ha a journal-ra gondolsz, akkor journalctl, aztán abba pipe-olod át, amibe akarod (viszont cserébe kismillió formában szűrhető, leghasznosabban, hogy melyik service-hez tartozó üzeneteket keresed)

Idézet:
Az alaprendszer mérete lett sokszoros és a systemd-el kapcsolatos függőségek rántanak be sok-sok dolgot és nő a méret.

Pedig a systemd-nek pont marha kevés függősége van, mert jó Borg módjára mindent is asszimilál (najó, a libqr-t és a tökömtudja melyik http server, ami opcionális függősége, azokat még nem sikerült, de próbálkozik :) )

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

> Ha a journal-ra gondolsz, akkor journalctl, aztán abba pipe-olod át, amibe akarod (viszont cserébe kismillió formában szűrhető, leghasznosabban, hogy melyik service-hez tartozó üzeneteket keresed)

A bináris loggolás pont az egyik legnagyobb agyréme a systemd-nek (még Torvalds is felemlegette, pedig amúgy eléggé csöndben van a systemd kapcsán), nem csak az a baj vele, hogy szeret korruptálódni, de alapvetően a logoknak az a lényege, hogy az ember tudja őket olvasni. Annak mi értelme van, hogy forwardoljuk, hogy ugyanazt kapjuk, mint nélküle? A sokat emlegetett meta-adatokat meg szöveges fájlokban is meg lehet jeleníteni.

A systemd-analyze-ot ismerem,használtam. Tök jó, hogy megmondja,minden mennyi ideig tart. És tök jó, hogy látom,mennyi mindent tölt be feleslegesen,és hogy mennyi mindennel kéne rengeteget szívnom,hogy megkapjam egy init rendszer faék egyszerűségét, hogy HA akarom, CSAK azt töltse be/próbálja betölteni amit én akarok. Ne mindent. IS.

Bocs, én csak egy buta maradi ember vagyok, nem látom át a journalctl, aztán abba pipe-olod át, amibe akarod csodálatos egyszerűségét a tördelt szöveges file bonyolultsága mellett.

5-6 éve egy telepített alaprendszer elfért ~100 Mb körül. Ma ugyanez 300+ Mb körül van. A változás a sytemd megjelenésével történt meg.
Értem én az automatizáció előnyeit,meg hogy minden egy helyről, de ez akkor is szar.

Értem én az is, hogy a mai világban a terabyte-os ssd-k idején a picsogásom sokaknak érthetetlen, de azzal vitázni, hogy igazam van, hát, sok értelme nincs...

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

> a tördelt szöveges file bonyolultsága mellett.

Itt azért nem csak egyszerűségről van szó, hanem használhatóságról. Ha az adatok nem struktúráltan vannak tárolva, akkor nehezebb velük dolgozni. Értem, olvasni könnyű, de a journalctl kimenetét se nehéz.

Cserébe csak próbáld megoldani a log entry-k dátumra szűrését. Esetleg egyszerre nézni több alkalmazás logját egy időintervallumban. Vedd figyelembe, hogy bizonyos appok a logokba hánynak dátummal nem jelzett sorokat is, mert csak.

Értem én, hogy bash mágiával megoldható, de nem kényelmesebb céleszközökkel? Az viszont csak úgy tud működni, hogy ezek az információk minden egyes sorhoz metaadatként társulnak, nem pedig a szöveg része valahogyan.

Szerk: A tisztánlátás végett: Nem védem és nem mondom hogy minden szempontból jobb, vagy ne lenne gond vele. Azt mondom, hogy arra hivatkozva, hogy "jó volt régen is" ne utasítsunk el már mindent élből. Mert ennyi erővel vissza is mehetnénk a számítástechnika őskorába, hiszen az aztán faék egyszerű volt a mostani világhoz képest.

> Cserébe csak próbáld megoldani a log entry-k dátumra szűrését.

cat /var/log/x.log | grep "21:40"

> Esetleg egyszerre nézni több alkalmazás logját egy időintervallumban.

cat /var/log/*.log | grep "21:40" | sort

Vagy ha esetleg szeretnéd látni melyik sor melyik fájlé:

for file in /var/log/*.log; do cat $file | grep "21:40" | sed "s/^/\x1B[1m`basename $file`@\x1B[0m /g"; done | sort -t '@' -k2

Azért ezek az egysoros megoldások elég messze állnak a mágiától; mennyivel rosszabbak ezek, mint a journalclt-t pipe-olni más parancsoknak?
A metaadatokat meg ugyanúgy lehet szövegesen tárolni. És nem arról van szó, hogy jó volt régen is, hanem arról, hogy a systemd nem létező problémákat old meg, vagy a megoldása rosszabb, mint a probléma.

Vagy ha esetleg szeretnéd látni melyik sor melyik fájlé:
Esetleg inkább grep -H "21:40" /var/log/*.log? :) Jó, nem POSIX, de a linuxos grep (is) tudja.

[troll]

Idézet:
Jó, nem POSIX, de

De itt pont az a lényeg, hogy le kell ragadni az előző évezredben, a 22 évvel ezelőtt szabványosított 50 éves megszokásoknál, különben mindmeghalunk!!!négy! :P
[/troll]

(nem mintha _bármilyen_ sima szöveges izé ki tudná hozni azt, hogy adott időintervallumban az egy service-hez tartozó összes logbejegyzést megkapd (--since --until --service oszt jónap), mert sok esetben [pl. random daemon forkol egy random külső processzt, ami nem a daemon megszokott logolási mechanizmusát használja] nincs mivel összekapcsolni az egy szolgáltatáshoz tartozó bejegyzéseket...)

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

Nem akarok én beleszólni a systemd vs non-systemd vitába, csak a grep-hez kívántam hozzátenni.
De azért esetleg egy kicsit: régebben (és bizonyára most is) voltak különböző log analizátor programok, amelyek a különböző formátumokat megzabálták és mindenféle okosságokat kihoztak. Sose használtam ilyet, nem voltam sose üzemeltető, csak gondoltam, megemlítem, hogy voltak/vannak célirányosabb programok erre a grep-en túl :)

Persze, hogy vannak, de a systemd-nek ott van a plusz infó, hogy X processz az Y service-hez tartozik és akárhogy forkol, exec-el stb., ez meg is marad (cgroupokkal követi). Így pl. ha lekérem a journalból az nrpe logjait, abban megjelenik az indított sudo összes logja (ha valamit nem az nrpe user nevében kell futtatnom), holott "semmi közük" egymáshoz. Ezt nem nagyon fogja tudni neked más összekötni.

Ráadásul a log analizátor programok (meg a kismillió különböző syslog implementáció, meg a simán fájlba gyűjtött logok, meg...) is azt mutatják, hogy volt egy folyamatosan fennálló probléma: az egységes logolás és legalább a fontosabb dolgokban egységes formátum (minimum: időbélyegző...) hiánya.

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

> Ezt nem nagyon fogja tudni neked más összekötni.

Honnan tudod, hogy nincs más logging szolgáltatás, ami ezt nem tudja?

> és legalább a fontosabb dolgokban egységes formátum (minimum: időbélyegző...) hiánya.

Ez tény, de erre nem az a megoldás, hogy már megint mindent a systemd-n keresztül intézzen az összes program. Ha úgyis bele kell nyúlni a programba - és bele kell, hiszen a systemd call-ok használatához is bele kell - akkor ennyi erővel egy a változtatás lehet egy egysoros patch is, ami beleteszi az időbélyeget is a logsorokba.

Idézet:
és bele kell, hiszen a systemd call-ok használatához is bele kell

Csakhogy nem kell belenyúlni: a systemd által indított service-knél az stderr (sőt, azt hiszem, az stdout is) azonnal megy a journalba, a (helyi) syslog hívások pedig szintén a journalnál csapódnak le - ahol ott van, hogy ki tudja keresni a PID-cgroup-systemd unit összerendelést és a megfelelő metaadatot hozzá tudja tenni a logbejegyzéshez.

A D-Bus-os interfész használatához valóban módosítani kell a kódot, de anélkül is szvsz. jobb minőségű naplókat ad.

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

> Csakhogy nem kell belenyúlni: a systemd által indított service-knél az stderr (sőt, azt hiszem, az stdout is) azonnal megy a journalba, a (helyi) syslog hívások pedig szintén a journalnál csapódnak le - ahol ott van, hogy ki tudja keresni a PID-cgroup-systemd unit összerendelést és a megfelelő metaadatot hozzá tudja tenni a logbejegyzéshez.

Hát bocs, de akkor ez duplán minősített eset, hiszen a systemd így gyakorlatilag abszolút semmit nem egységesített, hanem csak felparseolja a logokat, pontosan ugyanúgy, mint ahogy én is mondtam, csak teszi ezt pár kiló helyett a jóég tudja hány megában és egy erre specializált script/program helyett húzva magával az egész systemd ökoszisztémát... Látod erről beszéltem már nem egyszer, ha van is benne valami használható ötlet, vagy megoldás, ahhoz is kapod az egész rettenetet. Poettering saját magával szúrt ki: ha egy all-in-one monstrum helyett egy sereg egymástól függetlenül is működni tudó tool-t és service-t programozott volna le, akkor max. a bugok miatt kapott volna, de azokat meg már rég kifixálták volna azok, akik az adott tool-t/service-t hasznosnak ítélték és akkor Poettering lehet, hogy kevésébé ismertebb, de egységesen elismertebb lenne, a nem-feltétlenül-de-lehet-hogy-hasznos cuccaival és nem lenne lehetőség azzal kritizálni, hogy az egyik vagy másik tool felesleges marhaság, mert opcionális lenne az egész, nem pedig egy felülről ránkerőltetett ökoszisztéma és nem utálná a szakmai világ fele...

> de anélkül is szvsz. jobb minőségű naplókat ad.

Lehet, de mint mondtam, teszi ezt egyfelől egy corruption-prone és machine-readable-only formátumban, másrészt meg teszi ezt hússzor annyi erőforrásért (/summon hajbazer) és vonszolva maga után az egész systemd-t, amit a kutya nem kért. Az össze-vissza loggolás valóban probléma, de itt a megoldás rosszabb, mint a probléma! Az egyik megoldás az, hogy megírja rá az ember a csak ezért felelős parser/filter programját/scriptjét, a másik pedig az, hogy a programok íróinak patch-et, vagy javaslatot küldünk, hogy ugyan próbáljon már meg valami egységesen elfogadott formázással loggolni. Ehhez nem kell a systemd...

Idézet:
egy sereg egymástól függetlenül is működni tudó tool-t és service-t programozott volna le,

És az a sereg egymástól függetlenül is működni tudó tool:
a) hogy kapta volna el az _összes_ daemon stdout-ját/stderr-jét?
b) hogy kapta volna el az _összes_ daemon helyi syslog üzeneteit? (jó, ez éppen triviális, az összes syslog daemon erre való)
c) hogyan találta volna ki, hogy a 314-es PID-ű /usr/bin/nrpe stderr-je és a 12982-as PID-ű /usr/sbin/sudo által a syslognak küldött üzenetei egybe tartoznak?

Ha ez ennyire triviális probléma, akkor miért a systemd volt eddig az egyetlen, ami meg tudta oldani, holott korábban is már kismillió csomagnyi "sereg egymástól függetlenül is működni tudo tool" volt erre?

Tényleg olyan sokat nyernénk azzal, ha kitalálnánk egy random API-t (de szigorúan nem D-Bus, mert a systemd azt használja, tehát az eleve maga a gonosz, gondolom...), amivel egy azt implementáló szervíz-menedzsertől le tudná kérni egy azt szintén implementáló logmenedzser a C)-ben levő adatokat, hogy alapból úgy konfigurálnánk minden service-t, hogy azok stdout/stderrjét megkapja a loggoló alrendszerünk (persze cserélhető módon), ...

Idézet:
Az egyik megoldás az, hogy megírja rá az ember a csak ezért felelős parser/filter programját/scriptjét, a másik pedig az, hogy a programok íróinak patch-et, vagy javaslatot küldünk, hogy ugyan próbáljon már meg valami egységesen elfogadott formázással loggolni.

1) régóta van ilyen (syslog), nem sikerült mindenhol elterjednie
2) ha a fő daemont meg is patcheled, be is olvasztják, ..., ha külső állományokat hív, arra nincs hatása a patchednek (mondjuk egy NetworkManager indít egy openvpn processzt, ami aztán a fél világot hívogatja magától)

Idézet:
Az össze-vissza loggolás valóban probléma, de itt a megoldás rosszabb, mint a probléma!

Tehát a három lehetőség: 1) egy önjelölt barom kitalál valamit, elterjeszti, ami még ha megkérdőjelezhető implementációs szempontból (egybeforrasztott az "init rendszerrel", bináris fájl), de legalább működik, 2) magyarázzuk továbbra is, hogy jobb az, ha _mindent IS_ megpatchelünk, hogy távolról egységes legyen vagy 3) nem csinálunk semmit. És ezek közül szerinted minden jobb, mint az 1?

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

> a) hogy kapta volna el az _összes_ daemon stdout-ját/stderr-jét?

Miért, így hogy kapja el? Erre mondtam, hogy ha bele kell nyúlni az initbe, akkor tegyék; én nem mondtam, hogy a SysVInit szentírás és nem lehet rajta módosítani, vagy másik initrendszert csinálni. Tudom, hogy sok probléma van vele, de a systemd rossz válasz! Kérdezd meg pl. az OpenRC, vagy a s6 fejlesztőit, hogy mi a véleményük egy ilyen piping opcióról.
Egyébként meg egy daemon-t el lehet indítani úgy, hogy akár a kimeneteit, akár a logfájlját átirányítod valahova. Ez egy másik program csöve is lehet.

> b) hogy kapta volna el az _összes_ daemon helyi syslog üzeneteit? (jó, ez éppen triviális, az összes syslog daemon erre való)

(Megválaszoltad magadnak.)

> c) hogyan találta volna ki, hogy a 314-es PID-ű /usr/bin/nrpe stderr-je és a 12982-as PID-ű /usr/sbin/sudo által a syslognak küldött üzenetei egybe tartoznak?

Ld. a) pont és cseréld a releváns részeket.

> 1) régóta van ilyen (syslog), nem sikerült mindenhol elterjednie

Ez nem érv a systemd mellett. Mitől lenne az? Azért, mert az elterjedt, mert Poettering és a RedHat erőszakosan elterjesztette? Ennyi erővel ezt is lehet erőszakosan terjeszteni...

> 2) ha a fő daemont meg is patcheled, be is olvasztják, ..., ha külső állományokat hív, arra nincs hatása a patchednek (mondjuk egy NetworkManager indít egy openvpn processzt, ami aztán a fél világot hívogatja magától)

Ha én meghívok egy külső állományt, akkor az azt jelenti, hogy a shellje is nálam van. Látok mindent, amit csinál és azt teszek vele, amit akarok, mert én vagyok a parent process és ennek megfelelően oda irányítom minden ki és bemenetét, ahova akarom. Úgyhogy de: a daemonba küldött patch-nek erre is van hatása.

> Tehát a három lehetőség: 1) egy önjelölt barom kitalál valamit, elterjeszti, ami még ha megkérdőjelezhető implementációs szempontból (egybeforrasztott az "init rendszerrel", bináris fájl), de legalább működik, 2) magyarázzuk továbbra is, hogy jobb az, ha _mindent IS_ megpatchelünk, hogy távolról egységes legyen vagy 3) nem csinálunk semmit. És ezek közül szerinted minden jobb, mint az 1?

Korrekció: s/de legalább működik/és nem működik/ vagy esetleg s/de legalább működik/és nekem működik/. Így már nyugodtan lehet mondani, hogy bármi jobb, mint az 1) ugyanis az nem működik, vagy max. neked működik. Továbbá: az 1) lehetne jó, ha kivesszük belőle az implementációs szempontból megkérdőjelezhető részeket. Én erről beszéltem, csak ezt valahogy kihagytad a lehetőségek közül, így egy hamis dilemmát kreálva.

Idézet:
Tudom, hogy sok probléma van vele, de a systemd rossz válasz!
...
Ld. a) pont és cseréld a releváns részeket.

Legyen egy init rendszer, ami tudja ugyanazokat a szolgáltatásokat, mint a systemd, de ne a systemd legyen!!!!

Egyébként mennyivel lenne jobb, ha az OpenRC kapna egy OpenRC-logger-t, ami meg csak OpenRC-vel menne (pont ugyanazért, mert az OpenRC tudna neki a működéséhez szükséges infókat adni)

Idézet:
Mitől lenne az? Azért, mert az elterjedt, mert Poettering és a RedHat erőszakosan elterjesztette? Ennyi erővel ezt is lehet erőszakosan terjeszteni...

Nem, ez azért érv mellette, mert nem kellett hozzá a daemonokon módosítani ahhoz, hogy egységesebb logolást (és jobb) kapj, mint a másik megoldásnál, ami az, hogy _mindent_ módosítani kell.

Idézet:
vagy max. neked működik.

Meg a Linux felhasználóinak további kb. 90+%-ának...

Idézet:
Továbbá: az 1) lehetne jó, ha kivesszük belőle az implementációs szempontból megkérdőjelezhető részeket.

Lehet hozzá patchet küldeni, és akkor csak egyszer kell dolgoznod ;) Az implementációs szempontból megkérdőjelezhető részek egyike ráadásul majdhogynem kötelező (ki kell találnod egy API-t, amivel a szolgáltatás-felügyelődtől lekérdezheti a logoló, hogy mégis mi micsoda és mindent be kell rugdosnod a szolgáltatásfelügyelő alá, amit képessé kell tenned arra, hogy mindezt kövesse... - aztán vagy te is összevonod ezt a két a funkciót, vagy örökkévalóság +1 napig bikesheddel a teljes open source közösség, hogy milyen "csoport" azonosítók lehessenek stb.)

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

> Legyen egy init rendszer, ami tudja ugyanazokat a szolgáltatásokat, mint a systemd, de ne a systemd legyen!!!!

Figyelj, ha folyton olyanokra reagálsz, amit én nem mondtam, akkor semmi értelme a vitának. Kezdjük azzal, hogy a systemd nem egy init rendszer, hanem már minden is, egyben; épp te jössz mindig azzal, hogy ez egy ernyőprojekt. Folytassuk azzal, hogy ha a systemd-ben van valami, ami hasznos, akkor semmiféle ideológia nem gátol senkit sem abban, hogy felhasználjuk. Belemagyarázol dolgokat és arra reagálsz.
Ha Poettering csinált volna egy új init rendszert, ami ténylegesen a SysVInit problémáira ad választ, meg csinált volna egy raklap egyéb toolt, nekem nem lenne vele bajom, max. a bugok miatt, de azokat meg lehet javítani, vagy lehet mást is használni. Értsd meg végre, hogy hiába mutogatsz valamire a systemd-ben, aminek esetleg van értelme, ha mellé kapunk minden mást is, aminek nincs. (És aminek van értelme, azt is úgy oldják meg, hogy jajj...)
Úgyhogy a szarkasztikus mellébeszélést így lehetne átfogalmazni: legyen egy initrendszer, ami azt tudja, amit kell (és nem szégyen a systemd-től sem tanulni, ha véletlen van mit), de ne tudjon ötvenezer olyan dolgot, amit nem kell tudnia.

> Egyébként mennyivel lenne jobb, ha az OpenRC kapna egy OpenRC-logger-t, ami meg csak OpenRC-vel menne (pont ugyanazért, mert az OpenRC tudna neki a működéséhez szükséges infókat adni)

Nem feltétlenül. Az init rendszerek adhatnak erre backendet, a loggerek meg erre csatlakozhatnak. Nyugodtan lehet olyat is írni, ami több initrendszerét is ismeri.

> Nem, ez azért érv mellette, mert nem kellett hozzá a daemonokon módosítani ahhoz, hogy egységesebb logolást (és jobb) kapj, mint a másik megoldásnál, ami az, hogy _mindent_ módosítani kell.

A sysloghoz sem kell a daemonokon módosítani, tehát ez nem érv a systemd mellett.

> Lehet hozzá patchet küldeni, és akkor csak egyszer kell dolgoznod ;)

Nem fogják elfogadni, hiszen alapjában változtatná meg a rendszert. (Láttam a smiley-t, csak leszögeztem egy tényt.)

> Az implementációs szempontból megkérdőjelezhető részek egyike ráadásul majdhogynem kötelező (ki kell találnod egy API-t, amivel a szolgáltatás-felügyelődtől lekérdezheti a logoló, hogy mégis mi micsoda és mindent be kell rugdosnod a szolgáltatásfelügyelő alá, amit képessé kell tenned arra, hogy mindezt kövesse... - aztán vagy te is összevonod ezt a két a funkciót, vagy örökkévalóság +1 napig bikesheddel a teljes open source közösség, hogy milyen "csoport" azonosítók lehessenek stb.)

Tehát ahhoz, hogy a systemd egy monolitikus, szűrhető/kereshető logging szolgáltatást nyújtson, ahhoz kell pl. a logind, vagy a resolved? Itt nem az a baj, hogy két olyan funkciót vont össze, amit külön is lehet, meg egybe is lehet és ő az egybét választotta, hanem az, hogy itt hatvannyolcezer funkciót vontak össze, feleslegesen.

Idézet:
Az init rendszerek adhatnak erre backendet, a loggerek meg erre csatlakozhatnak.

Tehát (ahogy lentebb a kolléga is említette), kvázi köteleznél minden init rendszer és logrendszer írót, hogy tartsanak be egy API-t, amit valaki valahol kitalált, és jó esetben használható is és nem hátráltat senkit.

Idézet:
Nyugodtan lehet olyat is írni, ami több initrendszerét is ismeri.

Oks, mégse, mindenki írja meg az összes init rendszerhez a saját illesztőjét (márha az adott init rendszer ad megfelelő funkcionalitást ehhez), tehát legyen n*k protokollunk.

Idézet:
A sysloghoz sem kell a daemonokon módosítani, tehát ez nem érv a systemd mellett.

Láthatóan kell, mert nagyon sok daemon simán stderr-re logol, van, ami saját fájlba saját formátummal (<- ezzel egyébként sajnos még mindig nem kezdtünk semmit :( ) és véletlenül sem a syslogba.

Idézet:
Tehát ahhoz, hogy a systemd egy monolitikus, szűrhető/kereshető logging szolgáltatást nyújtson, ahhoz kell pl. a logind, vagy a resolved?

Resolved speciel semmihez nem _kell_, opcionális (mint oly sok minden más, amit kifogásolsz). A logind pedig közvetlenül nem vesz részt a logolásban, viszont a logba bekerülnek olyan adatok, amiknek a létrehozásáért a logind felel (pl. session id).
Minden egyes szerinted felesleges összegyúrásnál ott lenne, hogy vagy funkciót vesztesz nélküle, vagy csak API-t adna, amit mindenki vagy implementál, vagy nem (speciel itt van egy szép lista: https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/, a loggerhez a Service Bus API getUnitByPID() hívása az, amit minimum implementálnia kellene mindenkinek - természetesen mögötte az összes logikával, ami kell ahhoz, hogy egy random PID-hez tudj mondani egy unit-ot)

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

> Tehát (ahogy lentebb a kolléga is említette), kvázi köteleznél minden init rendszer és logrendszer írót, hogy tartsanak be egy API-t, amit valaki valahol kitalált, és jó esetben használható is és nem hátráltat senkit.

Már megint szavakat adsz a számba. Feltűnt a feltételes mód: "adhatnak"? Én nem kötelezek senkit semmire. Egy lehetőségről beszéltünk.

> Oks, mégse, mindenki írja meg az összes init rendszerhez a saját illesztőjét (márha az adott init rendszer ad megfelelő funkcionalitást ehhez), tehát legyen n*k protokollunk.

Tekintve, hogy hány ilyen megoldás van/lesz, valószínűleg tök mindegy hogy szorzod, nem fogsz túl magas számot kapni.

> Láthatóan kell, mert nagyon sok daemon simán stderr-re logol, van, ami saját fájlba saját formátummal

Ha úgyis bele kell nyúlni az initbe, akkor miből áll egy opció, hogy át lehessen irányítani a child processek streamjeit?

> (<- ezzel egyébként sajnos még mindig nem kezdtünk semmit :( )

De, csak neked nem tetszett.

> Resolved speciel semmihez nem _kell_, opcionális (mint oly sok minden más, amit kifogásolsz). A logind pedig közvetlenül nem vesz részt a logolásban, viszont a logba bekerülnek olyan adatok, amiknek a létrehozásáért a logind felel (pl. session id).

Félreértettél: arról van szó, hogy mi kell a loggoláshoz, nem pedig arról, hogy melyik systemd komponens haszálja a systemd log subsystem-jét. Arra akartam rávilágítani, hogy lehet, hogy pl. csak loggolni akarunk, de ennek ellenére jön a többi cumó is.

> Minden egyes szerinted felesleges összegyúrásnál ott lenne, hogy vagy funkciót vesztesz nélküle, vagy csak API-t adna, amit mindenki vagy implementál, vagy nem (speciel itt van egy szép lista: https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/, a loggerhez a Service Bus API getUnitByPID() hívása az, amit minimum implementálnia kellene mindenkinek - természetesen mögötte az összes logikával, ami kell ahhoz, hogy egy random PID-hez tudj mondani egy unit-ot)

Ha csak annyi dolog lenne összegyúrva, ami kellene, az beleférne, de nem annyi van. Hovatovább, random PID-hez unit: ha még él a PID, akkor lekérem a PPID-et és máris tudom. Ezt egyébként simán lehet az (bármilyen) inittől függetlenül is logolni, hogy mikor melyik processz milyen PID-del mit indított, vagy mikor szállt ki...

BTW. "Reimplementable Independently" "maybe" Ez micsoda? Nem tudják, hogy lehet-e függetleníteni? Arról nem is beszélve, hogy a "**systemd Implementation portable to other OSes or non-systemd distributions" oszlop elemei között egy darab yes van, a többi az no, vagy ritkábban partially.

> De itt pont az a lényeg, hogy le kell ragadni az előző évezredben, a 22 évvel ezelőtt szabványosított 50 éves megszokásoknál, különben mindmeghalunk!!!négy! :P

Bocs, de ez még trollkodásnak is nagyon gyenge volt. Senki nem mondta, hogy ragadjunk le, hogy ne haladjunk. Az viszont nem mindegy, hogy merre haladunk és a systemd rossz irány.

> (nem mintha _bármilyen_ sima szöveges izé ki tudná hozni azt, hogy adott időintervallumban az egy service-hez tartozó összes logbejegyzést megkapd (--since --until --service oszt jónap), mert sok esetben [pl. random daemon forkol egy random külső processzt, ami nem a daemon megszokott logolási mechanizmusát használja] nincs mivel összekapcsolni az egy szolgáltatáshoz tartozó bejegyzéseket...)

Már hogy ne tudná. Maximum ahogy egyre szofisztikáltabb lekérésekre van szükség, úgy kell finomítani a cuccot is. Senki nem mondta, hogy az ilyen jellegű szűrések haszontalanok lennének, na de, ehhez miért is kéne a systemd sok-sok megája, amikor akár shellben, akár C-ben (vagy egyéb kedvenc nyelvben) össze lehet erre rakni egy parsert? Ha esetleg az init rendszerben ehhez módosítani kell valamit, azt is nyugodtan meg lehet csinálni. Itt van a kutya elásva, hogy ha van is a systemd-ben hasznos dolog, vagy ötlet, nem tudod csak úgy külön használni, akkor is kapod hozzá az egész catastrophed-t, ha tótágast állsz és mekegsz. Meg kell írni külön-külön az összes cuccot, amik csak azért felelnek, ami a feladatuk.

Idézet:
Bocs, de ez még trollkodásnak is nagyon gyenge volt.

:( Hát jó...

Idézet:
amikor akár shellben, akár C-ben (vagy egyéb kedvenc nyelvben) össze lehet erre rakni egy parsert?

MERT ÖSSZE KELL RAKNI HOZZÁ EGY PARSERT, LÁTHATÓAN TÖK FELESLEGESEN.

És felőlem lehet ez a systemd-journald páros, lehet ez az Upstart+ILF (Imaginary Logging Facility), akár csak egy sima logger, amibe be tudom pipe-olni minden service kimenetét, syslog hívását, állandóan felnyalja a daemonok által "kézzel" írt logfájlokat stb. Jelenleg nincs másik olyan naplózó szolgáltatás, ami a különböző forrásokból származó, de logikailag egybe tartozó bejegyzéseket összeszedné (lásd még a fenti nrpe + sudo példát) és kapásból elvi akadálya is van, az, hogy ha nem készíted fel erre előre a rendszert, akkor a különböző források (a fenti példában: különböző processzek) összepárosítása a megfelelő infó hiányában kb. lehetetlen.

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

> MERT ÖSSZE KELL RAKNI HOZZÁ EGY PARSERT, LÁTHATÓAN TÖK FELESLEGESEN.

Láthatóan tök nem feleslegesen! Ez egyszerűen nem érv, hogy a systemd majd ezt is megoldja helyettünk! Mit oldjon még meg a systemd, mi nincs benne? Legyen benne pl. system-updater is, mondjuk "updated" néven, ami ellentmondást nem ismerő módon lefrissíti a rendszeredet, akkor is, ha nem kérted, mert ő ezt jobban tudja, á la windóztíz? Ne tudjon mindent jobban! Pláne ne így... Nem az a bajom, hogy van benne egy logparser/filterer, hanem az a bajom, ahogyan ezeket megoldotta.

> És felőlem lehet ez a systemd-journald páros, lehet ez az Upstart+ILF (Imaginary Logging Facility), akár csak egy sima logger, amibe be tudom pipe-olni minden service kimenetét, syslog hívását, állandóan felnyalja a daemonok által "kézzel" írt logfájlokat stb. Jelenleg nincs másik olyan naplózó szolgáltatás, ami a különböző forrásokból származó, de logikailag egybe tartozó bejegyzéseket összeszedné (lásd még a fenti nrpe + sudo példát) és kapásból elvi akadálya is van, az, hogy ha nem készíted fel erre előre a rendszert, akkor a különböző források (a fenti példában: különböző processzek) összepárosítása a megfelelő infó hiányában kb. lehetetlen.

De ember, pontosan erről beszéltem, hogy amíg a systemd is csak felparse-álja őket, nem pedig logging backendet biztosít, addig az nem egységesítés, hanem ugyanott vagyunk, mint egy független toollal! Az, hogy a systemd-nek itt van egy specifikus for-ja, az egy dolog, mert azt a funkcionalitást át lehet ültetni más tool-okba, szolgáltatásokba is.

Én kérek elnézést, hogy reflexből POSIX shell kompatibilis kódot írok. :P

> > Cserébe csak próbáld megoldani a log entry-k dátumra szűrését.
> cat /var/log/x.log | grep "21:40"

1. Oké, de ezzel nem szűrtél intervallumra. Bár nem volt kiemelve, de nálam a dátumra szűrés jellemzően inkább az
2. Oké, csakhogy ezzel bekerül minden olyan, ami tartalmazza a 21:40-et. Akár dátum (időpont?) akár nem. Például mi van ha a log szövegének része egy másik dátum valami oknál fogva?

A grep egy jó cucc, és nem mondom, hogy nem megoldhatatlan a feladat. Azt mondom, hogy struktúrált adatokkal mindennek ott a helye, és adattípushoz passzoló eszközöket kapsz (nos, illene kapnod). Ezzel szemben egy szöveges log azt és olyan formában tartalmazza, amit az adott app épp kiköp magából. Ahány app annyiféle dátumformátum, van ami local időt, van ami UTC-t használ, abban szűrj kényelmesen greppel. Ismétlem, jó cucc. Csak nem erre való. Tudod, a kalapács esete.

> A metaadatokat meg ugyanúgy lehet szövegesen tárolni.

Lehet, persze. Eltárolhatod jsonben, xml-ben, akár csv-ben is, csak épp innentől kell valami formátum specifikus parser, mert különben ugyanúgy meg vagy lőve az idézőjelek, escape-elések, és a szövegben előforduló, de nem adatnak számító elemekkel.

> hogy a systemd nem létező problémákat old meg, vagy a megoldása rosszabb, mint a probléma.

Ez a kijelentés még lehet igaz, de ez általánosítás, itt épp most kifejezetten a struktúrált logolás előnyeiről próbálok csak értekeni. Ettől még lehet a systemd-nek sok sara :)

> 1. Oké, de ezzel nem szűrtél intervallumra. Bár nem volt kiemelve, de nálam a dátumra szűrés jellemzően inkább az
> 2. Oké, csakhogy ezzel bekerül minden olyan, ami tartalmazza a 21:40-et. Akár dátum (időpont?) akár nem. Például mi van ha a log szövegének része egy másik dátum valami oknál fogva?

Két perces hevenyészett példák voltak. Írni kell olyan regex-et a "21:40" helyett, ami neked jó, pl.: "\[2019-10-06 16:..:..\]", vagy mittudomén.

> Azt mondom, hogy struktúrált adatokkal mindennek ott a helye, és adattípushoz passzoló eszközöket kapsz (nos, illene kapnod). Ezzel szemben egy szöveges log azt és olyan formában tartalmazza, amit az adott app épp kiköp magából. Ahány app annyiféle dátumformátum, van ami local időt, van ami UTC-t használ, abban szűrj kényelmesen greppel. Ismétlem, jó cucc. Csak nem erre való. Tudod, a kalapács esete.

Nem csak a grep van. Amúgy vicces a kalapácsos hasonlat felemlegetése, hiszen épp a systemd az, amit mindenre is használni akarnak, nem?

> Lehet, persze. Eltárolhatod jsonben, xml-ben, akár csv-ben is, csak épp innentől kell valami formátum specifikus parser, mert különben ugyanúgy meg vagy lőve az idézőjelek, escape-elések, és a szövegben előforduló, de nem adatnak számító elemekkel.

Mert ugye a felsorolt formátumokra nincsen még készen full parser és egyéb ötmillió tool.

> Ez a kijelentés még lehet igaz, de ez általánosítás, itt épp most kifejezetten a struktúrált logolás előnyeiről próbálok csak értekeni.

Ahhoz meg nem kell systemd.

Megpróbálom máshogy megfogalmazni. A systemd megoldása nem biztos hogy jobb másnál, de a random struktúrájú plaintext logoknál szerintem igen. Van pár előnye a plaintextnek, pl a hordozhatóság, és hogy tool nélkül olvasható, de ez ki is merül.

Ahogy írtam megoldható bash toolokkal és szöveg parse-olással a keresgélés, dátumra szűrés, de nem intuitív, nem hibatűrő, nem kényelmes, és legfőképp nem hatékony. A felsorolt formátumokra természetesen van parser és ötmillió tool, és emiatt ugyanilyen jó lett volna akármelyik logok tárolására. Csak legyen egy rendszeren belül egységes.

És ehhez igazad van, nem kell systemd. De ők legalább adtak rá megoldást. És ebben a szálban nem a systemd egészéről, hanem a logolásáról beszélünk.

Lehet forkolni kellene a systemd-t, és megoldani amit valaki írt itt fentebb, hogy célfeladatokra különálló, illeszthető egységekre legyen bontva. És akkor bármelyik része felhasználható volna a többi nélkül, illeszthető lenne más rendszerhez, stb.

És rögtön az első probléma az volna, hogy ezek a különálló egységek hogy kommunikájanak egymással, miért pont úgy, és miért pont ahhoz alkalmazkodjon mindenki akkor? :)

Jó megoldás nincs. Vagy össze nem illő darabokból ollózol össze egy rendszert, vagy legalább az illesztőfelületet lenyomod mások torkán. A systemd persze ennél tovább megy, de ha csak egy egyésges illesztőfelületet, meg független komponenseket adott volna, vajon jobb lenne a megítélése?

> Van pár előnye a plaintextnek, pl a hordozhatóság, és hogy tool nélkül olvasható, de ez ki is merül.

És a hibatűrés az smafu? A systemd bináris logjai nagyon szeretnek korruptálódni.

> és szöveg parse-olással a keresgélés, dátumra szűrés, de nem intuitív, nem hibatűrő, nem kényelmes, és legfőképp nem hatékony

Nem hibatűrő? A plaintext? Az hogy jött ki? Éppen a bináris log az, ami nem hibatűrő. A többire meg csak azt tudom mondani, amit eddig: nem merül ki az eszközkészletünk a shell-ben, lehet rá céleszközt írni. Akkor intuitív is lehet, meg kényelmes is, meg hatékony is. Ehhez nem kell systemd.

> Lehet forkolni kellene a systemd-t, és megoldani amit valaki írt itt fentebb, hogy célfeladatokra különálló, illeszthető egységekre legyen bontva. És akkor bármelyik része felhasználható volna a többi nélkül, illeszthető lenne más rendszerhez, stb.

Ha a kezdetektől kezdve így csinálják, akkor talán lehet lett volna értelme csinálni; a lényeg, hogy ne legyen kötelezően ráerőszakolva a rendszerre és a használójára, el lehessen dönteni, hogy mi kell belőle, vagy sem. Most már késő, mert ez már így van összedrótozva. Van egyébként valami systemd fork (uselessd néven), de a kutya nem használja.

> És rögtön az első probléma az volna, hogy ezek a különálló egységek hogy kommunikájanak egymással, miért pont úgy, és miért pont ahhoz alkalmazkodjon mindenki akkor? :)

Minek kommunikálna egymással két olyan egység, aminek nem is kell egymással kommunikálnia?

> Jó megoldás nincs.

#define jó
Megfelelő? Hogy ne lenne. Tökéletes? Az tényleg nincs. De a systemd-nél jobb megoldásokkal működtek ezek a rendszerek évtizedekig.

> Vagy össze nem illő darabokból ollózol össze egy rendszert, vagy legalább az illesztőfelületet lenyomod mások torkán.

Ez így totál értelmezhetetlen. Mi az, hogy össze nem illő? A rendszerben egy raklap össze nem illő dolog van, de ezeknek nincs közük egymáshoz; minek oda bármiféle illesztőfelület, amit lenyomnak a torkunkon? (És pont ez a torkon lenyomás az, ami miatt utálják az emberek.)

> A systemd persze ennél tovább megy, de ha csak egy egyésges illesztőfelületet, meg független komponenseket adott volna, vajon jobb lenne a megítélése?

Mindenképpen, mert opcionális lenne. A systemd-t elsősorban nem azért kap ennyi utálatot, mert rossz koncepciójú és rossz minőségű, hanem azért, mert ennek ellenére lenyomták az emberek torkán. Ha csak simán rossz lett volna, de két nap után elfelejtik, akkor max. röhögtek volna egyet az emberek. De ez így már nem vicces. Viszont ez az illesztőfelület még mindig nem tiszta; minek akarsz egymáshoz semmi közzel nem bíró komponenseket illeszteni? Egy hangkártyadrivert minek illeszteni a printerdaemonhoz? Hogy zenélhessünk a printeren, vagy, hogy felolvastathassuk a kinyomtatandó dokumentumot a hangkártyával? :P Csak mert a systemd-ben rengeteg ilyen hasonlóan abszurd "árukapcsolás" van, hasonlóan abszurd indoklásokkal.

> És a hibatűrés az smafu? A systemd bináris logjai nagyon szeretnek korruptálódni.

Nem csak ez a két véglet létezik.

> Nem hibatűrő? A plaintext? Az hogy jött ki?

Nem ezt írtam, a parse-olásról beszéltem. Nagyon könnyű elrontani főleg ha valami komplexet akarsz.

> Ehhez nem kell systemd.

Oké, a többire nem is válaszolok innentől. Mert sokadjára írom le, hogy nem a systemd-ről beszélek, és hogy amit írok az nem lesz invalid csak mert a systemd implementációja épp szar. Nem akarod megérteni amit mondok, csak a systemd-t fikázod vérszemet kapva, innentől feleslegesen tépem a szám :)

> Nem ezt írtam, a parse-olásról beszéltem. Nagyon könnyű elrontani főleg ha valami komplexet akarsz.

És ugyanezt a systemd-ben nem lehet elrontani? Ki kell tesztelni, akkor jól fog működni.

> Mert sokadjára írom le, hogy nem a systemd-ről beszélek, és hogy amit írok az nem lesz invalid csak mert a systemd implementációja épp szar.

Én sem csak a systemd-ről beszélek: te össze nem illő komponensek illesztéséről beszéltél és semmi alja nem volt az egésznek; erre szerettem volna választ kapni, hogy ezt mégis hogy érted. Ennek semmi köze nincs a systemd-hez.

> Nem akarod megérteni amit mondok, csak a systemd-t fikázod vérszemet kapva, innentől feleslegesen tépem a szám :)

Ez pedig megint nettó személyeskedés és hazugság.

Oké :)

Csak hogy értsd: most se ment át az üzenet. És lehet nem jól magyarázok, de nem hiszem, hogy ez a baj. Ha neked kényelmesebb szöveget parse-olni, mint struktúrált adatokban keresni, ám legyen. Szerintem nem az. Szerintem sokak szerint nem az. Ezért léteznek adatbázisok txt fájlok helyett szinte mindenre. A log is ilyen kell hogy legyen :) Erről van szó. Sem a systemd-ről, sem annak a jó vagy rossz implementációjáról. Ez nem jön át, és úgy érzem nem akarod megpróbálni megérteni sem. Nevezd ezt személyeskedésnek, szerintem nem az. Na ennyi.

Nem, ez így nem személyeskedés, de te az előbb nem ezt mondtad, olvasd vissza.
A probléma ezzel csak annyi, hogy struktúrált adatot abban tárolsz, amit akarsz és úgy dolgozod fel, ahogy akarod. És itt jön képbe a systemd, hogy miért is azzal akarjuk ezt is megoldani?

Eleg szar lenne, ha nagyvallalati rendszerek eseteben lokalisan nezegetne az emer a logot es nem valamilyen (logelemzo) eszkozzel (splunk, elasticsearch, sentry, stb.). Ha meg megint arra megyunk hogy gnome es desktop/laptop ott nem latom, hogy a linux desktop eve utan marineni journalctl-ezne. Raadasul a journalctl egy jo nagy fos. Egy grep is jobban mukodik nala.

Tok jo a binaris log. Lojj bele valahová egy-par random byteot, aztán lássuk mi lesz. Ugyanezt csináld meg egy sime text alapú lóg állománnyal. A másik a --since. Ezt less-el és kereséssel is megcsinálom és ha akarok visszább lépek (pageup). Systemd-vel nem, hiszen onnan kezdi kiírni és kész, azaz mehet az újabb since. Tényleg tök jó. :)
A logfajl figyelők meg bekaphassak. ;)
Még jó hogy az lehet küldeni belőle mindent syslogba. Bár emlékszem ez mekkora kin volt pocsteringnek. Hogy az ő szép talalmanyanal pedig nincs jobb. Na hagyjuk is.

Miakur...?!

-pilisig-

Egy gondolat a nagy systemd fikázás végére:

Ha a systemd ennyire szar, és ennyire rossz, hogy tud ekkora teret hódítani, és miért nincs értelmes alternatíva, ami nem veri ki ennyire a biztosítékot mindenkinél?

"hogy tud ekkora teret hódítani"

Eleg agresszivan nyomjak, idonkent elegge arcbamaszo stilusban (mondjuk poettering onmaga is egy hatalmas PR katasztrofa azzal, ahogyan viselkedik/kommunikal).
Amugy rengeteg ertelmes alternativa van, nem egy rc/init rendszer letezik.

> Eleg agresszivan nyomjak, idonkent elegge arcbamaszo stilusban

Na pont ez az, hogy kik, és mi a motiváció. Egyáltalán milyen motiváció lehet, és ha valami ilyen objektívan szar, akkor ki az, akinek van elég nagy "hatalma" hatni a döntéshozókra, és meg is éri neki?

> Amugy rengeteg ertelmes alternativa van

És a döntéshozók miért nem ezek mögé állnak be?

"És a döntéshozók miért nem ezek mögé állnak be?"
Mert az nem tenné könnyebbé a döntéshozó munkájukat...!, azaz a döntéshozók, (finanszírozók,) megválasztják a megfelelő pozicióra a megfelelő emberüket. Akinek ezek után, - persze erre tekintettel, - biztosan nagy arca is nő.

A systemd rég-rég nem csak egy init rendszer, hanem mindenféle rendszerközeli komponens összeborítva. Például init rendszer, hálózati időszinkron, login manager, log kezelő, parancs ütemező, stb stb. Ezek mind léteztek évtizedek óta, kisebb, egyetlen spéci feladatra készített eszközökkel, amik önálló életet éltek. És a systemd meg azért született, hogy ezeket az egymással lazán kapcsolt komponenseket központilag intézze valami (asszem a systemd -nek is vannak moduljai, tehát nem egy monolit az egész). De hogy ennek pontosan mi a pozitív hozadéka, arról azokat a fejlesztőket kellene megkérdezni, akik ilyesmikkel foglalkoznak (pl. GNOME? :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

+1

a pozitiv hozadeka egy distro-nak meg az, hogy egyetlen valamit kell karbantartani csak es nem a 4-5 dolgot. Mondjuk ki, hogy a systemd a lustasagra epitette a diadalmenetet meg a penzre. Ertem en a cegeket akik az egyes distribek mogott allnak, hogy sokkal ekvesebb penzukbe kerul igy a dolog, de ettol meg nem jo.
Te is es en is irtam, hogy semmi olyat nem csinalt ami eddig ne lett volna, csak egyszeruen begyurt mindent maga ala.

Azt tegyuk hozza hogy pocstering egy osx buzi es az ott levo dolgokat akarja mindenaron megvalositani. A systemd is onnan notte ki magat. A pulse dolgait is siman meg lehet csinalni alsa-val csak tobb munka.
A masik, hogy a faszit tokre nem erdekli a laptopon kivul semmi. Desktop orientalt Ami tok jo lenne, ha mar eljott volna a linux dekstop eve. De igy tok okafogyott a systemd. :D

Az a pulseaudio nem olyan ördögtől való dolog ám. Oké, egy plusz komponens, mit keres ez itt... de, onnantól fogva hogy a low levelről egy kicsit absztraktabb szintre emelte a hangkezelést, egy csomó plusz dolgot könnyen hozzá lehetett fejleszteni, pl. egyetlen mozdulattal rá tudod irányítani a hangkimenetet egy airplay receiverre (ez csak egy példa volt). A példánál maradva, jópár éve ez egy unofficial modul/patch volt, amit végül beolvasztottak a pulse -ba és már gyárilag ott figyel.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Nem csak a plusz felesleges réteg a probléma, hanem a rengeteg bug is. Messze több problémát okoz, mint amit megold.

Nem vagyok egy nagy audios, de tudsz linkelni egy studio hangszervert, ami pulseaudioval megy?

En tudok linkelni parat ami jackszerverrel megy.

Miert nem valami jack szerver kompatibilis dolog jott ki? Miert kell kulon uton jarni annak aki komolyabb audiora akarja hasznalni a gepet, es nincs benne abba a par common usecase-ben?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A miért nem kérdésre szerintem Jack-ék meg is adják a választ az összehasonlításban:

https://jackaudio.org/faq/pulseaudio_and_jack.html

Egyrészt a két rendszer más problémát akar megoldani máshogy. A PA is tud olyat, amit a Jack nem, és fordítva. A PA felépítéséből adódóan nem igazán tudja a zero latency-t, de arra amire tervezték nem is feltétlenül kell.

Viszont a kettő tud barátságosan együttműködni ahogy a cikk be is mutatja. Megteheted, hogy egymásba pipe-olod őket, sőt, érdekességképp írják, hogy a felhasználók egy része érthető okokból több hangkártyával nyomul, így simán opció egyiket low latency audióra, másikat átlag hétköznapi desktop dolgokra használni.

Szóval nem gondolnám azt, hogy nagyon külön utat kellene járni. Külön megoldás van a két feladatra, ez tény. De megfér egymás mellett, és ki tudod használni mindkettő előnyeit.

>Te is es en is irtam, hogy semmi olyat nem csinalt ami eddig ne lett volna, csak egyszeruen begyurt mindent maga ala.
Ennyi erőből bármit meg lehetett csinálni akár a sysvinit előtt is, mivel már léteztek turing-teljes gépek.

Biztosan bele lehet kötni a systemddel kapcsolatban sok mindenbe, de azért az legyen már VALÓS előny, hogy jóval használhatóbb, kényelmesebb, kevesebb fingreszelést igényel mind user, mind disztró maintainer szempontból, mint az elődjei.

Ha az ember gyűlöli pötyöringet, meg a systemd-t akkor persze nyilván ördögtől való az egész, de ha nem, akkor azért annak is vannak előnyei, hogy terjed és egyfajta init "szabvánnyá" válik a Linuxos világban, kevésbé ronccsá töredezett a platform legalább az alap építőköveit tekintve.

Én végfelhasználóként azt látom, hogy ha 10 éve hajítottam fel egy ubuntut gnómmal, akkor az alap működésen felül nagyon sűrűn szüttyögni kellett, most meg még archon is megy minden alap installnál, mint az ágybaszarás. BT audió, wifi, billzet világítás, fényerő, power management, touchpad, stb. Boot megvan másodpercek alatt.

Konkrétan már flottabbul működik a laposomon a rendszer, mint a Win, lassan minden szempontból. Ebben szvsz azért vastagon benne van a pulseaudio, a dbus vagy a systemd is. Ezek a dolgok miatt valahogy nem tudok haragudni a fejlesztőikre, hiába nézem néha értetlenül én is a systemd-be csomagolt funkciókat, vagy éppen a kommunikációjukat.

"most meg még archon is megy minden alap installnál, mint az ágybaszarás. BT audió, wifi, billzet világítás, fényerő, power management, touchpad, stb. Boot megvan másodpercek alatt. "

Ez a fingreszelős dolog tetszett :) És igen, én is így látom, out of the boxosabb lett nagyon-nagyon sokminden a Linuxos desktopon.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

> Ha az ember gyűlöli pötyöringet, meg a systemd-t akkor persze nyilván ördögtől való az egész

Bocs, de nem cserélted véletlen fel a sorrendet? Ez így ment, hogy az emberek csak úgy gyűlölték Poetteringet és ezért abcug systemd és pulseaudio? Nem lehet, hogy fordítva történt, hogy a pulse és a systemd gagyi volt és felesleges és mégis "szabvánnyá" vált és ezért rühellték meg az emberek Poetteringet?

> egyfajta init "szabvánnyá" válik

Egyébként ez meg még idézőjelben sem szabvány, hiszen nincs is szabványosítva. Ez inkább egy nagy vendor-lock.

A többire meg azt mondom, hogy remélem nem mondod komolyan, hogy a jobb hardware támogatás oka az "init rendszer" és egy olyan "hang alrendszer" ami nem tud az alatta lévő valódi hangrendszer (ALSA/OSS) nélkül meglenni? Ennek semmi köze nincs Poettering cuccaihoz. Fejlődik a Linux hardware támogatása, ahogy egyre több helyen használják és egyre több driver készül hozzá. Tök mindegy az init rendszer, vagy a hangrendszer. Én csináltam a cégnek olyan Devuan alapú live pendrive-rendszert, ami szinte mindenütt felkelt és minden működött; és semmiféle Poettering cucc nem volt benne.

>Bocs, de nem cserélted véletlen fel a sorrendet? Ez így ment, hogy az emberek csak úgy gyűlölték Poetteringet és ezért abcug systemd és pulseaudio?
A pulseaudio fejlesztése során utálták meg tudtommal, a systemd fejlesztésénél már eleve leginkább a személye miatt fikázták az egészet.

>Nem lehet, hogy fordítva történt, hogy a pulse és a systemd gagyi volt és felesleges
Pulseaudiónál kezdetben voltak gondok, de jó ideje nem hallani sok rosszat róla.
Systemd-vel nem tudom indulásnál volt-e ilyen, nekem sosem volt bajom. Pedig nem is csak alap dolgokra használom, laposon pl. systemd-boot van, titkosított root partícióval, ahol USB billzettel is be tudom pötyögni a jelszót.
Persze bugok mindenben vannak, biztosan nem mentes ez sem.

>Egyébként ez meg még idézőjelben sem szabvány, hiszen nincs is szabványosítva.
Kvázi szabvány. De facto szabvány. Nevezd ahogy akarod.

>Ez inkább egy nagy vendor-lock.
Egy ingyenes, opensource szoftver? Amit bárki forkolhat? Aminek alternatívái is vannak? :D
Ezek alapján a linux kernel is vendor lock.

>Fejlődik a Linux hardware támogatása, ahogy egyre több helyen használják és egyre több driver készül hozzá.
Ez így van. Nem is azt írtam, hogy a fentebbi rendszerek tehetnek mindenről, de szerepük az bizony van.

>Én csináltam a cégnek olyan Devuan alapú live pendrive-rendszert, ami szinte mindenütt felkelt és minden működött; és semmiféle Poettering cucc nem volt benne.
És ment mondjuk laptopon OOB a BT? Bemész a rendszer menübe, rányomsz h BT bekapcs, scanneli a deviceokat, feldobja a BT hangrendszered, párosítod és megy is rá ki a hang?

Az, hogy bebutul valami debilány alapú cucc penről és ha rányomsz a piros rókára, akkor bejön a zindex, azért 10 éve is ment már.

> A pulseaudio fejlesztése során utálták meg tudtommal, a systemd fejlesztésénél már eleve leginkább a személye miatt fikázták az egészet.

Nem egészen. A pulse miatt is utálták ez tény, de a systemd-nél is ugyanazok a problémák jöttek elő a személyével kapcsolatban, hogy van valami bug vagy ostobaság a systemd-ben és NOTABUG, meg WONTFIX.

> Pulseaudiónál kezdetben voltak gondok, de jó ideje nem hallani sok rosszat róla.

Most is vannak vele bajok, csak a durvább bugokat már felszámolták. Meg Poetteringet is, mert kiebrudalták.

> Systemd-vel nem tudom indulásnál volt-e ilyen, nekem sosem volt bajom. Pedig nem is csak alap dolgokra használom, laposon pl. systemd-boot van, titkosított root partícióval, ahol USB billzettel is be tudom pötyögni a jelszót.

Ehhez nem kell systemd.

> Egy ingyenes, opensource szoftver? Amit bárki forkolhat? Aminek alternatívái is vannak? :D

Az megvan, hogy a GNOME3 most tette kötelezővé a systemd-t, ami Linux-only és ezzel kizárta a használatból a többi UNIX-ot? Ez mi, hanem vendor-lock?

> És ment mondjuk laptopon OOB a BT? Bemész a rendszer menübe, rányomsz h BT bekapcs, scanneli a deviceokat, feldobja a BT hangrendszered, párosítod és megy is rá ki a hang?

Mivel BT-t nem volt még a közelünkben sem, így nem tudom, hogy az ment volna, de ennek mi köze a systemd-hez? Szerinted nélküle ez nem megy? Dehogynem, maximum az van, hogy azok a BT-t kezelő programok, amik jól működtek, azok systemd függőek lettek. És akkor lehet mondani, hogy systemd nélkül nincs BT, mert nélküle nincs az a program, ami normálisan kezelné. Ez is vendor-lock. Network managerek közül is több igényli már, igaz, hogy korábban nélküle is tökéletesen mentek és ha felteszed a régebbi verziót, akkor ugyanúgy tudod kezelni a netet. Vagy épp a BT-t. Ez az egész arról szól, hogy a systemd megkerülhetetlen legyen, pedig nincs rá szükség. Vagy olyan problémákat old meg, amik nélküle nem léteznek, vagy a probléma ugyan létező, de a megoldás rosszabb, mint a probléma.

> Az, hogy bebutul valami debilány alapú cucc penről és ha rányomsz a piros rókára, akkor bejön a zindex, azért 10 éve is ment már.

Kicsit komolyabb dolgokat is kellett ott csinálni, mint piros róka, meg zindex, vagy épp BT, de nem baj. Remélem nem azt akartad mondani, hogy ami systemd nélkül nem működik, az komoly dolog nem lehet, csak piros róka, meg zindex...

+1

Én is írni akartam a kollégának, hogy olyan tulajdonságokat tulajdonít a systemd-nek, amikhez nem kell, sőt nem is ő csinálja, pl. BT.

Idézet:
Az megvan, hogy a GNOME3 most tette kötelezővé a systemd-t, ami Linux-only és ezzel kizárta a használatból a többi UNIX-ot? Ez mi, hanem vendor-lock?

Egyébként erre van bármi hivatalos forrás is vagy próbálkozott bárki a Gnome 3.34 lefordításával BSD-n?
Mert eddig csak annyit láttam, hogy volt egy bejelentés, hogy a systemd funkcionalitását kihasználja mostantól a GNOME, hogy ez kizárólagos lenne, azt sehol nem találtam (olyan szinten meg nem érdekel, hogy átnézzem a GNOME shell forráskódját)

Pl. a GNOME évek óta (Fedora 19, azt hiszem) támogatja a multi-seat beállítást; a systemd-n keresztül. Gondolom a mai napig össze lehetne hozni ipari mennyiségű X11.conf írással, ahogy az előtte ment, viszont ha már ott van a seat támogatás a systemd-ben, Gnome-ék kihasználják... (és igen, ehhez pl. kellett a systemd-nek [spec. logind, de kit érdekel], hogy az udev kommunikáljon felé plusz infót).
A NetworkManagerek meg szintén kényelmesen elfutnak systemd nélkül is, a systemd-hez annyi közük van, hogy kell, hogy adjanak egy wait-online service-t, ami simán vár, amíg ténylegesen elérhető a hálózat (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/) - a NetworkManager-wait-online speciel simán egy nm-online hívás fix timeout-tal.

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

> hogy ez kizárólagos lenne, azt sehol nem találtam

Az emberek mindig túlgondolják a sztorikat, hogy legyen utána min mérgelődni. Simán lehet, hogy tényleg kizárólagosságot jelent, az is lehet, hogy nem. Addig viszont kell valami a népnek, úgyhogy feltételezzük a rosszat :)

> Egyébként erre van bármi hivatalos forrás is vagy próbálkozott bárki a Gnome 3.34 lefordításával BSD-n?

Azt linkelte be a topicnyitó. Konkrétan a BSD-ket, vagy Solarist nem említette senki, de ha a teljes user session kezelés a systemd-n keresztül történik, akkor mégis hogy lehet systemd nélküli rendszereken használni? Kicsontozva belőle a sessionkezelést és egyfelhasználós desktopként használva?

> Mert eddig csak annyit láttam, hogy volt egy bejelentés, hogy a systemd funkcionalitását kihasználja mostantól a GNOME, hogy ez kizárólagos lenne, azt sehol nem találtam (olyan szinten meg nem érdekel, hogy átnézzem a GNOME shell forráskódját)

Ezt a kommentek között írja le a szerző, hogy a gnome-session már csak bizonyos feladatokért felel, az user sessionok kezeléséért már nem. Úgy kb. egyébként a BSD-ket, vagy a Solarist sehol nem említették a 3.34 kapcsán.
Azonban arról már fél évtizede, még a 3.14 előtt írtak, hogy kidobálják a gnome-session-t és a ConsoleKit-et, lesz helyette systemd/logind. Ott még volt szó (példaként) a FreeBSD-ről (a többi BSD-ről, vagy a Solarisokról nem), hogy "Then we could write a minimal stub implementation for e.g. FreeBSD as we’d know exactly what parts of the API we actually need. The stub would still be minimal; allow GNOME to run, but that’s it." Magyarán annyira még méltatták őket, hogy legalább az elindítást lehetővé teszik FreeBSD-n, "de ennyi". Viszont a lényeg itt is a kommentek között van, ugyanis két BSD user felteszi a kérdést, hogy hogyan tovább, miután teljesen átállították a sessionkezelést; mi lesz a BSD-kkel? Válaszként két széttárt kezet kaptak, hogy "súlyos hiányuk van BSD fejlesztőkből és lehet, hogy API-eltérés miatt a GNOME3 nem fog menni más (non-Linux UNIX) rendszereken, de attól még elérhető marad", azaz nem igazán foglalkoznak vele, hogy Linuxon kívül működik-e máson is, vagy sem, de legalább hajlandóak patcheket befogadni, ha nem. TL;DR: It's Open Source, solve your own problems... (...és aki nem fejlesztő?)
További érdekesség viszont ebben a cikkben, hogy a KDE is át akar állni a logind-re. ("From what I understood, KDE will also make use of user sessions, logind, etc.") Tehát a fenti spekulációmmal nem is lőttem nagyon mellé; bár szerencsére eddig még nem lett belőle semmi. (AFAIK. Lehet, hogy azóta is vitatkoznak.)

> A NetworkManagerek meg szintén kényelmesen elfutnak systemd nélkül is

Nem azt mondtam, hogy mindnek kell, ez nyilván valótlan lenne; azt mondtam, hogy több is igényli. Pl. a Debian-ban lévő default manager egyáltalán nem fut nélküle. Azt mondjuk nem tudom, hogy forrásból le lehet-e úgy forgatni, hogy menjen nélküle, de mindenesetre a maintainerek úgy csomagolják, hogy függőség. Mind a két esetben beleerőszakolták a systemd-t a képletbe, csak az egyik esetben a developerek, a másik esetben a packagerek. A végeredmény szempontjából kb. mindegy.

Nem BSD hanem Linux.
Gentoo, csak azért tudod "systemd nélkül" használni mert kiszerveztek a systemd-ből a logind-t (elogind).

"Egyébként erre van bármi hivatalos forrás is vagy próbálkozott bárki a Gnome 3.34 lefordításával BSD-n?"

Ugyan nem használok semilyen BSD-t, hanem gentoot, de ha a kérdés a systemd hiányára irányul, akkor biztosra veszem, hogy nem. Kurvára nem lehet úgy lefordítani gnome-ot, hogy systemd nélkül működjön. Van wikije a gentoonak a systemd mentes gnome lehetőségre, de ott meg van hekkelve a gnome meg egy tucat függősége.

>Ehhez nem kell systemd.
Utaltam erre valahol?

>Az megvan, hogy a GNOME3 most tette kötelezővé a systemd-t, ami Linux-only és ezzel kizárta a használatból a többi UNIX-ot? Ez mi, hanem vendor-lock?
Miután szabadon forkolható, átírható, így értelmezhetetlen a vendor lock ebben az esetben. Vagy nem pont erről szólna a nyílt forrás?
A Gnome fejlesztői hagy csinálhassanak már amit jónak látnak. Majd ha a közösségnek nem tetszik, akkor leforkolják, mint tették pl. a Gnome 3 kiadásakor.

Pont onnan látszik, hogy ez az egész kérdéskör csak egy marha nagy vihar a biliben, hogy nem tette meg senki. Annyi kraft volt ebben a megmozdulásban, hogy pár alufóliasapkás átmenekült BSD-re, páran meg forkolták a debiant, de itt kb. el is fogyott a momentum. A közösséget marhára nem érdekli a dolog.

>Szerinted nélküle ez nem megy? Dehogynem, maximum az van, hogy azok a BT-t kezelő programok, amik jól működtek, azok systemd függőek lettek.
Írtam én, hogy a fentebbi dolgok nélkül nem volt megoldható? Nem. De valahogy mégis "sorjamentesebb" lett az egész folyamat (enyhén szólva).

>Remélem nem azt akartad mondani, hogy ami systemd nélkül nem működik, az komoly dolog nem lehet, csak piros róka, meg zindex...
Miért, ezt írtam? Szerintem nem.

Én ugyan nem utálom Potteringet. De egy pocsfej. Tényleg. Találkoztam vele. Olyan magas lóról beszélt velem és olyan stílusban, amit még apukám se engedné meg magának, de csak neki néznék el.
Ahhoz még nem kell gyűlölni a systemd-t hogy lássa az ember hogy szar. Jössz itt az init rendszerrel, de a systemd egy elenyésző része csak az init mára már.
Jóval használhatóbb??? Ez így fing a szélben. Példa?

A BT, wifi (network stack), bill világítás független a systemd-től. Mielőtt a kernelt is a systemd-nek tulajdonitanád, kicsit nézz utána a dolgoknak.

Amúgy a boot lassan lassabb a systemd-vel. :)
A leállításánál magukban pörgő System servicek, meg csodásak. Most már akár két perc is lehet a leállítás. :)

A pulse-rol is tudnék mesélni, hogy hányszor kell killall-olni, hogy a BT füles működjön miután profile-t vált az ember. Mondjuk ez sem systemd akár hiszed akár nem. De pocstering agyréme. Mondjuk miután kidobták a picsaba legalább használhatóbbá tették.

Az megvan, hogy azert talaltak ki a a systemd-t, hogy *gyorsabb* legyen a boot? :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Inkább arra, hogy figyelhetők legyenek a szervizek. Az hogy párhuzamosan indithatoak plusz. Persze kérdés, hogy ez a szervereken minek, mikor a hardware elemek boootja is van vagy tíz perc. Laptopon meg legtöbben sleepelnek aztán kész. Kéthavonta meg belefér egy fél perccel hosszabb boot sysv-vel is. De a systemd joooooo. :)
Mint írtam. Válasz egy sosem létezett problémára.

+/- masodpercek, ide vagy oda, szamit? Akkor se ha naponta bootolunk <- ami mondjuk szegyen lenne, evente 2+ boot mar lamer stilus.
____________________
echo crash > /dev/kmem

Hát aki rolling rilizel annak 1-2 hetente jön a reboot, mert frissül a kernel állandó jelleggel :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

"Hát aki rolling rilizel annak 1-2 hetente jön a reboot, mert frissül a kernel állandó jelleggel :)"

Nekem csak 1 - 1,5 havonta jön kernel frissítés. Pontosabban forrás frissítés, az meg rajtam múlik felrakom-e és mikor.

Én is visszatarthatnám akár, de a kernelhez igazított cuccok (pl. driver, virtualbox module) akkor szintén visszatartódnak, szóval inkább mindig felrakom és amikor eszembe jut tolok egy gyors rebootot. Egyébként is van egy Windowsom az Arch mellett, játékra :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Archnál meg fedoránál más a helyzet. Mivel hardened profilt használok csak LTS kernel jön. Tehát 4.19.xx -> 4.19.x+n -> 4.19.x+n+n stb. De mintha archnál is lenne lts kernel opcionálisan.

Ha nem teszem fel max plusz biztonsági kockázatnak teszem ki a rendszert. Egyébként valóban. Ha megjelenik egy újabb lts kernel, akkor a többi cucc miatt célszerű meglépnem.

> És a systemd meg azért született, hogy ezeket az egymással lazán kapcsolt komponenseket központilag intézze valami

Ez a mantra. Csakhogy:

a) A bugok miatt alkalmatlan arra amire állítólag való.
b) Olyan dolgokat is összekapcsol, amiket nem kéne. Pl. init rendszer, hálózati időszinkron, login manager, log kezelő, parancs ütemező, stb stb.
c) A systemd célja valójában az, hogy megkerülhetetlenné tegye az egész Linuxos szoftvervilágban a fejlesztőit.

> De hogy ennek pontosan mi a pozitív hozadéka

Kinek?

> b) Olyan dolgokat is összekapcsol, amiket nem kéne. Pl. init rendszer, hálózati időszinkron, login manager, log kezelő, parancs ütemező, stb stb.
A "do one thing and do it well" aka unix filozofia feladasra kerult.

> c) A systemd célja valójában az, hogy megkerülhetetlenné tegye az egész Linuxos szoftvervilágban a fejlesztőit.
Szomoruan mondom hogy az Oracle modellt latom kibontakozni. Lassan csak a penzrol szol. Amivel nem a penz a baj, hanem a csak.
____________________
echo crash > /dev/kmem

+1

Én nem értem mi köze az init rendszernek az asztali környezethez/ablakkezelőhöz/akármihez?

Én ezt úgy értelmezem, hogy a Gnome most már nem pusztán "asztali környezet" akar lenni, hanem komplett vezérlőpult, "parancsnoki híd", ahonnan mindent elérsz egyszerűen, akár mélységeiben is.

E mögé kell gondolom az, hogy a systemd-ből hívogasson vagy állítson le ezt-azt kattintásra.

Pedig csak az első bekezdésig kell eljutni:

Idézet:
If you are already using GNOME 3.34, then most likely your session is managed using systemd right now. For a long time now we were already running a systemd instance for every user, which is used to launch DBus and for DBus activated applications. So, with GNOME 3.34, we finally took the next step and moved the rest of the session over to run using systemd.

Ha jól értem ez annyit tesz, hogy a gnome session kezelésnek egy nagyobb részét (az egészet?) bízzák rá a systemd-re mint eddig.

Itt le is írják, hogy miért jó:

Idézet:
The great thing is, that this enables further improvements. There has been a lot of work to allow Xwayland to be started on demand and systemd plays a small part in that feature. Similar, we will also be able to shut down services that are only needed if specific hardware is present (e.g. smartcards). Also, using systemd it is now easy to sandbox all components which will give you an extra bit of security.

Köszönöm, sok minden világosabb lett. Azt kell hinnem, hogy igen öreg vagyok és begyöpösödött is. Sok év linux használat után (talán még Debian 4 volt) mindig újra és újra kell tanulnom sok mident és főleg a meglevő szemléletet kell felülírnom. Nekem a moduláris felépítés valahogy jobb volt. Most meg egy rakás dependencit ránt magával a gép induláskor. De mondom, ez az én beszűkültségem, és tetszik nem tetszik meg kell tanulnom az új idők új trendjeit, ha linuxot akarok használni.
Tehát meg tanulni hogyan is működik a systemd.

"Tehát meg tanulni hogyan is működik a systemd."

Ezt mindenképp, mert a munka során bármikor szükség lehet rá, de esetleg válts distrót. Én debiant cseréltem gentoora, mert megelégeltem, hogy folyamatosan telepakolták olyan dolgokkal, ami nem felet meg az elképzeléseimnek. Azóta nincsenek problémáim.

Igen, de akkor új rendszert is kell tanulnom... :) Debian/Debian like rendszereken már elég jól tudom, hová nyúljak, mit keressek, milyen konfig fájlok hol vannak, stb.

"Igen, de akkor új rendszert is kell tanulnom"

Nagyon rossz hozzáállás.

Ha megtanulod Gentoo-t, megtanulod a linuxot. ;)

Két év gentoozás alatt többet tanultam, mint a majdnem 15 évnyi debianozás alatt. Közben persze kipróbáltam az összes nagyot. (Arch, Fedora, SuSE, Mandriva/Mageia, PCLinuxOS, Slackware/Vector)
Mellesleg a megszerzett tudást más disztribúciókon is kamatoztathatod.

"Debian/Debian like rendszereken már elég jól tudom, hová nyúljak, mit keressek, milyen konfig fájlok hol vannak, stb."

Szerintem bűn leragadni egy fő disztró vonalon. Rohadt kényelmetlen tud lenni, ha leültetnek mondjuk egy Red Hat féle rendszer elé. Sőt debilány után egyenesen szörnyű.

lehet, hogy ezzel jön majd el a linux desktop éve :)