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.
There's just one thing missing from the site - the actual Minix from scratch instructions.
Lacking the instructions, this still looks cool and something I'll try in my spare time. Based on the relative differences, this looks a lot more doable timewise than Linux fron Scratch, just based on the relative difference in sizes between the two.
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.
Question: is the current MINIX licence GPL-compatible? I've given it a scan and it seems pretty liberal. Is it possible or feasible for code to be taken from linux (or vice versa) within the remit of these licences?
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.
No I think this is worth while.
/respondents to this post/ and you being me. Just hate calling myself dumb :)
Minix is a diffrent operating system with a diffrent focus. I can easly see Minix being used more effectively in the imbeded market where Linux is today.
Also I doupt the people who will be pulled into Minix from scratch would otherwise go to Hurd.
Also (correct me if I'm wrong)[1] but isn't Hurd incomplete? Making a Hurd from scratch might be a bit difficult at this stage.
[1] I know you will but it just feels better to say it. You know. To make it so people think twice before beliving me. It's good to know your dumb and admit it. It's not good to be dumb of course but if you are and know it admit it. People will soon cure you. People being
I don't actually exist.
We'll have a contest to see how many _single_ developers can design, code and finish
an operating system similar to Minix(conceptually) with some standards compliance(i.e.POSIX.)
We'll select a bunch of the most critical subsystems and define those as a Base and give extra
points for the following:
- using a language that's not generally used for OS design,
- designing and coding for portability(more platforms=more points)
- smallest code base
- best documentation
- time to complete, less time=more points
- fastest(benchmarkers paradise here we come...)
- POSIX compliance, more compliant=more points
- massive extra points for running windows software ;-)
- 'clean', no borrowed code = +100 points
and i'm sure there are other categories.
So for example, person A get 100 points for base compliance, 25 points for using a language
not generally used for OS design(Visual Basic?) another 25 points for best documentation.
His total score would be 150.
Person B submits a Base+ OS:
base compliance = 100
written in Forth = 25
highly portable = 25
time to complete, 6months, 23 days, = 25 points
best documentation = 25 points total score, 200 points
Ultimately, the point is how many POSIX-subset compliant OS's written by ONE programmer/analyst
can we get and how long will it take?
Say we get about twenty-five(25) base-implementations submitted by six months, three(3)
decent base+ implementations in 9-10 months and one(1) truly great implementation in 13 months;
We can then say that Ken Brown and company really, really don't have a clue about software
development, and OSs in particular.
"...that's as white as it gets; all the bits are on..."
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
L4 is BSD licensed.
.sig.
As for GNU/Hurd running on gnumach, it's quite usable, and relatively stable nowadays. If you really stress it, it will die on you. For me, the filesystem translators seem to be the most unstable. I've never been able to get libc to compile on a local partition (it worked *once* over NFS). Playing around with some of the features you don't find in a typical monolithic unix are neat. User-mounted NFS in your home, ftp sites as part of the filesystem, setting a translator to output fortune to your
X is kind of iffy. It normally works if you install from one of the preview CD's. It's dog slow, however, and I've had problems with the mouse translator dying.
But for a machine just to hack a bit, IRC, read mail with mutt...it works fine. Good for something like a P-200.
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.