Linux vs. valóság

A csontig, sőt velőig lerágott témát az ext4 vs. 0 byte-os file-ok probléma kapcsán veszem elő újra.

Mint azt már én is megírtam párszor, és még rajtam kívül annyian, a Linux kernelfejlesztők az utóbbi időben olyan távol kerültek a rendszerüket használó átlagfelhasználótól, mint Makó Jeruzsálemtől. Tipikus elefántcsonttoronyba zárkózott programozó betegség tüneteit kezdik(?) mutatni, miszerint "works for me", illetve "a specifikáció szerint van", az átlaguser, vagy éppen az átlagusereket supportáló rendszergazda, esetleg a sok ember sok munkájával kifejlesztett alkalmazások, és a rájuk épülő rendszerek meg le vannak szarva. Márpedig ők az egészet egyszerű bugként élik meg - olyan bugként, ami eddig nem volt a rendszerben. Az eset jól mutatja mi történik, ha fizetett programozók (mert a Linux kernel fejlesztői már rég nem lelkes közösség, hanem a Red Hat, IBM, Intel, Novell és mások által fizetett jómunkásemberek) bazárként dolgoznak.

Már kifejtettem volt, hogy mennyire káros a kompatibilitás ilyen mértékű - már elnézést de - leszarása. Az informatikai ipar dollármilliárdokat fordít a kompatibilitás megőrzésére hardver és szoftverszinten is, amit a Linux kernel fejlesztői egyszerűen ignorálnak. Új verziókban nem támogatott hardverek, nem forduló 3rd party patchek, folyamatosan változó, korábbi és későbbi verziókkal inkompatibilis userspace toolok és libraryk, kiirthatatlan, idegesítő feature-ek szegélyezték a 2.6-os Linux kernel eddigi pályafutását is. Már vártam, mikor történik meg, hogy mezei felhasználói programok is a kernel fejlesztők ignoranciájának áldozatává válnak.

Nos, megtörtént.

Tudom mindig az Amigával jövök (bár a jobbak nem szégyellnek tanulni a rég elfeledett játékgépből), de akkoris, kicsit nagyon vicces, hogy az 1Ghz-s 1GB RAM-os Pegasos II-mön, a from scratch írt Amiga-kompatibilis rendszer, a MorphOS alatt két kattintással bemountolom az 1.0-s Workbench lemez image-jét, majd elindítom róla az eredeti, 1985-ös alkalmazásokat, amik egy más hardverre, más processzorra és másik operációs rendszerre készültek és teljes integrációban futnak. 640x256, 4 szín helyett, 1280x1024-ben, truecolorban. És ezt kb. 10-15 ember fejleszti, otthon, hobbiból, és van vagy 1000-1500 felhasználója, optimista becslések szerint.

(És tudom, rossz a hasonlat. A Workbench 1.0-hoz adott Clock és Calculator, nem túl bonyolult programok. Csak az a baj, hogy a 68k-s bináris device driverek és file systemek is futnak. Ez utóbbiak (pl. PFS3) természetesen úgy, hogy bootolni is tudunk róla...)

Miközben Linux alatt - a komoly industry standard, világcégek, programozók százai, ezrei által írt és használt Linux alatt - lassan az sem fut, amit tegnapelőtt írtak. Linuxra.

Hozzászólások

+1

(off: tud valaki PC-re egy használható OS-t? :) )

"If a million monkeys were typing on computers, one of them will eventually write a Java program.
The rest of them will write Perl programs."

Hm, ez a sierra jónak tűnik, de lehet alszok rá még párat (azt írja, hogy basic támogatása van, abban meg nem tudom, hogy benne van-e a wpa2). Szerintem tavaszi szünetben esélyes lesz egy próbatelepítésre az opensolaris :)

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

Csak bologatni tudok, a 2.6.x-os szeria tenyleg katasztrofa.
A gond szerintem leginkabb az, hogy nincsen kulon testing ag, de lehet, hogy nagyban kozrejatszik, hogy mostanaban tenyleg a linux is a penzrol szol. A linux az opensource microsoftja mondjak nem kevesen. S lam tenyleg. A problema az, hogy egy alternativ oprendszert kell keresni az alternativ oprendszer helyett, majd ha az is ekkorara no az ipar szemeben, megint egy ujabbat.
Amugy ez az ext4 mondjuk szvsz egy olyan dolog, hogy ugye a btrfs elott jelent meg, nem tudom minek. Bugos is - ill. mindenki mas a hibas - nem kiforrott meg. Bar igen, mikor is kiforrott valami, mikor azt mondjak, hogy na mostmar lehet hasznalni? Lehet, hogy valamikro eldontik, mi is a jo irany, de ez megint egy kellemes visszalepes a linux vilagaban.

Ugyanez van a virtualizacio frontjan is. Kijelentik, hogy na a KVM a jovo. Igaz nincsenek hozza olyan jo toolok, mint a xen-hez, nem lehet annyira jol skalazni, de megis azert na ha mar a quamranet-et (vagy mittomenmi hogy hivjak azt a ceget) megvette a redhat, akkor mar hasznaljuk. Aztan bejelentik most, hogy lehet, hogy megiscsak jo dolog az a xen, s az egyeb virtualizacios technikakat ne is emlitsuk. En meg most mit csinaljak? Persze van megint 4 fajta ut, csak mindegyik ugy tunik, hogy egyelore nem jarhato. Maradjunk regi filerendszernel - ha ragaszkodunk a linux-hoz - maradjunk az egyeb virtualizacios technologiaknal, amik nem ilyen fejlesztok kezeben van.

Lehet, hogy ez a nagy szabadsag tenyleg egyre inkabb egy rohadt nagy majomketrec, mint sem hogy szabadsag.

Es akkor most lojjetek :).

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Nem nevezném kompatibilitásnak azt, hogy eddig úgymond szerencséjük volt.

szerk.: Nagyrészt race condition-ök megtalálásával és fixálásával keresem a kenyeremet. Amióta boldog-boldogtalannak többmagos processzora van, akad tennivaló bőven. Mégsem jut eszembe az Intelt hibáztatni azért, mert ilyen processzorokat gyárt, se a Linux illetve MS fejlesztőket azért, mert többmagos processzoron máshogy ütemezik a nyomorult szálaimat, mint egymagosokon, és ezért sok eddig lappangó bug előjött.

Bocs, de a Linuxszal nem csak ez a problema. Szerintem a folyamatos API/ABI valtozasokat, driverek hirtelen es varatlan kieseset nem feltetlen lehet a szalutemezessel magyarazni, marpedig a Linux hires ezekrol. De ha igen, akkor vezesd le nekem...
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez csak egy példa volt, amit a T. Olvasónak általánosítani kellett volna.
Értsd: ha egy fejlesztő valami olyasmire hagyatkozik, amiről nincs explicit deklarálva, hogy nem fog változni, akkor csak magára vethet, ha az a valami netán mégis megváltozik.
Fejlesztettünk szoftvert vmi java lib-re alapozva, és hogy, hogy nem, használtunk osztályokat az org.lib.internal namespace-ből, mert megvolt rá az okunk. Szívtunk is változtatás miatt később, mégsem kiáltottunk vérbosszúért és írtunk blogpostokat a lib fejlesztőinek kompetenciáját megkérdőjelezendő. Ugyanez a helyzet a Linux kernel belső interfészeivel is: mindenki tudja, hogy változhatnak, úgyhogy ha használod, akkor jobb, ha felkészülsz rá.

Bocs, de van kulonbseg a Java es egy kerneldriver kozott. A gond az, hogy a driverek un. publikus interfeszei is valtoznak. Probalj meg egy 2.6.8-as kernelhez irt drivert leforgatni egy 18 es felette levo kernellel. Nem fog menni patkolasok nelkul.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha az egész mondatot elolvasnád újra, akkor talán sejthetnéd, hogy a korábbi verzióval jól működő driverről óbégattam, ami az új verzióval természetesen nem megy, azért van ott zárójelben a "volt" szócska. Cizelláljam tovább, vagy most már átért, receive acknowledged?

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A mezei endusernek (konkrét példa: barátnőm édesanyja) nehéz elmondani, hogy pl. a karácsonyra kapott (nem tőlünk) webcam ugyan működik a latest Linux alatt, de nem tesszük fel, mert akkor nem fog menni az akármilyen XY egyéb kártya, meg az egész ötször lassabb lesz. (Konkrét eset: Ubuntu 6.06 vs. Ubuntu 8.10 on a P3/600 + 256MB RAM.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Tudod mit, ma jo kedvem van, leforditom:

Tehat a velemenyed szerint, ha az end user valaszthat a hulladek es a tragya kozott, akkor oruljon, h egyaltalan mukodik, es kuss a neve? Ez igen. Teljesen felesleges akkor legalabb a hasznalhatosagra torekedni, ugyis baromsag.

---
pontscho / fresh!mindworkz

Szóval vagy elvesztem a régi hardverem támogatását a biztonságért cserébe (mert ez így nem hangzott még el, de a backportok se tökéletesek, javíthatnak(tanak) dolgokat currentben, amiről nem veszik észre, hogy biztonségi probléma is, így nem kerül backportolva régebbi kernelekbe. Aztán a disztró saját stabil kernelfáját frissítők meg vagy észreveszik a hibát, vagy nem.) Vagy minden alkalommal, amikor megtörik egy "régi" de általam használt hw drivere, "Keep up with the good guys!" felkiáltással frissítem az egész gépparkot.
Kurvajó, gratulálok.

Ha soha semmivel nem jártam volna így, akkor nem panaszkodnék.
(Egyébként ISA-s SB kártyám, Mustek 600 cp flatbed scannerem mai napig tökéletesen működik.
A gond más területeket érint inkább. Lásd webkamerák, tv-tunerek, I/O kezelés, etc)
Az a sajnálatos, hogy szerinted ez így elfogadható.

Nézzünk egy user-t, ellenpéldának:

"For example, I bought an expensive ($500) fast 32-bit parallel I/O card 4 years ago, which claimed to have Linux support. This turned out to be "but only on RedHat 7.3 with the default kernel". In the end, we threw out the hardware. Actually, we replaced it with another "Linux-supported" hardware item, called a QuickUSB. This also had only a binary driver, but it used libusb, and we were able to reverse-engineer it to write a GPL-driver. (But it still wasn't good enough in the end)."

Nem látom hogy hisztizne, pedig fizetett is, meg dolgozott is.

Nem mindenki teheti meg, h csak ugy lecserelje a hw-t, plane ha az mukodokepes es jo. Lasd pl. LiRC esetet. Mintha egyik erv lenne a linux mellett, h a regebbi hardverekkel is emberi eroforras igeny mellett kepes mukodni. Meselhetnek ceges kornyezetben tortent hasonlo esetrol is tucatjaval, ahol ez a csere nem mukodik csak ugy ukmukfukk a hardver koltseg vonzata miatt, csak ezek a sztorik egyelore uzleti titkok.

---
pontscho / fresh!mindworkz

Érdekes, ahogy kategorizálod, hogy mi a hisztizés, és mi nem.
Kb, ugyan az a probléma, amiről beszéltünk.
Szerintem hisztizik! Blőő!

Én már csak azt nem értem, hogy te ultimately mit akarsz ebből kihozni, mi nem
tetszik? Hogy kritizáljuk a Linux kernel fejlesztését? Még csak nem is fuj-szaral4nux flame, hanem építő jellegű
javaslatok, egyszerű brainstorming olyanoktól, akik használják(nák) azt örömmel.
Hogy beleszólni nem tudunk (indító postban vázolt okok miatt is)? Igaz. Maradjunk kussban?
Minek. Zavar?
Fejtsd már ki, mi a bajod :)

> hanem építő jellegű javaslatok, egyszerű brainstorming olyanoktól, akik használják(nák) azt örömmel.

Hmmm. Ezek szerint lemaradtam pár hozzászólásról.

> Fejtsd már ki, mi a bajod :)

Nem tűnt fel hogy bajom lenne. Ha csak az nem, hogy egész éjszaka kódoltam. :-)

Jo neki, hogy o csak kidobhatja a $500 -os cuccot a kukaba, csak mert a Linux nem tamogatja, ettol meg ez a megoldas semmivel sem lett jobb. Azert gondolkodjunk mar picit, ha azzal reklamozunk valamit, hogy sok regi hardverrel is egyutt tud mukodni, akkor figyeljunk oda, hogy legalabb ne motorosfuresszel vagjuk magunk alatt a fat.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Amit Linuxra írnak az fut ha Linux fut!

[/me iszonyú gyenge poénja]

És mi lesz ha nem lesz kompatibilis szegény Linux bele a holnapi kolbásszal!
[/me még mindig szar poénokat nyom]

Nagy fos ez lesz ebből így, valóban.

No rainbow, no sugar

Én mezei júzerként azt vettem észre, hogy míg pár évvel ezelőtt arról szólt a Linux, hogy "megmutatjuk mindenkinek, hogy miénk a legjobb OS", most meg inkább a "dehát a többi OS is ugyanilyen bugos" mentalitás terjed. Ez nekem _nagyon_ nem tetszik, főleg azért, mert azt veszem észre, hogy egyre bugosabb az egész (a kerneltől kezdve az X-en át a legutolsó grafikus programig).

Ebben részben szerepe lehet annak a tendenciának, hogy a disztrók egyre rövidebb kiadási ciklusokkal dolgoznak, és mivel minden kiadásra valami újat kell felmutatni, ezért passzív nyomást gyakorolnak az alkalmazásfejlesztőkre, akik lapátolják a fícsöröket, de QA-ra nem marad idő rendesen. Ez pedig szomorú, mert drasztikusan romlik a szoftverek minősége (3-4 évvel ezelőtti Linuxokon ritkaságszámba ment az, hogy egy alkalmazás lehal, ma meg naponta elszáll az X). Kicsit vissza kellene venni a tempóból, és nem 6 hónap alatt megváltani a világot, hanem 1 éves vagy még tágabb kiadási ciklusokkal bevárni azt, hogy az alkalmazások tényleg stabilak legyenek.

"If a million monkeys were typing on computers, one of them will eventually write a Java program.
The rest of them will write Perl programs."

ext4 vs. 0 byte-os file-ok probléma kapcsán veszem elő újra.
Nem akarok nagyon flame-elni, de szerintem TyTso hozzáállása teljesen korrekt. Valóban azt mondja, hogy "a specifikáció szerint van", de nem úgy áll hozzá, hogy akkor "wontfix", hanem ő is keresi a workaroundot, hogy hogyan lehetne úgy megoldani, hogy az átlagfelhasználó se érezze a kellemetlen hatását. Szerintem ezzel éppen hogy ő pozitív kivétel sok más fejlesztővel szemben. Hogy ez a workaround mennyi idő alatt jut el az átlagfelhasználóhoz, az már nagyrészt nem rajta múlik (ezen nyilván lehet vitatkozni, hogy ez így helyes-e vagy sem).
Just my 2 cents.
---
Linux is bad juju.

Ha nem tetszik miért nem indítassz egy saját kernel forkot? A lehetőség adott. Nem hallottam, hogy bárki is próbálkozott volna ezzel, nincs annyi probléma a linux fejlesztésével, hogy megérje. Eddig nem akadt senki aki úgy gondolta volna, hogy jobban tudja csinálni.

A tobbi se sokkal jobb, nincs olyan oprendszer amibe ne lenne olyan feature/bug (attol fugg honnan nezed, amire en hasznalom, abbol a szempontbol ext4 > ext3) ami megosztja a tisztelt felhasznalokat.

Pont most olvastam egy erdekes dolgot, FreeBSD & sendfile kapcsan: http://www.ioremap.net/node/192

Lehet mutogatni, hogy linux nincs ertelmesen fejlesztve, de mutasson valaki nekem olyan OSt ami igen..

A fejlesztes nem arrol szol, hogy minden esetre felkeszulunk, es atombiztos, hulyebiztos mittudomenmit epitunk, akkor ugyanis nem jutnank sehova. A fejlesztesnek ara van, neha egy feature bevezetese avval jar, hogy egy-egy esetben nem az tortenik amit az ember megszokott. Akkor jon az, hogy a featuret kikapcsolhatova teszik, vagy workaroundot csinalnak, hogy ne legyen nagy meglepetes.

De kivenni egy featuret, ami sok esetben hasznos, csak azert, mert ha elcrashel a rendszer akkor gaz lesz, az a legnagyobb marhasag lenne.

A magam reszerol utalok adatot veszteni, mint gondolom mindenki mas, de teljesen egyetertek az ext4 fejlesztoivel: ha fontos az adat, fsync()/fdatasync() amikor epp kell.

Hogy egy peldat hozzak a valos eletbol: tegyuk fel, baratnom megker, hogy menjek el vasarolni, kene sajt. A sajt nem egy fontos dolog, megvagyunk nelkule, igy megjegyzem. Munka utan vagy eszembe jut, es veszek, vagy nem. Ha nem, akkor nem lesz sajtunk, majd eszunk sima vajas kenyeret.

Ha megker, hogy vegyek uj zuhanyrozsat mondjuk, mert nem tud furdeni nelkule, akkor azt felirom, mert fontos.

Elso esetben memoriaban elcacheltem, szepen elcrasheltem, es elveszett az adat (termeszetesen reboot utan (= hazaertem), a diszkrol elo lett csalogatva az adat megis (= baratnom leszurt), de az adat megis elveszett). Masodik esetben biztosra mentem, es synceltem lemezre (felirtam egy darab papirra).

A dologban a nehez nem az, hogy syncelni kell, mert azt minden OS tamogatja. A nehez az, hogy megtanitsuk a programot, hogy a megfelelo idoben synceljen. Szal minden klikkelesnel egy kicsit durva, foleg a main threadben. Percenkent ujrairni kismillio kis filet szinten durva az esetek tobbsegeben..

Node, a lenyeg a lenyeg, mint fentebb emlitettem, ha nem tetszik egy feature, szinte biztos, hogy ki lehet kapcsolni, vagy van a problemara megoldas. Ez igy szep es jo, es minden normalis OS-ben hasonlokepp van, egyik sem sokkal jobb a masiknal ilyen szempontbol.

Picit kotekednek.

Egy OS fejlesztesenel az a minimum, hogy amennyiben volt elozmenye az kompatibilis legyen valamilyen modon az elodjere irt alkalmazasokkal. Ezt mar szamos OSnel meg tudtak oldani.
A masik resze a dolognak, hogy egy OSnek es a reszeinek atombiztosnak kell lennie, mert anelkul erteket veszti az alkalmazas ami az adott OS-en fut es erteket veszti az a vas amnin az OS fut.
Ez nem jelenti, hogy rossz dolog egy-egy uj feature kifejlesztese, viszont korultekitest igenyel annak a bevezetese egy mukodo kornyezeteseteben.

Hibas felfogas, hogy az alkalmazas iroja szinkronizalja az adatokat, ugyanis egyreszt ez egy belso filerendszer muvelet, masreszt mas filerendszerekkel valo kompatibilitast csokkenti. Keszitsen a fejleszto kulon alkalmazast minden filerendszerhez?
Az egesz mentalitas, a kicsit a "masvalaki problemaja" megkozelites. Ennyi erovel visszamehetunk arra a szintre, ahol minden program sajat maganak kezeli az adott hattertarat.

A filerendszernek az alkalmazasok felol transzparensnek kell lennie. Egy alkalmazasnak megnyitni, irni, olvasni, bezarni kell tudnia a filet. Az osszes tobbi muvelet a filerendszer sara. Az alkalmazasnak nem kell tudnia, mi tortenik a hatterben, es mindenfele korok lefutasa nelkul legyen mindig 100%-ig biztos, hogy az elmentett adatai el is lettek mentve.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Egy OS fejlesztesenel az a minimum, hogy amennyiben volt elozmenye az kompatibilis legyen valamilyen modon az elodjere irt alkalmazasokkal. Ezt mar szamos OSnel meg tudtak oldani."

Meg tudtak persze. De a kompatibilitast hurcibalni nem mindig eri meg. Csak azert, mert 10 evvel ezelott volt egy hibas elgondolas, es ezt kihasznaltak/workaroundoltak a programok, attol meg nem kene megorizni a kompatibilitast ezzel a hibaval.

Oke, megvan a hatranya is a dolognak: a programokat ujra kell forgatni, esetleg portolni. Nodehat arrol lenne szo, hogy minimum open source programokrol van szo, tehat az esetek tobbsegeben ez nem okoz gondot.

Az elenyeszo kissebbseg ahol ez nem megoldhato, hat az igyjart. Arra valo az emulacio, hogy regebbi rendszerben lehessen futtatni azokat a dolgokat.

Az emberek szeretik felhozni a windowst, mint OSt ami tokelyre (tulzasba?) vitte a kompatibilitast. Probalj meg egy osi dosos programot futtatni XP alatt, el fogsz csodalkozni neha.

Nincs olyan OS, ami tokeletes kompatibilitast tudna nyujtani, legfeljebb az a nehany, amelynek kifejezetten ez a celja. Az osszes tobbi csak tessek-lassek kompatibilis, feltetelezi, hogy az ember elobb-utobb mar nem fogja mult evezredben irt programokat futtatni rajta. Vagy ha megis, majd hasznal emulatort.

"Hibas felfogas, hogy az alkalmazas iroja szinkronizalja az adatokat, ugyanis egyreszt ez egy belso filerendszer muvelet"

BEEP BEEP.

A rendszer ugy van elkepzelve, hogy te megmondod az OSnek, hogy mit tartalmazzon a file. Amig minden processz aki ezt a filet olvassa, azt a tartalmat latja, amit kell, addig a feladat el van vegezve.

Sehol senki nem mondja, hogy close() utan rogton diszkre is fog kerulni a dolog. Csak annyit mondanak, hogy a file allapota konzisztens lesz, es ha egy masik processz megnyitja, akkor azt az allapotot fogja latni, ami close() utan van, fuggetlenul attol, hogy a memoriabol ki lett-e mar irva lemezre.

Kepzeld el mi lenne, ha minden a szinkronizalas ugy tortenne, ahogy te mondod! Adott egy halozatrol mountolt eszkoz, rajta random filesystem. Ennek a sebessege borzalmasan lassu lenne, ha a filesystem mindig syncelne.

"masreszt mas filerendszerekkel valo kompatibilitast csokkenti. Keszitsen a fejleszto kulon alkalmazast minden filerendszerhez?"

Milyen kompatibilitas? fsync()/fdatasync() megfeleloen alkalmazva minden filesystemen mukodik rendesen.

"A filerendszernek az alkalmazasok felol transzparensnek kell lennie. Egy alkalmazasnak megnyitni, irni, olvasni, bezarni kell tudnia a filet. Az osszes tobbi muvelet a filerendszer sara."

Ez igy is van ext4-nel is. Megnyitod, irsz, olvasol, stb - minden rendben van.

A problema nem ebbol jott elo, hanem abbol, hogy mi tortenik amikor az op. rendszer elcrashel. Amikor elcrashel, nyilvan nincs mar lehetosege syncelni.

Tehat, tobb megoldas van:

1) Az op. rendszer X idonkent syncel (ext3 ezt defaultbol 5 masodpercenkent teszi, ext4 kb 1-2 percenkent). A crash bekovetkezesenek idopontjatol fugg, mennyire lesz sulyos az adatvesztes, de valami szinte biztos lesz.

2) Az op. rendszer folyamatosan syncel. Igy szinte kizarhato az adatvesztes, ellenben fortelmesen lassu lesz az egesz.

3) Az applikaciok segitik az op. rendszert, es megmondjak neki, melyik a fontos adat, amelyiknek mindenkepp lemezt kell ernie mihamarabb. Ez kicsit tobb feladatot ro a program irojara, ellenben sokkal inteligensebb megoldas.

Az OS nem azert van, hogy kitalalja az alkalmazasok helyett, mit kene azoknak csinalniuk. A programoknak igenis az is a feladatuk koze tartozik, hogy segitsek az OS-t a kulonbozo dontesek meghozatalaban (kulonben miert lennenek thread priorityk, meg mindenfele egyeb josag?).

"Az alkalmazasnak nem kell tudnia, mi tortenik a hatterben, es mindenfele korok lefutasa nelkul legyen mindig 100%-ig biztos, hogy az elmentett adatai el is lettek mentve."

Ez ahhoz vezetne, hogy a laptopod kb 10 perc alatt lemerulne. Gratula!

Egy portolas, ujraforgatas idovesztes. Ez olyan mintha egy uj doboz szog eseteben uj kalapacsot kene reszelned. Ez kulonosen akkor idegesito amikor az adott kod nem open source, vagy epp abadonware.
Ha megnezed az ipart, millio olyan alkalmazast talalsz amik 10-15 evvel ezelott keszultek el, viszont nincs ertelme lecserelni oket. Es azt el nem tudod kepzelni, hogy az altalad emlitett "igyjart" eset mekkora szivas tud lenni, ha emiatt pont egy olyan gyartoegyseg all meg ahol az uj es trendi cuccaid keszulnek.

Egy informatikai rendszernel az adataim biztonsaga az elsodleges. Az osszes tobbi hegyezese csak ennek a figyelembevetelevel tortenhet. Nincs olyan, hogy fontos es nem fontos adat. Ha egy adatra nincs szuksegem egy kesobbi alkalommal, akkor nem irom ki a hattertarba. Ha pedig meg akarom osztani ezt a nem fontos adatot, akkor ezt mondjuk egy ramdrive-on keresztul teszem.

10 perc alatti laptop lemerulese eseten elgondolkodnek, hogy nincs-e valami hiba az adott mobil hattertar megalkotasanal, vagy a laptopba helyezett akkumulator kapacitasaval. Ennyi erovel azt is nezhetnenk, hogy mennyi a rendelkezesre allas ideje a laptopnak kikapcsolva es bekapcsolva, es utana megkernenk a felhasznalot, hogy 3 perc munka utan 5 percre kapcsolja ki a gepet a magasabb uzemido kihasznalasa vegett.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Egy portolas, ujraforgatas idovesztes. Ez olyan mintha egy uj doboz szog eseteben uj kalapacsot kene reszelned. Ez kulonosen akkor idegesito amikor az adott kod nem open source, vagy epp abadonware."

Ez igy van. Ellenben egy doboz szog valoszinutlen, hogy bugos lenne, es ujra kene csinalni.

Viszont egy open source operacios rendszernek miert kene egyatalan torodnie a closed source programokkal?

Szoval ha en csinalok egy specifikaciot, azt nyilvanossagra hozom, implementaciot is csinalok hozza, mas is csinal hozza, de closed source, aztan hibat talalok a specifikacioban, es nem tudom kompatibilitast megorizve megoldani, akkor bizony en ki fogom javitani a hibat. Ha a masik fel nem alkalmazkodik az uj verziohoz, akkor vagy hasznalja a regit, vagy fusson emulatorban.

"Ha megnezed az ipart, millio olyan alkalmazast talalsz amik 10-15 evvel ezelott keszultek el, viszont nincs ertelme lecserelni oket. Es azt el nem tudod kepzelni, hogy az altalad emlitett "igyjart" eset mekkora szivas tud lenni, ha emiatt pont egy olyan gyartoegyseg all meg ahol az uj es trendi cuccaid keszulnek."

A legtobb esetben egy recompile eleg. Sok esetben pedig egyszeruen hasznaltak a regi programot, regi rendszerrel (pl gyogyszertarak jelentos resze a nem is olyan tavoli multban dosos programokkal).

Valoban, nem kell lecserelni. Az OS-t sem kell frissiteni alatta. A megoldas adott.

Ketsegtelen, nagy szivas, de lehet valasztani: kompatibilitas a vilag vegeig, vagy fejlodes. A ketto egyutt nem megy.

A fejlesztes nem egy fix tabla, hanem inkabb mozgo celpont - bizony bizony neha portolni kell, nem lehet a vilag vegeig kompatibilisnek maradni, legfeljebb ha ez kifejezetten az ember celja.

"10 perc alatti laptop lemerulese eseten elgondolkodnek, hogy nincs-e valami hiba az adott mobil hattertar megalkotasanal, vagy a laptopba helyezett akkumulator kapacitasaval."

Aha! Szoval ha az OS azt mondja a hardvernek, hogy "legyszi, ird mar ezt nekem lemezre!", akkor az varhat ameddig akar, hogy optimalizalja a dolgokat, de ha ugyanezt a program keri a filesystemtol, akkor a filesystem rogton es azonnal kene ugorjon?

Nem ellentmondasos ez egy kicsit? :)

Egyebkent azt kepzeld el, hogy laptopon dolgozik az ember, es sokat fordit. Rengeteg atmeneti file keletkezik. Ha minden egyes filenal syncelnek, az igencsak megdobna a vinyo terheleset, es gyorsitana ezaltal az aksi lemeruleset.

Ha nem irom rogton lemezre, lehet, nem is kell egyatalan, vagy megfelelobben lehet optimalizalni az irast, stb. Hosszutavon gazdasagosabb.

(Persze lehetne tmpfsre tenni a tempfileokat, de az macera. Plane, ha eleve nincs sok memoriam, es a fileok nagyok, kozben en meg esetleg bongeszni is szeretnek [ami mellesleg szinten sokat irna lemezre, amikor a firefox ugy dont, hogy akkor most a historyt meg mindent lementi nehogy elvesszen])

Hogyne. Csak epp akkor mit tegyen az ember, ha kidol a vas a szoftver alol. Behuzol egy uj vasat ala, es meglepve latod, hogy a regi OS-ed nem megy rajta.
Pont a fenn emlitett MorphOS olyan ami kepes erre a trukkre. Kepes egy olyan alkalmast futtatni amit 15 evvel korabban egy teljesen mas architekturaju gepre irtak.

Az altalad emlitett forditasi problema santit. Egyreszt egy klasszikus filerendszernel minden egyes atmeneti file letrhozasanal tortenik egy irasi muvelet es nincs olvasas mint a szinkronizalasnal. Masreszt ha nincs elegendo memoriad akkor elobb utobb a szinkronizalni fog a filerendszered, es akkor ugyanott vagy mintha direkben irnad a meghajtot. Ha meg van elegendo memoriad, akkor teljesen mindegy, hogy a forditas a meghajton vagy a memoriaban tortenik.
Amugy amiota van 4-500Mb szabad memoriam a gepemben joforman az osszes forgatast a ott vegzek, mert nagysagrendekkel gyorsabb.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Hogyne. Csak epp akkor mit tegyen az ember, ha kidol a vas a szoftver alol. Behuzol egy uj vasat ala, es meglepve latod, hogy a regi OS-ed nem megy rajta."

Vesz regi vasat, vagy lecsereli a szoftvert. Vagy uj vas + emulator. Ha egyik sem opcio, akkor sajna uj szoftvert kell talalni.

Szar az elet, eh?

"Pont a fenn emlitett MorphOS olyan ami kepes erre a trukkre. Kepes egy olyan alkalmast futtatni amit 15 evvel korabban egy teljesen mas architekturaju gepre irtak."

Hurra, akkor ahol erre van szukseg, lehet MorphOS-t hasznalni. Mar latom ahogy tolong a nagy Uzleti Szfera, hogy migraljon.

"Az altalad emlitett forditasi problema santit. Egyreszt egy klasszikus filerendszernel minden egyes atmeneti file letrhozasanal tortenik egy irasi muvelet es nincs olvasas mint a szinkronizalasnal."

Igen, nem is hasznalok "klasszikus" filerendszert a laptopomon. Pont ezert.

"Masreszt ha nincs elegendo memoriad akkor elobb utobb a szinkronizalni fog a filerendszered, es akkor ugyanott vagy mintha direkben irnad a meghajtot."

Ez nem teljesen helytallo megallapitas.

Eloszor is, nem biztos, hogy minden tempfile nagy. Tehat siman elofordulhat hogy a felet sose kell kiirni lemezre, mert torlodik meg mielott elfogyna a memoria. Ez mar rengeteg vinyo muveletet megsporolt.

De, ha feltetelezzuk, hogy minden tempfilet ki kell irni igy is ugyis, akkor is ha eloszor memoriaban taroljuk, kevesebb (de nagyobb meretu) irast lehet vegezni, ami megfeleloen optimalizalva arra jo, hogy kevesebbet mozog a vinyo feje, amivel szinten nyertunk valamennyit.

Mig ha rogton irnank amint jon a cuccos, konnyen lehet, hogy tobbet ugralna az a fej.

Vegyunk egy peldat! Adott egy 1Gb-s tempfile, amit mondjuk 64k-128k meretu szeletenkent irunk ki. Ha rogton irni kezdunk lemezre, konnyen lehet, hogy latjuk, je, itt meg epp van 100k hely, bepaszirozzuk ide a blokkot! Naon jo! Fel pillanat mulva jon a kovetkezo szelet, 64k... whopsz! Hat ezt rogton ide moge nem tudjuk, seek a vilag masik vegere, es beirjuk oda. Es igy tovabb.

A delayed allocation ezen nagyon szepen segit, mert az akkor kezd irni amikor a file mondjuk 500Mb (hasrautes szeruen, nyilvan ez sem magikus gyogyszer, de azert valamit hasznal), es igy egybefugobb, kozelebb levo helyekre tudja irni, nem kismillio darabra szetszedve.

Ez mind az irast, mind a visszaolvasast segiti, es energiatakarekosabb is.

Persze ennek egy jelentos resze hardver szinten is valoszinuleg implementalva van, viszont ahhoz, hogy azt kihasznaljuk, kommunikalni kell a vinyoval, nem lehet sleepben.

Ha van kismillio pici fileom, akkor lehet a vinyonak szolni, hogy haho, ird ki, es vagy kiirja, vagy nem, mert kozben kitoroljuk, vagy lehet az OS egy picit okosabb, es rajohet, hogy nem is kell a vinyonak szolni, ezzel is megsporolva par utasitast.

"Ha meg van elegendo memoriad, akkor teljesen mindegy, hogy a forditas a meghajton vagy a memoriaban tortenik."

Ebben egyetertunk :)

"Amugy amiota van 4-500Mb szabad memoriam a gepemben joforman az osszes forgatast a ott vegzek, mert nagysagrendekkel gyorsabb."

Nekem osszesen 512Mb van a laptopomban, en inkabb nem memoriaban forgatok, szeretek mast is csinalni kozben.

"Vesz regi vasat, vagy lecsereli a szoftvert. Vagy uj vas + emulator. Ha egyik sem opcio, akkor sajna uj szoftvert kell talalni."

Ezt add be mondjuk egy banknak vagy egy eromunek. Nem sokaig lenne allasod arrafele.

A Linux egy platform, nem pedig egy sima szamologep program. Igenis sokkal jobban ra kell fekudni a kompatibilitasra, mint egy userspace cuccnal. Persze ha a linuxnal nem cel a minel szelesebb koru hasznalat, es vissza akar zsugorodni hobbiplatformma, am legyen. Majd lesz mas.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Egy bank vagy erőmű tudja, hogy mennyi ideig akarja használni az adott rendszert, és olyan hardver-szoftver kombinációt választ, amihez garantáltan lesz támogatás, alkatrész és egyebek a tervezett életciklus végéig. Ha ezt nem tudja megtenni, akkor nem is szívesen dolgoznék ott.

Bank eseteben inkabb arrol van szo, hogy minel tovabb, ugyanis a rendszerek cserebereje nem olyan dolog, amit gyakran megejt az ember. Marpedig ha valami a 6-12 honapos onmagaval sem kompatibilis (ugye elso a biztonsag, tehat keep up-to-date your system), akkor nem azt fogjak sajnos valasztani.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Meg tudtak persze. De a kompatibilitast hurcibalni nem mindig eri meg. Csak azert, mert 10 evvel ezelott volt egy hibas elgondolas, es ezt kihasznaltak/workaroundoltak a programok, attol meg nem kene megorizni a kompatibilitast ezzel a hibaval."

BEEP BEEP

A Linux kernel nem hogy a 10 evvel ezelotti onmagaval, de sokszor meg a negy-ot honapos (!) valtozataival sem kompatibilis. Ezen gondolkodj meg egy kicsit. Vajon mennyire eri meg kabe minden harmadik stabil(nak mondott) kernelre portolni barmit is? Vagy a kompatibilitas rossz dolog, az ordogtol valo es mindenestol kerulendo?

"Az emberek szeretik felhozni a windowst, mint OSt ami tokelyre (tulzasba?) vitte a kompatibilitast. Probalj meg egy osi dosos programot futtatni XP alatt, el fogsz csodalkozni neha."

BEEP BEEP

Erdekes, en a Windows 3.11-hez irt PaintBrush alkalmazast siman hasznaltam XP alatt, pedig az mar igencsak egy oreg program. Most probalj meg egy hasonlo koru grafikus Linuxos programot futtatni.

Synceles: ez igazabol sosem volt fajlmuvelet, ez egy belemagyarazott nem is tudom micsoda. Igazabol ezt a dolgot az ilyen UNIX-szeru rendszerek vezettek be, ami bar tisztelendo valami, es lehet, hogy annak idejen meg jo megoldasnak is szamitott, azonban abban biztos vagyok, hogy manapsag egy kalap sokkal-sokkal jobb megoldast kitalaltak mar az okosok, amivel ez az oreg, becsontosodott technologia kivalthato. Vajon miert nem gondolkodott senki el azon, hogy a UNIX melyseges tisztelete mellett a vakon kovetes mar egy cseppet tulzas.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az emberek szeretik felhozni a windowst, mint OSt ami tokelyre (tulzasba?) vitte a kompatibilitast. Probalj meg egy osi dosos programot futtatni XP alatt, el fogsz csodalkozni neha.

Bocs, de az XP (ill. bármely NT alapú Windows) DOS kompatibilitása pont egy vicc. Azért én még emlékszem az OS/2 Warpra, amelyik rendesen virtualizalta a DOS tasknak az összes hardvert, amin futott, including pl. IRQ és DMA vezérlő. Én OS/2 alatt fejlesztettem a DOS-os zenelejátszómat, meg demókat, meg egy rakás egyéb HW-banging cuccot, mert ha valamit szétbarmoltam a hardverben, csak becsuktam a DOS ablakot, és a rendszer mindent helyrerakott nekem, új DOS ablak, és folytathattam a munkát. Miközben az internet (ill. eleinte BBS) kapcsolatom és más egyéb natív OS/2 cuccok gyönyörűen, döccenés nélkül mentek tovább.

Ja és mindezt egy 100Mhz körüli 486-on, 16MB RAM-mal, úgy 1996 magasságában... És aki azt mondja, hogy 2009-ben nem lenne igény a DOS kompatibilitásra, az nem a való világban él. Ráadásul ha egy 13 éves OS-nek nem volt feladat megoldani, akkor egy mai hipermodern OS-nek se legyen az. IMHO. Szerintem itt a HUP-on is tucatjával vagyunk rendszergazdák, akiknek mai napig kell DOS-os programokkal görcsölni. Egyszerűen mert az üzleti logika abban van írva, és a cégvezetőt baromira nem érdeklik a technikai részletek, viszont elvárja hogy ami 10 éve gond nélkül megy, az ne fossa szét magát attól, hogy új gépet vettek alá.

Ezen kívül a legnagyobb vicc, hogy bár a processzorban a mai napig ott van a V86 mód, lassan szoftverből kell brute-force emulálni a régi x86-okat is, mert az OS-ek basznak támogatni. Szánalmas.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A Windows 2000-tol kezdve ugy tudom nem is volt cel a DOS kompatibilitas megorzese, fokepp azert mert a DOS-emulacio inkabb a parancssor miatt van jelen, nem pedig a DOS miatt. Az, hogy a cmd.exe eleg sokmindent tud a command.com feature-ibol, az nagyon szep dolog, de a DOS ablaknak 2000-tol felfele soha semmi koze nem volt a DOS-hoz egyaltalan. Meg csak tavolrol sem.

Eleve a hardverkezeles is baromi sokat valtozott, nem hogy elbarmolni, de belenyulni sem tudsz. Rengeteg direkt hivas is elveszett, hiszen io/msdos.sys reges-regen nincsen mar seholsem. Innentol kezdve nincs sok ertelme kompatibilitasrol beszelni, mert a DOS ablak by definition nem ekvivalens semmifele DOS-sal. Csak parancssor. Ja, hogy par DOS program megis mukodik benne? Veletlen lehet.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igen. Tipikus példa erre az egyik kedvenc linuxos demóm, az Rgba - XenomorphiC. A readme-ből kiderül, hogy eredetileg Sarge alatt tesztelték, azzal jól is működött. Még etch alatt is futott. Lenny alatt szegmens hibával elszáll. Gondolkodtam rajta, hogy írok nekik, hogy legyenek szívesek újrafordítani, de végül is nem írtam, ugyanis nem hiszem hogy ez az ő hibájuk lenne.

+1
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Sajnos egyre inkabb onanizacios OS-be kezd a linux atcsuszni, mert mig korabban a cel egy-egy eszkoz vagy alkalmazas megirasa volt a celt, egyre inkabb a fejlesztok perverzioinak a kielese fele tolodik. Tovabbi gond ezeknek a perverzioknak a beemelese a fo kernel vonalba. Ilyen speciel most az ext4 is.

Tovabbi problema, hogy egy-egy fejlesztesi vonal sokszor nem annak megfeleloen kerul be, hogy mogotte mennyire atdolgozott, kiforrott koncepcio all, hanem, hogy ki tudja "mukodokepesen" osszecsapni a sajat otletet elsonek. (lasd devfs vs udev)

Tovabbi problema, hogy egy-egy major kernelverzio ugrasakor, "szar az egesz irjuk ujra" mentalitas kerul eloterbe, a kompatibilitas teljes mellozesevel. Ilyennek hala az, hogy teljesen trivialis alkalmazasok (pl. picprog) nem mukodnek az uj kernellel.

Amugy az AmigaOS es MorphOS pont egy jo pelda arra, hogy egy egyszer megfeleloen lespecifikalt es kidolgozott rendszer mikepp kepes hosszutavon mukodni.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Kerdes, hogy a trivialis alkalmazasok (pl picprog) a kernel miatt nem mukodnek, vagy a kulonbozo libraryk miatt?

Lehet en vagyok mazlista, de nekem eddig kernel upgrade sosem okozott kompatibilitasi gondot, pedig 2.5.akarmennyi ota nem hasznalok 2.4-et.

Raterve AmigaOS-re es MorphOS-re... azert az emlitett ket rendszer merfoldekkel egyszerubb szereny velemenyem szerint, mint egy Linux. Masreszt ha egyszer ir az ember egy specifikaciot, es attol nem ter el, az szep es jo, de abba nagyon nehez fejleszteseket bevinni.

Nem mondom, hogy rossz a modszer, mert egy adott celra (t.i. stabilitas es maximalis kompatibilitas) teljesen jo. Fejlesztes szempontjabol viszont nem a legidealisabb.

Neha a kompatibilitas nagyobb nyug, mint amennyi haszna van.

A picprog a TIOCSBRK es TIOCCBRK ioctl hivasokat hasznalja. Ezek gyakorlatilag 2.0.3-tol kezdve benne volt. Aztan szepen belekevertek valamit amito 2.6.0-tol kezdve az egesz ioctl kezeles megborult.
Ez pedig joforman minden olyan kodot erint ami ezeket hazsnalja. De ugyanez volt video4linux ioctl kezelesevel is. Igen vicces, amikor nagy nehezen megir az ember egy alkalmazast egy osszeganyolt modul hasznalatara, aztan egy kernelfrissites utan a frissen forgatott kod izgalmasabbnal-izgalmasabb hibakkal szal el. Es ilyenkor igencsak ketyeg az ember ideje, amit nyugodtan fordithatna sokkal ertelmesebb tevekenysegekre.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Sem a picprog, sem az altalam irt alkalmazas nem volt binary only. Szimplan arrol van szo, hogy az uj kernelben nem implementaltak/nem ugy implementaltak dolgokat amik korabban a rendszer reszei voltak.
Innen kezdve a mezei user a forrassal is ugyanannyit er mint egy binarissal.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

A mezei user akkor ne frissitse a rendszeret. Vagy alalmazzon szakertot, aki megfixalja a hibakat amiket az upgrade okoz (ha okoz).

Mint mondottam volt, a rendszer nem egy kobevesett 10 parancsolat. Nem az a celja. Ha az kell valakinek, hasznaljon mast, aminek ez celja.

Se a linuxnak, se a BSDknek, se a windowsnak nem celja, hogy 100% kompatibilis maradjon magaval a vilag vegeig. Valamennyire, nagyjabol - igen. Ha ennel tobb kell, ne frissits, vagy hasznalj olyan OSt, ami ezt garantalja.

A magam reszerol ugy vagyok vele, hogy ha egy elgondolas hibas volt, akkor azt ki kell dobni, akkor is ha emiatt par programot portolni kell. Inkabb az, mint egy hiba az idok vegezeteig, koszonom szepen.

Persze. De lehetoleg ne teged fogadjon fel.

Valoban, ha egy elkepzeles hibas akkor el kell dobni - ez igy eddig korrekt. De nem ugy, hogy _elotte_ nem kiabalom kozhirre, hogy na gyerekek, most akkor keszuljon mindenki, mert a kovetkezo verzioktol kezdve ez meg ez meg ez az API meg fog valtozni. Es igenis, ertesiteni a 3rdparty gyartokat szemelyesen is akar, ha arrol van szo, nem biztos, hogy eleg egy kernel-devel-announce listas bejelentes, hogy nesztek, itt a lista, es akkor holnaptol villany lekapcs. Majd ha eltelt egy ido - API valtozas eseteben mondjuk par honap - akkor lehet a villanykapcsolo lenyomasat megkezdeni.

Linux eseteben ugy tudom, az a modi, hogy kiadaskor jon egy szep iv, hogy akkor most innentol ezek meg ezek nem mukodnek. Ez az egyik hatranya a mostani fejlesztesi modellnek.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Masreszt ha egyszer ir az ember egy specifikaciot, es attol nem ter el, az szep es jo, de abba nagyon nehez fejleszteseket bevinni.

Nem, ha a specifikacio kelloen generic, de megis egyertelmu es explicit. Lehet ilyet csinalni, minden elozetes hireszteles ellenere is...

Fejlesztes szempontjabol viszont nem a legidealisabb. Neha a kompatibilitas nagyobb nyug, mint amennyi haszna van.

A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma. Es mint mar vagy 3x leirtam, veresre szanakozom magam, hogy pl. evi X milliard dollarert takoljak az x86-ot, meg egyeb hardvereket, hogy kompatibilis legyen 2010-ben is az XT-vel, es a Nagy Szent Szoftverfejlesztonek nehogy meg kelljen eroltetnie magat es valami ujat megtanulni, mert az rossz. Es akkor jon ugyanez a Nagy Szent Szoftverfejleszto, es ket kave kozott kitalalja, hogy nem kell a kompatibilitas a sajat hulladekanak korabbi verziojaval, mert az rossz. Jaj?

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

"A fejlesztot azert fizetik, hogy oldja meg a problemat. "
Ezt mar akartam en is irni, de a te szadbol ennek nagyobb nyomateka van. Igazabol en ezt kabe negyvenpontos betuvel emelnem ki, ha az nem csapna szet az oldal kinezetet.
Ha a Linux kernel fejlesztoi mar egyszer elhataroztak, hogy egy nagyon rendszerkozeli platformot fejlesztenek, akkor legyen bennuk annyi becsuletesseg, es tisztelet a kollegaik irant, hogy odafigyelnek a kompatibilitasra.

Tocsogosra sirom a kisparnamat, hogy egy kernel fejlesztese soran mi mindenre oda kell figyelni, es hogy ez mennyi munka, meg felelosseg. De akik azt mondtak, hogy mi kernelfejlesztok leszunk, azok elvben tudtak mit vallalnak, nem? Ha megsem, akkor itt nagyobb gondok is vannak. Nem tudom sajnalni oket, mert ez a feladatuk, ezt vallaltak.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azt, hogy ahonnan egy nagy cegnek a penze jon, semmit sem tudnak az ilyesmirol. Az a managerek, sales-esek es marketingesek vilaga, akik a szart is aranypapirba tudjak csomagolni. Ez pusztan technikai dontes, semmi mas.

Egyebkent igeny az lenne ra odafentrol is, mert pont azert van az osszes, nagygepekre is arult uzleti disztribnek (Red Hat, SuSE, stb.) sajat kernel aga, valamelyik regi kernel alapjan, amire sokszor backportoljak az ujabb hardverek drivereit is a vevok igenyeinek megfeleloen. A vevo alatt itt termeszetesen nem Atlag "Ubuntu.iso Torrent Rulez" Pistiket kell erteni, hanem az tobbszaz, tobbezer gepes halozatot uzemelteto kasztomereket.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Szerintem sokkal inkabb "vallasi" okok vannak emogott, semmint uzleti, vagy technikai. Es ez a problema. Valaki(k)nek az agyreme miatt, tul sokan szopnak. Koztuk en is, azert anyazok. Simple as that.

Na most mar tenyleg megirom a Binary Compatibility #2 bejegyzest, mert latom tovabbra is tul sokaknak van kaosz a fejeben arrol, hogy mirol is van szo, es miert teljesen ertelmetlen a Linux folyamatos compatibility breakje.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Bármilyen okokat is látsz mögé, ha a munkaadó azt mondja, hogy ezt és ezt kell csinálni, akkor ezt és ezt kell csinálni (vagy lehet menni világgá). A mellékelt ábra azt mutatja, hogy a munkaadó nem mondja azt, hogy tessék megőrizni a belső kompatibilitást.

fyi, egyszer sem foglaltam állást amellett, hogy a jelenlegi helyzet jó vagy rossz. De a jelenlegi helyzet adva van, tudomásul kell venni, és vagy meg kell tanulni alkalmazkodni hozzá, vagy hagyni a Linuxot a francba. "Simple as that."

Bármilyen okokat is látsz mögé, ha a munkaadó azt mondja, hogy ezt és ezt kell csinálni, akkor ezt és ezt kell csinálni (vagy lehet menni világgá)

Ja, tenyleg. Szerintem is tok realis elkepzeles, hogy a Red Hat sales-ese ott veri az asztalt azoknal a Linux kernel fejlesztoknel egy ilyen kerdessel, akikert amugy versenyt licitalna az osszes tobbi Linuxos ceg.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

RedHat felveszi az embert, aki csinál amit akar. Hát persze.

Ööööö. Szerintem nézz utána... Mondom, hogy még nem láttál nagyobbacska szoftvercéget működni belülről... Nem olyan emberekről van szó, akiket CV alapján, 12 egy tucatból választottak ki, hogy ki fogja írni a Flashes honlaphoz az index.php-t...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

> Azt, hogy ahonnan egy nagy cegnek a penze jon, semmit sem tudnak az ilyesmirol.

Kb ugyanerre mondtad, hogy "akkor nem mondanal ilyen hulyeseget". (Hogy ne kelljen keresgélni: "Úgy tűnik, hogy akik fizetik őket, azok nem tartják problémának")

> Egyebkent igeny az lenne ra odafentrol is,

fsync()-re, vagy mire?

Amúgy meg egyetértek, aki a munkát megfizeti, az követelhet.

Akár hülyeség, akár nem, a te kijelentéseidből következik.

"A fejlesztot azert fizetik, hogy oldja meg a problemat." Továbbá azt is mondod, hogy a kernelfejlesztők úgy fejlesztenek, hogy szarnak a kompatibilitásra. Közismert, hogy a kernelfejlesztők nagy része pénzt kap azért, hogy kernelt fejleszt. Ezeket logikusan összekapcsolva nem nagyon tudok másra gondolni, mint hogy akik fizetik őket, azoknak a kernel ilyen értelemben vett kompatibilitása nem fontos.

A gond itt szerintem inkabb arrafele keresendo, hogy nincs kifejezett allaspont, hogy kell-e kompatibilitas vagy sem, es ugy nez ki, sok kernelfejleszto akkor sem megy el a kompatibilitast megorzo iranyokba, ha ezt amugy viszonylag fajdalommentesen, a ceg politikajaval nem szembehelyezkedve megtehetne. Szerintem ez viszont sulyos gond, de fixme.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

> sok kernelfejleszto akkor sem megy el a kompatibilitast megorzo iranyokba

Nem vesznek plusz munkát a nyakukba, ez tény. Az a fizetett 10-15% azért, mert nem ezért fizetik őket; a nem fizetettek meg ezért, mert ők döntik el. :-)

Ha betolt valaki egy drivert a kernelbe aztán magára hagyta, akkor a kompatibilitás megőrzése az inkompatibilissé vált kód törlésével jár inkább, minthogy valaki a nyakába venné a hardverrel történő ismerkedést, hogy karbantarthassa a drivert.

Ez van. Vagy valami ilyesmi. Ha nem tetszik, be lehet szállni. :-)

Tudod mi a gond? Hogy a kernel fejlesztesenel az egyszeru kis developerke szart se er, mert a mentalitas a 'felsovezetes' koreiben rossz. Mivel nekik sincs igenyuk ilyesmire, szarnak bele a kompatibilitasba, innentol nem lehet sokat varni a tobbi developertol se, szellel szembe senkinek nincs kedve menni.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem az a gond, hogy a gond gond-e vagy nem gond, hanem az a gond, hogy akinek gond, az nem dolgozik hogy a gond ne legyen gond, aki meg dolgozik, annak ez nem gond.

:-)

> a kernel fejlesztesenel az egyszeru kis developerke szart se er

Mint ahogy az életben amúgy is lenni szokott: ha nem vagy elég jó egy melóra, akkor nem kapod meg.

> szellel szembe senkinek nincs kedve menni

Valahogy mérni kell hogy mi fontos, és mi kevésbé az. Ha senki sem vállal komolynak nevezhető erőfeszítést, akkor az nem fontos.

Persze ettől még gond.

Nem ugy ertettem, hanem hogy egy egyszeru kis developernek nem sok szava van a nagy vezetesbe. Hiaba vetne fol mittomen vmiklos hogy ez jo lenne, ha egy komplett fejlesztogarda lenne ellene. Persze az indentalason orakat el tudnak vitatkozni.

Tegyuk hozza, _szamukra_ nem fontos.
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A kompatibilitás egyúttal visszafogja a fejlődést, időnként muszáj változtatni egy-egy hibás tervezésen, még akkor is ha ez fáj másoknak. A Windows talán legnagyobb hibája, hogy a végletekig ragaszkodnak a visszafelé kompatibilitáshoz. Sok lehetőségük nincs hiszen a régi abadonware, de még használt programok senki sem fogja újrafordítani vagy neadjisten portolni az új API-kra.
Linuxon a legtöbb program esetében megvan a lehetőség. Ha lenne rá igény nem tartana sok ideig megcsinálni, hogy a linux képes legyen egy bizonyos verziójú linux utánzására, ahogy képes rá sok rendszer köztük a MorphOS. Erre többnyire egyszerűen nincs igény.
Néha a jövő érdekében szakítani kell a múlttal, és ez szerintem így van jól.

FYI, regebben voltak megoldasok arra, hogy mas OS, mas architekturajara irt programokat lehetett futtatni linux alatt (hirtelen nem ugrik be milyen kombinacio volt, utana tudok jarni ha fontos).

Szoval nemcsak lehetseges ez, hanem meg is csinaltak. Csak, pont ahogy irtad, nem volt ra igeny, hogy megerje hosszu tavon ezt karbantartani.

A kompatibilitás egyúttal visszafogja a fejlődést, időnként muszáj változtatni egy-egy hibás tervezésen, még akkor is ha ez fáj másoknak. A Windows talán legnagyobb hibája, hogy a végletekig ragaszkodnak a visszafelé kompatibilitáshoz. Sok lehetőségük nincs hiszen a régi abadonware, de még használt programok senki sem fogja újrafordítani vagy neadjisten portolni az új API-kra.

Semmi bajom a fejlodessel, es a pozitiv peldakent hozott AmigaOS/MorphOS parosnak is eppen eleg baja van a regi, az API-t ossze-vissza hasznalo alkalmazasok tamogatasaval, meg azokkal az egykori featurekkel, amiket ma mar inkabb bugkent tartunk nyilvan (bar az is megerne egy miset, hogy miert). De nyilvan a fenti ket rendszer a kompatibilitas extrem peldaja.

Az egesz problema tulajdonkeppen annyi, hogy a kernel fejlesztok a fejlesztes "gyorsitasa" (szerintem meg inkabb a sajat kenyelmuk) erdekeben feladtak a stabil kernel agat, hogy elkeruljek a nagy verziovaltasnal jelentkezo hosszas szopasokat. Ezzel persze csak annyit ertek el, hogy nem csak a fejltesztok/betateszterek szopnak, es nem csak verziovaltaskor, hanem MINDENKI szop, es folyamatosan. Ez a fo problema. Pedig a migracio eleve azert volt szopas, mert semmifele kompatibility layer nem letezik a kernelverziok kozott.

Senki nem szolna egy budos szot se, ha atvarialnak pl. a driver API-t pl. a 2.6 -> 2.8 -> 2.10 stb kozott, mikozben a 2.6 mondjuk meg tudna a 2.4-et, a 2.8 a 2.6-et es igy tovabb visszafele. Userspace dolgai detto. A kompatibilitas teljes ignoralasa es a vegnelkuli visszafele support kozott van egy arany kozeput. Meg kene talalni, mert ugy lehetne igazan jo OS-t irni... IMHO.

(Egyebkent jo kis flame-et generaltam ide, ez mar tetszik, hehe. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Mindig tanul valamit az ember... Egyebkent szerintem pont nem, hanem kisebb lenne. Mert ha lenne valamifele kompatibilitas, akkor egy rakas dolgot nem kene a kernellel szallitani, teszemazt pont a regi hardverek tamogatasahoz szukseges, regota erintetlen "bentfelejtett" drivereket, amiket ha akar valaki feltehet egy -legacy csomagban eppugy, ahogy most a binaris driverek mennek fel.

Mint ahogy MorphOS alatt bemasolom az 1990-es C= ethernet kartyam Aminetrol leszedett driveret a DEVS:Networks/-be, es megy.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

"However, DMA transfer between userspace and kernelspace is not yet implemented. This means essentially that drivers which involve high traffic are not an option yet. So graphic drivers as well as file system drivers and similar cannot use this API at the moment."

*Böff*. Ha ez azota sem valtozott, akkor ez nem driver API, hanem vicc.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A linux* egy olyan rendszer amelynek a legtöbb béta tesztere van az egész világon :)
Mi ezzel a gond? Jahogy, mostanában egyre több a végfelhasználó... értem.

*kernel + minden más
--
\\-- blog --//

Én szívesen növelném az Amigas-ok vagyis Pegasos-osok táborát 1 fővel. Ha tudsz olcsón valamit alaplapot, gépet, stb.... akkor érdekelne.

en a *solaris-t emlitettem volna
kicsit kozelebbinek tunik mint az amiga

--
HUP@Steam

Jah. De a Solaris sem teljesen tokeletes e tekintetben, legalabbis igy elso gyors ranezesre:

http://www.sun.com/software/solaris/programs/abi/appcert.xml

Ez azt sugallja, hogy azert vannak ABI valtozasok (ha mas nem, deprecated interface / library), vagy lehetnek a jovoben. Csak epp van ra tool, hogy a fejlesztok ezt kezelni tudjak.

Ketsegtelen, hogy tobbet igernek mint az OSek tobbsege, de Solarison sem garantalt, hogy amit X eve irtal, az ma is mukodni fog (csak nagyon nagyon valoszinu, felteve, hogy csak a public interfacet hasznaltad, amit nehol szeretnek megkerulni, es olyan dolgokat hasznalni amit nem kene - ne kerdezd miert).

Bocsi a hulye kerdesert, de uj vagyok a temaban: jol ertem, hogy MorphOS nem csak PowerPC-n megy? Erdekes lenne x86-on is kiprobalni valami hasonlot, de gondolom akkor ez felejtos, mert nem megy azon az architekturan. Jelenleg csak emiatt viszont nem engedhetem meg magamnak mas gep vasarlasat, mint ami jelenleg is megvan ...

Btw ez az ext4 nulla byte-os problema egy vicc, hogy mit csinalnak belole, hatha valaki fogja, es truncate-eli a file-t es ujrairja, mi abban a fura, hogy 0 byte-os lesz, ha pont az ujrairas elott szall el a cucc pl? :) Ez teljesen termeszetes, nem igy kene ugye kiirni az ilyesmit, hanem pl uj file-ba beleirni, majd atnevezni a regire, eleve mi van ha pont betellik a disk pl ujrairas kozben stb stb, akkor annyi volt a jatek, es lehet, kozben mas is irt az fs-re, es meg a regit sem lehet visszairni, visszaallitando az eredeti allapotot ...