Linux Unified Kernel: Windows programok futtatása Linux alatt

Címkék

A Linux Unified Kernel (LUK) - vagy más néven "Longene" - egy szabad, nyílt forrású operációs rendszer kernel projekt, amelynek célja kibővíteni a Linux kernel funkcionalitását úgy, hogy az binárisan kompatibilis legyen Linux-ra írt programok mellett a Microsoft Windows-ra írt alkalmazásokkal és eszközmeghajtó-programokkal is. A cél, hogy lehetővé tegye a Windows alkalmazások nagy hatékonysággal való futtatását Linux-alapú operációs rendszereken.

A fejlesztők azt remélik, hogy a LUK segítségével a Windows futtatásához szokott felhasználók folytathatják megszokott tevékenységeiket Linux alatt, vagyis a 3rd party szoftvervásárlók számára közömbössé válhat a futtatott operációs rendszer platform. Eddig az a felhasználó, aki Windows felhasználói programot vásárolt (majdnem) kizárólag csak Windows-on tudta azt futtatni, de ezután - a LUK fejlesztők szerint a Wine mellett - lehet más választása is. A remények szerint a LUK a Linux elterjedését illetően pedig vízválasztó lehet, hiszen növelheti a szabad operációs rendszer piaci versenyképességét azáltal, hogy képes lesz Windows programok futtatására is.

Longene - StarCraft Longene - Photoshop
StarCraft Photoshop

A Linux Unified Kernel projektet a Insigma Technology Co. Ltd. szponzorálja. A LUK SourceForge-on hostolt projektlapja szerint a cél egy Linux kernelmodul megalkotása, amely rendszerhívásokat és eszközmeghajtó-program réteget biztosít a Windows programok futtatásához.

A jelenleg pre-alpha státuszban levő Longene szabad szoftver, a fejlesztők a GNU GPL feltételei szerint terjesztik.

A projekt FAQ-ja kitér arra, hogy milyen létjogosultsága lehet a LUK-nak a Wine mellett, ami szintén Windows-ra írt programok futtatását teszi lehetővé Linux-on (is). A LUK honlapja szerint a Wine hatékonysága a hosszú fejlesztés után nagymértékben nőtt, de abból kifolyólag, hogy egy user space-ben működő köztes réteg, nem tudja a hatékonysági problémákat teljes egészében kiküszöbölni és itt jöhet a képbe a LUK.

Noha a LUK a Wine-ra szeretne alternatívát nyújtani, jelenleg még szüksége van a Wine-ra. A fejlesztők még nem tudtak minden szükséges rendszerhívást implementálni, ezért a LUK-nak még szüksége van Wine több összetevőjére is.

A LUK teoretikusan az összes modern Linux disztribúción működik. Több Linux disztribúción - köztük a Fedora-n, Ubuntu-n - tesztelték.

A Linux Unified Kernel legfrissebb kiadása a napokban jelent meg. Ezt a kiadást a fejlesztők mérföldkőnek tekintik, mert már külső hozzájárulóktól származó kódokat is tartalmaz. A fejlesztők szerint ezen a verzión a Windows alkalmazások már jobban teljesítenek, mint Wine-on és ez az első alkalom, hogy a fejlesztők bináris csomagokat is kínálnak a forráskód mellett.

A projekt honlapja - letöltési lehetőségekkel - itt. Bővebben itt és itt.

Hozzászólások

Ezzel az a baj, hogy 2005. szeptemberben indult, tehát 3,5 év kellett a pre-alpha eléréséhez, akkor hol van még a stabil verzió? 4-5 év? Addigra meg elavult lesz.

És így a vírusok is ugyanúgy futni fognak Linux alatt.

Lásd az alsó hozzászólásomat. Ha az ezzel a képességgel ellátott Linux rendszerek is ugyanannyira veszélyeztetettek lesznek mindenfajta malware-re, akkor annyi fog történni, hogy a vállalat nem csak a biztonsági szoftverrel foglalkozó cégek között tud választani, hanem olyanok között is, akik az oprendszert szállítják neki.

********************
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

Nemtom, szerintem ahol már egy Photoshop elfutkorászik, ott azért már elég sok dolog működik. És hol van még ugyebár a feature freeze... Ígéretesnek tartom, de valóban kell neki szerintem mondjuk 2 év még, hogy használható alternatíva legyen.
És akkor lesz egy normál kernelem, meg egy lukas :)

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Ez érdekesen hangzik, bár ha ez kernel modul akkor csak kell valami user space szintű dolog is a grafikus részek emulációjához.

Viszont legalább a website elérhetetlen, gondolom pár tízezren ráestek mostanában...:-)

paste az oldalról:
"Short-Term Plan
Linux Unified Kernel 0.2.4 will be released in May, 2009.
Medium-Term Plan
Achieve all win32 system calls, really embodies the advantages of Linux Unified Kernel in compatibility and efficiency.
Long-Term Plan
Achieve windows device driver framework and device driver interface support. "
az utolsó sor szerintem akár DX és .NET futtatást is lehetővé tehet...

En nem is errol beszeltem. Egy csomo olyan program van, ami managelt kodbol nem-managed kodot hiv (WinAPI hivasok), es ezen programok a platformok kulonbozosege miatt nem tudnak muxeni. Erre van a mono-ban valami winelib-es kezdemeny, hogy az ilyen rendszerhivasokat automatikusan tovabbitsa a wine fele.
--


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

Khmm... pedig annyira egyertelmu igyekeztem lennni... Szoval, jelenleg _nincs_ osszehekkelve a wine-nal, DE van egy kezdemenyezes az svn-jukben ennek megvalositasara. De ez csak _kezdemenyezes_, nem pedig kiadott termek. Ennel nem tudok egyertelmubb lenni, sajnalom.
--


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

Fasza, csak két kérdés:
Melyik Win verziót vették alapul a fejlesztéskor? Mert szép dolog az egész, de a Win7-el az egész megy a levesbe, ergo, egy másfél éven belül kezdhetik az egészet előlről, hogy aztán 3,5 éb után ismét kezdjék előlről.
Mi lesz a win specifikus biztonsági kérdésekkel? A wine-os userspacebeli futtatás miatt, elég macerás bármilyen csúnyaságot összeszedni, mivel annak a futása csak addig tart, amíg az alkalmazás megy, és nem teljes értékű környezetet ad. Itt pedig egy kernel szintű dologról van szó, és nem világos, hogy milyen szolgáltatások vannak implementálva.

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

"a Win7-el az egész megy a levesbe"

Nem tudom, API szinten milyen újdonságok lesznek a Win7-ben, de valószínűleg még elég sok évig nem lesznek Win7-only alkalmazások. És, gondolom, nem kell minden Win verzióhoz újraírni az egészet, az MS se írja 0-ról újra a Windowst minden verzió előtt.

"Mi lesz a win specifikus biztonsági kérdésekkel?"

A felhasználó által elindított trójai bármilyen rendszeren kockázat, és Wine-nal is össze lehet szedni. (Viszont jó eséllyel eléggé különböző a környezet ahhoz, hogy ne működjön, ez itt is igaz.) Windows biztonsági rést kihasználó vírusok nyilván nem fognak működni, mert elég kicsi az esélye, hogy ugyanazt a bugot beleteszik a LUKasak is. Alkalmazás (pl. webböngésző) biztonsági rést kihasználó kártevők működhetnek, de webböngészni úgysincs sok értelme LUK alatt futtatott windowsos böngészővel.

Most ha jól értem, a natív binárisok elindítására gyúrnak. Mi értelme van ennek? Miért kéne futnia natívan Linuxon a Windows-os programoknak?
Inkább fordítanák tudásukat és munkájukat a Mono -ra vagy a Wine -ra, ha már cross megoldásokban gondolkodnak.

--
Keep it simple, stupid.

Az ötletet nem tartom hülyének, hogy a kernel szintű dolgokat a Linux is kernel alól intézze, a gondot inkább ott látom, hogy a Windowsban a grafikus rendszer és a kernel úgy össze van kutyulva, hogy a Hamupipőke sem tudná szétválogatni de még a galambokkal sem a függvényturmixot...

ami nekem nagyon tetszett, az a drivertámogatás. Bár azt mondják Redmondban, hogy a sok 3rd party taknyolt driver miatt hasalgat el a Windows, de legalább van driver – talán ezzel a megoldással néhány speckó eszköz is működik majd Linuxon komolyabb reverse engineering nélkül. Kb. mint egy általános ndiswrapper. Jól teszik, hogy lerakják kernelszintre a dolgot.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

igazabol a signed driver megoldasnak nem az a lenyege h a gyartot szopassak hanem h seperc alatt blacklistelheto az MS altal. egy-egy broken driver ami miatt nem fog tobbet elhalalozni a gep es lehet jelezni a gyarto fele h javitsak meg a szorgos kis indiai/kinai koderek amit elbasztak, ezzel sajat magat vedi az MS gyarkolatilag

volt linkelve a video ahol a sysinternalsos csavo beszel errol

http://www.microsoft.com/uk/technet/spotlight/sessionh.aspx?videoid=993
--
.

Azt nem értem, hogy ez az alkalmazások terén mitől lenne sokkal jobb a Wine-nál. A Wine se virtuális gép, elvileg natív sebességgel futnak a programok, lassulást csak az overhead, és esetleg lassabb implementáció okoz. A probléma az, hogy nem tudták 100 %-osan implementálni a Win API-t, de ez a LUK-nál se lesz könnyebb.

NetBSD-s RUMP jelleggel egesz jo elkepzeles lenne, bar az elleknezne Linus nezeteivel...
___
info

Nem eléggé taknyolt már enélkül is mostanság a Linux kernel? :I

--
"How do you work in a team situation when all the other team members are fools and idiots?"

nem hinnem, hogy az MS takony ... kezdenek rajonni par dologra , es olyan dolgokat is tartalmaznak a rendszereik, amiket a linux a mainlineba soha nem is fog tartalmazni.... (igen, security teren ..., par PaX-os megoldas)
ha megnezed a windows 7-et egesz hasznalhato rszr-t dobtak ossze, es jopar dzsubundszu fenyevekre van tole, bar igaz, ez a desktop resze

serveren meg mindig a unix(-like) rszr-ek a jobbak
___
info

Egyébként én látok ebben fantáziát. Most tessék elgondolni a nagyvállalatok helyzetét. X millió dolláros személyre szabott alkalmazások miatt használnak Windowst.

Mennyivel jobb lenne a helyzet, ha azt mondhatnák, hogy tessék, válasszunk a Red Hat, a Novell, a Canonical, x y z között. Kapunk oprendszer, ami alkalmas a vállalati alkalmazásainkhoz, hosszú távú supporttal. Ha esetleg nem elégszünk meg, válaszunk egy másik céget. Ugyanakkor, a saját alkalmazásaink fejlesztését nem fenyegeti semmi. Elég szép verseny indulhatna be. Ez a stuff leginkább egy (vállalati) Linux "beépített" Wine és ReactOS ficsörökkel.

********************
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

volt már hasonló, a Win4Lin. névlegesen még most is létezik, de ma már egy kereskedelmi qemu változat. korábban egy kernel szintű virtualizátor volt, kissé több is annál. monulként futott, és win9x rendszer használatát tette lehetővé gnu/linuxon. így minden nem 3D alkalmazás vígan elfutott gnu/linuxon is. mégsem lett átütő siker. azóta eltelt 10 év, ez természetesen rengeteget jelent.
a windows vga driver LUK mellett használata a legérdekesebb, és az hogyan illeszkedne ez a linuxon szokásos Xorg környezetbe.

És azokat a biztonsági hibákat is hozzák, ami miatt sokan tartózkodnak a Windowstól? Nekem nagyon hiányoznának a natívan futtatható kártevők.
Vagy félre értettem valamit?

Nem lepődnék meg rajta, ha ezt a projektet a Microsoft szponzorálná...

Miért? Alternatív rendszerekről nemigen váltanak Windowsra, neki meg nem érdeke, hogy Windowsról váltsanak.
Egyelőre nem akkora piac a linuxfelhasználók, hogy érdemes legyen rajtuk futtathatóvá tenni a Windowsos desktop alkalmazásokat.

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

Ahelyett, hogy ebbe egy csomó energiát beletesznek, inkább a wine-ba segítenének be. Ha jól értem, az egyetlen lehetséges előnye az, hogy windowsra írt drivereket is lehet futtatni vele talán, ami nem kis dolog, de jó, ha 10 év múlva működőképes lesz.
Szerintem a mono is egy zsákutca. Ahelyett, hogy szenvednek a teljes framework implementálásával, és ha valami nehezebb jön (WPF), akkor felhúzzák az orrukat, hogy az túl van komplikálva ("over-engineered"), ezért nem implementálják, inkább odaállhattak volna a wine mellé, és elérhették volna, hogy menjen rajta a CLR - máris meglett volna a teljes .NET.

Nem tudom, ezen az úton nem indulnék el. Ha már Linuxra, vagy bármely más NEM Windows platformra próbálnék átszoktatni valakit, inkább olyan szoftverek használatára tanítanám, amely előfordul minden platformon. Ne próbáljunk Windowst csinálni a Linuxból (se), ebből jó vége nem lesz, nem lehet. Win32 API-t portolni nem kispálya és nem kecsegtet teljes sikerrel. Ráadásul ugyanabba a zsákutcába vezet, amelyet a Microsoft sem tud megoldani Vistán a visszafele kompatibilitással. Már ott is belátták: inkább kerüljön egy régebbi Windows virtuális homokozó dobozba, ott jó helyen lesz és nem terheli az anyarendszert a hülye DLL-jeivel és régi elvárásaival.

Inkább egy jól telepített és konfigurált Linux + VirtualBoxban egy XP. Ez lehet a jó recept Windowsos felhasználók átneveléséhez.

--
Kinek nem inge, ne vegye gatyára

Lehet, hogy rossz szemszögből nézem, de ahelyett, hogy arra igyekszenek, hogy a Linux kompatibilis legyen a Windows-al, inkább arra kéne törekedni, hogy a Windows kompatibilis legyen a Linux-al...

Mondjuk egy - nem vagyok programozó, nem tudom, hogy lehetséges-e - egységesített driver fejlesztői környezet (Mondjuk OpenDriver>OpenDR>ODR, ahogy tetszik), ami segítségével ugyan azon driver futhatna az összes "ODR" verziószámot futtatni képes op.rendszerenmáris sokat dobhatna a Linux támogatottságán. (Az EU jó eséllyel benne lenne, hogy ennek támogatására rákényszerítse a MS-t, az USA-ban pedig a Google-nek van olyan befolyása jelenleg, hogy ott is támogassák az ötletet).
Aztán lehetne egy közös programozási környezet is, ami segítségével különböző op.rendszereken elfuthatna ugyan az az alkalmazás... stb.

Megmaradhatna az összes rendszer eddigi külön felépítése is, de a legtöbb fejlesztő valószínűleg az arany középutat választaná. Bár ez ugyan úgy nem volna jó a Linux-nak, de így már legalább hivatalos támogatást kaphatna és többen felfigyelnének. És végre a PC tényleg egy egységes platformmá válhatna, hogy felvehessen a harcot a MAC és konzol hadjárat ellen.

Bár valószínű, hogy ezzel a gondolatmenetemmel nem mondtam senkinek sem újat, van itt elég szaki. :) Egyszerűen csak leírtam a véleményem,ami a jelenlegi látóterem alapján még nincs kirajzolódóban,pedig nem ártana... Esetleg már van/volt ilyen kezdeményezés? Azt tudom, hogy a java az elvileg platform független, de tudtommal, az másra való,mivel lassúcska.

Összegezve: Ha képesek kernel szintre levinni a Windows-os alkalmazásokat, akkor már biztos, hogy több éves lemaradásba fog kerülni a Linux a Windows-al szemben és apuska szerintem visszafelé fog elsülni. Ha viszont épülne egy arany középút,abban az esetben a Windows lenne hosszú távon halálra ítélve. (Ezért is gondolom, hogy ebből a szempontból az EU és az USA beleszólása kellene, hogy rákényszerítse a MS-ot a támogatására.

Ennek az egésznek úgy ahogy van, keresztbetesz a Linux fejlesztők híres mondása, miszerint minden stabil API hülyeség.
Amiről írtál, pedig gyakorlatilag egy stabil API/ABI kialakítása ("programozási környezet" ahogy te mondod), majd Windowsra portolása lenne. Felejtsd el. A Linux soha nem fogja elérni ezt a szintet, ugyanis nem akarja elérni.
Innentől nincs miről beszélni... (amúgy a fenti, "ugye csak vicc volt" írásom is erről szól, sajnos nem vicc)

> keresztbetesz a Linux fejlesztők híres mondása, miszerint minden stabil API hülyeség.

Idézni csak pontosan, szépen, ...

http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt

"Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. That interface is the one that users and application programmers can count on being stable."

Elnézést, akkor csak a piaci részesedés-kritikus API-k stabilitásáról van szó.

Amúgy, a fenti post is erről szólt:

egységesített driver fejlesztői környezet (Mondjuk OpenDriver>OpenDR>ODR, ahogy tetszik), ami segítségével ugyan azon driver futhatna az összes "ODR" verziószámot futtatni képes op.rendszeren

Pont ez az, amiért sokan könyörgünk már évek óta. De csakazértse teszik meg.

szerk: amúgy a kernel/userspace API stabilitása nem megváltás, ha az egy szinttel feljebbi libraryk ugyanazt az elbaszott modellt követik, mint az in-kernel. De ezt már kitárgyaltuk egyszer.

Miért? Többen tettek már bizonyságot arról, hogy távol járnak a szoftverfejlesztői pályától? :)

Amúgy nem értem, hogy miért érdeke a Linux fejlesztőknek, hogy ne legyen stabil API. Mire volt a népszerűsítő reklámkampány például, ha végül is eszük ágában sincs akarni, hogy terjedjen a Linux? Ha meg a kapacitás hiányzik, akkor az IBM, az Intel, a Nokia és a többi nagy miért ne tudna besegíteni?

> miért érdeke a Linux fejlesztőknek, hogy ne legyen stabil API.

A kernelfejlesztőknek egyaránt érdeke a "stabil API", és a "nem stabil API". Egyes esetben az egyik érdek kerekedik felül, más esetekben meg a másik.

> ha végül is eszük ágában sincs akarni, hogy terjedjen a Linux?

A kernelfejlesztői szereppel kapcsolatban nem vetődik fel, hogy akarja-e egy kernelfejlesztő hogy terjedjen a Linux vagy sem. Nem befolyásol semmit ha az egyik fejlesztő akarja, egy másik meg nem akarja.

> Amúgy nem értem, hogy miért érdeke a Linux fejlesztőknek, hogy ne legyen stabil API
A kompatibilitás megőrzése és a regressziók szűrése az egyrészt komoly tervezést igényel az elején, másrészt elég sokszor tömény szopás.
Az, hogy bevállalják a szopást nem játszik, mert a Linux funproject (szopjon a másik fejlesztő).
Persze sok szopást el lehetne kerülni alapos tervezéssel, de az megint nem játszik, mert a kernel fejlesztési modellje sokkal inkább a "cowboy coding" módszerre emlékeztet, mint valami alaposan megtervezett valamire.

Nézz körbe a kernel regresszióknál és hibáknál.
Illetve kereshetsz hosszútávú terveket is a fejlesztés menetét illetően (nem, a "world domination" és a "világ minden hw-ét GKH támogatja személyesen" nem az), de azt nemnagyon fogsz találni. Pedig elvileg kéne, hiszen nem csúnyazártdiktatorikus, akár bele is írhatnál a tervbe... ha lenne.

szerk:
Egy normálisan megtervezett, stabil rendszerben megengedhetetlen hogy "bocs tegnap még ment, ma már nem, de azért így kiadjuk a következő release-t", ezen felül mindenképpen szükséges egy roadmap. Linuxnál csak önfényezés van, és a fejlesztők végtelen lustaságának (tervezés téren) ideologizálása.

Amúgy örülök hogy kibővítetted a troll copypaste táradat velem.

> Nézz körbe a kernel regresszióknál és hibáknál.

Kimaradt, hogy szerinted miféle következtetést kéne levonnom kooperatív vs. diktatórikus fejlesztés témakörében, a körbenézést követően. Ha már "szakmai érv", akkor írd meg nyugodtan.

> "bocs tegnap még ment, ma már nem, de azért így kiadjuk a következő release-t"

Kimaradt hogy ki, mit, milyen célra szánva ad ki. Ha már "szakmai", akkor fogalmazz pontosabban.

> Amúgy örülök hogy kibővítetted a troll copypaste táradat velem.

Gondoltam, a saját szövegedet sikeresebben értelmezed.

Az, hogy ömlik a kezedből a megfellebbezhetetlen (a számodra megfellebbezhetetlennek tartott) igazság, ami elé a legfinomabb megfogalmazásban is kellene egy SZVSZ vagy egy "szerintem". De amit leírsz az semmi... egyetlen mondatoddal nem támasztod alá, hogy MIÉRT. Naná... ha nem írsz semmit, azzal nem lehet vitatkozni.
Ezt okoskodásnak hívják ... a szó rosszabb értelmében.

Esetleg lehet a szakmaiság hiányát emlegetni.

> "bocs tegnap még ment, ma már nem, de azért így kiadjuk a következő release-t"

Kimaradt hogy ki, mit, milyen célra szánva ad ki. Ha már "szakmai", akkor fogalmazz pontosabban.

Ki: Linux fejlesztok
Milyen celra: Altalanos hasznalatra

Olvasni marpedig tudni illik.

Nem azert, de tenyleg volt nehany necces huzasa Linus csapatanak, ezt jobb lenne nem kategorikusan tagadni. A Microsoft legalabb nem veri a mellet a kiadott cucc ismert hibaival. Nem tudom, lehet hogy jobb a boldog tudatlansag.
--


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

Már egy ideje tudtam, hogy létezik a project de azt hittem, hogy totál halott dolog - erre itt van ez a hír! A végén még használható dolog lesz belőle, csak így tovább!

---------------
Értelmezési hiba! Elolvassa újra? I/N

megvan az esti műsor.
@zamboriz eteti @Csigaa-t :)

Mellesleg ez sztem baromság...
Több kára van, mint haszna.

A Wine qrva jó (már úgy értem, hogy amikor működik, de folyamatosan, szigorúan monoton jobb lesz). Most csináltak valamit, ami a wine egy apró hiányosságát pótolja. De a screenshot-okon in a wine miatt megy a photoshop.
A wine nem lassú, NEM emulátor.
Ezek kezdik a hiányzó résszel, majd később újraimplementálják a wine-t. Jobb esetben... rosszabb esetben beemelik a gpl-es kódot a gpl-es kódjaik közé. Legrosszabb esetben ezt azért nem teszik meg, mert fizetőssé akarják tenni később.

A wine, mint userspace program eleg kevesse ferhet hozza olyan infokhoz/dolgokhoz, amik kernel level access-t igenyelnek. Erre jott letre ez a project. Abban igazad van, hogy beleolvadhatnanak a wine-ba, biztos ki tudnanak talalni valami nagyon okosat.
--


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

Kernel modul? Tainted? A kernel modul lehet fizetős, nem?

"A wine, mint userspace program eleg kevesse ferhet hozza olyan infokhoz/dolgokhoz, amik kernel level access-t igenyelnek. Erre jott letre ez a project. Abban igazad van, hogy beleolvadhatnanak a wine-ba, biztos ki tudnanak talalni valami nagyon okosat."

Pont ezt mondom: a wine-hez kellene ezt fejleszteni, nem a wine-al konkurrens módon. Nem a versenyt sajnálom, hanem a szétforgácsolódást. Főleg, mikor a wine már ilyen jól halad. Tulajdonképpen inkább az a problémám, hogy ahelyett, hogy a wine kiegészítéseképpen lenne egy (nagyon) jól működő wine, a wine ebben nem fog fejlődni, de létrejön egy újabb kísérlet, ami évek múlva a wine klónozásának nehézségei között kimúlik használhatatlanul. Ha meg nem múlik ki, akkor a wine gpl-es részeinek "ellopásával" a wine hátán annak segítése nélkül kapaszkodik fel. És nekem ez valahogy sugallja (hogy újraírnák a wine részt), hogy fizetőssé akarják tenni.

"A wine, mint userspace program eleg kevesse ferhet hozza olyan infokhoz/dolgokhoz, amik kernel level access-t igenyelnek."

Ezt érti vagy érteni véli az ember, de (irónia nélkül mondom, érdekel:) írhatnál valamiket, hogy mihez van szükség kernel level access-hez? Nem lehet megcsinálni user space-ben egy kis kernel modul támogatással?
Tudom, hogy egy kicsit lassabb lenne, de ez ilyen processzor sebességeknél nem túl nagy overhead. ?? Vélemény???

Peldaul a driverek nativ supportja igen kevesse elkepzelheto jelentos kerneloldali support hijjan (most felejtsuk el a glue kernelmodulokat). Ezen felul jopar WinAPI olyan rendszerhivasokat is elvar, melyekhez meg csak hasonlo sem igen van mostansag.
--


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

Van egy kalap amit igen, de van jonehany, amit nem, mert nagyon rendszerkozeli hivasok.
Foleg ilyen peldaul a soros port kezelesre vonatkozo osszes, a hardvereket celzo kulonbozo megoldasok... szoval van.
--


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