Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software

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

Posted by timothy from the are-oh-what dept.
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."
This discussion has been archived. No new comments can be posted.

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

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

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

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

    I mean with regards to putting it into action.
      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'?

  • Plan9 (Score:2, Interesting)

    by spitzak ( 4019 )
    Look at Plan9 for ideas!

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

    • Re:Plan9 (Score:3, Informative)

      by AtrN ( 87501 )
      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.

  • Old/new idea (Score:3, Interesting)

    by be-fan ( 61476 ) on Monday January 12, 2004 @10:21PM (#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 (Score:3, Informative)

      by topologist ( 644470 )
      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 :-)
      • 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: kernel/userspace separation (Score:4, Funny)

      by some guy I know ( 229718 ) on Tuesday January 13, 2004 @01:25AM (#7960401) Homepage
      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.
      • 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

    • Re:Old/new idea (Score:5, Informative)

      by be-fan ( 61476 ) on Tuesday January 13, 2004 @01:47AM (#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.
    • You would have to ban native binary code then. Every thing would have to be some type of bytecode.
      • 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.
        • 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. I

          • 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" arra

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

        • 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?
        • 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) so

  • FreeVMS (Score:3, Interesting)

    by JDWTopGuy ( 209256 ) on Monday January 12, 2004 @10:28PM (#7959348) Homepage Journal
    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.
  • ... for my card reader.

  • Great Idea, Except ... (Score:3, Interesting)

    by zangdesign ( 462534 ) on Tuesday January 13, 2004 @02:53AM (#7960771) Journal
    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 (Score:3, Insightful)

    by davegaramond ( 632107 ) on Tuesday January 13, 2004 @03:22AM (#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 (Score:4, Insightful)

      by smcv ( 529383 ) on Tuesday January 13, 2004 @05:59AM (#7961290) Homepage
      - 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).
      • - 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
        • > 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 s

      • Re:Bad ideas and good ideas (Score:4, Informative)

        by JKR ( 198165 ) on Tuesday January 13, 2004 @08:31AM (#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.

        • 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 ;)

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

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

  • Already too many OS... (Score:4, Insightful)

    by Frans Faase ( 648933 ) on Tuesday January 13, 2004 @07:21AM (#7961530) Homepage
    ...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.

  • 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

    • 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.
      • I have been browsing the documents at HP, but without being able to localize the VMS user-manual.

        What am I missing?

        --
        Simon Strandgaard

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

          • 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

            • 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 :^)

    • 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

      • 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

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

  • EDLIN [wikipedia.org]

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

  • Shouldn't this be on Sourceforge? (Score:3, Funny)

    by ameoba ( 173803 ) on Tuesday January 13, 2004 @10:53PM (#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".

  • 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

    • 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

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

Slashdot Top Deals

To be is to program.

Close