Lennart Poettering a nyílt forrású közösség **ggfejeiről

HUP cikkturkáló

A Red Hat alkalmazásában álló Lennart Poettering többek közt arról ismert, hogy nevéhez fűződik több, Linuxszal kapcsolatos, vitatott megoldás létrehozása. Ilyen megoldás például a Pulseaudio, vagy a sokak által legtöbbet szidott systemd.

Lennart most arról írt blogjában, hogy a nyílt forrású közösség tele van seggfejekkel. Mint írja, kapott már gyűlöletlevelet azért, mert nyílt forrású szoftvereken dolgozik. Emberek petíciókat indítanak annak érdekében, hogy fejezze be a nyílt forrású szoftverekkel kapcsolatos tevékenységeit. Nemrég emberek egy csoportja Bitcoin gyűjtésbe kezdett, hogy felbérelhessenek egy bérgyilkost, akivel megölethetnék. Ugyanazon a napon valaki idióta nótát tett fel vele kapcsolatban a YouTube-ra, emberek weboldalakat hoznak létre, hogy bojkottot szervezzenek a szoftverei ellen. Ezen kívül zaklatják az IRC-n stb.

Mint írja, ő sem szent, fiatalabb korában részt vett flameháborúkban, ahol nem maradt mindig a technikai oldalon. Mint írja, most is nyíltan beszél, de nem személyeskedik. Mint írja, nem a bazdmegeléssel van baja, hiszen ő is használ ilyen szavakat.

Úgy gondolja, hogy a nyílt forrású közösség meghatározó embereinek, kiváltképp Linus Torvalds-nak szerepe van abban, hogy egyesek így viselkednek. Linus ismert arról, hogy sokszor durván fogalmaz:

"[specific folks] ...should be retroactively aborted. Who the f*ck does idiotic things like that? How did they not die as babies, considering that they were likely too stupid to find a tit to suck on?"

A mondandóját így foglalta össze: fejétől bűzlik a hal.

Elgondolkodtató írása itt olvasható.

( uid_4656 v | 2014. 10. 06., h – 16:01 )

Szerintem a fickó kiválóan látja, hogy mi a helyzet (mondom ezt úgy, hogy nem vagyok különösebben nagy rajongója a systemd kifelé látszó részének - belülről tök jó program, de pl. a CLI-je rémesen eltér minden más program hasonló megoldásától).

Lazán kapcsolódik
Lehet, hogy Linus rossz mintáját követik, de még valószínűbbnek tartom, hogy üzletileg ellenérdekelt multi is mögötte van. Miért ne tenné? Pénze van, nem is kerül sokba, a legális lehetőség adott, és a nyílt forrású fejlesztői közösség jellege miatt támadható ilyen módszerrel.
A bitcoinos pénzgyűjtés bérgyilkosra viszont már súlyos bűncselekmény. Nagy nyilvánosság előtt, szervezetten... ez sok év letöltendő és a bíróság előtt már senkit nem érdekel, hogy csak poénnak szánták a szervezők.

( cherockee v | 2014. 10. 06., h – 17:51 )

amit csinál opensource, tehát forkolható, vagy leváltható, mégis ahelyett hogy a sok dühösködő ezt tenné, inkább megszólja, sőt, látom pár elmebeteg viccesnek tartja ha burkoltan meg akarják öletni. hasonló okokból nem igazán olvasok neten véleményeket, magyar sajtó és "kritikai" írások nagyrésze arról szól, hogy mi miért nem jó, és mennyire...emberünk próbál valami hasznosat csinálni, ami ráadásul nem kötelező, és mégis.

az pedig nekem egy új nézőpont, de jogosnak tűnik, hogy azért linus egy határozott alakja a témának, a stílusa minden csak nem korrekt (lehet úgy is kritikát kifejezni, hogy nem nevezek valakit egy halom szemétnek), de szerintem csak szítja a hangulatot, nélküle is menne a mocskolódás

( Hiena v | 2014. 10. 06., h – 20:42 )

"Hrrrmmmm..."-ahogy Yoda mester mondaná
Gyönyörű gondolatmenetek vannak az írásban. Pl. Egyetlen szép csavarral állítja be az átlagos FOSS fejlesztőt homofób rasszistának és saját magát a megértő hősnek. Ez eléggé jogvédős duma.
A másik probléma az arccal, hogy túlságosan erős a PR-je, ahhoz képest hogy mekkora szopást okozott a két olyan dolgokba is belenyúlva amibe nem kellett volna. Pontosabban nagyon rosszul nyúlt bele. A linux hangrendszerre igencsak ráférne egy alapos kipofozás, erre ő fölé húz egy réteget és innét kezdve el van intézve a dolog. Egyetlen probléma, hogy mire épp kiveszett volna az OSS (ami a maga agyhalottságaival még egész emészthető valami), végre kezdene stabilizálódni az ALSA, erre kap az egész egy újabb pofont.
A systemd fantasztikus képződmény. Épeszű ember csak bottal piszkálja és csak biztonságos távolságról, nehogy meginduljon és elszabadult monolitként agyoncsapja. Közben pont az init rendszer átláthatóságát heréli ki. És itt egy pillanatra egy kicsit a paranoiám is beindul, mert egy szűk fejlesztői csoport által kézben tartott, átláthatatlan, a bekapcsolás első pillanatától működő rendszer a nemzetbiztonsági szolgálatok álma. Melyik szektorban is érdekelt a Redhat? Oh, wait...

Szóval, popcornos téma...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Hmmm... Miért is?
Melyik cég a szállítja a legtöbb kormányzati linux disztribúciót?
Melyik cég linux disztribúcióját használják leggyakrabban kutatóintézetekben, szuperszámítógépeken?
Mekkora a részesedése a RedHat-nak az enterprise linux disztribúciók közt? (64% körül)
Mi korruptálható könnyebben? Egy monolitikus, kevés fejlesztővel rendelkező, több szinten is obfuscated szoftver vagy egy szög egyszerű, könnyen átlátható, sokfejlesztős rendszer?
Hogyan egyszerűbb új fő rendszerkomponenst benyomni disztribúciókba? Egyedi fejlesztőként, vagy egy nagy disztribúciót gyártó cég alkalmazottjaként?

Én elég sötét vagyok az IThez és a biztonsághoz, de ha adatot kéne gyűjtenem, akkor elsődlegesen hálózati csomópontokhoz és releváns adatokat tároló gépekhez próbálnék hozzáférni. Hasonlóképp egy malwaret a Linux retardált ökoszisztémájába valamelyik nagy disztribúció irányából próbálnék betolni. Pl. a systemd-t is egy pillanat alatt adaptálták az Ubuntuba, amint a Debian-osok mellette tették le voksukat. FOSS közösség, mint minden szubkultúra, kitermeli a maga celebjeit és hőseit. A szoftveres viszonylatban csapnivaló tervezés, dokumentálás és a tesztelés hiánya miatt a szoftver minőségét sokszor a mögötte álló nevek fémjelzik. És az ember már csak olyan, hogy a "nagy nevekben" jobban megbízik. Egyértelmű, hogy egy ismert név korrumpálása sokkal eredményesebb lehet, mert az ő munkája és kommitjei kevésbé kerülnek a figyelem központjába.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

állítja be az átlagos FOSS fejlesztőt homofób rasszistának

ez hol van a szovegben?

A linux hangrendszerre igencsak ráférne egy alapos kipofozás, erre ő fölé húz egy réteget

szamomra is talany, ugyan mi a banat letalapja van a pulseaudio letezesenek?

Épeszű ember csak bottal piszkálja és csak biztonságos távolságról, nehogy meginduljon és elszabadult monolitként agyoncsapja

ha a redhat atvette, akkor a centos is, es allitolag a debian is kacsintgat fele, igy hacsak nem akar valaki disztrot valtani, meg kell baratkozni a systemd-vel, meg ha szemelyes velemenyem szerint egy nagy rakas hanyas is...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Az OK, hogy valakinek nem tetszik amit csinál Poettering. Látszólag a munkaadójának megfelel. De miért kell ettől még zaklatni?

Igazából nem is kell válaszolni, tudom magamtól is. Az internet tele van féreggel, értelmi fogyatékossal, érzelmi sérülttel. Ezek a betegségeiket így vezetik le.

--
trey @ gépház

De miért kell ettől még zaklatni?

nem kell, de a jelek szerint van ra igeny. Legalabbis vannak, akik a negativ velemenyuket igy kozlik vele. Aztan hogy az Internet kikkel, mikkel van tele, az megint egy masik kerdes, aminek a topikhoz keves koze van.

Egyszeruen arrol van szo, hogy a fazon csinalt 2 dolgot, ami sokaknal kiverte a biztositekot, es aminek nemelyek (tehat nem minden elegedetlenkedo) hangot is adnak. Hogy bergyilkost kuldenek ra, meg irc-en zaklatjak, etc. az nyilvan nem megfelelo formaja a kritikanak, de valoszinuleg nem az a post mondanivaloja, hanem hogy mindenki csak bantja ot, ergo az open source (fejlesztok klubja, kozossege, whatever) az egy szar hely.

Hogy Torvalds-nak is megvan a maga arcpirito stilusa, ami masokat vagy hasonlora batorit vagy sem, ez egyelore eldontetlen, az mar biztos. Ennek ellenere a problema gyokere inkabb az, amit fentebb irtam: 2 nagy szart nyomott be nemely mainstream disztrokba. Valoszinuleg ezzel lehet osszefuggesben az, hogy "People have started multiple "petitions" on petition web sites, asking me to stop working"

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

"The Linux community is dominated by western, white, straight, males in their 30s and 40s these days. I perfectly fit in that pattern, and the rubbish they pour over me is awful. I can only imagine that it is much worse for members of minorities, or people from different cultural backgrounds, in particular ones where losing face is a major issue."

A WWSM vagy WWSMM tipikusan az angolszász jogvédők, feministák, melegjogi aktivisták szófordulata. Az ő szótárukban kb. egyenértékű kifejezés a homofób, patriarchiális, rasszistára. Erre rátesz még egy lapáttal is a második mondattal, ugyanis ez a tipikus "én is így nézek ki, de elhatárolódok tőlük" képmutató mentegetőzés, ami kisebbsség sajnáltatással folytat.

A redHat mindig is próbált valahol az üzleti linuxok Microsoftja lenni. A systemd elég jól belefér ez irányú törekvéseikbe.
A Debian maintainnerei párszor már bizonyították, hogy egy beszívott hippijével vetekedő előrelátásuk és planningjük van.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( joco01 v | 2014. 10. 07., k – 14:10 )

Csinált egy systemd-t, kit érdekel? Elég gázosnak tűnik, jobb nem használni. Engem csak az zavar, amikor [az én kedvenc disztribúcióm] mégis elkezd systemd-t használni. WTF... Ezt ki dönti el és miért? Ezek azok a fejek, akiktől bűzlik a hal. Mondjuk én nem vagyok az a típus, aki bármelyiknek is beszólna. Csak nézek értetlenül. Azt sem értem, hogy Linus eddig hogy úszta meg orrbavágás nélkül.

--

"Ezt ki dönti el és miért?"

Általában az adott disztribúció technikai vezetőtestülete. Sokszor az sem egységes. Lásd: Debian, ahol többször is nekifutottak a szavazásnak.

BTW: kinek kéne eldöntenie? Meg kéne szavaztatni a felhasználókkal? Vagy hogy?

A felhasználónak ott a lehetősége, hogy válasszon, váltson ha valami nem tetszik.

BTW: pl. a Pulseaudio-val kapcsolatos rinyálást nem értem. A rendszerem állítólag több éve tartalmazza. Én még azt sem tudtam, hogy benne van. Probléma nélkül használom. Laptopon is, asztali gépen is.

--
trey @ gépház

Pulseaudióról ez jut eszembe. De nem érdekel, mert desktopnak nem Linuxot használok. Egy audió alrendszerről nem tudom elképzelni, hogy olyan rossz legyen, mint a systemd. A Pulseaudio egy plusz választási lehetőség, ellenben a systemd sok szempontból az ellentéte, amikor a függőségeként hoz magával egy csomó mindent, és vagy le tudom tiltani plusz munkával, vagy nem. A Debian addig jó, amíg választhatok nem systemd-t, és amíg van kb. annyi ellenérv, mint érv, ezen nem is szabadna változtatni, és addig nem is fogok siránkozni. De szerintem van olyan disztró, ahol nem vállalják az evvel járó plusz munkát, és eldöntötték, hogy systemd, és akinek nem tetszik, az mehet máshova, csak azok azért megszívták egy kicsit. Az már nagyon Windowsos irány, hogy felraktunk egy böhöm nagy programcsomagot, ami mindent tartalmaz, és olyan bonyolult, hogy jobb, ha nem is érdekel, hogy mi van mögötte. Egy szerveren én szívesen elszüttyögök, és pl. időről időre törlöm a fölösleges csomagokat.

--

Ez igazából csak egy rejtett subscribe, de ha már erre járok.

Mégis mi a gond a systemd-vel? Hogy az ernyőprojekt összefog több alprojektet, amik 1-1 funkciót látnak el és ezeket többnyire egybe csomagolják a disztribútorok?

Szerk.:

De szerintem van olyan disztró, ahol nem vállalják az evvel járó plusz munkát, és eldöntötték, hogy systemd, és akinek nem tetszik, az mehet máshova, csak azok azért megszívták egy kicsit.

Jah, igen. Az alkalmazáskészítőknek a jó anyjukat, hogy szeretnének használni egy nem a 60-as éveket idéző rendszert, a csomagoló munkásoknak meg a jó anyjukat, mert lusták supportálni a 60-as éveket idéző rendszert. Értem.

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

~30 éve megszokott dolgot hajít ki a 3.14csába,nem igazán átlátható működéssel, és nem igazán tisztán látható (sok esetben nem is valós) előnyökért.

És ha már ilyen egyszerűen kicserélnek egy vitális komponenst, a ifconfig és bandája (ami sok-sok éve definiáltan deprecated) is eltűnhetne már az örök bitmezőket elfedő devnull-ban.

~30 éve megszokott dolgot hajít ki a 3.14csába,

Mint sokan mások, akik felismerték, hogy a 30 éve megszokott dolog ma már nem működik. Gondolom te a mai napig fekete-fehér szovjet TV-n dolgozol Commodore 16-on.

nem igazán átlátható működéssel,

Dokumentáció, forráskód. Ott van mind.

és nem igazán tisztán látható (sok esetben nem is valós) előnyökért.

Azért a feature listán nem kell lemenni az advanced stuffig, hogy láthatóak legyenek az előnyei, mind szerver (pl. szolgáltatások követése... mármint, hogy létezik ez a feature és nem kell hozzá külön alrendszer), mind desktop területen (pl. on-demand [socket/d-bus] indítás).

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

Gondolom, fiatalabb, vagy, mint 30 év, és te is azért működsz még :-P Attól, hogy valami régóta működik, attól még nem biztos, hogy sz@r. Te gondolom semmilyen C-ben írt programot nem hasznáűlsz, mert a C-nyelv több, mint 40 éves, ha jól számolom...

Gyakorlatilag mindegyik systemd fícsörre volt/van a systemV inithez illeszthető értelmes megoldás, igaz, pöcseleng szerint lehet, hogy se@@fejek írták azokat. Mások szerint meg nem...
Ha pl. a "szolgáltatások követése" dolgon azt érted, hogy kidöglés esetén csináljon valamit, arra az init önmaga is képes - igaz, tudni kellene használni (van hozzá doksi, ~30 év alatt polcfolyóméterben is egészen sok összejött, és bármelyiket is húzom elő, használható). De ha az kevés, akkor például ezer éve ott volt/van például a daemontools - igen, DJB is "érdekes" személyiség, ezt nem vitatom :-P

Gondolom, fiatalabb, vagy, mint 30 év, és te is azért működsz még :-P

Igen, az emberi biológia PONT olyan gyorsan változik, mint az IT. Pl. 30 évvel ezelőtt a föld lakossága olyan 30 ezer volt, egy ember élete felbecsülhetetlen érték volt, és ha valaki meghalt, akár egy ország bankrendszere omolhatott össze. Ma meg ugye vagyunk 1 milliárdan, és 3 évenként visszük ki a pusztába lelőni a már "kiöregedett" embereket.

Gyakorlatilag mindegyik systemd fícsörre volt/van a systemV inithez illeszthető értelmes megoldás

Igen, és mennyivel jobb az, hogy olyan funkciókhoz, ami azért jogos elvárásokat fogalmaz meg (például hogy legyenek az alkalmazásom függőségei elindítva, mire indítanák...), legókból össze kell pakolászni egy Frankenstein szörnye típusú cuccot, minden egyes deploynél. Amit legalább rohadt nehéz debugolni, cégenként/helyenként eltérő lesz [-> rohadt nehéz debugolni, mert először meg kell ismerned a helyi sajátosságokat], stb.

Ha pl. a "szolgáltatások követése" dolgon azt érted, hogy kidöglés esetén csináljon valamit,

Nem, az alatt azt értem, hogy ha lekérdezem egy szolgáltatás státuszát, akkor ne egy init script hazudja a pofámba, hogy "szerintem halott, bár pid fájl még van, passz" vagy kelljen process listákat néznem.

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

Igen, és mennyivel jobb az, hogy olyan funkciókhoz, ami azért jogos elvárásokat fogalmaz meg (például hogy legyenek az alkalmazásom függőségei elindítva, mire indítanák...), legókból össze kell pakolászni egy Frankenstein szörnye típusú cuccot, minden egyes deploynél. Amit legalább rohadt nehéz debugolni, cégenként/helyenként eltérő lesz [-> rohadt nehéz debugolni, mert először meg kell ismerned a helyi sajátosságokat], stb.

a fentiek szerint a linuxot sajnos nem neked talaltak ki. a systemd-nel nem kell semmit megtanulnod, ugye? muxik oszt jo' van. a linux soha nem volt ilyen, es a dolgok allasa szerint egy darabig nem is lesz. nem, a systemd-vel sem.

Nem a "megtanulás" a lényeg (jelentsen ez akármit), hanem az elérhetőség.

Ezt a triviális marhaságot (amit még a Windows is tud, az NT óta...) ahány disztró, annyi módon kell beállítanod - mint fejlesztő. Mint üzemeltető, a scripteket kell szerkesztened, ha a fejlesztővel/disztribútorral eltérő függőségi gráfban gondolkozol - és utána követned a disztrib/upstream scriptjeinek a módosítását.

Meg lehet csinálni, csak több effort 1) a fejlesztőnek [ha egyáltalán foglalkozik init scriptekkel], 2) a csomagolónak [többnyire saját gyártású az init script, security, attack surface stb.] és eltérő igényeknél 3) az üzemeltetőnek (módosítás, követés, dokumentálás stb.)

--

És ez csak egy volt azokból a konfigurációs lehetőségekből, amiknél ugyanez a gondolatmenet végigjátszható.

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

nekem a fo problemam a systemd-vel az, hogy nem illeszkedik az altalam kovetni probalt 'filozofiaba': legyen kicsi, egyszeru, gyors es mukodjon. a systemd ezek kozul talan csak az utolsot teljesiti, bar a forumokat elnezve ezzel is akadnak problemak.

az ketsegtelen, hogy a feature-ok kozott van sok jo dolog ( mar csak egy szamologep kell bele es keszen is vagyunk :) ) amik segitenek akar a fejlesztonek akar az uzemeltetonek, de ha ezert cserebe az az ar, hogy gozom sincs meg nagyjabol sem, hogy hogyan mukodik a hatterben, akkor en ezt az arat nem vagyok hajlando megfizetni. eppen ezert kezdtem el anno gnu/linux-al (nem kivant torlendo) foglalkozni, mert lehet(ett) latni, hogy mi hogyan mukodik (ha az ember akarja. ha nem akkor mind1). sejteni velem mi volt a cel a systemd-vel kezdetben (szokasos felsorolas: service-ok kovetese, eroforrasok kezelese stb.). ezek mind jol hangzanak. azonban amikor mar egy ntp-client-et is beletolnak a rendszer egyik legalapvetobb process-ebe, akkor igencsak el kellene gondolkodni, hogy ilyen filozofiaval vajon milyen alapveto tervezesi problemak fordulhatnak meg elo?
az ntp csak egy pelda volt. de mi koze az init-nek (systemd-nek) a halozathoz? hatha elhasal egy szarul megirt wifi/eth/infiniband stb. driveren? itt konkretan enterspajz kornyezetre gondoltam es infiniband-es rossz tapasztalataimra.

nem vagyok fejleszto, uzemeltetek. nekem nem csak az a fontos, hogy minden mukodjon, hanem az is hogy _jol_ mukodjon. az ido penz: minel egyszerubb valami annal kevesebb hiba fordul elo benne, annal kevesebb interakciot kovetel meg a reszemrol es igy keveset is kell vele foglalkozni. egyszer idot kell tolteni vele, hogy osszedrotozzam a 'frankeinsteint'? ha tobbet nem kell piszkalni cserebe akkor ez nekem pont eleg. en 16 eve a fentiek szerint probalkozok es eddig nagyjabol minden rendben volt. tudtam, hogy mit varhatok el es altalaban azt kaptam. a systemd ezek ellen dolgozik. a hiba bennem is lehet, elvegre 18 ev nagyon hosszu ido, de probalom objektivan szemlelni a kerdest. ennek ellenere nem szimpatikus a dolog.

azonban amikor mar egy ntp-client-et is beletolnak a rendszer egyik legalapvetobb process-ebe

Nem a PID1-ben fut, egyszerű service-ként, mint random NTPd.

az ntp csak egy pelda volt. de mi koze az init-nek (systemd-nek) a halozathoz?

LSB-ben is van: http://refspecs.linuxfoundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core…
És pl. az, hogy ha egy service-t beállítasz, hogy egy interface-n figyeljen, akkor nem árt, ha már él az az interface, amikor próbál bind-olni rá (EADDRNOTAVAIL).

hanem az is hogy _jol_ mukodjon. ... minel egyszerubb valami annal kevesebb hiba fordul elo benne

Akkor neked ideális a systemd: a SysV init elve, hogy ő nem csinál semmit, az init scriptekre bíz mindent: vagyis a bonyolultságot "kitolja" egy réteggel kívülre, ezzel rengeteg kód duplikációt, baromi hosszú shell scripteket készítve. Egy dolgot csinál (ELINDÍTJA a szolgáltatásokat), de azt nem jól.
A systemd (és itt most nem az ernyőprojektről, hanem a szolgáltatáskezelőről beszélek csak) fogja ezt a bonyolultságot, egy helyen implementálja - egy dolgot csinál (MENEDZSELI a szolgáltatások), [nemírokvéleményt].

egyszer idot kell tolteni vele, hogy osszedrotozzam a 'frankeinsteint'?

Neked egyszer időt kell töltened vele, aztán ha ott hagyod a céget, akkor az utódod odamegy, és az első pár hétben azt próbálja majd megfejteni, hogy mi hogyan függ össze (lehet csak annyi lesz, hogy elolvassa a dokumentációt, amit ott hagysz, lehet, hogy könyékig fog a scriptekben turkálni, csak hogy megértse a működését). A systemd technikailag nem veszi el ennek a lehetőségét (simán használhatsz "tiszta" init scripteket, vagy unit fájlokat, amik scripteket indítanak), csak egy standard eszközkészletet is ad mellé.

Rövid off-topic történet a napokból: a napokban írtam egy cuccot, webdav-on fájlfeltöltés, egy backgroudn service értesítést kap minden fájlról, aztán leindexeli. Szokásos fájlokra az indexelés tovább tart, mint a feltöltés, úgyhogy szépen queue-ba kerülnek az elemek, aztán egyesével kerülnek feldolgozásra - ami több, mint egy magot simán képes megenni [néhány része több szálon fut, a többi egyszálú]. Egy két magos VM-en emiatt a webdav sebessége visszaesett, mert nem kapott elég CPU időt az apache. Egy magra átlőve az indexelőt, szépen működik; SysV init-tel az init scriptbe be kellett volna tennem egy taskset hívást az init scriptbe, így más környezetben (ahol több mag is van) visszafogott teljesítménnyel futott volna. systemd-vel egy kiegészítő konfigfájlban (vagyis nem adtam erre default-ot!) egy CPUAffinity és meg van oldva - így a "végfelhasználó" nincs rákényszerítve, hogy használja, viszont egy ilyen bekezdésben ezt dokumentálom, és ha akarja, használja.

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

Nem kell baromi hosszú scripteket írni. Aki ilyet csinál, az nem tud scriptelni, nem tud élni a meglévő lehetőségekkel, eszközökkel. Midnen ott van néhány könyvtárban, szimpla fájlkezelő parancsokkal matathatóan.
Az init is képes menedzselni az egyes szolgáltatásokat,legalább is alapszinten - man inittab. De erre a feladatra elég régóta léteznek önálló, jól dokumentált, megbízható megoldások.

"be kellett volna tennem egy taskset hívást az init scriptbe" Két gyors megoldás: egyrészt le tudod kérdezni, hány mag van, és annak megfelelően paraméterezni a taskset hívást, de ha ez nem megy, akkor konfigurálhatóan (például /etc/sysconfig/fooo) megadod a paramétereket, és azt használja a scripted.

Mondom, illene ismerni a meglévő eszközöket...

Nem kell baromi hosszú scripteket írni.

CentOS 6, 31 db. init scripttel: 


cat /etc/init.d/* | wc -l
5196

Ebből 812 az, ami meg van közöttük osztva (/etc/init.d/functions)

Két gyors megoldás:

Le tudom kérdezni, és dönthetek a sysadmin HELYETT - ahelyett, aki ismeri a rendszerét, mind HW mind SW téren. Vagy igen, csinálhatok rá rendszerfüggő sysconfig/defaults fájlt, amivel annyit értem el, hogy aktív, futó kódba tettem be két KONFIGURÁCIÓS direktívát.

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

Nem mindenki tud jól scriptet írni. Linuxos körökben elég sok baromsággal lehet találkozni. Ja, 68 script, 10459 sor, ebből érdemi tartalom (egrep -v "^#|^$") 7606. De ha belenézek, akkor bőven lehetne belőle húzni.

A systemd esetén is kell valahova egy beállítás, csak azt nem te kezeled (sőt, nem is tudsz róla), a scriptelésben meg rajtad áll, hogy hogyan valósítod meg.
Az előbbi egy nem hordozható megoldás (csak systemd-vel műx), az utóbbi meg scriptestől-beállításostól együtt önállóan is életképes.

Akkor neked ideális a systemd: a SysV init elve, hogy ő nem csinál semmit, az init scriptekre bíz mindent: vagyis a bonyolultságot "kitolja" egy réteggel kívülre, ezzel rengeteg kód duplikációt, baromi hosszú shell scripteket készítve.

Csak a kód-duplikációra: ha jól van megtervezve, akkor nincs kód-duplikáció, nézd meg pl. a FreeBSD-ben levő initszkripteket.

Köszi, ez egy nagyon jó példa - tényleg nagyon szép tiszták a scriptek. De: mi a különbség aközött, hogy kihasználod a run_rc_command egyik szolgáltatását (teszem azt chroot - VALAHOGY beállítasz hozzá env változókat), és aközött, hogy kihasználod a systemd egy szolgáltatását (teszem azt, chroot). Az egyik szép tiszta, mert shell, a másik bloated szar, mert C (vagy mert többet is tud, mint egy chroot hívás)?

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

Rövid off-topic történet a napokból: ...

tenyleg erdekel, hogy ez mitol lesz automata, ha beirod hogy 'cpuaffinity = 1'? probaltam utanaolvasni, de nem talaltam olyan leirast ami emlitette volna hogy automatan a meglevo cpu-szam fuggvenyeben allitja be. ettol meg persze lehet ilyen.
ha igazak a fentiek, akkor csak eggyel odebbtoltad a konfiguraciot, raadasul egy olyen eszkozt hasznalva ami nem minden linux-ban fordul elo. sysv init-ben is megoldhato mint irtak masok, csak a konfiguracios beallitas helye valtozik. az, hogy melyik file-ban kell az 1-est atirni 2-esre szerintem teljesen mindegy, csak a sysv inites megoldas kb. minden linuxon (es jonehany unixon) is hasznalhato.

systemd+net - elfogadom, hogy igazad van. ahogy nezegettem vegulis egy butitott 'network manager' vagy ifupdown funkcionalitassal bir a systemd-networkd. plusz ad valahogyan informaciot arrol is, hogy tud-e majd bindelni az inditando service.

Pont ez, hogy nem automata. Hanem egy helyen, a specifikus környezetre (tehát overrideolva a service fájlt, nem felülírva) határoztam meg konfigurációt.

Kicsit több változik, mint a konfig helye (felelősségi körök és szabadsági szintek), mert SysV-nél nem beszélhetünk konfigról: ott (még a sysconfig, defaults, akármi is) futtatható kód van. Ami ha nincs felkészítve pl. a cpu affinitás állítására (mert a fejlesztő, disztribútor, mindenki úgy gondolta, hogy nem kell), azt jelenti, hogy az üzemeltetőnek - még ha csak shell script is - futtatott kódban kell módosítania. És utána ezt a módosítást lekövetni, akárhányszor bármelyik upstream lépcsőnél változik az init script. Egy override-olt service fájlnál ez nincs meg, mert ott annyit és csak annyit módosítasz a konfiguráción, amit úgy gondolsz, hogy kell - ha bármi más változik upstream (pl. más lesz az executable neve), a te és az ő beállításaik is élni fognak.

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

ez valoban jol hangzik, meg ha nem is automata ahogy eloszor gondoltam.
meg mindig vannak ketsegeim a systemd mukodesevel es hasznossagaval kapcsolatban, de akar mukodhet is a dolog. ha lecsillapodik korulotte a hype akkor kiderul, hogy mennyire lehet hasznalni/kihasznalni.
meg az is lehet hogy teljesen jo a dolog, de valamiert kihatralnak mogule vagy el sem kezdik hasznalni.

> meg mindig vannak ketsegeim a systemd mukodesevel es hasznossagaval kapcsolatban

Lehetnek, de azért tessék észrevenni, hogy a disztrók végül felsorakoztak mögé.

A disztrók készítői a init folyamatot sokkal jobban ismerik mint közülünk bárki. Aki azt hiszi, hogy ismeri, az csak téved. A SysV init egyszerűnek tűnik, de valójában bonyolult, a scriptek és azok együttműködése teszi azzá, olyan mélységben szövik át a unix/linux mechanizmusok amilyen mélyre legtöbbünk le se ásott soha. Rengeteg kompromisszum és megoldatlan kérdés van, de ezt már sokan megírták, nem megyek bele.

Azt véletlenül sem feltételezi senki, hogy a disztrók készítői jól ismerik a problémáikat és a lehetséges megoldásokat és nem pusztán azért cserélik a SysV initet hogy jól kibasszanak a felhasználóikkal..?

Szerintem a disztrók azért adnak systemd-t, mert az egyszeri usernek ez így jó, de közben mindenki tudja, hogy vannak negatívumok is. A sok rossz közül a kisebb rosszat választják. Aki a mellékesen behozott negatívumok miatt károg, az szerintem jogos. Elhiszem, hogy milyen über király init rendszer a systemd, csak az a sok sallang ne lenne benne, ami egyeseket zavar (lásd uselessd), és akkor eljönne az ígéret földje.

--

Anno talán elsőként váltott az Arch, akkor kicsit felhúztam a szemöldököm, hogy ez jó lesz-e nekem. Semmi negatívumal nem találkoztam azóta sem, de pozitívummal igen: gyorsabb lett az init, előbb áll fel a rendszer. Egyszerű, egységes szintaxissal tudok szolgáltatásokat kezelni (persze a klasszikus init scriptek többsége is egységes volt, de nem mindegyik) Ezt megtehetem akár GUI-val, ha kedvem tartja. Ráadásul ezt a GUI-t nem egy DM fejlesztői, hanem a systemd fejlesztői készítik, így nem gnome/kde/stb management tool-t kell keresnem. Hirtelen ennyi jut eszembe, teszem hozzá én elsősorban desktop user vagyok, ehhez tudok hozzászólni.
Lehet ontani a negatívumokról szóló véleményeket, csak ha ezek a negatívumok a gyakorlatban nem tapasztalhatók, akkor kit érdekel? A szakmai vitákat meg megfutották a fejlesztők és a disztribútorok, kár időt fecsérelni a spanyolviasz újrafeltalálására.

Ne felejtsünk el két tényt:
- az udev (ami azért elég fontos dolog) beolvadt a systemd-be
- pl. a gnome3-nak a systemd függősége lett (azaz kell a gnome3? akkor kénytelen vagy systemd-t használni)

(az utóbbi miatt próbálkoznak a systemd emulálására BSD berkekben)

Tehát nagyon úgy tűnik, egyre kevésbé lesz a systemd megkerülhető, gondolom, ezt a disztrók fejlesztői is felismerték.

azt azert ne felejtsuk el hogy a gnome3 lete vagy nem-lete az egyik leglenyegtelenebb dolog szerveren.
desktopon meg aztan teljesen mindegy hogy upstart, systemd, sysvinit vagy az a pythonban irt init-script fut amit tegnap talaltam az interneten. valamint a linux-hasznalata nem desktopon jellemzo szerintem. (nem mellesleg gnome3 != grafikus felulet)

az udev erdekes kerdes. az udev elott is volt elet. kicsit kenyelmetlen volt amikor bevezettek, aztan megszoktam, most mar hianyozna. viszont lehet forkolni es systemd nelkul tovabbvinni. ha lesznek elegen a systemd-ellenesek akkor gondolom ez is megtortenhet.

A tendenciára gondoltam, hogy már "egyszerű" programok is igénylik a systemd-t, pl. a gnome3 is (hirtelenjében ez ugrott be, lusta voltam többet keresni). Gondolom, vannak/lesznek más olyan programok, amelyek már szerver-alkalmazások, és igénylik a systemd-t (és mondjuk nemcsak a benne levő udev miatt, amit talán még meg lehet oldani az utálatos systemd nélkül is). Nem úgy értettem, hogy a gnome3 miatt kezd eléggé megkerülhetetlenné válni.

Udev: nyilván előtte is volt élet, és ha leváltják, utána is lesz élet. De most már nyilván szerves részévé vált a linux-rendszereknek. Viszont a forkolással két gond (mindenféleképpen) van: mindig le lesz maradva, illetve ha az "oridzsi" udev egyre jobban belegabalyodik a systemd-be, akkor egyre nehezebbé válik forkot karbantartani (hogy kellően friss legyen és ki legyen belőle gyomlálva a systemd-ragaszkodás).

remelhetoleg nem kerul sor arra, hogy pl. egy apache depend-eljen a systemd-re... mondjuk attol hogy en ezt nem szeretnem ez meg siman megtortenhet.

udev: esetleg elofordulhat az, hogy a fork fog jobban fejlodni mint a systemd-vel osszegyurt valtozat (ld. libreoffice vs openoffice bar ez kisse mas tortenet)

tavozz tolem satan :)

idovel ki fog derulni, hogy a 'nagyok' merrefele mennek, mi lesz a fo csapasirany. sot, mar el is indultak a systemd fele. ha ez lesz a tendencioa tovabbra is akkor ezt kell megtanulni hasznalni, egyuttelni a hulyesegeivel. (bar ettol nem lennek maradektalanul boldog)

Fejlesztőként adott rendszerre kell dolgoznod, és az ottani kötöttségeket kell követned. Nekem elég sok egyedi szolgáltatást kellett sysvinit alá berakni, akár úgy is, hogy alapértelmezetten "rossz helyen" volt, de nem jelentett nehézséget, sőt, frissítések során sem volt vele probléma.

Nem tudom, a systemd esetén ezt hogyan kezeled - gondolom, ott a systemd kitalálja, hogy fejlesztőként milyen más függőségi fában gondolkodsz. vagy nem...?

ott egész pontosan csinálsz egy unit.type.d könyvtárat a /etc/systemd/system alatt (pl. freeradius.service.d), benne számozott .conf fájlokkal (pl.: /etc/systemd/system/freeradius.service.d/90-ko-neki-a-postgres-mert-abba-vannak-a-userek.conf 


[Service]
Requires=postgresql.service

(disclaimer: fejből, itt pötyögve)

Daemon-reload, oszt jónapot.

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

Azaz két jól irányzott link helyett plusz fájl :-) Gondolom "visszafelé" is kezeli a dolgot a systemd, azaz ha leállítom a pg-t, akkor a freeradius is megáll, és ha eztán elindítom a pg-t, akkor a freeradius-t is automatice elindítja. Mert ez jó _lehet_, bár ha épp nem akarom elindítani a pg restart után közvetlenül a freeradius-t, csak akkor,a mikor a pg-t végigellenőriztem, hogy jól működik...

Azaz egy service freeradius stop -ot spórolt csak... És azért kéne elindítania, mert a leállítás nem explicit utasításra, hanem függőség miatt történt, ergo ha a függőség "megjavul", álljon vissza az eredeti állapot. Oké, workaround-ként pg leállít, majd freradius indít :)

Közben játszottam egy kicsit: konfig nélkül kihúlló service-től függő cuccokat nem gyilkol le, ahhoz egy külön unit-ot indíttatni kell vele az OnFailure-rel, ami mondjuk conflictol a leállítandó service-ekkel; ezt most benéztem.

Egyébként meg döntsétek már el, hogy akkor most jó, ha automatikusan csinál valamit, vagy nem (az egyik fő érv a systemd ellen mindig az, hogy mi az az - amúgy konfigurálható - működés, hogy megadott exit kódoknál simán újraindítja)

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

legyenek az alkalmazásom függőségei elindítva, mire indítanák...

egy SysV stilusu kornyezetben az Sxx linkekkel szepen meg tudod hatarozni, hogy mi mikor induljon el.

ha lekérdezem egy szolgáltatás státuszát, akkor ne egy init script hazudja a pofámba, hogy "szerintem halott, bár pid fájl még van, passz" vagy kelljen process listákat néznem.

es ha a script a /proc/<pid>/status-t nezi meg, az jo?

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Mindenhol race condition van, a hatterbe ugro daemonok kozotti fuggosegek kezelhetetlenek (sleep xxx es hasonlo "megoldasok" kellenenek hogy megvarjak egymast). A pid meglete keves, a /proc alatti olvasgatas kozben ujra felhasznalhatja a rendszer a pidet es maris mellement az ellenorzes, rosszabb esetben a processz leallitasa is csunyan lyukra fut. A sysvinit funkcionalitasa szerintem manapsag edeskeves, de akinek eleg, az legyen boldog vele - es ha nem akarja megismerni a systemd-t, akkor ne tegye - de legalabb ne trollkodjon, mert a hozzaszolasaibol latszik, hogy fogalmatlan.

Mindenhol race condition van,

es ezt igy hogy? Biztos elcsesztem valamit, hogy sleep nelkul sem sikerult az inditas soran ilyet osszehozni.

a /proc alatti olvasgatas kozben ujra felhasznalhatja a rendszer a pidet es maris mellement az ellenorzes

ennek szerinted mennyi az eselye? Ugy ertem, hogy epp akkor hal meg a demon, amikor a statuszat nezed / le akarod allitani, de a kernel meg ujra kiosztotta azt a pid-et egy vadidegen uj processznek?

es ha nem akarja megismerni a systemd-t, akkor ne tegye - de legalabb ne trollkodjon

meg jo, hogy nem ram gondoltal...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

"Ja, a systemd !Linux környezetben hol fordul elő?"

A /proc/PID/cmdline !Linux környezetben hol fordul elő?
Segítek, Linux-specifikus az is...de hát egy nálam okosabb embert idézve: " ismerni kell az eszközöket és a lehetőségeket."

Egy nagyon szép példa az interopra az OS X. Szabvány UNIX rendszer, nem úgy, mint a Linux, mégsincs benne procfs. Szóval lábon vagy lőve szabványos környezetben, ha procfs-re alapozod a scriptjeidet.

Ha systemd, akkor -most még- Linux. Ha Linux, akkor procfs is van. Ha ilyen helyzetben szeretnéd megtudni, hogy az 12345-ös PID-del mi fut, akkor kényelmesen turkálhatod a procfs-t. Ha meg nem Linux, akkor is van lehetőség a processzek adatainak a lekérdezésére - ahogy a ps parancs is csinálja :-P

Csakhogy ezek megint platformfuggo dolgok lesznek.

Arra akartam ramutatni, hogy az az erv, hogy a systemd Linux-specifikus, pont ugyanolyan erv, mint hogy hasznaljunk /proc/PID/cmdline-t. Az sem jobb ilyen szempontbol, mert Linux-specifikus.

Az, hogy az egyes platformokon a ps hogyan van implementalva, az mas kerdes, kotve hiszem, hogy mindenhol ugyanugy = azaz lehetoseg van a processzadatok lekerdezesere, de ez a lehetoseg platformonkent mas.

A kérdés az volt, hogy a systemd kontra initscript esetben hogy oldom meg, hogy egy szolgáltatás fut vagy sem kérdésre ne egy pidfájl és az abban szereplő számmal azonos pid-ű processz létének a vizsgálata legyen a válasz. Ahol van procfs, ott azt lehet használni, ahol nincs, ott meg azt a módszert, amivel meg lehet győződni arról, hogy az 12345 pid-hez milyen folyamat tartozik.

Egy megnevezni nem kivant penzugyi multinal neha megborult egy adatbazis, merthogy valami kilotte egy threadjet. Erdekes volt lenyomozni, mi is tortent, es a vege banalis lett: egy felugyelo program SIGTERM utan ellenorizte, megvan-e meg a leallitando processz, es ha igen, kuldott egy SIGKILL-t is. Ez teljesen megszokott dolog, csak manapsag mar problema azt hinni, hogy a PID nem hasznosulhat ujra, ez ha ez bekovetkezik, akkor az igy jaras esete forog fenn - ebben az esetben epp az adatbaziskezelo egyik uj threadje volt a szerencses nyertese a SIGKILL-nek. Lehet, hogy csak en vagyok keves hozza, de nem latom, hogy pl. cgroup nelkul hogyan is lehetne eliminalni ezt a szituaciot.

+1

Hogy otthon lerohad-e, az nagyjából még mindegy is lenne, de egy pénzt termelő production rendszernél már nem vállalnám a kockázatot.

Nálunk van olyan rendszer, hogy ha az elpusztulna, akkor (közvetve ugyan) emberek százezrei kezdenének anyázni, csak Magyarországon.

Tehát megnézem, hogy a /proc/$(cat pidfile)/cmdline egyezik-e azzal, aminek az állapotát le akarom kérdezni, és ha igen, akkor azt mondom, hogy "fut", ha nem, akkor nem. Ha az ellenőrzés és az "echo megy" között kipusztul, akkor így jártál, valóban. A leállításra dettó - viszont erre sok-sok éve van már megoldás, olyan, ami a kiss elvet nem b@cca telibe. És működik. Jól.

villaval (ha mar fork, hehe) az ember nem eszik levest. De a problema ennel a gyakorlatban osszetettebb szokott lenni, es nem vagyok maradektalanul biztos abban, hogy a systemd kepes kezelni mondjuk egy olyan hibat, hogy x forkolo demon azert hal meg, mert nem eri el a masik gepen levo mysql szervert. Szoval tied a pont, hogy a systemd kepes egy forkolo cuccot is ugyesen felugyelni, de ketseges, hogy a gyakorlatban mire elegendo ez...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Miért jó ezt a forknyilvántartó funkciót minden forkoló programba külön-külön belefejleszteni? Nem lenne jobb, ha erről gondoskodna a rendszer és a programokban külön-külön nem kéne? Szerintem jobb lenne. És mások szerint is, ezért is tudja pl. a systemd (de más hasonló megoldás is van) egy CGroup-ba tenni az összetartozó processzeket, és a CGroup alapján kinyírni őket (már ha kell):

[root@oops ~]# systemctl status postfix
...
CGroup: /system.slice/postfix.service
├─ 2503 /usr/libexec/postfix/master -w
├─ 2561 qmgr -l -t unix -u
└─18791 pickup -l -t unix -u
...

(Ezzel analóg egyébként az a nézet is, aminek alapján bizonyos emberek szent és sérthetetlen alapegységnek tartják az 1 db számítógépet. Pedig valójában 1 db számítógépnek semmilyen jelentősége sincs, az általa biztosított szolgáltatás(ok)nak van jelentősége. Másképpen érdemes gondolkodni. Lásd még a kérdés, hogy mi az a "server" - egy darab vas, amibe bele lehet rúgni, vagy valami, ami szolgáltatást nyújt?)

A hardver az IT azon része, amibe bele lehet rúgni. A cgroup alapján kinyírni esetében milyen sorrendben történjen meg a "szép" leállítása az egyes folyamatoknak? Ezt biza' az adott alkalmazás tervezése során kell meghatározni, és a megfelelő folyamatnak elvégezni a takarítást, ha épp azt kérik tőle.

Kivéve, ha épp összeomlott a "megfelelő folyamat". Vagy ha tervezés ide vagy oda, nem megoldható, hogy ő löjjön le a processz fában valamit (mert pl. ő ugyan csak egy shell scriptet indított, aminek éppen van 8-10 gyereke...)

Stop-nál pedig tiszta sor, lefuttatja az ExecStop-ot, amivel az a contract, hogy amikor annak a futása befejeződik, akkor már tekinthető leállítottnak a service, és a maradvány írható - bármi sorrend nélkül.

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

Igen, plusz még az is benne van a dologban, hogy az ExecStop futtatása után is szabályozható, hogy hogy történjen a maradék processzek lelövése:

KillMode=
Specifies how processes of this unit shall be killed. One of control-group, process, mixed, none.

If set to control-group, all remaining processes in the control group of this unit will be killed on unit stop (for services: after the stop command is executed, as configured with ExecStop=). If set to process, only the main process itself is killed. If set to mixed, the SIGTERM signal (see below) is sent to the main process while the subsequent SIGKILL signal (see below) is sent to all remaining processes of the unit's control group. If set to none, no process is killed. In this case, only the stop command will be executed on unit stop, but no process be killed otherwise. Processes remaining alive after stop are left in their control group and the control group continues to exist after stop unless it is empty.

Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=). Optionally, this is immediately followed by a SIGHUP (if enabled with SendSIGHUP=). If then, after a delay (configured via the TimeoutStopSec= option), processes still remain, the termination request is repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option). See kill(2) for more information.

Defaults to control-group.

Nem nagyon van ötletem, hogy mire lehetne még szükség egy közelítőleg jól megírt démon esetében...

A függőségek kezelése egyszerű: kétjegyű számokat 6-7 éves gyerek is képes nagyság szerint sorba rakni. Ha a mütyürke függ a tütymütytől, akkor a tütymüty-öt indító S##tütymüty névben a szám legyen kisebb, mint az S##mütyürke névben. A sorrend egy darab "ls" parancs kiadásával ellenőrizhető. Ha neked a sysvinit "Frankenstein szörnye", akkor mi a véleményed a BSD-s initről?
Elég sok esetben kellett "helyi sajátosságokat" feltérképezve komolyabb rendszereket vizsgálgatnom - nem kellett hozzá rettenet sok idő, hogy átlássam, mit, hogyan raktak össze - igaz ehhez pontosan ismerni kell az init működését. Sajnos nagyon sok linux-only emberke esetén ez az ismeret nem,hogy hiányos, egész egyszerűen nincs meg - lásd "init script hazudja a pofámba, hogy...". Aki ilyet elkövet, az lusta, trehány, alkalmatlan arra, hogy a "service foo status" avagy a "/etc/init.d/foo status" parancs kiadásakor lefutó kódot elkövesse. Ugyan olyan trehány, mint aki egyenlőségjelet tesz a "pingre válaszol" és a "működik a szerver" között. 


                1)
                        echo $"${base} dead but pid file exists"
                        return 1
                        ;;

A legnagyobb enterspájz linux disztribútort le "lusta, trehány, alkalmatlanozni" legalábbis bátor tett. (/etc/init.d/functions @ CentOS 6)

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

"A függőségek kezelése egyszerű: kétjegyű számokat 6-7 éves gyerek is képes nagyság szerint sorba rakni."

Ez teljesen jó megoldás, manapság a számítógépekben úgy is egyre kevesebb és egyre gyorsabb CPU magok vannak. Hm, várjunk csak...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, és mennyivel jobb az, hogy olyan funkciókhoz, ami azért jogos elvárásokat fogalmaz meg (például hogy legyenek az alkalmazásom függőségei elindítva, mire indítanák...), legókból össze kell pakolászni egy Frankenstein szörnye típusú cuccot, minden egyes deploynél. Amit legalább rohadt nehéz debugolni, cégenként/helyenként eltérő lesz [-> rohadt nehéz debugolni, mert először meg kell ismerned a helyi sajátosságokat], stb.

Nekem úgy tanították, ez a UNIX filozófia: egyszerű, egy feladatot jól tudó programokat lehet igény szerint kombinálni, és adott esetben komplex rendszert összehozni belőlük.

Nekem tetszik, de bizonyára van, akinek nem. Ezeknek persze nem kötelező ilyen logikára épülő rendszert használniuk.

Igen, és mondjuk awk-ot nem használsz, mert a funkciói helyettesíthetőek más programok egymásba kapcsolásával, igaz? Ill. gondolom nincs httpd a gépeiden, mert az gyakorlatilag csak egy wrapper valami TCP socket felett, és közelebb áll a unix elvhez, ha inkább inetd-ből és egy raklap shell scriptből összeollózod.

A Unix filozófia arról semmit nem mond, hogy mi számít egyszerű, egy feladatnak. Egy mappányi shell script elindítása ugyanannyira mondható nem egyszerűnek, mint egy - és itt most csak az init/unit-kezelő részről beszélek - systemd; egyszerűen más absztrakciós szint.

Ami viszont lényeges, az a kombinálhatóság - ez megvan. Ráadásul egy szép, standard, szerializálható protokollon IS, nem csak az egymásba pipeolt, locale-függő, ... stringeken keresztül.

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

Egészen őszinte leszek: ha nincs explicit okom, hogy máshogy tegyek, csak Windows-ra fejlesztenék.

Ennek okai: market share, nekem a Windows-hoz készült fejlesztőeszközök tetszenek a legjobban, a Linuxnál mindenképpen stabilabb fejlesztés szempontból (pl. nincs vita init rendszerről, shellről, stb.)

...nem hatekony milyen szempontbol?

Altalaban ilyenkor szokott elokerulni egy, azaz egyetlen erv, hogy "jajhat az xzy nyelv lassu".

Ezzel szemben:
- Feladatok 99%-ara igy is eleg gyors.
- Igy is van eleg ram a gepben
- Sokkal hatekonyabb benne fejleszteni
- Atlathatobb kod keszul
- Gyorsabban fordithato (mar ha forditani kell).
- Security, security, security

C programozok altalaban egyetlen egy dolgot vesznek figyelembe, megpedig a sebesseg. Aztan, hogy memleakel, bufferoverflowol, 3x annyi ido lefejleszteni, stb., amire mas nyelv sokkal jobb megoldast nyujt, azt mar szarja le magasrol. Holott ezek szamitanak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Van, amikor igen. Itt egy egészen egyszerű példa, számok summázása:

http://tothviktor.wordpress.com/2010/12/04/mire-optimalizalsz/

Négy dolog volt összehasonlítva: unsafe pointerbizgálás, for, foreach, Enumerable.Sum(). Nagyjából ilyen sorrendben lassulnak a dolgok és egyszerűsödik a kód. És ez csak egy triviális egyszerű példa. Érdemes megnézni a konklúziót.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nehogymár a programozó találja ki, hogy egy feladatnak mik a követelményei!

Számos olyan eset van, amikor nem csak, hogy nem kell optimalizálni, hanem egyáltalán nem számít, hogy mennyire hatékonyan vagy kevésbé hatékonyan hajtja végre a program a feladatot, ha megadott küszöbérték alatt van.

Egy példa: PoC-t kellett készíteni. Egyik lehetőség C++ volt, kb. 2 hónap fejlesztési idővel. A másik Python kb. 2 hét fejlesztési idővel.
A végeredmény szempontjából teljesen mindegy volt, hogy a C++ mondjuk 8 másodperc alatt feldolgozta volna azt, amit a Python mondjuk 90s alatt.
A lényeg az volt, hogy be lehessen mutatni, hogy az adott elképzelés működik.

De hozhatnék példának production rendszert. Ha megvan az NFR, hogy x alkalommal kell elvégeznie valamit másodpercenként, és a rendszer alapból tud 2x-et, akkor a programozó ne álljon neki optimalizálni, hogy kihozzon a rendszerből 3x-et, mert az, aki a fizetését adja, annak a 2x-3x különbség nem hoz semmi hasznot, tehát kidobott pénz.
Helyette implementáljon egy másik funkciót, ami visszahozza a költséget!

Ha majd egyszer valaha megváltozik a követelmény, és már 3x kell, akkor majd a megrendelő azt mondja, hogy most akkor nézzük meg, hogy mik a lehetőségek. Optimalizálás vagy erősebb hardver, vagy valami más. Aztán majd mindenféle szempontok alapján dönt.

Van egy weboldalunk, fut néhány példányban. Évente kb. egy-két alkalommal tartunk olyan optimalizációt, amikor kifejezetten erőforrásra kell optimalizálni, azt is többnyire inkább eseti jelleggel. Miért? Mert 0, azaz 0 hasznot hoz. Az, hogy mondjuk 800E-1M-el többet kell költeni vasra* (ami mondjuk 5 évre oszlik el), az aprópénz ahhoz képest, hogy mennyi múlik azon, hogy van-e egy adott feature-nk (ami konkrétan pénzt hoz) vagy sem. Ez egy kiszámolható, forintosítható dolog.

Ha már nekiállunk optimalizálni, akkor jobban megéri nekünk arra optimalizálni, hogy - akár nagyobb erőforrás igények árán(!) - gyorsabb választ kapjon az user, mintsem, hogy kevesebb vasat igényeljen.

* Kiszámolt érték a mi esetünkre nézve.

Vagy mondok egy másik példát: volt egy kisebb feature igény SOS-ben, becsült idő kb. 10-12 óra volt rá. Kb. 8-9 óra után kérdem kollégám, akinek odaadtam a taskot, hogy merre jár. Mondja, kb. a felénél, viszont most elakadt mert ezt meg azt azt optimalizálja, hogy ne kelljen két query, stb., merthogy együtt már 2x50ms és "ezt sokallja". Vége az lett, hogy mondtam neki, hogy szarjon bele, mert kb. 3 hétig kell a funkció és amúgy sem egy túl gyakran használt dolog lesz és egyébként is, először működjön, aztán nézze meg, hogy benne van-e az elvárható időn belül és ha igen, haladjon, mert fontosabb az, hogy meglegyen, minthogy a szerveren 0,1 vagy 0,2%-al emelkedik a load.

És rengeteg ilyen van, amire kár az időt pazarolni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Tudod te, hogy egy darab programozói emberóra költségéből hány giga ramot lehet venni?

És akkor nem arról van szó, hogy lehet szuboptimálisan programozni, mert úgyis veszünk majd új gépet, egyszerűen arról, hogy egy jól megtervezett C projekt, és egy jól megtervezett C# projekt közül ez utóbbi lesz az olcsóbb. (tfh. a fenti példa nem pont az a 0.001%, amikor a C _kell_ egy feladathoz, és tfh. a programozók mindkét oldalon ugyanolyan színvonalat képviselnek)

"Nem mindegy, hogy 10 vagy 100 szerver kell."

Ami az esetek 70%-ában úgy néz ki, hogy nem mindegy, hogy egy ugyanakkora vagy egy ugyanakkora szerver kell. A maradék 27% úgy, hogy egy kisebb vagy egy nagyobb kell.

Nem csak Facebook meg Google méretű rendszerek vannak a világon.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Idézet:

~30 éve megszokott dolgot hajít ki a 3.14csába,

Mint sokan mások, akik felismerték, hogy a 30 éve megszokott dolog ma már nem működik. Gondolom te a mai napig fekete-fehér szovjet TV-n dolgozol Commodore 16-on."

OS X = launchd
Solaris = SMF

Igazi UNIX-ok!

--
trey @ gépház

Magyarázza el valaki nekem, hogy mi a nagy baj az ifconfig-gal.
Többé kevésbé minden releváns információt megkapok egy ifconfig eth0 kiadásával az interface-ről ember által jól olvashatóan. Na jó nem lehet könnyen feldolgozni egy scripttel az outputot, de szerintem nem is arra készült.
Nem azt kérdeztem, hogy az ip ... mennyivel tud többet, hanem miért káros az ifconfig használata.
Nem kötözködés, tényleg érdekel.

A Pulseaudio egy plusz választási lehetőség

nem egeszem. Ha a hasznalt alkalmazasod (skype rulez) atall kizarolag pulseaudio-ra, akkor (amennyiben igenyed van hangra) neked is kovetned kell. A systemd kapcsan meg tudom, hogy picsogas, de a redhat-nek van/volt egy bizonyos init file-ja, a debian vonalnak egy masik, az egyeb disztroknak talan megint masik, es akkor itt a systemd, ami nyilvan semmihez nem hasonlit. Kovetkezmeny: bonyolodik az en munkam (fejlesztokent). Nem arrol van szo, hogy nem lehet megirni az indito konfigot systemd-hez, de ne menjunk el szo nelkul amellett, hogy "megis minek kellett ez?"

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

"megis minek kellett ez?"

A saját kérdésed egy idézettel válaszolnám meg:

redhat-nek ... volt egy bizonyos init file-ja, a debian vonalnak egy masik, az egyeb disztroknak talan megint masik

És mert egyik sem működött úgy, ahogy egy modern rendszertől az elvárható - nem ok próbálta mindenki lecserélni (Upstart, OpenRC stb.), körülbástyázni (Monit stb.), egységesíteni (LSB) stb.

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

Khm. De az Solaris-only és mint tudjuk a platform-függő dolgok csúnyák (szerk, mert félreérthető: igen, jobb lenne, ha platform-független lenne, de mivel Linux-only feature-ökre épít a systemd, így csak ott játszik. Az SMF hasonlóan, csak más pályán.).

Egyébként nagyjából azok a feature-ök hiányoztak a SysV initből, amik az SMF-ben ott vannak (függőségkezelés, szolgáltatás-követés etc.)

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

Akkor megkérdezhetem, hogy ennek a pöcsnek a Not Invented Here-en kívül milyen indoka lehetett arra, hogy más módon és más interfésszel implementálja ugyanazt, ami az SMF-ben már megvolt? Van róla doksi (inkább doksihegyek), ott az interfész, van open-source kód is, szóval még azt is meg lehet nézni, hogy hogyan is kéne működnie belülről. Lehet az interfészre írni GPL kódot, vagy lehet a kódot is átvenni - tetszés és/vagy licenszhuszárkodás szerint. Töredék meló (a kernel interfész az egyetlen izgalmas rész), és a kulcsfontosságú rész (= az architektálás) már megvan, nem kell éveket szopni újból, hiszen ezt mások már végigcumizták.

Ja, és hogy-hogynem, az SMF el bír működgetni PID=10 alatt is tökéletesen. Biztos hülyék voltak mind ott Kaliforniában, hogy nem kúrták ki a SysV initet is az egész alól...

Valóban, és én (is) tényleg utálni szoktam az xml-t - de ha választani kellene, hogy egy kellőképp dokumentáltan tervezett és implementált, több éve élesben is használt megoldás, vagy egy "újra feltaláljuk a kereket" és annak (biztosan előkerülő) gyermekbetegségei mellett tegyem le a voksomat, akkor esélyes, hogy legyűrném az xml-undoromat.

Megvolt a végén a ":P"? ;)

Viccet félretéve: Nem tudom kód szinten eldönteni, hogy mekkora szívás lett volna beleerőltetni a linux kernel izéit -- pl cgroups, amikhez azért tényleg jó ha van értelmes userland is), de őszintén szólva én sem nagyon értem, hogy miért nem merült ez fel sehol komolyabban, mert azért ha tippelnem kellene akkor technikailag meg kellene valósítható legyen. Én két dolgot tudok mögé képzelni (azon túl, hogy a saját kerék mindig píbb): az egyik valami licenszhuszárkodás, a másik, hogy senki nem nagyon szeretett volna függeni attól a solaristól, amit Larry bácsi -- szándékoltan vagy sem -- bárddal próbál széjjelverni mióta csak rátette a kezét.

Annyiban releváns, hogy zeller kollega arra hivatkozott, hogy a systemd túl új és ezért teszteletlen. Igen, enterspájz disztróban eddig nem szerepelt, de az elmúlt pár évben azért lényegesen több telepítésen tesztelték, mint az SMF-et valaha; egyébként egy linux kernelre portolt SMF pont ennyire lenne újdonság.

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

Értem, így valóban van benne valami. Mondjuk azért a lényegesen több telepítésben egyáltalán nem vagyok biztos (pláne úgy, hogy solarison azért nagyobb eséllyel használták is, nem csak úgy volt), illetve azért a linux kernelre portolt smf csak a linux kernelt érintő részeiben lenne újdonság, a komplett userlandja meg vezérlése nem. És zeller pont ezt mondta.

Apró különbség, hogy az SMF-hez van design & implementatiton dokumentáció (pontosabban az _is_ van), és általában is fölösleges dolog n+1-szer feltalálni a kereket. Bár az opensource világ "virágozzék száz virág" hozzáállása (minden feladatra van még legalább egy másik opensource szoftver) miatt nincs mit csodálkozni ezen az egészen.

http://xkcd.com/927/

Bár ebben a konkrét esetben erősen úgy tűnik, hogy legalább linux fronton kvázi ez lesz az egy standard, szóval neked mint fejlesztőnek csökkeni fog vele a munkád majd.

Én egyébként nagyon nem bánom, hogy a kurvasok boilerplate shell eltűnik majd a vérbe, de azért a systemd uiját szokni kell.

De van. De egyrészt ha az eddig mondjuk 4 féle (az RH, Debian, Ubuntu, SLES lista gondolom komolyabb szofvernél kb a minimum) helyett a linuxok egységesednek 1-re, máris kevesebb a dolgod. Másrészt pedig ha tetszik, ha nem, ma a unixos világ egészére befolyással van, hogy merre megy a linuxos világ. Ha a systemd elterjed, én igenis várom (mármint nem vágyom rá, hanem szerintem ez lesz), hogy a systemd más unixokon is megjelenik vagy portolva, vagy kompatibilitási réteg formájában, és sokan azt fogják mondani, hogy a számukra kevésbé érdekes mondjuk xBSD platformot ezentúl így támogatják (linux-compat? :)).

Volt anno a BSD-style init (nagyjából egy fájlba belehányva minden, aminek indulnia kellett), meg utána a systemV stílusú init (futási szintenként könyvtárakkal, "S" és "K" scriptekkel, stb.), jól átlátható struktúrával és működéssel. Faék egyszerű mind a kettő megoldás - működik, igaz, a "kinek áll fel hamarabb" (a gépe) versenyben le vannak maradva, mert nincs meg a masszív párhuzamosítás, de ha azt nézem, hogy egy modern szervernél mennyi ideig tart a hardver feltápászkodása addig, hogy az os egyáltalán elkezdhessen bootolni... Marhára mindegy, hogy az init folyamat mennyire gyors.

Szerintem a "minek kellett ez" az esetek nagyrészében az e-péló méretének a növelésére jó. Meg arra, hogy újabb tanfolyamokat adhasson el a cég :-P

Meg sosem dolgoztal enterprise kornyezetben, ugye? Probalj race condition nelkul inditani / leallitani processzt, szabalyozni, milyen eroforrasbol mit hasznalhat, stb. Voltak mindenfele probalkozasok (start-stop-daemon, daemontools, ...), teljes volt a kaosz, szo sem volt faek egyszerusegu, atlathato dologrol.

Aki a systemd kapcsan a boot ido csokkenesevel peldalozik, az jelzi magarol, mennyire fogalma sincs a dologrol.

Az erőforrások limitálása by design nem az init feladata volt, az azért felel(t), hogy amit kell, azt a megfelelő sorrendben elindítson/leállítson, amit adott futási szinten kell, hogy fusson, azt indítsa (és ha kell, akkor újraindítsa).
Enterprise környezet bőven volt a systemd előtt is, és köszönjük szépen, elvoltunk jól a systemV-os init rendszerrel (sőt, vpolt még BSD-style inittel is olyan rendszer, ahova linux azóta sem tehette be a lábát...). Attól, hogy egybegyúrtak valamit, attól nem lesz átláthatóbb. És egyszerűbb se. Pláne, ha minden extra dolgot belelapátolnak.

Voltak mindenfele probalkozasok (start-stop-daemon, daemontools, ...), teljes volt a kaosz, szo sem volt faek egyszerusegu, atlathato dologrol.

ke? Pl. a daemontools nem egy kikopott init cucc, annal tobb, masabb. A systemd egy (imho) haszontalan bloatware, a kiss-elv megcsufolasa.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Mondjuk nem tudom mit rugóztok ennyit ezen a KISS elven. Egy halom olyan szoftver van, ami minden, csak nem egyszerű, aztán valahogy mégsem akarja őket kidobni senki, mert szükség van rá, úgy, ahogy.

Ez a KISS egy olyan bullshit dolog, amit el lehet lőni mindenre, amit az ember nem akar megérteni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Miert, egy uzemeltetonek nem kell(ene) megismernie azt a rendszert, amit uzemeltet? (Egyebkent a tapasztalatom az, hogy miutan az IT-sok jelentos reszenek halvany lila goze sincs, hogy valojaban hogyan mukodik egy szoftver/hardver/szamitogep, legalabb ugy alapveto atfogo szinten, maximum csak magukat hitegetik ilyen bullshitekkel, hogy jaj, ez az init script egy shell script, akkor tudom hogy mukodik, bezzeg az xzy, az valami csunya program es csak config file van hozza, ki tudja mi van benne!!!1111)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Egy halom olyan szoftver van, ami minden, csak nem egyszerű, aztán valahogy mégsem akarja őket kidobni senki, mert szükség van rá, úgy, ahogy."

Szükségből erény?

Igen, van egy rakás ezaz, amit nem dobunk ki, de nem azért, mert nem volna jó kidobni, csak nincs más (egyáltalán nincs, vagy jobb nincs).
A systemd-re nehéz volna azt mondani, hogy nincs helyette más - pont ezzel az érvvel nem lehet felmagasztalni, más meg nem vagyon szól mellette.

Tetszik ez az írás, tök jókat írnak róla. Tényleg jobb lenne init scriptek helyett systemd configokat írni, tök jó a gyors boot is. Evvel nincs is baj, de tudtommal nem álltak meg itt. Konkrétan nem néztem utána, valaki javítson ki, de olyan dolgok/FUD-ok miatt hezitálok, mint pl. van benne saját NTP kliens (minek az, én az originál ntpd-t szeretem), dependel a DBUS-ra (minek az nekem), valami újfajta rendszernaplózást vezet be (???), és hasonlók, és ezeket esetleg nem lehet simán kikapcsolni. Lásd http://uselessd.darknedgy.net/ .

--

+1. Ezért mondtam, hogy lehet egyszerűbben megúsznám, ha jövőre retek 7 helyett Windows-t tanulnék :-) Bár ha alaposan belegondolok, más Unix-okon azért még itt-ott felfedezhető a systemV-os init, és eléggé enterprise dolgokat is lehet ilyen "elavult" dolgokat használó rendszereken látni :-P

van benne saját NTP kliens (minek az, én az originál ntpd-t szeretem),

systemctl stop systemd-timesyncd && systemctl disable systemd-timesyncd

Aztán felteszed a kedvenc NTP szervered. (amúgy Archwiki szerint ez csak kliens NTP, nem hozza a teljes szerver funkciót. Személyes tapasztalatom még nincs vele, systemd 206-nál tartok, az meg 213-ban jelent meg)

dependel a DBUS-ra (minek az nekem)

Nem sokára ott lesz a kerneledben, nem úszod meg (kdbus) :) Amúgy egy kiforrott könyvtárakkal rendelkező, széleskörűen tesztelt, biztonságos, modern IPC, jól definiált marshalling/seralization szabályokkal.

valami újfajta rendszernaplózást vezet be

Na igen, a journald-t nem tudod kikapcsolni, max. a kedvenc syslog démonodat berakni mögé.

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

"Az már nagyon Windowsos irány, hogy felraktunk egy böhöm nagy programcsomagot, ami mindent tartalmaz, és olyan bonyolult"

http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx

Érdekes módon, aki akarja, az meg tudja ismerni. A hupuk általános lustaságát légyszi ne ideologizáld már be azzal, hogy "jaj, bonyolult".

Egyébként a "böhöm nagy programcsomagról" valahogy előbb-utóbb mindig kiderül, hogy igazából eltávolítható belőle egy halom dolog, plusz ott a Server Core, stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A Pulseaudio-nak volt egy halom gyerekbetegsége, kezdetben nem működött túl jól (nem működött, lagos volt a hang, elcrashelt, stb. - nagyon sok hibája volt tényleg). Aztán ezeket kijavították. Nem egy túl bonyolult történet és erősen remélem, hogy a systemd-vel is így lesz :-)

Ja, meg a ReiserFS-nek is volt egy problémája 15 évvel ezelőtt, azóta is azon rugóznak a trollok. Érdekes, én 10+ éve használom minden nap probléma nélkül.

Vagy ott van a NetworkManager. Azt is szidták mint a bokrot. Volt is valóban vele gond, de évek óta már nekem problémamentes.

Ezeken a sérelmeken egy idő után túl kéne lépni.

--
trey @ gépház

Értem a poént, bár az, hogy Reiser börtönben van, keveset változtat a bárminek is a helyzetén.

Már a börtönbe zárása előtt ismert volt, hogy a ReiserFS-t (v3) nem fejlesztik tovább. Helyette lett volna a Reiser4, de sosem lett mainline kernel része.

Annak ellenére, hogy a ReiserFS-t már nem fejlesztik aktívan, mivel a mainline kernel része, továbbra is karbantartják és bugfixelik.

--
trey @ gépház

( uid_16313 | 2014. 10. 07., k – 17:35 )

Én inkább úgy fogalmaznék, hogy az egész világ tele van seggfejekkel, ez nem csak a nyílt forráskódú közösség kiváltsága.

--
robyboy

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

( saxus | 2014. 10. 09., cs – 01:05 )

Igazából csak azt nem értem, hogy az OSX-ből miért nem akarja senki sem kidobni a launcherd-t. Pedig arról koppintották a systemd-t állítólag...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mert aki OSX-et használ, az nem akarja eldönteni a vendorja helyett, hogy mi hogyan működjön a gépén, ő magáénak érzi a gyártó összes döntését. Érted, amikor a bugreportra az a válasz, hogy "Te nem is akarod azt a feature-t használni!" "Igen, valóban, nincs is szükségem erre, ó Nagyúr!" :D

ha valoban Kay hozzaallasa jellemzo az egesz systemd tarsulatra, akkor ritka nagy balfaszok. Itt (https://bugs.freedesktop.org/show_bug.cgi?id=76935) nagyon elkenik Kay meg Lenart szajat, es okkal.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Okkal?

Elnézve a thread-et:
* X bejelent egy hibát
* X új hozzászólásban közli, hogy az eredeti bejelentése fele tárgytalan
* Kay válaszol rá, leírva, hogy az nem bug, hanem elvárt működés (-> és itt egy kommunikációs hiba, nem írja, hogy az assert-et tényleg egy bug)
* X közli, hogy ő továbbra is szeretné úgy használni a debug opciót, ahogy akarja (amit a ASSERT bugja miatt nem tud) és az objektivitás látszatát keltve kijelenti, hogy ez egy rossz tervezési döntés eredménye (-> majd a thread-ben hoznak pro- és kontra érveket, mindkét oldalról egész meggyőzőeket)
* Kay válaszol, hogy ebben nem értenek egyet
* X felhagyva a technikai beszélgetést közli (az objektivitás látszatát keltve), hogy jól tette, hogy szkeptikus volt a bug megnyitásában. (BTW, amit ugye már javítottak)
* Y beszáll, ő is megkérdőjelezi a tervezési döntést.
* Kay válaszol, hogy a bugzilla nem egy fórum és használja erre a levelezőlistát; ezzel Kay kiszáll a bug-ból, többet nem szól hozzá.
* X visszatér, és elhangzik az első igazán személyeskedő hozzászólás - innentől downhill.

Hol ebben a rossz hozzáállás? Amíg technikai kérdésről volt szó, addig részt vett a beszélgetésben majd - jogosan - közölte, hogy a tervezési döntéseket a levelező listán kellene követni.

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

Ha és amennyiben véleményed szerint valahol bármely oldal véleményét rosszul foglaltam össze, arra nem az a válasz, hogy elkezdesz személyeskedni és sértegetni, hanem - kihasználva, hogy írott szövegekről van szó - hozol idézeteket, hogy hol módosítottam a jelentésen.

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

A válaszod szerintem is tényleg az, ami: nagy nyilvánosság előtt elkövetett rágalmazás; csak szólok.

De indoklást, hogy hol módosítottam volna bárki álláspontját, még mindig nem látok.

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

Off-topic: És miért feltételezed, hogy tudnád bizonyítani illetve mivel gondolnád bizonyítani az igazad? Egy ilyenért nem fogok ügyvédhez rohangálni, csak érdekel, hogy alaptalanul vagdalkozol, vagy ismersz valami körülményt, amit én nem (utóbbit kétlem).

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

A magyar lakosság 1-2%-ához [1] képest jelentős előnyöd van, értjük. Sőt, felteszem, a vakok és gyengénlátókhoz képest, a mozgássérültekhez képest, az autistákhoz és a többi fogyatékkal élőhöz képest is (490578 ember [2]).
Ezt nyilvánosan megjegyezni felesleges (mert a kontextusba sehogy nem illik), és a jóízlés határát súrolja - és a kérdést, hogy mivel bizonyítanád az állításod, továbbra sem válaszolja meg.

[1]: Pontosabb adat híján: http://hu.wikipedia.org/wiki/Analfabetizmus
[2]: http://www.ksh.hu/nepszamlalas/docs/tablak/fogyatekossag/11_01_01.xls

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

igen, okkal.

Supplying "debug" on the kernel command line gets parsed by systemd.

az 1. kerdesemmel egy klasszikust ideznek: "es ezt igy hogy?" Eleve az gaz, hogy a systemd a kernelnek szant parametereket felnyalja.

Majd Kay megmagyarazza, hogy That is the expected current behaviour (szabad forditasban (szf): igen, balfasz vagyok) The generic term "debug" is read by Base OS tools too. (megismetli, hogy idiota)

as "debug" is a kernel cmdline parameter and not aimed for systemd. [...] Actually, I'd like to continue using "debug" - a workflow a lot of kernel people have been doing for years - without anything interfering,

szerintem ertheto allaspont

Kay frappans visszavagasa: Generic terms are generic, not the first user owns them. (szf: vakuum van a fejemben)

BP elkeseredett, amiert ez a systemd-s ember tenyleg debil: Right, and breaking existing use cases by hijacking generic terms is also ok. I was right to be very skeptical when considering opening a bug here.

Ahogy barmelyik ertelmes ember is gondolna, ahogy a dolgoknak lenniuk kellene (eleve nem kene felparszolni a kernel cmdline-t): The kernel is the primary user of its own command line and has a reasonable expectation that it's the default namespace for parameters [...] There may be base utils that parse the command line (they really shouldn't) but even if they do, their reaction should not be to scribble all over the kernel log.

Majd Kay elkezd terelni: Bugzilla is not a discussion forum, and repeating the same

OK, a kerneles csavo belemegy a jatekba, es kiboki, hogy mi a konkret bug (ami btw. az 1. pillanattol kezdve nyilvanvalo IQ20 felett) Ok, the bug is that a *kernel* parameter compels a *userspace* program to trash the *kernels* log with enough information to break boot due to timeouts.

Kay elmes valasza: Again, move discussions to the mailing list; this is a bug tracker, but there is no bug to track or fix here.

Dude, are you for real? Are you actually actively trying to be a d*ck or you're this way by default. We're telling you there's a serious issue and we're even being constructive by giving suggestions and you're deflecting. You have got to be f*cking kidding me!

Azt hiszem, ennyi eleg is annak bemutatasara, hogy ez a Kay Sievers nevu tag egy retardalt braindead fucktardo, es total egyet ertek a kernelfejlesztokkel, hogy a systemd-s tag hozzaallasa finoman szolva nem megfelelo.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Igen, aztán ha továbbolvasod, akkor ugyanebben a thread-ben szerepelnek érvek arra is, hogy jó döntés a debug opciót értelmezni. És igen, jogosan tette, hogy lezártnak tekintette a bug-ot, mivel a bejelentett bug NEM LÉTEZIK, a hibás assert körül van egy bug és van egy megbeszélésre váró design döntés. EGYIK sem ez a bug.

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

Aaron Seigo nagyon hasonlót írt mint ez a cikk:
"I certainly get my "fair share" of trolls, insults and generally poorly behaved individuals but Lennart's experience is foreign to me and, I suspect, many others in similar positions. The difference? Lennart's approach to dealing with people in the community which has often been less than constructive and open."
És Seigo volt a KDE főnök a 4.0 megjelenésekor, szóval tényleg kaphatott hideget-meleget.

( ak0sh | 2014. 10. 09., cs – 23:23 )

>Lennart Poettering
Így próbál meg az NSA bekerülni a Lienuxokba.

( NevemTeve | 2014. 10. 10., p – 20:14 )

> Mint írja, kapott már gyűlöletlevelet azért, mert nyílt forrású szoftvereken dolgozik.

Azért ezt egy kicsit nehéz elképzelni, hogy Noném Géza szocipata egy reggel arra ébred, hogy kíváncsi lesz, hogy 'ej, ez a Lennart gyerek vajon nyílt vagy zárt forráskódú szoftvereken dolgozik-e, mert ha az előbbi, akkor az űrlények büdöslábú ügynöke, akinek gyűlöletlevelet kell küldeni, de ha az utóbbi, akkor békén maradhat.'

( neuron | 2014. 10. 11., szo – 13:10 )

"When it comes to systemd, you may expect me to have lots of colourful opinions, and I just don't," Torvalds told iTWire in an interview. "I don't personally mind systemd, and in fact my main desktop and laptop both run it.
In a reference to a spat he had with Kay Sievers, one of the main developers of systemd, Torvalds added: "Now, I don't get along with some of the developers and think they are a bit too cavalier about bugs and compatibility, but I'm also very much not in the camp of people who hate the very thought of systemd."
...
iTWire: Systemd seems to depart to a large extent from the original idea of simplicity that was a hallmark of UNIX systems. Would you agree? And is this a good or a bad thing?
Linus Torvalds: So I think many of the "original ideals" of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation.
There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at *some* level, but I think it's also clear that it doesn't really describe most of reality.
It might describe some particular case, though, and I do think it's a useful teaching tool. People obviously still do those traditional pipelines of processes and file descriptors that UNIX is perhaps associated with, but there's a *lot* of cases where you have big complex unified systems.
And systemd is in no way the piece that breaks with old UNIX legacy. Graphical applications seldom worked that way (there are certainly _echoes_ of it in things like "LyX", but I think it's the exception rather than the rule), and then there's obviously the traditional counter-example of GNU emacs, where it really was not about the "simple UNIX model", but a whole new big infrastructure thing. Like systemd.

Torvalds says he has no strong opinions on systemd

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

( Lacyc3 v | 2014. 10. 10., p – 21:51 )

A systemd, pulseaudio körbe tartozik még az rtkit is. Mit gondoltok róla?

( trey | 2014. 10. 16., cs – 07:37 )

Linus megbánta, hogy durván beszélt az emberekkel:

Linus Torvalds' Best Quotes from LinuxCon Europe 2014

4. Hohndel: “If you could change a single decision you've made in the last 23 years, what would you do differently?”

Torvalds: “From a technical standpoint, no single decision has ever been that important... The problems tend to be around alienating users or developers and I'm pretty good at that. I use strong language. But again there's not a single instance I'd like to fix. There's a metric shitload of those.”

[...]

6. “On the internet nobody can hear you being subtle.”

7. “One of the reasons we have this culture of strong language, that admittedly many people find off-putting, is that when it comes to technical people with strong opinions and with a strong drive to do something technically superior, you end up having these opinions show up as sometimes pretty strong language.”

--
trey @ gépház