Slashdot Mirror

I hope they go with Wayland .

So in a bright moment of usefullness i actually posted your complaint as an 'enhancement' bug report on libreoffice, probably more useful than posting it on slashdot ;P ref: https://bugs.freedesktop.org/show_bug.cgi?id=44780

I have been with Mandriva since version 9, it was the distro I picked which got me into Linux, so have been with the distro for a lot of years now. However since the beta of Mageia 1 came out, I jumped ship - I didn't want to deal with Mandriva's new menu system for a start.

The problem I see with a shareholder revolt is, the company should have found a way to not fire their main developers in the first place. Now they are working on the community Mageia Linux version, and who is left at Mandriva?

IMO if they wanted a better distro, you should get more people to bother to report bugs so they can be investigated, not think someone else has found it. This should be made easy for non technical users so that others with more experience may try re-creating the bug. The various distro webpages to report a bug are way over the top for a new person to understand and report a bug.

I myself among now lots of others reported various Nouveau free nVidia driver issues where there are problems if you want to switch to the real nVidia driver to get 3D. Stuff like Compiz, Google Earth, or BZFlag won't work with the Nouveau driver.... but 2D stuff works fine with Nouveau.

2011 was a year where I heard the term x-killer less than usual.

That's funny, for me 2011 was the year where I first heard the term "X-Killer"... Eg: Wayland.

Oh, there's plans to change that...

there was a time when, in debian/unstable, X11 had HAL as dependency... that was the time i thought the year-of-the-desktop people finally turned linux into a bad windows...

luckily it got deprecated because it was just too bad... but the freedesktop predator is still trying hard to make linux the prey of their everything-has-to-be-like-windows agenda...

that is also the reason why we have now FreeBSD kernels as an option in debian... there is a little hope that FreeBSD is too small a prey to get fucked up by freedesktop... but i don't know... maybe "Unity" is already worse than windows...

Uum, how come you haven't switched to the open-source radeon drivers already?
They were already more stable in their very first experimental release, than the one-half-developer-assigned sorry crap ATi calls their "drivers".
Check the open source feature matrix:
http://xorg.freedesktop.org/wiki/RadeonFeature
In practice this means, that everything works nicely. And the configuration and xrandr support is actually really nice and clean.
While Catalyst probably still doesn't allow compositing and 3D at the same time. lol. (Is the video still distorted to an insane level in brightness?)

TL;DR: Try the open-source drivers! Now. Period. You will never look back, and everything will work.

Your definition of decent seems to be a bit off. Decent software isn't slow, bloated, and buggy. I'll put up with slow and bloated. However buggy is never "decent" enough for use. Thank goodness there are alternatives.

It doesn't sound to me like this is that much like either PulseAudio or Jack. Those are both sound systems based on userspace daemons focused on flexible sound mixing, while this virtual graphics system is within the Linux kernel and seems to be focused on simply moving pixels from one hardware device to some other device.

Wayland is more like PulseAudio or Jack for graphics. Its proponents think it has advantages over the much thicker, more complex daemon we've used for decades called the X11 server.

David Airlie's HotPlug video work is really cool. I'm not surprised something bigger is coming out of it. What I really like are Elija's thoughts on putting it in the kernel so support is for more than X. Below is from the DRI-Dev thread. http://lists.freedesktop.org/archives/dri-devel/2011-November/015985.html [freedesktop.org]

On Thu, 3 Nov 2011, David Airlie wrote:

Well the current plan I had for this was to do it in userspace, I don't think the kernel has any business doing it and I think for the simple USB case its fine but will fallover when you get to the non-trivial cases where some sort of acceleration is required to move pixels around. But in saying that its good you've done what something, and I'll try and spend some time reviewing it.

The reason I opted for doing this in kernel is that I wanted to confine all the changes to a relatively small set of modules. At first this was a pragmatic approach, because I live out of the mainstream development tree and I didn't want to turn my life into an ethernal merging/conflict-resolution activity.

However, a more fundamental reason for it is that I didn't want to be tied to X. I deal with some userland applications (that unfortunately I can't provide much detail of yet) that live directly on the top of libdrm.

So I set myself a goal of "full application transparency". Whatever is thrown at me, I wanted to be able to handle without having to touch any piece of application or library that the application relies on.

I think I have achieved this goal and really everything I tried just worked out of the box (with an exception of two bug fixes to ATI DDX
and Xorg, that are bugs with or without my work).

-- Ilija

David Airlie's HotPlug video work is really cool. I'm not surprised something bigger is coming out of it. What I really like are Elija's thoughts on putting it in the kernel so support is for more than X. Below is from the DRI-Dev thread. http://lists.freedesktop.org/archives/dri-devel/2011-November/015985.html

On Thu, 3 Nov 2011, David Airlie wrote:

>
> Well the current plan I had for this was to do it in userspace, I don't think the kernel
> has any business doing it and I think for the simple USB case its fine but will fallover
> when you get to the non-trivial cases where some sort of acceleration is required to move
> pixels around. But in saying that its good you've done what something, and I'll try and spend
> some time reviewing it.
>

The reason I opted for doing this in kernel is that I wanted to confine
all the changes to a relatively small set of modules. At first this was a
pragmatic approach, because I live out of the mainstream development tree
and I didn't want to turn my life into an ethernal
merging/conflict-resolution activity.

However, a more fundamental reason for it is that I didn't want to be tied
to X. I deal with some userland applications (that unfortunately I can't
provide much detail of .... yet) that live directly on the top of libdrm.

So I set myself a goal of "full application transparency". Whatever is
thrown at me, I wanted to be able to handle without having to touch any
piece of application or library that the application relies on.

I think I have achieved this goal and really everything I tried just
worked out of the box (with an exception of two bug fixes to ATI DDX
and Xorg, that are bugs with or without my work).

-- Ilija

Absolutely. Chromium is already being ported and I would love to see Mozilla's Azure optimized for Wayland. I'm anxiously waiting for the speed boost.

Linux actually has it better over Windows and OS/X in that there is a well-defined place to dump your user's configuration that is *not* part of the Application, so the users don't clobber each other and the configuration stays even if the application is removed. This is to put it in ~/.appname. Windows suffers from a *lot* of potential locations (due to everything being writable at one time), while OS/X has a misguided attempt to put writable data into the application directory.

Putting .config files in the user's home directory is so 2001. Please stop it. If you're to believe one of the many specifications out there, like the XDG Base Directory Specification, then you should be storing user configuration files in ~/.config/blahblah so you're not filling up the user's home directory with crap.

It isn't happening, but even if X dropped support for the i810 completely, and you didn't want to use the VESA driver, you could still use an old X server, which is the Linux equivalent of Windows 7 using an XP driver.

Funny enough, while there are loads of alternative pdf readers out there, all of the alternative flash players I know of seem to be Linux only, or the windows versions are way behind. http://www.gnu.org/software/gnash/ http://sourceforge.net/apps/trac/lightspark http://swfdec.freedesktop.org/wiki/ Perhaps this will get these projects some attention...

Sorry, I have used it for about 2 months intensively and it has lots of issues. It just can't even save in .doc format in a correct way as files get always corrupted.
As long as there isn't a big development on going, it can't compete with MS Office in at least providng basic features.
I would love to see this stuff go further.

Have you filed a bug? Things won't get fixed unless people know about them.

https://bugs.freedesktop.org/enter_bug.cgi?product=LibreOffice

There is a lot of ongoing development. LibreOffice is a big project with a very active developer community.

There are a lot of little things that have never been cleaned up or standardized. Picking up something could take you a couple of ways; Do you want the understand the of the dynamics of what goes on between people, standardization process ... There is more than just code, there needs to be a direction to what needs to be accomplished.

Take a small thing that might be still being worked on, not to say this is what you should but more as a example,:
http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt
http://pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf

There are a lot of little "dangling ends" still out there that needs a bit of help; standards that need to be worked on and other things besides just code work.

https://github.com/MostAwesomeDude
https://www.ohloh.net/accounts/MostAwesomeDude
http://cgit.freedesktop.org/~csimpson/
http://git.kernel.org/?p=linux/kernel/git/csimpson/linux-2.6.git;a=summary

Your turn. Put up or shut up. >:3

It's all command-line anyway; how much resolution do you really need?

You never heard of Xorg, Freedesktop, or KDE?

Windows has installation CDs that are slimmed down as well as ones which contain more software. The solution isn't to have all distros include the same software. You said what the solution is: standards. All you need are standardized ways for the same type of thing to be done across any distro, like program installation standards. The system needs to be able to recognize all dependencies and to easily obtain anything which is missing. Then, who cares if libraryXYZ is missing? Your package manager will get it for you.

The stupid create-your-own-software-universe model needs to die. Programs need to be cross-distro at the very least, and cross-platform preferably.

Everyone: please just say no to any systems which attempt to lock you into a single vendor source for your software when alternatives exist that give you much more freedom. Using Android as an example, it takes away your freedom by locking you into Android-only apps. Why would I choose that over a distro which allows me to run any and all Linux apps? Want to buy something from the Ubuntu Software Center? Hell no, you shouldn't be ball-and-chained to a specific distro, and even if you did find the DEB file you would be locked out of RPM-based distros unless you somehow converted the DEB to RPM, but why should you have to?

The point is that even open source software can make you a slave if it doesn't offer standards, because that is where real freedom comes from. Development time has a cost, so spend your time and money helping out projects which seek to give true freedom to all computer users world-wide. Programs like Zero Install perhaps? Standards groups like freedesktop.org?

At this point I am ending this discussion because I've addressed this twice already and you are not reading. I have specifically talked about how this can and will be available from projects that are being discussed.

from wayland itself: http://wayland.freedesktop.org/faq.html

It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the fowarding into the desktop compositor, could let you export or share a window on the fly with a remote wayland compositor, for example a friends desktop.

THIS IS 100% WHAT YOU ARE ASKING TO BE ABLE TO DO? WHY DON'T YOU UNDERSTAND THAT?

You're talking like Wayland has already killed Xorg when wayland hasn't even had a stable release yet because it is not ready.

Wayland pretty much is "the compositor without all the layers in between." See this description of the Wayland architecture.

By far the most common complaint I see about X is "OMG IT'S SLOW BECAUSE IT ALWAYS RUNS OVER THE NETWORK!!!!!!!!". (...) As far as I can tell, anyone who's backing Wayland has no actual concrete complaints about X, they just feel the need to rewrite everything from scratch

Have you bothered to read the article about Wayland's architecture? The problem with X11 is not the network transparency or the fact that it is not invented by the author. The problem, AIUI, is that the X server has to interchange lots of information with the compositor because each handle pieces of the information that should not be split. If a click happens, the server handles it, but the compositor can modify the aspect of a window, so the server requires information from the compositor too. Wayland fixes this merging the server and the compositor. This has nothing to do with the network transparency.

This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier.

It sounds to me like X is supposed to be an optional component, to support legacy code and/or remote machines, etc. -- but isn't the only option. Wayland just takes over the one particular part of the process (just compositing on screen).
Admittedly, I haven't read a lot about wayland. Until this article, I'd never heard of it (perhaps showing how little I've kept up on tech news lately). But, out of genuine curiosity, how is this going to ruin the flexibility of X?

Go visit the Wayland site and look at its architecture. It's obvious how doing away with X will improve performance.

I am working on implementing a standalone remote Wayland application that would enable the functionality that the GP mentioned.

Wayland also brings to the table improved performance, and the freedom for each developer to use whatever means they want to generate their own framebuffer to the compositor. This means that Wayland won't need to be updated in 10 years to remove old, useless primatives and add new ones, like many others here are suggesting we do with X now.

There is a nice website with an explanation of the architecture here: http://wayland.freedesktop.org/architecture.html and they have a FAQ as well.

There is a pretty good description here: http://wayland.freedesktop.org/architecture.html

Pretty much all of the modern advances in Linux Graphics have been to push the performance sensitive parts of X to the kernel and the client. In current 3D apps, X does little more than the Wayland compositor does, but adds a cumbersome middle man.

1. If you even suggest for a second that systemd isn't awesome, you will hear from people (for example.... you) who says it's great, without addressing any concerns that system admins actually have.

Mainly because said concerns tend to boil down to "Waaah, it's different." Oh no.

2. The command line interface is annoying... it's even worse than the problems we have with SMF on Solaris 10+. Following the original threads about it, you can tell Lennart has no idea what people actually do with the command line. systemd calling $MORE? Hasn't anyone ever used expect?

"Annoying" is an opinion. Could you please link to said threads?

3. They want to roll cron and inetd into it... for no reason that I can see. Vixie cron and xinetd both work great last I checked. This seems to be bacause that's what MacOS X does with launchd, not for any real reason.

There are some advantages, such as per job/per request cgroups to make sure that all processes get cleaned up correctly. I'm not particularly bothered either way. Note that "in systemd" doesn't mean "in PID 1".

4. Doesn't socket activation require changes to daemons?

It does. However, you don't need to use socket activation -- "classic" forking services can be used just fine. Obviously, yes, if you want all the advantages of systemd, daemons do need to be modified to receive their sockets from systemd.

5. D-Bus dependency. On my init system. Sounds awesome, where do I sign up. systemctl actually didn't work at first on my F15 box because... I don't run dbus (standard X11 window manager, I don't generally use Gnome or KDE, lucky me.)

Some sort of RPC was needed for communication between systemctl and PID 1. TBH I would rather systemd used a solution that's already widely used in the Linux desktop, is well-maintained and robust, rather than Lennart rolling his own NIH version. But maybe that's just me. It doesn't seem like an unreasonable design decision to me. What solution would you prefer?

6. Optimizing for a problem most Linux boxes don't have... reboot speed and dependency resolution, which really sounds like something I do as little as possible. I run 100s or 1000s of boxes... reboot speed is rarely my concern... my boxes spend more time in POST then they do mounting filesystems and starting sshd these days. Sounds like a laptop problem to me.

As far as I can tell, systemd is also optimised for ensuring that login sessions and daemon processes are correctly & fully cleaned up (for example, if you're rebooting apache, systemd will make sure all the processes apache forked are terminated -- something SysV init can't do).

7. No separate /usr... and when you ask about it you're told "you don't want that." Now, I don't ever separate /usr if I don't have to, but I do not think that is an adequate answer, and I know people this is going to seriously affect at some point.

"systemd itself is actually completely fine with /usr on a separate file system that is not pre-mounted at boot time. However, the common basic set of OS components of modern Linux machines is not, and has not been in quite some time. And it is unlikely that this is going to be fixed any time soon, or even ever." People seem to be very keen to shoot the messenger (i.e. the systemd devs) for warning them that about breakage that has been present since before systemd existed.

Gah, I don't even run systemd myself and I seem to know more about it than most people commenting on this article...

You've probably been mislead: This is the current feature matrix.

The current status is here: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt When all is supported, the version of mesa will jump to 8.0. this month 7.11 will be released, and the next release is to be expected in January/2012.

I don't know about the "fully floating point audio path", but PulseAudio does support per-application volume faders.

It says it supports floating point sample types, but I don't know if that meets your criteria of being from the hardware up - I guess that would be a driver issue.

Perhaps (in the same way that Apple chose to reject the complex Mozilla codebase and went with KHTML to design WebKit), a project like Nouveau (is there a similar ATI from-scratch driver effort?) could produce stable, auditable graphics drivers that will run 3D graphics on modern hardware at speed.

Maye some company can subcontract the OpenBSD dev teams to do it. :)

Hate to break it to you, but it's not

http://wayland.freedesktop.org/faq.html#heading_toc_j_0

Why fork the X server?
It's not an X server and not a fork. It's a protocol between a compositor and its clients

That's because AMD has faked releasing documentation. They have released the most basic worth-/useless parts.
And as promised, the XOrg radeon team already implemented that, plus a lot more.
As can be seen here: http://xorg.freedesktop.org/wiki/RadeonFeature

If they release stuff that actually documents the 3D and video stuff, instead of just basic mode setting & co, then we'll fix the bits that are missing too.

But it's so nice of this whole thread with all parent posts and most sibling posts, to just spew uninformed ignorant bullshit...

Reminds me of the pledge for nouveau, the free-as-in-speech drivers for Nvidia graphics cards, which gathered at least around $14,000 — but was alas not fulfilled, on account of problems with finding an organisation to manage the money transfer ...

Provided that the business of the feasability of money transfer were handled beforehand, I could easily see such a pledge directed towards the development of GIMP reaching several dozen thousand dollars.

There are a ton of tools for almost every operating system and GUI API providing those features. They're called GUI Automation or GUI Test Tools. Linux Desktop Testing Project is just one of them.

Or they could just use the library which actually does the heavy lifting in evince (and Okular and nearly all the other pdf viewers for linux out there)Poppler.

I'm sure that this is exactly what they intend to do.

Uh... how is this +5 Insightful? The parent has clearly not RTFA, and is contributing nothing to this discussion except making broad statements about people associated with Gnome and assuming bad will.

The article, which I actually found was a rather good read, states that "FreeDesktop.org is broken as a standards body". Considering that the front page of freedesktop.org says "freedesktop.org is not a formal standards organization", this doesn't seem like an overly controversial statement.

And by the way, how can Gnome even claim anything? It is a project, not a person. It would be more to the point to say "what you'd expect from Dave Neary" (the article author), although equally uninformative unless you tell me why.

I am personally not involved with any Linux desktop development, but as an "outsider" reading about this debate and trying to understand what is going on, the parent's post doesn't give me any insight.

Perhaps most the most telling thing about your summary is that you don't understand that "freedesktop.org is not a standards body," which is clearly stated on the FD.o website. It helps with inter-desktop collaborations through specifications and their hosting. The process is very open and devs are welcome to contribute, fork, and modify specifications. You said "Mark Shuttleworth doesn’t understand how GNOME works," but apparently, GNOME doesn't understand how FD.o works. "The log in your own eye ..." and all that.

The fglrx drivers were terrible. They were ludicrously unstable. From what I understand, they eventually got better, but they would crash the system (ie, straight to POST, not just X11) on a regular basis for years.

Writing a compatibility layer for old drivers is a very tricky business. Specifically, it's the business of the writers of the old drivers. Only they know what arcane deprecated functionality their software uses, not the writers of the interface.

Open sourcing the API to the drivers did fix the problem. The open source drivers support ATI hardware all the way back to the first generation radeon.

I figure eventually someone will write the right wrappers so apps only need to deal with one API.

VA-API is the wrapper that you speak of. It has multiple backends, including backends for Intel cards, VDPAU and XvBA.

VA-API is the only standard that makes sense to implement, unless you like limiting your apps to nvidia/ati users only, or like writing three times as much code.

Still KDE is missing integration for FF, Chrome, OO.

Um. Surely you mean, "Still FF, Chrome, OO is missing integration for KDE"? Last time I checked, it was unreasonable to expect KDE developers to go out and patch KDE integration into [insert your every favourite application here].

I think OS community does not have enough resources to maintain different applications for several desktop, or maintain several desktops.

As long as people are able to choose to do something different, there will be people who do choose to something different. As soon as you mandate the One True Desktop Environment (for example) you lose most of the power of Free software.

Competition is good, but linux needs standards to make it easier for software and hardware manufactures to support it.

What, you mean like POSIX, the Filesystem Hierarchy Standard, and all of these other cross-DE specifications?

By what? The nouveau driver that doesn't adequately support my old-but-still-produced video card?

http://nouveau.freedesktop.org/wiki/FeatureMatrix

http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/ If you look 2.13.903 is out this will become 2.14 unless something major is found. This took a whole day !! to go from final release candidate to release for 2.12. I wonder what those linux users who imported from Malaysia will do.

wow! intel is really keeping up with whats What hot and new , intel open source Now sounds like intel really wants to please OSS users like on Arrandale when they pull these kinds of stunts, TFA:

Intel decided not to send out any Sandy Bridge CPU samples to us, so we are unable to deliver test results, but all I got were frustrated journalists asking me how to get the Sandy Bridge graphics working under Linux.

Arrandale is also a complete mess on some platforms like fedora for e.g.Currently now running gentoo with xorg 1.9. and kernel 2.6.37.7 and feeling lucky that most things are now working on an Arrandale platform.

There's NV and there is Nouveau, which is the community driver and from what I can tell, it's already much more advanced.

Power management has been lacking, but it's coming and they are already testing it: http://nouveau.freedesktop.org/wiki/PowerManagement

also, you can create a none OS application for Linux.

Linux for the desktop PC has far more places where the underlying operating system can be modified to in effect tee the decompressed video into MEncoder. You can do it at the level of Qt or Gtk+, at the level of X, or even in the kernel. There is nothing remotely close to the Protected Video Path under Windows; what is called DRM under Linux is something completely different.

True, though it could be done at the distro level, which appears to be the author's plans (the person who wrote this script works for Red Hat, and discussed elsewhere in the thread what Red Hat's plans are for rolling out systemd, which will handle this). Then things would be appropriately updated by the maintainers rather than relying on users to keep their .bashrc synced with infrastructure changes.

I understand what you're saying and agree. The problem I have is with your userid. 597. Users with IDs as low as this are mythical. Kind of like unicorns or maybe even grues; they are creatures of the imagination. Users with sub-1000 user ids are DANGEROUS. They say stuff that most often makes sense and this can be mesmerising. They do this to lure us into the trees to have intercourse with sirens of the forest, I have heard. Your post is an incredible example of the delirium that can ensue when magical beings make posts. Your post also contains NO REFERENCE TO MICROSOFT. This is indeed disturbing and should set alarm bells ringing. I would not be surprised to be able to type "open letterbox" in your post and see an envelope containing a letter or note.

True, though it could be done at the distro level, which appears to be the author's plans (the person who wrote this script works for Red Hat, and discussed elsewhere in the thread what Red Hat's plans are for rolling out systemd, which will handle this).

Indeed. "Should we be punting this for userspace tools to handle?" isn't the same question as "should we punt it to the user?".