Wine on hidas paska.
Cedega on buginen hidas paska.
Ja ne muutamat Windowsista portatut pelit pyörii hitaammin Linuxilla kuin alkuperäiset Windowsilla. Koodarit kenties laiskoja?
Linuxilla ei ole stabiilia binääristä rajapintaa, että suuremman skaalan kaupallista ohjelmakehitystä, kuten pelejä, tulisi koskaan olemaan. Mm. World of Warcraftin Linux-client vedettiin markkinoilta juuri tämän userlandin heterogeenisyyden takia.
LSB ei meinaa onnistua tavoitteissaan, vieläkään OpenSource komponentteja ei meinaa saada sovitettua LSB:n kriteereihin. Koittakaapas itse buildaa LSB-wräppereillä jotain hitusenkaan monimutkaisempaa.
Linuxilla ei ole stabiilia binääristä rajapintaa kernelissä. Kaupalliset laitteistovalmistajat ei voi binäärisinä mokkuloina ajureitaan jaella, joten laitteistotuki tulee lähinnä muutamalta isolta pelurilta (nVidia) joilla on varaa käyttää vitusti aikaa monimutkaisen puolibinäärisen rajapintawräpperin koodaamiseen tai harrastelijoilta jotka reverse-engineeraa laitteiden ohjelmointirajapintoja.
Jumalauta, kuluttajien tulisi vaatia GPL-liimatukilta edes pikkuisen yhteistyötä ja insinööriasennetta, että saataisin toimiva, stabiili ja standardoitu rajapinta kaupallisille ohjelmille ja ajureille. Ei muuten tule kevättä Linux markkinoilla.
PS: FreeBSD:ssä on ollut versioidut binääriset rajapinnat kernelissä ja userlandissa jo aikojen alusta.
Cedega on buginen hidas paska.
Ja ne muutamat Windowsista portatut pelit pyörii hitaammin Linuxilla kuin alkuperäiset Windowsilla. Koodarit kenties laiskoja?
Linuxilla ei ole stabiilia binääristä rajapintaa, että suuremman skaalan kaupallista ohjelmakehitystä, kuten pelejä, tulisi koskaan olemaan. Mm. World of Warcraftin Linux-client vedettiin markkinoilta juuri tämän userlandin heterogeenisyyden takia.
LSB ei meinaa onnistua tavoitteissaan, vieläkään OpenSource komponentteja ei meinaa saada sovitettua LSB:n kriteereihin. Koittakaapas itse buildaa LSB-wräppereillä jotain hitusenkaan monimutkaisempaa.
Linuxilla ei ole stabiilia binääristä rajapintaa kernelissä. Kaupalliset laitteistovalmistajat ei voi binäärisinä mokkuloina ajureitaan jaella, joten laitteistotuki tulee lähinnä muutamalta isolta pelurilta (nVidia) joilla on varaa käyttää vitusti aikaa monimutkaisen puolibinäärisen rajapintawräpperin koodaamiseen tai harrastelijoilta jotka reverse-engineeraa laitteiden ohjelmointirajapintoja.
Jumalauta, kuluttajien tulisi vaatia GPL-liimatukilta edes pikkuisen yhteistyötä ja insinööriasennetta, että saataisin toimiva, stabiili ja standardoitu rajapinta kaupallisille ohjelmille ja ajureille. Ei muuten tule kevättä Linux markkinoilla.
PS: FreeBSD:ssä on ollut versioidut binääriset rajapinnat kernelissä ja userlandissa jo aikojen alusta.
Vastaukset 16
Vanhimmat
ksym_ on taas herännyt. Ei kiinnosta paskaakaan.
> Linuxilla ei ole stabiilia binääristä rajapintaa,
> että suuremman skaalan kaupallista
> ohjelmakehitystä, kuten pelejä, tulisi koskaan
> olemaan
Niin tässä siis varmaankin tarkoitat, ettei sovelluskomponenttien ajonaikainen rajapinta ole välttämättä sama jakelusta toiseen? Tuo varmaankin on ongelma, mutta esim. libc on varmaankin aika taaksepäin yhteensopiva.
Samaan tapaan käyttäjäprosessien rajapinta kerneliin on linukassa varmaankin aika stabiili ja luultavammin "binääriyhteensopiva". Ainoa muutos tuohon on P4:n/AMD:n sysenter/syscall -käskyt, jotka on hoidettu glibc:n ja kernelin yhteistyöllä jotenkin yhteensopivaksi.
> Linuxilla ei ole stabiilia binääristä rajapintaa
> kernelissä.
Tällä varmasti tarkoitat, ettei esim. ajurikerneli rajapinta ole pysynyt samana aikojen allusta asti? Nythän tuo on ratkaistu mm. käyttämällä C99:n "designated initializers" -ominaisuutta (eli uusien ajuri-koukkujen lisääminen ei vaikuta olemassaoleviin).
Sitäpaitsi muistelisin, että on linuksin moduuleissa myös olemassa versionti, joten em. väitteesi ei (taaskaan) ole validi.
>> Tuo varmaankin on ongelma, mutta esim. libc on
>> varmaankin aika taaksepäin yhteensopiva.
http://plan99.net/autopackage/Linux_Problems#glibc
Vitut. Taaksepäin yhteensopivuus ei merkkaa yhtään mitään, kun tuossa GLIBC:ssä ei ole järkeviä keinija määrätä sitä ABI-versiota mille haluaa minkäkin ohjelman kääntää.
Windowsin DCOM:issa tämän pystyi moduulikohtaisesti säätämään. Ja hyvä niin.
>> Tällä varmasti tarkoitat, ettei esim.
>> ajurikerneli rajapinta ole pysynyt samana
>> aikojen allusta asti?
TARKENNAN: Tarkoitin, että binäärinen rajapinta kernel moduleille ei KOSKAAN pysy samana. Ei ole koskaan pysynyt, eikä tule pysymään. Linus Torvalds on itse syypää tähän, kun hän vastustaa henkeen ja vereen suljetun lähdekoodin ajureita.
Kernelin version muutos vanhemmasta uudempaan kusee binäärimodulit, vaikka muutos olisi vain minor-versiossa. Saman kernelin versionkin uudelleenkääntäminen eri asetuksilla rikkoo myös rajapinnan! Jo on perkele?
Linuxin versiolle X käännetty binäärinen moduuli ei käy enää versioon X 1. Tai vaikka versioon X jos se on käännetty eri parametreilla.
>> Nythän tuo on ratkaistu mm. käyttämällä C99:n
>> "designated initializers" -ominaisuutta (eli
>> uusien ajuri-koukkujen lisääminen ei vaikuta
>> olemassaoleviin).
Missä helevetin versiossa tuommoinen ominaisuus on tullut mukaan? Urlia kehiin.
Ja enpä ole vieläkään pystynyt ajureita Linuxiin binäärisinä levittämään, vaikka minulla serverissä montakin erilaista Linugsin versiota tullut testattua. Melko 2.6 sarjalaisia olen kokeillut.
Jos saat todellakin todistettua että Linuxiin on kehitetty jokin stabiili rajapintaviritys ajureille, niin olenpa hiljaa. Mutta näin en ole vielä tähän asti kokenut.
>> Sitäpaitsi muistelisin, että on linuksin
>> moduuleissa myös olemassa versionti, joten em.
>> väitteesi ei (taaskaan) ole validi.
Ja tuo kernelin versiointi ei vaikuta paskaakaan siihen, että toimiiko binäärimoduuli vai ei.
Se vain tarkistaa
1) kernelin moduuleille exporttaaman symbolilistan, ja vertaa sitä moduulin vaatimiin symboleihin. Jos eivät täsmää, niin moduuli ei toimi
2) kernelin version, jonka headereilla moduuli käännettiin. Jos ei täsmää, niin ei toimi.
Ja tämä abi siis rikkoontuu sekä eteen että taakseppäin, version kannalta.
Että ihan turhaa. Vieläkään mitään hyödyllistä eivät ole saaneet aikaan.
Ja minulla on syy:
Linus Torvalds ITSE on KIELTÄYTYNYT standardoimaan kernelin binääristä rajapintaa ulkoisten ajurien vaatimuksesta! Hänen mielestään yhteensopivuuden tulee olla enintään lähdekooditasolla, että binäärisen yhteensopivuuden tavoittelu ei toisi lisätaakkaa uusien ominaisuuksien kehittämiselle tai vanhojen korjaamiselle.
Mutta mielestäni tällainen paskanjauhanta on vitun naurettavaa hippeilyä. Jos saatana aiotaan vallata maailma jollain järjestelmällä, niin JUMALAUTA siinä on oltava tarkasti speksatut, standardoidut ja vuodesta toiseen (niin lähdekooditasolla kuin binäärisestikkin) yhteensopivina pysyvät rajapinnat.
Olen puhunut.
Koskahan sut sais tajuamaan että Linux ja Unix maailmassa arvostetaan käsitteitä VAKAUS, NOPEUS ja TIETOTURVA.
Nuo sinun perustelusi ovat aivan totta. Siis jos halutaan luoda uusi Microsoft Windows niin juuri noin menetellään.
"Jos saat todellakin todistettua että Linuxiin on kehitetty jokin stabiili rajapintaviritys ajureille, niin olenpa hiljaa."
" Szabolcsin ntfs-3g -ajuri toimii perinteisemmistä Linux-tiedostojärjestelmäajureista poiketen tavallisena ohjelmana Fuse-tiedostojärjestelmäajurirajapinnan avulla. Tällöin sen toiminta ei vaaranna ytimen vakautta ja se voidaan päivittää
ytimestä riippumatta. Myös ajurin kehittäminen helpottuu. "
http://www.digitoday.fi/page.php?page_id=9&news_id=20069469
Fusen mahdollistava kernel-moduli on oma kokonaisuutensa kernelissä. Sitä käyttävät userspacessa ajettavat filesystem daemonit vaatii oman versiotaan vastaavan userland libraryn toimiakseen.
Fusella et kuitenkaan kehitä mitään muita kuin tiedostojärjestelmäajureita. Muut ajurit joutuu sitomaan ytimeen.
Sitäpaitsi Fusella toteutetut tiedostojärjestelmät ovat helvetin paljon hitaampia kuin kernelissä toimivat vastaavat, koska nämä "ajurit" ovat vain omia prosessejaan. Jos tulee fs-pyyntöjä näille, niin joudutaan tekemään kontekstinvaihto kernelin kautta, ja kenties kopioimaan jopa dataa? Linux ei ole mikrokerneli, joten tällainen userspace filesystem rajapinta imee mutaa ja rajusti. Semantiikat ontuvat.
"Tällä varmasti tarkoitat, ettei esim. ajurikerneli rajapinta ole pysynyt samana aikojen allusta asti? Nythän tuo on ratkaistu mm. käyttämällä C99:n "designated initializers" -ominaisuutta (eli uusien ajuri-koukkujen lisääminen ei vaikuta olemassaoleviin)."
Heh heh... tuollaisella uudemman C-kielen ominaisuudella ei "ratkaista" mitään ongelmaa. Saman voi hoitaa muullakin tavalla C-kielessä.
sitähän käytettäisiin nopeuttavaativissa hommissa sitä mikrokerneliä jos se olisi nopea. Mutkun se ei ole.
> Heh heh... tuollaisella uudemman C-kielen ominaisuudella ei
> "ratkaista" mitään ongelmaa. Saman voi hoitaa muullakin tavalla
> C-kielessä.
Joo mutta nimenomaan tuo on yksi ongelma erilaisissa rajapinnoissa. Tottakai asiat voidaan tehdä muutenkin mutta yleensähän esim. ajuri rekisteröi tietyntyyppisen structin kernelille, jonka koukku-"metodeja" sitten käytetään vaikka nyt toteuttamaan read(2) em. laitteelle.
Linuksissahan alunperin nämä rajapinnat saattoivat muuttua, jolloin struktuuri ei enää olekaan välttämättä yhteensopiva. Aluksi käytettiin gcc:n omia extensioita mutta kun tuo tuli C99:n standardiin myöskin niin siirryttiin siihen.
Vertaa:
struct foo {
' void (*f1)(void);
' void (*f2)(void);
' int flags;
};
ajuri1:
static struct foo ajuri1_foo {
' ajuri1_f1, ajuri1_f2, FLAG1 | FLAG2
};
nyt jos struct foo:ta muutetaan hieman (lisätään metodi):
struct foo {
' void (*f1)(void);
' void (*f2)(void);
' void (*f3)(void);
' int flags;
};
niin ajuri1 ei enää käänny. Jos taas käytetään noita em. ominaisuutta niin ainakin tuo ongelma on poissa päiväjärjestyksestä. Tosin ei kukaan normaalisti menisi lisäämään metodia väliin vaan loppuun.
Tällä siis vain lähdekooditasoinen yhteensopivuus.
> Vitut. Taaksepäin yhteensopivuus ei merkkaa yhtään mitään, kun
> tuossa GLIBC:ssä ei ole järkeviä keinija määrätä sitä ABI-versiota
> mille haluaa minkäkin ohjelman kääntää.
Aijaa, mitäköhän sitten "symbol versioning" tarkoittaa?
http://www.gnu.org/software/libc/FAQ.html#s-1.17
Ainakin yrittävät olla yhteensopivia. Sitä en osaa sanoa, kuinka tuo toiminnee käytännössä, jos on käytössä useita versioita glibc:stä.
> TARKENNAN: Tarkoitin, että binäärinen rajapinta kernel
> moduleille ei KOSKAAN pysy samana. Ei ole koskaan pysynyt,
> eikä tule pysymään. Linus Torvalds on itse syypää tähän, kun
> hän vastustaa henkeen ja vereen suljetun lähdekoodin
> ajureita.
Joo tuon pystyy rivien välistä lukemaan. Eli hommahan on niin, ettei Linus & kumppanit epäröi muuttaa rajapintaa, jos siinä on parannettavaa. Tuskin kuitenkaan noita on tahalteen muutettu (ja jos on niin pistä linkki tänne).
> Missä helevetin versiossa tuommoinen ominaisuus on tullut
> mukaan? Urlia kehiin.
Muistelen, että 2.6 -kerneleissä käytetään ajureissa ym. kernelin moduuleissa nimenomaan noita. Tuohan siis helpottaa ainoastaan lähdekooditasolla. Aikaisemmin käytettiin gcc:n extensioita (jos käytettiin).
Urlia en heitä mutta katsopas vaikka esimerkkinä:
drivers/pci/pci-driver.c.
> Ja tuo kernelin versiointi ei vaikuta paskaakaan siihen, että
> toimiiko binäärimoduuli vai ei.
> Se vain tarkistaa
> 1) kernelin moduuleille exporttaaman symbolilistan, ja vertaa
> sitä moduulin vaatimiin symboleihin. Jos eivät täsmää, niin
> moduuli ei toimi
Nyt ihan mielenkiinnosta katselin kuinka tuo on _oikeasti_ tehty
(kernel/module.c) ja jos on pistetty CONFIG_MODVERSIONS-lippu päälle niin silloin katsotaan _moduulin_ struct_module:n versionumeron ja jos ei vastaa olemassaolevaan niin ei toimi. Jos em. lippu ei ole päällä niin moduuli menee oikein kivasti sisään.
> 2) kernelin version, jonka headereilla moduuli käännettiin. Jos
> ei täsmää, niin ei toimi.
Tätä ei ainakaan tehdä kernelissä ja itselläni ei ole modload- (vai mikä se nyt linuksissa onkaan) ohjelman sorsia koneella, joten tuohon ei pysty kommentoimaan. Missä muuten se kernelin versionumero on moduuleissa?
>> Aijaa, mitäköhän sitten "symbol versioning"
>> tarkoittaa?
Sitä, että kun softa käännetään niin sen interfacet deppaa käännönaikaisen GLIBC:n interfaceihin. Ja softa toimii silloin sillä GLIBC:llä tai UUDEMMILLA, mutta tarkka versiokontrolli on vitun purkkavirittelyä:
http://plan99.net/autopackage/Linux_Problems#glibc
"It's possible to override this using injected GAS pseudo-ops and indeed this is what gave birth to the apbuild tool but:
Nobody except us seems to know this technique. The LSB has a solution to do the same thing but it works by constructing fake "stub" libraries from relational databases. It's quite hard to separate from the other LSB policies like "you must statically link anything not in the LSB", making their tool worthless for open source projects who can't ship the entirety of GNOME/Python with their binaries. GAS pseudo-op injection is a lightweight and modular way to solve the same problem."
>> Joo tuon pystyy rivien välistä lukemaan. Eli
>> hommahan on niin, ettei Linus & kumppanit
>> epäröi muuttaa rajapintaa, jos siinä on
>> parannettavaa. Tuskin kuitenkaan noita on
>> tahalteen muutettu (ja jos on niin pistä linkki
>> tänne).
http://www.linuxdevcenter.com/pub/a/linux/2004/09/02/driver_ease.html
Linus Torvalds, the creator of the Linux kernel, has been quite clear on his position of ABI stability on the Linux Kernel Mailing List: "It's not going to happen. I am _totally_ uninterested in a stable ABI for kernel modules, and in fact I'm actively against even _trying_. I want people to be very much aware of the fact that kernel internals do change, and that this will continue." He continues, "I occasionally get a few complaints from vendors over my non-interest in even _trying_ to help binary modules. Tough. It's a two-way street: if you don't help me, I don't help you. Binary-only modules do not help Linux, quite the reverse. As such, we should have no incentives to help make them any more common than they already are."
Eivät poijjaat jaksa kehitellä niitä rajapintoja niin, että ne toimisi pitemmälläkin aikavälillä ilman muutoksia. Tämmöinen vaan ei käy sellaisessa järjestelmässä, mihin haluttaisiin kaupallista suljetun lähdekoodin laitteistotukea. Se on tajuttu Windowsissa ja Mac OS X:ssä ja FreeBSD:ssäkin.
FreeBSD:ssä kernelin sisäset rajapinnat vaihtuu major-version välein, mutta ainakin niiden muutokset dokumentoidaan niin ajurien kehittäjät pysyy mukana.
>> Tuohan siis helpottaa ainoastaan
>> lähdekooditasolla. Aikaisemmin käytettiin gcc:n
>> extensioita (jos käytettiin).
Muahaha, niinpä.
>> Missä muuten se kernelin versionumero on
>> moduuleissa?
http://www.tldp.org/HOWTO/Module-HOWTO/basekerncompat.html#AEN502
"The special .modinfo section of the mydriver.o object file in this example has "1.2.1" in it because it was compiled using header files from Linux 1.2.1. Try to load it into a 1.2.2 kernel and insmod notices the mismatch and fails, telling you you have a kernel version mismatch."
ELF-objektin .modinfo -sektiossa se piilee. Tuo on toiminnassa näissä 2.6 sarjalaisissakin, ja mielestäni aivan liian yksinkertainen menetelmä kaupallisia sovellutuksia ajatellen.
Ja vittu minähän en saatanan hippi-kommarien propagandakoneistolle ideoitani lahjoita. Joskus olen ehdotellut monenmoista modulaarista ohjelmien asennusrajapintaakin, tyyliin fuse-vfs daemoni joka mergeää softien resurssit on-demand, mutta aina on ideoilleni vittuiltu. Tuntuu olevan hippipojilla asenteena, että jos jokin tuoksuu semmoiselta että siitä on apua kaupallisille ohjelmistontuottajille, niin sitä pitää kiertää.
Jo on perkele :)
linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote, linux ei ole tuote,
ja vielä kerran, linux ei ole tuote.
Se on vaihtoehto.
Juu aikamoinen vaihtoehto onkin.
Koko järjestelmä vitun kehittämisideologiaansa myöten pakottaa käyttäjät tukeutumaan miltei kokonaan OpenSource ohjelmiin.
Vitustahan tällainen "vendor lock in" on. Samanlaista harrastaa vitun-antikristus-saatana Microsoft, heillä tämä sidonta tehdään vaan kaupallisiin ohjelmistoihin ja standardeihin.
Minun mielestä KULUTTAJALLA tulee olla VAPAUS VALITA, että käyttääkö kaupallista ohjelmaa vai vapaan lähdekoodin vastinetta. Linuxissa tällainen vapaus ei oikein toteudu, johtuen siitä että kaupallisten ohjelmien kehitys Linuxille on sietämättömän kökköä puuhaa johtuen sen heterogeenisyydestä ja lopullisten standardien puutteesta.
Niin että vitut.
"Koko järjestelmä vitun kehittämisideologiaansa myöten pakottaa käyttäjät tukeutumaan miltei kokonaan OpenSource ohjelmiin."
Eipä pakotakaan.
"Samanlaista harrastaa vitun-antikristus-saatana Microsoft"
Jaa open source maailmassa samanlaista sidontaa? Perustelepa tarkemmin...
"Minun mielestä KULUTTAJALLA tulee olla VAPAUS VALITA, että käyttääkö kaupallista ohjelmaa vai vapaan lähdekoodin vastinetta."
Ihan oikeassa olet. Ainakin Linuxien kanssa kuluttajilla/käyttäjillä on tämä mahdollisuus.
"Linuxissa tällainen vapaus ei oikein toteudu, johtuen siitä että kaupallisten ohjelmien kehitys Linuxille on sietämättömän kökköä puuhaa johtuen sen heterogeenisyydestä ja lopullisten standardien puutteesta."
Ihan hyvin toteutuu. Kaupalliset softatalot ovat vain edelleenkin siinä kuvitteellisessa luulossa että _heidän_ täytyy tehdä jokaiselle jakelulle käännnös ja testaus työ. Ei tarvitse. Se on jakelijoiden homma.
"Niin että vitut."
Koskas sää kasvat yli tosta murkkuiästäs?
>> Ihan hyvin toteutuu. Kaupalliset softatalot ovat
>> vain edelleenkin siinä kuvitteellisessa luulossa
>> että _heidän_ täytyy tehdä jokaiselle jakelulle
>> käännnös ja testaus työ. Ei tarvitse. Se on
>> jakelijoiden homma.
Suljetun lähdekoodin ohjelmistoissa tuo testaus ja käännöstyö on pakko hoitaa talon sisäisesti. Muutenhan se koodi vuotaa, ja kilpailijat pääsevät apajille!
Kukaan suljettua ohjelmistoa kehittävä firma ei VARMANA anna distrojen kehittäjille lähdekoodeja haltuun, että he sitten sovittaisivat niistä. Se on aika riskaabelia hommaa tässä patenttien ja teollisuusvakoilun aikakaudella ...
>> Koskas sää kasvat yli tosta murkkuiästäs?
Kasvanut jo aikoja sitten. Sen huomaa siitä, että osaan olla realistinen mielipiteissäni.
"Suljetun lähdekoodin ohjelmistoissa tuo testaus ja käännöstyö on pakko hoitaa talon sisäisesti. Muutenhan se koodi vuotaa, ja kilpailijat pääsevät apajille!"
Niin on. Esim Skype ja Google Earth vaikuttaisivat olevan aika vakaita vaikkei avointa koodia olekaan.
Jakelijoiden homma on testata se että ohjelma toimii heidän jakelussaan tai sitten ilmoittaa että heidän jakelussaan tämä ohjelma ei toimi. Näiden softatalojen ongelma se ei ole. Koskas tajuaisit tämän asian?