Announcement
Collapse
No announcement yet.
KDrive, Xnest, Xvfb Called For Removal From X.Org
Collapse
X
-
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.
-
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.
Leave a comment:
-
Originally posted by curaga View PostAs 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?
Originally posted by curaga View PostYou 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.
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.
Originally posted by curaga View PostSorry, 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.
Leave a comment:
-
Originally posted by daniels View PostIn 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.
Looks like XFree86 4.8.0.
Leave a comment:
-
Originally posted by daniels View PostCertainly 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)
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.
Leave a comment:
-
Originally posted by curaga View PostIt 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.
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.
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
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.
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).
Leave a comment:
Leave a comment: