On Thursday 09 November 2006 17:37, Loïc Minier wrote:
> On Thu, Nov 09, 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.
though I agree that it's to late for etch given that desktop-base has an
order of magnitude more users then desktop-profiles
> 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
- 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
- stacking configuration sets is inherently a sysadmin not a user activity:
from a user standpoint it's about configuring his graphical apps, the
variables desktop-profiles deals with are a mere means to that end.
Since the user can still configure things to his heart's content by
changing that setting in 'his' config set in $HOME (as long
as the sysadmin hasn't made the particular setting mandatory) , he
shouldn't care.
NOTE : if for some reason there is a user that needs to be able to add
configuration sets, the admin can easily give him that possibility
by adding an empty metadata file writeable for the user
-> I fail to see what the user is losing here. Do you still think this is an
issue?
(NOTE: changing starkde to set KDEDIRS works fine and will override
anything desktop-profiles does as startkde is run after desktop-profiles)
> 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).
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
-> I'd say that this isn't even noticable though of course YMMV.
-> 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
Question: at what point would you find performance problematic?
> - 20desktop:46:
> PROFILES=`tempfile`
> => adds a *write* on login; and if I ^C my ssh, the tempfile isn't
> deleted (you might want a cleanup trap)
point, but minor concern at best:
even when left behind, it's in either $TMPDIR or /tmp, so it's not exactly
in the way and will get deleted eventually
> 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?
> 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
> 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.
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
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
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
-> special casing destkop-base profile setup is likely to cause problems in
at least some cases
> 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)
> > 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?).
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?
-> 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)
-> sounds like an extremely bad idea to me
> 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.
<shrug>
that's very subjective, and I happen to disagree.
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).
So obviously the mechanism is popular enough, and given that it's all free
software that probably means a lot of people agree with me on that count
</shrug>
> > As for being generic that's 'A Good Thing' as:
> > Ultimately it's the local admin that should (be able to) decide what
> > configuration sets get activated when.
> > In the presence of multiple agents providing configuration sets that
> > reuires a central, generic way of controlling them.
> > Where 'controlling them' means 'controlling of certain specific
> > environment variables' for all DE's but gnome, and in the case of gnome
> > as a whole (as opposed to single apps using gconf) you still need to
> > control the freedesktop variables in addition to the gconf sources.
>
> 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
> 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. ...
Maybe it's regional but the only busenisses I've encountered that don't use
such a scheme (and I work in ICT-support) are those that are so small they
can suffice with a peer-to-peer network with a handfull of pc's. I don't
think I need to tell you that windows policies are an extremely common tool
in business networks and they conceptually work exactly that way.
> 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.
> 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
> > In the absence of a central generic mechanism you end up with multiple
> > specific hacks all messing with the same variables, which means the
> > local admin needs to:
> > 1) identify all agents providing configuration sets
> > 2) figure out the necessary environment variables and the specific
> > semantics for each variable
> > 3) for each agent figure out how it sets up those variables
> > 4) figure out in which order the various agents variable set mechanisms
> > are executed
> > 5) given 3 and 4 figure out what the result is and then add in your own
> > hack to adapt it to what you want
>
> So, you're saying that your solution has a broader spectrum in that it
> can help an administrator to enforce a configuration upon all DE at
> once. Sorry, but I think this is bullshit: desktop-profiles doesn't
> hide the name of the actual GConf settings/KConfig items that one needs
> to change in order to say, set the background. What desktop-profiles
> currently do is permit configuring the order in which completely
> unrelated databases of settings are cascaded. How does that help?
simple:
the people creating the config sets are not necessarily the people setting
up the stacking (To put it in terms of the evil empire we're talking MSCA
vs MSCE)
e.g at the company I work we have 2 engineers who normally take care of
creating the windows policies, we have about 30 that are usually outhouse
at clients, who use the policies those 2 created and will (at most, and
that seldomly) fiddle with them a little.
With a sufficiently developped CDD infrastructure it's not much of a stretch
to imagine lots of people creating configuration sets and putting them
online (this is essentially the creative part of creating a livecd, and we
all know how many of those are around). We're not there yet, but clearly
heading in that direction.
> You seem to claim that suddenly, there is a one stop shop for
> configuring all of KDE and GNOME and Xfce in a couple of clicks
nope, that will come sloooowwwwlly through increasing Freedesktop
standarization (though it isn't likely to give the holy grail you mentioned
any time soon)
> > NOTE: agents definining configuration sets would be upstream, the
> > user, debian proper, various CDD's, the local admin, and (in bigger
> > organizations) maybe some central ICT-department.
> > -> at a minimum you'd have 2 sets: upstream and user
> > -> by default you'd have 3: upstream, debian proper (through
> > desktop-base), and the user
>
> 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, ...
(there's a reason windows policies are applied on-login and based on
membership of active directory groups/OU's. Turnover is often high, and
it's common to have lots of changes in groupmembership as projects get
started and completed, priorites and people get reassigned, ...)
> > NOTE: we'll already have desktop-base and debian-edu-config packages
> > providing configuration sets' (and other CDD's are sure to
> > follow), so the existence of multiple such agents inside debian is a
> > reality that needs to be handled.
>
> Yes. And I agree that desktop-profiles has a form of "priority
> handling" -- just like GConf has. Except in the end GConf offers a
> single database of merged settings for this use case, while
> desktop-profiles only cascades database of each use case, which doesn't
> scale well, but that's irrelevant.
which is why KDE uses a system config cache (ksycoca)
(but dealing with merging settings of different configuration sets is a
different issue altogether.)
> > > My biggest concern goes to the
> > > per-startkde run configurability instead of a simple per-package
> > > installation configurability;
> >
> > (? not sure If I'm getting your point here)
> > starkde is per-run just like desktop-profiles. And for all non-gnome
> > desktops (and for gnome where it uses freedesktop specs) where
> > talking about setting up an environment variable which, by
> > definition[1], is a dynamic per-run setting.
>
> 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
--
Cheers, cobaco (aka Bart Cornelis)
Attachment:
pgpQVG2XHBwBQ.pgp
Description: PGP signature