Systemd áldozatok a Debiannál

 ( trey | 2014. november 17., hétfő - 10:41 )

A systemd régóta korbácsol nagy indulathullámokat a Debian közösségen belül. A sztori addig jutott, hogy már áldozatokat is szed. Nemrég a Debian veterán Joey Hess jelentette be, hogy 18 évnyi közreműködés után távozik a projektből. Távozásával számos Debian csomag - debhelper, alien, dpkg-repack, debmirror - elárvult.

Nem Hess az egyetlen, aki a systemd miatt úgy döntött, hogy befejezi tevékenységét. Tollef Fog Heen tegnap jelentette be, hogy távozik a systemd karbantartását végző csapatból. Távozását azzal indokolta, hogy nem bírta tovább a folyamatosan érkező támadásokból fakadó nyomást.

Hogy lesznek-e még a régóta folyó systemd vitáknak további áldozatai, az a jövő kérdése...

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

Nehéz megítélni még, hogy ezek a változások hosszú távon jót vagy rosszat jelentenek-e a disztribúció jövöjével kapcsolatban.
Idövel minden kiderül.
Sajnos ha 10 distro-ból 9 a systemd-re alapoz, akkor nem célszerü attól a 10-nél sem hosszú távon eltérni.

A Debian jövöje nem kicsit befolyásolja a ráépülö egyéb distrok sorsát is, pl. Ubuntu.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Ubuntu-ék nem upstart-ot használnak? Meg szerintem az *buntu-ban a csomagkezelőn kívül már nem sok debian van.

Ubuntunál is át fognak térni systemd-re.

Ahogy egyre többet olvasok a systemd-ről, egyre kevésbé tetszik, azzal együtt, hogy az alapkoncepció nagyon szimpatikus. De sokkal jobb lenne, ha a systemd megmaradna a daemonok indítgatásánál és leállításánál, ahelyett, hogy szinte mindent át akarna venni, amely eddig más programok feladata volt (logolás, mostanában mintha nyomtatás is lenne...)

Igen, es en ezt rettentesen sajnalom. A systemd jo rendszer es egeszen jo koncepcio lenne, csak a konfig fajlok borzasztoak. Nem gondolom azt, hogy egy init rendszert a DOS erabol ideszakadt ini fajlokkal kellene konfiguralni. Jobban illik hozza egy DSL, mint pl. az upstart eseteben, sokkal komplexebb problemak megoldhatok vele.

Azt vizionalom, hogy majd jonnek a kulonbozo workaroundok meg hackek amikor kiderul, hogy mit nem tud a systemd.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A deklarativ service fileok az egyik legnagyobb josag systemdben. Ha annyira komplex a feladat, hogy az nem eleg, akkor:

1) Konnyen lehet, hogy lebonthato N kevesbe komplex es leirhato reszre, ami eleve egy jo eredmeny.
2) Ha megsem, sysvinit script meg mindig mukodik.
3) Illetve lehet kombinalni a kettot, es shell wrappert hivni unit filebol. (fuj)

Raadasul ez egyszeruen parsolhato, es feldolgozhato, mig egy DSL sok esetben kevesbe adja meg magat 3rd party eszkozoknek.

--
|8]

Oke, mutass egy olyan eletszeru use-caset, amikor hasznos a systemd unitjait felparsolni. Eddig is jol elvoltunk enelkul, eztan is elleszunk, ha kell valami info, azt altalaban magatol a szerviztol egyszerubb kinyerni, hiszen az mar felparsolta az akarmilyen formatumu konfigjait.

1) de en nem feltetlen akarom lebontani, raadasul egy sima feltetelvizsgalatot nem is igen tudsz lebontani
2) kerdes, hogy meddig. Felek, hogy N verzio utan egyszeruen kidobjak, tegyel amit akarsz. Abbol a fejlesztesi modellbol, amit most tolnak, ez siman realis veszely
3) ennyire mocskos perverz allat nem vagyok

En az upstartot azert szerettem, mert volt egy pre-start script szekcioja, ahol ossze tudtam rakni a cucc kornyezetet, elo tudtam kesziteni a futtatasat, majd a start szekcioban elindult az app. Most ehhez mindenfele scriptfajlokkal kell megszorni a rendszert, tokeletesen feleslegesen, mert az ini-fetis miatt ezeket nem lehet ott tarolni, ahova tartoznak: az unitokban benne.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Olyannal probalkoztak emberek, hogy systemd unitokbol sysvinit scriptet gyartani, ehhez jol jott a parsolhatosag, es DSL hazavagta volna rendesen. Mas kerdes, hogy szerintem tok ertelmetlen volt ez a probalkozas, es el is halt. :P

1) Ha feltetelvizsgalat, arra a systemd is eleg sok lehetoseget ad (Condition* cuccok). Ezekkel nagyon sok dolgot meg lehet csinalni.
2) Amig az olyanok mint Oracle es egyeb hasonszoru allatok sysvinit scripteket szallitanak a termekukhoz, addig systemd is tamogatni fogja azokat. Ez azert eleg hosszu ido.
3) Pedig az upstart pre-start szekcioja pont ez, csak mas kontosben.

Kornyezet eloallitasahoz pedig megcsinalod a scriptet ami azt osszeallitja, es dependalsz ra. Csokolom. Illetve ott van ExecStartPre=, amivel inditas elott custom parancsokat futtathatsz. Peldaul /bin/bash -t is megfeleloen felparameterezve. ExecStartPre-bol lehet tobb is egy service fileban. Igy ha nem tul sok a tennivalo, meg tudod oldani ugyanezt systemd-bol is.

--
|8]

" megcsinalod a scriptet ami azt osszeallitja, es dependalsz ra." na, peldaul az nem nyilvanvalo szamomra (mert a bash script fejlesztesi logikatol tok idegen), hogy ha en kiexportalok egy scriptbol egy kornyezeti valtozot, akkor az elerheto lesz egy olyan scriptben is, amit nem en hivok.

Raadasul ezzel meg mindig az a bajom, hogy elszeparalt fajlok, es nem az unit integrans reszei.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Lasd ExecStartPre=.

--
|8]

Az ubuntuban nagyon sok Debian van. Ezert (is) ternek at upstartrol systemdre. Ha keves Debian lenne benne, akkor nem torodnenek ezzel.

--
|8]

Ha jelenleg is más init rendszert használnak mint a szülő disztró, miért róna nagyobb terhet egy másik init rendszerre való áttérés. Persze egyszerűbb átvenni a debian alapértelmezett init rendszerét, mert azzal van a legkevesebb gond.
Azzal én sem értek egyet, hogy minden rendszer szolgáltatást tuszkoljanak bele, de maga az alapötlet tetszik, szerintem egyszerűbb, mint init script-et buherálni. Itt most egyszerű desktop felhasználásra gondolok, szerver környezetben, nyilván ez nem állja meg a helyét feltétlen, de ezek után senki ne sírjon a lerágott "mikor jön el a linux desktop éve" téma miatt.

"folyamatosan érkező támogatásokból fakadó nyomást."

Ennek csak szerintem nincs sok értelme? Nem támadás akart lenni?

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

Az a fránya automatikus szövegkiegészítés! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Szerintem sosem jó ötlet mereven ragaszkodni valamihez, ami ekkora indulatokat vált ki...
Annak idején a Gnome3 feleekkora vihart sem kavart, pedig az is igencsak megosztó irányt vett, és tessék, itt vagyunk ki tudja, hány release-zel később, a használhatóság még mindig igencsak megkérdőjelezhető, és a vége az lett, hogy számtalan alternatíva szökkent szárba, mert komoly igény mutatkozott rá. Szerencsére azzal kapcsolatban belátták a disztrók is, hogy kell az alternatívákat is támogatni, és meg kell adni a választás lehetőségét.
Itt látom a systemd legnagyobb baklövését (remélem), mert annyira intruzív, hogy a disztrók amik mellette döntenek, nem tudnak az alternatívákkal is teljes mellszélességgel foglalkozni. Remélem, a systemd ebbe a totális kontroll igyekezetbe előbb-utóbb bele is bukik...

Olvasva pár systemd-ellenes hisztit az LKML-en, slashdot-on, elég szánalmas, amit az ellen-systemd vitázók közül sokan csinálnak. Tulajdonképpen nagyon sok sérült ember ezen a vitán éli ki magát. Systemd-védő oldalról ilyet eddig nem találtam ezen a két helyen (ami nem jelenti, hogy nincs).
(És most eltekintettem a szakmai érvelésektől)

azert a systemd eleg pilotavizsgas...

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

Miért is? Mennyivel nehezebb egy unit-ot megírni egy szolgáltatáshoz, mint egy init scriptet, amikor az előbbihez nem feltétlen kell még shell programozási ismeret sem? Mennyivel nehezebb úgy indítani valamit, hogy start/stop - ja, ez ugyanaz, csak nem kell még a script helyét sem tudnom, elég a unit/target/szolgáltatás nevét. Mennyivel nehezebb engedélyezni boot során valamilyen szolgáltatást az systemctl enable paraméterrel, mint a különböző disztrók különböző rc scriptes megoldásaival? Vagy mi az amit eddig init scriptekkel egyszerűen oldottál meg, a systemd-vel meg bonyolult lett?

Nálunk a gépek nagy része hálózatról bootol és onnan is fut. Ha nem kell bele diszk, nincs benne, ha kell, távolról, vagy helyből (DAS) veszi.
Minden gép a környezetének megfelelően áll össze, ebben a sorrendben:
- base ("gyártói" alap)
- default (a mi alapbeállításaink)
- network (az aktuális hálózathoz tartozó beállítások)
- class (a gépcsoportokhoz tartozó dolgok, pld. adatbázis szerver, dns szerver stb)
- ip cím, csak annak a gépnek szóló beállítások

Több program konfigja is dinamikusan áll össze, pld attól függően, hogy melyik gépteremben, vagy rackben van, mi a hostneve (pld. páratlan hostnevű master, páros slave, vagy ugyanolyan nevű hostból a géptermi suffix alapján ugyanez, vagy valami más működési eltérés), programok attól függően indulnak el (egyáltalán, vagy más paraméterekkel), hogy milyen környezetben futnak.
Ugyanez az rc scriptes megoldás képes konténerben is futni, és hasonló feladatokat ott is elvégezni.

Ez bonyolult lenne systemd-ben?
--
zsebHUP-ot használok!

Ez szép, de nem tudok rá egyértelmű választ adni, ilyen felhasználási területen még nem láttam. Bár létezik systemd-sysVcompat, de azt ezesetben szerintem gányolásnak kellene tekinteni, natív systemd-s megoldásra elsőre nem tudok mondani semmit azon kívül, hogy feltételezhetően megoldható :). De én desktop user vagyok jelenleg, szóval lehet, hogy van itt valaki aki okosabb mint én :)
Szerk: nem példa, de kapcsolódik valamennyire, bár még nem olvastam végig: systemd for Administrators, Part XX.-XXI. az 0pointer.net -en

Elso olvasatra ez nem lenne bonyolult systemdvel sem.

--
|8]

A FreeBSD-ben készen van, annál csak bonyolultabb lehet. :)
De érdekelne, tudsz esetleg linkeket, keywordöket adni, ami mentén el kellene indulnom?

EnvironmentFile, preset, systemd.target(5).

Gyartoi alap az ugye adott, a default lehet egy preset, a network/class cuccokhoz megfelelo targeteket csinalni, es egy ip cimnek szolo service-el osszekotni ezeket. Kulonbozo lokalis/dinamikus parametereket pedig EnvironmentFile-al gyonyoruen meg lehet oldani.

Valoszinuleg lehet maskepp is, hirtelenjeben ez jutott eszembe.

Ha picit hierarchikusabban szeretne az ember, akkor lehet systemd.slice(5)-al buheralni, csoportositani.

--
|8]

Elraktam, remélem nem jutok el oda sosem, hogy szükségem legyen rá. :)
Köszönöm.
--
zsebHUP-ot használok!

En mindenesetre koszonom az erdekes use-caset, adott par otletet a sajat rendszerem egyszerusitesere/rendbetetelere az, hogy gyorsan atgondoltam mivel lehetne megoldani a te esetedet :D

win-win! ELJEN A SYSTEMD!</troll>

--
|8]

subs

Sajnos nem annyira a jövő kérdése hogy Russ Allbery visszalépett a Technical Committee-ből. Szintén szóba kerül a systemd: https://lists.debian.org/debian-project/2014/11/msg00054.html

Sajnálom egyébként. Joey Hess-el egyszer találkoztam és váltottam két mondatot, de tudom hogy remek programozó. Tollef Fog Heen-el meg dolgoztam is együtt, szintén nagyon jó véleményem van róla.

Megszólalt Lucas Nussbaum DPL is: https://lists.debian.org/debian-project/2014/11/msg00061.html
Részben Steve Langasek véleményére alapozva a kedélyek csillapítására hívta fel a figyelmet. Elismerte hogy az init rendszer választás az egyik legnehezebb volt a Debian életében annak többféle aspektusa miatt.

Ezt valahogy nem láttam előzőleg. Szerintem Colin már akkor aktív DD volt amikor én még épphogy elkezdtem a Debian-al való ismerkedést (Unix vonalról jövök és SuSE volt az első Linux-om), közben már egy jó ideje DD vagyok magam is.
Annyit ír, hogy kiégve érzi magát és szeretne kevésbé stresszes dolgokkal foglalkozni. Ami biztos, hogy Debian mellett kezdetektől Ubuntu alkalmazott (Ő volt a 17-ik akit felvettek). Utóbbin belül Ő volt aki megalapította és vezette a telepítő készítő csapatot, volt fejlesztési vezető, de technikai vezető is egymás után. Tagja volt a Technical Board-nak is. Olyan dolgok fűződnek a nevéhez mint az Ubuntu-s UEFI Secure Boot implementáció, csomagok keresztfordításának biztosítása, számos Python csomag Python3-ra portolása vagy akár több egyéb project-ben való részvétel.
Pár éve egy hotelben volt szerencsém Vele ebédelni. Akkor tűnt fel csak igazán, mennyi mindennel foglalkozik és vajon hogyan bírja. Magánélete a sajátja, legyen elég annyi hogy egy olyan kis gyermeke van, aki kb most megy vagy most jár bölcsödébe. Egyáltalán nem csodálom hogy lazítani akar és nem kötöm össze a systemd vitával. Legfőképp hogy nem csak a Debian Technical Committee tagságáról, de az Ubuntu-s vezetői tisztségeiről is lemondott ha jól tudom.

Joey a blogján kifejtette, hogy nem a systemd miatt lépett ki, hanem mert a Debian nagyra nőtt. Ahogy olvasom másoknál is inkább ez jött elő, hogy ez a Debian már nem az a Debian, amihez 10-15 éve csatlakoztak.

De az emberi természetből fakadóan itt is, mint minden egyéb fórumon nyilván azt kell kidomborítani, amiből flame lehet. :S Már a cím is bulváros, szánalom, hogy egy szakmai kérdés ide süllyed.

>systemd
>szakma

kek

Köszi a frappáns demonstrációt az állításomhoz.
Engem nem (sem) kényszerített senki a váltásra, de nem sz@rok be minden újdonságtól, utánanéztem, kipróbáltam, bevált. Ezek után ideológiai problémává előttem már nem fog válni ez a kérdés :P
Az, hogy a számomra amúgy is kicsit dinoszaurusz debian berkeiben ki hogy éli meg, az a tényen, miszerint ez nem egyéb szakmai kérdésnél, nem változtat.

Windows-osodik a Linux

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Ha'persze.

--
L

Nem, sajnos ebben történetesen igaza van. A systemd lényegében az svchost-ot találja fel újra. Annak szinte minden architekturális hátrányával együtt.
---
Régóta vágyok én, az androidok mezonkincsére már!

Sajnos ez nagyon igaz. Eddig nem tudtam, honnan ismerős a dolog, de megvilágítottad.
Köszi... :)

Ahh mese!

Ez kb. olyan, mintha azt allitanank, hogy a gconf/dconf a windows registry lenne ujrafeltalalva.

(ahelyett, hogy fajlokat figyelne es ha valtozas van ujratoltene, kulon hasznalhatatlan xml megjelenitoben kell turkalni)

Ezek szerintem tok veletlen egybeesesek.
Miert pont a masik rendszer gyengeit (es csak azokat) masolnak le?

---
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 servicek nem lettek .so -k (.dll) -ek, mar innen is latszik, hogy nem svchost.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Abban szerintem igazad van, hogy "Miert pont a masik rendszer gyengeit (es csak azokat) masolnak le" ugyanis szerintem sem tudatos a másolás.

Ha az lenne, akkor megpróbáltak volna tanulni a másik hibáiból.

De tévedés ne essék, nekem a systemd-vel addig nincs bajom, amíg az csak egy init rendszer. De már rég nem az.

A gondok ott kezdőnek, hogy minden egyéb szart is elkezdtek ebbe beleerőszakolni (pont ebben hasonlít az svchost-ra). Van néhány dolog, ami külön processbe kerül, ezzel nyilván lehet érvelni a svchost-hasonlóság ellen, de sokminden monolitikus maradt.

De ami szerintem különösen problémás, hogy sok bevált, régóta karbantartott, kiforrott daemont cserélnek most le saját új implementációval. Olyanokat is, amiknek már érintőlegesen sincs közük az init alaprendszerhez. Nem meglepő, hogy tele van hibákkal (amatőr tervezési hibákkal is), regressziókkal, feature-vesztéssel, még éveknek kell eltelnie, mire komolyan használható lesz.

Szóval én valahogy komplex módon látom a systemd körüli problémát.
Az alap init rendszernek vannak hasznos feature-jei. Nyilván vannak nehezen lefedhető use-case-ek, de a tipikus feladatok többségét elég jól és könnyen el lehet benne intézni. Csomó korábbi jellegzetes hacket szükségtelenné tesz.

Vannak az init rendszerhez elég szorosan kapcsolódó funkciók (login, cron, disk-encryption password prompting, fs mounting), ezeknél még védhető, hogy integrálva lettek.

Aztán a hálózat környékén kezdődnek a bajok. Szerintem eleve az init rendszernek nem kéne a hálózathoz nyúlnia, max ifup erejéig. Forgalmaznia, hallgatóznia semmiképp nem volna szabad. Csakhát az ifup vonalon elindulva bejött a DHCP, akkor már legyen DNS kezelés is. Persze nem lehet megállni a resolv.conf kezelésénél, hiszen sok disztró már alapból dnsmasq-t rak be, így rögtön jött a DNS proxy/cache is. Ifup után tipikusan szokott kelleni tűzfalat felhúzni, akkor már legyen firewall manager is. Szokott még lenni hálózat felhúzás után NTP, legyen az is benne, ez már triviálisan húzta magával a timezone kezelést is. Stb stb. journald-re és tervezési hibáira most nem térek ki, az is egy külön történet.

Szóval az gond, hogy nem tudtak egy vonalat húzni, hogy ez még init rendszerhez hozzátartozik, az már nem. Sorban egymás után húzzák be maguk alá a daemonokat, mindig csak a következőt, ami éppen "adja magát". Így sosem lesz vége, jön a sshd, httpd, komplett grafikus desktop környezet, vm manager, ez mind sorra fog kerülni, mindig éppen csak a soron következő apróság miatt. Ráadásul nem beintegrálják a meglevő megoldásokat, hanem újraírják, sőt sok esetben újra is tervezik, nulláról újra-feltalálják. Ennyi felelősséget egy projekt nem vállalhat fel, ennyi mindenhez egyszerűen nem érthetnek kellő mélységben. És nem is értenek.

De a baj itt nem ér véget, ugyanis még mindig lehetne értelmes kompromisszumot találni. A fenti tervezési döntések még mindig úgy-ahogy védhetőek lennének, ha valami nagyon kompakt beágyazott disztribúcióhoz készítenének valami mindent egyben tudó busybox-szerűséget. A desktop/szerver disztrók megállhatnának a systemd alap feature setnél. Csakhogy a többségük nem így tekint rá (mondjuk a systemd fejlesztők sem így pozicionálják), hanem valami új standard linux userland-et látnak benne, ezért a disztrók tényleg minden compile-time opcionális "szatelit" feature-t használni is akarnak. Szerintem ez a valódi gond.

Just my 2c on teh topic.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nézd pozitívan: egy új lehetőség a nullás uid megszerzésére. :)
--
zsebHUP-ot használok!

A 0-s uid, az so last week. Úgy az igazi, ha az 1-es pid-et is sikerül megszerezni hozzá. :)
---
Régóta vágyok én, az androidok mezonkincsére már!

+1

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

nalam olyan egyszeru dolgok feladtak a leckek, hogy elerheto daemonok listazasa.
regen (kb. 4 eve) eleg volt egy `ls /etc/init.d`.

Varom mar, amikor D-bus-on lehet majd konfiguralni.
Ami aztan egyik helyi fajlban se tukrozodik,
hanem mindig D-buson kell lekerdezni a konfigmodositast,
es minden rebootnal D-buson keresztul hozzairni :)

Innen mar csak egy lepes a billentyuzet es eger szimulacio....

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

systemctl list-unit-files -t service gyonyoruen kilistazza neked az elerheto serviceket.

Most is DBuson keresztul lehet vezerelni, ami kisertetiesen hasonlit egy control socketre (ami volt sysvinitnel is, es megvan syslog-ng-nel, haproxynal es sok egyeb daemonnal). Nyilvan az itt elvegzett dolgokat megfeleloen perzisztalja. Van egy programozhato API-ja, dokumentacioval, librarykkal N+1 nyelvhez. Nem ertem, mi ebben a rossz.

--
|8]

you're doing God's work

Vegre valaki eszrevette!

--
>8]

"systemctl list-unit-files -t service gyonyoruen kilistazza neked az elerheto serviceket"

Azert vessuk mar ossze a kettot, hogy mennyivel masabbak. Tobbet is kell gepelni, raadasul ehhez fejbol kell vagnod a list-unit-files alparancs parameterezeset. Ehhez kepest szerintem az ls /etc/init.d sokkal-sokkal kezenfekvobb.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Hat nekem az elsohoz syst<tab>c<tab> lis<tab>u<tab>-<tab> kell, ami meg mindig hosszab, cserebe ha gyakran hasznalom, akkor csinalok ra egy aliast. Mint ahogy ls /etc/init.d/-re is csinalnek, ha sokszor hasznalnam. A parancs hosszat kritizalni imnsho nagyon szanalmas.

A kimenet pedig valoban mas, ahogy a parameterezes is. Ha a kimenet ertelmezese, es a parameterek megtanulasa (foleg man oldal meglete mellett) gondot okoz, akkor lehet, hogy nem IT teruleten kene dolgozni.

Vannak ennel sokkal ertelmesebb kritikak is systemd ellen. :)

--
|8]

Plusz tegyük hozzá, hogy van olyan disztribúció nem is egy, ahol nincs is /etc/init.d, hanem /etc/rc.d van, vagy épp almappákban ülnek a scriptek, vagy épp a /usr/etc alatt vannak... és akkor mindjárt nincs a gyors listázás, csak anyázás.

Nem okoz problemat sem a megtanulas, sem az ertelmezes. Csak minderre nem volt szukseg korabban, volt egy egyszeruen hasznalhato rendszer, csinaltak helyette bonyolultat, aminek sokkal hosszabb a betanulasi ideje, mint a regi rendszere volt. Es meg csak az alapveto funkcionalitasokrol beszelunk, nem az unitok/init scriptek sorozat gyartasarol.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ezzel vitaba szallnek. A magam reszerol en sokkal egyszerubbnek tartom a systemd-fele megoldast, debugolnom is konnyebb, es sorozatgyartani is a serviceket. Ket bonyolultabb sysvinit script irasa utan rettentoen kezdtem unni a dolgot, es valami egyszerubben kifejezhetore vagyni. (Case in point, syslog-ng debianos init scriptje a mai napig rettento torekeny, hosszu, es bonyolult, mig a systemd service file hozza ko egyszeru, es megcsinalja ugyanazt jobban).

Nagyjabol 2 napba telt megtanulni mely man oldalakon kell korbeneznem, ha valamit nem tudnek fejbol. sysvinitnel ilyen segitsegem nincsen, neten meg mas init scriptekben kell vadaszni, ha olyan megoldas kell, amire nincs meg fejben a valasz (es volt par ilyen eset).

--
|8]

Ez az egyik kedvenc részem a systemd-ből:

https://github.com/systemd/systemd/tree/master/shell-completion/bash

Én sem szeretek gépelni.

További különbség, hogy a systemd esetében ez tényleg a szolgáltatásokat listázza, míg a jól irányzott ls /etc/init.d (sajnos) nem-szolgáltatás nevű fájlokat is megad (akármi.bak, killall, stb.), ezen kívül nem adja meg pl. az rc.local-ba belehegesztett szolgáltatásokat sem.

Az egységesítés tud jó dolog lenni.

Jo, csak mondjuk recovery shellben nem biztos, hogy betoltodik a completion, egyaltalan, az se biztos, hogy bash indul el, nem valami recovery shell (busybox sh, dash, barmi egyeb). Tudom, akkor ott a man, le lehet irni papirkara a parametereket, aztan fel lehet gepelni. Komolyan... (doh)
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Azzal együtt, hogy nekem se lopta még be magát a szívembe a sysctl paraméterezése (majd biztos megszokom, ha sokat kell nyomkodni), de azért az megvan, hogy most kb arról beszélsz, hogy azt hogy /etc/init.d/ már megjegyezted, azt hogy list-unit-files meg még nem?

Nem a megjegyzes a gond, hanem amikor hirtelen kell az info, konnyebb olyanra emlekezni, aminek valami kotodese van a problemahoz. A systemctl list-services pl. sokkal emberkozelibb lenne, mint a list-unit-files. A list-unit-files szamomra semmit nem jelent, nem visz kozelebb a problema megoldasahoz, es ha valamiert elfelejtem, a man-ban nem az lesz az elso parancs, amit meg fogok nezni, hanem ugy kezdem, hogy /service aztan ahol van a leirasban valami a szolglatatasokrol, azt fogom vegigolvasni.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Magyarul ha valami uj, akkor fuj. Ertem.

--
|8]

Ebben az olvasatban egyetértek :) Mikor kicsit nyomkodtam ez a unit izé nekem is bökte a szememet.

Ha nagyon ls: ls /usr/lib/systemd/system && ls /etc/systemd/system ;)

A list-unit-files-nak annyi értelme van, hogy így mindent listáz (mount point, slice, service, target éssatöbbi), amit az összes többi systemctl hívásnál használható szűrővel (-t service) tudsz szűrni (pl. működik a systemctl status -t service is, de egy systemctl status -t mount-al le tudod kérdezni az összes mount point állapotát). Ráadásul nagyon nem is kell megjegyezni sokat, annyi, hogy systemctl, annak a man oldalán ott van minden paraméterezhetőség - ez az előnye meg van annak, ha mindent egy parancs mögé dobálnak be :)

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

"list-unit-files-nak annyi értelme van, hogy így mindent listáz"

Pont ez a bajom vele. Nem akarok szurni, nem akarok gondolkodni, hogy milyen parameter kell _meg_ ahhoz, hogy azt az eredmenyt kapjam, amit elvarok. Meg ha meg is tudom jegyezni, akkor is hosszu, unalmas, es en utalok gepelni. Ha van olyan, hogy svcs, annal csak es kizarolag bonyolultabb lehet szinte barmi.

Nem az a baj, hogy ne lenne man oldala, vagy ne tudnek utana nezni. Hanem az, hogy basszus ott van mellette harom masik init rendszer, ahol adott pelda van arra, hogy hogyan kell ezt ertelmesen, kenyelmesen megcsinalni. Nem az ls parancshoz ragaszkodok, de a systemd eseteben konkretan az ls is kenyelmesebb. Pedig ott meg manualisan kell szurogetni is.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A probléma az, hogy az SMF csak a szolgáltatásokkal foglalkozik, míg a systemd rendszerszinten gondolkodik (lehet pro- és kontra érveket hozni). [A sysvinit-et hagyjuk, az kb. a process szinten gondolkozik]

Lehet azt csinálni, hogy a systemctl különböző paraméterezéseit aliasokba/wrapperekbe kidobáljuk, abból meg az lenne, hogy lenne egy svcs, egy mounts, egy slices, egy targets, sockets, swaps, automounts, timers, ... parancsod - ami megint a megjegyezhetetlenség határát súrolja (ehhez a listához is bele kellett néznem a man-ba, pedig a két sorból csak egyet írtam össze).

Idézet:
Hanem az, hogy basszus ott van mellette harom masik init rendszer, ahol adott pelda van arra, hogy hogyan kell ezt ertelmesen, kenyelmesen megcsinalni.

Lentebb javasolta már valaki a SystemD for System Administrators sorozatot (a http://www.freedesktop.org/wiki/Software/systemd/ oldalon össze van gyűjtve az összes), tényleg fusd át, szépen leírja, hogy mi miért van - sok mindenre rávilágít és sok kérdést megválaszol (pl. valaki be szokta dobni, hogy de miért kell mask-olni letiltás után egy service-t, #5: nem kell (a letiltással többé nem aktiválódik, csak systemctl-el lesz indítható), viszont ezzel tudod biztosítani, hogy soha senki semmilyen körülmények közt nem fogja a systemd-vel elindíttatni - ha bízol mindenkiben, akinek van jogosultsága systemctl start-ot hívogatni, akkor elég a disable)

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

"A probléma az, hogy az SMF csak a szolgáltatásokkal foglalkozik, míg a systemd rendszerszinten gondolkodik (lehet pro- és kontra érveket hozni). [A sysvinit-et hagyjuk, az kb. a process szinten gondolkozik]"

Es? Ez engem hol kell erdekeljen? Nem birtak egy olyan utility-t csinalni, ami csak a szervizeket kezeli? Ertem, hogy a systemd ennel sokkal okosabb, tenyleg, meg is emelem a kalapomat a tudasa elott, okosabb mint en. Ezzel egyutt en szeretnem, ha buta modon is elerhetnem a gyakran hasznalt funkciokat. Ez olyan nagy keres?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A következő bekezdésben erre ott a válasz: ha a service-ek kapnak egy ilyet, akkor az összes többinek is kellene, és lenne 20 utility-d.

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

Igen, lenne 20 utility. Es ez azert rossz, mert?

Raadasul, a service-k inditasa a leggyakrabban hasznalt funkcio a systemd-ben (a mountokat szerintem meg mindig mindenki a mount paranccsal fogja kezelni, meg ha ebben is jobb a systemd), szoval arra kulonosen indokolt lenne egy rovidites.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Mert akkor 20 utility-t kéne megjegyezni :)

Egyébként Poettering-ék személyes tapasztalataim szerint egész korrekten állnak a feature requestekhez (én is küldtem egyet, írták, hogy nagyrészt amúgy is a TODO list-en van, de kódot szívesen fogadnak, az egyetlen gond, hogy a C-től hányok), ha kóddal együtt küldesz nekik, jó eséllyel a következő systemd-ben már ott lesznek a shorthand utilok.

(Off-topic: egyébként nemsokára jönnek majd a systemd-re épülő, kifejezetten kényelmi eszközök, mint a Fedora Server Role-ok, amivel nem 1-1 service-t, hanem teljes role-t tudsz egyben kezelni: rolectl start domain-controller. Belül ez gyakorlatilag egy target indítása: https://fedorahosted.org/rolekit/wiki/Design/RolePackaging)

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

remelem, nem csak fedoraba lesz ilyen, hanem debuntu vonalon is...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Alias. De most komolyan. Amennyit irtal, tizszer megirod az aliast, sot, akar olyan shell functiont is ami sysvinit, upstart es systemd rendszereken is pont azt kopi ki, ami kell neked.

--
|8]

Persze, ebben igazad van. Valoszinu, ha sokszor kell majd hasznalnom, szulni fogok aliast is. De amikor bemegyek egy random gepre, mert eppen megbiznak, hogy javitsam meg, akkor nem lesz ott az alias. Amikor olyan gepre kell bemennem, ahol nem modosithatok semmit, mert ilyen a megbizas, nem lesz ott az alias.

Hidd el, ertek a Linuxhoz, pontosan ismerem ezeket a mechanikakat benne, es ahol lehet, megoldom vele a problemaimat. 15-20 alias van csak a home-omban, ezen felul az altalam gyakran hasznalt gepeken tobb alias es script konnyiti meg a munkamat. De van, ahol ezek nem allnak, nem allhatnak rendelkezesre.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ez mindig félmegoldás. De komolyan. Igaz addig, míg van pár rendszered, amit magad tákolgatsz. Aztán mikor van sok, akkor ott nem lesz alias, hanem default lesz.

Ha gondot okoz recovery shellbol man-t vagy basht inditani, vagy betolteni a completiont, akkor szerintem komolyabb problemaid vannak. Ha nem akarsz tanulni, akkor hasznalj oskovulet rendszert ami sosem valtozik.

--
|8]

Pont ugyanaz a problemam a systemd-vel mint a PHP-val: baromira nem intuitiv a hasznalata. Annak idejen azert tertem at Ruby-ra, mert olyanok a konvencioi, hogy egy szamomra tokeletesen ismeretlen konyvtarat is ugy tudok hasznalni, hogy kb. nem vagy csak egyszer nyitom ki a doksijat, es utana vakon gepelem be a parameterezeseket, elenyeszoen kis hibaszazalekkal. Ez pl. PHP-nal sosem volt igy.

Ugyanez az upstart-tal, amikor lattam hogy van service parancs (CentOS-bol ismeros volt), akkor gyakorlatilag ket probalkozas utan tudtam, mi a parameterezese. Mert tudtam, mit akar tolem. A systemctl list-unit-files -rol elso ket korben gozom nincs, mit akar visszaadni, egyaltalan mik azok az unit fajlok? Es ez hol erdekel engem, ha a szervizekre vagyok kivancsi? Sehol.

Es valami ilyesmit varnek el a systemd-tol is. Egyszer elolvasom a manjat, es onnantol legyen intuitiv hasznalni. Az, ami most van, eleg sokminden, de nem intuitiv. Es ezt tartom problemanak. Tokeletesen irrelevans, hogy _en_ kepes vagyok-e megtanulni hasznalni, mert a systemd-t nem hrgy84 szamara irtak, hanem tobbszazezer ember szamara. Egy ilyen alapveto rendszertol igenis elvarhato, hogy onmagyarazo parancsai legyenek.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Izlesek es pofonok. Szerintem meg pont tok intuitiv a systemd (a Ruby meg nem :P).

Uj technologia -> doksi, tanulas. Ennyi. Amennyit itt osszeirogattal, ennyi ido alatt 3x meg lehet tanulni systemd alapokat. Van egy kivalo systemd for administrators sorozat, ami szepen fokozatosan bevezeti az embert a temaba. Csak ajanlani tudom.

(fyi, a sysvinitnek egy onmagyarazo parancsa sincsen.)

--
|8]

"sysvinitnek egy onmagyarazo parancsa sincsen"

Az eg meg valojaban nem kek, csak a feny igy szorodik rajta. Irrelevans. Attol, mert a sysvinit kenyelmetlen, ez nem excuse arra, hogy a systemd is az. Allitolag azert kezdtek neki, hogy valami jobbat csinaljanak.

"Van egy kivalo systemd for administrators sorozat, ami szepen fokozatosan bevezeti az embert a temaba. Csak ajanlani tudom."

Kosz, ennek utana tudok nezni. Ezzel egyutt meg mindig nem az a gond, hogy nem birom megtanulni. A zypper-t is megtanultam, pedig annal elbokottebb csomagkezelo keves van a vilagon. A gondom az, hogy kenyelmetlen, es ha szaz doksi van melle, akkor is kenyelmetlen. Es ha egy cipo kenyelmetlen, nem veszem meg. Miert tegyek maskepp egy init rendszerrel?
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Idézet:
A zypper-t is megtanultam, pedig annal elbokottebb csomagkezelo keves van a vilagon.

Mi a baj a zypper-rel? Nekem kifejezetten szimpatikus pl. a vendor stickyness benne, szerintem egy sokkal normálisabb koncepció, mint az apt pinning vagy a yum priorities.

Idézet:
Miert tegyek maskepp egy init rendszerrel?

Mert egy nadrág gyártó nem fogja neked azt mondani, hogy lehet, hogy a gumicsizma mocsok kényelmes, de ha az én nadrágomat akarod gumicsizmával viselni, akkor leszel szíves a logót letépni róla és letagadni, hogy valaha találkoztunk - egy szoftver vendor megteheti. Márpedig a vendornak érdeke előírni, hogy egy technológiailag sokkal fejlettebb, egységes ... rendszert kell, hogy használj - így előbb-utóbb (nem feltétlenül ma), meg fogja tenni.

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

" vendor stickyness benne, szerintem egy sokkal normálisabb koncepció, mint az apt pinning vagy a yum priorities."

Az nekem is szimpatikus, az kevesbe, hogy ezt csak es kizarolag konfig fajlbol engedi kikapcsolni, kulonben vert vizelsz, mire minden egyes rohadt csomagot, amit kell, atmozgatsz A vendortol B vendorhoz.

"Márpedig a vendornak érdeke előírni, hogy egy technológiailag sokkal fejlettebb, egységes ... rendszert kell, hogy használj - így előbb-utóbb (nem feltétlenül ma), meg fogja tenni."

Igen, csakhogy en valaszthatok olyan vendort, aki szamomra kenyelmesebbe tette a fejlett, egyseges rendszert. A tobbi vendor meg megszivta. Mindazonaltal, ettol meg fenntartom a jogot, hogy kritizaljam a "fejlett, egyseges rendszer" hibait.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Akkor ne vedd meg. De attol, mert Te nem tudod/akarod/lusta vagy megtanulni, az meg nem lesz feltetlen az init rendszer hibaja. Szerintem pl a list-unit-files sokkal kezreallobb (foleg egy joliranyzott aliassal), mint az ls /etc/init.d/ (vagy epp rc.d, vagy a frasz tudja mit hasznal epp a distro/os). Foleg, hogy ls kimenetbol nem latom, hogy mi disabled meg enabled, pedig imnsho az sokkal hasznosabb lenne.

--
|8]

csak nem az osszest....

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

cf: svcs -a

Az ezek szerint a fő baj ezzel a systemd-vel, hogy láthatóan olyan emberek hozták a döntéseket a projektet illetően, akik ehhez nem elég okosok, de az arcuk mégis túl nagy. Nem kellett volna nekiállni újból feltalálni a fa- meg a kőkereket, ha mások már a /35-ös radiálnál tartanak...

Redhat: chkconfig --list
Monit: monit summary

Mindegyik rovidebb es megjegyezhetobb, mint a systemd cucca. Tudom, eretnek vagyok, tessek dobalni a koveket.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:

()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

alias lsinit='systemctl list-unit-files -t service'

Szivesen, maskor is.

--
|8]

in this thread: damage control

KDbus lesz az majd. ;)

Idézet:
ifup után tipikusan szokott kelleni tűzfalat felhúzni

ifup előtt ;-)

Attól függ. (Lehet, hogy az utóbbi időkben túl sok olyan tűzfalat írtam, amiben a gép konkrét IP-jét fel kellett használni?!)
---
Régóta vágyok én, az androidok mezonkincsére már!

A tuzfalat a halozat inditasa elott illik aktivalni, mert kulonben van egy rovid intervallum, amikor vedtelen a geped.

Idézet:
Lehet, hogy az utóbbi időkben túl sok olyan tűzfalat írtam, amiben a gép konkrét IP-jét fel kellett használni?!

Halozat inditasa utan aktivalod azt az egy-ket szabalyt, ami fugg az IP cimtol?

Vagy előtte bekapcsolsz egy default DROP szabályt, aztán meg belövöd a véglegeseket...

Mondjuk a Debiannál amennyire tudom (javítsatok ki, ha nem így van) szoktak szavazásokat tartani arról, hogy merre tovább, és egy ilyen szavazáson dőlt el, hogy systemd-re állnak át. Ha ezek után valakinek ez nem tetszik, akkor így járt - és valahol az is benne van, hogy a Debian erős demokráciájával sem ért egyet, helyette a saját maga által vezetett diktatúrát szeretné inkább vezetni. Ez nem túl szép dolog.

Közben állítólag "kiderült", hogy nem a systemd és a vele kapcsolatos döntések, veszekedések, viták miatt vált éppen most kellemetlenné a Debian egy csomó embernek, hanem - mit tesz isten - éppen most lett túl nagy, zajos, <tedd a további fals kifogásokat ide>..

--
trey @ gépház

A systemd-vel kapcsolatos flamek mint ok, nagyon mas, mint a systemd maga. Foleg, hogy ha figyelembe vesszuk, hogy a kozelmultban ilyen-olyan posztokrol lemondottak (joeyh, rra, cjwatson, Mithrandir) kozul egy kivetelevel mind a systemd mellett tette le a voksat.

--
|8]

Ahogy én látom: ez a vita a Debianon belül és kívül kezd felettébb kellemetlenné válni egyeseknek. Így aztán aki teheti, kezdi magát függetleníteni tőle még idejében. Aki ellene volt azért, aki mellette azért (utóbbiaknak akkor lesz főleg kellemetlen, ha majd kijön a Jessie és a systemd mégsem válik be).

--
trey @ gépház

Hat amikor az ember csaladjat fenyegetik, az valoban kellemetlenne tud valni. Es bar van kapcsolat a valodi okok es a systemd kozott (bar joeyh eseteben peldaul semmi nincsen), akkor sem a systemd szedi az aldozatokat Debianon belul.

(Ha a systemd megsem valik be, akkor meg majd visszavaltunk. Nem ez lesz az elso visszavaltas, ha lesz, de az egy teljesen masik teszta. Es egyatalan nem lesz kellemetlen, ha netan nem valna be. Senki sem mindenttudo, es adott helyzetben hozott, megalapozott dontest nem kellemetlen.)

--
|8]

Arra utaltam, hogy a kilépők közül bármennyire is tagadják, szerintem a systemd körüli bohózat (vagy tragikomédia) az, ami szerepet játszott. Persze ha valaki azt szeretné, hogy később ne hozzák vele kapcsolatba, akkor ír egy blogbejegyzést arról, hogy nem amiatt lépett pont most le.

--
trey @ gépház

Ertem amit mondasz, de meg mindig arrol van szo, hogy systemd aldozat != systemd koruli bohozat aldozata. Fuggetlenul attol, hogy epp miert lepett le az illeto, az elobbi relacio fennall, igy a cikk cime alapvetoen hibas.

--
|8]

Lehet, hogy lehetett volna pontosabban is fogalmazni, bár szerintem ez csak szőrszálhasogatás. Maga a systemd az, ami a szart megkavarta. Most, hogy nem technikailag van vele baj, csak az, hogy megosztja az egész közösséget és ilyen indulatokat kelt, az szerintem tökmindegy.

--
trey @ gépház

Teljesen rosszul latod, mi folyik Debianon belul, de mindegy.

--
|8]

Ezeket a kommenteket (benne Bruce Perens-szel) elolvasva nekem valami nagy fejetlenség és kavarodás rajzolódik ki.

https://lwn.net/Articles/620879/#Comments
https://lwn.net/Articles/621003/#Comments

De ha van időd, akkor szívesen meghallgatom, hogy te hogyan látod belülről.

--
trey @ gépház

Fentebb írtam, hogy Colin Watson tényleg kiégésre hivatkozva mondott le TC tagságáról, de Ubuntu-ban is lemondott a tagságairól. Most nem tudom hol, de ha akarod megkeresem hogy (Ubuntu vonatkoztatásában) azt írta, hogy annyiban továbbra is aktív marad, hogy ha bármivel megkeresik, akkor segít a megfelelő emberhez irányítani a dolgot. Egyébként Ubuntu területére olyan személyeket keres, akik minden főbb feladatát át tudják venni.
Tehát nem csak Debian és nem csak systemd területén vesz vissza aktivitásából. Kiskorú gyermekére is gondolhatott.

Sam Hartman (volt DPL jelölt) egy pozitívabb nézőponról ír systemd kapcsán: https://lists.debian.org/debian-project/2014/11/msg00073.html

Tehát, ha jól értem, akkor összefoglalva: a suta indokokkal alátámasztott távozásoknak semmi köze a systemd-hez, az egész a véletlenek fura egybeesése és aki a systemd-t lát bele, az rémeket lát.

--
trey @ gépház

Itt csak Colin Watson-ról van szó, akit van szerencsém személyesen ismerni. Róla tudom csak biztosan azt írni hogy az elmúlt tíz évben odatette magát mind Debian, mind Ubuntu területén mint ~középvezető. Tőle nem csodálom hogy lazítani szeretne, főképp hogy kisgyermeke is van. Másrészt nem csak Debian, de Ubuntu tisztségeiről is lemondott, amihez még köze sincs a systemd-nek.

Többiek távozására, lemondására nem írtam semmit ha jól emlékszem - de javíts ki ha tévedek. Illetve annyit írtam, hogy Joey Hess-el is találkoztam személyesen, de Vele csak kb két mondatot váltottam (valahol többen sétáltunk és kérdezett valamit a fényképezőgépemmel kapcsolatban, kb mint mennyi képet készítettem). Az hogy miként vélekedik a project-ről vagy mennyire volt napi szinten elhavazva az ennyiből nem derült ki.

Colinnal én szinte napi kapcsolatban vagyok és az elmúlt három évben végigkövettem azt amiről itt is ír: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014/10/26

Az ő döntésének semmi, de az égvilágon semmi köze nincsen semmilyen technikai vagy distro politikához. Colin tényleg elkezdett kiégni... ezzel együt soha életemben nem találkoztam még olyan szintű zsenivel mint ő, aki egész egyszerűen mindent tud. Ráadásul mindig kedvesen, segítőkészen és végtelen türelemmel képes segíteni bárkin aki hozzá fordul.

Jelenleg egyébként az Ubuntu CI-nál dolgozik.

A kommentjeit meg nem olvastam eddig, egy kivetelevel, az elegge nagy csalodas volt. Most beleneztem a tobbibe, es azt kell mondjam, hogy a systemd-t nem erinto meglatasai teljesen helytalloak (de, mint irtam, meg nem olvastam mindet). (A systemds aggalyaival, otleteivel meg a fo gond az, hogy "we must", de akik akarjak, azok nem csinaljak, akiknek meg mondja, azok szerint pedig nem szukseges megcsinalni az altala elkepzelt valtoztatasokat).

Ahhoz kepest, hogy mara kb semmi koze nincs Debianhoz, egesz jo ralatasa van 1-2 dologra.

Debian belulrol: http://rhonda.deb.at/blog/debian/2010/08/04. Egy pelda 2010-bol, ami pont ugyanarrol a helyzetrol szol, ami miatt most lelepnek emberek. Mar akkor, 2010-ben, amikor systemd meg sehol nem volt, akkor is erezheto volt. Hasonlo okokbol lepett le joeyh, hasonlo okokbol mondott le rra. Nem a systemd-vel kezdodott, annal sokkalta melyebb a problema.

Tanulsagos olvasmany meg ez: http://mhall119.com/2014/11/economic-warfare-in-foss/ - ez pont az adott helyzetrol szol. Nem ez az elso ilyen Debiannal, nem is az utolso, es nem csak a Debian erintett, csak a Debiannal latvanyosan jon elo, mert hatalmas project, es sokakat erint, mi tortenik vele.

Picit tovabb szove: az az alapveto problema, ami miatt joeyh lelepett, ami miatt Rhonda is rosszul erezte magat 2010-ben (es azota is elo-elo tornek belole ezek az erzesek), ami miatt tobben letettek ilyen-olyan sapkaikat (vagy csendben, vagy kihirdetve, ki-ki vermerseklete es sajat belatasa szerint), az az, hogy a Debian belulrol nem egy kellemes hely sokszor. Erosen megnovekedett a politika es a rosszindulat, a rosszindulat feltetelezese masokrol. Mig regen ott voltak a durva flamewarok, azok legalabb nyiltak voltak. Az alamuszi, sunyi betamadasok nem voltak jellemzoek. A hatalommal valo visszaeles meg meg annyira sem.

Matthew Garrett fogalmazaott ezzel kapcsolatban jol Twitteren: https://twitter.com/mjg59/status/534619491842265088.

A problema reg kezdodott, es lassan erik be. Ketsegtelen, a systemds nyugok, es az esztelen mennyisegu troll sem segit a dolgon, de ha nem lett volna gaz a helyzet elotte, akkor ezek nem okoznanak problemat. Peldanak okaert az ffmpeg<->libav cucc legalabb ekkora katyvasz, sot!, es latvanyosabb is, imo, megsem volt miatta ekkora felhajtas. Miert? Mert TC nem volt bevonva annyira, mint systemd kapcsan.

--
|8]

Korrigalnek. Joey Hess *nem* a systemd miatt tavozott. Tollef Fog Heen sem.

Joey kerek perec megmondta, hogy nem systemd miatt. Tollef szinten (az, hogy systemd maintainerseg miatt tamadtak, nagyon mast jelent, mint az, hogy a systemd aldozata lenne).

--
|8]

Ez azert nem annyira egyertelmu. Szinten Joey Hess-tol:
title: "please stop"
"""
I am astounded that, in #762194, the technical committe has
...
This is not a decision-making process that will yeild a high-quality
distibution. Or one that I can be proud to be involved with. Or one
that, frankly, gives me any confidence in the technical committee's
current membership or indeed reason to continue to exist.
"""

Szerintem is a systemd-vel borult a bili. Ha nem is a systemd a ludas, de ravilagitott, hogy tobb burokracio van a Debianban mint egy EU tagallamban...

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

joeyh kielepesenek a burokraciahoz es a debianon beluli hangulathoz van koze, ahogy irod is. a systemds hacacare csak a hab volt a tortan.

--
|8]

> systemds hacacare csak a hab volt a tortan.

Most hogy a systemd tette-e nyilvanvalova a tulburjanzott burokraciat, vagy az csak ratett a lapattal (de akkor mi volt az inditoja?), ez szerintem mar csak nezopont kerdese.

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

Most ez elég rosszul fog esni a piciny sérült lelketeknek gyerekek, de aki nem ír magának saját init rendszert nulláról, az csak egy kontár.

Újat írni? Hogy a fenébe, amikor a meglévő kettőt sem tudják szimultán karban tartani? :)