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.
- Chain-Q blogja
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
X (csak kicsit drága hozzá a PC)
- A hozzászóláshoz be kell jelentkezni
Solaris 10. :)
--
"- The question is: what is a mahna-mahna?
- The question is: who cares?"
- A hozzászóláshoz be kell jelentkezni
http://www.sun.com/bigadmin/hcl/data/systems/details/27558.html
Nincs wifi :(
"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q
- A hozzászóláshoz be kell jelentkezni
De legalább kompatibilis (;
- A hozzászóláshoz be kell jelentkezni
opensolaris szobajohet?
http://opensolaris.org/os/community/laptop/
http://opensolaris.org/os/project/sierra/
--
HUP@Steam
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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” :)
- A hozzászóláshoz be kell jelentkezni
"A gond szerintem leginkabb az, hogy nincsen kulon testing ag"
Marmint stabil ag.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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á.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azok nem "un. publikus interfészek", hanem deklaráltan idővel változó belső interfészek.
- A hozzászóláshoz be kell jelentkezni
Es ez szerinted vigasztalja azt a mezei usert, akinek a HW-jehez csak regebbi, nem a kernel reszet kepezo, de amugy jol mukodo drivere van (volt)?
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Na, már a jól működő driver is baj.
- A hozzászóláshoz be kell jelentkezni
Read again, kthxbye.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
"de amugy jol mukodo drivere van (volt)?"
Read again, kthxbye.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
> ami az új verzióval természetesen nem megy
Én ilyenkor visszaállok a jól bevált kernelre, nem kezdek hisztizni. Mert továbbra is jól működik ...
Cizelláljam tovább, vagy most már átért, receive acknowledged?
- A hozzászóláshoz be kell jelentkezni
Én ilyenkor visszaállok a jól bevált kernelre
Probaltal mar barmilyen mostani disztribet pl. 2.6.8-al futtatni? Probaltal mar alapbol 2.6.8-as disztribre barmilyen mai userspace cuccot leforgatni?
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Akinek latest-greatest mániája van, az meg is érdemli.
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
> A mezei endusernek (konkrét példa: barátnőm édesanyja) nehéz elmondani,
Nem nehéz: "teccik tudni a trabantba nem működik a mercédesz motor".
- A hozzászóláshoz be kell jelentkezni
Ez tok jo moka abban az esetben, ha pl. egy remote, esetleg akarmilyen sechole volt az elozo verzioban. Vagy adat erroziot okozo problema miatt akar frissiteni. Erre is volt mar pelda a tortenelemben.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Tele van az élet ilyen "egy seggel két lovat" esetekkel, csak azoktól nem kezdenek hisztizni az emberek.
- A hozzászóláshoz be kell jelentkezni
Micsoda ervek.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Amilyen a kérdés, olyan a válasz.
- A hozzászóláshoz be kell jelentkezni
Tehat a velemenyed szerint ha valaszthatsz a hulladek es a tragya kozott, akkor oruljek, h egyaltalan mukodik, es kuss a nevem? Ez igen. Teljesen felesleges akkor legalabb a hasznalhatosagra torekedni, ugyis baromsag.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Hogy is van ez? Én választhatok, te örülj és kuss. Ez igen.
Meg kinek kéne a használhatóságra törekedni? Nekem vagy neked?
Zavaros.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
zamboriz szerint ez a tokeletesseg kulcsa.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Az a csóka tiszta MS fanboy. :-D
Ave, Saabi.
- A hozzászóláshoz be kell jelentkezni
Ehh, s/elvesztem/megtartom
a lényeget azért értettétek :)
- A hozzászóláshoz be kell jelentkezni
> Kurvajó, gratulálok.
Ha még soha, semmivel nem jártál így, akkor neked tényleg jó. (Megy az összes ISA-s kártyád, Gravis, 5 1/4 -es floppy, nyomtató portos ZIP, MFM vinyó, ..., gratulálok.)
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
> Az a sajnálatos, hogy szerinted ez így elfogadható.
A hisztizés? Az nem elfogadható.
- A hozzászóláshoz be kell jelentkezni
A userek hisztiznek. Ez egy kemény szakma :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
> Nem mindenki teheti meg, h csak ugy lecserelje a hw-t, plane ha az mukodokepes es jo.
Valóban. Meg olyan is van, aki nem cserélheti le a kernel-t.
> Mintha egyik erv lenne a linux mellett, h a regebbi hardverekkel is emberi eroforras igeny mellett kepes mukodni.
-a
- A hozzászóláshoz be kell jelentkezni
Valóban. Meg olyan is van, aki nem cserélheti le a kernel-t.
Ugy latom sikerult megertened a problemat.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Valóban. Meg olyan is van, aki nem cserélheti le a kernel-t.
És loop
Az nem megoldás, hogy soha (vagy szökőévente) frissítünk, me megy minden.
Tisztára mintha polit hallanám :)
- A hozzászóláshoz be kell jelentkezni
> És loop
Semmitmondó szövegre, semmitmondóan reagáltam.
> Az nem megoldás, hogy soha (vagy szökőévente) frissítünk, me megy minden.
Helyzetfüggő hogy mi a megfelelő megoldás. Nincs olyan megoldás, ami minden helyzetben egyformán tökéletes lenne.
- A hozzászóláshoz be kell jelentkezni
Az arany középútnak örülne mindenki.
Az, hogy a kompatibilitás jelenleg mindenhol egyformán szar, nem az.
- A hozzászóláshoz be kell jelentkezni
É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 :)
- A hozzászóláshoz be kell jelentkezni
> 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. :-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem, de legyen openszósz meg fríszoftver meg dzsipiL es legyen a kernel resze es akkor jon a nagy haleluja!!!
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"Amit Linuxra írnak az fut ha Linux fut!"
Tudod bar igy lenne... sokkal egyszerubb lenne az elet...
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
É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."
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
funkernel? :)
- A hozzászóláshoz be kell jelentkezni
"Ha nem tetszik miért nem indítassz egy saját kernel forkot" -> hagyjuk mar az ilyenfele beszolasokat.
- A hozzászóláshoz be kell jelentkezni
azért nincs kernel fork, mert inkább az emberek átpártolnak értelmesen fejlesztett OS-ekre (windows, OSX, *BSD, Solaris etc.)
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
"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!
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
"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])
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
> Ezt add be mondjuk egy banknak vagy egy eromunek.
Akkora válság azért nincs, hogy csak fagyós PC-re telik.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Hat ezaz. Mondjuk Linux tajekan az adott verzio supportja 4-5 ev, eromuvek,ipari rendszeriranyitas eseteben inkabb 15-20 eves supportrol van szo.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Hát akkor nem azt választják. És?
- A hozzászóláshoz be kell jelentkezni
Ja, ilyen hozzaallas mellett persze. Tudod mit, meg csak veletlen se ugyeljenek a kompatibilitasra, sot, meg a PC-ken valo elindulas sem cel. VMware-n mukodjon, azt csa.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
"Vajon miert nem gondolkodott senki el azon, hogy a UNIX melyseges tisztelete mellett a vakon kovetes mar egy cseppet tulzas. "
+1, főleg, hogy arról beszélünk, hogy kompatibilitás a világ végéig, vagy újítani kell [időnként].
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"Bocs, de az XP (ill. bármely NT alapú Windows) DOS kompatibilitása pont egy vicc"
Almat hasonlitasz kortevel. A Linuxnak milyen a Minix kompatibilitasa?
- A hozzászóláshoz be kell jelentkezni
Bocs de... Elolvastad a hozzaszolas tobbi reszet is? :) Az OS/2-nek sincs tobb koze a DOS-hoz, mint az NT-nek, sot... Szoval a gyumolcsoket inkabb hagyjuk.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Orulok neki, hogy nem ertetted meg, hogy mirol beszeltem. :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
"Hibas felfogas, hogy az alkalmazas iroja szinkronizalja az adatokat, ugyanis egyreszt ez egy belso filerendszer muvelet, masreszt mas filerendszerekkel valo kompatibilitast csokkenti."
Heh?! Milyen belső filerendszer művelet csökkent milyen kompatibilitást?
- A hozzászóláshoz be kell jelentkezni
"Van". linux-next a neve és offical.
--
\\-- blog --//
- A hozzászóláshoz be kell jelentkezni
Én úgy tudom, erről szól(t) a hosszú karbantartású kernelfa. Hogy mi van most vele, azt nem tudom, mert egyrészt én nem figyelem ennyire a kernel körüli eseményeket, másrészt pinyo átpártolt FreeBSD-re.
- A hozzászóláshoz be kell jelentkezni
Most a 2.6.27 az ún. "stabil" ág.
- A hozzászóláshoz be kell jelentkezni
Na jól van én vagyok a hülye, mondom, hogy nem ismerem ki magam a linux kernelfában. :)
- A hozzászóláshoz be kell jelentkezni
stabil ag != hosszu karbantartasu kernel
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Tudom. Csak rosszul linkeltem itt.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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. "
- A hozzászóláshoz be kell jelentkezni
Najah, ilyen is van. Ne tessek binary-only cuccot hasznalni, vagy ha megis kell, arra ott van az emulator.
Van olyan, hogy a kompatibilitasnak tobb hatranya lenne, mint a kompatibilitas megszegesenek. Feltehetoleg ebben az esetben is ilyesmirol van szo.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
"With great code comes great responsibility" :)
- A hozzászóláshoz be kell jelentkezni
Úgy tűnik, hogy akik fizetik őket, azok nem tartják problémának a belső interfészek kompatibilitásának hiányát.
- A hozzászóláshoz be kell jelentkezni
Ha lattal volna belulrol nagyobbacska szoftverfejleszto ceget mukodni, akkor nem mondanal ilyen hulyeseget.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Mit szerettél volna mondani?
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
Igény lehet, hogy lenne, de ezek szerint még nem elég erős ahhoz, hogy a kenyéradók a kernelfejlesztők körmére nézzenek.
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
> egy ilyen kerdessel
Milyen kérdéssel?
RedHat felveszi az embert, aki csinál amit akar. Hát persze.
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
Egy "igen" is elég lett volna. Mindegy, így tovább magyarázva is hülyeség.
- A hozzászóláshoz be kell jelentkezni
A valosagot lehulyesegezni meglehetos mereszsegre vall, de ahogy erzed. Azert orulok, hogy ilyen jot beszelgettunk.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Mesélj, milyen volt dolgozni a RedHat-nél? Kiraktak, mert nem voltál hajlandó fsync()-et rakni a kódodba, vagy mi történt?
- A hozzászóláshoz be kell jelentkezni
Szerintem teljesen reális az az elképzelés, hogy egy cég olyan dolgokat fejlesztet a fejlesztőivel, amit utána jól el tud adni.
- A hozzászóláshoz be kell jelentkezni
Pedig valaki verhetne mar az asztalt a Linux fejlesztoknel, mert ami itt megy az a sz*r also hatarat sem surolja mar lassan.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
> tul sokaknak van kaosz a fejeben
Semmi baj, majd segítünk. Csak okosan kell kérdezni.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
Amúgy meg egyetértek, aki a munkát megfizeti, az követelhet.
Lasd fent.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
Lásd lent.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Lasd fent.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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. :-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
mikozben a 2.6 mondjuk meg tudna a 2.4-et, a 2.8 a 2.6-et es igy tovabb visszafele
És a végén a mérete miatt külön dvd-n adnák ki a kernelt, a többiről nem is beszélve.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
- A hozzászóláshoz be kell jelentkezni
Ööööö... He?
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
- A hozzászóláshoz be kell jelentkezni
A túlzott kompatibilitási kényszer méretnövekedéssel is jár.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
> Mert ha lenne valamifele kompatibilitas,
http://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-to-have-stab…
- A hozzászóláshoz be kell jelentkezni
"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 hozzászóláshoz be kell jelentkezni
> Ha ez azota sem valtozott,
Nézz utána nyugodtan.
- A hozzászóláshoz be kell jelentkezni
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 --//
- A hozzászóláshoz be kell jelentkezni
Pontositsunk: egyre tobb a magat vegfelhasznalonak kepzelo emberke.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
en a *solaris-t emlitettem volna
kicsit kozelebbinek tunik mint az amiga
--
HUP@Steam
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
nem tudom, de pl ott van(volt) a blastwave a csomagok mennek 8as solaristol felfele
vagy 3rd party driverek, igaz lehet 8as driver nem megy de 10es es 11esen de ami 10 re lett irva az megy 11esen
igaz, lehet nem tokeletes magaba.
de ilyen teren linuxhoz viszonyitva az
--
HUP@Steam
- A hozzászóláshoz be kell jelentkezni
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 ...
- A hozzászóláshoz be kell jelentkezni