 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It also amuses me that there exists something that
>> Windows can actually do better than Linux.
>
> There's actually quite a bit that Windows now does better than Linux,
> and quite a bit that Linux today does better than Linux five years ago.
> For example, I read that the clock is now *finally* a file handle, like
> the Amiga figured out 20 years ago and which everyone seemed to
> conveniently ignore for the past 40 years when arguing "Everything's a
> file in UNIX!"
>
>> (I gather it's a similar story for figuring out when a file changed...)
>
> Yes. The IPC stuff in Linux honestly still hasn't caught up to Windows.
> There's no kernel transactions, the file locking is still a mess
> especially over the network, the privilege and authentication system (at
> the kernel level) is still comparatively weak, performance monitoring
> and error logging is not unified, etc.
I don't know a great deal about the inner workings of Windows or Unix.
But there are a number of things that Windows seems to do better:
- File permissions. None of this chmod 664 nonsense. You can set
arbitrary combinations of permissions for any number of users and groups.
[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...]
- 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.)
- File types [or, more accurately, file extensions] are associated with
programs. (Shame there's no CLI access to this.)
>> be unique." Well, uh, they do if you want to use names to identify
>> threads.
>
> No. You might want to kill all database worker threads and not all web
> server worker threads. I.e., the same thing you were talking about in
> Haskell code upgrades, where you want to kill all the threads running
> *this* code but not *that* code.
>
> "Identify" doesn't necessarily imply "identity" except in math. :-)
...and here I was thinking that's what the ThreadGroup class is for...
>> Neither can you do this with Haskell. But the definition of "list" can
>> refer to "list" itself.
>
> Oh. No, you can't do that in Erlang, since "list" doesn't exist until
> you've assigned it.
Right. So a variable doesn't come into scope until after it's defined?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. So you can say "this group can read the attributes of processes but
not write them, and that group can append to error logs but not read them."
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.
> [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. :-)
> - 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.
> - File types [or, more accurately, file extensions] are associated with
> programs. (Shame there's no CLI access to this.)
Like the "assoc" command? 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.
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.
> ...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. So a variable doesn't come into scope until after it's defined?
I believe that's correct.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> I don't know a great deal about the inner workings of Windows or Unix.
> But there are a number of things that Windows seems to do better:
>
> - File permissions. None of this chmod 664 nonsense. You can set
> arbitrary combinations of permissions for any number of users and
> groups.
http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/05/2011 07:01 PM, Florian Pesth wrote:
>>
>> I don't know a great deal about the inner workings of Windows or Unix.
>> But there are a number of things that Windows seems to do better:
>>
>> - File permissions. None of this chmod 664 nonsense. You can set
>> arbitrary combinations of permissions for any number of users and
>> groups.
>
> http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs
I'm not sure what the relevance of this link is.
I'm aware that a couple of people have hacked propper ACLs into recent
Linux kernels. This doesn't change the fact that the entire Unix
ecosystem still assumes that permissions are set via flat bitmasks. It's
almost infeasible to change this and still call the result "Unix".
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Wed, 18 May 2011 21:52:05 +0100 schrieb Orchid XP v8:
> On 18/05/2011 07:01 PM, Florian Pesth wrote:
>>>
>>> I don't know a great deal about the inner workings of Windows or Unix.
>>> But there are a number of things that Windows seems to do better:
>>>
>>> - File permissions. None of this chmod 664 nonsense. You can set
>>> arbitrary combinations of permissions for any number of users and
>>> groups.
>>
>> http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs
>
> I'm not sure what the relevance of this link is.
>
> I'm aware that a couple of people have hacked propper ACLs into recent
> Linux kernels. This doesn't change the fact that the entire Unix
> ecosystem still assumes that permissions are set via flat bitmasks. It's
> almost infeasible to change this and still call the result "Unix".
It's supported and works since ten years now (and according to wikipedia
is supported in Konqueror and Nautilus since quite some time). Just
because you put Linux and Unix in the same bag and Unix doesn't support
some things (which is by the way in this case not true since ACL's come
from Unix) does not mean that Linux can't do it or that it is a "hack".
And yes, Linux is not Unix and it shows in some details like this.
The fact, that a lot of distributions don't enable it by default means
that most people don't need it, but for sure it is there (same with
Extended Attributes, which are also not enabled by default but you just
have to switch it on).
So yes, you can set arbitrary user rights - you just have to enable it. I
even doubt that there is no solution to the file locking problem - but I
don't really know...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'm aware that a couple of people have hacked propper ACLs into recent
>> Linux kernels. This doesn't change the fact that the entire Unix
>> ecosystem still assumes that permissions are set via flat bitmasks. It's
>> almost infeasible to change this and still call the result "Unix".
>
> It's supported and works since ten years now (and according to wikipedia
> is supported in Konqueror and Nautilus since quite some time). Just
> because you put Linux and Unix in the same bag and Unix doesn't support
> some things (which is by the way in this case not true since ACL's come
> from Unix) does not mean that Linux can't do it or that it is a "hack".
> And yes, Linux is not Unix and it shows in some details like this.
> The fact, that a lot of distributions don't enable it by default means
> that most people don't need it, but for sure it is there (same with
> Extended Attributes, which are also not enabled by default but you just
> have to switch it on).
> So yes, you can set arbitrary user rights - you just have to enable it. I
> even doubt that there is no solution to the file locking problem - but I
> don't really know...
All Unix tools assume that file permissions are set using bitmasks. If
this doesn't hold, most software designed for Unix-like operating
systems simply stops working.
This is the trouble with having a wildly popular system - you can't
change it. The fact that ACLs are turned off by default almost certainly
has nothing to do with "people not needing it" - more likely it's turned
off because it breaks so much stuff.
Similar problems with file locking. As I understand it, there's now an
API to ask "is this file locked?", but if you don't use it, you bypass
all the locking and can access a file even if it's locked. Yeah, that's
really helpful.
I gather that Linux only just got the ability to notify you if a file
changes. (At least modern Linux desktops manage to *use* this
information correctly, which is more than Windows Explorer manages...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Wed, 18 May 2011 22:30:32 +0100 schrieb Orchid XP v8:
>
> All Unix tools assume that file permissions are set using bitmasks. If
> this doesn't hold, most software designed for Unix-like operating
> systems simply stops working.
Well, binutils and the file managers of the most used desktop environments
KDE and Gnome seem to support it. Now what other programs do with it I
don't know...
>
> This is the trouble with having a wildly popular system - you can't
> change it. The fact that ACLs are turned off by default almost certainly
> has nothing to do with "people not needing it" - more likely it's turned
> off because it breaks so much stuff.
Well, it wouldn't hurt to turn extended attributes on, even if they would
get lost using the wrong programs. I think in Ubuntu really a lot of
stuff is turned off, because people don't need it or they think it is too
dangerous (like this stupid sudo su stuff and only certain users can
change to root, which was taken from BSD...).
>
> Similar problems with file locking. As I understand it, there's now an
> API to ask "is this file locked?", but if you don't use it, you bypass
> all the locking and can access a file even if it's locked. Yeah, that's
> really helpful.
Sure that there is no call for saying "Lock this file definitely" and the
other lock mechanisms are just kept for POSIX compability?
>
> I gather that Linux only just got the ability to notify you if a file
> changes. (At least modern Linux desktops manage to *use* this
> information correctly, which is more than Windows Explorer manages...)
I think this is also older... there is this tailf program, which does the
same as tail -f but does not poll the file, so I guess there was some
mechanism already. But I agree, that a lot of the GUI's could implement
stuff much better.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/18/2011 14:14, Orchid XP v8 wrote:
> 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.
The only one I know of for sure is manipulating file system stuff.
Partitioning a disk, reading the UNC, marking a file system dirty, etc. I
don't know what privilege it is - maybe you actually can assign it.
>> That is the basic problem with complex permissions. :-)
> I assume that comment is directed at AD.
Well, all complex permissions systems.
> ...except that it's still implemented the old way.
No it isn't. Well, maybe with XP, but I don't think that's the case any more.
> 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.
Maybe if you're doing it thru the explorer?
> Oh yeah. TRWTF is 8.3 names.
What about them?
>> 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.
That's the "assoc" command.
> Like I say, it's a shame you can't use this feature to launch stuff
> programmatically. (At least, not without linking to C.)
Well, what are you going to launch? You can't launch *anything* without
linking to some sort of C code.
> 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.)
I wouldn't be surprised.
>> 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".)
No, it was the Creator/Type thing, each a four-character code. So a text
file made by MS Word might have a creator/type or MSWD/TEXT or something.
Mac files had two forks. One was the data fork, which is just like a UNIX
file. The other is the resource fork, which had structured blobs, each
defined by a type and a size, maybe a name, etc. So what you see in a
Windows executable as a "resource" file was actually the resource fork of a
Mac application or data file.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/18/2011 14:50, Florian Pesth wrote:
> Sure that there is no call for saying "Lock this file definitely" and the
> other lock mechanisms are just kept for POSIX compability?
Yes. The basic problem is that none of the lock mechanisms actually work
reliably in all situations.
> I think this is also older...
One problem is that there's at least 3 ways of doing this in Linux, all
three relatively recent.
One would give you a signal when a file in the one single directory you're
watching (maybe just the cwd) changed. Not very handy except for the
refreshing of a window in a file manager.
One would do some sort of something or other with messages sent to you
somehow I forget when anything under a particular file tree changed, IIRC.
It was poor because, IIRC, you had to block to wait for the messages or
something.
The latest one, done right, lets you open a file handle, writing to the
handle says what you're waiting to see change, reading the (selectable)
handle lets you know when something there changed and what it was.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
