Forum » Programiranje » Vzroki v kernelu Linuxa da na njem ne delajo Win aplikacije
Vzroki v kernelu Linuxa da na njem ne delajo Win aplikacije
BlueRunner ::
Drugače pa OS X nima več nič kaj pretirano dosti skupnega z ostalimi UNIX sistemi.
Hmm... kaj pa so značilnosti ostalih UNIX sistemov, da OS X nima več nič kaj pretirano dosti skupnega z njimi? Ker potem, ko odšteješ GUI, ti ostane Darwin, ki mi še vedno izgleda veliko bolj UNIX-like, kot pa kakšen GNU/Linux. V bistvu se mi zdi, da je OS X dejansko iz verzije v verzijo, vsaj do 1.5.x, vedno bolj UNIX.
jype ::
Mavrik> Drugače pa OS X nima več nič kaj pretirano dosti skupnega z ostalimi UNIX sistemi.
OS X _je_ Unix. No, Darwin je Unix, OS X je pa samo Darwin + šminka.
Glede na to da je Wine zelo prenosljiva reč ni nič čudnega, da je bil portan tudi na OS X.
OS X _je_ Unix. No, Darwin je Unix, OS X je pa samo Darwin + šminka.
Glede na to da je Wine zelo prenosljiva reč ni nič čudnega, da je bil portan tudi na OS X.
fmcgorenc ::
OJ če koga zanima alternativa za windows si poglejte tole stran
http://www.reactos.org/ stran je v angleščini
http://www.reactos.org/ stran je v angleščini
Brane2 ::
Stara stvar. Ti projekti med seboj sodelujejo, si posojajo in kombinirajo rešitve.
Wineovi razvijalci se tako pogosto sklicujejo na ReactOS, LUK pa na Wine in Reactos...
Wineovi razvijalci se tako pogosto sklicujejo na ReactOS, LUK pa na Wine in Reactos...
On the journey of life, I chose the psycho path.
yeti ::
Tale reactos ze dolgo opazujem. Open source binary compatible windows "like" os bi lahko prav prijazno pokopal linux na workstation nivoju, vsak ki je malo resen pa za server uporablja *bsd. Ker ni bloated. Nekdo je nekaj govoril o monolitnem kernelu NTjev... naj si gre kaj prebrat o kernelu NTjev, ves userspace se da spluvat, okrog kernela pa priporočam tišino :D Linus Torvalds (linux) vs. Dave Cutler (VMS, NT)... ne me smejat...
Zgodovina sprememb…
- spremenil: yeti ()
Brane2 ::
In kaj je tako zelo dobrega na NT kernelu ?
Ne poznam zadeve, le sprašujem...
Ne poznam zadeve, le sprašujem...
On the journey of life, I chose the psycho path.
BigWhale ::
vsak ki je malo resen pa za server uporablja *bsd. Ker ni bloated.
Nehej trapat no, tako linux kot BSD sa lahko bloated.
Nekdo je nekaj govoril o monolitnem kernelu NTjev... naj si gre kaj prebrat o kernelu NTjev, ves userspace se da spluvat, okrog kernela pa priporočam tišino :D
Sem preprican, da nam bos razlozil zakaj je NT kernel tako superioren.
fiction ::
Eh ja... obujanje starih tem je ocitno IN. ReactOS bo mogoce res kmalu zanimiv.
In kaj je tako zelo dobrega na NT kernelu ?Pomoje je kul to, da gre za microkernel. Ni vec samo kernel in user-space, ampak je tudi jedro "razdeljeno" na vec delov, ki si med seboj izmenjujejo sporocila (privilege separation, modularnost itd). Arhitekturno gledano je tako bolj "lepo", ceprav je v koncni fazi vse skupaj se vedno precej bloated (stvar je mogoce ravno zato se bolj kompleksna kot bi lahko bila). Sicer pa tudi npr. Darwin nima monolitnega jedra.
Brane2 ::
Sicer pa tudi npr. Darwin nima monolitnega jedra.
Sicer pa je baje Darwin performančno gledano crap.
Nanj je računal GNU, ki mu je bil Linux samo "temporary fix", dokler GNU ne zaživi, kar traja že večnost.
On the journey of life, I chose the psycho path.
Zgodovina sprememb…
- spremenil: Brane2 ()
yeti ::
In kaj je tako zelo dobrega na NT kernelu ?
Ne poznam zadeve, le sprašujem...
Architecture of Windows NT @ Wikipedia
napsy ::
.... naj si gre kaj prebrat o kernelu NTjev, ves userspace se da spluvat, okrog kernela pa priporočam tišino :D ...
Poganjenje GUI znotraj kernelspace se mi ne zdi preveč superiorno. Prej bi rekel arhitekturna napaka.
"If you die, you die. But when you live you live. There is no time to waste."
BigWhale ::
In kaj je tako zelo dobrega na NT kernelu ?
Ne poznam zadeve, le sprašujem...
Architecture of Windows NT @ Wikipedia
Ja, sam linux je boljsi:
Linux kernel @ Wikipedia
BlueRunner ::
Če pomislim, da je danes osnovna naloga jedra zagotavljanje ABI-ja za gonilnike, abstrakcija strojne opreme, upravljanje VM-FS sistema, nadzor nad večopravilnostjo in zagotavljanje varnostnih pregrad med procesi, potem ne vidim v čemu se skriva superiornost Linux-a pred NT jedrom.
Lahko pa pokažem s prstom na eno pomakljivost: varnostne pregrade oziroma ACL-ji so v NT jedru že od 1993 naprej razdelani na takšnem nivoju, kot ga je Linux dosegel šele z AppArmor in SELinux dodatki. 5 let kasneje, če pogledamo na AppArmor. Ubuntu, kot ena izmed najbolj popularnih distribucij, pa je takšne kontrole integriral šele 2007, pred tema pa je bil iz tega vidika v pravi kameni dobi. Tako je sedaj Linux sicer že tam, kjer mora biti, izkoriščanje teh možnosti ozirma njihovo mandatory vsiljevanje pa je razen pri RH/Fedora sistemih in njegovih izpeljankah, še bolj znanstvena fantastika. Torej več kot 10 let kasneje, pa stvari še vedno niso tam kjer bi morale biti.
Sedaj pa bi samo še to pomagalo, da bi MS bolj striktno izvajal QA procese nad svojo kodo, glede na to, da je pač ne more odpreti.
Lahko pa pokažem s prstom na eno pomakljivost: varnostne pregrade oziroma ACL-ji so v NT jedru že od 1993 naprej razdelani na takšnem nivoju, kot ga je Linux dosegel šele z AppArmor in SELinux dodatki. 5 let kasneje, če pogledamo na AppArmor. Ubuntu, kot ena izmed najbolj popularnih distribucij, pa je takšne kontrole integriral šele 2007, pred tema pa je bil iz tega vidika v pravi kameni dobi. Tako je sedaj Linux sicer že tam, kjer mora biti, izkoriščanje teh možnosti ozirma njihovo mandatory vsiljevanje pa je razen pri RH/Fedora sistemih in njegovih izpeljankah, še bolj znanstvena fantastika. Torej več kot 10 let kasneje, pa stvari še vedno niso tam kjer bi morale biti.
Sedaj pa bi samo še to pomagalo, da bi MS bolj striktno izvajal QA procese nad svojo kodo, glede na to, da je pač ne more odpreti.
Brane2 ::
Ampak to ni problem kernela samega, temveč userlanda.
Kar pa se poganjanja programja v kernel spaceu tiče, kot vem je tudi to možno.
Linux kernel blesti kar se odprtosti tiče in podpore industrijskim zahtevam.
Tako je dobil recimo grupe in kontejnerje, ki ti dovoljujejo poganjanje grup procesov ločeno od preostalega programja in tako dosego neke sorte virtualizacije.
In ne vem kako lahko enačiš ACL z s SELinuxom. SELinux je mnogo več od ACL.
Sploh pa je SELinux lep primer razvoja. Začetna izvedba se je na praktičnem preizkusu v industriji slabo obnesla, tako so bile vnešene spremembe in dodatki in stvar bo še nekaj evoluirala ali se bo na njenih izkušnjah pojavil naslednik.
Kar pa se poganjanja programja v kernel spaceu tiče, kot vem je tudi to možno.
Linux kernel blesti kar se odprtosti tiče in podpore industrijskim zahtevam.
Tako je dobil recimo grupe in kontejnerje, ki ti dovoljujejo poganjanje grup procesov ločeno od preostalega programja in tako dosego neke sorte virtualizacije.
In ne vem kako lahko enačiš ACL z s SELinuxom. SELinux je mnogo več od ACL.
Sploh pa je SELinux lep primer razvoja. Začetna izvedba se je na praktičnem preizkusu v industriji slabo obnesla, tako so bile vnešene spremembe in dodatki in stvar bo še nekaj evoluirala ali se bo na njenih izkušnjah pojavil naslednik.
On the journey of life, I chose the psycho path.
BlueRunner ::
Kaj je problem userlanda?
Pa tudi SELinux ne enačim z varnostjo v NT jedru. Samo povedati sem želel, da je Linux do pred nekaj let živel v kameni dobi varnostnih mehanizmov. To, da je napredoval in, da še bo napredoval pa se mi tudi zdi samoumevno.
Vendar pa ne razumem zakaj bi bilo eno jedro boljše ali slabše od drugega jedra. Nekatere probleme rešujeta na različne načine, vendar pa spadata v "isto štalo". Že zaradi tega je nemogoče najti zmagovalca ali poraženca.
Pa tudi SELinux ne enačim z varnostjo v NT jedru. Samo povedati sem želel, da je Linux do pred nekaj let živel v kameni dobi varnostnih mehanizmov. To, da je napredoval in, da še bo napredoval pa se mi tudi zdi samoumevno.
Vendar pa ne razumem zakaj bi bilo eno jedro boljše ali slabše od drugega jedra. Nekatere probleme rešujeta na različne načine, vendar pa spadata v "isto štalo". Že zaradi tega je nemogoče najti zmagovalca ali poraženca.
Brane2 ::
Kaj je problem userlanda?
Razvoj SELinuxa. Kernel ga je imel zelo hitro.
Sploh pa ACL je na Linux kernelu tudi že celo večnost. Ne samo to, ampak so uporabniku na voljo tudi razširjeni atributi ( user_xattr)...
Vendar pa ne razumem zakaj bi bilo eno jedro boljše ali slabše od drugega jedra. Nekatere probleme rešujeta na različne načine, vendar pa spadata v "isto štalo". Že zaradi tega je nemogoče najti zmagovalca ali poraženca.
Torej ni osnove za povzdigovanje NT kernela v nebo, sploh na osnovi nekih blok diagramov...
On the journey of life, I chose the psycho path.
BlueRunner ::
SElinux je v jedru. Userland ima podporna orodja. Kar je tudi samoumevno.
Privzet ACL v linux jedru pa je, kako bi rekel, kamenodoben. Ta ACL preprosto ne igra v isti ligi, v kateri igrata npr. Solaris in NT ali pa VMS, če smo že pri daljni prazgodovini. Kako zastarel je, pa pokaže že to, da potrebuješ "sudo". Seveda je lepo, če rešuješ problem v userlandu z nadzorom lansiranja procesov, vendar pa ko enkrat povzdigneš proces na euid 0, so brez AppArmor ali SElinux kontekstov vse stave odpovedane.
Ne vem pa kdo je povzdigoval NT jedro v nebo. Tisto "tišino" sem sam razumel kot "ne pljuvaj po stvari, ki ni nič slabša od Linuxa".
Samo NT jedro je po zasnovi in funkcionalnosti sodobno, po implementaciji pa se pozna šepanje pri QA. Pri drugih jedrih pa se najdejo pač druge napake. Popolnosti ni, na Mach pa čakamo že dooooolgo časa. Že samo dejstvo, da je od svojega nastanka v 1990 pa do danes doživelo samo eno resnično obsežno arhitekturno spremembo (NT 3.51 na NT 4.0 se je v njega preselil GDI) je pa tudi kompliment prvotnim načrtovalcem, ki so zelo dobro vedeli kaj počno.
Privzet ACL v linux jedru pa je, kako bi rekel, kamenodoben. Ta ACL preprosto ne igra v isti ligi, v kateri igrata npr. Solaris in NT ali pa VMS, če smo že pri daljni prazgodovini. Kako zastarel je, pa pokaže že to, da potrebuješ "sudo". Seveda je lepo, če rešuješ problem v userlandu z nadzorom lansiranja procesov, vendar pa ko enkrat povzdigneš proces na euid 0, so brez AppArmor ali SElinux kontekstov vse stave odpovedane.
Ne vem pa kdo je povzdigoval NT jedro v nebo. Tisto "tišino" sem sam razumel kot "ne pljuvaj po stvari, ki ni nič slabša od Linuxa".
Samo NT jedro je po zasnovi in funkcionalnosti sodobno, po implementaciji pa se pozna šepanje pri QA. Pri drugih jedrih pa se najdejo pač druge napake. Popolnosti ni, na Mach pa čakamo že dooooolgo časa. Že samo dejstvo, da je od svojega nastanka v 1990 pa do danes doživelo samo eno resnično obsežno arhitekturno spremembo (NT 3.51 na NT 4.0 se je v njega preselil GDI) je pa tudi kompliment prvotnim načrtovalcem, ki so zelo dobro vedeli kaj počno.
Brane2 ::
SElinux je v jedru. Userland ima podporna orodja. Kar je tudi samoumevno.
Ampak problemi, ki jih ima uvedba SELinuxa nimajo nič s kernelom. Ta je imel SELinux zelo zgodaj.
Pravzaprav je ena prvih implementacij bila za Linux.
Privzet ACL v linux jedru pa je, kako bi rekel, kamenodoben. Ta ACL preprosto ne igra v isti ligi, v kateri igrata npr. Solaris in NT ali pa VMS, če smo že pri daljni prazgodovini.
Najbrž zato, ker nihče ni rabil ničesar več. Pravzaprav je bil za večino že ACL odveč.
Winsi ga imajo, pa ni videti, da bi bila njihova varnost prav visoka.
Kot vem, je v kernelu posebna infrastruktura, na katero se obešajo tovrstni sistemi in kamor ne bi bilo problema dodati kaj takega, pa se nikomur ne zdi vredno.
Kako zastarel je, pa pokaže že to, da potrebuješ "sudo".
Ah, daj no. Tudi če je to res, ta problem reši manjši patch, ki ga je verjetno že apliciral kdo, ki ga je to zasrbelo.
Meni osebno je ACL brezveze. Lep na papirju, v praksi dvomljivo uporaben.
Samo NT jedro je po zasnovi in funkcionalnosti sodobno, po implementaciji pa se pozna šepanje pri QA. Pri drugih jedrih pa se najdejo pač druge napake. Popolnosti ni, na Mach pa čakamo že dooooolgo časa. Že samo dejstvo, da je od svojega nastanka v 1990 pa do danes doživelo samo eno resnično obsežno arhitekturno spremembo (NT 3.51 na NT 4.0 se je v njega preselil GDI) je pa tudi kompliment prvotnim načrtovalcem, ki so zelo dobro vedeli kaj počno.
Linux kernel je IMHO zakon, če ne zaradi drugih, pa vsaj ene lastnosti: odprte kode.
Z njeno pomočjo se bliskovito spreminja in tudi njegov ABI.
To pa je za stvaritve tipa NT kernel praktično onemogočeno- ko so enkrat zunaj, se ne morejo več spreminjat, saj userland pač nekatere odzive pričakuje.
On the journey of life, I chose the psycho path.
Mavrik ::
Linux kernel je IMHO zakon, če ne zaradi drugih, pa vsaj ene lastnosti: odprte kode.
In kaj točno to ma veze s tem kako dober je dejansko kernel?
Z njeno pomočjo se bliskovito spreminja in tudi njegov ABI.
Spreminjanje ABIja v kernelu je daleč največja neumnost kar jo lahko delaš, ker s tem neprestano sabo vlačiš potem še obvezne spremembe aplikacij, ki visijo na teh ABIjih.
Ni čudno da se za bolj resne primere uporablja recimo Solaris, ki drži kompatibilni ABI precej več časa.
The truth is rarely pure and never simple.
Brane2 ::
1. ABI se spreminja kontrolirano ( dodani syscalli, dodatni elementi v strukturah na koncu )
2. Ko pride do bistvenih sprememb, ki bi ogrožale združljivost, kar je zelo redko, pač scompilaš aplikacije nanovo.
2. Ko pride do bistvenih sprememb, ki bi ogrožale združljivost, kar je zelo redko, pač scompilaš aplikacije nanovo.
On the journey of life, I chose the psycho path.
Brane2 ::
In kaj točno to ma veze s tem kako dober je dejansko kernel?
To olajšuje prilagajanje kernela tekočim potrebam industrije z manj zdruzžljivostnimi problemi s preteklimi verzijami.
On the journey of life, I chose the psycho path.
BlueRunner ::
@Brane2: O ACL-jih raje odnehajva. Mislim, da njihovega obsega in funcionalnosti v NT-jih ne poznaš, zato se bi nadaljna debata verjetno razvila v dolgo in široko razlaganje kaj vse je v katerem sistemu izvedljivo. Če pa misliš, da je za tvoje potrebe ta funkcionalnost nepomembna, pa tudi OK. Je pač ne potrebuješ. Drugi imamo/poznamo tudi druge potrebe. Samo kot primer: GNU/Linux bi bil brez SELinux v finančnem okolju, kjer se pogovarjamo o zahtevni regulativi, omejen na periferne naloge. Tako pa je sposoben prevzeti tudi izvajanje finančnih aplikacij. Brez tega bi bila njegova implementacija na LSE znanstvena fantazija.
Za ABI pa ne moreš kar tako reči, da je njegovo fiksiranje slaba stvar. Če razvijaš gonilnike za svoje naprave ti je lažje podpreti sistem, kjer se ABI spremeni vsakih nekaj let, kot pa sistem, kjer se ABI spremeni skoraj vsakih nekaj mesecev. Vsi pa vsega pač ne bodo dali pod GPL in vrgli v odprto kodo. Samo poglejno nVidio, ki bo verjetno prej morala propasti, preden bo prenehala distribuirati binarne mehurje + izvorno kodo, ki dela adaptacijo na trenuten ABI.
Oh, le zakaj je včasih za kakšen specifičen kos HW-ja tako težko dobiti gonilnik.
Je pa res, da z fiksnim ABI-jem ne moreš delati reorganizacij jedra, kakor ti paše. Zato je Linux na kernel.org razvojno delo v teku, distribucije pa potem pridejo v dveh variantah: cutting-edge, kjer imaš zadnjo verzijo jedra in stabilne, kjer se skrbi za fiksen ABI in prenos aktualnih popravkov nazaj na fiksirano verzijo.
@Mavrik: Za resne stvari pa je GNU/Linux čisto primeren. Za nekatere specifične zahteve, pa je uporaba izvorne kode jedra praktično edina možnost. Komercialne in nekatere nekomercialne distribucije imajo načrt izidov, v vsakem drevesu pa vzdržujejo ABI zato, da nudijo stabilno platformo za ISV-je in OEM-e. Model razvoja jedra še ne pogojuje kaj potem drugi počno/počnemo s to kodo.
Za ABI pa ne moreš kar tako reči, da je njegovo fiksiranje slaba stvar. Če razvijaš gonilnike za svoje naprave ti je lažje podpreti sistem, kjer se ABI spremeni vsakih nekaj let, kot pa sistem, kjer se ABI spremeni skoraj vsakih nekaj mesecev. Vsi pa vsega pač ne bodo dali pod GPL in vrgli v odprto kodo. Samo poglejno nVidio, ki bo verjetno prej morala propasti, preden bo prenehala distribuirati binarne mehurje + izvorno kodo, ki dela adaptacijo na trenuten ABI.
Oh, le zakaj je včasih za kakšen specifičen kos HW-ja tako težko dobiti gonilnik.
Je pa res, da z fiksnim ABI-jem ne moreš delati reorganizacij jedra, kakor ti paše. Zato je Linux na kernel.org razvojno delo v teku, distribucije pa potem pridejo v dveh variantah: cutting-edge, kjer imaš zadnjo verzijo jedra in stabilne, kjer se skrbi za fiksen ABI in prenos aktualnih popravkov nazaj na fiksirano verzijo.
@Mavrik: Za resne stvari pa je GNU/Linux čisto primeren. Za nekatere specifične zahteve, pa je uporaba izvorne kode jedra praktično edina možnost. Komercialne in nekatere nekomercialne distribucije imajo načrt izidov, v vsakem drevesu pa vzdržujejo ABI zato, da nudijo stabilno platformo za ISV-je in OEM-e. Model razvoja jedra še ne pogojuje kaj potem drugi počno/počnemo s to kodo.
Poldi112 ::
Po drugi strani pa, če odpreš svoj driver, lahko kar pozabiš nanj, saj ob vsaki spremembi ABI-ja ki bi vplivala na tvoj driver le tega popravi tisti, ki izvaja spremembo. Za razliko od sistemov s stabilnim, kjer si mrzel, ko ti proizvajalec ne naredi driverja za nov sistem.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
Brane2 ::
@Brane2: O ACL-jih raje odnehajva. Mislim, da njihovega obsega in funcionalnosti v NT-jih ne poznaš, zato se bi nadaljna debata verjetno razvila v dolgo in široko razlaganje kaj vse je v katerem sistemu izvedljivo.
Saj jih ne rabim poznati v detajle, da vidim, da so največji večini folka nepotrebni.
Na ssitemu, kjer ti folk lahko postane root skozi luknjo in kjer se večina exploitov vrti okrog tega, je ACL težko kaj več ko šminka. Kaj ti pomagajo še tako zategnjena pravila, če so v primeru tovrstnega breacha brezpredmetna ?
Poleg tega pa, kot sem rekel, imaš v kernelu posebno infrastrukturo v ta namen. Če ti stvari niso všeč, pač obesi tja svoj turbo_acl.
Če pa misliš, da je za tvoje potrebe ta funkcionalnost nepomembna, pa tudi OK. Je pač ne potrebuješ. Drugi imamo/poznamo tudi druge potrebe. Samo kot primer: GNU/Linux bi bil brez SELinux v finančnem okolju, kjer se pogovarjamo o zahtevni regulativi, omejen na periferne naloge. Tako pa je sposoben prevzeti tudi izvajanje finančnih aplikacij. Brez tega bi bila njegova implementacija na LSE znanstvena fantazija.
In ?
Za ABI pa ne moreš kar tako reči, da je njegovo fiksiranje slaba stvar.
Kot kaže praksa zadnjih nekaj let, je fiksni ABI veliko več snag kot prednost.
Linus je enkrat napisal nek javni rant "Enough already with stable ABI moaning!" in moram reči, da se s tistim strinjam 100%.
Če razvijaš gonilnike za svoje naprave ti je lažje podpreti sistem, kjer se ABI spremeni vsakih nekaj let, kot pa sistem, kjer se ABI spremeni skoraj vsakih nekaj mesecev.
No, če lahko izbiram, potem najraje vidim, da se nič ne spreminja- nikoli. Da se cel svet ustavi zaradi mojega driverja.
V realu pa ni takih problemov. Vsi driverji mi delajo. Celo nVidia.
Vsi pa vsega pač ne bodo dali pod GPL in vrgli v odprto kodo. Samo poglejno nVidio, ki bo verjetno prej morala propasti, preden bo prenehala distribuirati binarne mehurje + izvorno kodo, ki dela adaptacijo na trenuten ABI.
So what ? Ne spomnim se, kdaj mi zaradi tega driver ni delal. Čakaj malo, zdaj sem se spomnil. par tednov nazaj sem vzel GTS250 in je driver ni spoznal. Vzelo mi je celo uro, da sem našel neuradni driver, ki je odpravil ta problem- ki je nastal zaradi sveže kartice in ne ABIja...
Oh, le zakaj je včasih za kakšen specifičen kos HW-ja tako težko dobiti gonilnik.
Zato ker ima zaprto kodo. Tako so z mojega multiboot stroja naposled morali odleteti Winsi 2K - ni driverjev za nov HW.
Zanimivo,d a mi vsa odprta koda pa dela naprej...
Je pa res, da z fiksnim ABI-jem ne moreš delati reorganizacij jedra, kakor ti paše. Zato je Linux na kernel.org razvojno delo v teku, distribucije pa potem pridejo v dveh variantah: cutting-edge, kjer imaš zadnjo verzijo jedra in stabilne, kjer se skrbi za fiksen ABI in prenos aktualnih popravkov nazaj na fiksirano verzijo.
Ne dramatiziraj. Jaz imam vedno zadnji gentoo-sources, headerje pa bistveno starejše.
Tako sedaj laufam 2.6.30-r4, vendar so linux-headerji 2.6.27-r2.
Ves SW se scompila torej s headerji za bistveno starejši kernel in dela b.p.
On the journey of life, I chose the psycho path.
Brane2 ::
Aja, še nekaj okrog nVidijinih zaprtih driverjev.
Poglej si malo na AMDjev site, koliko materialov za njihove Radeone je prišlo ven.
Nikoli ne reci nikoli.
Poglej si malo na AMDjev site, koliko materialov za njihove Radeone je prišlo ven.
Nikoli ne reci nikoli.
On the journey of life, I chose the psycho path.
BlueRunner ::
No, to je pač tvoje mnenje o temu kaj ti potrebuješ. Tvoje mnenje NT jedro ne naredi ne boljše ne slabše od ostalih sodobnikov.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Apple se poslavlja od 32 bitov (strani: 1 2 3 )Oddelek: Novice / Apple iPhone/iPad/iPod | 26968 (21952) | AndrejO |
» | Linux vstopa na področje CAD aplikacij (strani: 1 2 3 )Oddelek: Novice / Ostala programska oprema | 36270 (32621) | Brane2 |
» | win32 api vs "linux api"Oddelek: Programiranje | 3777 (3050) | denial |
» | Linus Torvalds: Linux je glomazen (strani: 1 2 )Oddelek: Novice / Ostala programska oprema | 10230 (6315) | yeti |
» | Za razvoj Minixa poltretji milijon evrovOddelek: Novice / Operacijski sistemi | 4499 (2560) | Jst |