Re: desktop-base status (Was: gdm theme changes!)
On Fri, Nov 10, 2006, cobaco (aka Bart Cornelis) wrote:
> > First, the simple fact that it's a longish shell script run on each
> > login with intermediate files is scary.
> while it's fairly big, but it's not all that complicated. It has also had an
> adequate amount of testing to shake out any fundamental problems IMO:
> - it's been in Debian sinds may 2005
> - it has a decent and growing amount of users (around 175 currently
> according to popcon)
> -> given the above I don't see what's so scary about the shell script.
My critics goes to:
1) the length of the script, you might say it's simple, but it's still
plenty of commands to run on each login
2) the fact that it's shell
3) the fact that it creates temporary files (which might not even get
purged in all cases)
Being in Debian since 2005 isn't any proof of quality, you don't want
me to dig up a list of packages which are around since 2005 and are
awful. :)
> > Sample things which scare me right away:
> > - 20desktop:42:
> > #make sure we start with empty variables
> > KDEDIRS='';XDG_CONFIG_DIRS='';XDG_DATA_DIRS='';CHOICESPATH='';GNUSTEP_PAT
> >HLIST='';UDEDIRS=''
> > => IIUC, KDEDIRS set manually by an user in the past would be discarded
> correct, but that's not a problem IMO, here's why:
> - if the admin has allow-user-xsession set in /etc/Xsession.options the user
> can stil completely override the variables as set by desktop-profiles
> by providing his own .xsession
This still makes it a regression, sorry. It isn't even documented.
> - it's the local admin that decides what configuration sets are installed,
> and get activated when, which is as it should be since otherwise the whole
> idea of mandatory settings goes out of the window
Well, no, you should simply prevent people from setting KDEDIRS at all.
Users who were capable of setting it via a .zlogin or something are
also likely to be able to set it in konsole.
You seem to advocate desktop-profies as a protection against a flaw
in KDE; I can only answer that startkde should reset KDEDIRS if needs
be, not desktop-profiles.
Is it also correct that under ssh -X logins, "env" dirs aren't parsed
anymore for *.sh scripts to load?
> -> I fail to see what the user is losing here. Do you still think this is an
> issue?
The user is losing the ability to set KDEDIRS and everything that one
can base on this, which can be anything IIUC.
> > full of sort + cat + grep + cut + sh (!!) + expr
> > invocations, on *each* login; spawning commands has a cost, and will slow
> > all logins, even those that don't care about KDE settings
> > => bad performance-wise
> I don't think performance is an issue (my experience using desktop-profiles
> on my own systems jives with that, as does the fact that I haven't gotten
> any complaints from users about performance at all).
The fact that desktop-profiles isn't part of the default install might
explain why it was not benchmarked... You can not possibly claim that
spawning so many commands doesn't cost time. Time that wouldn't be
eaten by a solution such as the third one I proposed for KDE.
> to give some indication, on the 1.83Ghz intel box I'm sitting at:
> - 'time bash 20desktop-profiles' takes around 0.170s
> - 'time dash 20desktop-profiles' takes around 0.100s
You could consider a cold filesystem cache, at least for the files
specific to desktop-profiles; I can certainly understand that "cat"
will be cached, but /etc/desktop-profiles wont.
> -> I'll run some more comprehensive tests later on various machines I have
> lying around, including the old 300Mhz Pentium 2 clunker that's my oldest
> box that still works
And don't forget about "ssh -X" logins. We're talking about the
default install of any desktop task, including Xfce -- which is
commonly used under slow systems...
> Question: at what point would you find performance problematic?
I would find it problematic to add something which can add .5 s to login. I
find it problematic to chose the more generic solution than the faster
one when the problem is solved in both cases.
> > So, IMO introducing a package like this one on *all* desktop installs
> > in a no-go at this point in the release.
> agreed with 'at this point in the release', what about after etch is
> released?
We can talk about it again. Certainly, getting a bigger visibility
would help, but I must admit I wouldn't be satisfied by wider testing
*only*, as I listed many problematic points which do sum up. There are
chances that we will have implemented something for desktop-base in
etch, and hence wont need desktop-profiles for this task.
I'm also afraid that as soon as we add something to the default
install, we have to support it until the end of times, even if we find
a better solution later on or realize that desktop-profiles shouldn't
be installed: the package will have been installed on some systems by
default, and we will have to support such setups in dist-upgrades et
al.
> > If you consider the hook I proposed in the list of dirs scanned by KDE
> > for KConfig instead, it is far less intrusive and simply requires
> > running a merge at package installation time, not on each login.
> While I'll agree that it's less involved, and -in isolation- simpler.
> It intrudes in the kde startup in the exact same way (by setting up KDEDIRS)
> and is thus just as intrusive
No, it sets the config dirs, not KDEDIRS. It's also less intrusive in
that it only adds the mandatory stat of a KConfigrc, something which
all proposed solutions do, and not a chaing of KConfigrc, or a chain of
directories, or a set of commands to run, or files to generate and
remove, etc.
> > Second, per-login flexibility is not useful for desktop-base.
> it doesn't hurt either (assuming performance indeed doesn't prove a
> problem),
>
> using a desktop-base specific mechanism on the other hand means that for any
> later addition/change to KDEDIRS you now not only need to determine what
> you want but also how to get it giving that desktop-base is messing with
> that variable in startkde.
I can indeed perfectly see how this would be incompatible with
desktop-profiles, as desktop-profiles resets KDEDIRS. This means that
if the desktop-base snippet runs first, you're going to ignore it. On
the other hand, the proposed env snippet I suggested would be
compatible with any similar solution. Just not with desktop-profiles,
but I consider this a bug in desktop-profiles, really.
> You'd either have to append or prefix the desktop-base config set to KDEDIRS
> either way your preventing some additions, one of the following scenarious
> will be impossible:
> 1) override part of the settings of desktop-base (e.g. say replacing the
> wallpaper with the company logo)
> -> requires prepending desktop-base profile to the KDEDIRS containing the
> overriding profile
It is the same problem as trying to override the system wide wallpaper,
and only that. And it's not a real life problem.
The problem you describe is specific to what the desktop-base package,
and anyone who would like to override its KDEDIRS setting with a
different one could use *exactly* the same mechanism as desktop-base,
but with a higher priority than desktop-base, for example
/usr/env/09_set-kde-dirs-for-company-logo.sh.
Now, if I ask the same question against desktop-profiles, you're going
to answer that I simply have to write a desktop profile, and I'm going
to retort that this is breaking KDEDIRS and forcing people into
desktop-profiles.
> 2) have desktop-base override another profile (e.g. say add in the ubuntu
> kde profile with all it's tweeks but override the branding with that from
> debian)
> -> requires apppending desktop-base profile to the KDEDIRS containing
> ubuntu profile
The problem you describe is specific to what the desktop-base package,
and anyone who would like to override its KDEDIRS setting with a
different one could use *exactly* the same mechanism as desktop-base,
but with a higher priority than desktop-base, for example
/usr/env/09_set-kde-dirs-for-company-logo.sh.
Now, if I ask the same question against desktop-profiles, you're going
to answer that I simply have to write a desktop profile, and I'm going
to retort that this is breaking KDEDIRS and forcing people into
desktop-profiles.
> NOTE: startkde is the last step in starting KDE, which means that without
> hacking /usr/bin/starkde further it becomes impossibe to override
> the desktop-base value of KDEDIRS if it sets it there
No, you can still override desktop-base in the same way it changes the
KDEDIRS it finds in its env.
> > This is about setting the defaults.
> > For example, a derivative can simply edit desktop-base to change the
> > artwork of the whole distro. Sure, desktop-profiles permit doing more,
> > and one can still install desktop-profiles, it should work.
> derivatives vastly prefer not having to fork packages (and in the case of a
> CDD setting up a debian system for a certain need without needing to fork
> anything is the ultimate goal)
desktop-base already provides a way to override its themes in a clean
way, via alternatives...
update-alternatives --display desktop-background
Please note that the above is DE agnostic, which desktop-profile is
not!
> > > for KDE all it does is set up KDEDIRS to include the wanted
> > > configuration sets. As you say above you _need_ to do that, and
> > > desktop-profiles by itself doesn not add any configuration. Idem for
> > > the other frameworks using environment variables (i.e. everything but
> > > gconf).
> > No, the third proposal I made for KDE is not about setting KDEDIRS.
> * me goes to look at earlier mail again
> the 3th was patching kdelibs to hardcode an added configuration set?
> (didn't see the actual discussion about that, so if I'm misunderstading the
> intention here I apologise. can you give a pointer to the thread start?).
Yes, that's correct.
> In other words patch kdelibs so that the way default KDE configuration setup
> works on debian is substantially different from all KDE documentation, just
> to reach a result that can easily be had by using the kde cascading
> mechanism as it's supposed to be used, and is documented all over?
KDEDIRS is meant to be an end-user and end-administrator mechanism for
changing the KDE pathes. Upstream hardcodes pathes, and so should the
vendor/distributor if needs be.
> -> that's introducing a (be it probably simple) patch that has absolutely no
> change of getting integrated upstream, for absolutely no real gain, and a
> noticable loss (of accuracy in all the non-debian documentation about kde
> configuration)
You're correct, this is not the ideal way of solving the problem -- and
nor is desktop-profiles which breaks the expectation that I can set
KDEDIRS :) -- but it is a problem for KDE to solve that it has no
way for distributor to cleanly hook default values or mandatory values.
Check GConf, it solves the problem cleanly.
> > And FWIW, I still consider the solution to set KDEDIRS very ugly; I
> > only investigated this option because it requires zero patching of
> > kdelibs and was suggested by a KDE maintainer.
> I will point out though that variables are the mechanism used for cascading
> config by KDE, Freedesktop, XFCE, Rox, and gnustep (i.e. every framework
> but gnome/gconf).
But this is targetted at end-users / end-administrators, and *not* at
vendors / distributors. And GConf can also be tuned by env vars, yet
it still offers hooks good enough for the needs of a distributor.
> > It's nice you have ultimate goals that go beyond desktop-base needs,
> > but this is *too* generic, and your genericity has a high cost.
> at this point there's no indication of performance problems (but I'll come
> back with some test figures in a while)
> the script has had a reasonable amount of testing and seems stable sofar so
> no cost there either
> -> I fail to see what the high cost is in this case
If you can't tell the difference in cost between running more than 500
lines of shell, which is spawning processes and writing files, and a
one-liner changing the KDEDIRS, you should get a break.
If you can't see that scanning a list of KDEDIRS for each KConfig
lookup is longer than scanning one, you should also get a break.
Remember: *all* desktop and ssh -X logins on *all* hardware for *all*
users with the desktop task. And *all* KConfig lookups when running a
KDE application.
> > I can understand that you have some use cases where you want to change
> > KDEDIRS on each login because membership to a UNIX group changed, but
> > this is far from being common,
> on the contrary this is an extremely common scenario in the business market,
> but let me scetch it out:
> You have a bussiness/enterprise that has a lot of computerusers, depending
> on what groups the users are part of (sysadmin, secretary, sales,
> maintenance, developers, human resources, helpdesk, ...) you want to set up
> certain things differently for each group, you also want users to be able
> to use any workstation without having to do any special setup.
> To name a couple of things you might want to change according to group
> membership: Which icons are on the desktop. What's the start menu
> structure. What's put the panel. What shortcuts are listed in the
> open/close file dialogs. ...
Thanks, I got it the first time.
Here are other ways to handle the same problem:
- seeding the config when you actually create the user or change his
group
- running a crontab to update the settings periodically
I'll add to this that this isn't used for defaults settings at all once
the user has changed his background.
And users don't swith group that often.
Now, I have a perfectly similar problem I can show as well: SSH
authorized keys. There was a patch to fetch SSH keys from the LDAP
server additionally to .ssh/authorized_keys, it's now completely
unused, it was too painful, too slow, too fragile; GForge and SF.net
are generating .ssh/authorized_keys via cron, this is saner.
> > On an off-topic note, I think DEs are moving away from environment
> > variables as configuration source;
> hm? on what do you base that? Freedesktop decided to variables for config
> stacking, I haven't seen any noice on the xdg list about changing that
> -> that's not going away anytime soon.
That's very off-topic, but as app are getting started by dbus nowadays,
they can not rely on inheriting environment anymore. Environment vars
are a bad thing. For example, I can't decide to start an ssh-agent
when I'm already logged in as other applications wont see its
environment vars.
But a critic of environment variables has not to be made by me, Policy
takes care of shooting them down already.
<file:///usr/share/doc/debian-policy/policy.html/ch-opersys.html#s9.9>
> > the future looks like a dbus world.
> er, what does an IPC-mechanism have to do with configuration stacking,
> communication between programs and configuration of programs have no a
> priori relation AFAIK
The point is that if you start looking for a dbus world, which we're
marching to, you can not rely on env vars anymore. I'm not saying that
configuration will be conveyed via dbus, but that relying on the
environment to transport the configuration path is broken. GConf
instead configures the configuration path, which is the only sane thing
to do.
A way of fixing KDE would be to make it read /etc/kde/kconfig-path
which would be a list of KConfig firs, and append .kconfig-path to
this. I don't know how the broken KDEDIRS concept could be considered
in such as setup to keep backward compatibility.
> > I agree we need some form of categorization. update-gconf-defaults
> > demonstrates one way of doing this. I like the general concept, just
> > not the fact that it happens at login time,
> the alternative is extra work for the sysadmin as he then needs to
> regenerate/reevaluate static mappings each time he changes group
> membership, adds or deletes a user, ...
desktop-base and derivatives are about package installations first, not
about the per-login configuration. It's you who is introducing the
constraint that we need to be able to change the default background on
a per-login basis. I don't want to support this, and especially not
like this.
> > No, the case of a /usr/env/10_desktop-base.sh which would statically
> > set KDEDIRS to $KDEDIRS:/usr/share/desktop-base is very different from
> > the case where KDEDIRS is computed from a set of commands (possibly
> > expensive, such as looking up groups) and files.
>
> No group lookups will be done unless 1 or more profiles have a group
> membership requirement, likewise for shell command requirements.
> -> expense rises according to what you use, yes it's possible to add an
> expensive requirement but then that's the admins choice
> -> default desktop-profiles setup doesn't involve any 'expensive'
> requirements
I didn't say it looks up group each time, I said it is possibly
expensive because it might be looking up groups. And this is the only
de facto advantage of your solution: in the useful case where it does a
group lookup (which is NOT common) it can be very expensive.
Again, in the more general case where one does not have to do any
group lookup to do, people would still have to go through the hoops
of desktop-profiles.
Now, I don't think the discussion is not leading us very far: you
already agreed that this is a post-etch question, and as I said, we
should have a solution for the desktop-base/artwork configurability and
overriding problem for etch; this will probably make desktop-profiles
for etch+1 a non-candidate to solve this problem.
My gut feeling about desktop-profiles is this: you've built a hackish
workaround based on the only overriding interface that KDE and Xfce
provide because that was feasible and solved your problem. A far nicer
solution is to write a backend for each DE which permit implementing
any form of storage or logic, and even to aggregate the same data for
multiple DE in the same database.
GConf has a sample LDAP backend which demonstrates this. KDE is
lacking in this respect, and so is Xfce (AFAICT, or I hope we wouldn't
be discussing this).
I would recommend that people continue using the hackish solution
when they have the specific requirements/needs, but that we aim at a
clean backend-based implementation for the long term genericity that
you're asking for, and keep a simple solution covering the common case
simply.
Bye,
--
Loïc Minier <lool@dooz.org>
Reply to: