Alright, let's get some actual numbers involved ...
../configure --prefix=/usr --enable-install-setuid --sysconfdir=/etc --localstatedir=/var --disable-docs --disable-devel-docs --enable-kdrive --enable-xfbdev --disable-xcsecurity --disable-xselinux --disable-xf86bigfont --disable-pciaccess --disable-config-udev --disable-dga --disable-xv --disable-xf86vidmode --disable-dri2 --disable-xvmc --disable-xdmcp --disable-xdm-auth-1 --disable-xinerama --disable-xace --disable-xfree86-utils --disable-xaa --disable-vgahw --disable-vbe --disable-int10-module --disable-libdrm --disable-dmx --disable-xvfb --disable-xnest --disable-xephyr --disable-xfake --disable-kdrive-kbd --disable-kdrive-mouse --enable-kdrive-evdev --disable-tcp-transport --disable-ipv6 --disable-local-transport --disable-secure-rpc --with-sha1=libcrypto --disable-dri CFLAGS=-Os
Then stripped with strip --remove-section=.comment --remove-section=.note.
-rwxr-xr-x 1 daniels daniels 1.1M Apr 11 15:24 bin/Xfbdev
-rwxr-xr-x 1 daniels daniels 1.4M Apr 11 15:24 bin/Xorg
-rwxr-xr-x 1 daniels daniels 117K Apr 11 15:24 lib/xorg/modules/libfb.so
-rwxr-xr-x 1 daniels daniels 17K Apr 11 15:24 lib/xorg/modules/libfbdevhw.so
-rwxr-xr-x 1 daniels daniels 23K Apr 11 15:24 lib/xorg/modules/libshadow.so
-rwxr-xr-x 1 daniels daniels 25K Apr 11 15:24 lib/xorg/modules/libshadowfb.so
So, that's 1.1MB, vs. 1.58MB + however much evdev_drv.so and fbdev_drv.so end up being. Add in the XKB bits, and you have ~5.1MB vs. ~5.58MB (+ fbdev_drv + evdev_drv).
For full disclosure, this is against my extmod + unexport branches of xserver which haven't yet been merged upstream, and I expect master performs a little worse here. Still ...
[Edit: It obviously goes without saying that we'll very happily take patches for size reduction in Xorg. We've shed about half our codebase since 2004 (~1.1M LoC -> ~500k LoC) and would be happy to see that trend continue.]
Announcement
Collapse
No announcement yet.
KDrive, Xnest, Xvfb Called For Removal From X.Org
Collapse
X
-
I'm not sure where you're getting these numbers from, but I make a cumulative total of about 2.5MB (might be a little more due to being overeager with strip, but in any case less than 3MB) for Xorg + evdev_drv + libfb + libfbdevhw + libshadow. fbdev_drv.so would be a little more but not too much. You could make this even less again by building with -Os.
So we've got ~2.8MB versus 1.6MB for my fully-stripped Xfbdev, which is still a bit of a jump but not half as catastrophic as you make out. Remember also that both of them depend on the 197KB xkbcomp, the 142KB libxkbfile, and an XKB data set which is 3.6MB (!!) unless you go out of your way to strip that down.
If you don't want pciaccess or drm, you can disable them with ./configure and squeeze some huge space wins, especially with pciaccess. Similarly, you could disable udev, Xv, DGA (which is pretty damn big), Xdmcp, DRI2, and XACE for even more.
There are still definitely some space and size wins to be squeezed out of Xorg, but it really isn't a massive increase over Xfbdev. Even so, you still have libX11 weighing in at 1.5MB+, and a fairly hefty pixman too. And your clients are likely running GTK+ (bigger than all of them combined), or Qt (even bigger again), with Cairo (pretty damn big).
tl;dr: I really don't think it's as big a deal as you're making out.
Leave a comment:
-
Originally posted by Nobu View PostWhere does the extra storage space usage come from? And ram?
The script would run, then the shell would exit, right? Most systems run a shell at least once anyway, so any shared libraries are already loaded into memory. And we're removing code in order to replace Xfbdev, etc., anyway, not to mention the binary isn't there anymore. Shouldn't that cut down on used disk space?
These are honest questions, correct me if I'm wrong.
Xfbdev uses less RAM than Xorg
Disk space for packages added (dependencies of both are omitted):
2793k Xfbdev package vs 4579k (server) + 180k (evdev driver) + 98.3k (fbdev) + 487k (libdrm) +37.3k libpciaccess
Total: 2793k vs 5382k = 2,589k difference
That's an awful lot for Tinycore (which I know curaga is involved in), pupngo, or a rescue system that lives alongside your data on an old 500MB flashdrive.
Leave a comment:
-
Originally posted by Nobu View PostWhere does the extra storage space usage come from? And ram?
The script would run, then the shell would exit, right? Most systems run a shell at least once anyway, so any shared libraries are already loaded into memory. And we're removing code in order to replace Xfbdev, etc., anyway, not to mention the binary isn't there anymore. Shouldn't that cut down on used disk space?
The code removed (Xfbdev in this example) does not help Xorg the binary/server, it would help the development. I seem to recall Xfbdev wasn't even built by default, you had to explicitly request it with a configure option.
Leave a comment:
-
Where does the extra storage space usage come from? And ram?
The script would run, then the shell would exit, right? Most systems run a shell at least once anyway, so any shared libraries are already loaded into memory. And we're removing code in order to replace Xfbdev, etc., anyway, not to mention the binary isn't there anymore. Shouldn't that cut down on used disk space?
These are honest questions, correct me if I'm wrong.
Leave a comment:
-
(Or, drop it and replace it with a script that passes the appropriate options to Xorg/fbdev, resulting in no loss of functionality whatsoever.)
Leave a comment:
-
Originally posted by Ibidem View PostXvfb:
Used by several packages' test suites, for automated testing. Drop it, and iceweasel/firefox/... have to
A. Drop automatic testing on X11, OR
B. Run test suites as root (not fakeroot, full root) (means packages must be built as full root)
Also, Xrdp does have reasons for existing.
Originally posted by Ibidem View PostXephyr:
Don't think about dropping this, until users can specify drivers or X autodetects when it's run nested via DISPLAY.
Useful for keeping experiments confined to one X server, while working on stuff separately.
Originally posted by Ibidem View Post[rant]
Oh-and-by-the-way,
Whoever thinks xaa should die had better fix up EVERY driver that still needs it before they commit the change. Breaking embedded hardware like this is NOT the way to win the market; most such boards use a non-EXA driver.
The argument that "the drivers are obsolete and rarely used" is about as intelligent as a desktop user saying "We should really get rid of Apache--it's rarely used, and has had several security holes". You may not see the users, but that doesn't mean they're not there; it's just a different field.
Do you really want Windows CE/Mobile/whatever MS named it today taking over the embedded market?
[/rant]
Anyway, as I pointed out, XAA is only ever used if you're not using a compositing window manager, and not using XRender, and not using double-buffering (even if it is client-side, like GTK and Qt have done for years now), and not using GL. So, um, that would be xedit, xterm and anything with Xaw (but not Xaw3d!) then. And even then, it only offers an advantage over EXA with unmaintained drivers where no-one is willing to provide any work on them.
I don't mind conceding that part of the embedded market - not least because it's nowhere near 70% and in fact not even close to 1%, so your Apache argument is pointless and irrelevant.
Leave a comment:
-
Originally posted by Sadako View PostSo it's better that users have no software than buggy software?
I've used Xnest, Xvfb and Xephyr for various things in the past, and would hate to see them go.
At the least, I really think they should wait 'till all the functionality of these servers which aren't currently available in the DDX drivers are implemented first before removing the servers, it'd provide motivation for whoever wants the servers removed to actually get the work done, whereas if the servers are removed first then we will likely never see some of the functionality re-implemented, and will effectively be removing functionality for no good reason.
Originally posted by Sadako View PostAnd before someone mentions "removing 30,000 lines of code" as a good enough reason, I wonder how much of that code actually affects the Xorg server itself?
Pretty sure they're all separate code trees within the source tarballs...
Leave a comment:
-
Originally posted by Ibidem View PostThat fellow is doing a new design with Debian Squeeze/kernel 2.6.32 + Xorg 7.5, which is a far cry from 2.4 + XF86 (in case you weren't paying attention, the last Debian version with a 2.4.x kernel and XF86 was 3.1 not 6.0, so you're 5 years behind the times on that.)
The board isn't one I picked, it's one his company picked.
According to http://xorg.freedesktop.org/wiki/ExaStatus these are the drivers that still don't support EXA:
glide, glint, i740, imstt, newport, impact, rendition, trident, voodoo, apm, cirrus, neomagic, cyrix/nsc, sun, ark, chips, s3, tga, tseng
Do you really think anybody will start a new project based on one of those chips and latest software? Those are not even previous decade, rather previous millennium!
Originally posted by Ibidem View PostIf you're going to through out claims to 'refute' what I say, you could at least verify that they match reality and each other!
Much as you may want to think that what failed on the desktop is dead, that's wishful thinking.
Go find a PC104 board that has NVidia graphics of any age/ION, or an AMD Radeon 3xxx or better, or find any x86 board listed as "embedded" that's halfway up-to-date.
The closest I've seen is an Atom board and a few of Via's designs; those might work reasonably if the graphics work, but even 'new' designs have to be compatible with the old ones to some extent, and switching from PC104 to (say) micro-ITX may not be possible due to those constraints.
I've even found a company selling 'embedded' boards based on an AM186; they also carry an Am386 based system that comes with Linux 2.2.
I could point out several examples of out-of-date hardware if I wanted, but checking the aforementioned ones should prove that much of the embedded/x86 stuff is very much 'the last decade or two's failed hardware. Gripe all you like, but if the hardware is from the last decade, they're unusually current--or are you going to pay them the (wag) $20/device they'd spend on going with real up-to-date hardware?
And you are aware that x86 is not the most popular architecture in the embedded market, right?
Leave a comment:
-
Originally posted by Ansla View PostWhere did you see an embedded system running uptodate software? Such obsolete hardware is most likely still running Linux 2.4 with XFree86.
And nobody is going to switch their EOL hardware to M$ crap, M$ wouldn't offer support anyway. Only for new hardware there is this chance, and they drop old code so that they can provide better features/performance for new hardware, so where is the problem again?
Or do you think embedded means last decade's failed desktop hardware? Because that's what the link you posted suggests.
That fellow is doing a new design with Debian Squeeze/kernel 2.6.32 + Xorg 7.5, which is a far cry from 2.4 + XF86 (in case you weren't paying attention, the last Debian version with a 2.4.x kernel and XF86 was 3.1 not 6.0, so you're 5 years behind the times on that.)
The board isn't one I picked, it's one his company picked.
If you're going to through out claims to 'refute' what I say, you could at least verify that they match reality and each other!
Much as you may want to think that what failed on the desktop is dead, that's wishful thinking.
Go find a PC104 board that has NVidia graphics of any age/ION, or an AMD Radeon 3xxx or better, or find any x86 board listed as "embedded" that's halfway up-to-date.
The closest I've seen is an Atom board and a few of Via's designs; those might work reasonably if the graphics work, but even 'new' designs have to be compatible with the old ones to some extent, and switching from PC104 to (say) micro-ITX may not be possible due to those constraints.
I've even found a company selling 'embedded' boards based on an AM186; they also carry an Am386 based system that comes with Linux 2.2.
I could point out several examples of out-of-date hardware if I wanted, but checking the aforementioned ones should prove that much of the embedded/x86 stuff is very much 'the last decade or two's failed hardware. Gripe all you like, but if the hardware is from the last decade, they're unusually current--or are you going to pay them the (wag) $20/device they'd spend on going with real up-to-date hardware?
Leave a comment:
Leave a comment: