>> The usual response I see from OSS is "you should be greatful we
>> bothered to write any documentation at all!"
>
> I've even seen "yes, we know the documentation is all wrong and
> misleading, but we didn't bother to put a note on it saying that"
> (Apache), as well as "please, sir, may I write the documentation for
> you?" "No." (Blender)

Use the force - delete the source!

No, wait, that's not quite right...

Anyway, I submitted a patch to GHC last year containing some trivial 
documentation updates. I'm still waiting for it to be merged. (As in, 
they have the new documentation, they literally just need to press a 
button to insert it into the development head... and nobody has done 
this yet. They haven't got around to it.)

In fairness, I suppose they probably need to check it for correctness 
first, but *man*!

...hold the phone! I just went to look at what date I *actually* 
submitted it, and it turns out they applied it yesterday evening. Just 
hours after I was looking at it, in fact. Coincidence, eh?

I still think 5 months to apply one teeny documentation patch is a tad 
slow...

Post a reply to this message

>> My understanding is that Unix is *great* at letting multiple processes
>> read the same file - it's *stopping* them doing this that's hard.
>
> Well, there is that, yes.

It amuses me that there were operating systems 20 years ago that could 
do this better than Linux. It also amuses me that there exists something 
that Windows can actually do better than Linux.

(I gather it's a similar story for figuring out when a file changed...)

>> Come to mention it, what's Erlang's thread scheduler like? Does it
>> just do
>> round-robin for all threads ready to run, or can you assign thread
>> priorities and stuff?
>
> I don't think there's any priority stuff that I remember.

Certainly I've often wished you could assign priorities to Haskell 
threads. But, unfortunately, the thread scheduler doesn't support that.

For that matter, it doesn't support querying how many threads are 
currently running either. Or what their relationships are. Or, indeed, 
anything about them.

(The other day, I was looking at Java, and was amused to note that "each 
thread has a name for identification purposes. Thread names do not need 
to be unique." Well, uh, they do if you want to use names to identify 
threads. :-P Silly Java...)

>> Presumably it just means that if you create more than 2^31 Haskell
>> threads,
>> the ThreadID counter will overflow and half the standard library will
>> malfunction...
>
> It might not even mean that, if nobody does any comparisons or math with
> them.

Testing for equity will still work. I think the only time ordering 
comparisons happen is if you store thread IDs in a BST - and then the 
ordering is arbitrary, it just needs to be total.

Now, if some library somewhere is trying to use thread IDs to infer 
which order threads were created in, *that* will break nicely.

So I guess the libraries don't break until you have 2^32 threads then.

>>>> You can upgrade the code, but unless you upgrade it all at once, both
>>>> versions need to speak the same wire protocol.
>>>
>>> Again, list of three integers vs list of seven integers.
>>
>> There's more to a wire protocol than what types you exchange. (There's
>> ordering, for example.)
>
> Well, yes, if you have two versions of Erlang that don't speak the same
> protocol as the other, they won't connect.

I was thinking more about two versions of the same program. Presumably 
they'll connect, but malfunction.

>> Does Erlang not permit recursive definitions then?
>
> Not of data. If "list" is already defined, you can't assign to "list"
> again.

Neither can you do this with Haskell. But the definition of "list" can 
refer to "list" itself.

Post a reply to this message

On 5/18/2011 1:32, Invisible wrote:
> It amuses me that there were operating systems 20 years ago that could do
> this better than Linux.

Yep. Annoyed me no end, when I had to use UNIX instead of a "real" operating 
system.

> 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.

> 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. :-)

> Testing for equity will still work. I think the only time ordering
> comparisons happen is if you store thread IDs in a BST - and then the
> ordering is arbitrary, it just needs to be total.

Exactly.

> Now, if some library somewhere is trying to use thread IDs to infer which
> order threads were created in, *that* will break nicely.

Exactly.

> I was thinking more about two versions of the same program. Presumably
> they'll connect, but malfunction.

It depends if one is upward compatible with the other. If the new program 
can handle new data and old data both, then they won't malfunction.

> 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.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

>> 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