Az Arch Linux is systemd-re vált

Linux

Egy ideje folyik már a diskurzus az Arch fejlesztők között arról, hogy a disztribúció systemd-re váltana. Egy lépéssel közelebb került a váltás azzal, hogy a projekt kiadta 2012.10.06-os telepítőmédiáját, amelyen már a systemd-t használják a Live rendszer felbootolásához. Az initscript-ek már nincsenek jelen a Live rendszeren, de még alapértelmezés szerint telepítésre kerülnek a target rendszeren. Ez a közeljövőben feltehetően változni fog. Az októberi telepítőmédia bejelentése itt. További részletek itt.

( answ | 2012. 10. 09., k – 02:49 )

Kíváncsi leszek Debian váltani fog-e (vagy erősebb lesz a BSD kernel ág ellenszele), illetve Ubuntu meddig húzza a saját fejlesztését (upstart).

Meg hogy a Gentoo OpenRC - systemd fronton mi fog történni. Behúzhatná már valaki a vészféket, mert nehéz követni.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( vector | 2012. 10. 09., k – 09:00 )

Az initscriptnek komoly múltja van a systemd-nek még a jövője is kérdéses... Ez az egész barkácsolás kezd szánalmas lenni, lásd HAL.

Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

Egyetértek. Kb egy éve tettem fel az Arch-ot, és nagyon meg voltam elégedve vele. Jobb lett volna, ha nem frissítgetem, még ma is használhatnám. Nem tudom miért kubikolnak jobbra-balra. Kénytelen voltam egy LTS 12.04-et feltenni, pedig nem rajongok érte, és az Arch KDE4-gyel is nagyságrendekkel gyorsabb volt.
Az lesz a vége, hogy keresek valami konzerv linux-ot, amiben 2.6.32-es kernel van, meg nem köpi a frissítéseket percenként, azt kalap.

U-dash
----
MSI MegaBook S271 + Intel SSD \m/

Egyetértek. Az Arch-nak köszönhetem, hogy megváltoztatta az álláspontomat a rolling release-sel kapcsolatban. Valaha tetszett a módszer, most már inkább kerülöm. Így jutottam el a Fedoráig, ami viszonylag friss, viszont nem kell naponta 2x gyökeresen átkonfigurálni.

--
robyboy

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

Nem a Systemd a probléma, hanem az, ha egy distro folyamatosan és drasztikusan változik úgy, hogy felhasználói szempontból semmi lényegeset nem hoz a változás, viszont rendszerkarbantartást igen.
Persze nyilván vannak emberek, akiknek a rendszer örökös hegesztése hoz megnyugvást, míg mások meg egyszerűen csak használni szeretnék meglepődések nélkül.

--
robyboy

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

Pontosan ezért vannak a hosszú karbantartású kiadások és rendszerek. A dev-eknek viszont elkerülhetetlen hogy a legfrissebb verziókat használják. Szerintem a sima user inkább ne használjon ennyire friss cuccokat, mert abból csak a problémákat fogja látni. Neki nem ez a lényeg.

Persze, hogy változik, de nem úgy, ahogy a rolling release, pl. az Arch.
Felhasználói szemszögből nézve kevésbé problémásan. Főbb verziók vannak, amik egyszerűbben tarthatók frissen. Lásd pl. még Trey Ubuntu-frissítési sorozatát. Ugyanez Arch alatt folyamatos config-fájl turkálással jár együtt a mindenkori változtatásoknak köszönhetően.

--
robyboy

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

Ha használni szeretnéd melepetések (bár azért mondjuk az archéknál mindig van figyelmeztetés ha valami drasztikusan változik) nélkül, akkor ne használj rolling release disztrót. Ez ezzel jár, kísérleti nyúl aki használja, cserébe minden friss. Mondjuk nekem különösebben nem okozott problémát semmi mostanában sem, igaz nem is álltam át systemd-re, csak frissítgetek apper-el naponta - pontosan azért, mert nem akarom perpill szívatni magam, majd ha erre lesz kedvem meg időm, áthegesztem. :)

Egyetértek!

Azért aki kitalálta úgy július közepén hogy most a /lib az legyen a symlink a /var/lib/ -be annak letépném a tökét.
Akik erre azt tanácsolják hogy ami a /lib -be dobott valamit azt távolítsuk el majd installáljuk újra az is menjen el a p*-ba. (simán livecdről move + symlink megoldotta a dolgot)

De a systemd tetszik. Nem volt gáz az átállás (pedig saját init scriptjeim is voltak ezeket kb fél nap volt belőni) és sokkal jobban átgondolt/megvalósított rendszer mint bármi amit eddig (sysiniten kívül még upstartot és OpenRc-t) láttam.

Majd akkor leállok vitatkozni mikor látod, hogy a systemd milyen mélységi-függőséghez vezet. És ez a függőség mennyire veszélyezteti a rendszer stabilitását, ellentétben egy initscript-el. Ami miután lefutott nem szól bele a rendszer működésébe...

Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

A magam reszerol, en kifejezetten hasznosnak tartom, hogy a systemdnek tobb beleszolasa van a rendszerembe. Sokkal nyugodtabb vagyok ugy, hogy szemmel tartja a processzeim, es korrektebbul kezeli a fuggosegeket, mint az init scriptes ganyolas. Az, hogy a systemd jobb ralatassal rendelkezik a rendszeremre, mint a sysvinit, pokolian hasznos tud lenni, es a rendszer stabilitasat jelentosen noveli, ha nem egy osszetakolt kartyavar tartja egyben.

De majd ha latok akar egyetlen egy sysvinites rendszert, amitol nem kapok sikitofraszt a borzalmas init scriptek lattan, es bugot sem talalok benne, akkor esetleg majd hajlando leszek nem ujjal mutogatni es rohogni annak vedelmezoin.

(Nem azt mondom, hogy a systemd tokeletes, mert nagyon messze van tole, de legalabb az elkepzeles nem annyira elcseszett :P)

--
|8]

"a systemd tokeletes, mert nagyon messze van tole,"

Ez a lényeg! Nem egy jövőkép a systemV de működik és addig nem szabadna a stable disztribe rakni amíg ki nem forrja magát. Ezért is hoztam fel a HAL-t példának! Mire kiforrta magát rájöttek, hogy nem is kell.

Szerinted mit használok? Wi... neeem! Na, na, na? Hát blackPanther OS v12.0(beta)-t * blackpantheros.eu

Amig nincs tisztessegesen dokumentalva, plusz a mukodese is eleg problemas, addig en ketszer megfontolnam, mielott eles kornyezetbe deployolom. Azert vannak a testing, staging agak minden disztroban, hogy ezek a dolgok ott megerlelodhessenek. Sajnos ma a legtobb disztro inkabb divatiranyzatokat kovet semmint esszeru megfontolasokat. Inkabb ez a problema.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ooo, teljesen tisztessegesen van dokumentalva, messze jobban, mint a sysvinit.

A honlapjan van egy "Manuals and Documentation for Users and Administrators" resz, alatta man oldalak, howtok, videok es miegymas.

A mukodesevel en eddig nem lattam komoly problemat, ami volt azt pikk-pakk kijavitottam. IRC-n is rendkivul segitokeszek voltak amikor sikerult labonlonom magam, elmagyaraztak szepen hogy rosszul kozelitettem meg a dolgot, ha igy-meg-igy csinalom jo lesz. Ez ugy lett.

--
|8]

( Troppauer | 2012. 10. 09., k – 09:03 )

Az init scripteket ismererem, nem igazán tudom, hogy mivel lehet jobb a másik kettő....
Nincs valami összehasonlító oldal erre?

Az első találatból is már látszik, hogy az őskövület sysvinit megoldás mennyire a fejlődés útjában áll.

Szerintem fejleszteni kell és hagyni kell a fejlődést, és amíg nem akarja valaki a gyorsan változó részt használni, az használjon valami RHEL-t vagy klónt 7 meg 10 éves támogatással, és ilyenre nincs gond hogy miért fejlesztik.

Amúgy az összehasonlítás elég meggyőző.

Szerintem nem most jó, hanem előkészíti a lehetőségét a további fejlesztéseknek, hogy használhassák a felsorolt extra dolgokat a jövőben.

Tehát a jelenlegi trend az szerintem, hogy az eddigi funkcionalitást le kell implementálni, hogy hasonlóan vagy ugyanúgy tudja és menjen a rendszer, plusz az extra tulajdonságok hozzáadása. Ezért lehet kérdezni, hogy most miért jó hogy lecseréljük, és relatíve nem változik sok minden, a régivel is bebootolt a rendszer. Nem most fog ez számítani.

A konkret kerdesre nem valaszoltal. Miert mutatja azt? Miert biztos, hogy az a fejlodes es nem csak maszatolas?
Annyiban persze egyetertek, hogy ha nem valtoztatnak, akkor nincs se fejlodes, se visszafejlodes, de ettol meg nem vagyok abban biztos, hogy ami most tortenik, azt egyertelmuen eloremutatonak lehetne nevezni. Se systemd, se upstart reszrol.

Szerintem itt nagyon kijon egyebkent, hogy mennyire nagy kulonbseg van szerverek es desktop rendszerek kozott, melyiknek mire van igenye.

tompos

Például D-Busszal lehet megoldani a következőket benne:
- a Bluetooth szolgáltatást csak a megfelelő program elindítása után kapcsolja be (erőforrás spórolás);
- a szövegszerkesztő 5 másodperccel el tudja halasztani a leállítást, mert éppen ment;
- a kedvenc torrent kliensed felfüggeszti a géped elaltatását, mert már csak három pillanat van hátra amíg leér a heti film;
- kernelfrissítés közben nem kapcsolhatod ki a géped.

Ezeket mind meg tudja valósítani a systemd, és mivel a szolgáltatások indítását/leállítását ő vezérli, ezek is a feladatai közé tartozhatnak. Illetve nem hiszem, hogy a initd ezek közül bármelyikre képes lenne.

--
The Elder Scrolls V: Skyrim

( ssikiss | 2012. 10. 09., k – 11:00 )

Próbáltam Arch-on nemrég, egyetlen zavaró dolog vele, hogy nem volt minden szervizhez konfiguráció hozzá, de ez gondolom gyorsan változik.

( hrgy84 | 2012. 10. 09., k – 16:52 )

Hat nem tudom, egyelore a systemd-nek meg mindig tobb hatranyat latom mint elonyet. Nyugos hasznalni, nehez debugolni, nem mindig vannak hibauzenetek, nem mindig latni, pontosan mit ut le... szoval ilyenek.

En meg mindig azt mondom, hogy az init script jobb, es azt ugyanugy lehetne parhuzamositani meg dbus-ositani, en sem latom, miert jobb ez a koncepcio, mint a mar meglevo, mukodo infrastruktura.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Most jön a hülye autós hasonlat:

Ez kb. az mint amikor mindenki hibrid autóról beszélt a Toyota meg előállt a Prius-szal. Totál alapjairól felépített hajtáslánccal ami hibriddé lett tervezve, nem pedig csak berakjuk a villanymotort valahova a robbanómotoros hajtásláncba (amit mindenki más csinált).

Itt is erről van szó. toldozgathatod-foldozgathatod a primitív systemV scripteket, meg megpróbálhatod párhuzamosan indítani őket, mindig maradni fog a probléma: ezek nem ekkora rendszerek gyors és hatékony indítására lettek kitalálva, hanem szerverekére amit bekapcsolsz azt megy évekig.

Amúgy nem értem miért nyűgös debugolni. Beírod hogy "systemctl" szépen kiír mindent hogy mi fut/mi nem/mit indítottak el és halt le közben, sőt ha valami ami nem indult el, meg lett javítva, akkor az el nem indult scriptekek is elindítja (ha nincs rajta timeout)

Látod hogy nem indult el? systemctl status "ami nem indult el" és azt is kiírja hányadik sorban állt le milyen hibaüzenettel.

Így ha belegondolok sokkal könnyebb debugolni és használni mint a többit. Az tény viszont hogy más a felépítése (tanulni kell) és rávenni pl. arra hogy elindithatnád de légyszi-légyszi ne indítsd el, mert várd meg hogy a másik, párhuzamos X induljon el előbb (mert pl az indítja el automatikusan a pulseaudio-t) na azt nehezen érti meg.(El lehet indítani? Akkor el is indítom! sleep-et a többszálas hozzáállás miatt simán képes kihagyni)

A másikkal meg az a baj hogy egyes fejlesztők patikamérlegen kimérik hogyha A meg B elindult, akkor most már mehetne C is de jaj, egyeseknek ezt csak G,H fennállása esetén csak V után szabadna, de amúgy a többikenek 3x gyorsabb lenne... Azt találd meg mikor bevezetik, hogy neked milyen új paraméter értékét kell hol beállítanod és ne szívj vele három napot és légy szerencsés, hogy egyáltalán be tudsz lépni az upgradelt rendszerbe (és én pl. nem vagyok [foglalkozásilag] rendszergazda, hogy 8 órán keresztül olvassam a Debian upgradenél az 1006 oldanyi changelogs-t - ez pont múlt héten történt velem). És ezt a systemd-nél egyszerűen szépen és elegánsan meg lehet oldani úgy, hogy ebből nem veszek észre semmit.

Nem a systemd-t akarom debugolni, hanem a mogottes cuccot (marmint, amit elindit). Es a 'systemctl status' nem mindig irja ki, hogy miert allt meg, egyszeruen csak kiirja, hogy failed. Kosz.

A kedvencem meg a mysql meg hasonlok inditasanal van valami ask password vagy mi a loturo... es egyszeruen keptelenseg a) lebeszelni arrol, hogy elinditsa b) megtudni, hogy valojaban mi a nyugje. Mert hogy jelszot nem ker, az tuti.

Legutobb pl. azzal szivtam, hogy a nginx-be athoztam egy masik geprol a konfigot, es a pid fajl nem oda kerult, ahova a systemd varta. Azt hiszed kiirt _barmit_ is? Nem, fogta, es lelotte az amugy tokeletesen futo szervizt, csak mert nem volt hozza PID fajl. Es talald ki, hogy mi a nyug. Csak ket orat toltottem el vele.

Gentoo-nal nagyon szepen megoldottak a fuggosegkezelest, annal tobb/szebb/jobb nem kell.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Már megbocsáss de ha mondjuk nem indulna el valamelyik service, akkor megnézem mi van benne, beállítom a környezeti változókat ahogy ő állítja be, majd elindítom az adott dolgot azzal a paranccsal amivel ő indítaná. Majd elolvasom a hibaüzenetet

Pont a Gentoo-nál volt ilyen problémám amit fentebb leírtam. Meg mondjuk merészeltem _kézzel_ hozzányúlni egyes indító scriptekhez (egyszerűen mert hozzá kellett), majd frissülés után állt a gép bambán, mert sikerült cirkuláris függőséget létrehozni az OpenRC ezt meg egyszerűen nem vette észre és lefagyott. (Azt nyomjad gyorsan az "I"-t bootolás után mert fennakad a szeme.) És a Gentoo-nál nincs is tool rá hogy ellenőrizd hogy jó-e... A systemd viszont simán kiszúrta indulásnál ha cirkuláris függőséget csináltam neki véletlenül és ettől még elindult a gép.

Vagy amikor a Gentoo-nál nem indult el valami rendesen, de ahogy debugoltam mindig jó volt. Ha élesben ment, valami nem indult el elég gyorsan, és a rá épülő szolgáltatás sz*rt elindulni (már marhára nem emlékszem mi volt az azt hiszem a lirc/X sorrendjével volt valami). Nem akartam bevenni függőségek közé mert pont az csinálta a cirkuláris függőséget, és ha beveszem akkor minden emerge --update után fél óra kalapálás és káromkodás.

Szívni mindenütt szív az ember, csak az a kérdés mekkorát.

init scriptnel siman raakasztod, strace-t hogy kovesse a service indulast. systemd -nel ez nem ilyen egyszru.

Eleg complex dolgok szokatak nalam most elokerulni, ugyhogy systemtap alkalmazasa egyre fontosabbnak tunik.

Egyebkent nagyon nagy josag a systemd, en distrot is valtanek, ha nem lene elerheto :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Minden fontos kernel symbolum be es kilepeset ill. paramatereit, belertve a syscallokat is. Kepes userspace alkalmazasok cimeire is ratapadni ill. egyeb kernel beliekre, VM beli pontokra ..

System wide strace -kent hasznalhato a ptrace(2) limitacioi nelkul.
Performance/latency testek...

Viszonylag egyszeru dolog: amikor tudod mi az az aktivitas , de nem tudod melyik folyamat ill. hol koveti el, akkor jol johet.

Pilota vizsgat elobb le kell rakni, addig nem repul.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Systemd es tarsairol nice irt, en elso korben ot kerdeznem.

dap jol mondja, a kettoben kb. annyi a kozos hogy systemel -kezdodik es 10 evenel fiatalabb :)

Melyik varosban ?
Menyire kepzett kozonsegnek ?
Mas tema is erdekel ?

Nem tudok igerni semmit, de alapjaban veve szivesen adok elo OpenSource/Linux temakoret erinto temaban.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Váááóóóó milyen jó kis anyagnak látszik! Köszi, ezt eddig nem ismertem. Ez ügyben akkor majd megkeresem először őt, de egyelőre csak tapogatózás van még hiszen messze még amikor lesz a rendezvény, egyelőre témákat gyűjtök és ha van akkor potenciális előadókat.

http://www.lok.hu , szeretnék a következő 2013 októberi konfon erről a témáról valamit.
Budapesten és rendszergazdáknak. ...azon belül viszont változatos tudásszinttel.

Igen egyébként a samba4 újdonságairól is szeretnék egy dupla előadást az első 45 perc gyors alapok, feltételezve hogy azért már látott sambát a másodikon meg konkrét példák rámászva a group policy-re.

...lassan körvonalazódnak még más 5letek is, eddig ez a két fix téma az admin szekcióban, amit szeretnék.

Rózsár Gábor (muszashi)