CRUX the last sane distro

Gondold végig, hány olyan alkalmazás/service indul bootoláskor, amit párhuzamosítani lehet egy linuxos desktopon!
Mennyit nyerhetsz vele időben? 10-20mp a maximum, amit el tudok képzelni. (a leglassúbb gépemen is kb. egy perc a grub menün nyomott enter után mire megjelenik a login - ubuntu 12.04)

Szerveren meg ott a gond, hogy egy sshd kaliberű szolgáltatás indítása másodperceket sem vesz igénybe, a lassan induló applikációk meg többnyire egymásra épülnek, esély sincs rá, hogy párhuzamosan indítsd őket.

Windows boot gyorsulásáról nem igazán van infóm, nem tudom, konkrétan mi változott. Azt tudom, hogy a login hamar megjön, de bejelentkezés után rendszertől függően, sokszor percekig indulnak még a különböző szolgáltatások, amik nélkül valójában használhatatlan a rendszer (lásd 3rd party tűzfal, víruskereső)
Telepítés után még gyors, de pár hónap, egy-két év után... a Vista kb. húsz percig fűrészelt minden reboot után, a win7 csak 5-6 percig.

De ezek nagy része olyan gyorsan indul, hogy nem lesz számottevő a gyorsulás, a többi meg egymásra épül: pl. adatbázis-middleware-web szerver trió.
A samba so so, határeset.
(systemd mellett van cron? Mintha azt láttam volna, hogy a syslogd-vel együtt kuka)

acsi gitar! Ez mi, amit te itt leirtal, karacsonyfa? Milyen szerver az, amin ezek egyszerre futnak? OK, biztos van olyan dev szerver, amire ezek mind kellenek (vagy inkabb megsem), de hogy a production szerverek 99+%-a nem ilyen, arra a nyakamat teszem. Nem tudom, nalatok mennyi minden fut 1 szerveren, de foleg a 8-16 cpu-s gepek vilagaban (amelyek eleve virtualizacioert kialtanak, amivel szepen, korrekt modon szegmentalni lehet a szolgaltatasokat) ez finoman szolva a kaosz, mintsem a prudens rendszerradminisztracio szinonimaja.

Diktatorok kezikonyve

Beírom a válaszaimat a tieid közé. Kékkel, hogy áttekinthetőbb legyen. Remélem azt a színt szabad használni. Ha nem, majd trey szól, és többé nem teszem.

"Na de ami a log fájlokat illeti, na az a perverzitás csúcsa ha épp az nem text alapú! "

Ja, hatékony keresés az perverzitás. Egy ilyen text fan ismerős is csinált naplót egyszer egy Minecraft szerverhez, hogy vissza lehessen nézni, hogy mit csinál egy-egy player. Aztán hamar rájött, hogy ahhoz picit lassú lesz a text.

Akkor az ismerősöd rosszul tervezte meg a naplóformátumot. Attól hogy valami text alapú, lehet hogy nem csak 1 állományból áll. Azaz lehet ám indexállományt is csinálni hozzá. De többnyire az se kell. Nemrég írtam például egy démont, s az is naplóz. Értelemszerűen minden sor a dátum-és időstringgel kezdődik. S mert többnyire azért lehet tudni, melyik nap lép fel a hiba, elég csak a sorok elejét figyelni/ellenőrizni/összehasonlítani, s a többi adattal csak akkor foglalkozni ha a keresett nap dátuma lett épp beolvasva.
Az ismerősödnél pedig megsaccolom, lehetett volna playerenként külön fájlt csinálni. Mondjuk itt lehet hogy tévedek mert gőzöm sincs a játékokról. De első tippre nekem ez ugrik be.
Továbbá, a spec bináris formátumokban csak azzal a módszerrel kereshetsz/kutakodhatsz amit direkt arra gyártottak. Text fájlban bármivel ami létezik a világon. Find, grep, perl, awk, regexp, meg az ég tudja mi minden még. Csak a fantáziád szab határt.

"Na és ha baj van, akkor egyáltalán nem szükségszerű, hogy épp a speciális bináris formátum kezeléséhez szükséges eszközök még működjenek."

Erre rengeteg jó megoldást kitaláltak már az évek során.

De most egyet se említettél meg... mindenesetre, 2 eset van: vagy te fejlesztetted ki a formátumot, vagy más. Ha te, akkor kisebb a veszély, de akkor se nulla. Ha más, akkor opensource vagy nem. Ha opensource, kisebb a veszély mint ha nem, de akkor se nulla, mert nem szükségszerű hogy legyen a cégednél szakember aki épp ahhoz a speckó akármihez ért. Ha van is ilyen, lehet hogy épp szabin van amikor a baj beáll. Vagy beteg. Vagy meghótta magát mert a fejére esett egy balkon. Vagy előző nap mondott fel. Vagy ott van nálad, de a baj épp abból áll hogy pont azok a progranyok törlődtek le (vagy azok valami függősége) ami kell a bináris formátum feloldásához, de ezt nem tudja megállapítani rögvest, mert hogy ez a baj azt épp a naplófájlból tudná kiolvasni, de azt nem lehet mert hiszen épp az van abban a damned bináris formátumban...
Ha meg nem is opensource, akkor végképp gáz, mert akkor benne vagy a vendor-lock-in-ben...

" biztonsági kockázat"

Hahahahahahaha, RLY?

Az. Ha nem tudod a formátumot elolvasni azon a gépen ahol az állomány eredetileg készült, át kell vinned másik gépre hogy elolvasd. Az ilyesmi mindig kockázatos. Mert a másik gép lehet fertőzött, vagy az ottani dolgozó korrupt, ipari kém, vagy szimplán haragosod, vagy útközben elveszik a pendrive, vagy ha hálózaton át küldöd az adatot valaki lehallgathatja, akármi. Aztán, a bináris formátum olvasásához eleve egy külön program kell, amibe a fene se tudja mit kódoltak le, s vélhetőleg nem fogod átnézni minden kódsorát magad. Ilyesminek kicsi az esélye, elismerem, de akkor se nulla.

"Így jártam én is, egy aránylag közönséges progival, a MySQL-lel."

Irreleváns hülyeség, amit itt leírsz. Sajnos egyébként van egy rossz hírem, bizonyos adatmennyiség felett nem fogsz te text-et használni. Mert lassú lesz.

Attól hogy sommásan kijelented hogy irreleváns, nem lesz igazad. Tényt írtam le, amit nem cáfoltál. Ha nagyon akarom, a pontos hibaüzenetet is reprodukálhatom újra(bocs, csak warning, nem hibaüzenet) s leírhatom.
"Bizonyos adatmennyiség..." - lehet. De a DokuWikim bírja, s vannak nála messze nagyobb leterheltségű DokuWikik is, és azokkal sincs baj. Attól hogy valami text alapú, simán lehet kitalálni olyan állomány- és indexrendszert, hogy nagy valószínűséggel többnyire csak a teljes adathalmaz egy emberileg elfogadható idő alatt kezelhető részét kelljen a rendszernek átnyálaznia. Különben is, ami a naplófájlokat illeti, azokat többnyire hamar törlik, de ha archiválják is, nem kell keresgélni bennük. Csak hiba esetén. Akkor meg mint fentebb említettem, az utóbbi napok sőt inkább csak órák eseményeiben, ami igazán nem vészes. És hiba különben is ritkán adódik.

"És nem fenyeget az a veszély, hogy gondolnak egyet a kedves fejlesztők, s hirtelen vége lesz valamelyik rendszerhívásnak ami muszáj a programomba."

Érdekes, hogy a MySQL backup/restore esetén mindig van valami érdekes meglepetés, de PostgreSQL-nek a bináris backup formátumával sosem volt bajom. Érdekes.

Nem a backupról és nem a restoréról beszéltem. Amint indítottam a szótárprogit, rögvest megjelent a warning. Azaz egy igazán frekventált, fontos hívásról volt szó. Szükséges a napi használathoz.
Különben meg, a PostGreSQL ritkábban áll rendelkezésre tárhelyeken mint a MySQL, s ha mégis többnyire plusz pénzért csak. Egyáltalán, ha a progi MySQL-re van fejlesztve, mit tehetnék? Az egyetlen biztos dolog a txt. Az mindenütt használható.

"Azért hogy nyerjenek 0.2 millisecundumot valamiben, ami naponta 1-szer kell "

Akkor most egy pillanatra húzzuk ki a fejünket a homokból és nézzünk meg valami más eszközt. Pl. TV-t. Vagy Settopboxot. Vagy mp3 lejátszót. Vagy hasonlót.

Tojok a TV-re. Vagy 20 éve nem nézek tévét. Tényleg. Úgy értem, persze néztem nemegyszer: amikor kimentem a konyhába ahol a nejem főz, ugyanis oda száműztem azt a ReklámWare superfluous zajládát, na olyankor amikor be volt kapcsolva és mondjuk várni kellett a kajára, hát akkor volt rá példa hogy akár 5 percig is bámulhattam. Többnyire addig se mert kikapcsoltam. Ha a nejem morgott emiatt, visszakapcsoltam, s inkább bevittem a kaját a szobámba.
A settopboxról azt se tudom micsoda. Tippelem hogy valami játékizé. Nos, nem szoktam olyannal élni.
Mp3 lejátszóm van. Nem tudom az hogy jön ide. Nem vettem észre hogy bootolna, de ha azt teszi is olyan hamar teszi, hogy nem észlelem. Minek kéne ezt gyorsítani? Egyáltalán, ezeket a kínnal szült példákat felejtsd el. Magasan nem érdekelnek. Tőlem ezekbe tehetnek a gyártók amit akarnak. Ezeket ugyanis nem akarom se programozni, se "személyre szabni". Én a legkifejezettebben csak és kizárólag a magam desktop gépéről beszélek (ami jelenleg laptop, de ha nem az lenne akkor is desktop volna). Szerintem azért annak elég más ám a feladata és szoftverkörnyezete mint egy mp3 lejátszónak nevezett "zenemorzsa" célkütyünek. Az egy speckó céleszköz, egyszer beleégetik a progranyját oszt' jóóvan. Az én gépem "általános célú" kütyü, s elvárom hogy ha turkálni akarok benne lehetőleg azért ne kelljen 2 évente újratanulnom épp a legfontosabb rendszerkomponensek kezelését/paraméterezését stb. Mert ha valami ritkábban használt progiról van szó, azt mondom oké, teszek rá. De már azért az init, meg hasonlók...
Nekem a Grub2 se tetszik. Olyan érzésem van, hogy egy komplett operációs rendszert írtak csak amiatt, hogy azzal indíthassák a tulajdonképpeni operációs rendszert. Már egy ideje vele élek és tanulom, de még mindig messze vagyok attól, hogy legalább annyira felfogjam és olyan magabiztosan kezeljem mint a Grub1-et, holott nem állítanám hogy azt is ismertem volna minden részletében. De azzal azért elvoltam. Na de ez... Ilyenkor visszasírom az ESZR gépek idejét ahol ifjúkoromban operátor voltam. Ott egy "IPL" nevű progi volt az, ami úgy távolról megfeleltethető a Grubnak funkciójában. Valami olyasminek a rövidítése ez hogy "Initial Program Load", persze tuti rosszul írom. Nem baj. Na olyan egyszerűnek kéne lennie egy rendszerbetöltőnek. Ezzel szemben most...

-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

Valószínűleg nem volt deprecated, amikor csinálta, csak időközben azzá vált, az eltelt idő alatt.

Na de ez épp engem igazol: ha valamit meg lehet oldani egyszerűbben, azaz kevesebb programmal, akkor csináljuk úgy. Biztos akadnak feladatok amikhez nagyon muszáj adatbáziskezelő, de az én szótárprogramom a közelében sincs annak a bonyolultságnak, ami a MySQL-t igényelné.
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

Te hoztad a windows-t példának, olvasd már vissza magad! :D

Nem, épp hogy a szerverek világából indulok ki, csak másodsorban desktopból.
Szerveren ritka a boot.
Desktopon meg nem fut annyi alkalmazás, hogy érdemes legyen energiát pazarolnom a boot optimalizálására.

"Olyan, mint a windows" == "bináris, tehát ha valami elkefélődik, az életben ki nem bogozom, mi baja volt", míg egy text alapú lognál, konfignál elég egy bármilyen rendszer, ami kezeli az adott fájlrendszert és van rajta vi.

Konkretizálva: win7-re telepített virtualboxban van egy ubuntu 12.04-es desktopom, teleszemetelve minden szeméttel, amit kipróbáltam az elmúlt kb. két évben, a memória 2GB-ra korlátozva, CPU (i5-2520)-ból egy magot használ, a diszk meg egy viszonylag ócska seagate momentus, ha jól emlékszem.
Kb. két-három éves konstrukció, én két éve vettem a vasat.

No, ennek a rebootja(! - shutdown, grub timeout, boot) volt összesen 34 másodperc.
És ebben benne van az apache felhúzása, a postgresql+mysql indítása kis méretű adatbázisokkal, meg a gnome indítása is.
A desktop gépem, amit mostanában néha-néha szerverként használok, ennél talán 10mp-cel lassabban bootol. A hardvere kb. 7-8 éves.

Oké, monitoring bejelez, onnantól kezdve mi veszi át a probléma lekezelését?

ez ugyben nincs kulonbseg: monitoring bejelez ES ettol fuggetlenul az init/svc/whatever jelenleg is elerheto cucc ujra tudja inditani a szolgaltatast - ha olyan a problema.

Akkor vegyük hozzá azt is, amikor a cloud-ban dinamikusan indulnak, leállnak virtuális gépek. Meg monodm, ne csak szerverben meg notiban gondolkodj.

ok, de mondjuk az android-os telefonokat, tableteket es mas konzumelektronikai kutyuket most kihagynam, ahol amugy sem jatszik a dns, samba, levelezes, stb. karacsonyfa effektus. Nem tudom, milyen cloud-ra gondolsz, ahol a gepek dinamikusan hol elindulnak, leallnak, stb. de meg mindig mondvacsinalt problemanak tartom, hogy mondjuk egy amazon ec2-ben levo cucc boot idejenek 5 sec-es sporolasa valoban tetel (mondjuk azt meg kotve hiszem, hogy a fentebb felsorolt 50 cuccot te rateszed egy felhoben levo gepre).

Diktatorok kezikonyve