Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Adopt a Lost Technology Today For R.O.S.

timothy posted more than 10 years ago | from the are-oh-what dept.

Operating Systems 56

submitted by Simon Strandgaard writes "When new operating systems gets designed today, great systems such as Amiga, Atari and VMS, seems to get overlooked in regard to their original features not found on other OSes. It might be time to collect and categorize those special unique features under the great/lost ideas wiki, so new OSes don't have to re-invent the wheel and re-innovate." This is all for R.O.S., a "ruby-centric operating system."

cancel ×

56 comments

Sorry! There are no comments related to the filter you selected.

Seriously . . (0, Troll)

Leroy_Brown242 (683141) | more than 10 years ago | (#7958646)

How many operating systems do we need? Why not find your favorite, and try to impliment these awesome features you like?

Couldn't they add a U to that? (2, Funny)

TMLink (177732) | more than 10 years ago | (#7959052)

Maybe they should call it the "Ruby-centric Operating Uniformly System"...that way they'd already have a mascot [nd.edu] .

nice ideas but.. (1)

sycotic (26352) | more than 10 years ago | (#7959180)

..isn't this all pie in the sky stuff though really?

I mean with regards to putting it into action.

Re:nice ideas but.. (1)

Spoing (152917) | more than 10 years ago | (#7959576)

  1. ..isn't this all pie in the sky stuff though really?

    I mean with regards to putting it into action.

Erm...isn't the point of the list that someone did 'put it into action'?

Re:nice ideas but.. (0)

sycotic (26352) | more than 10 years ago | (#7960161)

no, I mean with regards to the actual features and having them re-implimented into this single, new, operating system.

Plan9 (1, Interesting)

spitzak (4019) | more than 10 years ago | (#7959239)

Look at Plan9 for ideas!

In theory it fixes all the problems with Unix, while still keeping to the original design philosophy.

Re:Plan9 (2, Informative)

AtrN (87501) | more than 10 years ago | (#7960979)

Definitely. Plan 9 has wonderful ideas however it is covered by the following patent [uspto.gov] which may affect a development that uses its best ideas.

Re:Plan9 (0)

Anonymous Coward | more than 10 years ago | (#7968979)

That's nasty, pointing it out, though - you realise that now he knows about the patent, he's liable for triple damages if he violates it? That's the real reason behind Linus Torvalds' comment about it being a bad idea to look at patents, that SCO so famous took out of context.

Old/new idea (2, Interesting)

be-fan (61476) | more than 10 years ago | (#7959286)

I'd like to see the end of the kernel/userspace separation. Just put everything in one address space. With safe languages, there is no need for it. The safe language you can get fine-grained protection with close to zero performance overhead. This makes the VM a great deal less complex (read Charles Cranor's UVM paper to see the complexity cause by VM-enabled sharing) and faster/less memory-hungry.

Performance should improve a lot too. A P4 pays a couple of hundred clock-cycles penalty for each system call. Context switches are close to 1000 clocks. With a single address-space OS, you can get all the advantages of a microkernel providing services via OS servers, without any performance hit.

Re:Old/new idea (3, Informative)

topologist (644470) | more than 10 years ago | (#7959420)

LISP Machines had unified address spaces and a lot more. Looks like the site referred to in the article has a decent summary (I'd add more, but I'm too young to have used them, so I'll leave it to someone with first-hand experience :-)

Re:Old/new idea (1)

be-fan (61476) | more than 10 years ago | (#7959539)

The original title of the post was Lisp, and I was going to rant about how it had so many features that we're just getting now, except years ago and better. But I decided to refrain, because I didn't want to detract from the other part of my point.

Re:Old/new idea (0)

Anonymous Coward | more than 10 years ago | (#7962880)

Lisp machines had hardware type-tagging, though, meaning that it was still "memory protected" in a sense, just much finer grained than allowed with standard CPU architectures - it was damn difficult to crash a lisp machine completely (though buggy subsystems often failed, leading, similar to linux, to silly "well, linux hasn't crashed but X has so it might as well have" style situations).

Amiga did single-address-space, without the hardware type tagging. It was as stable as... a very pointy thing balanced on its tip, with a nearby elephant dancing.

Re:Old/new idea (2, Interesting)

be-fan (61476) | more than 10 years ago | (#7964828)

Type tagging isn't a protection mechanism. Its an optimization for dynamic dispatch (virtual calls in C++/Java-speak). The protection in the Lisp Machine came from two conditions:

1) You couldn't access the byte representation of pointers directly, nor do arithmatic on them. This meant that the only way to access an object was to be handed a pointer to it.

2) Array bounds were checked.

Since the Amiga used C/ASM (IIRC) neither of these conditions held true, which is the reason for the iffy stability.

Note, that you can easily do the LispM-style machine without hardware type tagging. Gwydion's Dylan compiler*, for example, emits guaranteed-safe binaries on regular x86 machines.

*> The CMU Common Lisp compiler ordinarily does the same thing, but unlike Dylan, Common Lisp has an "unsafe" mode that turns of certain checks.

Re:Old/new idea (0)

Anonymous Coward | more than 10 years ago | (#7967270)

No, hardware type tagging on a tagged architecture isn't just an optimisation. If the CPU traps out when you try an operation on a memory location of an incorrect type (don't forget, the type of a datum could include "type "accessible to object blah"" as well as more conventional types like "int" :-) ), it's ALSO akin to really fine grained memory protection.

Re:Old/new idea (1)

be-fan (61476) | more than 10 years ago | (#7968835)

Yes, it did speed up type checks, but you can easily do the same thing in software, and indeed, existing implementations of Lisp-like languages emulate tag bits in software. And in theory a type of a datum could be "type acessible to object blah" but that is impractical because of the number of tag bits available.

No LispM had more than 8 tag bits. That isn't enough to even completely encode every object type. Only very important types like integers, cons cells, etc, used a tagged representation. Everything else used a generic object representation. The tag bits certainly aren't enough to encode arbitrary information like "accessible to object blah." To get the same level of object-granular protection, you'd have to encode an ACL onto each object, and search it on each memory access!

Re:Old/new idea (0)

Anonymous Coward | more than 10 years ago | (#7968962)

(Bad) Idea I've been wondering about for "uncoventional" lisp intepreter: Given that memory is SO cheap, how about splitting the memory in two, and thus have each address have a tag word? Should give you lots of tag bits :-). Compile the lisp code down to run on a Forth-like "inner interpreter" that respects the tags rather than raw assembly. On a 32-bit architecture, that gives you a LOT of distinct tags, and if you dynamically allocated tags, you could indeed start having pseudo-hardware types like "accessible to object blah but only when the moon is full".

Mindbending.

Re:Old/new idea (1)

voodoo1man (594237) | more than 10 years ago | (#8004421)

CLISP does this on 64-bit machines, and it's very slow. Here's [google.com] a very informative post by Duane Rettig (one of the hackers of Franz's Allegro CL) explaining the optimal tag layout for Lisp on conventional byte-addressable machines.

Re: kernel/userspace separation (3, Funny)

some guy I know (229718) | more than 10 years ago | (#7960401)

I'd like to see the end of the kernel/userspace separation. Just put everything in one address space.
You mean like MS-Windows?
With safe languages, there is no need for it.
The problem with "safe" languages is that the underlying system can be used for such odious purposes as D"R"M, and there is no way to get around it.
And you would have to have a "safe"-language-only policy on such a system, or you would have a security nightmare similar to that of MS-Windows.
(I certainly wouldn't want to use such a system; I like C, even though I usually use Python (a "safe" language).)

Performance could be enhanced by doing more things in libraries (e.g., a ramdisk used exclusively by one application (or a limited set of mutually-trusted/ing applications) could be supported entirely in userspace, with no context-switching necessary).
Or several mutually-trusting/ed intercommunicating apps could share the same address space, so no VM remapping would be necessary when switching from one to another, nor would a system call be necessary.
(This would be kind of like a lightweight thread mechanism, but different threads could be loaded from different binaries.)

I don't know if any of this would actually be feasible, though, since I haven't really worked on the guts of an OS for about 20 years.

Re: kernel/userspace separation (2, Interesting)

be-fan (61476) | more than 10 years ago | (#7960482)

You mean like MS-Windows?
--------
Yeah, but with a safe language :)

With safe languages, there is no need for it.
The problem with "safe" languages is that the underlying system can be used for such odious purposes as D"R"M, and there is no way to get around it.
----------
Not at all. Systems-level safe languages (Lisp, for example) usually have a dialect used for kernel-level development. In this scheme, binaries would have to be signed, to ensure that the native code was compiled by the safe compiler. However, this signing only has to be strong enough to protect a traditional security model. Root users, of course, should be allowed to run unsafe, kernel-level code if they want.

And you would have to have a "safe"-language-only policy on such a system, or you would have a security nightmare similar to that of MS-Windows.
--------
You could always run "unsafe" code in a virtual machine.

(I certainly wouldn't want to use such a system; I like C, even though I usually use Python (a "safe" language).)
---------
C could be made safe, if you added runtime checks for array indexing, and disable pointer arithmatic except for arrays. Unless you're writing kernel-level code, you shouldn't use those features anyway. Or, you could just run it in a VM.

Performance could be enhanced by doing more things in libraries (e.g., a ramdisk used exclusively by one application (or a limited set of mutually-trusted/ing applications) could be supported entirely in userspace, with no context-switching necessary).
---------
The MIT exokernel does this. They've shown some impressive performance gains in certain apps, but the design is, by necessity, highly unconventional (the kernel provides extremely primitive abstractions, namely memory pages and raw disk blocks). And it just moves the bottleneck around. Depending on what you're doing, an extremely low-level kernel API could very well cause a lot more system calls than a high-level kernel API.

Or several mutually-trusting/ed intercommunicating apps could share the same address space, so no VM remapping would be necessary when switching from one to another, nor would a system call be necessary.
---------
You're essentially talking about threads. However, the problem is that you want sharing, but still want protection. Threads can corrupt each others memory, and that's unacceptable. Would you want your webbrowser to crash if your email client did as well? With a safe language, you get fine-grained control of who you trust. The only people you've got to trust are the ones you explicitly hand your object references to, and then only when dealing with that specific object.

(This would be kind of like a lightweight thread mechanism, but different threads could be loaded from different binaries.)
---------
Linux can do this exact thing via the clone() system call, but its of limited usefulness, because most of the time, processes do *not* completely trust each other.

I don't know if any of this would actually be feasible, though, since I haven't really worked on the guts of an OS for about 20 years.
---------
Its certainly doable (and indeed, has been done), but there are better ways now :)

Re:Old/new idea (4, Informative)

be-fan (61476) | more than 10 years ago | (#7960494)

On a related note, there is a nifty project on SourceForge [sourceforge.net] about a kernel that does precisely what I'm talking about. The safe language in use is a natively-compiled, heavily Lisp-influenced language with low-level extensions for kernel development.

Re:Old/new idea (1)

LWATCDR (28044) | more than 10 years ago | (#7963237)

You would have to ban native binary code then. Every thing would have to be some type of bytecode.

Re:Old/new idea (1)

be-fan (61476) | more than 10 years ago | (#7964853)

Most of the "safe" languages out there compile regular native binaries. Lisp, Dylan, Scheme, ML, Ocaml, Haskell, Clean, etc, all compile to native code.

Since these languages don't allow you to do pointer arithmatic, the only runtime checks they need to insert in the generated native code is for array bounds and type checks. Modern optimizers for these languages can eliminate most of these runtime checks.

Bounds checked C/C++? (1)

Latent Heat (558884) | more than 10 years ago | (#7971079)

Part of the power of C (as in Kernighan's "Why Pascal is not my favorite language") is the duality between pointer and array and the frequent lack of compile time restrictions on the array length. With a little pointer arithmetic, you can easily access subsections of arrays with whatever offset and length you feel like.

Since we are on the subject of tags, putting a tag on every scalar datum seems like a waste of memory and address space, but putting a few tags on an array doesn't seem like a big deal. Instead of an array being , an array could be , and this triple could be set 1) when you dynamically allocate an array, and 2) when you "cast" the array by taking a subslice of it. The bounds checking can be coded efficiently by an optimizer that knows about loop variables and such.

I suppose you could do something like this in C++ with a template class and the proper inlining and such (is an STL vector reasonably efficient?), but I don't know if the compiler can optimize out the bounds checks. I would think you would have to make this kind of array a language feature rather than a template-class implemented language extension to get best efficiency.

Re:Bounds checked C/C++? (1)

voodoo1man (594237) | more than 10 years ago | (#8004345)

Part of the power of C (as in Kernighan's "Why Pascal is not my favorite language") is the duality between pointer and array and the frequent lack of compile time restrictions on the array length. With a little pointer arithmetic, you can easily access subsections of arrays with whatever offset and length you feel like.
You can do this safer and faster using displaced arrays*. They first appeared in FORTRAN, but were most heavily exploited in the MIT Lisp Machines. They allow you to create "virtual" arrays that index onto an existing array in interesting ways, like changing the size and offset, or treating multi-dimensional arrays as vectors (and one of the most common application usually was to index byte-arrays onto word-arrays for hardware drivers). These can also be used in user-code to do very neat tricks with untyped arrays. Last but not least, there were also conformally displaced arrays (not to be confused with conformant arrays of Pascal or Modula), that displaced multi-dimensional arrays correctly with respect to dimension, so for example you could do in-place bit-blitting (which is how low-level screen drawing actually worked on some machines).

Sadly, I don't know of any other languages besides Common Lisp and FORTRAN that support them now. The byte-onto-word displacement is very much hardware dependent, and so is not mandated by Common Lisp. Neither are conformally displaced arrays, which is pretty aggravating considering how useful they are.

Since we are on the subject of tags, putting a tag on every scalar datum seems like a waste of memory and address space, but putting a few tags on an array doesn't seem like a big deal. Instead of an array being , an array could be , and this triple could be set 1) when you dynamically allocate an array, and 2) when you "cast" the array by taking a subslice of it. The bounds checking can be coded efficiently by an optimizer that knows about loop variables and such.
Yup, this is exactly how typed (displaced) arrays work in Lisp.

* - Actually, you can do things with displaced arrays that you can't do at all with pointer manipulation - fast, easy access to fractional addresses. You'd need this if you want to deal with bytes in a word-addressable architecture (such as the Lisp Machine), or for treating byte-arrays as bit-vectors.

Re:Old/new idea (1)

be-fan (61476) | more than 10 years ago | (#7964868)

Oh, I forgot one thing. While you could easily run native code, you'd have to have some sort of code-signing guaranteeing to the OS that a given binary was compiled with a "safe" compiler. The technology for this already exists, so that wouldn't be a problem.

Re:Old/new idea (1)

LWATCDR (28044) | more than 10 years ago | (#7979277)

So asm programing would be out. Also any mistakes in the compilers code generation could cause a security problem. Also wouldn't this run counter to OpenSource if you had to get your code signed?

Re:Old/new idea (1)

voodoo1man (594237) | more than 10 years ago | (#8004569)

Let me interject a third viewpoint into this discussion. I propose eliminating any guarantees about machine-level program representation in this hypothetical OS. Everything, and I mean all software would have to be distributed as source code. Then validating that source code for trustworthiness could be done by a simple search of the parse tree, and non-trusted software could be easily run in a protected environment. This, IMO, is the ultimate technical advantage of open-source (but not necessarily free) software.

Now this would require a sharp dividing line between executable code and data (at least for user programs - who knows what the OS is doing under the hood?). Data would then be serialized to UBF [www.sics.se] (mostly because XML is too fat). But this is actually a good thing - this would enable a painless move to the much more efficient Harvard architecture.

In practice, I think such system would probably suck in many ways; a lot of it would have to do with disallowing assembly. What is a much more realistic alternative (it's worked on some of the most successful systems ever built!) is to combine a powerful, interactive and unrestricted language and open-source software with technically sophisticated users. ITS [os.org] is the paragon of this approach.

FreeVMS (2, Interesting)

JDWTopGuy (209256) | more than 10 years ago | (#7959348)

Since VMS was mentioned, I'd like to let people know about this project:
FreeVMS [freevms.free.fr] (Mailing list archive) [nvg.org]

It's based on Linux for the moment, but it'll split eventually. Despite the homepage being a bit out of date, the project is alive; in fact I'm working on cleaning up the code a bit.

Features? Just so long as it has drivers... (2, Funny)

AJWM (19027) | more than 10 years ago | (#7959602)

... for my card reader.

Great Idea, Except ... (2, Interesting)

zangdesign (462534) | more than 10 years ago | (#7960771)

that those innovations on older systems would have to be pretty much reinvented anyway, since the older machines were developed with closed or copyrighted codebases. Not to mention which, most of those "innovative" features have been superseded by the better features available on more modern systems.

Seriously, what features from the Atari systems are so great, yet have been overlooked in modern systems?

Bad ideas and good ideas (3, Insightful)

davegaramond (632107) | more than 10 years ago | (#7960860)

Good ideas

- unified name space (like Unix's single root / hierarchy)
- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it
- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation
- everything is a file
- everything is a component
- Unicode

Bad ideas

- registry (at least the windows do it currently): it's like the 777 version of /etc
- XML for configuration (YAML is a better choice)
- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)
- resource fork/multiple stream or something like that (if i want two different content, i'll make two different record/file, thank you)

Not sure

- GUI at the lowest level?

Re:Bad ideas and good ideas (3, Insightful)

smcv (529383) | more than 10 years ago | (#7961290)

- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation

So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?

(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)

- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it

With an efficient enough filesystem (ReiserFS?) you could do something like this:

(extra linebreaks for clarity)

# What is the name of customer #001?
$ cat /tables/CUSTOMER/001/name

Joe Bloggs

# Who ordered order#003?
$ cat /tables/ORDER/003/customer

001

# What is the name of the customer who ordered order#003?
$cat /tables/CUSTOMER/$(- registry (at least the windows do it currently): it's like the 777 version of /etc

I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.

IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.

- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)

Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?

If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).

Aagh... should have used Preview (1)

smcv (529383) | more than 10 years ago | (#7961307)

- using a safe, higher level, garbage-collected, OO language (about time to kill C, damnit!), also as another poster noted, this can eliminate kernelspace/userspace separation

So... your security model breaks utterly as soon as someone finds a bug in the *compiler*?

(Incidentally, what is your compiler or interpreter written in, and why would I use an OS that only supports one language?)

- filesystem as database (why do we have to put stuffs in two different things anyway?); the filesystem should support hierarchiecal as well as relational paradigm. one can put a SQL interface on top of it

With an efficient enough filesystem (ReiserFS?) you could do something like this:

(extra linebreaks for clarity)

# What is the name of customer #001?
$ cat /tables/CUSTOMER/001/name

Joe Bloggs

# Who ordered order#003?
$ cat /tables/ORDER/003/customer

001

# What is the name of the customer who ordered order#003?
$cat /tables/CUSTOMER/$(</tables/ORDER/003/customer)/na me

003

The difficult bits of a relational database are the data integrity bits (transactions, atomic updates, that sort of thing), which *would* need extra filesystem support.

- registry (at least the windows do it currently): it's like the 777 version of /etc

I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.

IMO the main problem with the Registry is that it's in a few opaque binary files with a non-obvious structure; Unix configuration files are usually structured text, so it's easy to see whether a config file has become corrupted, possible to undo the damage, and possible to change everything with a simple text editor rather than having to invoke regedit. Unix config files are also split up sensibly (per-application) so they're easier to manage.

- package managers or installers (the OS should be modular and component-friendly enough to render this unnecessary; think a PC with pluggable PCI cards or USB devices; adding/removing software components should be as easy as plugging/unplugging hardware devices)

Hmm. So, how do you add software? Do you just copy a file-which-is-really-a-directory, MacOS-style?

If so, how do you suggest managing libraries? If every application has its own copies of all its libraries (or is statically linked), when someone finds a bug in, say, zlib, every program that used zlib needs an update. With separate library packages and intelligent dependency checking, you should only need to update zlib itself (and in a package management system, zlib should have been installed automagically the first time you installed an app which needed it).

Re:Aagh... should have used Preview (1)

jbert (5149) | more than 10 years ago | (#7961510)

> So... your security model breaks utterly as soon
> as someone finds a bug in the *compiler*?

The bugginess (or otherwise) isn't the main issue. You can think of the checks done in the compiler regarding access permissions as equivalent to the checks done by the system call interface at run time (and by the page fault handler, etc). If either is buggy (e.g. the recent mremap() bug in the Linux kernel) you get privilege escalation (of course, such checks are particularly difficult at compile time for some languages, e.g. anything with real pointers).

Basically the system comes down to transitive trust. The kernel could assume trust in one (or more) compilers, such that it is happy running the output of those compilers without run-time checks.

Note:

1 - You could have multiple trusted compilers, for whichever languages you favour.

2 - You don't need to enforce your trust relationships via digital signatures (although that would be one way). One alternative method would be to allow only "trusted" processes to mark another process as executable. Then, compilers would mark their output as executable.

3 - Other processes could run, but in a run-time sandbox (own address space, system call checking etc)

4 - Oops. Look at what we've got. Unix. "trusted" == root, except that system calls made by root owned processes would bypass all run-time checks.

OK, so that isn't a perfect view of things (it is useful to have run-time checking on most/many root processes), but you could certainly envisage a new capability which allowed a process to run in the kernel address space?

That doesn't seem as much of a far off idea now?

Re:Bad ideas and good ideas (3, Informative)

JKR (198165) | more than 10 years ago | (#7961808)

I'm sure parts of the Registry (HKEY_LOCAL_MACHINE?) are read-only for ordinary (non-Administrator) users; if you're right, though, the Registry is even worse than I thought.

On versions of Windows based on a real OS (NT and above) all the registry objects have security permissions associated with them. For a long time you needed two different registry editors because only regedt32.exe handled security, but XP has finally merged the functionality into one program. Most of the OS-related keys have security permissions such that ordinary users cannot break them.

There is a quantity of broken software (Kodak KPCMS, I'm talking to YOU) out there that just can't cope with storing user settings in the correct hive and thus needs to have its global settings made writable by anyone, but this is slowly improving. Now if only Adobe could fix the bug that requires oridinary users to have file create permissions in the root directory. It's not as if per-user temporary directories haven't been implemented since NT4.

Jon.

Re:Bad ideas and good ideas (1)

Havokmon (89874) | more than 10 years ago | (#7989932)

Now if only Adobe could fix the bug that requires oridinary users to have file create permissions in the root directory. It's not as if per-user temporary directories haven't been implemented since NT4.

Exactly where those registry settings should be kept: An ini file in the users home directory ;)

Re:Bad ideas and good ideas (1)

JKR (198165) | more than 10 years ago | (#7996439)

But that IS where the per-user registry settings are kept, in a binary hive in the user's profile directory. The only difference is, it's not a plain text file. Instead, you can load the hive using the registry editor, separate from the currently loaded registry settings.

Jon.

Re:Bad ideas and good ideas (1)

Havokmon (89874) | more than 10 years ago | (#8001637)

But that IS where the per-user registry settings are kept, in a binary hive in the user's profile directory. The only difference is, it's not a plain text file. Instead, you can load the hive using the registry editor, separate from the currently loaded registry settings.

Technically, yes, you are correct. Unfortunately it's not a per-application thing. Unless you put a lot of, IMHO, worthless work into it you get everything.

You also have to setup every pc to sync all of that up (upgrade to NT). It's a poor hack at best.

Write it to a text file, keep it in the user dir. Easy to modify, easy to remove, easy to manage. Any Win32 app that conformed to that spec would run just fine across multiple PC's on Any network, on any version of Windows.

The registry crap does nothing more than require extra MS software that's not needed.

Already too many OS... (3, Insightful)

Frans Faase (648933) | more than 10 years ago | (#7961530)

...that are designed from the bottom-up, instead of top-down. Whether a OS makes us of a file-system or a relational database to store data, is really not interesting from the perspective of the end-user (application programs). The same is true for so many OS related design decisions.

If you want to be truely revolutionary, you should take the top-down approach and start with a solid object-model (with a clearly defined semantics), and only then start thinking about how to implement the rest.

Re:Already too many OS... (0)

Anonymous Coward | more than 10 years ago | (#7963710)

No, because most "object models" are cirppled compared to relational models (with the possible exception of lispy object models). A relational database IS interesting from the perspective of the end user, as "joins" are what users always REALLY want when looking for things.

Re:Already too many OS... (1)

Frans Faase (648933) | more than 10 years ago | (#7971809)

I agree with you that most object models are crippled. But I was speaking of a "solid object model with a clearly defined semantics". Most common used object models lack clearly defined semantics in terms of mathematics. Please read my Object-Oriented Considered Harmful [planet.nl] and my article on Art of Programming [planet.nl] .

VMS logicals versus Unix environment variables (1)

neoneye (696191) | more than 10 years ago | (#7962283)

Thanks for all the information that has been submited to the wikipages, during this osnews/slashdot'ting.

BTW: anyone which dare to write a comparison between VMS's logicals and Unix's environment-variables? Are VMS logicals more secure? Wikipage Of VMS [rubyforge.org] .

--
Simon Strandgaard

Re:VMS logicals versus Unix environment variables (1)

Grotus (137676) | more than 10 years ago | (#7963131)

I put up a link there to the OpenVMS Documentation [hp.com] . Read the OpenVMS User Manual, chapter 13 for everything you want to know about Logicals. I personally don't know enough about UNIX environment variables to make a proper comparison.

Re:VMS logicals versus Unix environment variables (1)

neoneye (696191) | more than 10 years ago | (#7963322)

I have been browsing the documents at HP, but without being able to localize the VMS user-manual.

What am I missing?

--
Simon Strandgaard

Re:VMS logicals versus Unix environment variables (1)

Mikkeles (698461) | more than 10 years ago | (#7963906)

Do a search on the page for OpenVMS User's Manual; it's almost at the bottom. Links there (and repeated here) are to the .pdf [hp.com] and HTML [hp.com] versions.

According to the HTML document, logicals are discussed in chapter 11. You should also look at the related idea of symbols, covered in the following chapter (12).

(Also note that, in addition to SYSTEM and PROCESS, there are logical name tables for GROUP and JOB. As well, you can create your own LNM$TABLEs)

Another great idea in VMS is the ability to INSTALL a new command on an equal footing with those existing. This feature eliminates most of the need for $PATH.

Re:VMS logicals versus Unix environment variables (1)

neoneye (696191) | more than 10 years ago | (#7963961)

Thanks.. I am reading on it now.

Another great idea in VMS is the ability to INSTALL a new command on an equal footing with those existing. This feature eliminates most of the need for $PATH.
I don't understand, please elaborate :-)

Submit text to the OpenVMS wikipage if you wish.

--
Simon Strandgaard

Re:VMS logicals versus Unix environment variables (1)

Mikkeles (698461) | more than 10 years ago | (#7964702)

For a brief overview see CDU [hp.com] .
This discusses command tables. See section 1.3.2 for specific examples of using them with SET COMMAND and INSTALL to make new executables available as built-in commands.

Submit text to the OpenVMS wikipage if you wish.
Thanks, I probably will soon (once I figure out how to use it - I have never editted yet), but my only current access is from work, so I'll have to find a period when I have more than a few moments :^)

Re:VMS logicals versus Unix environment variables (1)

Slashamatic (553801) | more than 10 years ago | (#7990749)

VMS CLI symbols are the equivalent to Unix environment variables. Logicals are much more interesting, they are normally at process level, job level (process group) then group and system. Logical names also have access levels ranging from user mode through to kernel mode. Code running in kernel mode should never look at user mode logicals (unless on behalf of that user), so logicals are quite secure.

What is really cute is the interplay between the file system, RMS and logicals. This means that I can define a directory as follows:

DEFINE SRC USER,PROJECT,RELEASE

Whenever I access something via SRC:, it will pick the first occurrence out of the USER then PROJECT and finally RELEASE. This means that if the code was untouched, then it stays in RELEASE, if there is a project wide mod, then it can be in PROJECT and my personal copy under user.

Simply by changing the definition of SRC, I can switch to the project directory (ignoring my changes) or the release directory. This needs no supporting code in the programs. Effectively this is a bit like having a PATH for everything. Project management then becomes a doddle.

Re:VMS logicals versus Unix environment variables (1)

neoneye (696191) | more than 10 years ago | (#7991490)

It sound very similar to Path-Shortcuts [rubyforge.org] ?

Is this what it is?

Please feel free to extend the VMS chapter with more examples of logicals, and how the differ from unix/amiga.
VMS & OpenVMS [rubyforge.org]

I don't feel comfordable writing about VMS, because I have absolutely no experience with it. I know of Amiga and Unix.. and thats about it. If you have handson VMS experience, then submit text. Thanks in advance :-)

--
Simon Strandgaard

Re:VMS logicals versus Unix environment variables (1)

Slashamatic (553801) | more than 10 years ago | (#7995455)

The thing is with VMS is that search-lists as they are called are recursive. They to may contain logicals and other search lists. A logical may also replace a device, a directory, a filename or a file extension in that order. For example, logicals could look like:

DISK01$:[USERS.SMITH]filename.ext

The logical could be defined for DISK01$: (which happens to be a logical assigned at mount time) DISK01$:[USERS], DISK01$:[USERS.SMITH] and so on. Very flexible although the filesystem should loose the device reference to be more Unix like.

I'll try to put something together for you.

One Word (1)

MountainLogic (92466) | more than 10 years ago | (#7963304)

EDLIN [wikipedia.org]

How can you have a great OS without such a tool?

Re:One Word (0)

Anonymous Coward | more than 10 years ago | (#7964243)

Oh good, i heard it's bug-free, maybe it could be used as part of the IDE for the safe language? ;-)

Shouldn't this be on Sourceforge? (2, Funny)

ameoba (173803) | more than 10 years ago | (#7970035)

I looked at the webpage and well... I saw nothing.

"Wouldn't it be cool if we could write an OS that's better than everything else out there. I want it to be radically different. Please join me & be brilliant & provide all the inspiration and drive to make me famous for heading this project".

Give me the VMS distributed lock manager (1)

Slashamatic (553801) | more than 10 years ago | (#7991034)

One of the features integral to VMS is the distributed lock manager. It can work on a single machine or across a cluster and quite transparently.

Resources are represented in a tree form and you may only lock something if you have a compatible lock higher up the tree. The lock-modes are something like: NULL, Shared Read, Shared Write, Protected Read, Protected Write and Exclusive. Certain modes are defined as being compatible with other modes, i.e., protected write with shared read. The resource tree means that you can only lock a record for write if you have the file open for write. If you can't get a lock, you get forced to wait. However, you can implement code so the current lock holder is imformed there is a waiter so the holder can choose to release the locks.

Another neat thing is that anyone getting access to a lock can receive an attribute block which can contain arbitrary information. This block can be updated by any system with protected write or exclusive lock levels and is instantly relayed to other processes, whichever node on a cluster that they reside.

Of course, the lock system has access levels, so a user can't mess with system held locks.

It really gets fun though because the lock manager doesn't give a damn about what the resources refer to, so you can use it for all kinds of things.

Re:Give me the VMS distributed lock manager (1)

neoneye (696191) | more than 10 years ago | (#7991590)

Lock manager.. Good suggestion. I have copied your text to the VMS wikipage [rubyforge.org] .

Which alternatives does there exists?
How is this better than the other alternatives?

--
Simon Strandgaard

Re:Give me the VMS distributed lock manager (1)

Slashamatic (553801) | more than 10 years ago | (#7995362)

What I liked about the DLM is that it is fast and multipurpose. Plenty of clusters implement resource managers but few are so versatile.

To give an example of a use for the DLM, is that I mentioned the value block. With this it is simple to implement a cluster wide transaction counter. I create a lock in exclusive mode and set the value block up with my transaction number. Each time I want to increment it, I grab the lock and increment the transaction number and then release it. The code becomes simple.

The other feature, much used by the file processor (XQP) is that the locks are asynchronous. You may have optionally have a call-back when a lock is grabbed or when you are blocking someone. The call back is an AST and may interrupt the mainline code at that access level. ASTs are also used throughout the system for I/O, process control and other activities. On macines without ASTs they can be implemented via threads and synchronization objects.

Other approaches tend to implement part of this, but not all, i.e., non-asynch or no value block or no resource tree.

The lesson from Unix is to make the locks visible under /proc using their resource names. Under VMS, binary information could be encoded into the resource name such as a record number.

IBM have implemented a partial distributed lock manager system for Linux in developerworks. However you also need good cluster wide communications. VMS tended to have drivers for various cluster wide communications varying from LANs (using multicast protocols) through to specialised buses.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?