MenuetOS Debuts 390
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!"
Anybody remember... (Score:4, Interesting)
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)
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)
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.
Re:Anybody remember... (Score:2)
Re:Anybody remember... (Score:2)
Not quite correct... (Score:2)
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.
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.
Re:Not quite correct... (Score:2)
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.
Re:Anybody remember... (Score:2)
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:2)
Re:Anybody remember... (Score:5, Informative)
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:
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].
GEOS under a new name - NewDeal (Score:2)
Actually, GEOS was *purchased* by a zealous group of GEOS users and renamed to NewDeal... www.newdealinc.com
Well, I tried to download the demo, and they aparently are having some MS-SQL problems. Ya know, I'm going to have to play with this a bit - I always liked GEOS the first time around. NewDeal may be worth a look. Unluckly, that's probably all it's going to be worth. :-( I can't exactly see there being much support for it, application wise.
But, you HAVE to love the requirements for running it:
How many OS's do we need (Score:1)
I'd settle for Application software that worked the way I like to work.
As many as there are hackers for... (Score:2)
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)
Doh.. (Score:3, Interesting)
Re:Doh.. (Score:2)
Assembler? Bah! (Score:4, Funny)
Re:Assembler? Bah! (Score:1)
Diskette Drive Classical Music - Assembly! (Score:2)
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!
Re:Assembler? Bah! (Score:2, Funny)
Of course it doesn't translate to ASCII. Alan Turing died in 1954 and ASCII was created in 1963.
The joke is probably a Turing machine tape anyway. We don't know how to interpret the symbols without the state machine specification to give it context. Many jokes are not funny out of context.
what's left? (Score:1)
os written in C? done.
os written in asm? done.
os written in java? "done"
my remaining options are perl, tcl or awk.... hmmm.
Re:what's left? (Score:2)
my remaining options are perl, tcl or awk.... hmmm.
Hail to the king, baby. [tomsk.ru]
Re:what's left? (Score:5, Funny)
Re:emacs (Score:2)
All you need to do with emacs is write an extension for it to load as a server in MACH...
Oh wait, then you'd have HURD... nevermind.. ;)
Nothing New (Score:2)
Jeremy
Wonderful (Score:2, Funny)
Re:Not only is ASM not "portable" to other CPUs... (Score:2)
But if you ARE trying to impress girls, WOW, I can't think of a better -- oh, wait. Nevermind. Someone already found a better way, a webserver coded in PostScript [pugo.org].
Re:Webserver coded in PostScript (Score:2)
Re:But it gets you compact code (Score:2)
Take a look at the hardware documentation for the 21264 pipeline or the architecture documentation for the IA-64 and think about how much fun it would be to write reams of hand-coded assembly for them.
If Moore's law slows down, I suspect that we'll see even more work on aggresive optimizing compilers and profile-driven optimization, not on trying to hand-optimize general-purpose code for 16-way issue multithreaded speculative out-of-order
First question (Score:5, Insightful)
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)
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.
Re:OSes in assembler used to be the common case (Score:2)
LLL vs HLL, Menuet vs World (Score:2, Insightful)
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.
Depends on your definition of "quality" (Score:2)
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.
Re:LLL vs HLL, Menuet vs World (Score:3, Interesting)
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)
Re:First question (Score:2, Insightful)
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.
Re:First question (Score:2, Funny)
A nice standard desktop?
Re:First question (Score:2)
Re:First question (Score:2)
1)
a=b+c;
2)
push ax
push bx
ld ax,sr+4
ld bx,sr+8
add ax,bx
mv sr+12,ax
pop ax
pop bx
I'll take the first.
Re:First question (Score:2, Insightful)
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.
Re:First question (Score:2)
"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.
Re:First question (Score:2)
Is it just me? (Score:5, Insightful)
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)
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.
Yes, you are not 100% correct. (Score:3, Insightful)
Saying that it simply won't work and therefore is easier to debug is foolish on a grand scale. If anything, writing in assembly code gives you FAR more failure modes because you don't have a compiler which is running at least some sanity checks on your code. If anything, you'll find that it is higher level languages that "won't work" and assembly code that will do something obscurely weird when you trash the wrong memory address.
If there is anyone humiliated, it should be the previous poster who obviously has no idea about the complexity added in writing something directly in assembly rather than a higher level language. All you end up doing is trading portability for increased development time. There is even no guarantee that the code will run faster - C compilers are pretty good these days and can do magical things with intrinsic functions with superscalar scheduling.
To sum it up, YES!! You are not 100% correct. You are actually 100% incorrect.
You put too much faith in your religion... (Score:2)
"EE"
Heh heh.
Re:You are not 100% correct either. (Score:3, Insightful)
Knowing what you are doing is actually most of the problem with assembly coding. Remembering where on the stack you threw things, figuring out calling conventions, string handling, collection classes and other icky stuff that if you have a decent C++ compiler with a nice STL library you are going to be far more efficient. I admit there are plenty of times I drop down from C++ into assembly for debugging of a program, but very rarely to actually write code (why isn't there a 'bitwise rotate' operation in C?).
To be honest, I find it easier to debug an ASM program.
How complex a program are we talking here? I'm used to working on projects that are in excess of 100,000 lines of C++ code. That easily translates to well over a million lines of assembly and probably closer to ten million once template expansion has taken place. I defy anyone to take a non-trivial program and say that the ASM code is easier to debug than the C code - of course using an IDE which allows you to view variables, stack traces, commented assembly and edit and resume the program on the fly helps a lot.
You write the code, you know what precisely what is going on.
I debate that of any programmer - especially in assembly. The limited syntax and complete lack of any high level data structures make it a nightmare in the end.
C compilers can (depending on the programmer) generate some really impressive, logical, clean code - but not usually something that can compete with an ASM programmer.
Ah, but the point is that fast assembly code is neither logical nor clean. You deliberately move loads up the instruction stack, precompute results that you may not use for many cycles, drop stores in (for zeroing memory) now and again when you have a pipe free and do it all differently depending on your target architecture (P5, P6, K7, P4 etc.) If you have a chance, look at the output of Intel's VTune compiler at some stange with all the optimizations turned on - you'll find the assembly unintelligible but faster than you thought possible.
Just curious - are you talking strictly x86 here or do you believe that this is valid across all CPU architectures? Have you any real plans to try to write faster code than a compiler can on IA64 - if so, I'd be interested on hearing your strategies.
Re:Yes, you are not 100% correct. (Score:2)
Re:Yes, you are not 100% correct. (Score:2)
Both MSVC7 and Intel's VTune are both very good compilers for x86. gcc has and probably will always be a dog. Sun, HP and IBM all make optimising compilers for their architectures as well.
The only dogma I see is the myth that humans coding in assembly are automatically going to know everything about the chips pipelines and register reservations.
As for "hundreds of dollars", don't make me laugh. Show me one software company that can't afford a few hundred dollars on a compiler that they could save on the chairs.
Re:Yes, you are not 100% correct. (Score:2)
I never said *I* had a couple of years experience, I said that the original poster should wait for a couple of years experience outside school (which makes it more than a degree).
Now if you'll take your head out of your butt, you may be actually able to write some sense instead of spouting unfounded derision.
Writing an OS in assembly is kinda "cool", but completely useless. In fact, why didn't he forget assembly and code it all in hex - that would be more than "cool". Personally I write code to get the job done as best I can for the client and writing in pure assembly is almost never the correct answer - especially not for an OS.
...and no, they don't call me Einstein. They use my real name. I'm sure they call you things too, but they aren't really worth repeating.
A step backwards... (Score:3, Interesting)
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.
Re:A step backwards... (Score:2)
How do you think your going to load a java interpreter to run the kernel? :) 25 meg "sun microsystems" MBR ?
Re:A step backwards... (Score:2)
java *is* an OS (Score:2)
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.
Re:java *is* an OS (Score:2)
Re:A step backwards... (Score:2)
Re:A step backwards... (Score:2)
Re:huh? (Score:2)
That's crazy. C absolutely can meet or exceed asm speeds, and high level languages often do the same. The problem is that it's nearly impossible to manage optimized assembly code, so there are some kinds of optimizations (ie, software pipelining) which can only realistically be done by a compiler. Even if speed was the primary concern (and this is rather dubious to begin with), it's not clear that asm would always win.
Then try this... (Score:2)
I've linked to the downloadable non-commercial-development version.
Smalltalk is very addictive once you start using it. I love the flexability that multiple polymorphism (selecting a method based on the name, and the types of all of the arguments, rather than on just the name, and maybe the first argument) offers, as well as the convience of being able to work on the same image from whatever platform (sun, windows, mac) that I happened to have access to.
As a quick response (Score:5, Insightful)
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?"
Re:As a quick response (Score:2)
Speed Up? How much (Score:3, Insightful)
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.
Re:Speed Up? How much (Score:2)
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
Where's the code? (Score:2)
Main Page... (Score:2)
Need to whore me some karma....
if it's in assembler... (Score:3, Funny)
but seriously, this is pretty sweet. i'm going to load it up at work tomorrow.
Can we move on to the next level please? (Score:2)
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]
Re:Can we move on to the next level please? (Score:2)
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.
Re:Can we move on to the next level please? (Score:2)
Systems basically appear randomly when someone's pet project becomes stable enough to appear on the
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.
Assembly? Hah! (Score:2, Funny)
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)
Guess that means he has to distribute the C version, too.
Re:Isn't assembly trivial to get from a binary any (Score:3, Informative)
My God......it's full of stars... (Score:2, Funny)
Thinking of uses for this... (Score:4, Interesting)
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
Re:Thinking of uses for this... (Score:2, Interesting)
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.
Re:Thinking of uses for this... (Score:2)
On asm vs "proper" programming (Score:5, Interesting)
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)
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.
Re:On asm vs "proper" programming (Score:5, Interesting)
I think the main point is that this is a *personal* achievement, not one for the computer community as a whole. Sure, there's no great need to do this, but man, if I had the time I'd love to try to do this, simply to see if I could. I wouldn't go down as the first anything, but the project would not be for fame or advancement of computing, but for personal advancement.
Re:On asm vs "proper" programming (Score:2)
As technology progresses we focus more on the higher levels of what is capable, versus the lower levels of survival training. Yes it's possible to live off the land, just as it's possible to write programs (even a whole OS) in asm.
Personally, I'll stick to visiting the supermarket for food, and C, perl, PHP, etc for programming.
Maybe for the embedded / handheld market? (Score:3, Insightful)
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
Dude, is it just me? (Score:2)
An OS from Finland? (Score:4, Funny)
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.
Don't Forget Steve... (Score:2, Insightful)
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...
Re:Don't Forget Steve... (Score:2)
Why not a translating assembler? (Score:2)
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 are thinking of C. (Score:2)
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?)
V2 Operating System (Score:2)
Does anyone know what V2 OS has become nowadays ?
One of many alternative operating systems (Score:2)
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).
installer mirrored here (Score:2)
http://www.geocities.com/placebic/2001-09-06-menu
Thats it (Score:2)
with one hand tied behind my back...
This is why we have C and UNIX (Score:2)
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.
All-assembly programing and other odd hobbies (Score:2)
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.
Re:Boy band? (Score:1)
But close enough.
:P
Re:it fits what? (Score:2)
Re:Hey, here is an idea! (Score:2)
Re:Yeah But (Score:2, Funny)
All I can say is, that's a pretty fucking hardcore patch. Even my keyboard is anti-aliased now.
Re:Yeah But (Score:2)
It's like MacOS X for the brain. No really, it's the same technology Steve Jobs depends on. [geocities.com]
Man, and you thought your terminal had a "visual bell." Yowzah.
Re:RC5 would haul ass (Score:2)
If you want your dnet client to run at its absolute possible fastest, you're best off doing away with the whole OS business in its entirety. A non-multitasking environment such as good ol' DOS would probably be best for that.