Am 30.10.2012 04:16, schrieb John VanSickle:

>>> In fairness, it's not /completely/ identical. The folders are called
>>> "keys" under Windows, whereas Gsettings calls them "schemas". Both
>>> systems store this stuff in a binary file, but Gsettings loads the key
>>> definitions from XML files and "compiles" them into binary.
>
> Okay, but why compile them?  It's not like drive space is a scarce
> resource anymore.

Faster access, maybe?

>> Snort.. Actually, the problem with the windows registry are:
>>
>> 1. Can't read the damn thing, without the editor.
>>
>> 2. Things don't always uninstall cleanly.
>
> That's mostly the uninstaller's fault.  I suppose there's a utility that
> allows you to record the registry changes made by an installer, so that
> when the utility is uninstalled you can follow up and scrub the registry
> completely.

Except when the installer doesn't know that the application itself does 
make additional changes to the registry.

Or when the installer makes a change to parts of the registry that other 
installers are also likely to touch, and un-installing isn't done in 
reverse order.

> 5. All of your eggs are in one basket.  Yes, let's put the settings for
> your application, Jack's application, and the drivers for your hardware
> devices, all in one big file.  That won't cause any problems, no sir.

 From Orchid's postings, I gather that the Gsettings concept is 
different in this respect, by having the applications just add or modify 
their own private XML file, and then compile all such XML files into one 
blob (for, as I suspect, faster access).

Post a reply to this message

> Am 29.10.2012 14:33, schrieb Francois Labreque:
>
>>  > (After all, Unix doesn't have ACLs for files yet.)
>>
>> WAT?
>>
>> Have you ever typed "ls -l"  ?  Do you know what the "rwxr-x---" mean on
>> the left hand side.
>
> And you know that ACL is an acronym for "Access Control LISTS", right?
>
Yes.

> Full-fledged ACLs do allow you to specify individual access rights for
> an arbitrary number of users and/or user groups, not just for the owner,
> one user group and the rest of the world.
>

I know that too.  But Andy was exagerating slightly (what else is new?).

> BTW, some commercial Unixes like HP-UX do provide proper ACLs (they even
> use that very term for the feature).
>

And recen versions of Novell's NDS are exactly that too.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

> On 29/10/2012 01:33 PM, Francois Labreque wrote:
>>> (After all, Unix doesn't have ACLs for files yet.)
>>
>> WAT?
>>
>> Have you ever typed "ls -l" ? Do you know what the "rwxr-x---" mean on
>> the left hand side.
>
> No deary. I mean being able to set an *arbitrary* combination of
> permissions.
>

Then if that's what you mean, say that.  ;)

> If you have a folder and you want all the people in QA to have read-only
> access, the people in Helpdesk to be able to create new files but not
> modify existing ones, and the guys in Development to have full
> read/write access, you can actually do exactly that with NTFS file
> permissions. Good luck trying to do it with umask...


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>  From Orchid's postings, I gather that the Gsettings concept is
> different in this respect, by having the applications just add or modify
> their own private XML file, and then compile all such XML files into one
> blob (for, as I suspect, faster access).

This is quite a good idea, because then it's up to the OS to decide how 
to handle conflicts (eg if two apps try to set the same thing in their 
own XML). Also then when you uninstall you can just delete the XML and 
know that any settings from that app no longer have any influence. In 
Windows on the other hand it's simply whichever application changed the 
value most recently that wins.

However does this mean that every time a program writes to the registry 
the OS must recompile everything?

Post a reply to this message

On 30/10/2012 04:11 PM, scott wrote:
>> From Orchid's postings, I gather that the Gsettings concept is
>> different in this respect, by having the applications just add or modify
>> their own private XML file, and then compile all such XML files into one
>> blob (for, as I suspect, faster access).
>
> This is quite a good idea, because then it's up to the OS to decide how
> to handle conflicts (eg if two apps try to set the same thing in their
> own XML). Also then when you uninstall you can just delete the XML and
> know that any settings from that app no longer have any influence. In
> Windows on the other hand it's simply whichever application changed the
> value most recently that wins.
>
> However does this mean that every time a program writes to the registry
> the OS must recompile everything?

Compiling just creates the key names and their default values. Actually 
reading and writing doesn't require recompilation.

Also, recompiling takes approx 400 ms on my virtual machine...

Let me just repeat again: Settings have default values. And textual 
descriptions [which are often less helpful than you'd like].

Under Windows, if you mistype the registry key, it just creates a new 
key [which then uselessly does nothing]. Under Gsettings, it whines "no 
such schema" or similar.

The *really* annoying part is that Gsettings appears to totally stop 
working if X isn't running. It's also maddeningly hard to change another 
user's settings...

Post a reply to this message

On Tue, 30 Oct 2012 11:33:22 -0400, Francois Labreque wrote:

>> BTW, some commercial Unixes like HP-UX do provide proper ACLs (they
>> even use that very term for the feature).
>>
>>
> And recen versions of Novell's NDS are exactly that too.

Well, Novell's product (actually, NetIQ's product now - since they were 
acquired by Attachmate last May and the identity products have mostly 
shifted to the NetIQ business unit) is eDirectory, and it doesn't do 
filesystem permissions - it manages the identities used in filesystem 
permission entries in the directory entry tables in NSS and TFS volumes.

I wonder, though, how difficult it would be to use eDir identities as 
part of *nix ACLs - probably not hard, just need the RFC2307 (IIRC) 
extensions installed to map uid/gid to the OS, and integrate pam 
authentication with the LDAP server. :)

Jim

Post a reply to this message

On 10/30/2012 1:46 AM, Orchid Win7 v1 wrote:
>> Still, even something like,
>> "Export all keys specific to this application.", would have been nice.
>
> What makes you think you can't do that?
>
It can't. To do that would require exporting "all linked keys". That 
means that you search for, say, Explorer, and you don't get get the key 
"USER-Explorer-...", you also get the 5-6 hexidecimal keys for its 
components, keys in other sections, which relate, etc. You have to know 
what all of them are, and either mark them yourself, or export them each 
separately, as far as I can tell. And, just searching for what key you 
need is a pain in the ass sometimes (especially if it turns out that the 
specific thing you are looking for is one of those "hidden" settings, 
which is not normally in the registry at all, nor documented any place 
obvious, no accessible through any of the user menus).

Post a reply to this message

On 10/30/2012 1:40 AM, Orchid Win7 v1 wrote:
>>>> Snort.. Actually, the problem with the windows registry are:
>>>>
>>>> 1. Can't read the damn thing, without the editor.
>>>
>>> Why is that a problem? You always need some sort of software to read a
>>> computer file and regedit comes with Windows.
>>>
>> Uh.. Because the editor sucks
>
> ...which leads us back to "you're not supposed to touch this stuff
> manually".
>
> Ever tried using e2fstune? Not very intuitive, is it? Then again, how
> often do you even need to touch it?
>
>> (like, for example, listing all
>> related keys, in a filter of some sort, not using notepad, or a pad of
>> paper to write down keys, while hunting through a dozen extra searches
>> to find them all).
>
> 1. The registry editor is perfectly capable of dumping chunks of the
> registry as text. It also has a search function. (Admittedly it's not
> very scriptable.)
>
> 2. You can write your own application to access the registry. Hell, it's
> probably quite easy to throw something together in VB to do a quick
> search or two...
:snark: and how much of what that is supposed to do is "undocumented", 
in the same way that, prior to completely changing the system, you 
couldn't find any documentation on how the hell ActiveX interfaced with 
the scripting system, in their own editor, and Informal Exploder, so you 
could move them around on your "form"? :/snark:

That was about when I gave up looking to Microsoft's own documentation 
for anything useful. Here is how to add scripting: ... Here is how to 
create and use ActiveX controls: ... What, you actually want to, without 
creating new wrappers, and all the other BS, use the inbuilt ActiveX 
controls, with scripting, and, *Gasp!* go into "design mode" with them, 
so you can create custom layouts in your own applications? What, are you 
one something!? Yeah.. It would be nice to do that!!!

At the time ***one*** company I could find found a solution to the 
problem. There solution turned out to be, "Design controls that act 
exactly like the inbuilt ones, but which *we* could switch modes with, 
ourselves." The other solution was to leave them active, but wrapper 
them in a completely redundant method, which did nothing more than 
temporarily make them non-visible, draw a box where they where supposed 
to be, and provide drag handles. Redundant because this wasn't necessary 
in the original controls, in the compiler suite, they already have that 
functionality.

There are hints, all over the place, that its, at least in theory, 
possible to tell the OS to switch a specific form to that mode. There is 
jack all saying how, what messages to use to do it, etc.

Later, as I said, they, sort of, fixed this, but basically killing the 
old ActiveX entirely, and replacing it with something else, which 
included more sane methods to talk to, and get information back from, 
never mind instance, controls.

But, even the documentation for that is minimalist, and nearly useless. 
I have no idea if "design mode" is still something only a hacker, with 
detailed understanding of the OS internal messaging, has a clue how to 
access.

So, sure.. You can probably write something to access the registry, 
but... will it actually do what it claims to?

Post a reply to this message

On 10/30/2012 1:48 AM, scott wrote:
>> A lot of developers write magic numbers to the registry so that when
>> your trial period ends, uninstalling and reinstalling the application
>> will not reset your trial period.
>
> Is this method really used? There are programs to record all
> reads/writes to the registry, so you really can delete all the keys
> created. Or you just restore a backup of the registry to start the trial
> again. I suspect they are a bit more cunning than this.
>
Yeah, it is. There are very few programs out that track changes though, 
and they are usually "security" type things, like one called scoty (or 
something like that), which watch dog they thing, so look for odd 
changes, like something adding a new startup program some place (it 
catches everything doing that, so even legit stuff gives a pop-up, which 
can be interesting...) Other cases may be hidden files, in odd places, 
etc. One of the kind of interesting ones is a "give away of the day" 
thing, which doesn't actually demo, its installer actually registers it, 
within the 24 hours of the give away, and flat refuses to install it as 
a working application, if the server says "no".

But, in general, adding some sort of flag to the registry, with a date, 
or the like, is the simplest solution. So, in principle, if you knew 
what changed, you could undo it.

Post a reply to this message

Am 31.10.2012 04:14, schrieb Patrick Elliott:

>> 2. You can write your own application to access the registry. Hell, it's
>> probably quite easy to throw something together in VB to do a quick
>> search or two...
> :snark: and how much of what that is supposed to do is "undocumented",
> in the same way that, prior to completely changing the system, you
> couldn't find any documentation on how the hell ActiveX interfaced with
> the scripting system, in their own editor, and Informal Exploder, so you
> could move them around on your "form"? :/snark:
[lots of ranting about ActiveX deleted]

What, exactly, does that have to do with accessing the registry?

> So, sure.. You can probably write something to access the registry,
> but... will it actually do what it claims to?

The question is not whether it will actually do what it claims to, but 
whether you know what you want it to do.


Your list of things you'd like to be able to do includes "listing all 
related keys". Guess what - per definition of the registry, regedit does 
that already: The only "native" relationship of registry keys is in the 
hierarchical tree structure of sections.

Each and every other relationship between registry keys is only by 
convention of individual services and applications - such as the Windows 
explorer assigning file extensions to file types, and file types to 
applications. Or the device manager linking drivers to devices. Or what 
the heck.

At the end of the day, you DO need service- or application-specific 
knowledge if you want to edit the registry, because it's services and 
applications that assign semantics to the raw data they store in there.

Post a reply to this message