Fórumok
Találtam egy érdekes cikket a fork-ról:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=14&cad=rj…
Találtam egy érdekes cikket a fork-ról:
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=14&cad=rj…
Hozzászólások
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hoto… ha bárkit érdekel.
Bele kell tenni a fork()-ot is a systemd-be! Problem solved!
Tehát akkor dobjuk ki mindenhonnan a
-ot, de mit javasolnak helyette?
Három konkrét alternatívát is felsoroltak (
,
,
), de ebből a
egészen konkrétan nem a
-nak, hanem a
+
kombónak a kiváltására való (ja és még nem tökéletes, de bezzeg a windózos
), a másik kettőt meg lehúzták, hogy igazából nem jó, tehát működő drop-in replacementet nem mondtak.
Arról nem is beszélve, hogy a
-ot nem csak az
-kel párban szokták használni: ezeken a helyeken az általuk preferált és javasolt
nem válthatja ki a
-ot. Ugyan felsorolnak pár - szerintük már nem életszerű, túlhaladott - példát az
nélküli
használatra, de ez meg hiányos, pl. a daemonok is hiányoznak belőle és ott a child process megy tovább a szülő helyett (a szülő kiszáll) és pont ezért ott a legjobb a
ebből a szempontból, mert ott tényleg az egész process-t másolni kell, címterestől-mindenestől (
ezzel ki is esik) kérdés nélkül, amit ugyan lehet, hogy meg lehet oldani pl. a
segítségével is, de az meg Linux-only...
Ennek megfelelően a
kihajítására az nem lehet érv, hogy a
jobb, mint a
+
kombó. Félreértés ne essék, azt nem vitatom, amit leírtak a
problémáiról, de amíg nincs rá cross-platform POSIX alternatíva, amivel a
funkcionalitása is 100%-ig megvalósítható, addig nem lehet levesbe küldeni.
Kezdésnek azt, hogy az utolsó lépésként dobjuk ki a forkot :)
Az utolsó részben szépen sorban írják:
1. Deprecate fork
2. Improve alternatives
3. Fix teachings
(4. Drop fork)
Szvsz. nem is akarják a levesbe küldeni, de amíg nem beszélünk a problémákról, amik megoldására kell az alternatíva (ami egyébként látod, már részben van is, fel is tudták sorolni), addig senki nem fog standardizálni egy alternatívát...
Tippre ezt ők is úgy gondolták, mint a Wayland bevezetését: bedobnak egy problémát (szar az X11 - szar a fork), előbb-utóbb valaki tesz javaslatot, az átmegy kismillió bizottságon és kismillió OS implementálja (Wayland protokoll és összes implementációja - [ez még itt nincs]), aztán aki nagyon nem akarja átírni a kliensét, az kap egy kompatibilitási réteget (XWayland - [még nincs: az új API használatával emulált fork() hívás]), aztán talán évtizedek múlva már ki lehet kapcsolni a kompat réteget is...
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> Kezdésnek azt, hogy az utolsó lépésként dobjuk ki a forkot :)
Lényegtelen, hanyadik lépésként akarják kidobni, ha nincs az előtte lévő lépések között, hogy "invent alternatives". Az "Improve alternatives" nem elég: miféle alternatíváról beszélnek? (BTW, ami a "Fix teachings"-ot illeti, külön viccesnek tartom, hogy szerintük a windózos
-t kéne tanítani, amikor az a téma, hogy hogy futtatunk külső programot egy UNIX processen belül.)
> Szvsz. nem is akarják a levesbe küldeni, de amíg nem beszélünk a problémákról, amik megoldására kell az alternatíva (ami egyébként látod, már részben van is, fel is tudták sorolni), addig senki nem fog standardizálni egy alternatívát...
A
nem simán a
-ot váltja, hanem a
+
kombót. A
semmiképpen sem másolja a címteret, míg a
mindenképpen, ergo a
nem alternatívája a
-nak. A
lehet, hogy használható lenne (nem néztem át a paraméterezését), de Linux-only. Van olyan POSIX-compliant megoldás, ami 100%-ig tudja "emulálni" a
funkcionalitását? Ha nincs, akkor nem lehet a
-ot kidobni és nincs mit "improve"-olni se. Ők legalábbis nem soroltak fel semmiféle használható alternatívát, ami minden platformon kiválthatná, tehát még részben sem adtak megoldást.
Azt meg senki nem mondta, hogy ne beszéljünk a problémákról, azokat én sem vitattam, amiket a
ellen felhoztak, de az kevés, hogy a
monnyonle, ki is kell tudni váltani valamivel. Mindenütt.
> Tippre ezt ők is úgy gondolták, mint a Wayland bevezetését: bedobnak egy problémát (szar az X11 - szar a fork), előbb-utóbb valaki tesz javaslatot, az átmegy kismillió bizottságon és kismillió OS implementálja (Wayland protokoll és összes implementációja - [ez még itt nincs]), aztán aki nagyon nem akarja átírni a kliensét, az kap egy kompatibilitási réteget (XWayland - [még nincs: az új API használatával emulált fork() hívás]), aztán talán évtizedek múlva már ki lehet kapcsolni a kompat réteget is...
Ja és pont ugyanaz a baj ezzel az egésszel, mint a Wayland-del. Az oké, hogy az X11-nek már minden baja van és amúgy is agyfasz programozni (tudnék mesélni, két éve poénból elkezdtem fejlesztgetni egy saját toolkitet rá), nem is erre találták ki anno, stb. A Wayland-et ugyan nem ismerem, tehát érdemben nem tudok róla nyilatkozni, nem tudom, hogy jó-e, vagy sem, de azt tudom, hogy Linux-only. Illetve nem egészen, mert unofficial FreeBSD/DragonFlyBSD támogatás van. De a többi BSD-vel, Solarisokkal, AIX-szal, HP-UX-szal és egyebekkel mi lesz? A kompat réteget a hajukra kenhetik, mert az visszafele működik: az X11-only cuccokat lehet vele futtatni Wayland alatt, de a Wayland-only cuccokat hogy futtatod Wayland nélküli rendszeren? Ez megint ugyanaz, mint a GNOME3 systemd függése: hiába akarná valaki felrakni a szükséges függőséget, ha nincs a rendszerére.
Megfordítom: ha a BSD, Solaris, AIX, HP-UX stb. majd akar magának normális desktop alkalmazásokat, akkor hozzáfejlesztik a Wayland támogatást.
És ha GNOME3-at akarnak, akkor meg portolják a systemd-t?
Ha valaki egy cross-UNIX ökoszisztémát akar leváltani, akkor nem ártana, ha amivel váltani akarná, az alkalmas is lenne rá és nem a felhasználóktól várná, hogy megcsinálják arra. Itt nem egy opcionális új programról beszélünk - amit kiadtak X rendszerre és ha valakinek majd kell egy másikra, akkor majd portolja, ha akarja - hanem a defacto UNIX ablakkezelőrendszer nyugdíjazásáról. Azt csak akkor lehet leváltani, ha az élő rendszereken már mind fut az alternatíva. BTW, ismervén a freedesktopos fejlesztési tempót, mi a garancia arra, hogy befogadják az alternatív rendszerek támogatására irányuló patcheket? Sokszor még a hibákat sem hajlandóak fixálni.
Speciel ők egy protokoll definíciót (Wayland) és egy referencia implementációt (Weston) adtak közzé, utóbbi valóban Linux-only. De az összes nagyobb DE ablakkezelője ilyen-olyan mértékben már támogatja a Waylandet (KWin, Enlightenment pl. van is BSD-re), ami továbbra is csak egy protokoll (és egy X11-hez képest triviális támogatni, annyira kevés dolgot tudnak kommunikálni).
Egyébként meg de, bőven elég, ha a saját rendszereire megcsinálja, ha az portolható/újraimplementálható más rendszerekre. Vagy melyik UNIX-okat (és szegény UNIX-like rendszerek?) kellene támogatnia _KÖTELEZŐEN_ minden projektnek? BSD, MacOS, Minix, AIX, HP-UX, Solaris, GNU Hurd, ...?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Egyáltalán, van valaki, aki ezeken a unix rendszereken GUI-t, és desktop alkalmazásokat futtat? És ha igen, akkor miért?
> Egyáltalán, van valaki, aki ezeken a unix rendszereken GUI-t, és desktop alkalmazásokat futtat?
A különféle BSD-ken és Solaris klónokon? Vannak. Sokan. Többszázezren. Ami persze elenyésző a Linux felhasználótáborához képest, de ez mindegy.
> És ha igen, akkor miért?
Mert az a desktop rendszerük? FreeBSD-sek pl. itt a hupon is vannak szép számmal, akik desktopnak használják. Open és NetBSD-st is láttam egyet-kettőt. Azt nem tudom, hogy rajtam kívül van-e itt olyan, aki Solaris desktopot is használ.
> De az összes nagyobb DE ablakkezelője ilyen-olyan mértékben már támogatja a Waylandet (KWin, Enlightenment pl. van is BSD-re), ami továbbra is csak egy protokoll (és egy X11-hez képest triviális támogatni, annyira kevés dolgot tudnak kommunikálni).
De nem az a baj, hogy a DE-k nem támogatják a Wayland-et, hanem az, hogy nincs Wayland Linuxon kívül. Hiába van Enlightenment BSD-re, ha Wayland viszont nincsen...
> Vagy melyik UNIX-okat (és szegény UNIX-like rendszerek?) kellene támogatnia _KÖTELEZŐEN_ minden projektnek?
Pedig leírtam, de úgy látszik nem ment át...na de akkor még egyszer:
Nem mondtam, hogy minden projektnek támogatnia kell mindent, hanem ellenkezőleg: még példát is mondtam, hogy egy új opcionális program csinálhatja, hogy kiadják X rendszerre, aztán majd portolják, ahova akarják. De ami egy UNIX-os alappillért, esetünkben az ablakkezelést akarja váltani, ott nem lehet eljátszani, hogy na, akkor a régi megoldás leves; a mainstream ablakkezelőket forceoljuk, hogy álljanak át erre, viszont implementáció csak X rendszerre van, a többiek pórul jártak.
És azt is leírtam, hogy ha az egész UNIX ökoszisztémát érintő változást akarok végrehajtani, akkor az élő rendszereket kell támogatni, amit használnak.
Wayland van pont annyira, mint X11, mert az egy protokoll. Weston valóban nincs, ami a referencia implementáció, de a HW - kernel - X11 szerver - WM - alkalmazás utat a Wayland lerövidíti HW - kernel - Compositor (ami egyben a régi X11 szerver és az ablakkezelő) - alkalmazásra (az utóbbi "-" meg egyébként GUI toolkit szinten meg van oldva a legtöbb toolkitben).
Speciel pedig BSD: https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-Wayland-Ava… 2017-es hír, hogy szó van arról, hogy alapértelmezetten Wayland támogatással fordítsák a dolgokat. VAN Wayland Linuxon kívül. (de BSD-s kérésre már API-t módosítottak: https://lists.freedesktop.org/archives/wayland-devel/2019-January/03986…)
Waylandben a mainstream ablakkezelők maguk a kompozitorok, nem kell hozzá külön még egy display server.
És még egy kis off: a standardizálás szép és jó dolog, de hagyni kell, hogy field testeljünk dolgokat, _mielőtt_ standardot írunk (és jó esetben nem pont azt specifikáljuk, amit csináltunk, hanem amit a tapasztalatok szerint egyértelműen elbacctunk, aztán már jobban oldjuk meg a standardban), különben lesz egy raklap használhatatlan szabványunk. Ráadásul időnként a standardokat is érdemes újra vizsgálni, hogy egy 200+ magos gép több terabyte RAM-mal ne feltétlenül a PDP-11 HW-jéhez igazított megoldásokat használja...
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> VAN Wayland Linuxon kívül.
Saját bevallásuk szerint unofficial a FreeBSD és DragonFlyBSD támogatás. Oké, lehet, hogy működik, de a többiekkel még mindig nem tudjuk mi lesz.
> (de BSD-s kérésre már API-t módosítottak: https://lists.freedesktop.org/archives/wayland-devel/2019-January/03986…)
Ennek örülök, de sajnos nem ez a jellemző.
> Waylandben a mainstream ablakkezelők maguk a kompozitorok, nem kell hozzá külön még egy display server.
Ööö...és? Hol fogja ez vigasztalni a non-Linux KDE usereket, ha a KWin eldobja az X11 támogatást?
> És még egy kis off: a standardizálás szép és jó dolog, de hagyni kell, hogy field testeljünk dolgokat, _mielőtt_ standardot írunk (és jó esetben nem pont azt specifikáljuk, amit csináltunk, hanem amit a tapasztalatok szerint egyértelműen elbacctunk, aztán már jobban oldjuk meg a standardban), különben lesz egy raklap használhatatlan szabványunk. Ráadásul időnként a standardokat is érdemes újra vizsgálni, hogy egy 200+ magos gép több terabyte RAM-mal ne feltétlenül a PDP-11 HW-jéhez igazított megoldásokat használja...
Ebben egyetértünk, de nem értem miért írod, mert én nem írtam olyat, hogy az X11-et kellene újraimplementálni újra és újra. Semmi bajom a Waylanddel, sose próbáltam, így nem tudom, hogy milyen, csak az bassza a csőröm, hogy a lassan felemelkedő új kvázi-szabvány windowing nagyon úgy tűnik, hogy Linux-only lesz. (Jó, oké, FreeBSD talán támogatva lesz...)
Az meg ugye egyértelmű, hogy nem várható, hogy ezek a Linuxhoz képest marginális méretű közösségek el tudjanak keríteni csak erre a célra annyi fejlesztői erőforrást, amivel viszonylag gyorsan implementálni lehetne, miközben ezer más bajuk is van.
Erre egy forrást adjál már. És ne a Weston referencia-implementációra, mert annál valóban, hanem a protokollra.
Ott, hogy ezt csak azután fogja tenni, hogy már hibamentes a Wayland compositoruk (most még defaulttá se merték tenni, nemhogy dobni az X11 támogatást :) ). Másik oldalról meg az alkalmazásnak kb. mindegy, mi megy alatta, ő úgyis egy GUI toolkitet használ (GTK, Qt), azokban meg még jó ideig marad az X11 támogatás (futásidőben dönthet a toolkit, hogy mit akar beszélni).
A viszonylag itt elég relatív, eddig 11 évük volt :) És továbbra is: itt nem a FreeBSD fejlesztőkre dobják át, hogy írjanak kompozitorokat, hanem a kompozitorok fejlesztőinek (GNOME, KDE, Sway, ...). Akiknek a projektjei már most is ott vannak a BSD-ben és működnek (a Waylandnek a stabil és hatékony működéshez messze nem kell annyi kernel taknyolás, mint anno az X11-nek).
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> Erre egy forrást adjál már. És ne a Weston referencia-implementációra, mert annál valóban, hanem a protokollra.
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)
Jobboldalt:
> Ott, hogy ezt csak azután fogja tenni, hogy már hibamentes a Wayland compositoruk (most még defaulttá se merték tenni, nemhogy dobni az X11 támogatást :) ). Másik oldalról meg az alkalmazásnak kb. mindegy, mi megy alatta, ő úgyis egy GUI toolkitet használ (GTK, Qt), azokban meg még jó ideig marad az X11 támogatás (futásidőben dönthet a toolkit, hogy mit akar beszélni).
Tehát magyarán arra alapozunk, hogy olyan sok idő tellik még el addig, amíg dobják, hogy addig csak készen lesznek az alternatív implementációk? Hát...
> A viszonylag itt elég relatív, eddig 11 évük volt :)
És ezzel meg is válaszoltad ennek a valószínűségét. :(
> És továbbra is: itt nem a FreeBSD fejlesztőkre dobják át, hogy írjanak kompozitorokat, hanem a kompozitorok fejlesztőinek (GNOME, KDE, Sway, ...).
Akik viszont nagy ívben tesznek mindenre a Linuxon kívül (ld. a GNOME3 systemd függését és a KDE is ezt tervezi, bár még nincs eldöntve), tehát indirekt módon a FreeBSD/Solaris/whatever fejlesztőkre testálják. (Igaz, hogyha a KDE és a GNOME3 systemd függő, akkor igazság szerint ezeknek a DE-knek a szemszögéből nézve mindegy, hogy van-e Wayland, vagy sem.)
> Akiknek a projektjei már most is ott vannak a BSD-ben és működnek (a Waylandnek a stabil és hatékony működéshez messze nem kell annyi kernel taknyolás, mint anno az X11-nek).
Nem védem az X11-et, könyörgöm; azzal kezdtem, hogy tudom, hogy milyen. A BSD-ben lévő projektekről meg annyit, amennyit az előző bekezdésben. És a BSD-kkel még mindig nem merítettünk ki mindent.
Az a Weston referencia implementáció lesz.
Egy csomó Wayland kompozitor van, ami elérhető nem-Linux rendszerekre.
Ugyanonnan:
Enlightenment, KWin, Sway biztosan ott van a FreeBSD portsban, a Claylandként linkelt Clutter szócikkben ugyanez a lista: Linux, BSDs, OS X, Microsoft Windows.
Mert mire alapozzunk? Döntsd már el, hogy mit vársz el a szoftver világtól, mert az _biztosan_ nem fog menni, hogy _valaki_ a 0. pillanatban előáll egy standard protokollal és legalább 3 cross-platform implementációval, ami mindenki problémáit azonnal megoldja, tökéletesen integrálható azonnal minden környezetbe és mindenen is elfut egy krumpliról hajtott GladOS-tól kezdve a 200+ magos szerverig...
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> Egy csomó Wayland kompozitor van, ami elérhető nem-Linux rendszerekre.
Maximum FreeBSD-re. Mi lesz a többivel?
> Mert mire alapozzunk? Döntsd már el, hogy mit vársz el a szoftver világtól,
Mi az, hogy "döntsem már el"? Én eddig is végig ugyanazt mondtam. Nem érted?
> mert az _biztosan_ nem fog menni, hogy _valaki_ a 0. pillanatban előáll egy standard protokollal és legalább 3 cross-platform implementációval, ami mindenki problémáit azonnal megoldja, tökéletesen integrálható azonnal minden környezetbe és mindenen is elfut egy krumpliról hajtott GladOS-tól kezdve a 200+ magos szerverig...
Mert élő és használt UNIX == krumpliról hajtott GladOS. Jól van haver. Ha megérteni nem tudod, amit mondok, csak kiforgatni, akkor ezt itt szerintem el is engedhetjük.
Megértem, amit mondasz, azzal nem értek egyet, hogy mindenki a 0. perctől csak a közös minimum metszetnek megfelelően implementálhasson bármit, és hogy mindenkitől elvárjuk, hogy támogasson olyan rendszereket, ahol egyrészt minimális potenciális felhasználójuk lehet, másrészt adott esetben mocsok drága a teszt rendszer. Erre van ott a rendszer gyártója.
Átfordítva: ha több tíz millió Linux user szív mondjuk HW gyorsítás nélkül, mert a 100 AIX usernél nincs ott a kernel támogatás a HW gyorsításhoz, akkor a legkisebb rossz az AIX support dobása.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Mondom, hogy nem érted. Én nem ezt mondtam, ezzel te jössz már sokadszorra. Ha nem írtam le ötször, hogy nem "mindenki", meg "minden projekt", akkor egyszer sem. Azt írtam, hogy amikor valami platformokon átívelő - értsd: mindenkit érintő - alap dolog lecserélése a cél, akkor. Ami mindenkit érint, abból nem lehet kizárni senkit. Többször nem írom le.
És ezt a 0. perc dolgot is te szajkózod, én egyszer sem mondtam. Nem az a baj, hogy nem támogatta alapból (a WIP az egy valid excuse, ha nem tart örökké), hanem az, hogy úgy néz ki, hogy nem is fogja. De ezt is leírtam már nem egyszer, de többször ezt se fogom.
Úgy semmi értelme válaszolni, ha nem érted, vagy nem akarod érteni, hogy miről beszélek, hanem helyette totál másra reagálsz, mintha én azt mondtam volna.
Ez egy Gizike vs. kerozinmeghajtású sivatagi jegesmedve kategóriás hasonlat volt. A HW gyorsítás egy plusz dolog, ha az ahhoz szükséges cuccok egyáltalán nincsenek meg az AIX kernelben, akkor nyilván nem lehet támogatni, de képet attól még kaphatunk. Nem arról volt szó, hogy a Wayland olyat tudjon, amit nem lehet, de nem is az a helyzet, hogy X és Y feature-ök nem elérhetőek E és F platformokon, hanem arról, hogy az egész nem elérhető A és talán B platformokon kívül.
Szeretnél még valamit belemagyarázni, amit én egyáltalán nem mondtam?
Te meg még mindig láthatóan nem akarsz különbséget tenni a protokoll (Wayland), a referencia implementáció (Weston) és az összes egyéb kompozitor (Sway, KWin, GNOME akámi, Clayland, ...) között. A protokollban semmi Linux-specifikus nincs (ill. ami van, az nem szándékos és az első levél után kezdődik az ötletelés, hogy cross-platform legyen). A referencia implementáció valóban Linux only, de mint a példa mutatja, portolható. A többi kompozitornak meg a saját döntése, hogy mit és hogyan fog támogatni.
Ami azt illeti, per pill. az X11 a kevésbé cross-platform dolog, ha túllépünk a best of 1970-es évek grafikai primitívein. 21 (!) éves az első DRI kiterjesztés az X11-hez, a Wiki szerint ennyi idő alatt "The various versions of DRI have been implemented by various operating systems, amongst others by the Linux kernel, FreeBSD, NetBSD, OpenBSD, and OpenSolaris.". Itt sincs sokkal több nem-BSD rendszer... sajnos, úgy tűnik, a többi rendszer érdeklődés hiányában elmarad...
Már bocs, de _TE_ vagy az, aki összemos random dolgokat (Weston _referencia_ implementáció követelményei a Wayland protokollal), és bár hoztam kismillió példát crossplatform Wayland kompozitorra, továbbra is ragaszkodsz ahhoz, hogy az valami Linux-only izé és hogy lett ki lett cseszve szegény Unixokkal.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> Te meg még mindig láthatóan nem akarsz különbséget tenni a protokoll (Wayland), a referencia implementáció (Weston) és az összes egyéb kompozitor (Sway, KWin, GNOME akámi, Clayland, ...) között.
Ha nem tettem volna különbséget, akkor fel tudtam volna tenni a KWin X11 eldobásával kapcsolatos kérdését? Akkor erről ennyit...
> A referencia implementáció valóban Linux only, de mint a példa mutatja, portolható.
A protokoll referencia implementációja, vagy a protokoll Linuxos implementációjának referencia implementációja? Ha az utóbbi, akkor igazad van. Ha az előbbi, akkor annak tartalmaznia kéne a többiek referencia implementációját is, nem?
> Ami azt illeti, per pill. az X11 a kevésbé cross-platform dolog, ha túllépünk a best of 1970-es évek grafikai primitívein.
Végülis csak az összes UNIX-on jelen van... Nem 1970-es szinten.
> 21 (!) éves az első DRI kiterjesztés az X11-hez, a Wiki szerint ennyi idő alatt "The various versions of DRI have been implemented by various operating systems, amongst others by the Linux kernel, FreeBSD, NetBSD, OpenBSD, and OpenSolaris.". Itt sincs sokkal több nem-BSD rendszer... sajnos, úgy tűnik, a többi rendszer érdeklődés hiányában elmarad...
Hogy azt nem érted, amit én mondok, az egy dolog. De, hogy azt se, amit a Wiki ír? "Among others" - a felsoroltak csak példák voltak és egyébként a "nem sokkal több BSD" az 3x annyi. És a Solaris is, az smafu? Hovatovább az előző példában leírtam, hogy az esetleges extrák hiánya egy dolog, de képet attól még kaphatnánk.
> Már bocs, de _TE_ vagy az, aki összemos random dolgokat (Weston _referencia_ implementáció követelményei a Wayland protokollal),
Nem, ezt csak te próbálod belemagyarázni.
> és bár hoztam kismillió példát crossplatform Wayland kompozitorra
Nem, te hoztál pár példát arra, hogy van olyan amiben van FreeBSD támogatás is. A crossplatform kicsit több ennél.
Na, akkor mégiscsak több rendszerre kell referencia implementáció? Miért? Különösen egy olyan dolognál, ahol kifejezetten fontos, hogy milyen kernel van alatta, amin keresztül kommunikál a HW-vel?
Ahogy Petőfi mondta: Idézni csak pontosan, szépen! "sincs sokkal több nem-BSD rendszer", szám szerint 1.
Ilyen is volt: Clayland.
De akkor menjünk bele az INSTALL fájljába (https://github.com/clutter-project/clayland/blob/master/INSTALL)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> Na, akkor mégiscsak több rendszerre kell referencia implementáció? Miért? Különösen egy olyan dolognál, ahol kifejezetten fontos, hogy milyen kernel van alatta, amin keresztül kommunikál a HW-vel?
Mégiscsak? Én végig azt szerettem volna, hogy legyen; hol írtam én olyat, hogy ne legyen?
> Ahogy Petőfi mondta: Idézni csak pontosan, szépen! "sincs sokkal több nem-BSD rendszer", szám szerint 1.
A "nem" szócskát benéztem. Te meg az "among"-ot, mert az a lista csak kivonat. Csak a DRI oldalán nincs feltüntetve az OS support.
> Ilyen is volt: Clayland.
> De akkor menjünk bele az INSTALL fájljába (https://github.com/clutter-project/clayland/blob/master/INSTALL)
Nem néztem végig az összeset, ezek szerint hiba volt, mert pont erre gondoltam támogatás alatt, mint amit a Clayland hoz. A kérdés már csak az, hogy ezek a kompozitorok mennyire "cserekompatibilisek" egymással, lehet-e majd pl. KDE-t használni KWin helyett Claylanddel. Ha igen, akár azonnal, akár némi munkával, akkor tényleg nincs gáz. Ha viszont nem, akkor hiába jó a Clayland - vagy bármely másik igazi crossplatform kompozitor - ott vagyunk vele, ahol a part szakad; ha a mainstream DE-k/toolkitek nem használják, akkor továbbra is kizárják a többi UNIX-ot; maximum ilyen fapad WM-ek lesznek rájuk.
Akárhányszor rákérdeztem, hogy mégis mi az, amit kötelező legyen támogatni. pl. itt: "tehát indirekt módon a FreeBSD/Solaris/whatever fejlesztőkre testálják."
Egyébként meg persze, hogy testálják, mert a display servernél (legyen az X11/Xorg vagy Wayland/akármi) akár mindenféle absztrakción keresztül (pl. DRI, udev, libinput stb.), de a kernellel és végső soron a HW-vel kell kommunikálni.
De akkor újra: mi lenne az a lista a UNIX/UNIX-like (mert én nem vagyok annyira kirekesztő, mint te ;) ) rendszerekről, amit te _kötelezően_ támogatandóvá tennél. A Hurd pl. szerepel rajta?
Pont annyira, mint X11-nél. Elvileg igen, gyakorlatilag... öööőőőő... pl. a GNOME-osok ragaszkodnak a kliens oldali ablakdekorációkhoz, a KWin továbbra is szereti maga menedzselni az ablakdekorációkat, úgyhogy egy GNOME app hülyén néz ki KDE alatt (mondjuk ez nem igazán DE-specifikus, KDE alatt egy Firefox is hülyén néz ki, hogy ott van az ablakdekoráció... ki lehet kapcsolni, de... ehh.)
Mondjuk ezzel én még megvárnám, hogy valamelyik disztró alapértelmezetté tegye a Wayland felületet, de mindenki egyelőre nagyon konzervatívan állnak hozzá.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
> Akárhányszor rákérdeztem, hogy mégis mi az, amit kötelező legyen támogatni. pl. itt: "tehát indirekt módon a FreeBSD/Solaris/whatever fejlesztőkre testálják."
De ezt vagy ötször válaszoltam meg, hogy az élő rendszereket...
> De akkor újra: mi lenne az a lista a UNIX/UNIX-like (mert én nem vagyok annyira kirekesztő, mint te ;) ) rendszerekről, amit te _kötelezően_ támogatandóvá tennél. A Hurd pl. szerepel rajta?
Ld. fentebb, most már bazisokadjára: élő rendszerek. Mindenütt, ahol váltani akarja az X11-et és még használják, igen akár UNIX-on kívül is. Holt rendszereket nyilván felesleges.
> Pont annyira, mint X11-nél. Elvileg igen, gyakorlatilag... öööőőőő... pl. a GNOME-osok ragaszkodnak a kliens oldali ablakdekorációkhoz, a KWin továbbra is szereti maga menedzselni az ablakdekorációkat, úgyhogy egy GNOME app hülyén néz ki KDE alatt (mondjuk ez nem igazán DE-specifikus, KDE alatt egy Firefox is hülyén néz ki, hogy ott van az ablakdekoráció... ki lehet kapcsolni, de... ehh.)
Ez nem annyira fontos; a megugrandó minimum, hogy stabilan működjön.
Van egy olyan tippem, hogy a Linuxos közösséget (és az arra épülő ecosystem-et) mérsékelten érdekli, hogy mindig minden kompatibilis legyen. Ami
egyébként teljesen jogos, ott a specifikáció és a forráskód, portolja, akinek van kedve.
Őőő, régen nem azért sírtak, hogy a nagyok saját deazértis szabványokat használnak? Most meg a szabad közösség vezető rendszerészei teszik ugyanezt?
Mondjuk azt, hogy a 20-30 éves rendszerekkel való teljes kompatibilitás viszonylag alacsony prio, viszont bejött
egy csomó olyan igény, amit jól a meglévő rendszerek törésével lehet megoldani. Nincs ezzel gond, már megszoktuk az IT-ben.
Illetve pont a Wayland az, ahol van rendes, dokumentált szabvány és referencia implementáció is. Az, hogy valaki
a saját rendszerét nem akarja utánahúzni, miközben a többiek megteszik, az bizony le fog maradni, és az egyébként
is marginális rendszere el fog tűnni a süllyesztőben.
Nem a Waylanddel van konkrétan gond (illetve nem tudom, hogy azzal van-e gond), hanem a freedesktopos mentalitással, hogy Linux/x86 van támogatva, esetleg ARM, meg nagyon esetleg FreeBSD, a többi rendszer nem fontos, ha portolva is van valami, akkor se rendesen, hemzseg a platform specifikus bugoktól, vagy akár már lefordítani sem lehet rendesen.
Oké, de a freedesktop-osok eléggé világosan elmondják, hogy ők alapvetően specifikációt adnak, és esetleg valamilyen referencia implementációt.
Innentől kezdve az egyes disztribuciók/rendszerek feladata, hogy ezeket leimplementálják úgy, ahogy ezt gondolják.
Hát ez az, hogy azért nem egészen: ők karban is tartanak, meg fejlesztenek is több szoftvert. Ugye a legeklatánsabb példa a systemd, amire egyre több cucc dependel, viszont ez 100% Linux-only és nem referencia implementációt adnak, hanem a konkrét szoftvert. De ott van pl. a pkg-config is, amire megint csak a fél UNIX-os világ dependel (sajnos). Az sem referencia implementáció, de próbáltad már leforgatni pl. OmniOS alatt?
Én egyre inkább úgy látom, hogy a Linux az egyáltalán nem a "standard unix" irányba megy. Ha megnézzük, a filerendszer, az
init rendszer, a csomagkezelés, a default shell, a könyvtárszerkezet, tűzfal config, driver támogatottság, stb. eléggé
más Linux és mondjuk FreeBSD-nél.
Viszont elterjedtségben a Linux kb. lenyom mindent, innentől meg...
Hát pont ez az, hogy a Linux egyre kevésbé UNIX, viszont egyre inkább átveszi a UNIX-ok helyét! Gőzerővel folyik a Linux elwindózosítása, miközben szintén gőzerővel folyik a UNIX-világ ellinuxosítása...össze lehet adni a kettőt. És akkor az ms ilyen tanulmányokkal jön. Kinek jó ez? De mindegy, nem gyártok konteót...
+1
Pontosan ezt mondom, hogy már utol is érte a vindózt. A siker csak azért nem teljes, mert rossz alapokkal indult. ;)
Registry tudtommal még nincs, de ki tudja mit talál ki még Poettering. :P
Szerintem nem egyre inkább átveszi, hanem konkrétan teljesen átvette. Elhanyagolható azok száma, akik a Linuxon kívül
bármi mást használnak cloud környezetben, vagy lassan már azon kívül is. Ha csak az Amazon-t nézzük, ott 9x% a linux
szerverek száma, de már az Azure-ben is 50% felett van. BSD, Solaris meg az összes többi más itt gyakorlatilag 1%-ot
sem érnek el.
Solaris-os gépet maximum valami nagyon deprecated, még le nem cserélt rendszerben tudok elképzelni, AIX a bankok miatt
még tartja magát, HP-UX-nek még van 5 éve, és nagyjából ennyi.
Még nem vette át. Ez a sok felhős szemét nem tudom hogy jött ide, amikor desktop UNIX-okról van szó, mindenesetre szerintem többszázezer ember nem elhanyagolható, maximum elenyészően kicsi a Linuxhoz képest. De ennek ellenére sem elhanyagolható, nem csak azért, mert még mindig sokan használják, de azért is, mert rengeteg dolog épül rá; a BSD-k helyét a Linux egy csomó helyen nem fogja tudni átvenni a license miatt.
Azt hogy minek mennyi ideje van hátra, azt nem tudom, de amíg él, addig illene támogatni, nem pedig még rásegíteni, hogy minél előbb pusztuljon ki.
+1
A kérdés, hogy mire használjuk ma a fork()-ot? A fork() egyébként, legalábbis Linuxon, nem rendszerhívás, hanem libc függvény és a fork()-ból is clone() lesz mint a pthread_create()-ből.
Csak egy két példa:
- fork() + exec() -> erre mondják a posix_spawn-t
- network szerver: master process accept(), majd fork() -> vannak olyan IPC megoldások, hogy fd-t tudsz rajta átküldeni a worker processeknek, ami sokkal kisebb state sharing, könnyebb biztonságos kódot írni
- heap sharing -> posix shm
A fő problémájuk a fork()-al, hogy nehéz jól használni, és amit használni kéne belőle, azt más szoftver designnal, biztonságosabban, jobb teljesítménnyel meg lehet oldani.
Az tény, hogy rengeteg legacy kód használja, de ha megnézzük a high profile appokat, amik valóban cross platform appok - tehát mennek Windowson is - ott már most meg van oldva a fork() kiváltása.
És itt nem is arról van szó, hogy kidobjuk a fork-ot és a helyét sóval hintjük be. Hanem arról, hogy hogyan, mire oktatjuk a programozókat. Mert sajnos a legtöbb Unix programozó kurzus eljut odáig, hogy "nézd milyen elegáns ez a fork", de a veszélyeiről már nem beszél semmit. Pedig a fork() is bekerülhetne a signal() mellé (meg a Java Thread.stop() mellé), az "ott van az API-ban, de ne használd" kategóriába.
Mondom: a
-kal kapcsolatos felvetéseiket nem tagadom, igazuk van benne. De egyelőre nem tudjuk csak úgy lecserélni.
A te példáidból is hiányzott a daemon létrehozása és ott muszáj mindent másolni kérdés nélkül. Van olyan POSIX függvény, ami minden UNIX-ban benne van és tudja ezt?
A programozók okításával még úgy-ahogy egyet is értenék, de valahogy borsódzik a hátam, amikor az ms akarja oktatni a programozókat; ld.
oktatása UNIX-os programozás oktatása címszó alatt.
Félig off: A network szervernél miért volna szükséges külön worker processeket létrehozni, amikor vannak thread-ek is? Azt tudom, hogy a
setjei limitált férőhelyesek, meg maga a
nem thread-safe, de
helyett is van kqueue, IOCP, meg epoll.
MT nagyon szép elméletben, meg az egyszálas event alapú cuccok is (epoll, kqueue és társai).
Szerveres környezetben viszont ezek kifejezetten a rémálom kategóriában vannak, főleg ha gyakran kerülnek új funkciók egy kódba vagy hirtelen kell skálázódnia a rendszernek mondjuk 10 gépre.
MT-vel az a baj, hogy egy teszteletlen új funkcióban lévő hiba képes az egész szervert megakasztani vagy akár el is száll. Eventes design ugyanez, csak az még átláthatatlan is egy bizonyos bonyolultság felett. Ha kombinálod is a kettőt még rosszabb. Ráadásul ilyen környezetben egy programozó automatikusan kihasználja a perzisztens memóriát és a rendszer teljesen használhatatlan lesz, amint már nem elég neki egyetlen gép és szét kéne dobni többre.
fork()-os multi processz szerverekkel semmi ilyesmi gond nincs.
fork() helyett lehet persze más is, csak akkor gyalog kell átadni a child-nak azokat a dolgokat, amiket fork() hívással automatikusan megörököl (file descriptorok, konfiguráció, stb.).
Ez érdekelne bővebben is; van erről valami konkrét anyag, a miértekről és a hogyanokról, szerveres környezetben a thread vs.
témában? (Tudom ráguglizhatnék, de nem szeretnék mazsolázni...)
Az eventes megoldásokkal mi pontosan a probléma?
Nálam ez csak tapasztalat.
Nagyon jól felelevenítette a dolgokat a lentebb linkelt sambás diasor.
Azt átfutottam, de így gyorsba' csak annyi jött le belőle, hogy anno az ms elcseszte a koncepciót, most meg már muszájból ragaszkodnak hozzá.
Amúgy próbáltál már hibát megtalálni MT szerverben?
Napokat el tud vinni, ahelyett, hogy fejlesztenél és valódi munkát végeznél.
MT desktopra amúgy tök jó dolog szerintem.
Eventes cuccokkal az a gond, hogy egy idő után egy istentelen bonyolult állapotgéped lesz, ami totál karbantarthatatlan kódhoz vezet. Sokkal egyszerűbb átlátni egy sima program flow-t.
Egyszerű dolgokra viszont nagyon jók, ha rengeteg párhuzamos kapcsolatot kell kiszolgálni.
Pl. http alapú dolgot csak úgy érdemes csinálni szerintem, hogy egy event alapú szerver (pl. nginx) fogadja a kéréseket és továbbítja a multi process backendeknek. Ezeknek az összes perzisztenciája valamilyen event alapú szerverben (pl. memcached) vagy/és egy jól skálázódó adatbázisban van.
fork() (ill. multi process design) hatalmas előnye még, hogy izolálva vannak egymástól a processek címterei
> Amúgy próbáltál már hibát megtalálni MT szerverben?
Hogyne. Az előző melóhelyemen egy több különféle szerver daemon-t írtam mind szervergépre, mind embeddedre és mind MT volt.
> Napokat el tud vinni, ahelyett, hogy fejlesztenél és valódi munkát végeznél.
Nem tapasztaltam. Egyáltalán nem emlékszem olyan esetre, amikor az MT szívatott volna meg valamivel, pedig a rohamtempós fejlesztések miatt voltak azért bugok. Szerintem csak megfelelő locking kérdése az egész, de nem nevezném magam expertnek a témában, úgyhogy ez csak az én véleményem.
> Eventes cuccokkal az a gond, hogy egy idő után egy istentelen bonyolult állapotgéped lesz, ami totál karbantarthatatlan kódhoz vezet. Sokkal egyszerűbb átlátni egy sima program flow-t.
> Egyszerű dolgokra viszont nagyon jók, ha rengeteg párhuzamos kapcsolatot kell kiszolgálni.
Az eventes megoldások eddig nekem kimaradtak; mindig
-tel szoktam dolgozni, mert a
ahány rendszer, annyiféle szívás, míg a
mindenütt működik és mindenütt ugyanúgy működik. Viszont nagyon sok baja van, főleg a description set-ek kezelése egy agyrém. Ebből a szempontból a
ezerszer jobb koncepció, de az összes rendszerben van valami hülye gyíkja és mindegyikben más. :(
> Pl. http alapú dolgot csak úgy érdemes csinálni szerintem, hogy egy event alapú szerver (pl. nginx) fogadja a kéréseket és továbbítja a multi process backendeknek. Ezeknek az összes perzisztenciája valamilyen event alapú szerverben (pl. memcached) vagy/és egy jól skálázódó adatbázisban van.
Ez a második fele már teljesen feladatspecifikus. Pl. statikus filekiszolgálásra minek kellene? Vagy akár sima infopage backendhez. A HTTP csak sima adatközlési protokoll, nem szükségszerűen webszerver.
> fork() (ill. multi process design) hatalmas előnye még, hogy izolálva vannak egymástól a processek címterei
Ez tény, viszont hatalmas hátránya, hogy a teljes process minden cuccát copyzni kell. Egy méretes processnél ez elég komoly overhead, a tanulmány is ezt feszegeti.
MT: addig jó, míg egymagad megtervezed és megírod az egészet.
Nagyobb, több emberes, mások által írt libeket használó dolgokkal viszont nekem nem túl jók a tapasztalataim.
Eventes fejlesztésre nekem libevent nagyon bejött.
Multi process: Persze, ennek akkor van értelme, ha viszonylag bonyolult logikákat kell leprogramozni pl egy webes backendben vagy egy web service-ben és fontos szempont a skálázhatóság.
A fő process persze nagyon kicsi kell legyen és előre le kell gyártani a child-okat (preforking), különben az összes erőforrás a forkolásokra fog elmenni.
A posix_spawn() különben elég jó alternatívának tűnik, valszeg megpróbálom majd fork()-ot kiváltani vele legközelebb.
> MT: addig jó, míg egymagad megtervezed és megírod az egészet.
> Nagyobb, több emberes, mások által írt libeket használó dolgokkal viszont nekem nem túl jók a tapasztalataim.
Hát tény, egyedül írtam őket.
> Eventes fejlesztésre nekem libevent nagyon bejött.
Thx, majd megnézem, úgyis bele kell majd magam ásni az eventesdibe.
> A fő process persze nagyon kicsi kell legyen és előre le kell gyártani a child-okat (preforking), különben az összes erőforrás a forkolásokra fog elmenni.
Na jó, de mi van, ha közben merül még fel az igény a forkingra? Tartunk egy külön process-t, ami semmit nem csinál, csak forkol, ha kell?
> A posix_spawn() különben elég jó alternatívának tűnik, valszeg megpróbálom majd fork()-ot kiváltani vele legközelebb.
Azt hogy??? A
a
+
kombót tudja kiváltani, nem a sima
-ot. A
egészen pontosan arra jó, hogy külön processen belül el tudj indítani egy külső programot, anélkül, hogy a teljes processedet forkolni kéne, amire nem biztos, hogy szükség van egy mezei programmeghívásnál.
Nem mentem ennek annyira utána, de posix_spawn() után a child megörökli a file descriptorokat.
Nézz meg egy preforking apache-ot, az folyamatosan szüli az új gyerekeket, ha nem elég, amennyi van (persze ez beállítástól függ). Mondjuk szerintem nem nagyon van erre szükség, ha van előtte reverse proxy.
Nem az a baj, hanem az, hogy a
az nem a processedet másolja, hanem egy új processt húz fel nulláról, a célként megadott programfájlból; ezzel nem lehet a sima
-ot kiváltani.
Hát nem is arról híres, hogy kevés memóriát eszik.
Ha a bind() eredményeként kapott fd-t megkapja valahogy a posix_spawn() hívással indított program, akkor tökéletes.
A többi dolgot át lehet neki adni parancssorban vagy környezeti változóban.
Az meg egyáltalán nem baj, hogy ez egy másik bináris is lehet, mint ami menedzseli az egészet.
A manager programot egyszer kell megírni és akármilyen binárisokat lehet vele indítani szerver processznek.
Ha lesz időm, kipróbálom.
Esetleg ha valaki szerint ez tuti halott ötlet, megköszönöm, ha szól.
Várj, te most gyakorlatilag úgy akarod kiváltani a
-ot a
-nal, hogy elindítod a programodat mégegyszer és aztán IPC-n áthajigálod neki, amit kell? Javíts ki, ha tévednék, de ez szerintem még nagyobb overheaddel járna, mint a
.
Az fd-t is át kehet adni parancssorban, ha egyébként öröklődik.
--
ulysses.co.hu
Igen, csak rosszul írtam. Öröklődnek a megnyitott fájlok, így elég parancssorban a descriptort átadni, ami ugye egy egész szám.
Sokat nem spórol vele az ember, mert tipikusan semmit nem szokott csinálni egy démon a fork előtt, csak beolvasni a configot és rábindolni a portra, esetleg még usert váltani. Ekkor még nincs akkora címtér, mint egy régóta futó programnál, de legalább fel lesz készítve a program a fork() utáni időkre.
Bár ahogy most systemd doksijait olvastam, bind-ra és userváltásra sincs szükség.
Hogy került a képbe a systemd?
Annyira szidtátok feljebb, hogy utánanéztem.
Az az igazság, hogy én 15-25 éve linuxoztam, unixoztam aktívabban, amikor még init volt a rendszerek alapja. Az utóbbi 10 évben pedig már csak egészen érintőlegesen követtem a Linux fejlődését. Például elképzelésem nem volt, minek ez a systemd.
Most, hogy utánanéztem, már látom. Nagyon fasza dolog!
Jajj...
Ja és lehet, hogy adok megint egy esélyt a szálasdinak a projektben, amire épp készülök, mert systemd-ben van watchdog is.
Legalább az adatbázis kapcsolatokat jó lenne poolozni, ami multi process rendszerben macera. Több 10 különböző adatbázisból is le kell tudni kérdezni adatokat. Gáz lenne állandóan adatbázis kapcsolatokat építeni és bontani mondjuk 3 rekord miatt.
Valszeg úgy fogom megírni az alapot, hogy így is, úgy is tudjon működni, aztán ha már elég stabil, átállítom multi processzről többszálúra.
Aztán ha mégis elszáll vagy megáll egy rossz lockoláson, akkor a systemd watchdogja megoldja a gondot.
Nagyon hasznos volt most nekem itt hétvégén ez a fórum, köszi érte!
Miből állna megírni egy pársoros watchdogot...? Azzal, hogy ráállsz a systemd-re, nagyon rossz lóra teszel. Nem csak a hordozhatóságot kukásítod, de a systemd nem a stabilitásról híres.
Csak egy minimális libet kell hozzálinkelni, ami úgy oldja meg a systemd kompatibilitást, hogy standalone módon is tud menni. Amúgy meg ezeket a démonokat a saját felhő szolgáltatásunkban fogjuk futtatni linuxos VPS-eken. 1-2 felhasználó lesz, aki a saját gépén akarja majd futtatni, de azoknak is linuxuk van.
Több más problémát is megold különben systemd, amiken eddig csak agyaltam.
Például több különböző porton különböző démonoknak on demand kell majd menni, hogy ne zabáljanak feleslegesen erőforrásokat. Erre is írhatnék egy külön démont, ami figyel egy sor porton és indítgatja a többit, átadva a socket descriptorát, ha bejön egy kérés (ezért örültem annyira posix_spawn() hívásnak), de ezt systemd out of the box megcsinálja.
A másik, hogy a kiesésmentes működés is egyszerű lesz, mert ugyanazt a binárist több különböző portra is rá tudom ültetni vele. Ha valamelyik megáll 1-2 másodpercre, amíg a watchdog újra nem indítja, addig ott a többi.
Ezek web service-ek lesznek, így nginx-nek több backendet beállítva teljesen megbízhatóan fog működni a rendszer.
systemd a mostani Linuxok alapja és azért elég széleskörűen használják mindenhol stabilitási gondok nélkül. Nekem sem volt eddig gondom vele.
Nem hiszem, ha megírnám ezeket a funkciókat nulláról, az jobb lenne. Ha valami működik, szívesen használom. Van ezeken kívül ezer más megoldandó...
Például több különböző porton különböző démonoknak on demand kell majd menni, hogy ne zabáljanak feleslegesen erőforrásokat.
Bizony, ezt volt majd 30 éve az inetd, majd xinetd, osztán föltalálódott a systemd xml-ben.
A fejlődés megállíthatatlan!
A következő verzióban a systemd fogja futtatni a kernelt is.
A végső célként a processzor is a systemd lesz, így már az Intel és mocskos bandája is csődbe fog menni. :-D
wut?
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Hint google: systemd xml
Hint: a githubos találatok (első kettő) a man page-k, utána egy commit az előbbihez, utána meg tőle független dolgok... egyébként pedig:
The Biggest Myths (http://0pointer.de/blog/projects/the-biggest-myths.html)
(kiemelés tőlem)
Sima hót standard ini-stílusú konfig fájljai vannak...
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Sajnálom tévedtem. :(
Ez elég nagy bukta, mert a hozzászólásokat nézve csak ebben az egyben. :-D
https://en.wikipedia.org/wiki/DocBook
inetd-vel én is próbálkoztam még az ősidőkben, de az komoly szervernek alkalmatlan.
xinetd nálam kimaradt, mert initd-vel azonosítottam, de a man oldalát nézve nem lenne alkalmatlan.
Az más kérdés, van-e értelme egy nem standard dologra építeni, mikor systemd 1-es PID-del megy alapból minden linuxon.
Hát pontosan ezt mondom: Az inetd az standard a hálózattal rendelkező unixokon. A mai napig.
És wtf initd? Olyanról még nem hallottam. Létezik init és egyes rendszereken init.d, de az nem program, hanem dir.
Van egy kis zavar az erőben, ahogy a kommenteket nézegetem. A fork(), mint rendszerhívás (már makró?), néha commandline opcióvá válik. ;)
Természetesen init->inet, csak elírtam, Mester.
Egyébként értelmetlen lenne a mondat.
> Például több különböző porton különböző démonoknak on demand kell majd menni, hogy ne zabáljanak feleslegesen erőforrásokat. Erre is írhatnék egy külön démont, ami figyel egy sor porton és indítgatja a többit, átadva a socket descriptorát, ha bejön egy kérés (ezért örültem annyira posix_spawn() hívásnak), de ezt systemd out of the box megcsinálja.
Dehát ezt a
is megcsinálja out of the box...
> A másik, hogy a kiesésmentes működés is egyszerű lesz, mert ugyanazt a binárist több különböző portra is rá tudom ültetni vele. Ha valamelyik megáll 1-2 másodpercre, amíg a watchdog újra nem indítja, addig ott a többi.
> Ezek web service-ek lesznek, így nginx-nek több backendet beállítva teljesen megbízhatóan fog működni a rendszer.
Dehát mennyiből állna implementálni egy szimpla watchdog mechanizmust?
> systemd a mostani Linuxok alapja és azért elég széleskörűen használják mindenhol stabilitási gondok nélkül.
Elég széleskörűen vannak vele stabilitási gondok, én inkább így fogalmaznék.
> Ha valami működik, szívesen használom.
Ha működik, de a systemd pont az ellenkezőjéről hírhedt.
Ha tényleg gond lesz vele, akkor is lesz lehetőségem megírni vagy mást használni helyette.
A legegyszerűbbnek egyelőre az tűnik, ha használom úgy ahogy van.
Ismerek olyanokat, akik kernelt is maguknak szeretnek írni, én nem vagyok ez a típus.
Ha akarod, beírom ide is a tapasztalatokat.
Itt nem kernelírás szintű dolgokról volt szó, az egyiket alapból tudta egy már kiforrott, erre a célra kitalált daemon, a másik meg egy pársoros watchdog mechanizmus.
A klasszikus fork() mellett nem véletlenül jelent meg közel 2 évtizede a Linuxban is a pthread_create(). Sokkal gyorsabb, ha nincs szükség izolációra.
Az igaz, de itten a kerdes inkabb a fork() + execve() + a tucatnyi egyeb resource oroklesenek teljes problematikaja.
Szerintem hasznos cikk. Még nem olvastam végig, de egyelőre úgy látom, nem a fork() a probléma, hanem exec() és társai.
Nagyon beszédes az első ábra:
Figure 1: Cost offork()+exec()vs.posix_spawn()
Én például sosem értettem, minek kell ilyen "költséges" és nyakatekert módszer Unixon egy külső parancs elindításához, de beletörődtem, hogy a Unix gáz ezen a téren. Tényleg nem éppen közismert sajnos a posix_spawn() a programozók körében, én sem tudtam róla.
És egy csomó más problémáról sem, amiket felsorol a cikk.
Viszont azt nem tudom egyelőre elképzelni, hogy egy porton bejövő forgalmat kiszolgáló szerver hogy tudna normálisan működni fork() nélkül. Szálasdit én nem szeretem, mert a közös címtér miatt ott gyakran előfordul, hogy egy programhiba magával rántja az egész démont.
https://sambaxp.org/archive-data-samba/SambaXP2014-DATA/thu/Jeremy_Alli… 2. és 3. slide :) [a többi is érdekes, de ezen a kettőn mindig jót röhögök]
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Vicces, de nagyon tanulságos diasor.
Ezeken (multi process -> multi thread -> event driven) szerintem mindenki végigmegy, aki programoz szervereket.
És megtanuljuk értékelni a fork() egyszerűségét ;)
Nekem az volt az első gondolatom, hogy a cikk 70%-ban valójában Linux ellenes politikai pamflet. Nehogy már az ms-nél találják ki, hogy mi legyen tanítva az iskolákban. Bár a fork-kal kapcsolatos nehézségek valósak.
De ugyanilyen pamflet írható volna a threadek hátrányairól is. Például, hogyan fér össze a szemétgyűjtés a threadekkel. Ha szemétgyűjtés alatt az összes thread le van állítva, akkor a rendszer helyből nem skálázódik. Ha nincs leállítva, akkor is rosszul, mert a szálak számával lineárisan nő a (közös) változótér nagysága, amiben a szemétgyűjtés matat.
--
ulysses.co.hu
+1 mindkettőre. (Bár mondjuk nem kötelező GC-s nyelvet használni.)
Önmagában az, hogy a GC leállítja az összes szálat, nem feltétlenül gond, a kérdés, hogy mennyi időre. Ha jól emlékszem, ezért
van a G1 garbage collector a Java-ban...
+ érdekes
* Én egy indián vagyok. Minden indián hazudik.