On 18/05/2011 06:20 PM, Darren New wrote:
> On 5/18/2011 8:28, Invisible wrote:
>> - File permissions. None of this chmod 664 nonsense. You can set
>> arbitrary
>> combinations of permissions for any number of users and groups.
>
> Yep. And the same permission framework works on every resource, not just
> files.

Yeah. Processes, printers, event logs, the registry. (Shame you can't 
use it for MS Access though...)

More importantly, you don't just have permissions for "read", "write" 
and "execute". The permissions are more fine-grained than that. For 
example, you can make it so a user can append to a file even though they 
can't read from it. Or make it so they can access it via the backup API, 
but can't read it normally. And so on.

> There's a handful of things you need to have "administrator"
> privs to do that you really should have a separate permission for (like
> reading the UNC journal), but not much.

There's a couple of things which are "privilages" rather than 
"permissions". For example, normally (under Windows XP) only members of 
Administrators and Power Users have the ability to start and stop 
services. It looks like this is hard-wired, but actually it isn't. 
Somewhere deep in the murky depths of the Control Panel, you can 
actually change this.

You can't change this in Windows NT v4, but you can in Windows XP. I 
should know. We had an issue where we wanted certain users to be able to 
start and stop services, but *not* be able to log people off the PC. 
Administrators can do both, normal users can do neither. In NT4, you 
can't fix this. In XP, you can assign both privilages independently.

There might be a tiny few things which really are hard-coded to 
Administrator (the user) and/or Administrators (the group), but I 
haven't run into that.

>> [But then they tried to retro-fit permission inheritance, which doesn't
>> actually work how you'd think it works. And don't even get me started
>> on the
>> whole Active Directory thing with three different sorts of security
>> groups
>> that nobody understands...]
>
> That is the basic problem with complex permissions. :-)

I assume that comment is directed at AD.

Regarding my first comment: With NT4, the permissions for an object 
default to the permissions of its parent at the time of creation. But if 
you change the permissions of the parent, the child's permissions stay 
the same. Except usually when you change the parent's permissions, 
there's an option to recurse over the children and set their permissions 
the same. Except that if you do this, any children who had their 
permissions deliberately changed get reset. In short, it sucks.

In Windows XP (and possibly Windows 2000), they added the ability for 
one object to actually "inherit" the permissions of its parent. That 
means that if you change the permissions on the parent, the permissions 
of all children change, *except* the ones which you've set to not 
inherit. Those stay the same. And any extra, child-specific permissions 
that aren't inherited don't get changed either. This is much better...

...except that it's still implemented the old way. In other words, each 
object still has the full permissions list on it, and changing the 
permissions on a parent object still recurses over all children. It's 
just that now permissions are marked to indicate whether they're manual 
or automatic, and only the automatic ones get futzed with.

Which means that changing the parent's permissions has the intended 
effect, but if the parent has 80,000,000 children, it still takes 
forever to set the permissions, because you literally have to touch 
every child and update its ACL on disk.

Still, it's much better than what existed before.

Oh yeah. TRWTF is 8.3 names.

>> - The registry provides a unified place to store configuration, whether
>> per-user or per-system. (Just a shame that there's no real interface for
>> managing it yourself - e.g., if you want to revert your MS Word
>> configuration to how it was yesterday.)
>
> Yeah. It's kind of a big bag at this point.

Which is a pity. It's nice that there's one central settings database, 
and you can make it follow the user around the network and stuff. It 
also lets you do stuff like group policy. In other words, sitting at my 
desk, I can activate the screensaver on every PC on the network, set the 
timeout, and make it impossible to disable. Try doing that with a 
generic Linux distro.

And although the GUI only works for MS products, you *can* use it to 
control *anything* that uses the registry [i.e., the vast majority of 
Windows software - *if* you can figure out which ****ing key controls it!]

The downside is...

1. Group policy doesn't apply to groups [which can overlap]. It applies 
to *folders* [which are strictly hierachical]. Stupid artificial limitation.

2. Group policy works by overwriting parts of each PC's registry. If you 
turn off the group policy, the settings to *not* go back to what they 
were before. (!!) You have to apply a new policy to set the settings to 
something else. (And you cannot set them to "whatever it was before", 
because that information no longer exists. Best you can do is set it 
back to whatever the installation default value is.)

>> - File types [or, more accurately, file extensions] are associated with
>> programs. (Shame there's no CLI access to this.)
>
> Like the "assoc" command?

I usually go through the GUI. I don't know how to change it from the 
CLI. But basically, the part where every file that ends in ".txt" opens 
Notepad when you double-click it, while anything ending ".html" opens 
Internet Explorer.

Like I say, it's a shame you can't use this feature to launch stuff 
programmatically. (At least, not without linking to C.)

> Primitive, but you can also fronk the registry
> if you need something more sophisticated. The nice thing about it is
> that it *is* centralized. No more groping around in the web server's
> configuration to figure out such stuff.

Linux seems to manage this now. Or at least, Linux file managers seem to 
open the correct application for most common file types now. I have no 
idea how it's implemented. (I have a sinking feeling it's a type 
database for each file manager, rather than something that arbitrary 
applications can use.)

> Even better, of course, would be having it in the actual metadata of the
> file, like the Mac's OS tried to do, except they did it before MIME was
> around, so it didn't work out as well as it might.

Is that the whole resource fork / data fork thing? I never heard how 
that actually works. (Other than "it doesn't".)

I know AmigaDOS distinguished between "projects" and "tools" at the same 
level as it distinguishes between "files" and "directories". (A "tool" 
is something that's supposed to be executable.)

>> ...and here I was thinking that's what the ThreadGroup class is for...
>
> That too. I think the real point of that line in the documentation is
> that the runtime doesn't *check* that the name is unique.

Right, OK.

>> Right. So a variable doesn't come into scope until after it's defined?
>
> I believe that's correct.

Oh well. I guess this is why Erlang is the most successful "functional" 
programming language around.

It's MUNCTIONAL! You're going to be UNCOMFORTABLY PARALLEL! Soon you'll 
have so many children, and you've give then ERLANG, and they'll run 
ABNORMALLY FAST! You want to be good at databases? Try PETABASES! 
Functional, Erlang, functional, database, FUNCTIONAL!!!!

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message