|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |