Vzroki v kernelu Linuxa da na njem ne delajo Win aplikacije

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.

OJ če koga zanima alternativa za windows si poglejte tole stran
http://www.reactos.org/ stran je v angleščini

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...

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.

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.

.... 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.

Č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.

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.

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.

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.

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.

@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.

@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.

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.