Tudod, hogy süsü témára ugrok. Pláne, ha valaki hülyeséget beszél.  ;D
Amit mondasz, az terelés, és az sg.hu-n esetleg be is veszik.
Miért kéne egy három évvel ezelőtti programot feltenni? A kompatibilitás lényege az, hogy amit egy három évvel ezelőtti KWrite-on megírtál, az a JELENLEGI KWrite-on is megnyitható, szerkeszthető, főzhető, süthető, ehető.
Ami viszont nem igaz a különböző májkroszoftofisz alatt létrehozott dokumentumokra.
Persze a linuksz ettől még sz@r.  ;D
Egyébként ahogy örökösen hivatkozol egy régóta nem támogatott rendszerre, már több mint nevetséges.
Ezen az alapon a windows 3.1 mi a francér nem tudott pl. dvd-t lejátszani? Ne komolytalankodjunk.

Szerk.: a win 3.1 meg a dvd rossz példa volt, elnézést. Az ikszpé sem tudja.  ;D

Az a baj hogy a mai linuxosok fejében elég érdekes fogalmak élnek a kompatibilitásról. Nos, akkor tegyük picit tisztába:

Van az operációs rendszerek kompatibilitása, ezen belül is van bináris és forrás szintű kompatibilitás. A bináris kompatibilitás azt jelenti hogy ha van egy X oprendszeren futó programom akkor azt mennyire tudom futtatni az Y operációs rendszeren, legyen X és Y különböző oprendszer, vagy ugyannannak a verziónak a különböző verziója. Itt alapvetően két dolog merülhet fel: egyrészt az hogy az X oprendszer tudja-e futtatni az Y oprendszeren futó programot változtatás, emuláció nélkül, másrészt a dll-pokol, azaz az X oprendszer rendszer dll-jei kompatiblisek-e Y-nal. Másik dolog a forrás szintű kompatibilitás, amikor az X oprendszerre megírt program lefordítható Y oprendszer alá is.
Windows esetén a bináris kompatiblitás viszonylag jó, legalábbis régebbi->újabb irányban. Persze nem lehet tökéletes, mivel azért  volt pár olyan dolog ami elkerülhetetlen volt, Pl. a 9x alatt még sok mindent megtehettél amit nem illendő egy oprendszerben. Forrás szintű kompatibilitás az egyes verziók között pont annyi mint a bináris, az API nem nagyon változott csak bővült.
Linux esetén más a helyzet. Maga az a.out illetve elf formátum nem igazán változott, de itt is bekerültek olyan dolgok ami miatt a bináris kompatbilitás billeg, Pl. a szálkezelés ami anno először fejreállította a Kylixot (de azt még ki lehetett védeni LD_ASSUME_KERNEL-lel). Nagyobb gond a dll pokol, ugyanis linux alatt általában nem bővül az API hanem változik, ami azt jelenti hogy a dll újabb verziók visszafelé sem kompatibilisek binárisan, ezért nem tudod a KDE X-es verzióján a KDE X-1-es binárist (Pl. kwrite) futtatni. Ezek már binárisan nem kompatibilisek, de forrásszinten igen. Aztán úgy 2-3 évenként végigsöpór egy-egy olyan nagyobb hullám a linuxon ami a forrás szintű kompatibiltiást is elsöpri, ilyen volt Pl. a KDE2->KDE3 átállás.

Ettől független az hogy az oprendszeren futó X program mennyire tudja írni vagy olvasni ugyanennek a programnak az X-1 verziójával készült adatformátumot. Ennek kb. annyi köze van az oprendszer kompatiblitáshoz mint ha azt mondanád hogy a terepjáró azért szar mert többnyire agresszív kopasz kigyúrt alakok ülnek benne.

DVD olvasás: linux-szal legálisan nemigen fogsz gyári (nem másolt) DVD filmet lejátszani. A libdvdcss ugyanis nem igazán legális mint ahogy Pl. az mplayer/xine win32-es codecjei sem azok, valamelyik pedig kell ahhoz hogy DVD-t olvass. Bár pár éve volt valami legális (és persze fizetős) progi de én azóta sem hallottam felőle. Linuxra nem üzlet fizetős progit fejleszteni…

Miért kéne egy három évvel ezelőtti programot feltenni?

Mert a (win) programozók ált. lusta disznók. )))
X millió forintért árulnak egy gyak. 3.1-esre írt sz@rt, amin szinte csak a telepítőt változtatták, hogy fusson 95-ön is. )) (Na ezért.)
Ha jó a kit-kat ide, akkor xp-re is le tudják fordítani. És, hogy legyen látszata a „fejlődésnek” a verziószámot is át lehet írni.

Persze csak egy kicsit. Mert a közigazgatósági sw-eket is fejleszteni kell.

Ez a legfőbb költség. Az ügyintézőt lehet addig verni amíg el nem kezd linuxot használni, de szoftver híján max. a tuxracert tudja futtatni.

A fejlesztő környezetről meg annyit: ha egy gimpet meg lehetett írni c-ben, akkor egy közigazgatósági sw-t is meg lehet írni mondjuk kdeveloppal. (Persze, ha valaki egy kit-kat programmal dolgozik, annak nehéz megemészteni, hogy egy gimp milyen bonyolultságú feladat.

Persze hogy meg lehet. Meg lehet assemblyben is, csak pénz és határidő kérdése. 😉

Egy előnye van. Az integráltság. (És csak vindóz alatt.)
Persze ez rögtön bukik, ha a ms idétlen hülyeségei helyett – mert van pár -, valami értelmeset is akarsz néha használni.

Mire gondolsz ?

Ma reggel azzal kezdtük, hogy újratelepítettük a drivereket… mert, ha mást dugsz az usb-be, vagy máshova, vagy egy darabig nem használod, vagy napfény van, vagy eső, akkor nem működik. (Kiv. az usb drive, egér, vagy billentyűzet, mert azok egyelőre még mennek. Igaz, hogy csak xp-t használunk nem vistát. Ugyhogy van még mit fejlődni a vindóznak :devil: .)

Őszintén szólva nem igazán találkoztam ilyennel. De nem kizárt – windows alatt a gyártó írja a drivereket, és nem lehet könnyű jó drivert írni úgy hogy az ember segge alatt folyton himbálózik a dzsunka 😀

Windows esetén a bináris kompatiblitás viszonylag jó

Milyen lenne? Semmit nem változtattak rajta. :))))