freedesktop.org xlibs 1.0 Released 243
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!"
Not that X is slow ... (Score:3, Insightful)
What's the DBUS ? (Desktop bus ?)
Simon
Re:Who uses Xlib (Score:5, Insightful)
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.
Re:Xlib is trash. (Score:3, Insightful)
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.
Re:Who uses Xlib (Score:5, Insightful)
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 [secondlife.com]
Re:Not that X is slow ... (Score:5, Insightful)
I think glib (at least the routines for data types -- lists, hash tables, strings, etc) should be in the C standard library. The gobject stuff, while useful, should always be in a separate library.
Re:Some of us (Score:4, Insightful)
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
Re:Not that X is slow ... (Score:2, Insightful)
glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing. You can kind of prevent your program for totally blowing up, but you don't have the ability to correctly handle errors (at least in glib 1.2, don't know if 2.0 fixed this - we're talking about a nontrivial change here).
Great for building toy programs, but absolutely terrible for building a production quality system. It saddens me that so much otherwise great work (for example from the GNOME folks) is a castle built on a swamp. And it saddens me much more that people who don't understand this problem would say things like you just said, encouraging others who might not yet know better to build more software on a poor foundation.
Re:XFree86 Has Not Merged With X.Org ?? (Score:4, Insightful)
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
Re:Too many damn x's! (Score:2, Insightful)
Harold
Re:X is extremely inefficient on the network. (Score:3, Insightful)
---
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.
Re:4Sight (Score:3, Insightful)
Re:That's the point (Score:4, Insightful)
"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.