Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

MenuetOS Debuts 390

Posted by michael from the next-linus dept.
Eugenia Loli-Queru writes: "OSNews is hosting an interview with Ville Turjanmaa, the creator of the Menuet Operating System. Menuet is a new, 32-bit OS under the GPL and it fits to a single floppy (along with 10 or so more applications that come as standard with the OS). It features protection for the memory and code, it has a GUI running at 16.7 million colors (except with 3Dfx Voodoo cards), sound at 44.1 khz stereo etc. And the most important and notable feature? The whole OS was written in 100%, pure 32-bit x86 assembly code!"
This discussion has been archived. No new comments can be posted.

MenuetOS Debuts More

MenuetOS Debuts

Comments Filter:

  • Anybody remember... (Score:4, Interesting)

    by Maddog_Delphi97 ( 173780 ) on Wednesday September 05, 2001 @10:49PM (#2258467)
    Anybody remember GEOS?

    That's another OS that was written entirely in assembly... by the time they finished, Windows had ALL of the marketshare...

    • Re:Anybody remember... (Score:5, Interesting)

      by GrouchoMarx ( 153170 ) on Thursday September 06, 2001 @12:18AM (#2258682) Homepage
      Not entirely accurate. GEOS pre-dated Windows by years. In fact, GEOS predated the Macintosh. It started on the Commodore 64, from Berkeley Software (the After Dark folks). It was ported to the Apple IIe a mere month before the Macintosh was released. It was then ported to the PC, and was released on the PC at the same time as Windows 3.0. All of the reviews at the time said that GeoWorks Ensemble, as it was called, was the better program. Graphical interface, wastebasket (had that on the Commodore version, too), a Documents folder, a full office suite that at the time had the full range of features in word processing, spreadsheet, and VECTOR-BASED drawing apps (yes, like Adobe Illustrator light, a decade ago), and support for running DOS programs as well. The entire word processor was only a few hundred kb, and it ran FAST, on a 286 and up. Development was done in "Graphical Object C".

      So what happened to it? GeoWorks (spun off from Berkeley) had no concept of marketing. Microsoft had an excellent concept of marketing, and a monopoly in DOS that they could build from. GEOS didn't stand a chance in the marketplace, and never took off.

      So, GEOS was ported yet again, this time to an entirely new platform. It was the OS for the Casio Zoomer Z-7000, the first PDA (predated the Newton). But the hardware was big and clunky, so it never took off. But it did provide a breeding ground for a little company that made software for it, including the handwriting recognition system. They were called Palm Computing, and a little while later they would be bought up by US Robotics where Jeff Hawkins would churn out the first Palm Pilot, finally jump starting the PDA "revolution".

      Yet another attempt was the porting of the GEOS 3.0 kernel to the Sharp PT-9000. It ran the same apps as the desktop suite, exactly the same apps. That made it completely and fully compatible between the two as a (gasp!) tablet-like PC, complete with pen interface. It had the level of integration in 1996 that Microsoft didn't dream of until 1999. But for reasons unknown, Sharp killed the project shortly before it was completed and it never saw the light of day.

      A final gasp was the HP OmniGo 100LX and 110LX, both of which were clamshell devices running GEOS. Also a no-go.

      Today, GeoWorks exists by owning a lot of patents on various obtuse concepts and pretending to have a case to file suit. Rather sad, really, but to this day my mother still uses GeoWorks Ensemble as her desktop environment.

      So what's the point of this little offtopic jaunt? The failure of GEOS had nothing to do with being written in assembly. It had nothing to do with it being late to finish, it predated all the big names, and in fact did a better job of them. (Ensemble is still the standard by which I judge the usability of an environment, and none have yet to match it, except maybe the Palm.) It had everything to do with marketing and marketshare. GeoWorks had engineers, but not marketdrones, and the MS marketdrones rolled over them like they weren't there. Lessons to be learned for anyone attempting to develop a new OS today.

      • Re:Anybody remember... (Score:5, Informative)

        by NaturePhotog ( 317732 ) on Thursday September 06, 2001 @01:23AM (#2258807) Homepage

        Mostly correct.

        GEOS pre-dated Windows by years. In fact, GEOS predated the Macintosh. It started on the Commodore 64.

        Commodore GEOS pre-dated Windows. I'm not sure if it predated the Macintosh or not. However, the PC-based version didn't come out until 1990. The Commodore 64 version was pretty cool, though -- a graphical OS and app (one at a time) in 64 K .

        The entire word processor was only a few hundred kb

        The current version is 114K. It hasn't been updated significantly in a while, and so is lacking indexing and some other key features, but it's a pretty amazing little app.

        Development was done in "Graphical Object C".

        The OS itself was in 80x86 assembly, as were the initial apps (WP, drawing, spreadsheet). Later libraries and some apps were done in GEOS Object C.

        It started on the Commodore 64, from Berkeley Software (the After Dark folks)

        After Dark was from Berkeley Systems [berksys.com].

        GEOS (Commodore and otherwise) was from Berkeley Softworks. The company was later renamed GeoWorks, then Geoworks [geoworks.com].

        Today, GeoWorks exists by owning a lot of patents on various obtuse concepts and pretending to have a case to file suit.

        AFAIK, Geoworks only has one patent, the flexible UI [uspto.gov]. It's not particularly obtuse; it's a fairly cool concept (the reactions from people seeing a demo with apps running under Motif, OpenLook and a CUA interface all on the same screen was pretty funny). What's potentially obtuse is enforcing the patent against WAP. But IANAL, so I don't know if it's a stretch or not. Hmm...strike that. They got a second patent [uspto.gov] that looks a little more WAP/HTML specific.

      • Wow, I remember GEOS! Didn't early versions of AOL use a GEOS windowing environment running on top of DOS? I seem to remember it that way... (I used to sign up for free AOL trial subscriptions way back when so I could download files, then upload them to local BBSes for leeching privileges... yeah, cheesy)
        • Yep. AOL started out as QuantumLink on the Commodore 64, so AOL and Geoworks (then Berkeley Softworks) had an existing relationship. As PCs became more popular, AOL and Geoworks co-developed an AOL client that ran under GEOS to go along with their Mac-based client. For many years, even after Windows had taken over, if you requested the "DOS version" of AOL they'd send you a stripped down version of GEOS and the AOL client.
      • I'm fairly confident GEOS came out after the Macintosh. The Mac was released in January of 1984, or at least that's when the Superbowl ad ran. I first saw one at a computer show in the spring of that year.

        1984 was a pretty important year for Commodore, as it was when the C-64 dominated sales.

        I'm fairly certain GEOS was released towards the end of 1984. I remember first seeing it in around that time frame, and I was fairly in tuned with the Commodore scene at the time. (founded local Commodore user group and was friends with a number of magazine authors, etc.)

        This history of the GUI sounds about right:
        http://pla-netx.com/linebackn/guis/guitimeline.h tm l

        It talks about GEOS being released in 1985. I think it was early 1985, just before the Amiga launch. It was a pretty big thing at the time.

        The Casio Z-7000 was most certainly not the first PDA. First of all the Newton was released before the Zoomer. The term PDA was coined by Apple.

        But there were many small handheld computers dating back many years prior to this. Radio Shack, Sharp etc. had handhelds back in '81. The PC-2, etc.

        Granted they didn't keep your schedule and contacts, but. The first computer I saw performing that task was the Atari Portfolio in '89. As I recall it was the first handheld that ran MS-DOS and had a small spreadsheet, etc. The father of a friend of mine purchased one, and it was quite cool at the time.

        That's not to say GEOS wasn't cool, because it was. GeoWorks for the PC came out at a particularly turbulent time, but I recall it being reasonably popular for a period of time.

        • I'm not sure when GEOS/64 was released, but I don't think it was before mid 1985. That's when I got my C-64. Eventually they started bundling it with 64s, but I don't think that started until 1986. I'm not sure how long it existed before the bundle.

          Now I wish I hadn't gotten rid of a huge stack of Compute's Gazette magazines from the mid-80s. One could probably find a lot in there. :-)
      • The entire word processor was only a few hundred kb, and it ran FAST, on a 286 and up.

        Err, sorry, no it ran fast on a 8088 and up. Bloody embarrassing for today's operating systems including Linux if you ask me.

        I don't know if the whole thing was written in assembly - I doubt it in fact. Using their SDK (running on a SPARC station 1) I developed for it in C.

    • Re:Anybody remember... (Score:5, Informative)

      by NaturePhotog ( 317732 ) on Thursday September 06, 2001 @12:25AM (#2258706) Homepage

      Anybody remember GEOS? That's another OS that was written entirely in assembly... by the time they finished, Windows had ALL of the marketshare...

      Yep, I was one of the developers (fonts, help system, spreadsheet, DBCS version). GEOS is a pre-emptive multi-tasking, multi-threaded OS with a GUI, single imaging model, object-oriented (object-oriented assembly? MooOOoo!), and lots of other wizzy features. It originally ran on a 4.77 MHz, 640K IBM XT, and still uses less than 16MB of disk space (your video card probably has that much RAM now :-)

      The OS and apps were done in a reasonable amount of time, but the big problems were:

      1. the SDK wasn't available for too long
      2. the SDK initially only ran on SPARCstations
      3. Microsoft had a OEMs locked into using Windows if they wanted to use DOS. DR-DOS was an option at one point, but OEMs were scared off from it by the incompatabilites MS added

      GEOS still lives on. Several companies worked with it until recently, NewDeal [newdealinc.com] and MyTurn.com [myturn.com]; both are, alas, now defunct. Nokia [nokia.com] used GEOS for the 9000/9110 Communicator which is still alive and kicking. The OS still belongs to Geoworks [geoworks.com] where it was created, but lots of software is available at Två Katter [tvakatter.org].

  • Firstly I've got to say congratz for knocking this one out. But to be honest how many more Operating Systems do we need?

    I'd settle for Application software that worked the way I like to work.

    • Firstly I've got to say congratz for knocking this one out. But to be honest how many more Operating Systems do we need?


      It's not really a matter of need, as in how many Operating Systems do we need to try and push on people's desktops. Instead, it becomes a matter of people trying different methods of OS Development and different design philosophies. Think about it for a minute - if only 4 or 5 groups created all Operating Systems that are out there, it would be unlikely that new ideas in OS development would be fully explored.


      You might want to look around and check out all the Operating Systems there are out there that researchers and hobbiests (sometimes there doesn't seem to be THAT much of a jump between the two ;-) have spent tons of time on. Sometimes they are developed just to 'scratch an itch', sometimes they are developed to see an idea all the way to completion to see how well it works out.


      Don't knock these guys for trying to develop a new OS - sometime or another the ideas they come up with may end up in Linux, *BSD, etc. (Of course, in the interest of full disclosure, I work with an alternative OS project [allos.org] that somewhat died, and just got resurected this week. ;-)

  • v2OS (Score:1, Informative)

    by Anonymous Coward
    This sounds exactly like v2 OS... last I heard v2 had finished its C libraries and TCP/IP...

  • Doh.. (Score:3, Interesting)

    by RAruler ( 11862 ) on Wednesday September 05, 2001 @10:53PM (#2258483) Homepage
    This sounds incredibly cool, but with all these new OS'es popping up like QNX, AtheOS, and my alltime favorite BeOS. The only problem is, that theres too many showing up, and too little support for them. Sure, this is a great example of what you can do with Assembly, but are you gonna make a full fledged OS out of it? Is anyone working on a brand new OS that they think will actually go someplace? Personally, i'm still holding out that BeOS doesn't sink like the Titanic..

  • Assembler? Bah! (Score:4, Funny)

    by Sagarian ( 519668 ) <(ude.tim.mula) (ta) (rellims)> on Wednesday September 05, 2001 @10:54PM (#2258484)
    An operating system in assembler? Bah! Such high level languages are tools for the weak, macros be damned! You know what I have to say about that? Reminds me of an old joke by Alan Turing : 11100101010100100111010100101010010100101001111 ? 10011010100111011100001 !!! HA!
    • That joke is as funny as Stephen Hawkings crawling...

    • An operating system in assembler? Bah! Such high level languages are tools for the weak, macros be damned!

      Heh. Interesting perspective. I suppose all the nasty compatibility issues imposed by assemblers are all but erased, are they?

      Never mind the debugging you'll have to spend with machine language. Assembly has its own issues, of course - mistyped register numbers, wrong hardware addresses, then the usual programming errors you get in any other language. But with machine language, you have to count your zeros and ones very carefully... of course, you'll eschew the bourgeois luxury of hexadecimal, won't you?

      :)

      I love Assembly. Back in high school, I was ordered to write a program that made a computer play music. Everyone else wrote little Pascal and structured BASIC programs to play Chopsticks on the school's Macs 512s.

      I wrote a TMS9900 Assembly program which played Flight of the Bumblebees in three-part harmony with the stepper motors of my TI-99/4A's three 5.25" full-height SSSD diskette drives. Percussion was achieved by toggling the head pad solenoids.

      My Computer Studies teacher didn't like it because he couldn't understand it to critique it. But he gave me an A+ anyway, probably because the source code was about 30 pages long.

      Ahhh... High school.

      While I haven't programmed in Assembly in about ten years, you can check out my resume here [glowingplate.com], since I'm looking for work!

  • os written in lisp? done.
    os written in C? done.
    os written in asm? done.
    os written in java? "done"

    my remaining options are perl, tcl or awk.... hmmm.
  • There are ton of pet project operating systems like this. Some simple searching revelas a huge community of these DIY operating systems. :)

    Jeremy

  • Wonderful (Score:2, Funny)

    by Octal ( 310 )
    x86 assembly? Now that's what I call portability!

  • First question (Score:5, Insightful)

    by All Dead Homiez ( 461966 ) on Wednesday September 05, 2001 @11:05PM (#2258525)
    1. You have wrote the whole OS in a x86 assembly. How much speed you think you gained by using asm-only when compared writting the source in C or C++?
    Ville Turjanmaa: Parts of Linux was rewritten in assembly and the speed gain was 10-40%. That will give an idea.

    I don't mean to flame here, but one of the first things you learn in a computer architecture class is to "make the common case fast." The parts of Linux that were rewritten in asm that improved performance by 10-40% were most likely primitives that were executed hundreds of times a second - like bcopy() and maybe some parts of the VM subsystem. Ville's response draws no distinction between rewriting bcopy() in asm, and rewriting printk() (which is slow, but rarely executed) in asm. Unfortunately, I see no point in rewriting them both if it's not necessary. Sometimes it matters but often it doesn't.

    The space advantage to hand-optimized asm is clear, but the cost in portability and time almost certainly outweighs it. I really don't see what this OS offers that Linux doesn't have.

    -all dead homiez

    • Re:First question (Score:5, Insightful)

      by PaxTech ( 103481 ) on Wednesday September 05, 2001 @11:14PM (#2258551) Homepage
      I really don't see what this OS offers that Linux doesn't have.

      No one made claims about it offering anything that Linux doesn't have. It's a neat hack. The guy thought of something that hadn't been done before, wondered if it could be done, and then did it. An excellent hack is its own reward.

    • MenuetOS has been floating around for a while now. I briefly looked at the website a while ago, it looks tres cool, but I don't know much about it. Even without knowing the details, I can say that for a hobby project, this is a staggering accomplishment. As well, there other operating systems in development that are 100% ASM, Unununium comes to mind. http://uuu.sourceforge.net/

      The fact that the operating system was made in ASM is bringing up the low-level language versus high-level language war. I will admit that Linux and MenuetOS aren't really comparable. But ignoring differences, the end result: MenuetOS makes Linux look MEGA bloated, slow, and laughable. You guys should be taking 2nd, 3rd, and 4th looks at QNX RTP, BeOS, and AtheOS. This should serve as a big kick in the ass for you all Linux-fans. It's really nothing "that great." Sure it's free, but you sacrificed quality.

      People claim that C compilers can generate code that is similar to what an ASM programmer is capable of. This is not true. A well-planned and pain-stakingly optimized C program can approach a novice ASM programmer. But this is almost never the case. Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.

      Anyway, I could go on forever. If you want to address anything I said, I am ready prepared for retaliation. :)
      • If your definition means extremely well optimized at the expense of long dev time and completely unportable, so be it.

        Indy cars have exceptional quality for that particular track; aren't they even optimized for left hand turns? But most people would choose to own a well done street car.

        The parallels in dev time and portability say enough.
      • People claim that C compilers can generate code that is similar to what an ASM programmer is capable of. This is not true. A well-planned and pain-stakingly optimized C program can approach a novice ASM programmer.

        You know, maybe that's true if you have a genuine 80386 or -486 chip, but with the "Family 6" of Intel processors (p 2, 3, and 4), customized compilers produced by the manufacturer know WAY more about the particular branch predicting and out of order dispatch, to name just 2, than any novice ASM hacker.

        The problem is we don't really deal with the fundamental instruction set of the processor anymore. The intel family 6 and the AMD K6 and 7 are super-pipelined beasts which re-implement the x86 instruction set by basically having a front-end block transform those macrocodes into custom micro-ops.

        So you probably still CAN produce faster code with an assembler than, for instance, "gcc -o2," but you'd better have the block diagram for the processor sitting around to guide you, and that's not exactly a task for the novice. And I'd still be willing to bet that your margin over a manufacturer's custom compiler would be razor-thin, at best.

        Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.

        Well, that's an aesthetic choice, and I'll let you have it, but I'll take the inherent "beauty" of well-commented C code any day.

    • Re:First question (Score:4, Insightful)

      by tshak ( 173364 ) on Wednesday September 05, 2001 @11:54PM (#2258625) Homepage
      The problem is, this OS's codebase will not scale due to the fact that it will be nearly impossible to debug once it get's the size of... two floppies.

    • Re:First question (Score:2, Insightful)

      by schwap ( 191462 )
      The space advantage to hand-optimized asm is clear, but the cost in portability and time almost certainly outweighs it. I really don't see what this OS offers that Linux doesn't have.

      I wonder, when linux 0.01 came out someone said:
      I really don't see what this OS offers that Minix doesn't have.

      I think thats all I have to say.

    • I really don't see what this OS offers that Linux doesn't have.

      A nice standard desktop?
    • Add to that the extra cost of maintaining and error-checking the more cryptic code vs. improvements that could have been made using that time, and the end-user might have been more benefited by writing most of the code in c/c++ (or a similar language).
    • The question of "is it practical to code is assembler" is utterly meaningless, without some context. If you're writing firmware for a low cost, mass produced embedded product [slimdevices.com], your development time/cost is not crititcal, and you plan to sell a million units, then by all means, code *everything* in assembler. Save $2 by using a smaller CPU/RAM/ROM, and that's an extra $2 million you can afford to spend on development.

      In this case, the guy was writing an operating system. It fits on a floppy disk. It's really fast. So what, you might say... I have a $1K PC with an 80GB hard drive, what the hell do I care how fast printk() is, or the size of my kernel image.

      Now imagine you're developing a router, or a Tivo, or an Internet toaster. You need an OS. Your choices are Linux, running on a $40 ARM or PowerPC chip, or Menuet, running on a $10 i386.

      Besides the compelling practical applications for MenuetOS, I'm sure the guy learned one hell of a lot about computer architecture in the process of writing it. It's not just about hack value - coding in ASM is a wonderful learning experience.
    • I don't remember which famous book it was that went around software development, but one of it's sentences was.

      "A software usually spends 90% of the time in 10% of the code".

      Which is most times pretty true. Now say you've finished an application and it runs too slow, the plain way is to optimize just anything that hits into your mind. Now say you super-optimized the other 90% of the code in which the application spends only 10% of the time to zero effort, you're final application is only 10% faster, not much for the cross assumption we reduced the time requried to null.

      So what's the "good" way to do? Run a profiler on the application, find out which 10% of the code is responsible for 90% of the time, and optimize this one, if you're good you can it optimize by the half. So the application runs 45% faster, altough you only re-coded 10% of the code.

      Same goes for linux where some percent was rewritten in assembler. Well I guess in the special cases of OSes the breaking point is even more higher, 98%/2%, but it's only some magic number you could tell without the special code in testing.
    • Portability?? WTF are you talking about it's a god damned OS, not a ridicolous little java app. You have to write for the hardware at that level.

  • Is it just me? (Score:5, Insightful)

    by evanbd ( 210358 ) on Wednesday September 05, 2001 @11:07PM (#2258530)
    Or is a stack trace a *helpful* thing when debugging code?


    From the FAQ:


    And the benefit of asm coding is that if you make a mistake in programming, you notice it immediately. You dont get warnings, things just wont work.


    Anyone else have serious doubts about this thinking?

    • Re:Is it just me? (Score:2, Informative)

      by Chakat ( 320875 )
      You can have a stack trace and access to a debugger in assembly - even GDB can follow assembly instructions. Also, you have to remember that the earliest parts of the Linux operating system, back when it was Linus' toy to learn x86 assembly, had a different, yet still very useful way of debugging. He would set hard break points in the routine he was working on, and then running the resulting (ultra-primitive) operating system code. If it halted, he knew that it hit is infinite loop and that section worked. If it rebooted due to an exception being thrown, then he knew that there was something wrong with that section of code that he would have to investigate.

      Assembly debugging may be harder, but when it does break, you sure know it. If you've been using it long enough, you can tell how it broke, and maybe even close to where it broke.

  • A step backwards... (Score:3, Interesting)

    by Tom7 ( 102298 ) on Wednesday September 05, 2001 @11:10PM (#2258538) Homepage Journal

    What crazy reasoning drives a project to write something complicated and difficult in a lower-level language than the current best practice?

    The only thing I can think of is the idea that it will be leaner and faster, which are seriously misguided notions given the trend of faster and faster hardware. What we care about now are scalable algorithms, stable and robust kernels and drivers, and appropriate abstractions to allow easy extensions. All of these are made easier by high-level languages. They are made more difficult by machine language.

    What I'd like to see is a powerful kernel mostly written in a very high level safe language like O'Caml or even Java. That would be a feat with some important consequences.
    • What I'd like to see is a powerful kernel mostly written in a very high level safe language like O'Caml or even Java. That would be a feat with some important consequences.

      How do you think your going to load a java interpreter to run the kernel? :) 25 meg "sun microsystems" MBR ?

    • Does the term "VM" mean anything to you ? This is why talk of java's portability is non-sensical, java programs only run on a single OS - the java VM. "I can write an OS, first of all, give me an OS..."

      Besides, the point of an OS is to manage low level system resources, like registers, cache, memory, devices. You can do the meta-level stuff in a high-level language if you like, but at some stage you're going to have to go low level. Plenty of OS's have been written (as far as possible) in higher level languages than java.

      • Thank you, thank you, thank you. And God bless you. I've been saying that for years. Java is not any more portable than any other language. It's just had the porting code done ahead of time for you.
    • Yes it would be a feat with important consequences like a slow crappy OS to rival Windows. Java is useless for systems work. Seriously misguided my ass, it doesn't matter if the hardware is fater and faster, the assembler and c code will still be faster than Java. The attitude of these days especially in Universities is that speed no longer matters, and that's just bullshit. It's that attitude that give us windows and legions of crap ass coders that only know java, the lincoln log set of languages. Java has it's place, but the phrase seriously misguided is more appropriately applied to these people who believe that Java, or any language for that matter, is the be all and end all of programming languages.

  • As a quick response (Score:5, Insightful)

    by fluxrad ( 125130 ) on Wednesday September 05, 2001 @11:10PM (#2258540)
    ...to those of you who ask "How many OS'es do we need?"

    Think about when linux first came out, and everyone said "How many frickin' OS'es do we need? We've already got DOS, MacOS, and Unix (variants, etc.)"

    New OS'es are good for the market, people! They provide a fresh perspective on the way things should be done and facilitate ingenuity and competition. They may not all become famous or provide new tools or inventions to the OS market, but some of them do - and that's exactly why we need 'em.

    In that light, i must say i've yet to see someone bitch "Jesus, how many different types of cars do we need?"
    • I agree wholeheartedly about multiple OSes being good for competition and all the resulting benefits thereof. But there is one flaw in your car analogy. Gas is gas is gas. Super unleaded works in a Ford, a Chevy, a Subaru, a Toyota, and a Kia. Software is not so multi-platform.

  • Speed Up? How much (Score:3, Insightful)

    by maxbayes ( 519102 ) on Wednesday September 05, 2001 @11:12PM (#2258545)
    The speed up achieved by writing the whole OS in assembly isn't much. you just can't compare it saying parts of linux was written in assembly and that got 10-40% speedup. That doesn't mean it'll scale up in propotion.
    Turjanmaa doesn't even have an estimate on how much speed up he's achieved. but my guess would be not more that 10% over linux. cuz the most accesed part of linux is already in assembly, so you won't have huge speedups.
    • cuz the most accesed part of linux is already in assembly, so you won't have huge speedups.
      It's entirely possible they're doing something totally different from the way Linux does it. Maybe there are kernel primitives much closer to x86's particular brand of assembly (SIMD enhancements perhaps?) and every piece of code is examined to determine when and where using those things would make sense.

      All the same, I think I'm with the "who cares" crowd on this one. What does it do besides "me too"? I don't think I'll care about any new OS until it's fully object-driven and secondary storage is transparent to the applications programmer. Then we'll talk.

      -jhp

  • If this is GPLed, where's the source? I couldn't find it. I downloaded the OS and tried it out a bit, and it actually seems quite good. Mind you, without a TCP/IP stack and such, it's pretty useless, of course, but whomever was behind this is clearly pretty good with the assembly. I'd love to see if the code is even remotely maintainable.
  • If you are having trouble with the link, try this [menuetos.org] one.

    Need to whore me some karma....

  • if it's in assembler... (Score:3, Funny)

    by Satai ( 111172 ) on Wednesday September 05, 2001 @11:26PM (#2258575)
    ...does that mean it'll be a pain in the ass to fix "LENGHT" to "LENGTH" in the editor picture on the website?

    but seriously, this is pretty sweet. i'm going to load it up at work tomorrow.

  • I don't mean to be a "flamer" but, please let us think about this in a broader perspective.

    Lately I have been seeing a lot of OS announcements (as may posters pointed out before me) everything from BeOS, to FreeDOS and Linux, et. al. -- and all of those OSs seem to be centered around taking on Windows of the evil M$.

    If that is the intention, may I suggest that the OS war is over and that M$ is the clear winner and that any continues battle on this ground is just a step backward.

    Lets face it, in few more years, we will care less about the OS and wary more about the user interaction and front-end applications. Even Linus Torvalds realizes this as his new focuse for Linux is now on: Making Linux usable tops Torvalds' list [cnet.com]
    • Um, I think you can probably divide new OSes into two categories:

      Commercial, which obviously have to compete with Microsoft whether they like it or not.

      Non-commercial, which don't generally seemed to be targeted at Microsoft at all.

      This guy's OS fits into the "because it'd be cool" subcategory of "non-commercial".

      You've got a good career ahead of you as a pundit, though. That much is glaringly clear.
    • Your post seems to indicate that you believe that there is an OS "war" going on, with separate camps struggeling for world (or at least computer) domination. While I think this is true (to an extent) for commercial systems that compete directly with one another, I think it's pretty silly to generalize it to Linux, other Open Source OSs, and niche systems.

      Systems basically appear randomly when someone's pet project becomes stable enough to appear on the /. radar, or when a company tries something new, thinking they've found a new niche market to make some money in. If they are crap (many are), they will just go away after a period of time. If they do what they were designed for well (assuming there was some form of design involved), they fill their niche. A select few grow in strength, and as their popularity and abilities grow, their "population" increases.

      The analogy I'm trying to draw is one with evolution (as you may have guessed). Random mutations create new organisms. Most mutations are detrimental, and the organism dies (or never makes it past the embryo stage). Others confer some form of advantage, and presto, you have a platypus. Of course whether the penguin is an animal with just a small niche or the potential to become the dominant species remains to be seen!

      My point is, though, that just like in evolution, there is no predestined goal of "domination", or a conscious quest for survival. The best we can do is introduce some new mutations and do a little bit of genetic engineering on our favourite uh... OS, and hope for the best.

  • I'll stick with Penix [very.net], thanks.

    The Penix system uses interpreted BASIC for "Ease of Modification". Good move in my book. BASIC programmers are plentiful.

  • Isn't assembly trivial to get from a binary anyway (Score:3, Interesting)

    by aozilla ( 133143 ) on Wednesday September 05, 2001 @11:49PM (#2258615) Homepage
    From the GPL: "The source code for a work means the preferred form of the work for making modifications to it."

    Guess that means he has to distribute the C version, too.
  • I just upgraded my entire company to this OS and we are blazing ahead into the early 90's. Some of my 'less-educated' users are complaining about the lack of support for StarOffice but I'm assuring them that it will come with time. In the meantime I'm working on a Lynx port. I never knew I could get 10% (!!!) improvement on my existing Pentium II 1 Ghz machines!

  • Thinking of uses for this... (Score:4, Interesting)

    by mcc ( 14761 ) <amcclure@purdue.edu> on Wednesday September 05, 2001 @11:52PM (#2258622) Homepage
    Well.. just a thought..

    Was trying to think of maybe how this would be good for anything other than rootdisks and novelty value.. and then i started thinking.. well.. 44-khz stereo sound, workable gui, MIDI support..

    I can't get the thought out of my head that something-- maybe not this specific OS, because this specific OS is tied to the x86, but maybe something patterned on the same general system design-- like this would maybe be actually useful as an embedded OS for a sampler.

    Am i just completely on crack, or would a sampler/synthesiser with a small lcd screen and an os like this one be as cool as it seems to me it would be?

    Then again, any really cool stuff you could do with such a system-- say, letting you program your own midi synths in realtime-- would *demand* that it have an interpreter for something more high-level than assembly built in, and doing, say, a LISP/Python interpreter in an environment written wholly in assembly could maybe get messy. Maybe we'd rather have an OS written in LISP in our samplers....?

    Oh, the hell with it. Forget i brought it up :)
    • this was my thought, as well.....in fact, the fact that it is a RTOS lead me to initially believe that this was the aim. I still haven't really seen the point, except that the guy wanted to do it.

      it would be a cool embedded OS, though. the GUI is decent enough, to make it worth the time. it really looks like it would be a good alternative to QNX or NT embedded...BUT, would licensing issues make it impossible for a small company to use it without releasing their source, considering the entire OS seems to be under the GPL? the GPL is great, but the companies that produce POS's and other such devices that could use a GUI generally try to be pretty proprietary with their software.

  • On asm vs "proper" programming (Score:5, Interesting)

    by Alan ( 347 ) <.gro.seifu. .ta. .xeretcra.> on Thursday September 06, 2001 @12:19AM (#2258683) Homepage
    Ok, most of the responses to this so far have been "assembler doesn't give you that much improvement" , "assembler is a bad way to do things if you're trying to do them The Right Way".

    Well, why can't he use asm? If I want to write an OS is BINARY that's a cool-ass hack, even if it is not The Right Way to do it. Come on guys, give the guy a break... he did something *awsome* and something probably 98% of us can't do (I know I certainly can't) and he should be credited for that. I'm not saying that this OS is something that should be taught in OS design courses, but it's still very very VERY cool :)

    • Re:On asm vs "proper" programming (Score:5, Insightful)

      by thockin ( 514323 ) on Thursday September 06, 2001 @01:24AM (#2258811)
      The point here is not whether it is "proper" to code an OS in assembly - it's been done for years. The point is that if one is to write an OS nowadays, and they choose to do it in all asm, they are doing it for the sake of doing it.

      100% asm does NOT buy them improved coding efficiency or improved maintenance or debugging (I've yet to meet an asm coder who can write as much as fast as a mediocre C programmer). What 100% asm does, is make them feel special. That sounds derogatory, but it's not.

      Chances are that the world doesn't need a new OS. Chances are that he didn't do anything revolutionary or groundbreaking. Chances are that he will never make a red cent off his OS. Chances are he had a great time doing it.

      I've written an OS from scratch. It's hard. My OS is nothing special or groundbreaking, heck it barely DOES anything. Did I do it? yep. Did I have fun? yep. Did I learn a lot? yep. Did I do it in 100% asm? nope. I'm not that good at asm, and truth be told, I don't care THAT MUCH. I like C. C is a good language for an OS.

      If this guys likes writing and debugging asm, then more power to him. But let's not mistake this for a decision about "properness" or even pure efficiency. He did it beacuse he felt like it.

  • Maybe for the embedded / handheld market? (Score:3, Insightful)

    by MadCow42 ( 243108 ) on Thursday September 06, 2001 @12:21AM (#2258686) Homepage
    Sure, there's a plethora of other OS choices these days, but a small, efficient, graphically based OS would lend itself very nicely to the embedded / handheld market.

    Sure Linux is cool, but once you slap X on top of it, it's not nearly as efficient on slow machines.

    Who knows... you could have a Menuet based PDA or phone next year.

    MadCow
  • Or does the link go to an almost-blank page with only a single banner ad flashing at the top? What gives?

  • An OS from Finland? (Score:4, Funny)

    by robinjo ( 15698 ) on Thursday September 06, 2001 @12:45AM (#2258748)

    An OS from Finland? Does this come from the frozen small hellhole next to North Pole? Do they even have electricity there? World domination? Yeah right. Won't happen in a million years!

    ...said people 10 years ago and went on with their life. Boy, were they wrong.

    Never underestimate an OS that comes from Finland.

  • What about the (IMHO) famous programmer Steve Gibson [grc.com], author of Spinrite [spinrite.com] (sorry /.ers, may be before your time) who writes all his stuff in assembler? His utilities and more would easily be fit onto a floppy disk - even though some use the Windows API (AFAIK). This dude is a guru to anyone using and appreciating the x86 platform! When MFM hard drives were all we had, he provided us a way to keep them working well beyond the MTBF the manufacturers had planned (or promised). A purist beyond belief - and a blowhard in rhetoric, (if you check out his website), yet, a genius in assembler (we're not worthy!)(sorry; tried for a link and was overwhelmed)

    Can you say "change my interleave without FDISK first?"

    This guy rules! Don't forget him! He's at least as important as Peter Norton. Maybe more...
  • Rather than write assembly code targetting for platform X, what do people think of taking a more portable approach and writing a translating assembler which uses basic assembly instructions (jump, load, mul, add, comp, etc.) but translates them into actual platform assembly code which can be turned into native machine code for all supported platforms? Where an instruction (say, 'div') isn't supported by a platform's microcode, it can be implemented using several simpler instructions.

    An approach like that should keep things at a low level allowing slim code and fast execution times, but not lock the end product onto a single platform.

    Does an assembly product like this already exist? I tried searching freshmeat, but gave up after browsing through several pages of disassemblers, regular assemblers, etc.
    • You're thinking of C. Assembly isn't meant to be portable. The idea of writing assembly code is to tune some very efficiency-critical code for a particular platform.

      What portable code would you write, which wouldn't be easier (and probably faster, since the compiler could do more optimization) in C? (Or -- god forbid -- a high level language?)
  • Can you remember the V2 Operating System? It was also posted on Slashdot some times ago. It was very promizing, written in full asm, had a nice GUI, a nice shell, a nice debugging console, etc. A very similar project.
    Does anyone know what V2 OS has become nowadays ?
  • There are a good number of alternative OSes out there, similar to this one. They don't get much attention, however, as they're all (1) short on useful applications, and (2) not Linux. But remember that being UNIX-like is not necessarily the end goal of operating systems, so I'm happy to see alternatives being developed.

    As for the negative comments about this OS being written in assembly:

    Remember, the rule of optimization has always been "make it work, then make it fast." Low-level OS details--multitasking, memory protection, resource handling, memory management--have been solved problems for 30 years or more. So we know how to make it work; it's okay to focus on making it fast. And, yes, to an experienced programmer with the right mindset, assembly is still faster than C++, everything else being equal. That's just been accepted as a truism, though it was once heresy (much as programmers now accept that object-orientedness is not the panacea that everyone once thought it to be).
  • I'm going to write an OS in VB!

    with one hand tied behind my back...
  • I seem to recall from the "C Bible", ANSI C by K&R 2nd Ed, that C was born out of the need of improved code base maintenance. It wasn't an argument as to whether or not assembly was "better" or "faster", it was an argument as to whether assembly was a reasonably useful language for a codebase as large as an operating system. By its very nature, assembly is cryptic. Although C is a bit abstract, it's understandable at a higher level.

    It's great that people wish to write applications and operating systems in assembly. They possess a greater knowledge of the hardware layer of the computer than I, and a greater need for the abstract. Given the choice, C is my preferred language. It allows me to concentrate on the application side of things, yet gives me enough low-level control that I can do hardware specific instructions w/o having to enter the assembler.

    Assembly has its uses, especially in code optimization, and it will probably never go away for that same reason. It is certainly a "no nonsense" approach to programming, and ideal for embedded applications.

  • Well, I suppose this guy deserves praise for having achieved something unusual, but as far as I am concerned, this is of the order of building a 50ft Statue of Liberty replica in one's back garden using beer cans. Difficult, possibly absorbing, oddly impressive, and utterly useless.

    There are a whole bunch of reasons not to do this.

    1. It's not efficient, even in the limited sense "producing code that runs faster than the opposition". On modern architectures, using pure handcoded assembly only tends to have a performance benefit when you know something the compiler doesn't (say, some kind of aliasing relationship among variables in a function) or when you can use instructions that a compiler can't. Rewriting a hot-spot in pure asm is one thing, but trying to beat the compiler overall is quite another. This disparity is even more pronounced in the world of RISC/EPIC... if you doubt me, try beating global register allocation for a function with 200 basic blocks and a thousand live ranges. By hand. Good luck...

    2. It's not in the slightest bit portable. Not to other architectures (obviously) - and it's liable to suffer from immense performance problems even moving to other implementations of the same architecture with different latencies and numbers of functional units.

    3. It's been done already, ages ago. This is how people used to build operating systems. There are good reasons why they stopped. There is nothing innovative about doing another Commodore 64 operating system almost 20 years after the fact. The constant and strange references to color and sound sort of reinforce this impression, too.

    4. It doesn't illustrate any particularly interesting principle. Using a medium-level language (or even a high-level language) to build a toy OS from the ground up allows you to concentrate on OS principles, while still getting down to the bare metal for the code that has to be written in asm. Writing a boot-loader or a well-optimized string copy function is an illuminating task (well, at least the first time you have to write one, anyhow). However, once you are a competant asm programmer, writing merge sort in asm instead of C will teach you nothing about asm or merge sort that you didn't already know. And one could use the time saved to learn the basic principles of optimization, which, based on his remarks about Linux, the author of this system clearly doesn't know.

    5. Asm is difficult to write and debug. No compiler to catch obvious errors. This is so obvious to require no discussion.

    6. (addressed only to those people who think that this leads somewhere practical - if you merely admire it as a beer-can-Statue-of-Liberty, ignore this one) It'll Never Work. I'm sure it does just fine as a toy system, but a POSIX layer? A TCP/IP stack? Ummn, no. It's simply never going to happen. There are plenty of tiny OS's around on which lean systems could be based, but they were written and designed to be dense and elegant, not to prove some weird point about asm programming.

Slashdot Top Deals

"I got everybody to pay up front...then I blew up their planet." "Now why didn't I think of that?" -- Post Bros. Comics

Close