God weet alles, want hij is lid van de Mosad. To protect your freedom i will take that away from you. Mijn drankgebruik heeft ernstig te lijden onder mijn gezondheid.
Anoniem: 73385
Juist NU !
En de nieuwe features zijn, laat me raden:
• Alpha Translucency
• On the fly resolutie veranderingen
• Kleinere footprint
• Wat dies meer zij...
update:
Wel genant om juist op zo'n overduidelijke locatie een spelfout te maken...After tremendous testing and community feedback, the 4.4.0 Release is now available for seveteen (yep that's 17!) popular platforms and with more coming in the ensuing week
Hadden ze misschien tóch meer haast dan ze willen doen overkomen
[ Voor 46% gewijzigd door Anoniem: 73385 op 29-02-2004 22:10 . Reden: update ]
Anoniem: 73385
Wat de inhoud daarvan is kan ik nog niet melden, aangezien xfree86.org lijkt te lijden onder een niet kwaadaardige DoS
de server kent volgens mij wel het onderscheid tussen een main window met windowhandle ed en een popup menu en kan die dus transparant weergeven (onder popup menus valt dus ook dingen als bovenaan in een applicatie)Anoniem: 73385 schreef op 29 februari 2004 @ 20:06:
En hoe weet die server wanneer hij dat moet toepassen ?
Ik neem aan dat niet alles in en uit fade...
en anders geeft hij effectief het hele venster transparant weer (borders kan natuurlijk weer gewoon blijven omdat dat ook door de wm gaat)
in 4.4 zitten niet zo'n spectaculair grote wijzigingen, niks dat dicht in de buurt komt van freedesktop, xouvert of directfb.
een vraag uit het publiek was trouwens of freedesktop niet hetzelfde als xouvert probeerde te bereiken, waarop Keith Packard zei dat xouvert meer research achtige richting opging, minder stabiel ging zijn omdat er sneller en grotere veranderingen werden doorgevoerd dan bij freedesktop die voor een stabiele X gaan maar die wel voldoet aan moderne eisen.
If it ain't broken it doesn't have enough features
12 × LG 330Wp (Enphase) | Daikin FTXM-N 3,5+2,0+2,0kW | Panasonic KIT-WC03J3E5 3kW
Of zie ik dat verkeerd?
Saru mo ki kara ochiru | Even monkees fall from trees | jabber: twbms.ate.jabber.org
Ohw iemand wasmij voor

[ Voor 18% gewijzigd door Erhnam op 01-03-2004 13:18 ]
http://www.xbmcfreak.nl/
Anoniem: 73385
Volgens hun mailinglist zijn ze dood ja...Anoniem: 27915 schreef op 01 maart 2004 @ 05:17:
xouvert lijkt vooralsnog dood... Ik gok vooralsnog op FDO's X server..
Anoniem: 73385
Dat is dan niet zo mooi, die taak zou bij de Windowmanager moeten liggen lijkt mij...de server kent volgens mij wel het onderscheid tussen een main window met windowhandle ed en een popup menu en kan die dus transparant weergeven (onder popup menus valt dus ook dingen als bovenaan in een applicatie)
Anoniem: 27915
Anoniem: 73385
Natuurlijk, je kan het laten weergeven hoe je maar wil, maar in essentie is het beperkend, en bovendien is het het vertroebelen van verantwoordelijkheden.
Wat dat betreft is Fresco een stuk consistenter.
Anoniem: 27915
Anoniem: 73385
Maar wat bedoel je met een window type ?
Impliceert dat dat je dus zelf die types kan ontwerpen, aangezien ze worden onderscheiden door de properties ?
Dus dat de widgets een soort objecten zijn, die de X Server in dit geval zelf construeert (maar dat is logisch gezien voorspelbaar als je die server bepaalde properties voert). Ik heb verder totaal geen verstand van de techniek achter het X protocol hoor, dus hoe die properties exact technisch gezien worden doorgegeven weet ik niet, maar is dit wat je bedoelt ?
Zo niet, verklaar je aub nader
Mijns inziens is Y Windows geen goed alternatief. En wel hierom:
Haha, dat draait een beetje om mijn punt heen. Allicht zal het sneller zijn als alle mogelijke widgets, en dus ook de classes daarvan (afhankelijk van de technische implementatie van die widgets natuurlijk) al in de X Server (Y Server in dit gevalIn-server implementation of widgets
Y specifies a core set of widget classes. Objects of these classes are stored in the server, where they are closer to the user and thus more responsive from the user's point of view.
Het is echter wel inflexibel. Natuurlijk is die inflexibiliteit geen ramp voor real world situaties, de desktopuser geeft er simpelgezegd geen reet om. Maar ja, ik blijf de eeuwige perfectionist
Weer een schijnvoordeel. Natuurlijk is dit mooi en aardig, maar je kunt niet ontkennen dat het symptoombestrijding is, en persoonlijk prefereer ik eerlijkgezegd wat meer structurele oplossingenModularity (plug-in style: dynamically unloadable and reloadable)
Unload an old video driver, load a new version. On the fly. No restart in sight.
Oftewel: X Server en videodriver gescheiden houden. Ik begrijp dat dat mogelijk complicaties geeft, vooral voor de (hardware-) optimalisaties. De videodriver is dan immers niet op de hoogte van de precieze structuur van alle elementen op de desktop (zoals welk window on top ligt etc; zelfs uberhaupt welke windows er zijn). Wat de verdere gevolgen daarvan zijn kan ik ook niet zo uit m'n mouw schudden, ik denk dat iemand als Beelzebubu daar meer over weet te vertellen, met zijn kennis op dit gebied. Het gaat er maar om dat duidelijk is wat ik bedoel.
Is niet meer dan logisch en een vereiste om serieus te worden genomen als alternatief.Consistency and Themeability
Y widgets use the currently loaded theme to render themselves. Since all server widgets are using the same theme, all widgets appear consistent throughout the desktop.
Wat hij hiermee wil zeggen is mij niet geheel duidelijk. Allereerst verwacht ik dat dit reeds het geval is met de themes voor de bekende windowmanagers op XFree86.Client applications can also use the theme's drawing operations, allowing specialised widgets to make themselves fit in with the look-and-feel.
Wat nu precies het voordeel of het bijzondere aan dit is zie ik ook niet in.
Hmm, tja. Is ook al het geval bij XFree86, alhoewel dat veel te wensen over laat , zoals reeds geconstateerd.Support for hardware acceleration
The Y design can make use of hardware acceleration to speed up rendering operations. This can even include the use of 3D-accelerators' textures to draw windows with (someone has already implemented a prototype of this which is very smooth).
Hoe dit technisch precies is geregeld is onduidelijk, maar ik sta iig voor dat de hardwarefabrikant de hardwareoptimalisaties in zijn drivers regelt, niet de auteur(s) van de Y Server. Dit om alles niet wederom spaak te laten lopen, door eventuele bureaucratie bij het team wat aan (in dit geval) de Y Server werkt. Ook lijkt mij dat de mogelijke optimalisaties en/of speciale features per kaart (sterk) verschillen, en dat de fabrikant ook de beste kennis heeft hoe die mogelijkheden zo goed mogelijk te benutten.
Maar ok, dat is weer een heel andere discussie
En wat betekent dat ? Dat zou wel eens tot gevolg kunnen hebben dat je voor iedere taal een apart theme moet maken (en bovenal: de user moet dat weer downloaden/installeren). Dat ligt voor de hand als het om de strings etc gaat, maar de grafische elementen zullen niet zozeer verschillen (meestal).Better internationalisation, localisation, and accessiblity
In-server widgets means there can be exactly one current language, one complex input method system for languages that require them, and one set of accessibility features.
Ook is onduidelijk of je nu wel de taal on-the-fly kunt veranderen. Dat lijkt mij nogal elementair, zeker als je wél de resolutie en zelfs de videodriver op die manier kunt veranderen
Als je themes on-the-fly kunt veranderen, zou dat dus ook met de taal kunnen als dat theming systeem zo elkaar zit als ik nu schets (afgeleid van wat ik begrijp uit de info op die site).
Nu zullen velen zeggen: maar dit is helemaal geen X Server, een Y Server. Ik weet niet precies in hoeverre dit het geval is, naast de andere naam (
Daarom ben ik van mening dat dit project alleen maar meer diversiteit (in negatieve zin) zal zaaien, iets wat niet bevordelijk zal zijn voor de adoptie van een *nix (Linux lijkt vooralsnog de meest kansrijke kandidaat) Desktop voor de normale user.
Als er een oligopolie ontstaat van oplossingen voor die desktop (inclusief alternatieven voor X als Fresco) zullen hardwarefabrikanten waarschijnlijk ook hun vingers niet aan *nix drivers willen branden.
En last but not least is mij onduidelijk of deze Y Server gebruik maakt van het X(11) protocol of niet. Als dat niet het geval is zal dat behoorlijk tegen de Y Server werken, want veel applicaties zijn op X gericht, alleen al de grote (en dus wat meer volwassen) windowmanagers als Gnome en KDE.
Nou, zo kan ik natuurlijk nog wel een hele tijd doorgaan met het puntsgewijs becommentarieren van de technische eigenschappen van die Y Server
Fresco lijkt mij zoals ik al eerder zei erg interessant, maar ik begrijp dat er voorlopig niet naar uit ziet dat dat een succes op grote schaal wordt, niet in de laatste plaats door het onconventionele karakter daarvan (met alle gevolgen van dien)....
Ik mag dan misschien over komen als een pessimist, ik hebt op zich best vertrouwen in een verbeterde X Server zoals die van FreeDesktop.org. Voorlopig houdt ik het daar dan ook maar bij.
Maar ik ben niet bekend met de technische eigenschappen van het X protocol (dat is de enige echte beperking, alhoewel het natuurlijk praktisch erg moeilijk wordt als men grote delen van de fork van XFree86 over moet gaan doen), en kan dus ook niet oordelen over de mogelijkheden en onmogelijkheden daarvan.
[ Voor 2% gewijzigd door Anoniem: 73385 op 02-03-2004 14:59 . Reden: [b]-tags ]
Anoniem: 107036
Tja ik ben nog niet zo'n guru die dat 1,2,3 port.. misschien wel een keer interessant om te bekijken maar ik las al een paar mailings, van iemand die het aan het porteren was naar FreeBSD, met technische opmerkingen die me werkelijk van A tot Z niks zeiden dus ik denk dat ik m'n tijd beter kan besteden aan iets kleinere projectendingstje schreef op 29 februari 2004 @ 17:20:
Waar wacht je nog op? Freebsd Porters Handbook en de sources is all you need
Was er niemand van NOS op FOSDEM die een paar leuke foto's of movies heeft geschoten?
Owja was er op FOSDEM nog gezegt wanneer de eerste echte release uitkomt ?
Anoniem: 73385
Porten voor FreeBSD is trouwens wonderbaarlijk gemakkelijk, alleen wat met de makefile rotzooien, gcc is verkrijgbaar voor FreeBSD dus dat zorgt ervoor dat alles meestal netjes compiled.
Alleen als mensen programma's gaan schrijven die speciaal op Linux gericht zijn (bijv. assumpties over locaties van bepaalde bestanden) dan wil het nog wel eens mis gaan. Vaak zijn de auteurs van dat programma echter wel bereid om een door derden gemaakte kleine patch voor de source te accepteren, dus dat loopt wel los.
[ Voor 2% gewijzigd door Anoniem: 73385 op 02-03-2004 14:55 . Reden: typo ]
Anoniem: 27915
Een keer raden wat X doet.
Ik kijk zo naar je post. Ik heb niet superveel tijd, doe dit tussen de experimenten door, maargoed... Kom d'r zo op terug!
[ Voor 53% gewijzigd door Anoniem: 27915 op 02-03-2004 18:34 ]
Anoniem: 73385
Maar Beelzebubu, ik ben benieuwd naar jouw commentaar op mijn X post, ik neem aan dat jij meer verstand van zaken hebt hieromtrent....
LOL Experimenten
[ Voor 14% gewijzigd door Anoniem: 73385 op 02-03-2004 19:04 ]
Anoniem: 27915
Nee, widgets en types zijn niet zo close gerelateerd. Vanuit Gtk+ gezien (heb ik meer ervaring mee) is bijna elke widget een GdkWindow (abstraction van een XWindow). Nu kun je je voorstellen dat een 'button' en een 'venster' niet hetzelfde zijn. Beiden zijn echter een GdkWindow, en voor de X server dus in zoverre gelijk. Nu heeft elke window een set properties die zijn type aangeven waardoor het eindresultaat er uitziet zoals het er uit ziet. Voorbeelden van zulke properties zijn width, height, parent window (voor embedding), toplevel (zo ja, dan krijgt 'ie een WM border, tenzij andere properties dit weer niet willen), root window (je desktop), etc.Anoniem: 73385 schreef op 01 maart 2004 @ 20:54:
Maar wat bedoel je met een window type ?
Impliceert dat dat je dus zelf die types kan ontwerpen, aangezien ze worden onderscheiden door de properties ?
Dus dat de widgets een soort objecten zijn, die de X Server in dit geval zelf construeert (maar dat is logisch gezien voorspelbaar als je die server bepaalde properties voert). Ik heb verder totaal geen verstand van de techniek achter het X protocol hoor, dus hoe die properties exact technisch gezien worden doorgegeven weet ik niet, maar is dit wat je bedoelt ?
Zo niet, verklaar je aub nader..
Voor de X server is alles een XWindow. Veel meer dna dat weet ze ook niet, want alle drawing operations worden asynchroon uitgevoerd. De opbouw van je desktop werkt dan zo: teken root window, get list of childs, if visible, teken van achter naar voren. En dat dan dus recursief. Elke draw wordt aan de client gerequest, en de client voert dan weer tekenoperaties op de server uit (blit).
De client (Gtk+, de toolkit) is verantwoordelijk voor opbouw van widgets, theming, uiterlijk, dat soort dingen.
Y is niks. Y is zo'n leuk leuter-universiteits-projectje waar niks uit zal komen. [/troll]Mijns inziens is Y Windows geen goed alternatief.
Het is niet sneller! Iedereen denkt dat, maar iedereen verwart runtime code ook met protocol. Het X protocol is ontzettend complex, dat geef ik onmiddelijk toe. Echter, lokaal draait alles via localhost unix sockets en shmem, en dan is er geen snelheidsverlies t.o.v. serverside beeldopbouw. Sure, op details kun je veel verbeteren, maar algemeen genomen is X echt wel goed opgezet.Haha, dat draait een beetje om mijn punt heen. Allicht zal het sneller zijn als alle mogelijke widgets, en dus ook de classes daarvan (afhankelijk van de technische implementatie van die widgets natuurlijk) al in de X Server (Y Server in dit geval) vast staan.
Het punt van protocol vs. runtime code is als volgt: X client (Gtk+) geeft opdracht aan X en die wordt "asynchroon" uitgevoerd door de server. Complex! Bloat! Eng! Oi! NOT! Want in werkelijkheid betekent dit slechts dat ik een bitje door mijn unix socket gooi, de kernel doet op gegeven moment een taskswitch (en die doet 'ie aan de lopende band) en mijn X server leest een bitje. Dit heet asynchroon maar door de manier van taskswitchen in moderne 32bits OS'en is dit in realiteit zo goed als synchroon. En als je - buiten de taskswitch om - kijkt naar de werkelijke operaties die worden uitgevoerd, dan zijn ze hetzelfde.
X kan - wat dit betreft - dus niet langzamer zijn!
Ah welnee joh, dat moet de client doen. Hoe kun je anders meerdere desktops runnen op 1 server?Is niet meer dan logisch en een vereiste om serieus te worden genomen als alternatief.
1
| X -- :1.0 |
Ooit geprobeerd?
Hardware optimilisaties horen alleen om deze reden al in de kernel thuis. Gelukkig snapt het DRM project dat, en volgt nvidia die trend (alhoewel de scheiding tussen X driver/kernel driver daar wat vaag is omdat men niet weet welke wat doet).Hoe dit technisch precies is geregeld is onduidelijk, maar ik sta iig voor dat de hardwarefabrikant de hardwareoptimalisaties in zijn drivers regelt, niet de auteur(s) van de Y Server. Dit om alles niet wederom spaak te laten lopen, door eventuele bureaucratie bij het team wat aan (in dit geval) de Y Server werkt. Ook lijkt mij dat de mogelijke optimalisaties en/of speciale features per kaart (sterk) verschillen, en dat de fabrikant ook de beste kennis heeft hoe die mogelijkheden zo goed mogelijk te benutten.
Taal is een sessie eigenschap; hoe wil je anders taal per sessie op een multi-user OS instellen? Om dat onderdeel te maken van een server is vrij onnozel, de server moet juist door de client gedreven worden om strings te renderen. En wie bepaalt de content van de strings? Juist! De client. Dus moet de client dit soort dingen regelen, niet de server.En wat betekent dat ? Dat zou wel eens tot gevolg kunnen hebben dat je voor iedere taal een apart theme moet maken (en bovenal: de user moet dat weer downloaden/installeren). Dat ligt voor de hand als het om de strings etc gaat, maar de grafische elementen zullen niet zozeer verschillen (meestal).
Ook is onduidelijk of je nu wel de taal on-the-fly kunt veranderen. Dat lijkt mij nogal elementair, zeker als je wél de resolutie en zelfs de videodriver op die manier kunt veranderen...
Als je themes on-the-fly kunt veranderen, zou dat dus ook met de taal kunnen als dat theming systeem zo elkaar zit als ik nu schets (afgeleid van wat ik begrijp uit de info op die site).
Door dit soort functies in de server te integreren maak je het syeteem meer en meer afhankelijk van de specifieke grafische implementatie. Dan krijg je dus iets als win32, waar de UI onderdeel van de base system is. en dat hoort niet. Want mijn terminal moet ook i18n'ized zijn. Vim ook; make ook.
Anyway, again: Y is een unversiteitsprojectje van een student die nog veel moet leren. X is opgezet door de beste mensen ter wereld op de beste opleiding ter wereld. Ik zeg niet dat X perfect is, maar d'r is wel over nagedacht. Veel dingen kunnen beter, maar je moet het niet anders doen om het anders doen, maar om de verbetering. en dat mist Y.
Afgezien van het feit dat ik het alleen maar eens kan zijn met jou verhaal en ik verder dus weinig met Y heb, wil ik toch nog even wat kwijt.Anoniem: 27915 schreef op 02 maart 2004 @ 19:05:
Het is niet sneller! Iedereen denkt dat, maar iedereen verwart runtime code ook met protocol. Het X protocol is ontzettend complex, dat geef ik onmiddelijk toe. Echter, lokaal draait alles via localhost unix sockets en shmem, en dan is er geen snelheidsverlies t.o.v. serverside beeldopbouw. Sure, op details kun je veel verbeteren, maar algemeen genomen is X echt wel goed opgezet.
Het punt van protocol vs. runtime code is als volgt: X client (Gtk+) geeft opdracht aan X en die wordt "asynchroon" uitgevoerd door de server. Complex! Bloat! Eng! Oi! NOT! Want in werkelijkheid betekent dit slechts dat ik een bitje door mijn unix socket gooi, de kernel doet op gegeven moment een taskswitch (en die doet 'ie aan de lopende band) en mijn X server leest een bitje. Dit heet asynchroon maar door de manier van taskswitchen in moderne 32bits OS'en is dit in realiteit zo goed als synchroon. En als je - buiten de taskswitch om - kijkt naar de werkelijke operaties die worden uitgevoerd, dan zijn ze hetzelfde.
X kan - wat dit betreft - dus niet langzamer zijn!
Ik ben met beide protocollen (X en Y) maar een beetje bekend (X meer), maar is het niet zo dat bij Y de data (de bitjes) die de client naar de server stuurt uiteindelijk -minder- is, omdat themes en widgets door de server worden berekend... en de client dus niet meer een hele widget hoeft te sturen naar de server, maar alleen de "vraag" een widget te tonen? (compleet afgezien van het feit, dat ik die benadering lichtelijk krakkemikkig vind)
Zeker over een netwerk zou dat in snelheid schelen toch?
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Anoniem: 27915
Over een netwerk. Maar in 99,9% van de gevallen praten we over lokaal, en Y ondersteunt volgens mij uberhaupt geen network transparency. En lokaal gebruikt X shmem, waarbij server en client dezelfde geheugenadressen gebruiken en er dus geen datacopy plaatsvindt.mOrPhie schreef op 02 maart 2004 @ 19:31:
Ik ben met beide protocollen (X en Y) maar een beetje bekend (X meer), maar is het niet zo dat bij Y de data (de bitjes) die de client naar de server stuurt uiteindelijk -minder- is, omdat themes en widgets door de server worden berekend... en de client dus niet meer een hele widget hoeft te sturen naar de server, maar alleen de "vraag" een widget te tonen? (compleet afgezien van het feit, dat ik die benadering lichtelijk krakkemikkig vind)
Zeker over een netwerk zou dat in snelheid schelen toch?
Anoniem: 73385
Dan is het al stukken beter, maar toch vind ik nog steeds dat de X Server alleen maar met pixmaps ed dient te werken. Maar ok, dat zal wel praktisch onwerkbaar zijn.Nee, widgets en types zijn niet zo close gerelateerd. Vanuit Gtk+ gezien (heb ik meer ervaring mee) is bijna elke widget een GdkWindow (abstraction van een XWindow). Nu kun je je voorstellen dat een 'button' en een 'venster' niet hetzelfde zijn. Beiden zijn echter een GdkWindow, en voor de X server dus in zoverre gelijk. Nu heeft elke window een set properties die zijn type aangeven waardoor het eindresultaat er uitziet zoals het er uit ziet. Voorbeelden van zulke properties zijn width, height, parent window (voor embedding), toplevel (zo ja, dan krijgt 'ie een WM border, tenzij andere properties dit weer niet willen), root window (je desktop), etc.
Hoe bedoel je ?Elke draw wordt aan de client gerequest, en de client voert dan weer tekenoperaties op de server uit (blit).
Ik neem aan dat de client alleen de droge parameters doorgeeft (zoals die XWindows en properties) en dat de X Server daar iets moois van bakt, adhv die properties etc.
Hehe, dat vind jij dus ookquote:
Mijns inziens is Y Windows geen goed alternatief.
Y is niks. Y is zo'n leuk leuter-universiteits-projectje waar niks uit zal komen. [/troll]
Nou ja, ik had geen voorkennis over dat Y, en aangezien er nu zo'n gedonder is rond XFree86 wilde ik ff alle genoemde alternatieven langsgaan.
Wie weet was het nodig dat ik sommigen uit de illusie moest helpen dat Y wat is...
Haha, niet dat ik daar zelf zo stellig van overtuigd was ...Het is niet sneller! Iedereen denkt dat, maar iedereen verwart runtime code ook met protocol. Het X protocol is ontzettend complex, dat geef ik onmiddelijk toe. Echter, lokaal draait alles via localhost unix sockets en shmem, en dan is er geen snelheidsverlies t.o.v. serverside beeldopbouw. Sure, op details kun je veel verbeteren, maar algemeen genomen is X echt wel goed opgezet.
Ik heb er zelfs geen bezwaar tegen als de X Server ook lokaal via het loopback adres communiceert, is snel genoeg hoor.
Ik doelde op consistentie van widgets. Nogal wiedes dat die er altijd en overal hetzelfde uit moeten zienquote:
Is niet meer dan logisch en een vereiste om serieus te worden genomen als alternatief.
Ah welnee joh, dat moet de client doen. Hoe kun je anders meerdere desktops runnen op 1 server?

Dus volgens mij haal je je quotes een beetje door de war
Ik zie nergens iets wat over X Servers vs Clients gaat rondom dat fragment...
Ja hehe, maar het theme is dat ook, en de taal is (in de opzet van de Y Server) een deel van het theme.Taal is een sessie eigenschap; hoe wil je anders taal per sessie op een multi-user OS instellen? Om dat onderdeel te maken van een server is vrij onnozel, de server moet juist door de client gedreven worden om strings te renderen. En wie bepaalt de content van de strings? Juist! De client. Dus moet de client dit soort dingen regelen, niet de server.
Ben ik het zeker mee eens.Anyway, again: Y is een unversiteitsprojectje van een student die nog veel moet leren. X is opgezet door de beste mensen ter wereld op de beste opleiding ter wereld. Ik zeg niet dat X perfect is, maar d'r is wel over nagedacht. Veel dingen kunnen beter, maar je moet het niet anders doen om het anders doen, maar om de verbetering. en dat mist Y.
Wat ik dus nog niet helemaal begrijp aan je post is het client/server verhaal.
Bij mijn weten geeft de X client de 'parameters' door (continu), zoals cursorpositie, input etc. Hieronder zou ook het aantal en de staat van de Xwindow objecten kunnen vallen, of dat momenteel ook zo is weet ik niet maar dat doet ook niet echt ter zake voor de theorie erachter.
De X Server processed die parameters, en output daarbij een 'plaatje', al dan niet in de vorm van een soort pixmap, en displayed die op het scherm van de client. Als die server lokaal draait dan stuurt ie het gegenereerde beeld toch eerst op naar de client, ipv het direct naar het display device te tekenen.
Deze opzet geeft op één punt toch wel te denken. Als je nou de grafische calculaties aan de client over wilt laten, bijvoorbeeld omdat die een veel betere videokaart heeft, kan dat niet zomaar. Ik wil niet zeggen dat je dat moet willen, en dat het een vereiste is dat dit moet kunnen, maar het zou toch wel beter zijn.
Maar hoe bedoel jij bijv. dat de client die widgets van bijv. de GTK tekent
Anoniem: 73385
Dat is inderdaad zo, maar wat hebben we daaraan (zoals je zelf al in twijfel trekt) ?Ik ben met beide protocollen (X en Y) maar een beetje bekend (X meer), maar is het niet zo dat bij Y de data (de bitjes) die de client naar de server stuurt uiteindelijk -minder- is, omdat themes en widgets door de server worden berekend... en de client dus niet meer een hele widget hoeft te sturen naar de server, maar alleen de "vraag" een widget te tonen? (compleet afgezien van het feit, dat ik die benadering lichtelijk krakkemikkig vind)
Zeker over een netwerk zou dat in snelheid schelen toch?
Er valt trouwens maar te bezien hoeveel dat oplevert aan dataverkeer(-besparing), wie weet wel méér, door al die poespas die die maker van plan is te integeren...
Hehe, dat is wél zo, maar niet dat dat het beter zou makenMaar in 99,9% van de gevallen praten we over lokaal, en Y ondersteunt volgens mij uberhaupt geen network transparency.
Volgens mij was dit eerder al door een ander ontzenuwd, bijster veel voordeel zou dat shmem niet opleveren...En lokaal gebruikt X shmem, waarbij server en client dezelfde geheugenadressen gebruiken en er dus geen datacopy plaatsvindt. .
Maar dat maakt niet uit, data via de loopback zenden is echt wel snel zat hoor, responsiveness kun je ook op andere manieren bereiken.
[ Voor 2% gewijzigd door Anoniem: 73385 op 02-03-2004 20:12 . Reden: typo's ]
Anoniem: 27915
Dat doet ze in principe ook, alleen gerenderde pixmaps, en dat noemen we dan drawables.Anoniem: 73385 schreef op 02 maart 2004 @ 20:03:
Dan is het al stukken beter, maar toch vind ik nog steeds dat de X Server alleen maar met pixmaps ed dient te werken. Maar ok, dat zal wel praktisch onwerkbaar zijn.
De client geeft een soort pixmap en de properties door. Denk je nu in dat een window volledig verborgen is achter een andere; deze zal dan niet refreshen als er iets binnen die applicatie gebeurt. De buffer blijft dus "oud", dat scheelt CPU cycles (hey, elke cycle is d'r eentje.Hoe bedoel je ?
Ik neem aan dat de client alleen de droge parameters doorgeeft (zoals die XWindows en properties) en dat de X Server daar iets moois van bakt, adhv die properties etc.
Oooeeee, daar vergis je je in.Ik heb er zelfs geen bezwaar tegen als de X Server ook lokaal via het loopback adres communiceert, is snel genoeg hoor.
Je hebt verschillende types client/server interacties. Je hebt display<->renderer (X server, X client), en je hebt applicatie<->backend (toolkit, X server). Jij noemt nu de eerste, ik ging met name op de tweede in. De eerste werkt grotendeels zoals jij aangeeft.Wat ik dus nog niet helemaal begrijp aan je post is het client/server verhaal.
Bij mijn weten geeft de X client de 'parameters' door (continu), zoals cursorpositie, input etc. Hieronder zou ook het aantal en de staat van de Xwindow objecten kunnen vallen, of dat momenteel ook zo is weet ik niet maar dat doet ook niet echt ter zake voor de theorie erachter.
De X Server processed die parameters, en output daarbij een 'plaatje', al dan niet in de vorm van een soort pixmap, en displayed die op het scherm van de client. Als die server lokaal draait dan stuurt ie het gegenereerde beeld toch eerst op naar de client, ipv het direct naar het display device te tekenen.
Deze opzet geeft op één punt toch wel te denken. Als je nou de grafische calculaties aan de client over wilt laten, bijvoorbeeld omdat die een veel betere videokaart heeft, kan dat niet zomaar. Ik wil niet zeggen dat je dat moet willen, en dat het een vereiste is dat dit moet kunnen, maar het zou toch wel beter zijn.
Maar hoe bedoel jij bijv. dat de client die widgets van bijv. de GTK tekent?
Anoniem: 73385
Ja maar hoe zit de taakverdeling nu precies ?De client geeft een soort pixmap en de properties door. Denk je nu in dat een window volledig verborgen is achter een andere; deze zal dan niet refreshen als er iets binnen die applicatie gebeurt. De buffer blijft dus "oud", dat scheelt CPU cycles (hey, elke cycle is d'r eentje. ). Als de window weer (partially) visible wordt, krijgt 'ie een signaal voor een redraw, zodat de pixmap weer 'vers' is.
Je slaagt er goed bepaalde praktische voorbeelden te geven, maar de theorie erachter begrijp ik zo nog niet direct.
Ja maar een combinatie van datalles is een werkend raderwerk. Hoe zit de verdeling nu precies want ik zie door de bomen het bos niet meer.Je hebt verschillende types client/server interacties. Je hebt display<->renderer (X server, X client), en je hebt applicatie<->backend (toolkit, X server). Jij noemt nu de eerste, ik ging met name op de tweede in. De eerste werkt grotendeels zoals jij aangeeft.
Met theorie bedoel ik natuurlijk niet de technische werking tot in detail, maar gewoon wat nu wat doet en waarom. Niet waarom iets dat doet, in plaats van die ander, daarom en daarom.
[ Voor 3% gewijzigd door Anoniem: 73385 op 03-03-2004 17:39 ]
Anoniem: 27915
• Kort specs over X protocol op X.org zelf: http://www.x.org/X11_protocol.html
• Uitleg, voorbeeldjes: http://www.freesoft.org/CIE/Topics/113.htm
Bedenk dat wat jij een client noemt (display) volgens de specificaties een server heet. De client is datgene die de eigenlijke applicatie runt, de server is datgene die het eindresultaat weergeeft. Beetje verkeerd om.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Persoonlijk vind ik 't verdomd handig, zo met die netwerktransparantie erbij
All my posts are provided as-is. They come with NO WARRANTY at all.
Anoniem: 31357
Handig is het soms wel maar de Windows oplossing dmv "rdesktop" of VNC werkt over een aanzienlijk drukbezet netwerk veel vlotter naar mijn gevoel dan X forwarding. En dat was dacht ik toch wel één van de hoofdredenen van implementatie van de netwerktransparantie, beperkte network load en sneller reageren ipv domweg screenshots over te pompen. Van mijn part mogen ze die droppen, ik ben niet tevreden over het resultaat. Ik ben er geheel niet van overtuigd dat werken dmv localhost met shared mem dezelfde responsiveness oplevert....CyBeR schreef op 03 maart 2004 @ 22:33:
Persoonlijk vind ik 't verdomd handig, zo met die netwerktransparantie erbij
Waarom schuiven venstertjes in Windows anders veeeeeeeeeeel vloeiender over het scherm. (Testcase: P4 met HT 2.6Ghz/800FSB, 512DDR400, ATI Radeon 9200/128DDR) Zowel in Windows als Linux gebruik ik official ATI drivers. In linux de laatste nieuwe FireGL X drivers alle X optimalisaties, nieuwste X versie etc... De beeldopbouw is vrij snel, maar hapert toch wel in Linux, waar in Windows een venster sneller dan het oog lijkt te glijden. Het lijkt wel of er een delay ingebouwd is of een maximum framerate. Ik zou niet weten hoe ik het anders moet omschrijven. Probeer zelf maar eens een venster van pakweg 640x480 snel heen en weer te verslepen op een Windows of Linux desktop op dezelfde hardware.
In het verleden werd er steeds met de vinger naar X gewezen, en hier verkondigen jullie dat het anders moet zijn, wie of wat is dan de schuldige want er is toch wel een duidelijk verschil?
X? Kernel? Drivers? WindowManager? Combinatie van alles? Het moet toch ergens vandaan komen? Vroegers was een argument om Linux te gebruiken dat het sneller draait dan Windows op oudere hardware.... Ik heb geleerd dat de realiteit helemaal anders is wanneer er X aan te pas komt. X vreet geheugen en CPU cycles en dan nog komt het niet in de buurt van de responsiveness van Windows. Spijtig genoeg, maar ik zag in Y toch wel ergens een stap in de goede richting.
Ikzelf heb er geen problemen mee met een Nvidia GF4 Ti4400. Op Linux werkt het zelfs beter dan in Windows; voornamelijk bij het afspelen van DVD's; alles blijft gewoon perfect werken i.t.t. Windows. Volgens mij is het toch echt voornamelijk een driver kwestie. Als je de render extensie geactiveerd hebt en goede drivers werkt het volgens mij echt prima. Als je echter geen goede drivers hebt dan is het huilen met de pet op is mijn ervaring tot nu toe.Anoniem: 31357 schreef op 04 maart 2004 @ 00:00:
[...]
Handig is het soms wel maar de Windows oplossing dmv "rdesktop" of VNC werkt over een aanzienlijk drukbezet netwerk veel vlotter naar mijn gevoel dan X forwarding. En dat was dacht ik toch wel één van de hoofdredenen van implementatie van de netwerktransparantie, beperkte network load en sneller reageren ipv domweg screenshots over te pompen. Van mijn part mogen ze die droppen, ik ben niet tevreden over het resultaat. Ik ben er geheel niet van overtuigd dat werken dmv localhost met shared mem dezelfde responsiveness oplevert....
Waarom schuiven venstertjes in Windows anders veeeeeeeeeeel vloeiender over het scherm. (Testcase: P4 met HT 2.6Ghz/800FSB, 512DDR400, ATI Radeon 9200/128DDR) Zowel in Windows als Linux gebruik ik official ATI drivers. In linux de laatste nieuwe FireGL X drivers alle X optimalisaties, nieuwste X versie etc... De beeldopbouw is vrij snel, maar hapert toch wel in Linux, waar in Windows een venster sneller dan het oog lijkt te glijden. Het lijkt wel of er een delay ingebouwd is of een maximum framerate. Ik zou niet weten hoe ik het anders moet omschrijven. Probeer zelf maar eens een venster van pakweg 640x480 snel heen en weer te verslepen op een Windows of Linux desktop op dezelfde hardware.
In het verleden werd er steeds met de vinger naar X gewezen, en hier verkondigen jullie dat het anders moet zijn, wie of wat is dan de schuldige want er is toch wel een duidelijk verschil?
X? Kernel? Drivers? WindowManager? Combinatie van alles? Het moet toch ergens vandaan komen? Vroegers was een argument om Linux te gebruiken dat het sneller draait dan Windows op oudere hardware.... Ik heb geleerd dat de realiteit helemaal anders is wanneer er X aan te pas komt. X vreet geheugen en CPU cycles en dan nog komt het niet in de buurt van de responsiveness van Windows. Spijtig genoeg, maar ik zag in Y toch wel ergens een stap in de goede richting.
Tja
Anoniem: 31357
All my posts are provided as-is. They come with NO WARRANTY at all.
Anoniem: 27915
Dan mag jij mij bewijzen dat dat hieraan ligt. Totdat je bewijst is hetgeen je hier verkondigt complete onzin.Anoniem: 31357 schreef op 04 maart 2004 @ 00:00:
Ik ben er geheel niet van overtuigd dat werken dmv localhost met shared mem dezelfde responsiveness oplevert....
Het ligt deels aan XFree86, maat nier aan het X protocol. XFree86 heeft veel te weinig optimalisaties op welk front dan ook. Een stukje assembler hier en daar of een code-updateje zou niet verkeerd zijn.In het verleden werd er steeds met de vinger naar X gewezen, en hier verkondigen jullie dat het anders moet zijn, wie of wat is dan de schuldige want er is toch wel een duidelijk verschil?
Vandaar dat ik ook zo veel verwacht van FDO X.
Anoniem: 31357
Mja dat kan ik niet, je hebt gelijk. Ik wou eigenlijk alleen maar de vraag stellen waar het fout loopt. Ik hoop ook stilletjes dat het met FDO beter zal werken, maar daar is het nu nog te vroeg voor spijtig genoeg. Veel heb ik niet te klagen maar het mag van mij zeker sneller gaan als de hardware niet de beperkende factor is, niet?Anoniem: 27915 schreef op 04 maart 2004 @ 16:12:
[...]
Dan mag jij mij bewijzen dat dat hieraan ligt. Totdat je bewijst is hetgeen je hier verkondigt complete onzin.
.
Anoniem: 27915
Okee... We beginnen bij wat men het X protocol noemt. Het is mij compleet onduidelijk welke van de twee client en server zijn, maar ik noem de toolkit altijd de client en de renderer server (zoals op die X protocol plaatjes van x.org in de link die ik hiervoor gaf). Dit is het eigenlijke X protocol. De applicatie, toolkit of wat dan ook heeft hier een set vierkantjes (Drawables of XWindows) die elk een positie, size en data-array hebben. Hierbij horen ook nog een stuk properties die het geheel ingewikkeld maken dus die laat ik lekker weg hier.Anoniem: 73385 schreef op 03 maart 2004 @ 17:39:
Ja maar hoe zit de taakverdeling nu precies ?
De applicatie/toolkit en renderer communiceren via een systeem wat je een beetje moet zien als een messaging systeem als SOAP (SOAP is een XML messaging systeem; het is natuurlijk geen SOAP, want dat bestond toen nog niet, maar dat vind ik wel een goede parallel). Overigens is het X protocol een stuk platter dan SOAP, maar basale XWindow objecten kan je doorgeven. Dit messaging systeem loopt over network of unix sockets (remote vs. lokaal) en is bidirectioneel.
De applicatie/toolkit kan messages naar de server sturen waarin een Drawable verplaatst, geresized wordt of waarin nieuwe data wordt gestuurd naar de Drawable. De server reageert hierop door een nieuw beeldframe te redenderen, en doet dit door recursief Drawables bovenop elkaar te stapelen van achter naar voren (dus Drawables op hetzelfde level worden op zo'n manier gerendered dat eerst de window die half-verborgen is achter een andere fully exposed windown wordt gerendered, en dan pas de fully exposed window) en van top (Root window, je desktop) naar bottom (knopjes in applicaties e.d.). Dit gebeurt allemaal asynchroon. Fully hidden windows worden niet gerendered en hoeven ook geen refresh data naar de server te sturen (immers: geen effectief verschil). De server kan ook messages naar de client sturen voor dit soort doeleinden.
De server rendert, zoals gezegd, Drawables recursief naar het beeldscherm of een tussenbuffer (double buffering). Dit resultaat wordt op het beeldscherm getoond. De server draait dus altijd op de machine met beeldscherm, muis e.d. De client kan op remote (application) servers draaien (en dan praat je dus over remote X). Dit is ook de reden dat rendering op de (X; niet applicatie!
Input devices (joystick, muis, keyboard, drawboards, etc.) werken via dit X protocol en sturen events van de X server naar de X client. De client gebruikt deze om de applicatie hierop te laten reageren (bijvoorbeeld door een tooltip te laten zien of een button op te lichten als de muis eroverheen gaat, etc.).
Zo duidelijk?
Fedora Prepares For Xorg Instead of XFree86
Ziet er naar uit dat de massa toch gaat voor de X van keith...
http://www.xbmcfreak.nl/
Waarschijnlijk is deze fork niet meer dan een tussenstap in de overgang van XFree86 naar de nieuwe FDO Xserver, zolang de laatstgenoemde nog niet uitontwikkeld is en goede driver support heeft.
À vaincre sans péril, on triomphe sans gloire - Pierre Corneille
Ik ben benieuwd wanneer de andere vendors een keuze hebben gemaakt. Lijkt me aan de ene kant niet verkeerd om allemaal hetzelfde alternatief te ondersteunen, echter was dit ook de situatie met XFree86, een alternatief was / is er niet, dus er was ook sprake van een soort "lock-in".
Ik denk dat dit wel een goede ontwikkeling is. Er is zeker nog wat werk nodig aan de FDO Server, dus een tussentijds alternatief lijkt me niet verkeerd. En men kan richting integratie met een nieuwe X Server werken.
Everyone complains of his memory, no one of his judgement.
Anoniem: 73385
Fedora is dan ook een "proefjes"-distributie
@Beezlebubu:
Aangezien het icoontje in MyReact geel bleef, dacht ik dat je geen reactie meer had gepost
Ik zal zo spoedig mogelijk reageren, bedankt voor de moeite iig
Vooruitstrevendheid betekent niet proefjes, imo. Ze zijn gewoon moedig om als eerste een 'nieuwe standaard' te adapteren.
Everyone complains of his memory, no one of his judgement.
Anoniem: 73385
Ik wist niet zo snel een Nederlands equivalent te vinden
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Anoniem: 27642
maar er zitten meer "kappote" dingen in dat dingen die werken.
Zo is er b.v. nog niet eens support voor GLX. of DRI. (of enkel minimaal eigen kleine hacks. maar de modules zelf zijn nog lang niet te compilen. (tot en met missende includes
naast kdrive zijn ze nu ook al begonnen aan het poorten van xizzle.
maar uiteraard niet verwachte dat die werkt ofzo. (het was zelfs zo erg dat ik twee directories en files moest aanmaken omdat de complete xserver anders niet wou compilen. (flb_fixed,flb_first uit mijn hoofd en daar een makefile.in in die hij toch niet gebruikte)))
xserver is nu leuk speelgoed. maar ik zou het eigenlijk nog niet eens beta software noemen.
(voor de rest heb ik overgenst geen verstand van de interne werking van X'n of een complete kennis van FDO's xserver. dus wat ik hier zeg is puur ervaring van de afgelopen week)
Anoniem: 73385
Je begint weer een uitgebreide technische beschrijving te geven van wat er in de praktijk allemaal gebeurt
Maakt niet uit, je bent nogal bevlogen natuurlijk van je werk uit
Dat document waar je naar linkte is al heel verhelderend, ik lees mezelf wel wat beter in
Client: Widgets, skinning, core-messages ontvangen van xserver, X-messages terugsturen naar X-Server.Anoniem: 73385 schreef op 19 maart 2004 @ 17:39:
Je begint weer een uitgebreide technische beschrijving te geven van wat er in de praktijk allemaal gebeurt..
Server: Recursief renderen, tonen en updaten van X-Windows aangeboden door een client, core-messages doorsturen naar client, hardware-accelleratie.
Zoals het verhaal van beelzebubu al doet vermoeden komt er veel meer bij kijken, maar jij wilt een simpele taakverdeling, hier hebbie 'm.
Om het verhaal niet offtopic te doen laten gaan: Omdat zaken zoals transculentie en alpha-blending rekening moet houden met alle clients getoont op het scherm, zoals motif, QT, java, GTK, ooO (en dus niet alleen z'n eigen haggie moet redden
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
1
2
3
4
5
6
7
8
9
10
11
| x/xfree86-4.4.0-i486-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-devel-4.4.0-i486-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-docs-4.4.0-noarch-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-docs-html-4.4.0-noarch-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-fonts-100dpi-4.4.0-noarch-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-fonts-cyrillic-4.4.0-noarch-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-fonts-misc-4.4.0-noarch-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-fonts-scale-4.4.0-noarch-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-xnest-4.4.0-i486-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-xprt-4.4.0-i486-1.tgz: Upgraded to XFree86 4.4.0. x/xfree86-xvfb-4.4.0-i486-1.tgz: Upgraded to XFree86 4.4.0. |
Volledige changelog
Zou dit ermee te maken hebben dat slackware eigenlijk alleen maar 'vanilla' sources compileert? Dus eigenlijk niet zoveel wijzigt aan de sourcecode? Of is het alleen maar omdat XFree de enige technisch afdoende en stabiele oplossing is?
Anoniem: 27915
Thanks.Anoniem: 73385 schreef op 19 maart 2004 @ 17:39:
Maakt niet uit, je bent nogal bevlogen natuurlijk van je werk uit...
Dat document waar je naar linkte is al heel verhelderend, ik lees mezelf wel wat beter in...
Mjah, de X mensen hebben meerdere malen herhaald dat de libs (dus datgene waar je naartoe linkt als applicatie) niet onder de nieuwe licentie vallen. Alleen de server (die standalone runt) valt daar momenteel onder. Dus er is momenteel nog geen "echte" reden om over te stappen behalve de combinatie van "puurheid" willen en een soort van aversie tegen de praktijken. Puurheid moge duidelijk zijn: Debian zal nooit XFree86 4.4 shippen. Aversie lijkt me ook duidelijk, met name vanuit RedHat en Suse: zij "gebruiken" opensource als een soort drijfbootje naar geld, en de filosofie van de nieuwe X licentie past daar niet tussen. Nogal logisch dat zij liever de fork van X 4.4-rc2 gebruiken, of anders de FDO X server.Quasily schreef op 25 maart 2004 @ 01:30:
Slackware gaat wel XFree 4.4.0 gebruiken. Quote uit de changelog van slackware-current:
[..]
Zou dit ermee te maken hebben dat slackware eigenlijk alleen maar 'vanilla' sources compileert? Dus eigenlijk niet zoveel wijzigt aan de sourcecode? Of is het alleen maar omdat XFree de enige technisch afdoende en stabiele oplossing is?
X.Org Foundation Releases X Window System X11R6.7
X.Org Foundation today announced their first release of the X Window System since the formation of the Foundation in January of this year. The new X.Org release, called X Window System Version 11 Release 6.7 (X11R6.7), builds on the work of the X.Org X11R6.6 and XFree86 Project Inc.
Ziet er dus naar uit dat de gehele fork nu eindelijk zijn vruchten gaat afwerpen.
Verder: http://www.xwin.org/Software/XDevConf
Met leuke presentaties:
Current presentations for the X Developer's Meeting include:
Keith Packard and Jim Gettys: "The (Re)Architecture of the X Window System"
Deron Johnson & Hideya Kawahara "Looking Glass"
Dave Reed & Dave Smith: "Croquet: Integrating X with 3D Immersive Environments"
Eamon Walsh: ""Fine-grained Access Control for X"
Owen Taylor: The Widget Toolkit Developer's Perspective on X
Current discussions and/or hacking sessions include:
The big picture of X and a plan to get the necessary pieces done (Stuart Anderson)
Network security and X (Jim McQuillan and Ted T'so).
What can be learned from Longhorn and OS/X? (Jon Smirl)
X on OpenGL (Keith Packard and Jon Smirl)
Dat wordt
http://www.xbmcfreak.nl/
Anoniem: 4417
Met die zin wordt wellicht het idee geschept dat Keith Packard de schuld heeft aan de fork. Laat duidelijk zijn dat we juist die weinige opvallende verbeteringen in XFree86 aan hem te danken hebben!deadinspace schreef op 24 maart 2003 @ 22:32:
Toen Packard op eigen houtje zonder overleg met de rest van het team een bepaald deel van XFree86 aanpaste is hij uit het XFree86 core team gezet.
De schuld van het gebeuren ligt dus niet bij Keith Packard (die zichzelf uiteindelijk genoodzaakt zag om Xfree86 te verlaten), maar bij David Dawes, die zich al jaren gedraagt als een elitaire klootzak. Ik vind het lullig om dit van iemand te zeggen, maar het is waar.
Ergens heeft Dawes met zijn arrogantie juist voor iets goeds gezorgd: anders was de community waarschijnlijk blijven aanrommelen met XFree86. Het nieuwe X.org-initiatief geeft daarentegen een zeer grote impuls aan de hele community om met prachtige innovaties te komen wat betreft de meest gebruike user interface onder Linux (en andere Unix-varianten)!
[ Voor 4% gewijzigd door Anoniem: 4417 op 22-04-2004 17:19 ]
Anoniem: 73385
Hehe, goed?
Als die Dawes niet zo arrogant was, was er uberhaupt geen aanrommeling, waarvan de negatieve gevolgen door een fork teniet zouden kunnen worden gedaan.
Hehe, wel grappig zo'n stelling, een soort van dubbel-gelaagde paradox.
[ Voor 7% gewijzigd door Anoniem: 73385 op 22-04-2004 19:04 ]
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Anoniem: 73385
edit:
Ah I understand, verradelijke zin.
Lees het deel rondom "waarvan" nog maar eens aandachtig...
[ Voor 63% gewijzigd door Anoniem: 73385 op 23-04-2004 15:17 . Reden: update ]
Affin, back ontopic
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Anoniem: 51493
Op FOSDEM beweerde meneer Packard dat meneer Dawes zijn eigen licentie in de XFree86 source verspreide dmv zijn code daaronder te laten vallen. Dat samen met de paranoia-praat welke meneer Dawes verspreid ("een groot complot") en tenslotte de vooruitstrevende ontwikkelingen van FD.O leidt bij mij tot de conclusie "mazzel XFree86!".Anoniem: 4417 schreef op 22 april 2004 @ 17:18:
Met die zin wordt wellicht het idee geschept dat Keith Packard de schuld heeft aan de fork. Laat duidelijk zijn dat we juist die weinige opvallende verbeteringen in XFree86 aan hem te danken hebben!
Anoniem: 4417
Ik vind het nog steeds frappant dat David Dawes kennelijk de enige is die openbaar namens het XFree86-project mag spreken. Is die man een dictator of zo? Waarom horen we nauwelijks iets van de andere ("niet-dissidente") XFree86-ontwikkelaars?Anoniem: 51493 schreef op 23 april 2004 @ 18:12:
[...]
Op FOSDEM beweerde meneer Packard dat meneer Dawes zijn eigen licentie in de XFree86 source verspreide dmv zijn code daaronder te laten vallen. Dat samen met de paranoia-praat welke meneer Dawes verspreid ("een groot complot") en tenslotte de vooruitstrevende ontwikkelingen van FD.O leidt bij mij tot de conclusie "mazzel XFree86!".
http://freedesktop.org/Software/XDevConf/LG-Xdevconf.pdf
[ Voor 24% gewijzigd door Erhnam op 30-05-2004 15:52 ]
http://www.xbmcfreak.nl/
Anoniem: 27915
Omdat niet elke hacker een goede publieke spreker is.Anoniem: 4417 schreef op 25 april 2004 @ 12:47:
Ik vind het nog steeds frappant dat David Dawes kennelijk de enige is die openbaar namens het XFree86-project mag spreken. Is die man een dictator of zo? Waarom horen we nauwelijks iets van de andere ("niet-dissidente") XFree86-ontwikkelaars?
À vaincre sans péril, on triomphe sans gloire - Pierre Corneille
grrrrr dan mag ATI nu langzamerhand wel eens drivers gaan releasen voor X.orgThe_Surfer schreef op 31 mei 2004 @ 18:30:
BTW, Slackware (de enige grote distro die XFree 4.4 gebruikte) is nu ook overgestapt naar X.org (zie http://osnews.com/comment.php?news_id=7210). Ik denk dat we XFree onderhand wel dood kunnen verklaren
There is no such thing as innocence, only degrees of guilt | Flickr!
Wat is het probleem? De ATI (XFree 4.3) drivers werken perfect in X.org. Het schijnt zelfs dat ze beter werken dan in XFree 4.4:Zym0tiC schreef op 31 mei 2004 @ 22:57:
[...]
grrrrr dan mag ATI nu langzamerhand wel eens drivers gaan releasen voor X.org
Patrick Volkerding:
I also noticed that the ATI Radeon binary drivers designed for XFree86 4.3.0 do not work with XFree86 4.4.0, but do work with the X.Org release.
À vaincre sans péril, on triomphe sans gloire - Pierre Corneille
Doel je hiermee op de referentie naar de Composite-extention in het XServer gedeelte? De verwijzing naar Keith zie ik namelijk nergens.Erhnam schreef op 30 mei 2004 @ 15:45:
Ik kreeg laatst een slide van SUN onder mijn ogen. Blijkbaar werken ze samen Keith mee aan de implementatie van de SUN Glass desktop.
http://freedesktop.org/Software/XDevConf/LG-Xdevconf.pdf
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
1. Ze werken niet helemaal perfect. Vanaf XFree 4.4 RC2 ofzo (dus ook in X.org) heb ik het probleem dat de Xvideo niet werkt, of alleen in het begin. Is een bekend probleem, met meerdere drivers (ook de SiS dingen geloof ik). Dit probleem zit trouwens net zo goed in XFree 4.4The_Surfer schreef op 01 juni 2004 @ 08:00:
[...]
Wat is het probleem? De ATI (XFree 4.3) drivers werken perfect in X.org. Het schijnt zelfs dat ze beter werken dan in XFree 4.4:
[...]
2. Het probleem met XFree 4.4 was redelijk triviaal op te lossen door ergens in een Xversion.h o.i.d. te zeggen dat het om XFree 4.4 RC5 ging ofzo, dan werkte het allemaal net zoals in X.org.
Verandert z'n sig te weinig.
Weer een tijdje geleden maar iedereen weet dat X.org 6.8.2 er aan zit te komen.
Candidate 2 is uit:
http://cvs.freedesktop.or...RG-6_8-branch&view=markup
Voor de mensen die het leuk vinden om te testen:
Een howto hoe je de laatste CVS aan de praat krijgt en up2date houdt!
http://www.neowin.net/for...php?showtopic=204593&st=0

Wie heeft er nog nieuwe updates?
[ Voor 15% gewijzigd door Erhnam op 14-01-2005 15:19 ]
http://www.xbmcfreak.nl/
Anoniem: 31491
bron
http://www.ati.com/suppor...&submit.y=11&submit=GO%21
Heeft iemand ze al getest?
[P5B deluxe] [Core2Duo 6300] [2 X 1GB DDR2] [GF FX7300] [320 GB WD] [Gentoo] [VISTA]
Er zou toch een versie 7.0 komen waarin grote delen van de oude X Server herschreven zouden worden ?
Want nu is X.Org niet veel meer dan XFree86 met een paar extra extensies ... (toch ?)
Als het goed is wordt in de nieuwe X.org de hele boel netjes gemodulariseerd. X.org is zeker meer dan een fork van XFree86 met wat extra's. Op het moment wordt vooral nagedacht over de toekomst van de architectuur rond X zelf. Ze zitten daar heus niet stilKLEI_j0s schreef op maandag 17 januari 2005 @ 22:24:
Hoe zit het nou met de nieuwe X.org
Er zou toch een versie 7.0 komen waarin grote delen van de oude X Server herschreven zouden worden ?
Want nu is X.Org niet veel meer dan XFree86 met een paar extra extensies ... (toch ?)
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
Anoniem: 27915
freedesktop.org repositories... Heb jij een url voor mij? Ben wel benieuwd!Anoniem: 27915 schreef op maandag 17 januari 2005 @ 23:19:
Jullie bedoelen KDrive? Da's de opvolger van X.org waar Keith Packard en dergelijke aan werken. Flink alpha, maar te volgen via de freedesktop.org repositories. Enkelen durvals hier op GoT hebben het geloof ik zelfs draaien...
http://www.xbmcfreak.nl/
Nog wat kleine probleempjes in de laatste releases. Ziet er naar uit dat het allemaal wat langer op zich laat wachten.
http://www.xbmcfreak.nl/
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
💶 Wil je in een vrije democratie blijven wonen? Betaal dan voor nieuws. 📰
❌ ceterum censeo contra factiones ad dextrum extremum esse pugnandum. 🙅🏻♂️
Tzt komt x.org om debian. Maar reken maar niet dat het vlot zal zijn. debian's eigen patches op Xfree86 maken het retestabiel en x.org zal voorlopig te unstable zijn om zelf in debian "unstable" een plekje te vinden.ucchan schreef op woensdag 26 januari 2005 @ 14:06:
Misschien een open deur, maar weet iemand of x.org ook tzt in debian gaat komen..?
Volgens mij was het een bewuste keuze X.org niet in debian op te nemen voor het helemaal gemodulariseerd is, omdat er anders veel overbodig werk gebeurt.Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 00:15:
Wat een gelul.. Debian is simpelweg te traag, en da's niet voor 't eerst...
micheljansen.org
Fulltime Verslaafde Commandline Fetisjist ©
Getuige de vele discussies hieromtrend op de x.org mailinglist, is het nog helemaal niet zeker dat X.org modular gaat worden. Er zijn nog veel voorstanders van de monolitic tree en veel verschillende meningen over een een modular x.org. En als het modular gaat worden, zal dat zoveel werk gaan kosten, dat met het aantal developers nu, het nog wel een tijdje zal duren voordat de modular-release het daglicht ziet. Misschien praten we dan over R6.9 of wellicht zelfs R7. R7 zal immers ingrijpende veranderingen ondergaan en een modular tree past daarom in dat rijtje thuis.dawuss schreef op donderdag 27 januari 2005 @ 00:26:
[...]
Volgens mij was het een bewuste keuze X.org niet in debian op te nemen voor het helemaal gemodulariseerd is, omdat er anders veel overbodig werk gebeurt.
Of dat dus de exacte reden is waarom debian nog niet is overgestapt op X.Org betwijfel ik dus. Ik ga nog steeds mee met de theorie van beelzebubu.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
De reden waarom Dabian nog niet is overgegaan is omdat er nog te veel veranderingen en wijzigingen plaatsvinden op de x.org tree, met gevolg dat er nog te veel issues en bugs in de tree zitten... (zie de blogs/planet) Dabian vernieuwt onderdelen pas als gebleken is dat ze echt stabiel zijn. Ik verwacht dat ze niet tijden lang kunnen achterblijven (omdat andere onderdelen gnome/kde wel vooruit gaan) en op een bepaald moment moeten ze wel een versie uit de tree accepten. Deze zouden ze dan eventueel zelf kunnen verbeteren met patches om zo meer stabiliteit te brengen.mOrPhie schreef op donderdag 27 januari 2005 @ 00:58:
[...]
Getuige de vele discussies hieromtrend op de x.org mailinglist, is het nog helemaal niet zeker dat X.org modular gaat worden. Er zijn nog veel voorstanders van de monolitic tree en veel verschillende meningen over een een modular x.org. En als het modular gaat worden, zal dat zoveel werk gaan kosten, dat met het aantal developers nu, het nog wel een tijdje zal duren voordat de modular-release het daglicht ziet. Misschien praten we dan over R6.9 of wellicht zelfs R7. R7 zal immers ingrijpende veranderingen ondergaan en een modular tree past daarom in dat rijtje thuis.
Of dat dus de exacte reden is waarom debian nog niet is overgestapt op X.Org betwijfel ik dus. Ik ga nog steeds mee met de theorie van beelzebubu.
http://www.xbmcfreak.nl/
http://blogs.sun.com/roll...50125#xorg_6_8_2_release1
Overige newsbronnen:
http://planet.freedesktop.org/
http://www.technorati.com/tag/Xorg
[ Voor 31% gewijzigd door Erhnam op 27-01-2005 10:56 ]
http://www.xbmcfreak.nl/
Beetje offtopic, maar waarom zou Debian nou weer te traag zijn?Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 00:15:
Wat een gelul.. Debian is simpelweg te traag, en da's niet voor 't eerst...
Omdat alles binary is?
[ Voor 7% gewijzigd door DeMoN op 27-01-2005 13:18 ]
Gamertag: Cosmicv0id
"Het woord Gods is voor mij niets meer dan een expressie en het product van menselijke zwakheid. De Bijbel is een verzamelwerk van legendes die achtenswaardig zijn maar ook primitief en kinderachtig.'' - Albert Einstein
Trager != snelheid.DeMoN schreef op donderdag 27 januari 2005 @ 13:17:
[...]
Beetje offtopic, maar waarom zou Debian nou weer te traag zijn?
Omdat alles binary is?
Dabian is wat 'trager' op het gebied van vernieuwing. Ze geven de voorkeur aan stabiliteit boven vernieuwing. Om die reden nemen ze niet het nieuwste van het nieuwste op in hun tree's en zijn dus wat trager met het oppakken van de laatste releases.
http://www.xbmcfreak.nl/
omg, ja dat weet ik.. verkeerd opgevat en dat zelfs na het hele topic gelezen te hebben.Erhnam schreef op donderdag 27 januari 2005 @ 13:26:
[...]
Trager != snelheid.
Dabian is wat 'trager' op het gebied van vernieuwing. Ze geven de voorkeur aan stabiliteit boven vernieuwing. Om die reden nemen ze niet het nieuwste van het nieuwste op in hun tree's en zijn dus wat trager met het oppakken van de laatste releases.
* DeMoN gaat koffie halen
Gamertag: Cosmicv0id
"Het woord Gods is voor mij niets meer dan een expressie en het product van menselijke zwakheid. De Bijbel is een verzamelwerk van legendes die achtenswaardig zijn maar ook primitief en kinderachtig.'' - Albert Einstein
Anoniem: 27915
Volgens mij haal je een aantal dingen enorm gruwelijk door elkaar. De blogs die je aanhaalt, gaan over de CVS versie van X.org, evenals de "vele veranderingen in de tree". Dat is een goed iets, dat geeft namelijk aan dat het project actief ontwikkeld wordt. En inderdaad, dan kan er veel instabiliteit inkruipen. Daarom zul je weinig gekken vinden die CVS draaien.Erhnam schreef op donderdag 27 januari 2005 @ 09:28:
De reden waarom Dabian nog niet is overgegaan is omdat er nog te veel veranderingen en wijzigingen plaatsvinden op de x.org tree, met gevolg dat er nog te veel issues en bugs in de tree zitten... (zie de blogs/planet) Dabian vernieuwt onderdelen pas als gebleken is dat ze echt stabiel zijn. Ik verwacht dat ze niet tijden lang kunnen achterblijven (omdat andere onderdelen gnome/kde wel vooruit gaan) en op een bepaald moment moeten ze wel een versie uit de tree accepten. Deze zouden ze dan eventueel zelf kunnen verbeteren met patches om zo meer stabiliteit te brengen.
Daarom heeft men het fantastische moderne concept van releases uitgevonden. Zo is er bijvoorbeeld een X.org release gedaan, welke keurig goed werkt op bijvoorbeeld Fedora. Die release zou evenzogoed in Debian kunnen. Echter, Debian wil graag compatibiliteit behouden (legacy) met XFree86, en wil daarom graag met een generiek provides-systeem gaan werken. Dit betekent feitelijk dat je XFree86 en X.org beiden kan draaien en dat een van beiden genoeg is om als depends: voor enig ander pakket te dienen zonder intern te conflicteren. Dat blijkt echter niet zo makkelijk. Fedora is simpelweg overgestapt (de simpele approach).
Dat Debian moeilijk doet is begrijpelijk, ze supporten een enorme tyfuszooi aan vage obscure hardware, maar consequentie blijft staan: ze zijn traag.
XGL: Draai X met een opengl backend:
http://lists.freedesktop....2004-November/004358.html
http://nat.org/2005/february/
source:
http://cvs.freedesktop.org/xserver/xserver/hw/xgl/
Goede blogs:
http://www.technorati.com/tag/Xorg
http://blog.drinsama.de/erich/en/linux
http://planet.freedesktop.org/
[ Voor 21% gewijzigd door Erhnam op 10-02-2005 09:34 ]
http://www.xbmcfreak.nl/
Overigens is Xgl verre van ideaal. De complete output wordt naar een fullscreen glx-window gegooit. Dit is te verhelpen natuurlijk, maar heeft als nadeel dat hij een eigen custom windowmanager heeft moeten hacken.
Ik heb het toentertijd ook geprobeerd te builden, maar heb het na 3 avonden klooien opgegeven.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Mja, is Xorg net zo portable naar alle architecturen waar debian op verkrijgbaar is als de huidige XFree86 4.3.0 dat is op dit moment?Anoniem: 27915 schreef op donderdag 27 januari 2005 @ 16:12:
[...]
Volgens mij haal je een aantal dingen enorm gruwelijk door elkaar. De blogs die je aanhaalt, gaan over de CVS versie van X.org, evenals de "vele veranderingen in de tree". Dat is een goed iets, dat geeft namelijk aan dat het project actief ontwikkeld wordt. En inderdaad, dan kan er veel instabiliteit inkruipen. Daarom zul je weinig gekken vinden die CVS draaien.
Daarom heeft men het fantastische moderne concept van releases uitgevonden. Zo is er bijvoorbeeld een X.org release gedaan, welke keurig goed werkt op bijvoorbeeld Fedora. Die release zou evenzogoed in Debian kunnen. Echter, Debian wil graag compatibiliteit behouden (legacy) met XFree86, en wil daarom graag met een generiek provides-systeem gaan werken. Dit betekent feitelijk dat je XFree86 en X.org beiden kan draaien en dat een van beiden genoeg is om als depends: voor enig ander pakket te dienen zonder intern te conflicteren. Dat blijkt echter niet zo makkelijk. Fedora is simpelweg overgestapt (de simpele approach).
Dat Debian moeilijk doet is begrijpelijk, ze supporten een enorme tyfuszooi aan vage obscure hardware, maar consequentie blijft staan: ze zijn traag..
Wat betreft het provides systeem: ik zie problemen bij debian als ze xorg en xfree86 tegelijk gaan supporten: Xorg heeft een paar nieuwe libraries en extenties waar programma's tegen gaan linken. Deze programma's werken dan niet meer op de oude XFree86. Op Archlinux hebben we dat hacky opgelost door gewoon die libs uit Xorg te lichten en in de XFree86 tree te patchen en vervolgens een rebuild te doen. Alle maintainers bakken tegen Xorg, terwijl arme zieluge ATi users destijds aan XFree86 vast zaten.
http://www.xbmcfreak.nl/
Torrentje: klik
Changelog: http://x.org/XOrg_Press_Releases/X11R6.8.2.html
Ziet er uit dat het vooral een paar bugfixes zijn
À vaincre sans péril, on triomphe sans gloire - Pierre Corneille
http://linuxreviews.org/features/3ddesktop/
3d-desktop:
http://fedoranews.org/tchung/3ddesktop/
http://desk3d.sourceforge.net/



http://www.xbmcfreak.nl/
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
http://www.xbmcfreak.nl/
Om dit aan te zetten:
http://gentoo-wiki.com/TIP_Xorg_X11_and_Transparency
Xgl ontwikkelingen!
[ Voor 40% gewijzigd door Erhnam op 01-03-2005 16:32 ]
http://www.xbmcfreak.nl/
Mensen moeten hun mailinglists en documentatie beter lezen.
Er was ooit een probleem met composite, dat OpenGL-applicaties composite deden crashen. Deze vrij nieuwe optie heeft dit probleem opgelost. Dit heeft echter helemaal _niets_ met Xgl te maken.
Xgl is een interpratie van X11 naar OpenGL. Hierdoor ontstaat een heavy geaccellereerde XServer die op dit moment niets meer is dan een fullscreen GLX-window in een bestaande X11-Server. Gezien de vele discussies op de mailinglists is wel te veronderstellen dat een hoop mensen interesse hebben in de techniek. Dat is waarom developers nu bezig zijn met "GL" als ware backend voor x.org te gaan implementeren. Hiervoor zal waarschijnlijk GLX ontzien worden en een apart iets bedacht worden (of al bedacht zijn?). GLX richt zich namelijk op windows binnen een X11-implementatie, terwijl het doel is de hele X-Server met opengl-technieken te renderen. De echte mogelijkheden zijn mij nog niet precies duidelijk, maar dat de mogelijkheden waarschijnlijk koel zijn voor het oog is een ding wat zeker is.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Anoniem: 27915
Om dat aan te vullen. Arthur, de painting-engine van Qt 4.0, zal zeer waarschijnlijk ook cairo gaan ondersteunen, naast OpenGL en Xlib.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Alleen zonder glitz is cairo 10x trager. Maar glitz is nog een library die bovenop X11 draait zoals beelzebubu al zei..mOrPhie schreef op dinsdag 01 maart 2005 @ 21:55:
Helemaal mee eens beelzebubu. Ik heb verschillende gtkcairo-dingen gecompileerd om te testen en ik ben zeer onder de indruk. Cairo gaat zeker een belangrijke innovatie in X betekenen.
Om dat aan te vullen. Arthur, de painting-engine van Qt 4.0, zal zeer waarschijnlijk ook cairo gaan ondersteunen, naast OpenGL en Xlib.
Hoewel: Cairo backends
[ Voor 5% gewijzigd door BoAC op 02-03-2005 08:04 ]
Ik houd de maillinglists van XFree86 niet bij en heb dus geen idee wat er zo "terrific" aan is. Eén ding is zeker: Ik ben best wel benieuwd naar de details.Solid like a Rock: 4.5.0 goes Live
It is on our website and ready to download. 4.5.0 was born yesterday and the delivery I hear wa smooth. Get a copy now. It's just terrific....details to follow.
Een experimentele community-site: https://technobabblenerdtalk.nl/. DM voor invite code.
Have a taste of freedom. It is sometimes a bitter pill. To me though, this is the sweetness of the GPL
K00l Luminocity OpenGL Videos
http://www.gnome.org/~seth/blog/xshots


http://www.gnome.org/~set...ey-hoot/WobblyWindows.avi
http://www.gnome.org/~set...ot/WorkspaceSwitching.avi
http://www.gnome.org/~set...key-hoot/MovieOfMovie.avi
http://www.gnome.org/~set...ot/TransparentWindows.avi
http://www.gnome.org/~seth/blog/relations
http://galaxy.osnews.com/email.php?blog_id=672
http://www.xbmcfreak.nl/
Heb ik vandaag ook toevallig gezien via gnomedesktopErhnam schreef op donderdag 24 maart 2005 @ 09:50:
Hele zooi fancy stuff! Spinnende windows, Draaiende desktops met filmpjes spelend rechts onderin het overzicht! Dit mag je niet missen:
K00l Luminocity OpenGL Videos
http://www.gnome.org/~seth/blog/xshots
[afbeelding]
[afbeelding]
http://www.gnome.org/~set...ey-hoot/WobblyWindows.avi
http://www.gnome.org/~set...ot/WorkspaceSwitching.avi
http://www.gnome.org/~set...key-hoot/MovieOfMovie.avi
http://www.gnome.org/~set...ot/TransparentWindows.avi
http://www.gnome.org/~seth/blog/relations
http://galaxy.osnews.com/email.php?blog_id=672
Ik denk dat deze fancy 'toys' niet geschikt zijn voor de gewone desktop omdat het vermoeiend is, maar voor presentatie-doeleinden zeker interessant