X.Org Server 1.15 Brings DRI3, Lacks XWayland Support 340
An anonymous reader writes "A belated holiday gift for Linux users is the X.Org Server 1.15 'Egg Nog' release. X.Org Server 1.15 presents new features including DRI3 — a big update to their rendering model — a rewrite of the GLX windowing system code, support for Mesa Mega Drivers, and many bug fixes plus polishing. The release, though, goes without any mainline support for XWayland to ease the adoption of the Wayland Display Server while maintaining legacy X11 application support."
Re:Good! (Score:5, Interesting)
No. I just like network-transparent applications. It was one of the main draws that I had toward Linux almost 20 years ago, and is why I still use it today.
(My home Linux boxen are all headless, and they can stay that way for all I care. If I want to run something graphical, it's trivial with X.)
(And no: VNC is more of a problem than it is a solution.)
How well does XWayland work? (Score:3, Interesting)
Having seen terrible X compatibility layers for Mac OS X and Windows, I have got to ask if I should expect XWayland to be better? Integration between applications talking the X protocol and applications talking a proprietary protocol has been ranging from terrible to nonexistent. Some implementations have taken the approach of creating a window inside which all X applications are rendered. This has potential for great compatibility among the X applications, but they are demoted to second class citizens, with no chance of integrating with anything happening outside that window. Others have been rendering X applications each in a separate window. But usually they still cannot see windows opened by applications talking the proprietary protocol, and thus cannot interact with them. Secondly that design has a tendency to treat windows opened by an X application I just started as if it was just one more window opened by another X application, which was already running. For example on Windows, that causes new windows to be opened behind existing windows instead of in front.
The lack of X has been the main technical drawback Mac OS X has been having compared to Linux. I'd much rather see Mac OS X catch up with Linux than for Linux to go down to the level of Mac OS X.
Re:Good! (Score:3, Interesting)
Some of us grew up on Sun BSD you insensitive clod.
sysv init scripts are a new fangled mess.
Re: Good! (Score:5, Interesting)
I really don't understand the reason for pulseaudio in the first place, I heard that when wanting to change and modify their sound system in (was it?) freebsd? they just updated the audio driver, they didnt include some ridiculously slow, horrible to setup daemon to do it
There's a lot of history involved. OSS was originally contributed to Linux under the GPL, then to *BSD under the BSDL. It was maintained in both, but then the original author took it commercial. FreeBSD just forked the last BSDL version and kept maintaining compatibility with new versions. Linux ripped it out and replaced it with the Advanced Linux Sound Architecture (ALSA).
One of the drawbacks with early OSS was that you had a single /dev/dsp and so only one application could play sound at once. With ALSA, you still only had one /dev/dsp, but if your card did hardware mixing, and you rewrite your applications to use ALSA, then you could get mixing. Unfortunately, most things weren't rewritten to use ASLA and most cheap cards back then didn't do hardware mixing, so userspace sound daemons started appearing. Unfortunately, GNOME and KDE each had their own (incompatible) ones. Meanwhile, FreeBSD just implemented in-kernel sound mixing.
Over 10 years ago, this was why I switched to FreeBSD. I wanted XMMS to play music and my KDE IM client and GNOME mail client to be able to make notification bings, and maybe have a game in the foreground playing sound. This was trivial with FreeBSD, impossible with Linux. Now, it's possible with Linux, but only by requiring every single audio-playing app (or, at least, library) to be rewritten with the Linux fad-of-the-day API. This underlines the philosophical difference between FreeBSD and Linux, and is why I remain a FreeBSD user.