[Registry] Re: LinuxRegistry in Freedesktop & KDE

[Avi Alkalay]

> I think you'll find that a huge amount of retraining is needed. And
> don't think it's a one off job, either - they'll be a constant flow of
> admins from Solaris or HP-UX, who'll be surprisingly lost in a sea of
> tiny text files.

The idea is not to edit tiny text files. Actually you guys should stop
thinking in this tiny files.
Start thinking in a namespace. And then forget it again.

The LR's idea is to provide a consistent infrastructure to let creation
of apps' configuration UI to be as easy as 1-2-3.
I'm not talking about a simple KDE key editing tool, but a high level UI,
application oriented, that will ask you human questions, like "Where is
your HTML documents folder", and will change the correct keys behind. You
don't have to know which key it is.

But, as advanced sysadmin you are, if something goes wrong, in extreme
situations, you can manually lookup and edit the keys with vi.




> The majority of sysadmins I know would be perfectly happy to use some
> form of cosy UI to do their day to day work, as long as they can hit the
> real files when things go wrong.

Linux Registry was designed for them, as I cited above.


> The problem is that each key has semantics - a simple key editing tool
> is no better than vi, and quite possibly worse, given the lack of
> contextual information presented. The key editing tool must know the
> semantics of the key it's editing.

Read my first comment. But for that we need an applications ecosystem
around LR, which is only the infrastructure.


> 
> >   And we code not only for end-user usability. What about system
> > administration? Isn't it useful to share desktop background's
> > preferences, keyboard layout prefs, mouse prefs? And then we could speak
> > about file formats, and the tons of code needed to parse every
> > configuration file in every piece of unix software.
> 
> Oh dear.
> 
> Firstly, it's trivial to code a parser for a simple key: value formatted
> config file. Secondly, that code exists in those apps, and is very well
> tested. Thirdly, the newer 'desktop' apps handle all this functionality
> already, and do it through an API, so the code only exists once.

I disagree. Gnome has its own. KDE too. Samba also. The same for Apache,
XFree, Mozilla, mount, init, wget, rpm, etc.
Only in the above line we have 10 repetitions of the code that could be
the same.





> Actually, you don't need to parse the Apache config file to do that. You
> just need to write it, that's all. GConf, KConfig, ACAP, LDAP - all
> these things can store the apache config for you, leaving the config
> files intact for httpd to use, and allowing them to be used no matter
> whether GConf is running or not. An experienced sysadmin with *no*
> knowledge of any of these config systems can even deal with it if things
> go wrong, and have the configuration system reparse the file.

With LR he can too.




> 1) You'll need to read, and parse, a significant number of files simply
> that change that specific datum in a way that's useful to the user, with
> LR.

This is true for any key-value pair configuration system.






> 2) You'll need to search through multiple directories, too, with LR.

Same for GConf.




> I have 1078 lines in my httpd.conf. These include copious comments to
> remind me what I was doing. On the assumption that there's 500 lines of
> actual configuration data, and that LR stores them one file per line,
> that's around 1M of disk to store something currently taking (including
> the comments) 35K. That's considerably more bloat than Microsoft are
> capable of with Word. That's ridiculous.


Ridiculous is to visit a customer that just want to install an SSL
certificate in his Apache, and have no idea how to do that. This customer
knows Windows' point-and-click way, and feels confortable with it. This
customer wants to use Linux, but knows nothing about vi. The technical
person responsible for doing this configuration doesn't even know what
"Kate" (KDE text editor) means. She did it quite well in a Windows
machine last week, without understanding SSL concepts. To listen she
saing Windows is better then Linux because of these facts is ridiculous.
Oh, this is ridiculous.

Clearly, LR is not the solution for this. But providing a programatically
easy way to change software parameters will make high level UI
configuration software appear and consolidate in Linux distributions.
This is a change on how users use the Linux desktop.



> Let's look at it another way - a typical virtual host in Apache takes up
> a fraction of a block, but contains somewhere around 10 lines,
> typically. Assuming each line is a single key or directory, then you've
> takes up 40k of disk to store ~250 bytes of data. See? We have passed
> ridiculous, and moved into impressive.

This is an issue, but addresseable. Lets try to stop thinking in bits and
bytes, and start thinking in thousands of users feeling Linux to be easy
to use.

I work at the Linux organization of IBM, visiting dozens of customers
everyweek. They just need "ease of use" to migrate. KDE is easy enough,
Gnome also, but this is not true for Samba, Apache, XFree, etc.



> I think it's possible to store it less efficiently, if you really work
> at it, but without actually cheating and storing redundant data, or
> splitting up each value so you only store one byte per file, I can't
> think of a way. Finally, we move into Extreme.
> 
> I think you missed the original commenter's use of the word "extreme".
> If wasting disk space were a dangerous, yet hyped-up sport, LR would
> have a string of cult websites in garish colours, and feature
> prominently on the cover of glossy, expensive magazines dedicated to
> pointlessly wasting disk space, including reader's letters with titles
> like "75dpi PNG to 1200dpi TIFF - Far out!".

By the way, adding to the customer's story above, the machine she bought
to serve these 2MBytes total pages and images has a 76 GBytes HD. And
BTW, she expects to start Apache (and read his keys) once a year, or
less.





> I have to say, I'm still not clear on what LR actually gains us.
> 
> I see it gains a uniform method for setting a key, but given that the
> semantics of the key are undefined, the key must, by inference, only be
> set by an application, or human, which is fully informed.

Please see my comments above.

I want Linux to change the world. Is not changing in the speed I was
expecting.
I believe one of the reasons are bad infrastructure concepts hinerited by
old Unix systems.
I designed LR to try to address some of them.


Thank you,
Avi

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow