A Systemd letjogosultsaga megszunt

A FOSDEM-en volt bejelentes,
a distrowatch.com oldalra commentelok remekul meglattak, hogy micsoda nagy dolog tortent.
A systemd eltavolitja a parhuzamos indulas kepesseget!

Mivel a fejlesztoknek csak SSD meghajtojuk van es igy nem tesztelnek, nem fejlesztenek ilyen dolgot.
A systemd celja eredetileg a rendszer inditas parhuzamositasa volt.
A systemd eredeti celjat, az elonyos oldalat kivettek,
maradt a hatranyos oldala, egy make-it-terrible-complex-bloated-obfuscated-all-in-one---no-simple ganylabda,
amitol minden epeszu ember menekul.
A systemd letjogosultsaga ezennel megszunt! HA-HA-HA

Mar karorvendve varom, hogy a disztribuciok szepen kiveszik a systemd-t es csunyan elmuljon meg az emleke is!! HA-HA-HA
Az LWN elhallgatja, csak a distrowatch.com oldalrol kell megtudni, meg azota sem irta senki!
A hir egyszerre FELHABORITO es egyszerre orvendetes.
Nyilvan csak akkor lesz orvendetes ha a disztrok tenyleg kipurgaljak a systemd-t, de megis, mi okbol hagynak bent?
:)))

Hozzászólások

Te ugye nagyon nem tudsz angolul?

One feature being removed from systemd is read ahead, a process designed to decrease boot times by anticipating data needed during boot time. Poettering reports all systemd developers now use SSD disk drives rather than spinning disks, making it impractical to test the read ahead feature.

Hat te egy fasz vagy :).
Nem tudsz angolul, nem erted, hogy mi van oda irva, miutan kijavitanak, meg pampogsz ilyenekrol? Azert halasnak lenni, hogy leirtal valami fals infot?

Legalabb valami ertelmes dolgot boffentenel ide a systemd-vel kapcsolatosan, ami tenyleg gazos (ld. gmmore postjait pl)

Vagy siman trolling, hogy ilyen hulyenek tetteted magadat? :)

Ugyan már. A céges gépemen Red Hat 6.6 van, a saját tabletemen Windows 8.1, a telefonomon pedig Android 5.0. Engem a Microsoft, a Google és a Red Hat egyszerre pénzel.
A Microsoft azért, hogy használjak Androidot, a Red Hat azért, hogy használjak Windowst, a Google meg azért, hogy Red Hatet használjak.

Mármint a te világképed szerinti elsődleges céllal, hogy gyorsabban induljon? Még mindig párhuzamosan is tud indítani, köszöni, jól van. Most csak kb azt mondták, hogy mostmár nem pöcsölnek azzal, hogy próbálják a szükséges fileokat azelőtt beolvasni a diskről, még az előtt, hogy valóban kellene, mert ugyis SSD van már mindenkinek, nem lassú pörgős diszk (az más kérdés, hogy ez mennyire korlátolt egy világkép).

Ettől még nem ez lesz a systemd elsődleges célja, ők továbbra is egy mondern szervízkezelőt (meg még ezt azt) akarnak csinálni. Azokkal a célokkal lehet nem egyetérteni, de hogy a readaead lett volna bármikor is az elsődleges célja, az egy nettó baromság.

kroozo:
"Ettől még nem ez lesz a systemd elsődleges célja, ők továbbra is egy mondern szervízkezelőt (meg még ezt azt) akarnak csinálni. Azokkal a célokkal lehet nem egyetérteni, de hogy a readaead lett volna bármikor is az elsődleges célja, az egy nettó baromság."

Ja vagy ugy! En nem igy tudtam.
Sajnos nem volt eleg idom elolvasni a reszleteket es ezek szerint baromsagokat irtam.
Bocsi mindenkitol, kiveve Nagyz-tol, mert ot utalom.

Van azért a többi miatt is hőzöngés. :) De mint a fenti példa mutatja, egy jó részük nem annyira releváns.

Egyébként én meglehetős ambivalens érzésekkel nézegetem. Egyrészről sok mindent üdvözítőnek tartok, másrészt egy kicsit tényleg sokat markol a projekt. Harmadrészt tudom, hogy ernyőprojekt, és szétszedhető. Negyedrészt látom, hogy ez nem feltétlen triviális, és nem feltétlen történik meg :) Ötödrészt meg kissé zavar az arogancia, amivel az urak önnön magukat sokszor mindenkinél okosabbnak tartják, és nem hajlandóak meghallgatni ellenérveket. Hatodrészt azért van is igazuk hébe hóba. (Hetedrészt belegondolok, hogy majd minden nagyobb foss projekt körül vannak ilyen emberek, linus, alan dekok, theo de raadt, szóval ilyen szempontból csak business as usual).

Szo sincs rola. A readahead arrol szolt, hogy megprobaljuk, melyik szektorok lennenek a kozeljovoben beolvasva, es betoltjuk oket, hogy a page cache-bol jojjenek. Lassu veletlenszeru hozzaferesu (random seek) eszkozrol szekvencialis olvasasnal segit(het). Mas esetben pedig lassithat is, mert nem szukseges reszek is beolvasasra kerulhetnek, es kozben mas olvasasok varakoznak a diszkre. Nem veletlenul dolgozzak at az IO schedulereket is, a regi forgotanyeros diszkek idejeben hasznos optimalizalasok (minel kevesebb fejmozgas, interleave figyelembevetele, stb.) manapsag egyre kevesbe hasznosak, plane SSD-n, ahol nincs fejmozgas es abbol eredo kesleltetes.

Hát meg amúgy sem.

Nekem konkrétan ma lett SSD-s laptopom (i5, HDD, 4GB ram helyett i7, SSD, 8 GB RAM), de a Windows 8.1 bootolása gakorlatilag semennyivel nem lett gyorsabb. (x<=10 másodperc vs. x-2 másodperc) Ha az IO miatt tart egy consumer oprendszer bootolása percekig, az már régen rossz, 2015 van.

Dehogy szűnt meg. A systemd egy system & service manager, aminek csak egy kis szelete az init.

>Dehogy szűnt meg.
Tulajdonképpen +1, hisz soha nem is volt. Ez egyébként nagy általánosságban igaz a freedesktopos projektekre, valahogy így képzelem el az alkotói folyamatot:

1. Találjunk ki egy nem létező vagy már megoldott problémát
2. Oldjuk ezt meg úgy, hogy linugz only legyen. Ha valakinek ez nem tetszene, akkor vágjuk az arcába, hogy az ő rendszere nem elég elterjedt (a linugzzal ellentétben, ugyebár)
3. Mivel épelméjű emberek nem használnak szívesen rákos szarokat, ezért a saját rákos szarjainkat tegyük függővé a "megoldásunktól", és vice versa, így aki az egyik használatára rákényszerül, annak muszáj lesz a többit is "felpattintania". Bónuszpontot ér, ha az aktuális RÁK le se fordul a RÁK nélkül (pkg-config)
4. xy nevű projektünk hibamentességére nem szabad túl sok erőforrást pazarolni, mert úgy kevesebb idő maradna új "problémák" (goto 1.) megoldására, továbbá nem lenne ok kiadni az xy2 nevű waret, aminek legfontosabb jellemzője, hogy teljesen inkompatibilis xy-nal, de a többi projektünk függőségi láncán keresztül mindkét verziót fent tartjuk a user gépén. Bónuszpontot ér, ha ebből valamilyen extra probléma származik. (Szemfülesek észrevehetik, hogy az általunk generált problémára akár szállíthatnánk egy "megoldást" is, 1. pont megint)
5. Ha valakinek a fenti pontok közül valamelyik nem tetszene, akkor az ostoba, bőgatyás, antisze, szélsőséges, a Haladás kerékkötője.

Lennart vagyok,
a Red Hatnek dolgozom

Erőteljesen a fejlesztési (meg a vele foss módon szokásosan tervezési) fázisban van, úgyhogy tesznek is bele, meg dobnak is ki belőle "ezt-azt", aztán majd legalább 5-10 év múlva nézzük meg, mennyire lesz kiforrott dolog belőle (vagy inkább akkor, amikor eljön a Linux desktop éve, a világméretű IPv6 átállás után...)

Engem egy jottányit se érdekel az egész sztori, userként remekül tudom alkalmazni a kedvenc disztrómat (igen, a munkámban is), ha az dönt valahogy és a soron következő rolling update kitépi a rendszerből, de az általam elvárt funkcionalitás megmarad, akkor majd azt mondom hogy jóvan, a fiúk teszik a dolgukat a bányában.

--
arch,debian,openelec,android

dev: http://goo.gl/7Us0GN
BCI news: http://goo.gl/fvFM9C

Elso hozzaszolo az emlitett oldalrol:
When someone need an example to explain the hate against systemd, this is a good one.
1) One of the intended goals for systemd (quicker boot of the operating system) has been put on the second tier.

Egyrészt, bármi hihetetlen is, de bizony egy szoftverben mindig vannak éppen fontos, meg kevésbé fontos featureök. (Leszámítva azt az esetet, amikor a management szerint minden high. Aztán meg jön a csodálkozás ugyanettől a managementtől, hogy mégsincs meg minden, vagy nem olyan). Még olyan is van, hogy pl a prioritások megváltoznak, ie, valami, ami komolyan fontos volt, most már nem annyira az.

Másrészt, a konkrét esetben baromira jót tenne egy kis gondolkodás.
- Nem kellene összemosni a gyors bootot, meg a readaheadet. Az egyik egy cél, a másik pedig ezen cél elérésének lehetséges eszköze. Vannak még hozzá más eszközök is, nevesül pl az, hogy a systemd az egymástól nem függő szolgáltatásokat hajlandó párhuzamosan elindítani. Azaz attól még, hogy a readaheddal nem foglalkoznak többet, még nem jelenti azt, hogy a gyors bootolás továbbra már nem cél.
- Aztán érdemes megérteni, hogy mit is csinált a readahead: megpróbálta optimalizálni a lassú lemezről (mármint viszonylag, a többi egységhez képest) való olvasást. Tippre pl azzal, hogy mondjuk ha már arrajárt valami olvasásnál, elcachelt még ezt azt, másrészt azzal, hogy adott esetben amíg valamik még indultak a későbbiekhez szükséges fileok olvasgatását megpróbálta elintézni közben. Namost, mivel az SSDk nagyságrenddel gyorsabbak, mint egy rendes hdd, illetve az olvasási karakterisztikájuk is más (nem kell felpörgetni, nem kell fejet pozicionálni, etc) ezzel nem igen lehet már nyerni, cserébe egy frankón bonyolult problémakör. (Egyébként élek a gyanúperrel, hogy a readaheadnek néhány corner-caset, meg laborkörülményeket leszámítva egyébként is minimális hozadéka volt, ha egyáltalán).

Szóval alapvetően tök logikus dobni, és valami mással foglalkozni helyette (akár jobb dependencia kezeléssel, ami gyorsabb induláshoz fog vezetni, ki tudja ;)). Az egyetlen megkérdőjelezhető pont az, hogy "mert nálunk már mindenkinek ssdje van, ha neked nincs, leszarjuk", de ezt ugye nem kérdőjelezted meg :)