Working On The X.Org 7.6 Katamari

[phoronix]

Phoronix: Working On The X.Org 7.6 Katamari

If all goes according to plan, X.Org Server 1.9 will be released in about two weeks, but after that there still is the X.Org 7.6 release "katamari" to be done. While X.Org releases themselves aren't as important any longer with the X Server releases being done at different points and the rest of the X.Org package collection being modular, the X.Org 7.6 release is expected in October...

http://www.phoronix.com/vr.php?view=ODQ5Mw

[curaga]

It's sad to see X gaining bloat and forcing it on users (very little used xcb libs, which in turn force python).

[RealNC]

Isn't XCB considered a good thing?

[curaga]

Yeah, it adds support for multi-threaded X client drawing and also supposedly improves Xlib operations' speed.

The thing is, no app I need has the need to draw from more than one thread, and Xlib op speed is the least of my graphics speed worries. IE - no user benefit at all, just bloat.

Before libX11 1.4 it wasn't forced, --without-xcb is removed in 1.4.

[RealNC]

I thought XCB is intended as a replacement for Xlib/Xt and it makes things simpler for developers.

Also, what bloat are you referring to? Most stuff I read about XCB is that it reduces bloat and helps performance.

Furthermore, many programs seem to use it. Here, an "lsof /usr/lib/libxcb.*" gives:

COMMAND    PID   USER  FD   TYPE DEVICE SIZE/OFF   NODE NAME
dbus-laun 2247 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kdeinit4  2295 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
klauncher 2296 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kded4     2298 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kglobalac 2307 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
ksmserver 2324 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kwin      2337 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
knotify4  2360 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
plasma-de 2362 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kuiserver 2365 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kaccess   2377 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
krunner   2386 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
polkit-kd 2387 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
yakuake   2389 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
kmix      2392 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
tvtime    2437 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
ksystrayc 2438 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
thunderbi 2457 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0
firefox   2739 realnc mem    REG    8,2   119840 132899 /usr/lib64/libxcb.so.1.1.0

Pretty much every application I start uses XCB?

[curaga]

Also, what bloat are you referring to?

1.5mb of libraries I have no need for, plus on average 2 more linked libraries per X app (thus slowing the start of each app).

Plus the fact it requires python, which is bloat by itself.

Pretty much every application I start uses XCB?

None of those by themselves, all via libX11.
Very few apps can use it at all, and of those most also have a working xlib backend (mesa, evas).

[RealNC]

Hmm, it seems like your only concern is 1.5mb of space, which sounds kind of ridiculous :P

The extra link stage per X app does not increase loading time, since we're talking about shared libs.

Also, Python is a powerful tool that has become an integral part of Linux infrastructure, just like Perl. It makes certain tasks very easy to implement.

So to sum it up, where you see "bloat", I see advancement and development, and making use of existing technologies instead of reinventing the wheel. As it should be. If everyone was sharing your opinion, we would still be using 386'es with 2MB RAM, MS-DOS and Turbo Pascal

[curaga]

Hmm, it seems like your only concern is 1.5mb of space, which sounds kind of ridiculous :P

If bloat was accepted, we'd all be running Windows and buying new comps every year.

The extra link stage per X app does not increase loading time, since we're talking about shared libs.

Sure it does. I openly admit having read Drepper here
IIRC it was in his "How to write shared libraries" doc.

Can't recall how to measure it right now, but there's an env var to show exactly how much time the dynamic linker spends resolving these. Cutting down on shared libs, both linked and dloaded, is why OpenOffice got a start speed boost at one point.

Also, Python is a powerful tool that has become an integral part of Linux infrastructure, just like Perl. It makes certain tasks very easy to implement.

It will not become a part of my ecosystem if I can help it. Even perl is not considered always present, see Rob Landley's perl-removal patches to the kernel build system.

So to sum it up, where you see "bloat", I see advancement and development, and making use of existing technologies instead of reinventing the wheel. As it should be. If everyone was sharing your opinion, we would still be using 386'es with 2MB RAM, MS-DOS and Turbo Pascal

I'll agree to disagree here.
I'll also point I'm not against the improvements per se (multithreading, faster xlib), but the way they are implemented. Python, one-lib-per-X-extension approach, and being big additional libs instead of, say, fixing/adding to Xlib.

[RealNC]

You will see zero difference if you enable XCB on your system.

I challenge you. This is Phoronix, which means we even have benchmarks, no? I know what I'm talking about because I had -xcb in my USE flags for ages There is absolutely no negative hit in performance or loading times, which in short means: XCB is not bloat. Far from it.

[nanonyme]

Can't recall how to measure it right now, but there's an env var to show exactly how much time the dynamic linker spends resolving these. Cutting down on shared libs, both linked and dloaded, is why OpenOffice got a start speed boost at one point.

Btw, this is why prelink exists.