KDrive, Xnest, Xvfb Called For Removal From X.Org

[daniels]

Not really, though it's certainly smaller to make the Xorg internals a fair bit smaller, and possible to make the ruleset very, very, very, very much smaller. To be honest that'd probably be size-competitive with parsing the console keymaps and mangling them into XKB keymaps.

[curaga]

OK then. Would you say whether it would be possible to skip the 3.6mb rulesets, 400kb library and compiler entirely, without removing the X-internal xkb parts?
I'm thinking it wouldn't be many lines of code to read the console keymap and load it into Xorg's internal xkb representation. Not that I know, merely guessing.

That would certainly be a huge improvement, though I'd certainly like to see the 500kb of Xorg-internal xkb removable too.

[daniels]

As shown by your own numbers, it's not only the ruleset: the size of the Xfbdev binary itself is near doubled. Is that only the xkb code? Or something else too?

A mixture of making XKB mandatory, and other stuff we pushed from Xorg into common code.

You clearly know XKB well, but it seems you haven't considered the alternative.

Please tell me why work should be spent on making the rulesets smaller, when not using them entirely is the better option. The code path that simply uses the console keymap surely still exists?

Shipping all console keymaps is 140kb compressed, and those are enough for most western languages. Not shipping a keymap at all is also sometimes done when there's no need for one.

I have considered the alternative, and I still maintain that it's the better option. Argument by assertion isn't much fun though, so I'll say that I think it's better due to greater maintainability, not having to have two completely separate and unrelated rulesets (see, e.g. cxkb, which allows you to use XKB keymaps on the console), and due to being used by a far, far greater number of people than the alternative which was basically untested.

So yeah, I'd much prefer to see XKB's worst flaws (mainly its size and complexity) fixed than maintain two options, only one of which sees any development or testing, when the interactions between the two are so incredibly complex as to be a significant source of problems on their own.

Sorry, the amount of work in making current Xorg smaller far exceeds the cost of possible local exploits in a controlled environment. Only speaking for myself of course, but I'm also no X dev.

No problem - it's your environment, so it's up to you to judge the importance of numerous local and remote code execution vulnerabilities.

[Ibidem]

In that case, I have no clue which Xfbdev you're shipping, since XKB has been mandatory for all of our servers for over four years now. If you took a four-year old version of Xorg too, then you could disable XKB from that and save 4MB. You're making a pretty pointless comparison.

http://distro.ibiblio.org/tinycoreli...rc/Xvesa-base/
Looks like XFree86 4.8.0.

[curaga]

Certainly it's a shame that the xkeyboard-config ruleset is so enormous; I've been toying with the idea of a minimal ruleset (for many reasons) for some time now. Hopefully I'll actually get around to it, but it would sure be nice if the crowd who needed a stripped-down server supported us by helping with things like this rather than just rubbishing everything on forums four years after the fact.

As shown by your own numbers, it's not only the ruleset: the size of the Xfbdev binary itself is near doubled. Is that only the xkb code? Or something else too?

If you want to help get involved, here's some ideas:
- add a configuration option to only install a very minimal ruleset (evdev / pc105 / US only), plus the resulting XML file
- add a configuration option to disable translations, and strip down the XML file to remove those translations
* - help with the ongoing effort to simplify the ruleset, particularly within compat and types
- possibly look at merging back the xkbcommon changes into xkbcomp, as well as making that generate a shared library the server could use instead of forking xkbcomp to produce an XKM file, then parsing that XKM file with resultant loss of information (libxkbcommon won't ever expose everything the X server needs to know)

You clearly know XKB well, but it seems you haven't considered the alternative.

Please tell me why work should be spent on making the rulesets smaller, when not using them entirely is the better option. The code path that simply uses the console keymap surely still exists?

Shipping all console keymaps is 140kb compressed, and those are enough for most western languages. Not shipping a keymap at all is also sometimes done when there's no need for one.

That way everyone benefits, and you guys don't feel compelled to ship a four-year old X server with no end of known security vulnerabilities.

Sorry, the amount of work in making current Xorg smaller far exceeds the cost of possible local exploits in a controlled environment. Only speaking for myself of course, but I'm also no X dev.

[daniels]

It is hardly a pointless comparison. It's an X server that fills a need versus another that has 4mb of cruft that cannot be disabled.

In essence, it's showing that you've made something mandatory that causes 4mb of bloat that is not needed in some cases.

Yes, although the net benefit was the ability to remove huge tracts of code which were horrifically complex and error-prone. It fixed several real problems with the server and widened the scope of people who understood keyboard handling within the server from one to many. I stand by it, and I'd do it again today.

Certainly it's a shame that the xkeyboard-config ruleset is so enormous; I've been toying with the idea of a minimal ruleset (for many reasons) for some time now. Hopefully I'll actually get around to it, but it would sure be nice if the crowd who needed a stripped-down server supported us by helping with things like this rather than just rubbishing everything on forums four years after the fact. If you want to help get involved, here's some ideas:
- add a configuration option to only install a very minimal ruleset (evdev / pc105 / US only), plus the resulting XML file
- add a configuration option to disable translations, and strip down the XML file to remove those translations
* - help with the ongoing effort to simplify the ruleset, particularly within compat and types
- possibly look at merging back the xkbcommon changes into xkbcomp, as well as making that generate a shared library the server could use instead of forking xkbcomp to produce an XKM file, then parsing that XKM file with resultant loss of information (libxkbcommon won't ever expose everything the X server needs to know)

That way everyone benefits, and you guys don't feel compelled to ship a four-year old X server with no end of known security vulnerabilities.

[curaga]

It is hardly a pointless comparison. It's an X server that fills a need versus another that has 4mb of cruft that cannot be disabled.

In essence, it's showing that you've made something mandatory that causes 4mb of bloat that is not needed in some cases.

[daniels]

In that case, I have no clue which Xfbdev you're shipping, since XKB has been mandatory for all of our servers for over four years now. If you took a four-year old version of Xorg too, then you could disable XKB from that and save 4MB. You're making a pretty pointless comparison.

[curaga]

Hm, checking the xserver git master seems xkb cannot be disabled. That's 4mb more of Xorg.

So, using your stripped number, it's 650kb vs 5.6mb.

[curaga]

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.

The Xfbdev binary we ship is 646.5 kb. All the XKB things you mention are not needed with Xfbdev.

I'm also not getting why you're not listing all of the Xorg's internal libs (libcfb libmfb libint10 etc etc), but only those. How can an user tell which can be deleted of them? ldd doesn't show anything as depending on them.

Oh right, the OpenSSL dep, I had forgotten about that! Thanks for the reminder

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).

It's not a general purpose box usually that is that space conscious or runs Xfbdev. You can often not use gtk, qt, cairo, pixman and folks.