KDE-ontwikkelaars willen Wayland-windowmanager ondersteunen
De ontwikkelaars van de KDE-desktopomgeving willen stapsgewijs de Wayland-windowmanager gaan ondersteunen. In 2012 zou de KDE-interface volgens de nieuwe plannen op de vermoedelijke opvolger van X.org Server moeten draaien.
Het Wayland-project is nog verre van voltooid, maar moet volgens de ontwikkelaars op termijn een oplossing gaan bieden voor een aantal zwakke punten van de X.org Server-windowmanager, zoals de traag verlopende doorontwikkeling van X11 en een verouderde architectuur waardoor onder andere geavanceerde compositing-mogelijkheden ontbreken. Onder andere Ubuntu-ontwikkelaar Canonical en Fedora hebben ondersteuning voor de Wayland-displayserver in toekomstige Linux-versies toegezegd, terwijl Intel overweegt om Wayland te gaan gebruiken voor Touch UX 1.3.
Inmiddels kan KDE aan dat rijtje worden toegevoegd: op de Desktop Summit in Berlijn heeft KDE-ontwikkelaar Martin Gräßlin aangegeven dat ook zij de Wayland Display Server willen toepassen, zo meldt Phoronix. Dit moet stapsgewijs gaan gebeuren: een werkgroep gaat onder de naam 'KWin Lighthouse project' de KDE-code aanpassen voor het lichtgewicht Wayland. In de zomer van 2012 zou de geplande KDE 4.9-release moeten draaien op de nieuwe windowmanager. De daaropvolgende periode moet er vooral aan de stabiliteit van de omgeving worden gewerkt.
Gräßlin waarschuwde de Wayland-ontwikkelaars om niet dezelfde fouten te maken die bij de introductie van de audiodeamon PulseAudio op het Linux-platform enkel jaren geleden zijn gemaakt. Door een groot aantal bugs die maar met moeite werden weggewerkt, bezorgde PulseAudio bij veel gebruikers de nodige hoofdpijn. Verder is het nog wachten op voldoende driversupport van onder andere Nvidia en ATI om zo de op OpenGL gebaseerde windowmanager bruikbaar te maken.
Reacties (72)
"The more, the better" is mijn eerste reactie. Maar als ik terugkijk op de problemen dat het bij Ubuntu opleverde toen ze overstapten van Gnome 2 naar Unity (zie ook de reacties in nieuws: Canonical brengt Ubuntu 11.04 uit ) hoop ik dat ze bij KDE wat rustiger zullen integreren.
Je praat nu wel over twee heel vershillende dingen, namelijk een desktop-manager en de acherliggende display-server.
De eerste heeft heel veel invloed op het gebruik, de tweede zal op het eerste gezicht voor een gebruiker geen verschil uitmaken.
De eerste heeft heel veel invloed op het gebruik, de tweede zal op het eerste gezicht voor een gebruiker geen verschil uitmaken.
Die verwarring heeft waarschijnlijk zijn oorsprong in het artikel zelf, aangezien men hier Wayland een 'windowmanager' noemt, terwijl het een 'displayserver' is.
X11 heeft op vandaag geen enkel alternatief - wil je een desktoppc op linux, dan hang je vast aan X11, dat iirc nu 25 jaar oud is. Tijd voor een moderne oplossing, tijd voor Wayland!
X11 heeft op vandaag geen enkel alternatief - wil je een desktoppc op linux, dan hang je vast aan X11, dat iirc nu 25 jaar oud is. Tijd voor een moderne oplossing, tijd voor Wayland!
Dat iets 25 jaar oud is, maakt het niet slecht. Het concepts van wielen onder een auto (nah ja, voertuig, vroeger waren het koetsen e.d.) is al vele duizenden jaren oud. Het voldoet nog steeds prima.
Puur leeftijd is dus geen argument.
Puur leeftijd is dus geen argument.
De wielen voldoen nog steeds omdat we nog niks beters hebben dan wielen. Tegen de tijd dat we massaal krachtvelden en anti-gravitatie gaan toepassen zullen de wielen een heel eind passé zijn heb ik zo'n vermoeden.
Je moet dus wel kijken of er iets beters voorhanden is en Wayland zal wanneer het verder is uitgewerkt wellicht beter zijn dan X11.
Ik weet daarom niet of de vergelijking met wielen wel zo treffend is. Sowieso zal op de langere termijn wel blijken waar de meeste animo voor is en welke daardoor zal overleven.
Je moet dus wel kijken of er iets beters voorhanden is en Wayland zal wanneer het verder is uitgewerkt wellicht beter zijn dan X11.
Ik weet daarom niet of de vergelijking met wielen wel zo treffend is. Sowieso zal op de langere termijn wel blijken waar de meeste animo voor is en welke daardoor zal overleven.
Het wiel bestaat al lang, net als een displaymanager. Zie waylan dan als een wiel met lichtmetalen velgen en rubber banden.
Het is net zo rond als een houten wiel maar ik denk dat je het verschil wel degelijk merkt.
Correct me if i'm wrong ik heb niet veel linux ervaring
Het is net zo rond als een houten wiel maar ik denk dat je het verschil wel degelijk merkt.
Correct me if i'm wrong ik heb niet veel linux ervaring
Momenteel heb je X11: waar "xclients" hun vensters kunnen tonen WIndow Managers geven daar hun venster control randje omheen. Dat alles wordt getoont op de Xserver wat het display aanstuurt.
En je hebt directfb: veel minder omslachtig van X een applicatie die direct de framebuffer aanspreekt.
Nu is er Wayland daar spreken applicaties allemaal naar hun eigen buffer en Wayland verwerkt dat tot een beeld..
Het is dus totaal iets anders!
En je hebt directfb: veel minder omslachtig van X een applicatie die direct de framebuffer aanspreekt.
Nu is er Wayland daar spreken applicaties allemaal naar hun eigen buffer en Wayland verwerkt dat tot een beeld..
Het is dus totaal iets anders!
Ik zie wayland meer als een fietsband die ze onder een auto proberen te steken. Het is veel te beperkt. Ik zou met dat soort onzin alleen maar functionaliteit verliezen. Zoals het kunnen draaien van grafische programma's via ssh. Ik denk dat je het verschil vooral zult merken in het niet meer kunnen doen van dingen die je vroeger wel kon, en het hele systeem meer als Windows aan gaat voelen: beperkt, gemaakt voor simpele gebruikers die alleen maar browsen en mailen...
hoewel ik je hier voor een deel gelijk in geeft, moet je je wel wat dingen afvragen voor je dit als slecht bestempeld...
1 - hoe nuttig is een remote x client nog ano 2011 waar elke pc sterk genoeg is voor het verwerken van desktop taken... - we leven immers niet meer in een terminal server tijdperk..
2 - wat is meer waard remote x, of snelle beeldverwerking
3 - waarom is vnc / rdp niet goed genoeg om die xorg features over te nemen.
- ja er zijn wat featuers in org die wellicht beter voor jouw zijn dan waylan... x-over-ssh is wat mij betreft net zo obsolete als win 3.11
1 - hoe nuttig is een remote x client nog ano 2011 waar elke pc sterk genoeg is voor het verwerken van desktop taken... - we leven immers niet meer in een terminal server tijdperk..
2 - wat is meer waard remote x, of snelle beeldverwerking
3 - waarom is vnc / rdp niet goed genoeg om die xorg features over te nemen.
- ja er zijn wat featuers in org die wellicht beter voor jouw zijn dan waylan... x-over-ssh is wat mij betreft net zo obsolete als win 3.11
Da's onzin natuurlijk.
1) Omdat thin clients nog steeds veel gebruikt worden. Waarom denk je dat applicatievirtualisatie zo hot is tegenwoordig? Omdat je i7-processor het dan makkelijker heeft? Nee, voor bedrijven zijn thin clients nog steeds erg interessant. En wat Linux betreft komt de LTSP (Linux Terminal Server Project) steeds verder in de ontwikkeling.
2) Dat ligt aan het gebruik en de applicaties die je draait.
3) VNC is te traag, RDP is niet public (denk ik; weet ik niet zeker!!). Althans, de Microsoft-invulling van RDP is niet zomaar beschikbaar.
1) Omdat thin clients nog steeds veel gebruikt worden. Waarom denk je dat applicatievirtualisatie zo hot is tegenwoordig? Omdat je i7-processor het dan makkelijker heeft? Nee, voor bedrijven zijn thin clients nog steeds erg interessant. En wat Linux betreft komt de LTSP (Linux Terminal Server Project) steeds verder in de ontwikkeling.
2) Dat ligt aan het gebruik en de applicaties die je draait.
3) VNC is te traag, RDP is niet public (denk ik; weet ik niet zeker!!). Althans, de Microsoft-invulling van RDP is niet zomaar beschikbaar.
Thin clients zijn een duidelijk voorbeeld van systemen waarbij het theoretische voordeel van X11 (remote windowing) volstrekt overbodig blijkt: je thin client haalt z'n hele desktop van de remote server, niet een paar windows. Dat betekent dat de desktop compositing ook niet meer lokaal hoeft, en dus kan de client nog thinner.
*zucht*
Wat wordt ik toch altijd moe van al die analogieën.
Zijn we nu allemaal echt zo lomp dat we de abstracte IT niet kunnen bevatten zonder het elke keer maar te vergelijken met huizen, autos, winkels, enz?
Wat wordt ik toch altijd moe van al die analogieën.
Zijn we nu allemaal echt zo lomp dat we de abstracte IT niet kunnen bevatten zonder het elke keer maar te vergelijken met huizen, autos, winkels, enz?
Wayland wordt niet beter dan X11 sterker nog x11 zal er gewoon naast blijven draaien voorlopig!
Punt is Wayland doet dingen anders. Bijvoorbeeld programma´s als x2go zullen met Wayland alleen niet meer kunnen! Om dit soort truuks te bewerkstelliggen moet je ingewikkeld en traag programeren en het maakt X11 ook traag!
De ontwikkelaars van Wayland hebben dit ook al toegegeven, simpel weg Wayland heeft andere prioriteiten en daarmee voordelen maar zeker weten ook tekortkomingen!
Punt is Wayland doet dingen anders. Bijvoorbeeld programma´s als x2go zullen met Wayland alleen niet meer kunnen! Om dit soort truuks te bewerkstelliggen moet je ingewikkeld en traag programeren en het maakt X11 ook traag!
De ontwikkelaars van Wayland hebben dit ook al toegegeven, simpel weg Wayland heeft andere prioriteiten en daarmee voordelen maar zeker weten ook tekortkomingen!
Voor een simpele desktop of notebook is Wayland een goede oplossing, minder complex als X11, echter met X11 kunnen ook weer dingen die Wayland niet kan en nooit zal kunnen, zoals het aansturen van een scherm op een ander systeem. applicatie op de het ene systeem (gedeelde) applicatieserver, venster op het andere (desktop/X11-) systeem.
The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
http://wayland.freedesktop.org/
http://wayland.freedesktop.org/
AFAIK is Wayland beide. Bij X11 is het nog zo dat de client naar de X11 server stuurde wat hij getekend wou hebben. Vervolgens werd dit door X11 daadwerkelijk getekend. Door de latere compositing extension kon het gerenderde deel vervolgens bij een window manager terecht komen die vervolgens alles op het scherm samenvoegde (evt. met effecten). Bij Wayland gaat dit anders. De applicatie tekent zichzelf (via OpenGL ES) waarna die aan "Wayland" door geeft waar in de videokaart "zijn weergave" staat. Vervolgens kan "Wayland" dit op het scherm tekenen, effecten op toepassen, etc.
De reden dat ik over "Wayland" spreek is dat Wayland zoals het nu is meer een testomgeving is (voor zover ik begrepen heb). Wayland is een protocol (op XML gebaseerd) en "de server" kant hoort daarbij rechtstreeks in de window manager geïmplementeerd te worden.
De reden dat ik over "Wayland" spreek is dat Wayland zoals het nu is meer een testomgeving is (voor zover ik begrepen heb). Wayland is een protocol (op XML gebaseerd) en "de server" kant hoort daarbij rechtstreeks in de window manager geïmplementeerd te worden.
Na het KDE 4.0-fiasco zullen ze het inderdaad wel HEEL rustig aan gaan doen, neem ik aan.
Als ik zo lees dat Ubuntu en Fedora X11 willen gaan vervangen door Wayland, en ik aan de zijkant als gerelateerd bericht zie staan dat nvidia geen plannen heeft voor ondersteuning, is er eigenlijk maar 1 ding wat in me opkomt... De eerste mongolische distro die het in z'n kop haalt om er voor te zorgen dat ik niet meer kan gamen is de eerste die ik van m'n systemen af knal en er nooit meer op komt. Niet iedereen is tevreden met trage nouveau drivers zonder goede 3d support...
offtopic:
En dat Ubuntu moet al helemaal oppassen na me geïrriteerd te hebben met Unity... gelukkig kun je daar nog voor Gnome kiezen op dit moment. Fedora 15 was ik ook niet zo blij mee, maar de "classic" mode in Gnome 3 bevalt me op zich wel.
En dat Ubuntu moet al helemaal oppassen na me geïrriteerd te hebben met Unity... gelukkig kun je daar nog voor Gnome kiezen op dit moment. Fedora 15 was ik ook niet zo blij mee, maar de "classic" mode in Gnome 3 bevalt me op zich wel.
Grappig dat een KDE ontwikkelaar verwijst naar Pulseaudio. Ik herinner mij dat dit juist de fout is die KDE had gemaakt door versie 4 veel te vroeg uit te brengen met behoorlijk wat bugs waardoor veel naar Gnome zijn overgestapt.
KDE 4.0 en 4.1 waren nooit bedoeld voor de eindgebruiker. Spijtig genoeg zijn er veel mensen die daar anders over dachten met alle gevolgen vandien.
Daar zijn de meningen over verdeeld. Noem het dan geen 4.0 met een hele marketing campagne er achter (voor onafhankelijk open source begrip erg groots)
Wat KDE wilde was distributies zowel 3.5 als 4.0 meeleverden, zodat gebruikers alvast met 4.0 konden spelen en op 3.5 terug konden vallen voor het echte werk. Alleen OpenSuSE heeft dat gevolgd en is pas vrij laat naar 4.x als standaarddesktop overgestapt.
De hoeveelheid werk die met het ondersteunen van 2 versies gepaard gaat, was voor veel distributies reden dat niet te doen. Bovendien werd 3.5 amper nog ondersteund door het KDE-team. Er is nog een 3.5.10 gekomen, maar het werk dat daaraan gedaan werd was wel zo minimaal dat er voor een distributie weinig businesscase was om nog 3.5 aan te bieden.
4.0 heeft wel het gewenste effect bereikt: Veel gebruikers probeerden het. Helaas beviel het allesbehalve en moesten er ook nog eens meer wijzigingen gedaan worden dan waar het KDE-team op gehoopt had.
Alles bij elkaar kan je stellen dat enerzijds de taktiek om met een 4.0-versie meer gebruikers te laten testen een kapitale blunder is geweest: Enerzijds was de versie nog te slecht voor algemeen gebruik, anderzijds had er veel erder terugkoppeling van gebruikers moeten wezen om de ontwikkeling de goede kant op te leiden.
De hoeveelheid werk die met het ondersteunen van 2 versies gepaard gaat, was voor veel distributies reden dat niet te doen. Bovendien werd 3.5 amper nog ondersteund door het KDE-team. Er is nog een 3.5.10 gekomen, maar het werk dat daaraan gedaan werd was wel zo minimaal dat er voor een distributie weinig businesscase was om nog 3.5 aan te bieden.
4.0 heeft wel het gewenste effect bereikt: Veel gebruikers probeerden het. Helaas beviel het allesbehalve en moesten er ook nog eens meer wijzigingen gedaan worden dan waar het KDE-team op gehoopt had.
Alles bij elkaar kan je stellen dat enerzijds de taktiek om met een 4.0-versie meer gebruikers te laten testen een kapitale blunder is geweest: Enerzijds was de versie nog te slecht voor algemeen gebruik, anderzijds had er veel erder terugkoppeling van gebruikers moeten wezen om de ontwikkeling de goede kant op te leiden.
Ook, maar de eerste versies van PulseAudio.. zeg tegen elke hardcore liinux gebruiker "PulseAudio (vroege build string)" en grote kans dat hij/zij in tranen uitbarst...
Onder anderen ik.. pulseaudio was om te huilen.. heel veel incompatibileit met applicaties.. en stottrende audio.. hoog cpu gebruik.. memory leaks.. crashes etc..Ook, maar de eerste versies van PulseAudio.. zeg tegen elke hardcore liinux gebruiker "PulseAudio (vroege build string)" en grote kans dat hij/zij in tranen uitbarst...
Dat lag echter niet aan PulseAudio maar aan brakke drivers die de specificaties niet volgden. Dankzij PA zijn de bugs in die drivers naar boven gekomen en gefixt.
Ik moet eerlijk zeggen dat ik onder gentoo de pulseaudio use-flag ook consequent uit heb staan. Onder ubuntu heb ik het gezien, en ik word er warm noch koud van. Stotteren, ruisen, vastlopers, vage en verwarrende instellingen, om nog niet eens te spreken van het feit dat je het er niet eens 100% uitgehakt krijgt.
Bah, bah, driewerf bah.
Voorlopig kom ik er in Gentoo door creatief gebruik van alsa software mixer icm gstreamer een aardig eind uit
Edit: Ohja, ook wel relevant: Ik ben een fervente KDE-gebruiker.
Bah, bah, driewerf bah.
Voorlopig kom ik er in Gentoo door creatief gebruik van alsa software mixer icm gstreamer een aardig eind uit
Edit: Ohja, ook wel relevant: Ik ben een fervente KDE-gebruiker.
[Reactie gewijzigd door Hadron op zondag 7 augustus 2011 19:59]
vraagje ik heb ubuntu draaien hierzo. In het begin met gnome en vlc en pulse wat probleemjes gehad. Dit was simpel op te lossen ik heb ubuntu nu op 3 pc´s draaien met alsa en Pulse audio en draait toch echt als een zonnetje?
Dat is geen vraag...
En het zal ook heus voor een hoop mensen wel werken, anders zou niemand het in hun distro willen hebben, maar voor een hoop andere mensen werkt het niet of voor 90%.
En het zal ook heus voor een hoop mensen wel werken, anders zou niemand het in hun distro willen hebben, maar voor een hoop andere mensen werkt het niet of voor 90%.
Ben toen gewoon maar bij Alsa gebleven Wel zo handig met mijn Creative kaartjes.
Is er trouwens al software om de X-Fi te besturen? (Zoals Crystalizer en dergelijken)
Wel zo handig met mijn Creative kaartjes.Is er trouwens al software om de X-Fi te besturen? (Zoals Crystalizer en dergelijken)
Pulseaudio zit nog steeds vol met bugs. Zelfs in Fedora 15 loop ik nog tegen issues met storing aan als ik bepaalde programma's gebruik. Ik heb audacious, die hiervoor prima werkte in pulse, nu weer terug moeten zetten naar alsa, en met wine is het nog nooit bruikbaar geweest.
In F14 had ik veel willekeurige skips tijdens het spelen van muziek in gstreamer met pulse. Dit ben ik gelukkig in F15 nog niet tegen gekomen. Oude bugs eruit, nieuwe bugs erin?
Ik heb echt niks tegen pulse, vind het concept prima (welke andere audiosystemen kunnen bv zo goed om gaan met netwerkaudio? ik ken er geen), maar al die bugs geven het zo'n nare nasmaak... iedere distro-upgrade kan ik weer kijken wat er deze keer wel en niet werkt met pulse
In F14 had ik veel willekeurige skips tijdens het spelen van muziek in gstreamer met pulse. Dit ben ik gelukkig in F15 nog niet tegen gekomen. Oude bugs eruit, nieuwe bugs erin?
Ik heb echt niks tegen pulse, vind het concept prima (welke andere audiosystemen kunnen bv zo goed om gaan met netwerkaudio? ik ken er geen), maar al die bugs geven het zo'n nare nasmaak... iedere distro-upgrade kan ik weer kijken wat er deze keer wel en niet werkt met pulse
Ik herken heel goed de bugs uit de vroege versies van Pulse, maar nu toch al een aantal jaren geen problemen meer mee op mijn 2 systemen, noch heb ik daar 2 Ubuntu gebruikende collega's over gehoord.
screenshots; http://wayland.freedesktop.org/screenshots.html
maar goed, plaatjes zeggen totaal niets; performance maakt 't verschil de 'beleving' op de enduser
maar goed, plaatjes zeggen totaal niets; performance maakt 't verschil de 'beleving' op de enduser
[Reactie gewijzigd door himlims_ op zondag 7 augustus 2011 16:15]
Sterker nog, ik zou in eerste instantie niet een het verschil willen zien tussen een KDE op X.org en KDE op Wayland. Bij gebruik zou ik het wel willen merken in vooral snelheid, het al-dan-niet synchroom lopen van videobeelden en op langere termijn het toevoegen van features die op X.org niet of met moeite mogelijk zijn.
Niet mee eens. Ik merk duidelijk bijvoorbeeld OS-X (Finder) minder snel is dan Windows Explorer maar omdat Windows vooral hangt wanneer het bezig is lijkt het trager.
Ook het verschil tussen Firefox en Chrome.
Wanneer iets trager lijkt maakt het niet zozeer uit wat er nou sneller is, ermee werken voelt fijner als het sneller lijkt.
Ook het verschil tussen Firefox en Chrome.
Wanneer iets trager lijkt maakt het niet zozeer uit wat er nou sneller is, ermee werken voelt fijner als het sneller lijkt.
[Reactie gewijzigd door Wolfos op zondag 7 augustus 2011 23:21]
Mooi een nieuwe windowmanager is zeker nodig en zoals er staat hopelijk zonder PulseAudio drama.
PulseAudio is verre van drama, het probleem is legacy toepassingen die in mindere mate compatibel zijn met Pulse. Met PulseAudio kun je bijvoorbeeld geheel netwerktransparant audio devices op een andere computer aanspreken alsof die in je eigen computer zitten. Vertel mij maar eens met welke andere audio server op welk platform dan ook dat mogelijk is.Mooi een nieuwe windowmanager is zeker nodig en zoals er staat hopelijk zonder PulseAudio drama.
[Reactie gewijzigd door cumulus007 op zondag 7 augustus 2011 17:13]
Is dat, ironisch genoeg, niet een feature die Wayland niet over zal nemen van X11? Netwerktransparanite.Met PulseAudio kun je bijvoorbeeld geheel netwerktransparant audio devices op een andere computer aanspreken alsof die in je eigen computer zitten
Dat zal me een biet zijn, zolang ik vanaf mijn laptop muziek kan afspelen op mijn Linux-mediacenter met PulseAudio door eenvoudigweg het mediacenter als geluidsuitvoer te kiezen, ben ik tevreden.
Als je alleen naar audio kijkt wel ja...
Zeker geen ssh gebruiker? Hoe ga ik met Wayland ooit een grafisch programma via ssh kunnen draaien? Ik vind dat hele Wayland een stap terug. Functionaliteit die Linux voor mij een beter systeem maken dan Windows, laten ze gewoon vallen.
Verder snap ik ook niet wat er in Xorg ontbreekt aan "geavanceerde compositing mogelijkheden" als ik zie wat compiz allemaal kan...
Zeker geen ssh gebruiker? Hoe ga ik met Wayland ooit een grafisch programma via ssh kunnen draaien? Ik vind dat hele Wayland een stap terug. Functionaliteit die Linux voor mij een beter systeem maken dan Windows, laten ze gewoon vallen.
Verder snap ik ook niet wat er in Xorg ontbreekt aan "geavanceerde compositing mogelijkheden" als ik zie wat compiz allemaal kan...
Hoeveel mensen denk je dat er zijn die grafische programma's (whatever that may be) over SSH gebruiken? Ik denk dat dat er bijzonder weinig zijn. Daarnaast is een SSH tunnel met een remote desktop tool natuurlijk ook zo opgezet 
Grafische programma's.... Alle programma's die niet vanop de commandline lopen dus. En niet alleen over SSH, maar ook gewoon zonder tunnels als terminals in een lokaal netwerk. Iets dat met de huidige automatiseringstrends juist steeds populairder wordt.
vnc - rdp protocollen tellen dus niet mee?? en zijn ook niet effcienter door gebruik van modernere technieken??? - [/sarcasme]
VNC blijft wat achter, RDP is bewezen degelijk en efficient. Ik draai dat zelf inderdaad ook over een SSH-tunnel en met mij tientallen klanten. In de MS-wereld is dat dus een oplossing die absoluut niet over het hoofd gezien mag worden, dus goed dat je hem noemt.
Echter is RDP native MS, het ligt wat minder voor de hand om dat in een linuxomgeving te gaan draaien omdat iemand zo nodig X eruit wilde gooien.
Wel is het zo dat X op zijn beurt ook weer achterblijft op RDP, maar of je dat gaat oplossen door een nog minder efficient systeem in te voeren?
Echter is RDP native MS, het ligt wat minder voor de hand om dat in een linuxomgeving te gaan draaien omdat iemand zo nodig X eruit wilde gooien.
Wel is het zo dat X op zijn beurt ook weer achterblijft op RDP, maar of je dat gaat oplossen door een nog minder efficient systeem in te voeren?
[Reactie gewijzigd door mae-t.net op maandag 8 augustus 2011 17:55]
Zeker geen SSH gebruiker? Ik heb toch al heel wat machines beheert via SSH en beheer er momenteel ook aardig wat, maar aan grafische meuk daarvoor weinig behoefte gehad.
Los daarvan, voor hele desktops moeten ze wel iets regelen, weet niet of dat er wel in zit.
Los daarvan, voor hele desktops moeten ze wel iets regelen, weet niet of dat er wel in zit.
Ik heb zelf ook al herhaaldelijk nut gehad uit X11 forwarding, dus hoop dat ze die display buffers kunnen forwarden via SSH uiteindelijk ofzo.
En met compositing, X heeft er zat problemen mee, bijvoorbeeld met dual monitor + Xinerama.
En met compositing, X heeft er zat problemen mee, bijvoorbeeld met dual monitor + Xinerama.
Een displaybuffer forwarden via SSH zal netwerk vréten. Werkt vast nog wel in een glasvezelkantooromgeving. Thuiswerken bye bye.
Het klassieke probleem is dat je een displaybuffer bij elke wijziging moet versturen. Protocollen als RDP en VNC optimaliseren dat door de wijzigingen te comprimeren, iets wat erg efficient is omdat de meeste wijzigingen klein zijn. Een extra letter zijn een paar honderd pixels, geen miljoen.
X11 heeft als probleem dat je niet makkelijk kunt uitvissen wat de wijzigingen zijn. Dat betekent dat je compressiealgoritme lastiger is. Een nieuw project als Wayland zal dat beter aanpakken - remote desktops zijn nu een stuk beter begrepen dan 25 jaar geleden.
X11 heeft als probleem dat je niet makkelijk kunt uitvissen wat de wijzigingen zijn. Dat betekent dat je compressiealgoritme lastiger is. Een nieuw project als Wayland zal dat beter aanpakken - remote desktops zijn nu een stuk beter begrepen dan 25 jaar geleden.
Xinerama is verouderd en afgeraden, gebruik gewoon xrandr als je meerdere schermen wil...
Je kan je afvragen af je daarvoor de schuld moet leggen bij die legacy applicaties of de euvelen hoort de wijten aan de vernieuwzucht die nu eenmaal bij open source hoort. Niet dat ik dat afkeur, maar ik heb linux gebruiker weleens momenten gehad dat ik me besefte dat zelfs windows 98 de basisfuncties voor consumenten beter deed.
Als je hele audiosysteem omvalt, glitches vertoont, cpu slurpt bij het leven en applicaties gewoon geen geluid willen produceren dan kan netwerktransparantie van audio devices je niet zo heel erg boeien
Inmiddels gaat het gelukkig weer beter qua audio in de linuxwereld.
Als je hele audiosysteem omvalt, glitches vertoont, cpu slurpt bij het leven en applicaties gewoon geen geluid willen produceren dan kan netwerktransparantie van audio devices je niet zo heel erg boeien
Inmiddels gaat het gelukkig weer beter qua audio in de linuxwereld.
toch als ik een kde applicatie en firefox youtube filmpje afspeel weigert de kde applicatie geluid af te spelen omdat de device bezig is.. of andersom.. ik speel een nummer in een kde applicatie of hij staat gewoon open en speelt niks weigert firefox/flash een youtube filmpje geluid af te spelen...helaas...Je kan je afvragen af je daarvoor de schuld moet leggen bij die legacy applicaties of de euvelen hoort de wijten aan de vernieuwzucht die nu eenmaal bij open source hoort. Niet dat ik dat afkeur, maar ik heb linux gebruiker weleens momenten gehad dat ik me besefte dat zelfs windows 98 de basisfuncties voor consumenten beter deed.
Als je hele audiosysteem omvalt, glitches vertoont, cpu slurpt bij het leven en applicaties gewoon geen geluid willen produceren dan kan netwerktransparantie van audio devices je niet zo heel erg boeien
Inmiddels gaat het gelukkig weer beter qua audio in de linuxwereld.
Dat komt eenvoudigweg door de gebrekkige implementatie van PulseAudio onder KDE. De geluidsmixer KMix is waardeloos vergeleken met GNOME's variant, het geluidssysteem Phonon van KDE zorgt alleen maar voor meer verwarring.
Ik denk dat de implementatie van pulseaudio bij sommige distros(*hint*kubunt*hint*) gewoon waardeloos was, op Mandriva bv liep alles veel soepeler met dank aan Colin Guthrie voor zijn werk aan kmix en pulseaudio en Helio Castro voor het werk aan kmix. Trouwens als je een bug indiende bij pulseaudio was Lennart Poettering ook nooit te beroerd om te zoeken naar een oplossing....
[Reactie gewijzigd door Madame Jeanette op zondag 7 augustus 2011 17:59]
Als er iets hier out-of-the-box wel werkte op mijn Arch Linux met KDE 4.7 was het wel het geluid. Eerlijk gezegd: toen ik zag dat er pulseaudio werd binnengehaald hield ik mijn adem in. Maar het werkt perfect.
Hoe recent is jouw KDE ervaring en met welke versie was dat?
Hoe recent is jouw KDE ervaring en met welke versie was dat?
De meeste problemen die aan PulseAudio verweten werden vielen in één van de volgende 2 categorieën:Je kan je afvragen af je daarvoor de schuld moet leggen bij die legacy applicaties of de euvelen hoort de wijten aan de vernieuwzucht die nu eenmaal bij open source hoort.
- Bestaande toepassingen die ALSA verkeerd gebruikten, en ook niet werkten met Bluetooth audio bijvoorbeeld. Een veelgemaakte fout daarbij was dat programma's er van uit gingen dat bepaalde optionele driver-functies altijd bestaan ipv eerst de driver-functie aan te roepen die je vertelt of dat ook echt zo is.
- Bugs in audio-drivers die vroeger niet zichtbaar waren omdat niemand de drivers op die manier gebruikte (de meeste programma's gebruikten maar een fractie van de ALSA API, PulseAudio gebruikt die intens).
[Reactie gewijzigd door Filip Maurits op maandag 8 augustus 2011 18:48]
Dat was meer dan 10 jaar geleden al mogelijk met esound..[...]
Vertel mij maar eens met welke andere audio server op welk platform dan ook dat mogelijk is.
http://en.wikipedia.org/wiki/Enlightened_Sound_Daemon
En esound is niet voor niks verdwenen... wat een k*zooi was dat. Als je audio minder dan een seconde achterliep had je geluk. Realtime was een concept waar dat esound nog nooit van had gehoord, en video afspelen via esound wilde je al helemaal niet aan beginnen.
Niet dat dat arts van kde zoveel beter was... dat hield gewoon je device non-stop bezet, ook als je niks afspeelde, zodat alle non-arts applicaties, en dat waren er nogal wat, niks meer met je audio hardware konden.
Hoeveel issues waren er wel niet waarvoor "disable esound/arts" de oplossing was? Ben blij dat die narigheid over is. Als ze nou de bugs eens uit pulse halen komen we nog ergens...
Niet dat dat arts van kde zoveel beter was... dat hield gewoon je device non-stop bezet, ook als je niks afspeelde, zodat alle non-arts applicaties, en dat waren er nogal wat, niks meer met je audio hardware konden.
Hoeveel issues waren er wel niet waarvoor "disable esound/arts" de oplossing was? Ben blij dat die narigheid over is. Als ze nou de bugs eens uit pulse halen komen we nog ergens...
Voor zover ik weet, doet jack niks met netwerk audio, en is het voornamelijk gericht op professionele realtime audio productie waar een paar extra milliseconden lag belangrijker worden geacht dan processorgebruik of de desktop use-case waar je tig programma's door elkaar hebt draaien die iets met je audiokaart willen.
Volgens mij is jack een prima laag om onder pulse te steken, maar in z'n eentje is het niet zo geschikt voor de standaard huis-, tuin- en keukendesktop. Voornamelijk omdat het gros van de applicaties geen jack output ondersteund.
Volgens mij is jack een prima laag om onder pulse te steken, maar in z'n eentje is het niet zo geschikt voor de standaard huis-, tuin- en keukendesktop. Voornamelijk omdat het gros van de applicaties geen jack output ondersteund.
Wayland is geen windowmanager.
Ik weet niet waarom ze in het artikel de term erbij hebben bedacht.
IceWM en Metacity zijn windowmanagers.
Ik weet niet waarom ze in het artikel de term erbij hebben bedacht.
IceWM en Metacity zijn windowmanagers.
Pulse was ehm... "leuk" inderdaad. Ik denk wel dat ze daar nu wel voor op gaan letten iets over een ezel en een steen. Hoewel de mensen die hier werk in stoppen niet allemaal dezelfden zullen zijn zal zo'n debacle niet meteen vergeten worden denk ik 
Ik ben het wel eens met de redenering van 84hannes; zo'n switch wil je niet dat het effect visueel is, maar dat de performance en features beter worden.
Ik ben het wel eens met de redenering van 84hannes; zo'n switch wil je niet dat het effect visueel is, maar dat de performance en features beter worden.
ligt het aan mij of is wayland geen windowmanager? dacht dat het de server was waarop een windowmanager kan draaien, net als X. maar correct me if i'm wrong
Je hebt gelijk, dit is inderdaad een fout in het artikel.
Niet correct, zie mijn eerdere post en de wikipedia pagina over Wayland
Wayland is het (op XML gebaseerde) protocol waarmee de applicaties met de Window Manager communiceren. De Window Manager (die de server kant van het protocol implementeert) is daarmee dus in een keer de display server.Wayland provides a method for compositing window managers to communicate directly with applications, eliminating their dependence on X, allowing them to communicate directly with video and input hardware, becoming the display server.
sudo apt-get autoremove pulseaudio
Het eerste wat ik doe bij kubuntu om line in terug te krijgen.
Het eerste wat ik doe bij kubuntu om line in terug te krijgen.
Erg leuk dat je dan gelijk de mogelijkheid om meerdere programma's tegelijk audio te laten afspelen, verliest.
Ik heb je al een keer eerder zien reageren over het feit dat PulseAudio samen met KDE brak zou zijn. Waar ik een tegenovergestelde ervaring mee heb opgedaan de afgelopen dagen omdat ik KDE weer eens een kans heb gegeven.
Als je PulseAudio van je systeem mikt zou je niet meer twee applicaties tegelijkertijd geluid uit kunnen laten spugen? Hoe deden we dat toch voor PulseAudio? Ohja, ALSA kan het al enige jaren van zichzelf, ook out-of-the-box (dmix, default ingeschakeld).
Mijn laptop is niet eens voorzien van PulseAudio en die doet keurige software mixing met ALSA dmix.
Hoe het verder distributiegewijs uitkomt weet ik niet. Misschien dat Kubuntu geconfigureerd is om met PulseAudio te werken en niet terugvalt op ALSA dmix. Maar je stelling dat je geen audio van twee verschillende applicaties naar hetzelfde audio-apparaat zou kunnen sturen is kul.
Als je PulseAudio van je systeem mikt zou je niet meer twee applicaties tegelijkertijd geluid uit kunnen laten spugen? Hoe deden we dat toch voor PulseAudio? Ohja, ALSA kan het al enige jaren van zichzelf, ook out-of-the-box (dmix, default ingeschakeld).
Mijn laptop is niet eens voorzien van PulseAudio en die doet keurige software mixing met ALSA dmix.
Hoe het verder distributiegewijs uitkomt weet ik niet. Misschien dat Kubuntu geconfigureerd is om met PulseAudio te werken en niet terugvalt op ALSA dmix. Maar je stelling dat je geen audio van twee verschillende applicaties naar hetzelfde audio-apparaat zou kunnen sturen is kul.
Toch even opmerken dat met dmix één programma nog steeds je geluidskaart kan blokkeren (en verder doet PulseAudio nog veel meer dan enkel audio mixen natuurlijk).
Wat een pulseaudio haters hier allemaal, ik heb er raargenoeg nooit problemen mee gehad (gebruik het sinds ubuntu 10.04)
Dan is het ook voor jouw tijd. Ik gebruik Ubuntu sinds 7.04 en heb het ook niet heel bewust meer meegemaakt. Alleen dat als ik bijv al in de browser een filmpje afspeelde ik niet nog ander geluid er doorheen kon hebben, in latere versies kon dat opeens allemaal gewoon.
In het begin was pulseaudio inderdaad enorm buggie. Het leek meer op een beta dan op een final.
Later zijn de meeste van de bugs gefixt waardoor het nu doorsnee prima werkt.
Later zijn de meeste van de bugs gefixt waardoor het nu doorsnee prima werkt.
Uit een aantal reacties leid ik af dat het niet geheel duidelijk is wat Wayland nu eigenlijk doet.
Wayland is in essentie een compositor. Dat wil zeggen dat het zowel aan windowmanagement als compositie/samenstelling van de client display buffers doet vooraleer deze gepushed worden naar het scherm. Het gebruikt dan ook de reeds bestaande display technologie die reeds in de linux kernel en de mesa library zit. In dat opzicht hoeven ati en nvidia dan ook geen speciale aanpassingen te doen voor wayland, behalve dan er voor te zorgen dat hun drivers netjes samenwerken met de laatste linux gfx back-ends.
Verder is het zo dat client window nog hun eigen 'decoratie' schilderen waarmee de user het venster kan verplaatsen, sluiten, etc. Bedoeling is uiteindelijk naar een apparte library interface te gaan waarmee je een 3rd party windowmanager kan schrijven.
Ook hoor ik soms de kritiek dat er geen netwerk layer is die X wel had. De opmerking hier is dat het nog altijd perfect mogelijk is deze functionaliteit te implementeren onder de vorm van een apparte wayland client die rendering en input commands ontvangt van een ander programma, of beter nog... je kan simpelweg X gebruiken als wayland display client.
Wat zijn dan zoal de voordelen?
Door windowmanagement en compositor in 1 process te integreren krijg je geen delay meer wanneer je bvb een window verplaatst. Bij X krijg je het fenomeen van window tearing. Dit komt omdat de client niet in sync loopt met de window manager (dit kan ook niet aangezien X een asynchroon protocol is).
Stel je tekenent, als X wm, decoratie rond een client. Als de gebruiker deze decoratie versleept wil je dat de client mee versleept wordt. Als je dit simpelweg op deze manier zou implementeren in een X omgeving zal de client altijd 'laggen' op de decoratie die je versleept*. Dit komet omdat je eerst tegen X moet zeggen 'verplaatse mijn decoratie' en dan zegt 'verplaats client'. Door de window manager en de compositor in hetzelfde process te steken kan je dit in 1 rendering cycle doen. Misschien herinner sommige zich nog de wayland uitspraak 'every frame is perfect'. Dit is hier een voorbeeld van.
(*)In de praktijk wordt de client kind gemaakt van de decoratie waardoor het verplaatsen van de decoratie automatisch het effect heeft dat alle kinderen (dus ook de client) mee in sync wordt verplaatst.
Wayland is in essentie een compositor. Dat wil zeggen dat het zowel aan windowmanagement als compositie/samenstelling van de client display buffers doet vooraleer deze gepushed worden naar het scherm. Het gebruikt dan ook de reeds bestaande display technologie die reeds in de linux kernel en de mesa library zit. In dat opzicht hoeven ati en nvidia dan ook geen speciale aanpassingen te doen voor wayland, behalve dan er voor te zorgen dat hun drivers netjes samenwerken met de laatste linux gfx back-ends.
Verder is het zo dat client window nog hun eigen 'decoratie' schilderen waarmee de user het venster kan verplaatsen, sluiten, etc. Bedoeling is uiteindelijk naar een apparte library interface te gaan waarmee je een 3rd party windowmanager kan schrijven.
Ook hoor ik soms de kritiek dat er geen netwerk layer is die X wel had. De opmerking hier is dat het nog altijd perfect mogelijk is deze functionaliteit te implementeren onder de vorm van een apparte wayland client die rendering en input commands ontvangt van een ander programma, of beter nog... je kan simpelweg X gebruiken als wayland display client.
Wat zijn dan zoal de voordelen?
Door windowmanagement en compositor in 1 process te integreren krijg je geen delay meer wanneer je bvb een window verplaatst. Bij X krijg je het fenomeen van window tearing. Dit komt omdat de client niet in sync loopt met de window manager (dit kan ook niet aangezien X een asynchroon protocol is).
Stel je tekenent, als X wm, decoratie rond een client. Als de gebruiker deze decoratie versleept wil je dat de client mee versleept wordt. Als je dit simpelweg op deze manier zou implementeren in een X omgeving zal de client altijd 'laggen' op de decoratie die je versleept*. Dit komet omdat je eerst tegen X moet zeggen 'verplaatse mijn decoratie' en dan zegt 'verplaats client'. Door de window manager en de compositor in hetzelfde process te steken kan je dit in 1 rendering cycle doen. Misschien herinner sommige zich nog de wayland uitspraak 'every frame is perfect'. Dit is hier een voorbeeld van.
(*)In de praktijk wordt de client kind gemaakt van de decoratie waardoor het verplaatsen van de decoratie automatisch het effect heeft dat alle kinderen (dus ook de client) mee in sync wordt verplaatst.
[Reactie gewijzigd door Zubzub op maandag 8 augustus 2011 09:18]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
