Photon microGUI in Linux?

[Niek]

Hallo daar

Ik heb een tijdje geleden QNX geprobeerd, maar helaas is de hardware-ondersteuning matig. Omdat de GUI heel erg goed is, lijkt het me leuk om de Photon microGUI in Linux te kunnen draaien.
Weten jullie of dit mogelijk is of dat er een port bestaat?

Alvast bedankt

[Niek]

* schop *

Niemand

[xychix]

wat is QNX ??? os ?? gratis ????
antwoord op je vraag: nee ik ken het niet eens

*schop* (hoef jij dat niet meer te doen)

[Niek]

QNX is idd een gratis besturingssysteem. Het is erg snel, heeft een mooie GUI (Photon) en je kan er de meeste Linux-programma's in draaien. Het is gratis te downloaden op www.qnx.com

[TheNose]

Voor zover is weet is photon niet opensource, dus ik vraag mij af hoe je dat wilt doen. Photon is trouwens wel lekker rap en compact, jammer van de slechte drag and drop ondersteuning.

[odysseus]

Er bestaat in ieder geval wel een uitgebreide QNX-skin voor KDE, zie www.kde-look.org. Daarmee heb je echter alleen het uiterlijk, de snelheid die QNX blijkbaar heeft zul je er niet door krijgen.

[Niek]

Op woensdag 14 november 2001 20:17 schreef odysseus het volgende:
Er bestaat in ieder geval wel een uitgebreide QNX-skin voor KDE, zie www.kde-look.org. Daarmee heb je echter alleen het uiterlijk, de snelheid die QNX blijkbaar heeft zul je er niet door krijgen.

Bedankt voor de tip (voor de geinteresseerden, hier is de homepage), ziet er erg mooi uit!

Jammer dat Photon niet opensource is, ik vind X echt baggertraag en echte alternatieven zijn er niet.

[tweakerbee]

Zou een aardig idee zijn om Photon te porten ja. Of natuurlijk de BeOS gui. Die is ook wel lekker snel. Ben het met je eens dat X niet echt fijn is (wel mooi, maar traag + crasht)

[deadinspace]

Even een opmerking over X: dat veel mensen hem traag en/of instabiel vinden lijkt mij toch puur een driver-kwestie (omdat de fabrikanten te lam zijn om specs te geven), en een driver-probleem los je niet op door bijvoorbeeld QNX' gui te porten.

[blouweKip]

Bij mij is x wel redelijk snel (laaste versie in debian/sid + nvidia drivers)

[Verwijderd]

Afkloppen maar X is hier in al geen maanden op zijn bek gegaan. Oke heb een redelijke bak (P3 1Ghz 512 Mb Geforce 2 MX) maar Windows is beslist instabieler.

[Verwijderd]

Nog even een opmerking over MicroGUI. Volgens mij is er ook een skin voor ICEwm. Ik vond MicroGIU ook helemaal te gek, maar ja he. X op een p200 is nie errug snel. ICE en blackbox blijven dan al gauw als alternatieven over. Dus "redelijk" snel en MicroGUI onder X gaat wel...

[Remenic]

X is tering traag, zelfs op m'n Athlon 1.33GHz met NVidia TNT2.

open eens een konqueror, een xchat, een openoffice... open dan een terminal, Eterm ofzo, en ga daar eens mee over je scherm schuiven (wel "show contents while dragging" o.i.d. aanzetten). Je ziet alles lekker opnieuw hertekend worden. Zalig zo snel...

Nee, das met win2k toch wel een stuk beter...

Misschien dat DirectFB wat wordt:
http://www.linuxfromscratch.org/~remenic/dfb_lfs.png
http://www.linuxfromscratch.org/~remenic/browserfun.png

Niet sneller dan X (teminste, zoals je het hier ziet... XDirectFB schijnt wel sneller te zijn dan XFree86) , maar wel een stuk mooier

edit:
typo's rule

[deadinspace]

Op donderdag 15 november 2001 19:36 schreef Remenic het volgende:
open eens een konqueror, een xchat, een openoffice... open dan een terminal, Eterm ofzo, en ga daar eens mee over je scherm schuiven (wel "show contents while dragging" o.i.d. aanzetten). Je ziet alles lekker opnieuw hertekend worden. Zalig zo snel...

Valt wel mee hier hoor, en zoveel boeit het me ook niet... alsof ik de hele tijd 4 programma's over elkaar heb...

Misschien dat DirectFB wat wordt:
http://www.linuxfromscratch.org/~remenic/dfb_lfs.png
http://www.linuxfromscratch.org/~remenic/browserfun.png

Niet sneller dan X (teminste, zoals je het hier ziet... XDirectFB schijnt wel sneller te zijn dan XFree86) , maar wel een stuk mooier

Wat heeft dat mooier ermee te maken? Je realiseert je hopelijk dat je het er met XFree86 ook zo uit kunt laten zien?

En dit gebruikt dus nog steeds X. Als je beweert dat X traag is, en XDirectFB niet, spreek je jezelf dus behoorlijk tegen (aangezien XDirectFB net zo goed een X server is, en dus het X protocol praat).

Maar misschien doelde jij op XFree86, dan zou een snelheidsverschil aanwezig kunnen zijn ja. Ik weet niet hoe groot een eventueel snelheidsverschil zou zijn, maar ik moet zeggen dat ik hier (hier == pII 448 mhz, g450) weinig last heb van traagheid.

Maar ik zou wel graag even duidelijk weten waar je op doelt... bedoelde je dat X traag is (als in het protocol is traag omdat het slecht ontworpen is ofzo) of dat XFree86 (de X server die de meesten kennen en gebruiken) traag is?

[Niek]

Volgens deze benchmark is XDirectFB vele malen sneller dan XFree86 (OK, het is een beetje vals, ze hadden het met XFree 4.1.0 moeten vergelijken). Als mijn videokaart goed werd ondersteund door DirectFB, zou ik het wel weten...

[Remenic]

Op donderdag 15 november 2001 20:35 schreef deadinspace het volgende:

[..]

Valt wel mee hier hoor, en zoveel boeit het me ook niet... alsof ik de hele tijd 4 programma's over elkaar heb...
[..]

Wat heeft dat mooier ermee te maken? Je realiseert je hopelijk dat je het er met XFree86 ook zo uit kunt laten zien?

En dit gebruikt dus nog steeds X. Als je beweert dat X traag is, en XDirectFB niet, spreek je jezelf dus behoorlijk tegen (aangezien XDirectFB net zo goed een X server is, en dus het X protocol praat).

Maar misschien doelde jij op XFree86, dan zou een snelheidsverschil aanwezig kunnen zijn ja. Ik weet niet hoe groot een eventueel snelheidsverschil zou zijn, maar ik moet zeggen dat ik hier (hier == pII 448 mhz, g450) weinig last heb van traagheid.

Maar ik zou wel graag even duidelijk weten waar je op doelt... bedoelde je dat X traag is (als in het protocol is traag omdat het slecht ontworpen is ofzo) of dat XFree86 (de X server die de meesten kennen en gebruiken) traag is?

Ja, ik bedoelde XFree86.



Ps. Ik had een heel verhaal opgeschreven om duidelijk te maken waar ik op doelde, maar bij nader inzicht bedacht ik me dat 't toch geen zin heeft hier op in te gaan. Sommige fanatiekelingen staan toch niet open voor meningen van anderen.

[Remenic]

Op donderdag 15 november 2001 20:35 schreef deadinspace het volgende:

Wat heeft dat mooier ermee te maken? Je realiseert je hopelijk dat je het er met XFree86 ook zo uit kunt laten zien?

Hier wil ik nog wel effe reactie op geven, jij zegt dat *ik* het er zo uit kan laten zien. Vertel me maar eens hoe ik dat zal moeten doen dan. Waar kan ik de patches for XFree86 downloaden?

Ik verwacht een opmerking die zeer bijdehand is...

[Onno]

Op donderdag 15 november 2001 20:35 schreef deadinspace het volgende:
Maar ik zou wel graag even duidelijk weten waar je op doelt... bedoelde je dat X traag is (als in het protocol is traag omdat het slecht ontworpen is ofzo)

X is door het ontwerp in sommige opzichten gewoon trager (en minder direct) dan sommige andere systemen. Daar krijg je wel een hoop flexibiliteit voor terug, maar sommige dingen hadden misschien toch wel anders gekund. Het afhandelen van muis-events lijkt bijv. niet real-time te gebeuren, maar er wordt gewoon een queue verwerkt. Als je zoals iemand al noemde heel erg actief met vensters gaat zitten schuiven, kan het gebeuren dat de boel nog beweegt terwijl je je muis al lang hebt losgelaten. Zoiets zie je in bijv. Windows niet. Of je videokaart het nou op tijd kan redrawen of niet, je venster beweegt op het moment dat jij de muis beweegt, en geen seconde langer.

[deadinspace]

Op vrijdag 16 november 2001 09:13 schreef Remenic het volgende:
Hier wil ik nog wel effe reactie op geven, jij zegt dat *ik* het er zo uit kan laten zien. Vertel me maar eens hoe ik dat zal moeten doen dan. Waar kan ik de patches for XFree86 downloaden?

Ik verwacht een opmerking die zeer bijdehand is...

De Mac-achtige look kan met een windowmanager die een leuk theme heeft (Enlightenment had ergens een aqua theme meen ik), dus dan is het enige verschil nog de alpha blending/transparency zooi. En dat kan X / XFree86 ja, zie http://www.xfree86.org/~keithp/render/ . En ja, dat is beta, maar dat is DirectFB op zijn zachtst gezegd ook.

Op vrijdag 16 november 2001 08:54 schreef Remenic het volgende:
Ps. Ik had een heel verhaal opgeschreven om duidelijk te maken waar ik op doelde, maar bij nader inzicht bedacht ik me dat 't toch geen zin heeft hier op in te gaan. Sommige fanatiekelingen staan toch niet open voor meningen van anderen.

Ik zal me, omdat ik X / XFree86 verdedigde, maar even aangesproken voelen.
Ik sta heus wel open voor andermans meningen, en ook voor nieuwe technieken e.d. (wrom zou ik anders andere OSsen dan Windows gebruiken).

Op vrijdag 16 november 2001 09:57 schreef Onno het volgende:
X is door het ontwerp in sommige opzichten gewoon trager (en minder direct) dan sommige andere systemen. Daar krijg je wel een hoop flexibiliteit voor terug, maar sommige dingen hadden misschien toch wel anders gekund. Het afhandelen van muis-events lijkt bijv. niet real-time te gebeuren, maar er wordt gewoon een queue verwerkt. Als je zoals iemand al noemde heel erg actief met vensters gaat zitten schuiven, kan het gebeuren dat de boel nog beweegt terwijl je je muis al lang hebt losgelaten. Zoiets zie je in bijv. Windows niet. Of je videokaart het nou op tijd kan redrawen of niet, je venster beweegt op het moment dat jij de muis beweegt, en geen seconde langer.

Ook dat realiseer ik me.
X is niet perfect; sommige dingen zijn niet goed ontworpen, en sommige andere dingen hadden niet goed ontworpen kunnen worden omdat er teveel veranderd is in computer-hardware en software-eisen.
Aangezien DirectFB een hele nette abstractie voor je hardware vormt, zul je met DirectFB zeker een hogere performance halen dan met X.
Maar er zijn 2 dingen die je dan in de gaten moet houden:


• Backwards compatibility. Ja, het is sukky maar belangrijk.
Er moet een hoop geport worden voordat al je programma's in DirectFB kunt gebruiken. En dan krijg je dus scenario's dat je een prog download en het niet kunt gebruiken omdat het voor X is gecompiled en niet voor DFB, of andersom (ik weet niet precies hoe het zit als het via een widgetset zoals bijv gtk gaat).
Dit betekent niet dat we daarom bij een (arguably) inferieur systeem moeten blijven, maar het betekent wel dat voor we de moeite nemen om alles over te porten, het systeem waarheen we het overporten de moeite waard moet zijn.


• Network transparency. Een belangrijk punt imho.
Ik weet niet of DirectFB een fatsoenlijke oplossing voor netwerk transparency heeft. Zo ja, dan mag je deze opmerking als niet gemaakt beschouwen.
Ik ben de network transparency van X erg op prijs gaan stellen... De mogelijkheid om een programma vanaf een andere computer te draaien is erg prettig (ivm ram/cpu van je lokale bak, het feit dat je een prog niet hebt, of het feit dat de remote compu een ander OS/architectuur heeft), en de mogelijkheid om je complete desktop van een andere bak te draaien is ook grappig en blaast oude 486ers weer nieuw leven in.

Maar als een nieuw systeem een net ontwerp heeft, waardoor het efficient is en zaken als hardware acceleratie en alpha blending en antialiassing netjes en goed afhandeld, even flexibel is als X, network transparency aanbiedt, enz, enz dan vervangt dat systeem X heus wel hoor. Dan mag het ook.

Maar het valt mij vaak op dat X wordt afgezeken zonder goede redenen. Snelheid is vaak nogal afhankelijk van de drivers, en als je DirectFB zou gebruiken met dezelfde brakke drivers (omdat het bedrijf in kwestie te lam is om specs te geven bijvoorbeeld) dan zal het met DirectFB waarschijnlijk niet veel beter gaan.

Over XFree86 / XDirectFB:

Ok, dit zijn beiden X servers, dus het hele verhaal hierboven over X vs DirectFB is hier niet van toepassing.
Aangezien XDirectFB ook van het X protocol gebruik maakt, blijven de gebreken van X gewoon als je XDirectFB gebruikt.

Enig snelheidsverschil kan dan ook alleen maar komen omdat XDirectFB efficienter geimplementeerd is. Aangezien XDirectFB voor een redelijk gedeelte is herschreven kan ik me daar iets bij voorstellen, maar het lijkt me sterk dat het snelheidsverschil schokkend is... kan iemand die het *zelf* heeft geprobeerd in plaats van naar die benchmark te kijken daar misschien iets over zeggen?

[Remenic]

Op vrijdag 16 november 2001 16:18 schreef deadinspace het volgende:

[..]

De Mac-achtige look kan met een windowmanager die een leuk theme heeft (Enlightenment had ergens een aqua theme meen ik), dus dan is het enige verschil nog de alpha blending/transparency zooi. En dat kan X / XFree86 ja, zie http://www.xfree86.org/~keithp/render/ . En ja, dat is beta, maar dat is DirectFB op zijn zachtst gezegd ook.

Op dit antwoord zat ik te wachten. Hier is dus waar je het fout hebt. X-Render ondersteund ALLEEN alpha blending binnen z'n EIGEN canvas. Hij heeft dus niet de mogelijkheid om z'n eigen window ECHTE opacity te geven. Dus dat ie zegt, ik wil 50% transparant zijn, en X doet de rest kan niet. Wat je altijd zal moeten doen, is kijken wat er onder het windowtje staat, dat in het geheugen kopieeren (zodat dat plaatje in z'n eigen canvas staat), en daar z'n eigen spul overheen tekenen met alpha blending. Beetje omslachtig, en dus moet elke applicatie het zelf ondersteunen. En niet alleen, dat, want dat op zich is geen probleem, maar veranderingen achter een window worden door X niet doorgegeven.

Dus stel dat je een browser sessie open hebt staan, met daar overeen een echt transparante terminal, dan zal als er ik het browser venster een animated gif plaatje is, zal dat niet geupdate worden door de terminal. Je blijft dus het oude plaatje in de terminal zien. Kijk maar eens naar liquid van mostet, als je wilt zien wat ik bedoel.

KeithP is bezig met een nieuwe vorm van alpha blending die dit wel toe staat, maar dat is op het moment alleen nog in CVS te verkrijgen, en zeer buggy spul volgens mij.

Maar dit is dus NIET want xrender kan.

Op vrijdag 16 november 2001 16:18 schreef deadinspace het volgende:

[..]

Ik zal me, omdat ik X / XFree86 verdedigde, maar even aangesproken voelen.
Ik sta heus wel open voor andermans meningen, en ook voor nieuwe technieken e.d. (wrom zou ik anders andere OSsen dan Windows gebruiken).
[..]

Ook dat realiseer ik me.
X is niet perfect; sommige dingen zijn niet goed ontworpen, en sommige andere dingen hadden niet goed ontworpen kunnen worden omdat er teveel veranderd is in computer-hardware en software-eisen.
Aangezien DirectFB een hele nette abstractie voor je hardware vormt, zul je met DirectFB zeker een hogere performance halen dan met X.
Maar er zijn 2 dingen die je dan in de gaten moet houden:



• Backwards compatibility. Ja, het is sukky maar belangrijk.
Er moet een hoop geport worden voordat al je programma's in DirectFB kunt gebruiken. En dan krijg je dus scenario's dat je een prog download en het niet kunt gebruiken omdat het voor X is gecompiled en niet voor DFB, of andersom (ik weet niet precies hoe het zit als het via een widgetset zoals bijv gtk gaat).
Dit betekent niet dat we daarom bij een (arguably) inferieur systeem moeten blijven, maar het betekent wel dat voor we de moeite nemen om alles over te porten, het systeem waarheen we het overporten de moeite waard moet zijn.


• Network transparency. Een belangrijk punt imho.
Ik weet niet of DirectFB een fatsoenlijke oplossing voor netwerk transparency heeft. Zo ja, dan mag je deze opmerking als niet gemaakt beschouwen.
Ik ben de network transparency van X erg op prijs gaan stellen... De mogelijkheid om een programma vanaf een andere computer te draaien is erg prettig (ivm ram/cpu van je lokale bak, het feit dat je een prog niet hebt, of het feit dat de remote compu een ander OS/architectuur heeft), en de mogelijkheid om je complete desktop van een andere bak te draaien is ook grappig en blaast oude 486ers weer nieuw leven in.

Maar als een nieuw systeem een net ontwerp heeft, waardoor het efficient is en zaken als hardware acceleratie en alpha blending en antialiassing netjes en goed afhandeld, even flexibel is als X, network transparency aanbiedt, enz, enz dan vervangt dat systeem X heus wel hoor. Dan mag het ook.

Maar het valt mij vaak op dat X wordt afgezeken zonder goede redenen. Snelheid is vaak nogal afhankelijk van de drivers, en als je DirectFB zou gebruiken met dezelfde brakke drivers (omdat het bedrijf in kwestie te lam is om specs te geven bijvoorbeeld) dan zal het met DirectFB waarschijnlijk niet veel beter gaan.

Dit is allemaal een beetje mening afhankelijk. Hoewel ik veelvuldig gebruik maak van X z'n network transparency, denk ik dat dit op andere manieren ook heel makkelijk opgelost kan worden. Voor MS Windows zijn er ook programma's waarmee je X applicaties kan draaien, en dat werkt prima voor zover ik weet.

Ik heb niets tegen XFree86, als het wat meer grafische technieken benut. Ik zit hier met een super videokaart, op een ouderwets systeem. Goed, ik heb anti-aliased text nu, daar ben ik heel blij mee. En ik weet dat het systeem openstaat voor meer mogenlijkheden, maar ik zie er maar geen vaart in. DirectFB is van de grond af opgebouwd, bestaat nog niet zo gek lang, en kijk naar de dingen die het nu al ondersteund! En XFree86 bestaat al hoe lang??

Het is een beetje net als Microsoft op die manier. 6 jaar later, en we zitten nogsteeds met dezelfde "look" (in geval van windows). Goed er zijn wat dingen bijgekomen, maar het is niet het verschil van MacOS 9 naar MacOS X. Dat is wat ik denk waar wij aan toe zijn.

Gewoon 1 drastische verandering, weer eens iets totaal nieuws. Als we over een paar jaar nog met XFree86 zitten te kutten, en er komt een nieuw OS dat wel toffe dingen brengt, dan ben ik heel erg snel weg.

Begrijp me niet verkeerd, ik heb niets tegen Linux en ook niet tegen XFree86. Maar ik ben zeker niet blij met hoe XFree86 er nu voor staat.

Ik ben jaloers op systemen als MacOS X, Beos, en QNX Photon. Ze hebben alleen een eigen look, iets wat linux niet heeft. En ja, dat is aan de ene kant een voordeel, maar op de manier waarop het nu geimplementeerd is is het een nadeel imho. Ik haat het feit dat Qt en GTK apps er verschillend uit zien. Er is geen toffe theme die onder bijde toolkits er 100% hetzelfde uitzien. Dit oogt vrij lelijk, imho.

De dag dat Qt en GTK dezelfde themes gebruiken (en GOED, niet op de brakke manier dat KDE nu GTK themes ondersteund), en XFree86 meer technologische voortgang boekt zal de dag zijn dat ik ophoudt met zeuren over de main GUI van linux (XFree86).

[Remenic]

Oh, en toen ik zag/hoorde DirectFB nu ook GTK ondersteund (en binnenkort ook Qt) werd ik wel even verdrietig...

Hierdoor ben ik vandaag de dag niet zo heel enthousiast meer over DirectFB. Nadat ik las dat XFree86 ook echte opacity gaat ondersteunen begon ik weer een beetje respect te krijgen voor XFree86.


En het zal best dat het overkomt alsof ik niet weet wat ik wil, maar dat komt omdat er in linux teveel is. In princiepe ligt het probleem (imho) bij GTK, Qt, en XFree86. GTK <-> Qt zien er niet hetzelfde uit. XFree86 geeft GTK en Qt niet de mogelijkheid grafische wonderen uit te voeren.

[deadinspace]

Op zaterdag 17 november 2001 15:08 schreef Remenic het volgende:
Op dit antwoord zat ik te wachten. Hier is dus waar je het fout hebt. X-Render ondersteund ALLEEN alpha blending binnen z'n EIGEN canvas. Hij heeft dus niet de mogelijkheid om z'n eigen window ECHTE opacity te geven. Dus dat ie zegt, ik wil 50% transparant zijn, en X doet de rest kan niet. Wat je altijd zal moeten doen, is kijken wat er onder het windowtje staat, dat in het geheugen kopieeren (zodat dat plaatje in z'n eigen canvas staat), en daar z'n eigen spul overheen tekenen met alpha blending. Beetje omslachtig, en dus moet elke applicatie het zelf ondersteunen. En niet alleen, dat, want dat op zich is geen probleem, maar veranderingen achter een window worden door X niet doorgegeven.

Dus stel dat je een browser sessie open hebt staan, met daar overeen een echt transparante terminal, dan zal als er ik het browser venster een animated gif plaatje is, zal dat niet geupdate worden door de terminal. Je blijft dus het oude plaatje in de terminal zien. Kijk maar eens naar liquid van mostet, als je wilt zien wat ik bedoel.

KeithP is bezig met een nieuwe vorm van alpha blending die dit wel toe staat, maar dat is op het moment alleen nog in CVS te verkrijgen, en zeer buggy spul volgens mij.

Maar dit is dus NIET want xrender kan.

Ah, dat wist ik niet, dus daar heb je dan inderdaad gedeeltelijk gelijk.

Dit is allemaal een beetje mening afhankelijk. Hoewel ik veelvuldig gebruik maak van X z'n network transparency, denk ik dat dit op andere manieren ook heel makkelijk opgelost kan worden. Voor MS Windows zijn er ook programma's waarmee je X applicaties kan draaien, en dat werkt prima voor zover ik weet.

Mwa... het valt mij op dat die equivalenten voor Windows meestal trager zijn, hoewel ik er niet heel veel ervaring mee heb.
Het lijkt mij in ieder geval belangrijk om hier van het begin af aan rekening mee te houden; niet om te proberen het later 'erbij te bouwen'; dat leidt altijd tot kludges.

Ik heb niets tegen XFree86, als het wat meer grafische technieken benut. Ik zit hier met een super videokaart, op een ouderwets systeem. Goed, ik heb anti-aliased text nu, daar ben ik heel blij mee. En ik weet dat het systeem openstaat voor meer mogenlijkheden, maar ik zie er maar geen vaart in. DirectFB is van de grond af opgebouwd, bestaat nog niet zo gek lang, en kijk naar de dingen die het nu al ondersteund! En XFree86 bestaat al hoe lang??

Het is een beetje net als Microsoft op die manier. 6 jaar later, en we zitten nogsteeds met dezelfde "look" (in geval van windows). Goed er zijn wat dingen bijgekomen, maar het is niet het verschil van MacOS 9 naar MacOS X. Dat is wat ik denk waar wij aan toe zijn.

Gewoon 1 drastische verandering, weer eens iets totaal nieuws. Als we over een paar jaar nog met XFree86 zitten te kutten, en er komt een nieuw OS dat wel toffe dingen brengt, dan ben ik heel erg snel weg.

Begrijp me niet verkeerd, ik heb niets tegen Linux en ook niet tegen XFree86. Maar ik ben zeker niet blij met hoe XFree86 er nu voor staat.

Ik ben jaloers op systemen als MacOS X, Beos, en QNX Photon. Ze hebben alleen een eigen look, iets wat linux niet heeft. En ja, dat is aan de ene kant een voordeel, maar op de manier waarop het nu geimplementeerd is is het een nadeel imho. Ik haat het feit dat Qt en GTK apps er verschillend uit zien. Er is geen toffe theme die onder bijde toolkits er 100% hetzelfde uitzien. Dit oogt vrij lelijk, imho.

De dag dat Qt en GTK dezelfde themes gebruiken (en GOED, niet op de brakke manier dat KDE nu GTK themes ondersteund), en XFree86 meer technologische voortgang boekt zal de dag zijn dat ik ophoudt met zeuren over de main GUI van linux (XFree86).

Op zaterdag 17 november 2001 15:13 schreef Remenic het volgende:
Oh, en toen ik zag/hoorde DirectFB nu ook GTK ondersteund (en binnenkort ook Qt) werd ik wel even verdrietig...

Hierdoor ben ik vandaag de dag niet zo heel enthousiast meer over DirectFB. Nadat ik las dat XFree86 ook echte opacity gaat ondersteunen begon ik weer een beetje respect te krijgen voor XFree86.


En het zal best dat het overkomt alsof ik niet weet wat ik wil, maar dat komt omdat er in linux teveel is. In princiepe ligt het probleem (imho) bij GTK, Qt, en XFree86. GTK <-> Qt zien er niet hetzelfde uit. XFree86 geeft GTK en Qt niet de mogelijkheid grafische wonderen uit te voeren.

Welcome to the mess

Ja, het zou prettig zijn als er een nieuw, fatsoenlijk systeem werd ontworpen, die drastische verandering waar jij het over had, maar dat nieuwe systeem moet dan wel alle nadelen van X aanspreken en alle voordelen ervan meenemen...
De nette hardware-abstractie lijkt DirectFB voorlopig wel voor elkaar te hebben, maar ook 'in the long run' ? Met X (en XFree86) is het op te lossen via X' modulariteit... er is iets nieuws, en je schrijft er een module voor. Het is niet ideaal nee, maar in principe wel heel uitbreidtbaar (ook al gaat het met die compleet andere hw/sw wel richting kludge).
Ook de networking transparency (en daarmee een flinke dosis crossplatformheid) moet er imho van begin af aan netjes inzitten.
En natuurlijk efficientie, en hier heeft DirectFB een voordeel over X ja.

Een systeem dat al deze (en meer) problemen addresseert en netjes oplost mag van mij gerust X vervangen hoor, en liever vandaag dan morgen.

Maar ik geloof niet dat DirectFB deze zaken allemaal addresseert, en andere projecten (zoals Berlin) ook niet. Dat is iets dat me vaak stoort; er worden veel projecten begonnen en dan gehyped als veel beter dan X, maar uiteindelijk komt het nergens, laat staan dat het nou echt allemaal zoveel beter is dan X.

En dat GTK vs QT gebeuren... Ja, dat is mij ook een doorn in het oog. In plaats van dat er 1 widgetset is die extreem flexibel is, met themes die de complete look&feel veranderen, met goede bindings voor alle belangrijke talen, die lekker efficient is, enz, enz...
Ik heb niks tegen 2 grote Desktop environments en 20+ windowmanagers, want die gebruik je toch niet tegelijk, maar dat gekut met die 2 widgetsets van nu vind ik helemaal niks.

Een nieuw, heel goed grafisch systeem met een nieuwe generieke widgetset, en dan alle software die de moeite waard is porten... Dat zou de beste oplossing zijn, maar ik zie het voorlopig niet gebeuren.

[RG]

Persoonlijk vind ik X en XFree ook niet echt veel soeps. De manier waarop het werkt met suid gekloot en dan zijn eigen drivers die DRI hebben. Dat is nog niet het ergst, het ergste is dat het gewoon een sloom systeem is. Vooral met het tekenen van rechthoeken en dergelijke is het enorm traag. Daarnaast ondersteund het maar weinig moderne features.
DirectFB heeft wel toekomst denk ik, al denk ik ook dat de Linux kernel we wat moet verbeteren op dat punt en dat er kernel drivers komen voor dat soort dingen. Daar is trouwens niet iedereen van DirectFB het mee eens, maar ik dus wel Er zit immers ook een webserver in de kernel, waarom dan geen geavanceerde grafische API... kun je toch uitzetten als je dat niet hoeft.
Het leuke aan DirectFB is dat je alleen ff GDK moet aanpassen in de GTK+ library en hoppa alle GTK apps draaien op DirectFB. DirectFB netwerktransparantie kan je maken door een speciaal device te maken die output naar het netwerk. X doet in feite hetzelfde...

Wat ik gewoon wil is een snelle grafische schil, die als het even kan netwerktransparant is en lekker flexibel is en veel features heeft. Ik wil gewoon mijn resolutie en refreshrate on the fly aan kunnen passen zonder in duffe configfiles te gaan kloten. En ik wil normale kerneldrivers en niet van die XFree drivers die stiekem toch direct io mapping mogen doen vanuit een soortement van kernelspace in userspace...

[odysseus]

Op zondag 18 november 2001 02:46 schreef RG© het volgende:
Persoonlijk vind ik X en XFree ook niet echt veel soeps. De manier waarop het werkt met suid gekloot en dan zijn eigen drivers die DRI hebben.

Hoe wil je zoiets dan draaien zonder suid? Je wilt niet dat alleen root iets grafisch kan doen en zonder suid kunnen gewone gebruikers nu eenmaal niet aan bepaalde functies komen die gewoon vereist zijn voor een nette grafische omgeving (directe hardware toegang comes to mind). Het zou natuurlijk wel mooi zijn als je het voor elkaar krijgt om een goede grafische omgeving te maken zonder een server die permissies heeft om je systeem vrij onbruikbaar te maken.
Je probleem met die drivers volg ik niet helemaal. Wil je dan dat het onmogelijk is om drivers te maken die niet vanuit de kernel draaien? Dat wordt helemaal een zooitje, zeker als mensen dan een standaard niet ondersteunde kaart hebben. Moeten die allemaal dan maar hun kernel gaan hercompileren om het te laten werken? Lijkt me niet dat je de acceptatie van GNU/Linux bij het brede publiek op die manier helpt. Ik vind het zelf eigenlijk wel best dat drivers nu userspace zijn met eventueel (zie bijvoorbeeld NVidia) een driver in de kernel.

Dat is nog niet het ergst, het ergste is dat het gewoon een sloom systeem is. Vooral met het tekenen van rechthoeken en dergelijke is het enorm traag. Daarnaast ondersteund het maar weinig moderne features.

Dat het sneller kan ben ik direct met je eens. Of het ook veel sneller kan zonder de voordelen van XFree86 (of X in het algemeen) op te geven, betwijfel ik. Het gebrek aan moderne features is gedeeltelijk waar: die features zijn er vaak niet, maar er is wel de _mogelijkheid_ om die te maken. Zie projecten als DRI en de XRender-extensie.

DirectFB heeft wel toekomst denk ik, al denk ik ook dat de Linux kernel we wat moet verbeteren op dat punt en dat er kernel drivers komen voor dat soort dingen. Daar is trouwens niet iedereen van DirectFB het mee eens, maar ik dus wel Er zit immers ook een webserver in de kernel, waarom dan geen geavanceerde grafische API... kun je toch uitzetten als je dat niet hoeft.

Ho. Wacht. Het principe van een goede kernel is niet 'zet alles erin en zet uit wat je niet gebruikt', maar 'houd het zo minimaal mogelijk en voeg alleen dat toe wat je echt nodig hebt'. Ik ben het volledig eens met de ontwikkelaars die vinden dat er geen kerneldrivers vereist moeten zijn. Dit komt misschien de snelheid ten goede, maar is een ramp voor de stabiliteit. Die webserver in de kernel die je noemt (Tux) is een goed voorbeeld van iets wat er volgens mij _nooit_ in mag zitten. Ik wil er daarbij nog even op wijzen dat er ongeveer een half jaar geleden een flinke discussie is geweest over die webserver en daaruit bleek ook dat eenzelfde webserver die volledig userspace geimplementeerd was een (praktisch) gelijke snelheid kon halen. De voordelen van kernelspace processen worden vaak overdreven.

Het leuke aan DirectFB is dat je alleen ff GDK moet aanpassen in de GTK+ library en hoppa alle GTK apps draaien op DirectFB. DirectFB netwerktransparantie kan je maken door een speciaal device te maken die output naar het netwerk. X doet in feite hetzelfde...

Niet helemaal waar. Hier zie je het verschil tussen dingen al bij het ontwerp meenemen en dingen er later nog 'bij ontwerpen'. X stuurt inderdaad alle output over het netwerk (wat zou je anders willen doen?), maar wat je vergeet te vermelden is dat er bij het ontwerp van X al rekening mee gehouden is dat de hoeveelheid output zodanig is dat je er goed mee over het netwerk kunt werken. Ziedaar het verschil tussen implementatie tijdens of na het ontwikkelen van een produkt.

Wat ik gewoon wil is een snelle grafische schil, die als het even kan netwerktransparant is en lekker flexibel is en veel features heeft.

Ben ik volledig met je eens, net als ieder ander zinnig mens. Deadinspace zei dat hierboven ook al. Wat ik (en hij) betwijfel is of je dat bereikt door een volledig nieuw systeem te bouwen. Mocht je dat systeem volledig uitontwikkelen, dan geloof ik graag dat het beter is dan X(Free86), maar ik denk niet dat dat lukt. Voorlopig is X gewoon de beste keus, met de meeste features en de beste ondersteuning. Dat zijn belangrijke dingen, die je niet zomaar weg kunt gooien. Het enige probleem dat ik met XFree86 heb is dat het niet echt 'open' ontworpen wordt. Je krijgt wel allerlei changelogs te zien, maar de directe ontwikkeling blijft een beetje duister (zo ken ik bijvoorbeeld geen CVS-versie van XFree86, dat zegt al heel wat). Er is ook al eens een rel geweest toen The Open Group van X (of XFree86, dat weet ik niet precies meer) gesloten software wilden maken. Na protesten is dat uiteindelijk niet doorgegaan.

Ik wil gewoon mijn resolutie en refreshrate on the fly aan kunnen passen zonder in duffe configfiles te gaan kloten.

Ctrl-Alt-+ en Ctrl-Alt-- is gewoon switchen tussen resoluties. Zo'n probleem is dat toch niet? De refreshrate heb ik nog niet geprobeerd, maar het lijkt me stug dat als je naar een hogere resolutie gaat hij niet van refreshrate wisselt (zou wel leuk zijn ), dus blijkbaar kan dat ook gewoon. Het probleem is dat er niemand een tooltje schrijft dat dat gewoon even met een slidertje in laat stellen. Dat programmaatje zou dan gewoon voor jou in die 'duffe configfiles' kunnen kloten, zoals jij het zegt.

En ik wil normale kerneldrivers en niet van die XFree drivers die stiekem toch direct io mapping mogen doen vanuit een soortement van kernelspace in userspace...

En ik wil drivers die met zo min mogelijk permissies hun werk nog kunnen doen. Als dat een speciaal soort userspace drivers zijn, dan gebruik ik die.

* odysseus wil 'gewoon' een goed werkend, stabiel systeem zonder non-free spul...

[RG]

Hoe wil je zoiets dan draaien zonder suid? Je wilt niet dat alleen root iets grafisch kan doen en zonder suid kunnen gewone gebruikers nu eenmaal niet aan bepaalde functies komen die gewoon vereist zijn voor een nette grafische omgeving (directe hardware toegang comes to mind). Het zou natuurlijk wel mooi zijn als je het voor elkaar krijgt om een goede grafische omgeving te maken zonder een server die permissies heeft om je systeem vrij onbruikbaar te maken.
Je probleem met die drivers volg ik niet helemaal. Wil je dan dat het onmogelijk is om drivers te maken die niet vanuit de kernel draaien? Dat wordt helemaal een zooitje, zeker als mensen dan een standaard niet ondersteunde kaart hebben. Moeten die allemaal dan maar hun kernel gaan hercompileren om het te laten werken? Lijkt me niet dat je de acceptatie van GNU/Linux bij het brede publiek op die manier helpt. Ik vind het zelf eigenlijk wel best dat drivers nu userspace zijn met eventueel (zie bijvoorbeeld NVidia) een driver in de kernel.

DirectFB werkt momenteel gewoon in userspace als je onder een gewone gebruiker bent ingelogd. Dit kotm gewoon omdat het via hetzelfde principe werkt als een geluidskaart zeg maar. Gewoon via een kernel device (het frambufferdevice dus) toegang hebbentot de hardware. Hierdoor ben je af van al het gezeur van drivers die toch stiekem vanuit userspace directe toegang hebben tot de hardware en programma's die stiekem als suid draaien. Mij lijkt een grafische API ind e kernel het beste. Dan bedoel ik dus gewoon een simpele basislayer zoals die nu al geboden wordt door het framebuffer, maar dan aangevuld met een aantal zaken die DirectFB nu appart moet afhandelen in drivers. Die drivers moeten gewoon geïntegreerd worden in de kernel lijkt me, doen vrijwel alle andere systemen ook gewoon. Gewoon drivers als modules, heeft je soundkaart toch ook?? Ik zie totaal het probleem niet...

Dat het sneller kan ben ik direct met je eens. Of het ook veel sneller kan zonder de voordelen van XFree86 (of X in het algemeen) op te geven, betwijfel ik. Het gebrek aan moderne features is gedeeltelijk waar: die features zijn er vaak niet, maar er is wel de _mogelijkheid_ om die te maken. Zie projecten als DRI en de XRender-extensie.

Ja wat heeft een gebruiker eraan of het mogelijk is? Het moet gewoon werken punt uit. Je kunt moeilijk een huisvrouw haar eigen XFree extensie laten schrijven niet waar?[quote]
Ho. Wacht. Het principe van een goede kernel is niet 'zet alles erin en zet uit wat je niet gebruikt', maar 'houd het zo minimaal mogelijk en voeg alleen dat toe wat je echt nodig hebt'. Ik ben het volledig eens met de ontwikkelaars die vinden dat er geen kerneldrivers vereist moeten zijn. Dit komt misschien de snelheid ten goede, maar is een ramp voor de stabiliteit. Die webserver in de kernel die je noemt (Tux) is een goed voorbeeld van iets wat er volgens mij _nooit_ in mag zitten. Ik wil er daarbij nog even op wijzen dat er ongeveer een half jaar geleden een flinke discussie is geweest over die webserver en daaruit bleek ook dat eenzelfde webserver die volledig userspace geimplementeerd was een (praktisch) gelijke snelheid kon halen. De voordelen van kernelspace processen worden vaak overdreven.[quote]

Tja maak dat Linus Thorvalds maar eens wijs. De grootste tegenstander van een microkernel zo ongeveer. Wat jij zegt klopt gewoon niet. Die drivers voor XFree draaien ook in een soort van kernelspace hoor. Ena ls je XFree stabiel vind, moet je maar eens bij mij komen kijken. Ik begrijp echt niet, waarom er geen grafische API in de kernel mag komen (die er BTW al is, maar op beperkte schaal). Die webserver heeft geen hardwaretoegang nodig, maar die videodrivers wel en dat wordt nu op een erg omslachtige manier geregeld vie XFree dus.

Niet helemaal waar. Hier zie je het verschil tussen dingen al bij het ontwerp meenemen en dingen er later nog 'bij ontwerpen'. X stuurt inderdaad alle output over het netwerk (wat zou je anders willen doen?), maar wat je vergeet te vermelden is dat er bij het ontwerp van X al rekening mee gehouden is dat de hoeveelheid output zodanig is dat je er goed mee over het netwerk kunt werken. Ziedaar het verschil tussen implementatie tijdens of na het ontwikkelen van een produkt.

Ehm nou je kunt ook gewoon calls doen? Berlin bijvoorbeeld werkt via CORBA. In plaats van de hele tijd bitmaps over het netwerk te pompen, zeg je gewoon wat een client moet doen.

Ben ik volledig met je eens, net als ieder ander zinnig mens. Deadinspace zei dat hierboven ook al. Wat ik (en hij) betwijfel is of je dat bereikt door een volledig nieuw systeem te bouwen. Mocht je dat systeem volledig uitontwikkelen, dan geloof ik graag dat het beter is dan X(Free86), maar ik denk niet dat dat lukt. Voorlopig is X gewoon de beste keus, met de meeste features en de beste ondersteuning. Dat zijn belangrijke dingen, die je niet zomaar weg kunt gooien. Het enige probleem dat ik met XFree86 heb is dat het niet echt 'open' ontworpen wordt. Je krijgt wel allerlei changelogs te zien, maar de directe ontwikkeling blijft een beetje duister (zo ken ik bijvoorbeeld geen CVS-versie van XFree86, dat zegt al heel wat). Er is ook al eens een rel geweest toen The Open Group van X (of XFree86, dat weet ik niet precies meer) gesloten software wilden maken. Na protesten is dat uiteindelijk niet doorgegaan.

Ook dat. XFree wordt erg traag ontwikkeld vind ik zelf. Niks tegen de developers van XFree, maar dat hele XFree is zo'n omvangrijke en ondoorzichtige zooi geworden.

En ik wil drivers die met zo min mogelijk permissies hun werk nog kunnen doen. Als dat een speciaal soort userspace drivers zijn, dan gebruik ik die.

Ik vind dit een raar argument. Als er iets vreemd is, is het wel XFree dat ten eerste als suid draait en daarnaast nog eens drivers heeft die buiten de kernelspace toch direct met de hardware mogen kloten. Doe mij dan gewoon goede drivers in de kernel, ben je van al dat gesodemieter af... vergelijk het met een geluidskaart, muis, etc...

* odysseus wil 'gewoon' een goed werkend, stabiel systeem zonder non-free spul...

Jij hebt de licensie van XFree gezien en die van DirectFB? En jij weet hoe onstabiel XFree is?? Dat is namelijk mijn hoofdrede waarom Linux op de desktop voor mij nog geen hit is geworden...

[odysseus]

DirectFB werkt momenteel gewoon in userspace als je onder een gewone gebruiker bent ingelogd. Dit kotm gewoon omdat het via hetzelfde principe werkt als een geluidskaart zeg maar. Gewoon via een kernel device (het frambufferdevice dus) toegang hebbentot de hardware.

Ik ben het met je eens dat DirectFB dit beter afhandelt dan XFree86, maar wat precies verhindert XFree86 om hetzelfde te doen? Ik denk niet dat er ergens in de X-standaard vermeld staat dat de output niet via een apart device mag gaan. Sterker nog, er bestaat ook zoiets als Xvfb. Alhoewel Xvfb gebruik maakt van een virtual framebuffer, geeft dat toch duidelijk aan dat je dan ook een echt framebuffer kunt gebruiken met XFree86.

Hierdoor ben je af van al het gezeur van drivers die toch stiekem vanuit userspace directe toegang hebben tot de hardware en programma's die stiekem als suid draaien.

Zoals ik net al vermeldde: ik ben ervoor om programma's met zo weinig mogelijk permissies hun werk te laten doen. Maar ook hier geldt weer: DirectFB doet dit dus op deze manier, maar X is flexibel genoeg om dat ook te kunnen. Bovendien kun je ook best een kerneldriver gebruiken met X(Free86) als je dat graag wilt, het is alleen iets wat ik liever niet doe. Misschien zegt het wel wat dat dit nog steeds niet overal gebeurt, blijkbaar zijn kerneldrivers toch niet 'de' oplossing voor problemen...

Mij lijkt een grafische API ind e kernel het beste. Dan bedoel ik dus gewoon een simpele basislayer zoals die nu al geboden wordt door het framebuffer, maar dan aangevuld met een aantal zaken die DirectFB nu appart moet afhandelen in drivers. Die drivers moeten gewoon geïntegreerd worden in de kernel lijkt me, doen vrijwel alle andere systemen ook gewoon. Gewoon drivers als modules, heeft je soundkaart toch ook?? Ik zie totaal het probleem niet...

Een kleine kanttekening: de kernel handelt dan wel geluid af, maar alleen het doorlussen van raw-audio van userspace naar je geluidskaart. Voor video/grafische dingen gebeurt hetzelfde: alles wat in userspace kan (het opbouwen van dat wat er op het beeld moet komen) gebeurt in userspace en alleen het overbrengen van de beeldinformatie vanaf userspace naar je videokaart of processor gebeurt door de kernel. Dat blijft naar mijn mening de beste oplossing. Met eenzelfde argument als jij gebruikte: er zit toch geen audiomixer in de kernel, waarom dan wel een complete grafische API. Je wilt toch geen alpha-blending door de kernel laten uitvoeren, hoop ik?

Ja wat heeft een gebruiker eraan of het mogelijk is? Het moet gewoon werken punt uit. Je kunt moeilijk een huisvrouw haar eigen XFree extensie laten schrijven niet waar?

Volgens mij zei je net zelf 'dat DirectFB ook makkelijk netwerktransparantie zou kunnen ondersteunen'. Natuurlijk moet het gewoon werken, maar wil je zeggen dat DirectFB dat doet? Je zult het toch echt eerst moeten ontwikkelen, dat geldt voor beide alternatieven en het is bij allebei mogelijk.

Ehm nou je kunt ook gewoon calls doen? Berlin bijvoorbeeld werkt via CORBA. In plaats van de hele tijd bitmaps over het netwerk te pompen, zeg je gewoon wat een client moet doen.

En wat denk je dat X kan doen?

Ook dat. XFree wordt erg traag ontwikkeld vind ik zelf. Niks tegen de developers van XFree, maar dat hele XFree is zo'n omvangrijke en ondoorzichtige zooi geworden.

Op dit punt zijn we het ondertussen dus wel eens, XFree86 is inderdaad een nogal ondoorzichtige spaghetti geworden. Maar dat DirectFB dat niet wordt als het evenveel kan als XFree86, moet ik nog zien.

Jij hebt de licensie van XFree gezien en die van DirectFB? En jij weet hoe onstabiel XFree is?? Dat is namelijk mijn hoofdrede waarom Linux op de desktop voor mij nog geen hit is geworden...

Ik heb de licenties van XFree86 en DirectFB net even vergeleken. XFree86 heeft een bijzonder korte licentie, die mensen in principe alles toestaat, zolang ze bij reclame maar niet de naam van The Open Group gebruiken. Voor de rest staat er alleen in dat je naar believen mag handelen, wijzigen en distribueren en dat er geen garanties zijn voor het goed werken van de software. Geen slechte licentie lijkt me zo. DirectFB valt (volgens de source, ik zie het niet op hun site) onder de LGPL, die in feite precies hetzelfde vertelt met nog wat restricties, zoals de verplichting te vermelden welke wijzigingen er zijn ten opzichte van het origineel. Geen schokkende verschillen op licentiegebied dus.
Wel zou XFree inderdaad soms wat stabieler mogen, maar om het nu onstabiel te noemen...ik heb hier de afgelopen tijd een keer een crash van XFree86 gehad en dat kwam door de (binary) NVidia-drivers, dus daar kan ik lastig iemand de schuld van geven behalve mijzelf...overigens denk ik niet dat de onstabiliteit van XFree86 de reden zou zijn dat GNU/Linux nog niet op de desktopmarkt is doorgebroken. De meeste mensen die een desktop gebruiken migreren van een platform waar crashes in de grafische modus nog veel frequenter zijn...

[RG]

Ik ben het met je eens dat DirectFB dit beter afhandelt dan XFree86, maar wat precies verhindert XFree86 om hetzelfde te doen? Ik denk niet dat er ergens in de X-standaard vermeld staat dat de output niet via een apart device mag gaan. Sterker nog, er bestaat ook zoiets als Xvfb. Alhoewel Xvfb gebruik maakt van een virtual framebuffer, geeft dat toch duidelijk aan dat je dan ook een echt framebuffer kunt gebruiken met XFree86.

XFree kan dat doen ja, maar dat is niet gebruikelijk. Maar dat is niet zozeer waardoor XFree traag is, maar eerder waardoor het een slecht ontwerp is. IMHO horen drivers in in de kernel thuis en niet in de userspace die dan stiekem toch kernel space is...

Zoals ik net al vermeldde: ik ben ervoor om programma's met zo weinig mogelijk permissies hun werk te laten doen. Maar ook hier geldt weer: DirectFB doet dit dus op deze manier, maar X is flexibel genoeg om dat ook te kunnen. Bovendien kun je ook best een kerneldriver gebruiken met X(Free86) als je dat graag wilt, het is alleen iets wat ik liever niet doe. Misschien zegt het wel wat dat dit nog steeds niet overal gebeurt, blijkbaar zijn kerneldrivers toch niet 'de' oplossing voor problemen...

De enige reden is dat het niet bepaald goed is voor de porteerbaarheid. Waarom kerneldrivers niet de oplossing zijn is mij een raadsel. Als men gewoon een fatsoenlijke API maakt, kunnen andere UNIX developpers het overnemen. FreeBSD is ook al bezig aan een framebuffer device meen ik.
Waarom gebruik jij dan wel een kerneldriver voor je geluidskaart, maar niet voor je videokaart? Trouwens de commerciële NVidia drivers bevatten een kernel modules, so who cares?

Een kleine kanttekening: de kernel handelt dan wel geluid af, maar alleen het doorlussen van raw-audio van userspace naar je geluidskaart. Voor video/grafische dingen gebeurt hetzelfde: alles wat in userspace kan (het opbouwen van dat wat er op het beeld moet komen) gebeurt in userspace en alleen het overbrengen van de beeldinformatie vanaf userspace naar je videokaart of processor gebeurt door de kernel. Dat blijft naar mijn mening de beste oplossing. Met eenzelfde argument als jij gebruikte: er zit toch geen audiomixer in de kernel, waarom dan wel een complete grafische API. Je wilt toch geen alpha-blending door de kernel laten uitvoeren, hoop ik?

Dat wil ik liever wel ja. Heb je daar een videokaart die alles gewoon hardwarematig kan, nee hoor wordt het softwarematig gedaan (beste voorbeeld is dus XFree). Dit is een van de hoofdredenen dat XFree zo sloom is. Wat DirectFB doet is alles softwarematig implementeren en als een kaart een bepaalde feature ondersteund, het dan hardwarematig laten afhandelen. Zo benut je optimaal je grafische kaart. XFree daarentegen doet een heleboel dingen gewoon softwarematig en das nou niet bepaald efficiënt...

Volgens mij zei je net zelf 'dat DirectFB ook makkelijk netwerktransparantie zou kunnen ondersteunen'. Natuurlijk moet het gewoon werken, maar wil je zeggen dat DirectFB dat doet? Je zult het toch echt eerst moeten ontwikkelen, dat geldt voor beide alternatieven en het is bij allebei mogelijk.

Eh ja dat zei ik, maar ik neem aan dat mensen die deze feature willen geen huisvrouwen zijn, maar mensen met kennis. En dat zoiets ontwikkelen heel wat eenvoudiger is dan weer een hele zwik XFree extensies ertegenaan gooien.

En wat denk je dat X kan doen?

Bitmaps over het netwerk pompen, meer niet. Kan je dus in theorie zo met DirectFB regelen door een framebuffer device driver die alles over het netwerk stuurt.

Op dit punt zijn we het ondertussen dus wel eens, XFree86 is inderdaad een nogal ondoorzichtige spaghetti geworden. Maar dat DirectFB dat niet wordt als het evenveel kan als XFree86, moet ik nog zien.

DirectFB gebruikt zoveel mogelijk dingen van de Linux kernel. Daarom is het ook zo klein. XFree is gewoon een grote rotzooi geworden, ik snap echt niet meer waar het allemaal voor dient, teriwjl DirectFB gewoon een eenvoudige library is met wat drivers erbij. Ik zou ik niet weten waarom DirectFB zo nodig alles moet kunnen wat XFree kan. Ik noem maar PEX of XT, gebruikt toch niemand, en zo zijne r nog 800 voorbeelden...

Wel zou XFree inderdaad soms wat stabieler mogen, maar om het nu onstabiel te noemen...ik heb hier de afgelopen tijd een keer een crash van XFree86 gehad en dat kwam door de (binary) NVidia-drivers, dus daar kan ik lastig iemand de schuld van geven behalve mijzelf...overigens denk ik niet dat de onstabiliteit van XFree86 de reden zou zijn dat GNU/Linux nog niet op de desktopmarkt is doorgebroken. De meeste mensen die een desktop gebruiken migreren van een platform waar crashes in de grafische modus nog veel frequenter zijn...

XFree hangt bij mij bij intensief werken een paar ker per dag. Kan ik weer gezellig resetten en daarna mij filesysteem gaan repareren. En dit komt gewoon door XFree en niet door de NVidia drivers.

[BezurK]

Ahum, graag een beetje on-topic blijven heren

[deadinspace]

Op zondag 18 november 2001 13:28 schreef odysseus het volgende:
Ctrl-Alt-+ en Ctrl-Alt-- is gewoon switchen tussen resoluties. Zo'n probleem is dat toch niet?

Hm... Zie je het probleem echt niet of doe je alsof je het niet ziet?
De resolutie van je monitor is geen probleem nee, maar het on-the-fly aanpassen van de resolutie van je *desktop* (zoals in bijvoorbeeld Windows wel kan) is onmogelijk op het moment (dat wil zeggen, zonder X herstart).
Nou wordt er wel aan een X extension (de RANDR extension) gewerkt die dit mogelijk maakt (mits de programma's het ondersteunen), maar die is afaik nog niet af.

Op zondag 18 november 2001 13:50 schreef RG© het volgende:
DirectFB werkt momenteel gewoon in userspace als je onder een gewone gebruiker bent ingelogd. Dit kotm gewoon omdat het via hetzelfde principe werkt als een geluidskaart zeg maar.

Ho.
Je vergeet dat voordat je als user met DirectFB iets mag, je wel read-write rechten op /dev/fb0 nodig hebt. Dus als 2 users op 1 systeem allebei DirectFB willen gebruiken moeten ze allebei read-write rechten op /dev/fb0 hebben, en kunnen ze dus allebei het scherm lezen, waarbij het niet uitmaakt wie er ingelogd is.
(dit is wel op te lossen door de permissies/user van /dev/fb* on-the-fly te veranderen, net als met /dev/pts/* gebeurt, maar het is evengoed niet perfect)

Ja wat heeft een gebruiker eraan of het mogelijk is? Het moet gewoon werken punt uit. Je kunt moeilijk een huisvrouw haar eigen XFree extensie laten schrijven niet waar?

Niemand zegt dat je je eigen XFree modules moet schrijven.
Maar de extensies van X maken het mogelijk later dingen toe te voegen (shared memory, DRI, Xrender, RANDR, GLX, enz, enz) die niet origineel in het ontwerp zaten. Een erg belangrijk feit.

En jij weet hoe onstabiel XFree is??

Nou, hier zijn de crashes (1 jaar, 3 computers met X) op 1 hand te tellen hoor.

Op zondag 18 november 2001 14:55 schreef odysseus het volgende:
Op dit punt zijn we het ondertussen dus wel eens, XFree86 is inderdaad een nogal ondoorzichtige spaghetti geworden.

* deadinspace agrees.

Op zondag 18 november 2001 17:16 schreef RG© het volgende:
XFree daarentegen doet een heleboel dingen gewoon softwarematig en das nou niet bepaald efficiënt...

Ehm nee, XFree laat wel degelijk zoveel mogelijk dingen aan de hardware over. Dit gaat niet allemaal even efficient, omdat het X protocol daar niet voor ontworpen is, maar XFree laat wel zoveel mogelijk door de hardware uitvoeren.

Bitmaps over het netwerk pompen, meer niet. Kan je dus in theorie zo met DirectFB regelen door een framebuffer device driver die alles over het netwerk stuurt.

Ook dat is niet waar; X stuurt teken-opdrachten over het netwerk; dus bijvoorbeeld 'teken een rechthoek met kleur bla, plaats bla en grootte bla' in plaats van dat hij een bitmap ervan over het netwerk stuurt.
Wat jij voorstelt zou VEEL meer netwerk-verkeer veroorzaken.

XFree hangt bij mij bij intensief werken een paar ker per dag. Kan ik weer gezellig resetten en daarna mij filesysteem gaan repareren. En dit komt gewoon door XFree en niet door de NVidia drivers.

Nee. XFree is best stabiel.
Je weet trouwens dat de nVidia drivers erom bekend staan dat ze kernel memory corrupten?

Op zondag 18 november 2001 13:28 schreef odysseus het volgende:
Ho. Wacht. Het principe van een goede kernel is niet 'zet alles erin en zet uit wat je niet gebruikt', maar 'houd het zo minimaal mogelijk en voeg alleen dat toe wat je echt nodig hebt'.

Hier wil ik nog even iets over opmerken.
Linux (als in: de kernel) is eigenlijk veel te groot. Eigenlijk zou alleen de echte hardware-acces in de kernel moeten, en de rest in userspace (het microkernel idee). Maar dat is weer een hele andere discussie.

Op zondag 18 november 2001 18:31 schreef BezurK het volgende:
Ahum, graag een beetje on-topic blijven heren

Het was toch al duidelijk dat QNX' Photon gui niet op GNU/Linux draait? Dan is die vraag beantwoordt namelijk.
En de rest van de discussie gaat juist over de hele reden dat de topicstarter vroeg of die Photon gui niet op GNU/Linux draait: de tekorten van X / XFree86.
Best een belangrijk onderwerp imho.

[BezurK]

Jezus, twas een grapje hoor (), doe rustig aan, tis nog weekend

Ik ben het er overigens wel mee eens dat X NIET instabiel is, bij mij crashed het zelden, heeeeel zelden.

[deadinspace]

Op zondag 18 november 2001 21:55 schreef BezurK het volgende:
Jezus, twas een grapje hoor (), doe rustig aan, tis nog weekend

Weekend voor de tentamenweek ja

[RG]

Ho.
Je vergeet dat voordat je als user met DirectFB iets mag, je wel read-write rechten op /dev/fb0 nodig hebt. Dus als 2 users op 1 systeem allebei DirectFB willen gebruiken moeten ze allebei read-write rechten op /dev/fb0 hebben, en kunnen ze dus allebei het scherm lezen, waarbij het niet uitmaakt wie er ingelogd is.
(dit is wel op te lossen door de permissies/user van /dev/fb* on-the-fly te veranderen, net als met /dev/pts/* gebeurt, maar het is evengoed niet perfect)

Tja dat klopt, maar dat is met alle andere hardware zo. Dat on the fly veranderen lijkt me nog altijd een beter optie dan de oplossing van XFree.

Niemand zegt dat je je eigen XFree modules moet schrijven.
Maar de extensies van X maken het mogelijk later dingen toe te voegen (shared memory, DRI, Xrender, RANDR, GLX, enz, enz) die niet origineel in het ontwerp zaten. Een erg belangrijk feit.

Dat die extensies er zijn ia hardstikke leuk, maar of het er nu allemaal sneller van wordt weet ik niet. IMHO kun je beter een nieuw systeem ontwerpen, en niet eindeloos blijven vastklampen aan XFree. Als Linux werkelijk iets wil worden op de desktop, zal het eerst een fatsoenlijke GUI moeten hebben. Alle andere OS'en die ik ken (behalve dan die ook X gebruiken) hebben gewoon hun grafische drivers in de kernel zitten, of in ieder geval als een kernel component draaien...

Nou, hier zijn de crashes (1 jaar, 3 computers met X) op 1 hand te tellen hoor.

Hier heb je daar dus een rekenmachine voor nodig En echt snel is het ook niet vergeleken bij Windows...

Ehm nee, XFree laat wel degelijk zoveel mogelijk dingen aan de hardware over. Dit gaat niet allemaal even efficient, omdat het X protocol daar niet voor ontworpen is, maar XFree laat wel zoveel mogelijk door de hardware uitvoeren.

Tja maar als je daar eerst 17 stappen voor nodig hebt, dan gaat dat ook niet echt opschieten...

Ook dat is niet waar; X stuurt teken-opdrachten over het netwerk; dus bijvoorbeeld 'teken een rechthoek met kleur bla, plaats bla en grootte bla' in plaats van dat hij een bitmap ervan over het netwerk stuurt.
Wat jij voorstelt zou VEEL meer netwerk-verkeer veroorzaken.

Dat is ten dele wel waar, maar tegenwoordig draait vrijwel alles op bitmaps, dus doet XFree in feite ook niet veel meer dan bitmaps overpompen... Trouwens dat "teken rechthoek" enzo, kan je volgens mij directfb zo laten doen over het netwerk.

Nee. XFree is best stabiel.
Je weet trouwens dat de nVidia drivers erom bekend staan dat ze kernel memory corrupten?

Ik heb geen flauw idee of ze dat doen, maar als ik ze niet gebruik hang XFree net zo vaak. En als je het niet geloofd kom je maar eens kijken Ik heb daar met alle distributies met alle XFree versies 4 of hoger gehad

Hier wil ik nog even iets over opmerken.
Linux (als in: de kernel) is eigenlijk veel te groot. Eigenlijk zou alleen de echte hardware-acces in de kernel moeten, en de rest in userspace (het microkernel idee). Maar dat is weer een hele andere discussie.

Ben ik het mee eens! Maar als je daarmee de snelheid van je GUI moet inleveren dan hoeft het van mij niet. Er moet gewoon een grafische API zijn lijkt mij, waarmee je de volle snelheid uit je systeem kunt persen. Als Linux op de desktop wat wil worden moet dat in elk geval gebeuren...

[deadinspace]

Op zondag 18 november 2001 23:51 schreef RG© het volgende:
Dat die extensies er zijn ia hardstikke leuk, maar of het er nu allemaal sneller van wordt weet ik niet. IMHO kun je beter een nieuw systeem ontwerpen, en niet eindeloos blijven vastklampen aan XFree.

Wat wil je? Voor elke nieuwe videokaart-feature die er wordt bedacht een nieuw grafisch systeem bedenken?

Tja maar als je daar eerst 17 stappen voor nodig hebt, dan gaat dat ook niet echt opschieten...

Dat is een nadeel ja, en dat gaf ik zelf ook al toe.

Dat is ten dele wel waar, maar tegenwoordig draait vrijwel alles op bitmaps, dus doet XFree in feite ook niet veel meer dan bitmaps overpompen...

Mwa... valt nogal mee hoor. Als je bijvoorbeeld een browser remote draait, is het tekenen van de widgetset bijvoorbeeld veel lijntjes-werk. Het browsergedeelte zelf is ook een kwestie van een witte achtergrond met een hoop text en een paar plaatjes (meestal dan).

Trouwens dat "teken rechthoek" enzo, kan je volgens mij directfb zo laten doen over het netwerk.

Dat wordt waarschijnlijk lastig als daar niet van begin af aan rekening mee gehouden wordt. En dat is precies mijn punt wat ik eerder probeerde te maken.

Ben ik het mee eens! Maar als je daarmee de snelheid van je GUI moet inleveren dan hoeft het van mij niet. Er moet gewoon een grafische API zijn lijkt mij, waarmee je de volle snelheid uit je systeem kunt persen. Als Linux op de desktop wat wil worden moet dat in elk geval gebeuren...

Het microkernel design kost bijna altijd wat performance (niet veel als het goed ontworpen en geimplementeerd is), maar het is een veel netter ontwerp, en is mega-stabiel mits juist ontworpen (zie bijvoorbeeld Solaris).

[RG]

Wat wil je? Voor elke nieuwe videokaart-feature die er wordt bedacht een nieuw grafisch systeem bedenken?

Nee, uiteraard niet. Videokaart features op 2D gebied veranderen toch amper meer. Maar dus zijn wel enorm verbeterd sinds dat X ontworpen is. Toen hadden ze nog geeneens een videokaart en daar heeft X nu nog steeds problemen mee. IMHO is het een verouderd systeem dat aan vervanging toe is. Das een beetje hetzelfde als de pc zelf. Je kunt wel constant delen sneller blijven maken, maar je blijft met compatabiliteit gekloot zitten (IRC, Isa, etc...). Vandaar ook dat Intel nu met de Itanium een compleet nieuwe architectuur gaat invoeren.

Mwa... valt nogal mee hoor. Als je bijvoorbeeld een browser remote draait, is het tekenen van de widgetset bijvoorbeeld veel lijntjes-werk. Het browsergedeelte zelf is ook een kwestie van een witte achtergrond met een hoop text en een paar plaatjes (meestal dan).

Ja OK, maar tegenwoordig wordt dat steeds minder. Stel je draait een fancy KDE GUI over het netwerk met een pixmap theme dan doe je in feite niets anders dan constant bitmaps oversturen...

Dat wordt waarschijnlijk lastig als daar niet van begin af aan rekening mee gehouden wordt. En dat is precies mijn punt wat ik eerder probeerde te maken.

Vind ik ook, maar ik denk dat ze dat ook wel gaan doen. DirectFB was oorspronkelijk bedoeld om dmv settopboxen TV te kunnen kijken enzo. Maar men is het nu enorm aan het uitbreiden. Kon het vorige week nog slechts 1 applicatie tegelijkertijd draaien, nu kan het alweer meerdere applicaties draaien...
Misschien is Berlin ook een goed alternatief. Ik heb dat zelf eens geprobeert en het was zwar indrukwekkend en technisch superieur aan alles en iedereen, maar helemaal gericht op vector graphics, waardoor alles wat je nu hebt in feite door de plee gespeld kan worden.

Het microkernel design kost bijna altijd wat performance (niet veel als het goed ontworpen en geimplementeerd is), maar het is een veel netter ontwerp, en is mega-stabiel mits juist ontworpen (zie bijvoorbeeld Solaris).

Het gaat er mij helemaal niet om hoe ze het maken, maar dat ze het maken. Dat een GUI in een microkernel snel kan zijn bewijst QNX wel. Moet je voor de grap maar eens proberen, past op 1 diskette. Ik snap dan ook absoluut niet waarom Linux nog niet zoiets in de kernel heeft... In principe maakt het voor de stabiliteit ook geen bal uit hoe je het implementeerd want wil je acceleratie dan zul je drivers nodig hebben die direct met de hardware mogen werken. Dan hangt het van de stabiliteit van de drivers af hoe stabiel je systeem is (nVidia??)

[deadinspace]

Op maandag 19 november 2001 15:56 schreef RG© het volgende:
Videokaart features op 2D gebied veranderen toch amper meer.

Dat is een gevaarlijke uitspraak... '640k should be enough for anyone', remember?

IMHO is het een verouderd systeem dat aan vervanging toe is.

Ja.
Maar wel door een net, efficient en goed systeem dat dezelfde voordelen als X biedt en de nadelen ervan niet heeft.

Ja OK, maar tegenwoordig wordt dat steeds minder. Stel je draait een fancy KDE GUI over het netwerk met een pixmap theme dan doe je in feite niets anders dan constant bitmaps oversturen...

Je hoort het.. geen KDE gebruiken!
Maar dit zal bij een netwerk-transparante implementatie van DirectFB niet anders zijn hoor.