Linux registry project

[Haden]

Yes and this project does nothing more than add 1 more format to the mix. Do you really think this registry would be accepted by companies with commercial unixes like Solaris, Tru64 or HP-UX?

You are right, they probably won't. But, lets take such vision (I'm making this up, but I bet they would choose something similar):

1. Lets name root of "registry" /etc
2. Settle directory structure (high level) as much as possible, involve many parties.
3. Start converting programs, this would not break anything: my program stores "keys" in e.g. /etc/system/my_app/... Anyone has problems with that? Nope.. except "this guy uses new format, what a nut".
4. More programs convert, the smaller "original" /etc is, and one day - there are no old formats left, we are converted 🙂

 

[Haden]

How much more secure is it going to be?

More fine grained control, one either has access to whole config or doesn't, you could have access/not have to every key separately (they are files, permissions apply).
Probably not widely used, but it's possibility being offered.

 

[n0cmonkey]

Originally posted by: Haden

Yes and this project does nothing more than add 1 more format to the mix. Do you really think this registry would be accepted by companies with commercial unixes like Solaris, Tru64 or HP-UX?

You are right, they probably won't. But, lets take such vision (I'm making this up, but I bet they would choose something similar):

1. Lets name root of "registry" /etc
2. Settle directory structure (high level) as much as possible, involve many parties.
3. Start converting programs, this would not break anything: my program stores "keys" in e.g. /etc/system/my_app/... Anyone has problems with that? Nope.. except "this guy uses new format, what a nut".
4. More programs convert, the smaller "original" /etc is, and one day - there are no old formats left, we are converted 🙂

Take off the rose colored glasses. It doesn't work like that.

1. Your registry = /etc, Bob's registry = /reg, Sarah's = /system, Ctho9305's = /Software
2. Get a directory structure down. Sure.
3. Your app goes in /etc/system/my_app/, Bob's goes in /reg/software/my_app/config, Sarah's goes in /system/local/computer/software/configuration/my_app, and CTho9305 comes up with something absurd that he explains to me after I've been drinking and I start to think he's right before I pass out on my keyboard.
4. A couple of programs convert by adding more software because they have to continue using the standard/traditional setup because not everyone will switch.

Radical changes like this will not make it everywhere, so we're adding software to solve a problem that doesn't exist.

 

[n0cmonkey]

Originally posted by: Haden

How much more secure is it going to be?

More fine grained control, one either has access to whole config or doesn't, you could have access/not have to every key separately (they are files, permissions apply).
Probably not widely used, but it's possibility being offered.

And this could be solved by paying attention to the permissions of the config files. If someone doesn't need information on one part of the config, he won't need information on the rest.

 

[Haden]

Take off the rose colored glasses. It doesn't work like that.

Can't argue with that, but hell, IMHO it's worth trying, plus if more "authorities" would get involved maybe something could be settled (e.g. fd.org would push kde/gnome..)

 

[drag]

Originally posted by: n0cmonkey

Originally posted by: Haden

How much more secure is it going to be?

More fine grained control, one either has access to whole config or doesn't, you could have access/not have to every key separately (they are files, permissions apply).
Probably not widely used, but it's possibility being offered.

And this could be solved by paying attention to the permissions of the config files. If someone doesn't need information on one part of the config, he won't need information on the rest.

Actually. I like that NOBODY but root has permission to anything in /etc/ or /system/ configuration files.

Nobody has any access to anything outside their home folders, if you can help it.

That's the security system I like.


Root UID = access to everything. User UID = have access to jack sh!t outside their home directories.

What is so wrong with that?

If you have to have a user adminstrate the printers, then put them in the printer group. If users need to be able to perform certain administrative tasks, then set them up to do their tasks in the sudo configuration files.

If a system configuration isn't suppose to be world-readable, then put permissions on it's configution file that it can't be read by anybody outside the UID of it's parent appication/service.

If a system configuration file is suppose to be world-readable, then let it be.

If a system configuration file is suppose to be world writable, then that is BS and a security flaw and needs to be eliminated by more intellegent design.

 

[Haden]

And this could be solved by paying attention to the permissions of the config files. If someone doesn't need information on one part of the config, he won't need information on the rest.

Then no one is forsing to use, it's possibility.

It's like no one needs XDamage and other FD.o server extensions, and then take screen shots and do pathetic software blending on their own.

 

[Haden]

Actually. I like that NOBODY but root has permission to anything in /etc/ or /system/ configuration files

-rw-r--r-- 1 root root 1038 2004-07-10 18:05 /etc/passwd
reading isn't nothing.

 

[drag]

Originally posted by: Haden

Actually. I like that NOBODY but root has permission to anything in /etc/ or /system/ configuration files

-rw-r--r-- 1 root root 1038 2004-07-10 18:05 /etc/passwd
reading isn't nothing.

What do you mean? Why do you think we use shaddow passwords?

/etc/passwd is a legacy thing left over from ages ago. That's why we have PAM.

How is your registry going to solve this?

The only reason we even still have /etc/passwd is because their are billions of legacy applications left over that would require untold amounts of work to switch over to the newer PAM system. I doubt making a new registry for Linux will allow use to fix that.

Any other examples?

Fine grain = complicated. The more complicated you make something, the more likely it is to f*ck up. I am a real big fan of the KISS, even if it is inconvient sometimes.

 

[n0cmonkey]

Originally posted by: Haden

Actually. I like that NOBODY but root has permission to anything in /etc/ or /system/ configuration files

-rw-r--r-- 1 root root 1038 2004-07-10 18:05 /etc/passwd
reading isn't nothing.

There isn't anything I can think of in /etc/passwd that is a secret. Most of that information can be found out easily through other methods. That's why the passwords are stored in another file (/etc/shadow in Linux, /etc/master.passwd on *BSD).

 

[n0cmonkey]

EDIT: I hate fusetalk.

 

[n0cmonkey]

Ok, something funky is going on either with my browser or with the forums. Maybe this will work better (instead of quoting):

EDIT: I still hate fusetalk.

 

[drag]

Hating win registry (should they rename project? 😉) seems impact discussion very much.

That's probably a good idea to change the name. After all that's what people think your modeling it after.

The thing is is that people who use Unix like it because it's open, and easy to deal with. There are no complications like having to go thru a API to deal with things like configuration files.

And if the project is a actually good idea, they are going to have to do better then that DOC website to convince people of it.

The big things that /etc/ has going for it is that:
1. It works.
2. It's easy to understand and easy to work with. Some configuration scemes that people choose are crap, but for the most part by simply reading the configuration file you know what to do to edit it by the time your finished.
3. It's simple.

The Linux registry is anything but simple, it may or may not work, and so far isn't easy to understand.

I mean paired keys are easy thing to deal with sometimes, although my only real experiancee with them is a very negative.

But as a overall concept it is not easy to grasp, it's not easy to create a intellectall model of how it works.

Your talking about creating a programming API to deal with this stuff.

But what your telling me is that your creating a new type of /etc/ directory, but we already have that.

Why would any body realy care to go thru all that work? Why would the hundreds of thousands of programmers, developers, and hobbyists suddenly decide to rewrite all their applications to conform to this?

What I think would be a much better idea is to create a standard file format for doing configuration files, keep everything in the /etc directory and just let the application developers decide in what directory they want to stick their configuration files.

If they/you make a realy good and easy to use universal file format for configuration files, then people will quickly adopt it, and you get 90% of the benifits of the "linux registry" without having to practically rewrite the entire operating system.

That seems a much better idea then a whole new API-thingy.

Sorry if I come off a bit to argumentative, but I am sceptical of redoing something that already works.

But at least I am not the type of person that you have to convince, I don't develop diddly squat except for some crappy python and bash scripts. 🙂

 

[Sunner]

Aside from some very good points made above, I'm now officially hating it, because it's XML based.
Didn't read that far yesterday.

 

[Barnaby W. Füi]

I'm a big fan of KISS, and I don't see how creating 20 directories and 20 files just to replace a simple text file helps anything. If all we need is an abstract way to edit config files (i.e. ignorant of their actual location on disk), then it's very simple to write libraries which will look for files in various, standard places, and abstract the creating/opening/modifying/closing of them so that their locations and names are uniform and the app can be ignorant of them (and thus not need OS-specific hacks). As for the actual config file format, there are plenty of standardized config file formats and libraries for reading/writing them.

And people bitch enough about how abc software needs xyz feature; they'll just bitch more when the developers are busy converting to the "linux registry's" API, and more bug reports and feature requests get ignored or put off while they do so.

And like I said, I'm all for starting off from a clean slate, but unix is the wrong place to do it. People just simply aren't going to recode everything to deal with such huge changes. Utopia would be nice, but people never agree on what utopia is; also, it's a ridiculous amount of work to get there, and people have jobs, other hobbies, families, etc. 😉 For some reason, open source seems to attract lots of such false messiahs -- people who think they have the one magical answer to a problem, if only everyone would adhere to it, which of course they never do. People like this guy, for example. Idealism seems to be more effective in small groups of people; in huge communities like the unix/linux world, you probably need to be more realistic than idealistic (though some idealism is always nice).

 

[n0cmonkey]

Originally posted by: BingBongWongFooey
people have jobs, other hobbies, families, etc. 😉

:Q

 

[Barnaby W. Füi]

Originally posted by: n0cmonkey

Originally posted by: BingBongWongFooey
people have jobs, other hobbies, families, etc. 😉

:Q

Well, some do. 😛

 

[Haden]

Originally posted by: Sunner
Aside from some very good points made above, I'm now officially hating it, because it's XML based.
Didn't read that far yesterday.

Are you sure? One posible representation is creating xml file from keys and importing keys from xml back.

Anyway, it seems *nix administrators (correct me if I'm wrong) will have similar reactions.
Too bad, otoh, I hope programmers will nod their heads as the core idea (not nuances) is great.

Frameworks/APIs are problem in *nix world, "don't use it if you don't like it" doesn't fully apply: one doesn't give a s*t about end user application, but bad backends hurt everyone in the long run
(compare DirectSound/DirectMusic to gstreamer/arts/alsa/esound... from developer point of view).

 

[Klixxer]

Yet another format to edit config files in, as if the init.d, rc.(whatever) in rc.d or in etc and so on, i think that Slacks setup is best, you know the files you know where they are located, updates work and everything just kinda works.

I like my etc and my rc.(whatever) and rc.d files intact, i know how it works, it's easy to understand, easy to search, each folder and file follows the syntax i and so many others find easy.

It kinda feels like when Xandros tried to move to ONE folder for all apps, making it more like windows, anyone who installed it was confused.

Linux isn't windows, it was based on *nix, keep it the way it is, the smaller differences are easy to learn, a registry would just mess up things (and most probably break things and make it harder to find, good luck searching a full fledged server/workstation for a possible error when you know what you are looking for and could easily find the file but don't know what it is called in "registry")

Haden, yes indeed, let's compare Direct Sound to ALSA (which works just fine with arts/esound etc), what is your problem, my problem is the very implementation of DS and the various controls compared to ALSA where you write only one control and it works THROUGH ALSA in arts/esound etc.

You want to write one specific to work with arts and one to esound etc then you are just setting yourself up for a lot of unneccessary work.

(The mixer settings in ALSA are as good as any, there is no reason to dwell into further mixers and sound systems, especially since both gnome and KDE come with their sound servers (arts and esound) disabled by default these days and most people are moving either more into the KDE world or the more lightweight WM's wich have no sound system.

A few years ago, when SUSE was the only system with ALSA you might have been correct, but not now.

 

[drag]

Plus with stuff like dmix plugins (software mixing support) it pretty much removes the need for Arts and esound... (little sidetrack. I use Dmix on my laptop, the sound card sucks and doesn's support hardware mixing so that I could only play one sound at a time.)

(a little side track)

 

[Haden]

If you insist.
I can give you very simple example:

1. mplayer has plugin (called volume) which operates on sound stream to change its volume
2. alsaplayer has such algorithm build in
3. xmms arts plugin has similar algorithm build in
4. xmms alsa plugin has one too [btw, it is based on my patch which Havard took time to clean up/merge]
5. amarok has probably cleanest solution: arts supports effect attaching to stream, one of effects is StereoVolume

These are apps which I know for sure, xine/other probably has similar implementation or you aren't controling apps volume at all - you are controling pcm/main mixer.

How is it wrong?
Well, DS has BufferVolume method.

 

[Klixxer]

Originally posted by: Haden
If you insist.
I can give you very simple example:

1. mplayer has plugin (called volume) which operates on sound stream to change its volume
2. alsaplayer has such algorithm build in
3. xmms arts plugin has similar algorithm build in
4. xmms alsa plugin has one too [btw, it is based on my patch which Havard took time to clean up/merge]
5. amarok has probably cleanest solution: arts supports effect attaching to stream, one of effects is StereoVolume

These are apps which I know for sure, xine/other probably has similar implementation or you aren't controling apps volume at all - you are controling pcm/main mixer.

How is it wrong?
Well, DS has BufferVolume method.

1. Affects sound mixer in ALSA by default.
2. ALSA, well, it's standard Linux by now, so what is the complaint?
3. By default XMMS will not use arts, so what is the problem, sure, you CAN use arts with it, you have a choice to do so, is that a negative thing?
4. See three, alsa will use the oss compability by default, you can change it if you want to.
5. WTF is amarok? Is it a KDE app i have never heard of? Why would i want to use it and why would i want to use arts when ALSA does the exact same thing.

ALSA is a big step forward which has left arts and e-sound as choice apps, there is no real reason to use either anymore, ALSA will do whatever you want it to do, you send the stream if you want to, to the default port and ALSA will handle it, Linux Standard Audio has become as easy to throughput streams as arts has ever been.

Besides, i am running fluxbox or XFCE4, no arts, no esound, streaming works just fine.

There is a choice to run sound servers for KDE and Gnome, it is not a necessety and as a programmer you can pretty much just forget about it and use ALSA instead, if you want to play it safe, use OSS, Alsa still supports legacy OSS ports.

I am still not getting what your complaint is, there IS a standard for Linux that works very well for all the aspects you have mentioned (and is a helluvalot easier to program for than DSound if you ask me) just like there is one for Win, BTW, there are still a legacy that Dsound is just another layer of, it directly interfaces with your hardware, just like ALSA USED to do ontop of Open Sound System in SUSE's application of it.

So you do have the same problem with Win, besides, what about midi, completely separate in Dsound (non-existent) while included in the same driver as the Digital Sound driver in ALSA, isn't that a smoother solution, as long as we are getting into sound apps and programming for sound, you cannot expect me to forget about MIDI. (if you are starting to program sound for Linux i suggest you take a look at the MIDI part of ALSA, it is extremely capable and can save you a lot of headache if you need it)

Wow, that was a rant, nothing personal against you though. 🙂

 

[Haden]

Ghm, don't want to dwell totally away from thread, but can't leave your post unanswered, as you didn't understand my point at all.

First, alsa is the way to do coding for sound, right? Then nearly every app coded using alsa would have to implement their own software volume control (which is done now),
or, which you seem to think is ok, use primary mixer.
The problem is, mixer is for mixer applications, if one has xmms playing and lowers its volume, one doesn't expect to lower main output volume of all apps now does he?
Standart application should never touch mixer, if told to play silently _it_ must play silent, not everything.

Thus the framework is faulty, and what happens is applications get coded "wrong" (either ignorance, or implement my own approach) - all will "suffer" in long run, which is my point of previous post.

 

[Klixxer]

Originally posted by: Haden
Ghm, don't want to dwell totally away from thread, but can't leave your post unanswered, as you didn't understand my point at all.

First, alsa is the way to do coding for sound, right? Then nearly every app coded using alsa would have to implement their own software volume control (which is done now),
or, which you seem to think is ok, use primary mixer.
The problem is, mixer is for mixer applications, if one has xmms playing and lowers its volume, one doesn't expect to lower main output volume of all apps now does he?
Standart application should never touch mixer, if told to play silently _it_ must play silent, not everything.

Thus the framework is faulty, and what happens is applications get coded "wrong" (either ignorance, or implement my own approach) - all will "suffer" in long run, which is my point of previous post.

Eh, no, ALSA (these days kernel) modules provides an interface to control the mixer, including the various interfaces towards all controls you can possibly want, i know i have more than i can handle, i need half of them, it even support an extensive equalizer as a core module.

So the mixer (and the volume controls for PCM, MIDI, BASE and so on) for the various interfaces is provided by ALSA, so you program for the INTERFACE, you do not need to reinvent the wheel and do your own volume control or bass boost or equalizer setting or surround for your app, you just need to learn how to program for the existent interface.

In xmms, if you lower volume and use the standard plugin, you will lower the PCM volume, not the main volume, same goes for all other apps, unless, of course you choose to link PCM to Main, you have that choice, but only a complete moron would even think of doing that.

.Thus, whatever you are talking about, you assumed and you were wrong from the first assumption and you have been wrong about everything you have written in this thread since then.

As i said, it is nothing personal, but i REALLY dislike it when people who do not have the slighest idea of what they are speaking of starts spreading FUD.

And as it is nothing personal, let's just move on now and forget, hopefully you have learned something, maybe you will even look into Linux one day.

 

[Haden]

Not realy, so you are telling me that you can have to for example several xmms instances running, affect volume on one (using alsa plugin, ant not using software volume control), and other instance volume is unaffected?
If it is so, I'm very surprised, as well as bunch of other people which are programming applications I've mentioned and wasted their time to implement software volume controls.