Slashdot Mirror
Minix from Scratch Project Established
decuser writes "The MFS - Minix from Scratch project was established in the wake of the Brown-Tannenbaum controversy. MFS aims to be to the Minix community what LFS is to the Linux community, a recipe for building an alternative OS from 'scratch.'" See the project's website at mfs.sunsite.dk or minixfromscratch.org.
The problem was that it cost money :P I always wanted to mess around the code on a simple, yet an operating system you could DO something with.
Don't say "Linux!". Have you SEEN how many lines of code that is? I just a lowly hobbyist.
Back in 1992 or 1993, a unix admin suggested that I check out a PC unix called "minix." Back then, "googling" consisted of connecting a ftp clinet to ftp.wustl.edu and manually traversing the directory structure looking for something interesting. I don't remember if it was at ftp.wustl.edu or sunsite.unc.edu, or even on usenet, but I eventually stumbled across this PC unix called "linux." It sounded right, so I went with it.
Months later, I spoke to the admin again, and found that I was mistaken. Rather than type in thousands of lines of code for an 8086 unix kernel, I had a fully functional linux workstation with X11, ethernet and all the rest of the good stuff that we take for granted today but were PC fantasies in the Windows 3.0 days.
Improving minix's feature set could potentially make it a tool for teaching other OS concepts; You could have one class where you use minix, and another where you use SMP minix, or what have you.
It's still a pretty useful OS for a 286.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Linus took Minix and evolved it to a state where Linux is today.
No. Linus used Minix as the OS for his computer, and used it to run his text editor and compiler and so on to build Linux.
No doubt he read the Minix book. But he didn't "evolve" Minix -- he did something else, on his own.
Then legions of coders around the world used the Internet to contribute improvements to Linux, and Linus managed the whole project. He has really shined as a manager and as a system architect, even more than as a coder.
if as many man-hours were spent improving Minix as were spent improving Linux, who is to say which would be the best today.
I have always heard that microkernel is supposed to make things better. The system is easier to get right, easier to debug. Sure it runs a bit slower with the overhead, but it will be rock solid stable and secure.
What makes me wonder about all this good PR is that the Hurd existed as a project before Linux, and it's still alpha code. Why? And why is the Hurd only available for 32-bit x86? Is the hype surrounding microkernel false, or was there some other factor that has slowed down the Hurd despite its microkernel superiority? (And if so, what is that other factor -- human factors among the the Hurd development leads perhaps?)
Note that I am not implying anything with these questions; they are honest questions from someone who doesn't know, and wonders.
I say support the MFS project, diversity is better than stagnation.
If by "support" you mean "don't spend any time criticising and complaining", I'm right there with you. I'll even go so far as to say "Minix from Scratch guys: good luck, have fun!" But I'm not going to spend any of my own time working on this project.
And I do wonder why they chose to work on Minix instead of the Hurd.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Did run Hurd for a few days. It's very rough. Not even as good as Linux 0.9x. Hurd Mach kernel is too old. Really showing its age. Can't do SMP, no hope there either. The Hurd kernel needs to be replaced with something like L4. Hurd deveopment moves at glacial pace. There is some sort of attempt to bring Hurd to L4 but I think it is not going anywhere.
Honestly, I don't see any progress with Hurd. It would have been cool 10 years ago, but other projects have left it in the dust. One thing, Hurd does support ESR's "Cathederal and Bazaar" thesis. The secretive, closed development cabal which surrounded Hurd for so many years is what probably hurt it the most, inducing bit rot and scaring off new recruits.
He had a good experience with it, but it didn't do some things he needed. Also, he wanted to learn 386 assembler.
This could potentially be rectified by building a "File System Manager" and "Device Manager" that support the Linux device and file system models. Then, all Linux device drivers and file systems etc could be plugged into Hurd and used with little/no modification.
The benefit of an exercise like this is that it would push Hurd into "useful" space so that it would become worth putting effort into, and there would then be a microkernel OS with a rich set of code.
For all Linus' comments about "computer science masturbation", there is still a place for microkernels and they can be pretty damn efficient. Having a solid microkernel OS in OpenSource land is of significant value.
Engineering is the art of compromise.
When I left Microsoft it wasn't pre-emptive or very useful. WTF would I want to look at the code, or play with DOS for?
;-]
In my operating systems class I was learning how to implement stuff that Windows wouldn't have for another three years (yes, I implemented pre-emptive multi-tasking in '92 on x86 hardware, and it wasn't bloody well rocket science).
Hell, I was reading Tanenbaum for my Operating Systems course. I used his definitions for a bunch of system calls to implement a UNIX layer in another OS. (Uh oh, now SCO will sue me and my professor. =)
Quite frankly I think implementing Minix from scratch is a hell of a lot more interesting than anything DOS ever did. [ And I have the course notes to prove it
Now, don't get me wrong, BBS Sysop has street cred in my book, but DOS isn't exactly what I'd call a sophisticated system to want to play with that much as compared to a real multi-tasking OS, which Minix most definitely was.
Lost at C:>. Found at C.
If fact, back in 1991 I was toying around with both Minix and Linux. Minix was pretty cool but it did cost money and it was pretty basic in what it could do. It was pretty much text only. Linux, on the otherhand was something of a baby huey, born on the gigantic side. I remember ftp'ing disk images for days on my 2400 baud modem and then creating a humongous pile of disks.
Minix, on the other hand, was like 2 disks AFAIK, but it wasn't nearly as groovy as Linux was with all that GNU software that was immediately ported over to run on it. I even struggled to get X running on my Debian 0.9 system but never pulled it off with my EGA card that weighed about ten pounds and was covered with hundreds of chips. A VGA card and monitor cost a king's ransom back in those days was way out of my price range.
But compared to MS-DOS and DesqView, which I used to run my old BBS system on back then, Linux was pretty darned cool! You could put a getty on your comport and it kind of was a bbs already, and you could actually do meaningfull things with your computer while it ran the bbs since it had virtual consoles and awesome multitasking even back then, whereas with DesqView you sort of had a poorly performing kind of multitasking system that barely ran anything usefull without taking up so many cycles that nothing really worked well at all. I don't think that Minix was able to do anything like this back then, but then I only really messed around with it for a couple of days.
Clickety Click
In my operating systems class I was learning how to implement stuff that Windows wouldn't have for another three years (yes, I implemented pre-emptive multi-tasking in '92 on x86 hardware, and it wasn't bloody well rocket science).
I MER_INTERRUPT, scheduler); /* idle */
Heartsurgery is easy: All you need is a blunt knife. Doing something useful like saving someones life by laying a bypass is not.
Implementing preemptive Multitasking is easy. All you need is a loudmouthed CS student. Doing something useful with it like making a formerly cooperatively multitasking OS preemptive is not. (just think of all the device drivers, filesystem, network code that need to be changed).
It is not a matter of:
#define S_WAITING 1
#define S_READY 2
#define MAXPROC 4
struct task {
int state;
unsigned char cpustate[SCPUSTATE];
}
struct task tasktable[MAXPROC];
int currentproc = 0;
disable_interrupts();
set_interrupt_vector(T
program_timer();
init_task(0, NULL);
init_task(1, task1);
init_task(2, task2);
enable_interrupts();
while(1) {
serout ("Idle hands read slashdot");
}
find_eligible_task() {
while(currentproc < maxproc && tasktable[currentproc].state != S_READY)
currentproc++;
if (currentproc == maxprc)
currentproc = 0;
}
scheduler() {
save_current_cpustate(tasktable);
find_eligible_task();
restore_cpustate[currentproc];
}
task1() {
while (1)
serout ("He mom! Check it out! I did this!\n");
}
task2() {
while(1)
serout ("You mean I can't use the UART when you are using it?\n");
}
There. Preemptive multitasking more or less. Build your own toy operating system around it. Filling in the assembly code for stuff like
dis/enable_interrupts, init_task, save/restore cpu_state etc. I will leave it to the inclined CS student to do that.