[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Sean Middleditch]

On Wed, 2004-04-21 at 11:29, Avi Alkalay wrote:

> I didn't know UNIX file persmission are ineffective. Can you tell us with
> your extensive sysadmin experiences on how it made you loose data or let
> hackers get in?
> Maybe I understood what you mean: You want some kind of SSL
> X509-certified access to files. Well, UNIX FS will never do it. You'll
> have to stack software to achieve it.

Maybe you should read the next bloody paragraph in my mail before typing
several paragraphs of pointless response?

> 
> 
> > A daemon can provide more powerful access control (by authenticating the
> > user connecting to the daemon and using built in ACL policy geared
> > specifically for configuration management), as well as enforce logging
> > of key changes and fix race conditions on keys that LR can't handle
> > (which are both major security issues).  The daemon also means that the
> > configuration tools themselves do not need to run as root, which is very
> > important given that graphics toolkits generally aren't that secure (way
> > too much code that's highly complex in nature).
> 
> Oh really? How can a daemon know which user had connected to him? Maybe
> passing an XML document describing its UID? Oh yes. Aren't XML generated
> by the user?

By authenticating said user, they same way other daemons do it, such as
X11 or D-BUS.  Perhaps you should read up on such techniques and
understand them before dismissing them.

> 
> About race conditions, I allways said you'll need an additional layer of
> software, and pay the specialization consequences. Many software don't
> need it. LR is designed to be for generic use.

It isn't generic if it doesn't work everywhere.  And as soon as you add
tha tlayer of software, LR is useless, because all it becomes is a
low-level file store, and one that isn't that good.

> > All of these issues are present with current file-based configuration
> > systems, yes, but if you're going to make people switch APIs and loose
> > all existing experience and knowledge regarding configuration their
> > systems, perhaps you should try to fix these real problems (among the
> > others we've raised already, like network-shared configuration, change
> > notification, value/type constraints, etc.) and not just worry about
> > something as trivial and irrelevant as file format...
> 
> Yes, the small number of experienced UNIX people will have the new OPTION
> of doing point-and-click to consistently configure Apache, for example.
> And the big majority of Windows users will GET THE ABILITY to use Linux.

Or alternatively they can use one of the many available Apache graphical
configuration tools that have been in existence for years and do not
need to break any existing tools, scripts, etc.  LR offers Jack and shit
for graphical configuration tools, and Jack left town.

> > >    bash# rg vi system/sw/XFree
> > > 
> > > And vi will pop with an XML vision of your keys. Then you'll change and
> > > save it, and rg will find what you changed, and apply it.
> > 
> > That's not much better than one file per key.  If you're going to add
> > hacks for linear editing of keys, provide it in a format users can
> > safely, easily, and efficiently edit, not a format intended for machine
> > parsing.  Most apps that have introduced XML config files have gotten a
> > *lot* of flak from users because it is such an incredible pain to work
> > with compared to other file formats, like those you're trying to get rid
> > of.
> 
> The way user will be able to edit their configurations is
> point-and-click. This is the only way accepted today in real world
> businesses. Anyway I needed an (very very simple) XML format for dumping,
> reloading keys.

If you have one file per key, why do you need a new format (and all that
extra bloat, code, dependencies - how evil of you!) when we have tar?

> Programatically, and for security, 1 file per key it is still better.
> Speed is an issue yet.

You've yet to prove either of those points, other than just re-iterating
that mantra repeatedly while ignoring the problems we've offered.

> > That's great for Apache.  You're not pushing LR for Apache, you're
> > pushing it for the entire system.  You can't assume that since it's not
> > bad for one daemon in one use case that it's therefor not bad for the
> > entire system.
> 
> I'm ready to assum that, with a very open mind. But honestly the issues
> are still smaller then the benefits, in my vision.

That statement is about as telling as any with regards to the whole
design... we don't need assuming open mind in design.  We need the
problems solved.  We don't need assumptions made based off of Apache's
needs in one specific sistuation, we need real engineering to fix the
real problems faced by the hundres/thousands of real applications that
aren't Apache.

> > And boot up time *does* matter.  Users don't want to wait for their
> > machine to boot.  Many desktops (and especially laptops) need to boot up
> > a lot more than once per 6 months, often many times per day, and these
> > systems have slower disks than most servers.  Laptops especially need to
> > avoid file system traffic as much as possible because spinning up the
> > disk (or keeping it spinning for longer than necessary) slaughters
> > battery life.  The less seeking and traversal the disk has to do, the
> > better.
> 
> 
> >From BASH man page, BUGS section: "It's too big and too slow."
> But nowbody dreams to port all Linux startup scripts to C. Why? Because
> to keep everything open, editable, and flexible it is absolutely required
> to stay this way.

First off, many systems don't use bash during startup.  Most of the ones
that do are indeed slow and users do in fact complain about it.  Second,
even if Bash is forced on a some systems, that doesn't mean we should be
forced to put up with the problems of LR as well.  Especially when LR is
fixable.

> 
> LR has issues, I admit and want to address them. But its goal is to
> provide programatical flexibility, while not killing the human readable
> paradigm.

Which is a noble goal.  It just isn't worth the problems, yet. 
Especially not when it *will* require effort on the parts of app
writers, administrators, tool developers, script authors, etc. to switch
to and in the end doesn't actually offer anything we don't already
have.  Offer more features than just a new file format and it's much
more likely to be useful.

Really, though, this is the wrong place to be discussing this at all. 
Even if FreeDesktop.org bought into LR, it's 100% useless if the actual
apps don't use it.  Get Apache to convert, get Bind to convert, get
KConfig to convert (and not in experimental tests, either) and then, if
those (and other apps) start using it, it will become standard.  There
are tons of standards bodies that have tried to push some various
technology/protocol/whatever which failed because developers didn't
care.  Those app authors can also likely give you much more specific and
to-the-point feedback than we can.

> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.