Slashdot Mirror
freedesktop.org xlibs 1.0 Released
Daniel Stone writes "A short time ago, freedesktop.org xlibs 1.0 was released. Simply put, this is the collection of libX11, libXext, and other little-used libraries that kind of power your whole desktop. The xlibs team at fd.o are now maintaining all these libraries, and more, and we're going to be making releases as part of the fd.o platform, which is far more wide-ranging, but it still forms an important part of the platform. Share and enjoy!"
... but having one group looking after all these libs would seem to offer some scope for optimisation and consolidation. Sounds like a good thing...
What's the DBUS ? (Desktop bus ?)
Simon
Physicists get Hadrons!
And X is NOT slow. For what it does, it does it quite efficiently, and it even has network transparancy thrown in for "free", because of the way it works. Just because the code base of XFree86 is a bit aged and has accumulated a lot of cruft over the years, doesn't mean the initial design is flawed. It was ahead of it's time, and it's still relevant.
Oh, and X works pretty good for me. Haven't seen a crash because of X in years. Maybe it's something else (buggy driver? broken hardware?) that's plagueing you. It's not X, in any case.
Bullshit.
I triple dog dare you (not necessarily the parent troll, but the general audience) to find a binary or library capable of displaying on an X11 display that's not linked, statically or dynamically, to libX11 and friends; of course, barring the things written by masochists that implement the X Window protocol themselves over a TCP or Unix socket.
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
And X is NOT slow.
He is right about X not being slow. The problem is the perception thats X is slow. X is what is visual to the user, users either blame KDE/Gnome or X.
Take a pre-emptive low latency linux kernel and run X on it, its like night and day, its smooth, fast, which proves its not X but the kernel.
Windows cheats and loads the gui extremely fast, but if you watch your hardrive light, and tool tray, you will noticed things are still being loaded in the background. The system is busy for a few more seconds. You can load an application, and it waits till after the services start.
So, X seems slow compared to other OS's.
1. Long delays to get into KDE/Gnome, and actually use the system.
2. Slow response on user input.
3. Multitasking, switching apps pause the system.
4. Loading directories in ICON/Image view takes longer than windows.
5. Lindows has everything running as Root for a speed boost.
I predict we will see pre-emptive, low lantency kernels as standard on Mandrake and Suse. Preemptive kernels are now standard on 2.6.x (well, if you check the box). And even more pre-linking to help boot time.
BSD has the same issues. Apple's X server does seem faster than both Linux & BSD. I'm only running window maker on it, so its not an exact match, but task switching and running gimp does seem more reponsive.
Could the answer be the mach kernel osx uses? Maybe we need a new suite of benchmarks for user interaction. (os+X+wm/etc).
-
I code in my SecondLife
Yeah, and what kind of non-bloated non-gtk/qt applications do you run in your non-bloated window manager?
psavo, a wmaker user himself
fucktard is a tenderhearted description
The headline that got put on the press release was misleading. The reality is that X.Org has been reformed to be more like the GNOME Foundation. There will be open elections to appoint a board. Votes will no longer be obtained through monetary contributions; in other words, any one can have a vote and be elected, no matter their affiliation. The actual information handed out by X.Org should be posted on their site in the next few days, which includes the mission statement and aims of the project.
Some developers that have at one time or another been associated with XFree86 are participating in the reformation of X.org. How that translated into "XFree86 and X.org have mereged" in the headline is beyond me.
Harold
Actually, the line about X.Org was mostly true until a few days ago. X.Org has just been reformed as a group that individuals can join and contribute too without any sort of monetary contribution. The new X.Org is essentially like the GNOME Foundation. Open elections will be held within the next coming months and anyone is free to participate in the elections and/or run for a seat. freedesktop.org is actually involved in the reformation of X.Org; there is a lot of overlap between the two projects and who is working on them. The xlibs release is something that the memebers of the new X.Org are interested in and are moving to as the future of X.
Harold
What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"?
---
X makes you do input-processing application-side, but that doesn't really introduce an inefficiency. The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.
Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait for round trips? Nope.
---
Probably not. But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.
A NeWS-like architecture is much more efficient for implementing distributed applications on cell phones, because it permits the application to download executable code to the phone, saves the user time and money, as provides a high quality, responsive user interface.
---
Maybe, but cell-phone applications would necessarily have to be a lot-more limited than general-purpose desktop apps.
Have you ever heard of a language called "JavaScript"?
---
Yes.
In case you never heard of it, believe me: there are a lot of people willing to download JavaScript code.
---
If you can convince app developers to write their code in Javascript, than more power to you. But that's where I was getting at with the Lisp comment. To be really practical for modern desktop apps, you'd have to use something a lot faster than Javascript. For stuff like HTML rendering, there is a large computational bottleneck. Thus, you'd need a safe, yet fast language.
In case it's not obvious: The web browser / http server model IS a NeWS-like architecture.
---
To tell the truth, the web-browser, http-server model is working just fine on top of X. The needs of an internet-based system are very different from a local/network-based system, and I really see little advantage to a NeWS style system targeted at the markets X is aimed at.
The main problem with your HTML/Javascript example is that it only works well because all applications use the same basic display logic (HTML/CSS). However, desktop applications in general do *not* use the same basic display logic. The display logic of a text-editor is very different from the display-logic of a photo editor. If you want to implement this differing display logic in a NeWS-style system, you end up loading large amounts of complex display code into the server. And to feed that display logic, you end up shipping large amounts of data over the wire.
- additional ranting deleted -
---
There is no indication that X is holding back Linux on the desktop. What's holding back Linux on the desktop are ease of use and application support. X is quite competitive with the other two desktop systems out there (OS X's and Win XP's). With the freedesktop.org work, it'll be highly competitive with future UIs like Longhorn.
A deep unwavering belief is a sure sign you're missing something...
I think, right now, you're looking more like the fanatic.
Put identity in the browser.
A C++ program can rely on a glib-based C library just as easily (perhaps somewhat easier, due to the consistent object model) as on any other C library. There is no problem here at all.
"Using Glib in KDE is pointless"
Using glib in DBUS is not however, and using DBUS in KDE is not... moot point. Also keep in mind that KDE's reliance on C++ and C++'s platform difficulties (SOME of which went away with the finalization of the ANSI standard a few years back) was exactly the reason that Sun had to choose Gnome as their desktop, even though they prefered KDE at the time. They had to support two compilers though, and if you can't lock customers into a compiler, C is the only way to fly (Java is as close as it gets otherwise, and it might be ok after another decade or two to mature).
I'm not language zeloting here... I see the value of C++ accedemically, but building software in it DOES cut you off from the rest of the world in the sense that the many, many thousands of C-based software projects and products in the world then have a hard time making any use of you at all.