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!"
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.
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
I can't agree more. I recently wrote a fairly complicated proxy server and using glib (combined with the gnet libraries) has completely saved me. The glib routines for building quick hashtables, lists, and dynamic strings (all in C) make so many aspects of my life easier. By using a glib dynamic string as my input buffer, I can easily grow it to accomodate the incoming data rather than having to do all the realloc stuff myself.
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.
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
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.