init helyettesítőn dolgozik az Ubuntu

Ubuntu

Az Ubuntu azon dolgozik, hogy lecserélje a jelenleg széles körben használt init daemont. Az új implementáció neve "upstart". A fejlesztése már megkezdődött. Az upstart nem csak init helyettesítő, hanem cron, anacron és inetd helyettesítő is lenne.

Az ütemterv szerint már az Edgy Eft kiadása környékén megkezdődik az integrációja, és az Edgy+1 és Edgy+2 idején folyik a majd tovább.

Hogy az upstart miben különbözik a Mac OS X-es launchd-től, a solarisos SMF-től vagy az új generációs initng-től? Hogyan működik? Mi szól mellette? Megtudható itt.

( dikki | 2006. 08. 27., v – 18:34 )

"Az ütemterv szerint már az Edgy Eft kiadása környékén megkezdődik az integrációja, és az Edgy+1 és Edgy+2 idején folyik a majd tovább."

sőt: edgy+2-től már kötelező lesz alá fejleszteni mindent, anélkül nem fogadják el a csomagot :o

( davs | 2006. 08. 27., v – 18:56 )

Szerintem felesleges...Olyan, mintha új kernelt akarnákak csinálni. Gondolom eltér majd az init-tol, szal jon megint a keveredés, kell csinálni init-re, upstart-ra csomagokat stb...Sok plusz munka lesz csak szerintem. Az initet meg véleményem szerint nem fogják tudni globálisan lecserélni...Ezt csak mi szívjuk meg egy kicsit...

"For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants."

Nem kell agodni, ha lusta valaki megtanulni, menni fog a regi is.

Kivancsi lennek kinek lenne batorsaga, a mostansag hasznalt make|configure|auto.* cuccokat levaltani.. (Az egeszet ujra gondolni, es felturbozni)

Mar tuleltunk jo par valtast, ezt is tuleljuk..
(statikus->devfs->udev, apache->apache2, gtk->gtk2,..stb )
En kivancsian varom, es amint lehet felcuccolom a gentooimra..

svn: annyi köze van a cvs-hez, hogy a megálmodói a cvs hibáit és előnyeit alaposan elemezték és kigondoltak egy olyan teljesen új rendszert, ami a cvs hátrányait kiküszöböli, de nyújtja ugyanazokat az előnyőket. Amúgy meg a két rendszer gyökeresen eltér egymástól. Kb. fél éve tértem át cvs-ről svn-re.

make leváltása: bizony mindenhova beitta magát a kis féreg, de már nagyon elavult. Ha előveszel egy C/C++ programozási könyvet, akkor automatikusan nyomatják benne a make-et, talán még a tanárok is, sok fejlesztőeszközbe bele van integrálva. De létezik a C/C++ nyelven kívül is világ, ahol általában a make-et nagyon hanyagolják. Láttam már komoly projektek make-ről scons-ra átállni!

Vannak dolgok, amik gyorsan változnak és vannak, amik sokkal lassabban, de azok is változnak!

scons nagyon jó, én átálltam rá. Helyből kezel olyan dolgokat, ami make alatt eléggé fejfájos, vagy szinte lehetetlen. Viszont ha a parancsokat tudod, amiket végre kéne hajtani, akkor scons-ban macerásabb. Amúgy python-ban írták és maga a build script-et (SConstruct) is python-ban kell megírni, de olyan jó a tutorial, hogy nulla python tudással nagyon sokra lehet jutni.

A cvs-nek nagyon erősek a gyökerei: egy rcs fölé épített rendszer.

Szerintem nagyon is szukseges, a mostani init egy oskovulet ... Nem veletlen talan, hogy meg Solaris-ban is "modernizaltak" a dolgokat kicsit, pedig van amiben nem ok szoktak vezetni a modernizalo mozgalmakat tipikusan :) Az ma mar tenyleg nevetseges kicsit, hogy komoly szolgaltatasokat daemon-okat stb elindit az init aztan "el is feledkezik" roluk, ha kihalnak annyi, se ujrainditas, se vmi report generalas, semmi. Ez azert eleg durva, mi pl eddig is sajat megoldasokat hasznaltam, ahol egy "felugyeleti reteg" inditgatta a cuccokat, es "vigyazott" rajuk. Meg az is igaz, hogy a vilag modernizalodik, a "bedrotozott" sorrendu, finomabb dependency nelkuli initscriptesdi regen elment, ma mar eleg nehezkes, ugyanis egy csomo olyan dolog jelent meg, amit nem feltetlenul lehet tudni, hogy mikor mire kell dependalnia, lasd pl hotplug eszkozok (regen ugye a szamitogeprol "nem volt illendo" semmit lehuzni/csatlakoztatni "menet kozben", ez ma mar azert kisse elavult nezet). Solaris alatt a SMF pl egesz turheto, elmult napokban jatszottam pont vele.

"Az ma mar tenyleg nevetseges kicsit, hogy komoly szolgaltatasokat daemon-okat stb elindit az init aztan "el is feledkezik" roluk, ha kihalnak annyi, se ujrainditas, se vmi report generalas, semmi."

respawn

Ha meg initscriptből induló cuccok, akkor arra ott a daemontools, bár ott a background/fork dolgokkal kell vigyázni, bár most már a syslog-ng kezelése is megy belőle szépen.

Akkor Gabu szavait félreértettem (tudom, hogy helybenforgatós btw), de nem fogom fel, miért ne futtatnák BSD-ken - OK, persze MAC-en nem futtatják, mernemtrendi meg nem üb3rc00l.
--
Mortal Kombat's gimmikk was to replake all instankes of the letter 'C' with the letter 'K' (bekause of that feature, it was one of the first applikations to bekome part of KDE).

Én azt nem szeretem emellett az init tudásában, hogy nincsenek olyan kategóriák, amik egymástól függetlenek.
Vannak a runlevelek, aztán jól van.

Készítettem olyan rendszert az előző laptopon, hogy 2-es szint volt hálózat nélkül, 3-as hálózattal, 4-es pár egyéb dolog, ami normál esetben nem kellett.

Kínszenvedés volt karbantartani, a csomagoknak gőzük nem volt arról, hogy szerintem melyik runlevelre tartoznak, frissítéskor kézzel kellett utánaállítgatni, stb.

Mennyire jó lenne hozni néhány kategóriát, mint mondjuk internet, otthon, cég, és ha a csomagoknak beállítani, hogy ha nincs internet, te nem futhatsz. Ha otthon vagyok, te nem futhatsz. Ha van internet és a cég is aktív, akkor te futsz.

Tudom, vannak csomagok, amik pl. megpróbálják kitalálni, hol vagyok, és erre scripteket indítgatnak el.

De én azt szeretném, hogy ez legyen egy rendszerbe integrálva. Esetleg én kézzel tudjak bekapcsolni környzeteket (ahogy most tudok init 3-at mondani) pl. init (startup, akármi) A-ügyfél, akkor azokat indítja el, amiket mondjuk A-ügyfélnél futtatok, az a webszerver, azzal az adatbázissal, ilyesmi, hogy tesztelhessek.

G

Nem tom a linuxos init milyen, rendes UNIX alatt van a, b, c futási szintek is, amiket magától soha nem hazsnál. Te viszont rakhatsz oda is dolgokat,és persze init b -t is mondhatsz. És ez a 3 szint még a hülye lentről-fölfelé/föntről-lefele elvet sem követi, teljesen független a többitől. Nem pont az ami neked kell, de közelít.

( BikMak | 2006. 08. 27., v – 19:07 )

végre gyorsabban indul majd a desktopom:)

( Husky | 2006. 08. 27., v – 19:29 )

Össze kéne zutyulni a swsusp-pal. Minden bootolás után gyárthatna egy mem.image-et az épp elindult daemonokról. Aztán rebootkor csak körbenéz hogy változott-e valami... ha igen, normál boot, ha meg nem, akkor csak előrántja a múltkori boot eredményét.

( tolmi | 2006. 08. 27., v – 19:39 )

Végre VÉGRE!!!

No de félre a tréfát. Örültem volna, hogyha az SMF-et portolják. Annak több értelme lett volna. Még akkor is hogyha néhány dolgot abban meg is kellene változtatni. Tényleg felesleges ez a még egy init replacement.

"Tényleg felesleges ez a még egy init replacement."

Látom elolvastad a belinkelt oldalt.

1. Nem csak init replacement
2. a meglevő init "hibáit" javítja, tehát ha jobb lesz, akkor nem felesleges

"Örültem volna, hogyha az SMF-et portolják."

"SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking."

Kívánságod részben teljesült.

--
trey @ gépház

Egyrészt: Elolvastam a cikket.
1)Valóban. Miközben veri az őklét a falba, hogy a D-BUS ne process managerkedjen, majd az upstart:
"The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs."
Szóval akkor hogy is van ez, hogy egy feladat, de azt jól?! :) Lényeg hogy nem szeretném ha a(z) (ana)cron-omat kicserélné...

2)Nos, valóban nem lenne felesleges, de tulajdonképpen ahogy már fentebb is írták, egy újabb megoldást kell megtanulni, egy újabb megoldást kell használni a fejlesztőknek. Mindezt el tudom fogadni, ha akkora előnyt hoz olyan módon hogy az nagy valószínűséggel de facto szabvány lesz. Erre ez nem igaz. Csak az hogy jól beújít. Arra akartam utalni, hogy az SMF-re igaz a fentebb említett UNIX filozófia, valószínüleg de facto szabvány lesz a SysVinit mellett/helyett, ezért szerencsés lenne használni azt az XML alapú leíróhalmazt, ami hajtja az SMF-et. Igen, még akkor is, ha ez eseményvezérelt és el kellene dobni ezt a megközelítést. Egyszerűen nem látom, hogy miért lenne sikeres az ekkora energiabefektetés. TÉNY hogy baromi jó az ötlet, de sajnos szkeptikus vagyok a leendő elfogadottságával kapcsolatban(azonnal visszavonnám mindezt, ha a RedHat és/vagy Novell is beszállna a dologba). Túl sok pluszmunkát igényel a maintainerektől.

"Kívánságod részben teljesült." Ideje volt már. :) Untam hogy ezen bukok sok kis 10 perceket, meg kásztömszkripteket bütykölnöm a korrekt process managementhez.

Én nem akarok ezen trollkodni, csak a véleményem próbálom elmondani(néha elég kacifántosan). Ettől a véleménytől függetlenül üdvözlöm a kezdeményezést, mert ha ezt végigcsinálják és átverik a közönség sűrű palánkján, akkor egy picit az új Linux világ kapuja fog feltárulni. Legyen úgy ;)

"Szóval akkor hogy is van ez, hogy egy feladat, de azt jól?! :) Lényeg hogy nem szeretném ha a(z) (ana)cron-omat kicserélné..."
Miért? Most nem arról van szó, hogy írnak egy progit, ami több feladatot lát el egyszerre, hanem arról, hogy a jelenlegi helyzetben egy feladatot lát el több progi. Végülis az init, cron, anacron is jobokat indit. Most majd egy cucc fogja csinálni.

Nem. Számomra az ő értelmezésük rossz. Nem technikailag kell egy proginak egy feladatot ellátnia(ahogy ők gondolják), hanem egy magasszintű problémát kell kezelnie egy programnak. A cron és az init szerepe NEM keverendő a UNIX filozófia szerint. Én nem mondom hogy ez rossz, én azt mondom, hogy nekem ez nem annyira tetszik. :)

"Tényleg felesleges ez a még egy init replacement."
Azért a dolognak van egy jó oldala is: van egy új igény a piacon (pl. 3D desktop, gyorsabb indulás, virtualizáció, stb.) és erre mindenki beindul, elkezdenek fejleszteni gőzerővel. Néhány elterjed, a többi nagyjából elhal (eltekintve attól a pár fanatikustól, akinek valami miatt az egyik másik annyira megtetszik, hogy nekiáll továbbvinni még a kevés felhasználó ellenére is). Ami végeredményeként a legéletképesebb megoldás fog megmaradni (szemben a zárt forráskódú világgal, ahol azt mondja a gyártó, hogy nesze ez van, ezt kell meg(v)enned). Az már más kérdés, hogy az életképesség nem tisztán szakmai, hanem függ más tényezőktől is.

( crown v | 2006. 08. 28., h – 00:08 )

Hat, ubuntu-ban (edgy) van 0.1.1-1 verzio belole, de jo nagy " THIS PACKAGE IS EXPERIMENTAL, YOU INSTALL IT ON YOUR SYSTEM AT YOUR OWN RISK. " figyelmeztetessel.

Kivancsi lennek, most ez mennyire experimental valojaban.

( mpathy | 2006. 08. 28., h – 03:57 )

Érdekes. Ez az eseményvezérléses dolog mennyire lesz vajon Linux specifikus? Úgy értem más Unix rendszerek mennyire támogatják az ilyemit? Elképzelhető, hogy nem Linux rendszereken is leváltja egyszer az init-et?

( wwrreecckk | 2006. 08. 28., h – 19:10 )

Szerintetek nem inkább az InitNG projektet kellene felkarolnia, átalakítania ububtu-éknak?