Slashdot Mirror
Europe Funds Secure Operating System Research
narramissic writes "A Dutch university has received a $3.3 million grant from the European Research Council to fund 5 more years of work on a Unix-type operating system, called Minix, that aims to be more reliable and secure than either Linux or Windows. The latest grant will enable the three researchers and two programmers on the project to further their research into a making Minix capable of fixing itself when a bug is detected, said Andrew S. Tanenbaum, a computer science professor at Vrije Universiteit. 'It irritates me to no end when software doesn't work,' Tanenbaum said. 'Having to reboot your computer is just a pain. The question is, can you make a system that actually works very well?'"
I thought Windows was secure. Why not use that? *cough* *cough*
The question is, can you make a system that actually works very well?
I'm glad someone finally got to asking this question.
.. they want their funding back.
Seriously , I thought minix had been put out to pasture years ago.
Also what are 5 people going to manage that entire corporations and thousands of OSS developers failed to do in the last few decades? Ok , one of them might be the next Alan Turing and surprise us all but I won't hold my breath.
said Andrew S. Tanenbaum, a computer science professor at Vrije Universiteit
It sounds intentionally misleading to present them as "a computer science professor" when he's the one MINIX guy.
You just got troll'd!
All respect to Andrew Tanenbaum, I'm not trying to troll. It's a sincere question.
He has said Minix was to be a teaching tool.
Now they want to turn it into a super reliable OS?
I don't think it's to make it into another production OS. Could it be in order to develop new OS concepts and ideas which can be spread out to the world?
I don't see this taking off to be honest. Minix was always a research toy. There is too much momentum in Linux. But what it might do is spur some ideas that get incorporated into the likes of Linux or BSD etc.
You could buy the whole documentation in X honking thick binders from www.heise.de - maybe you still can.
Andrew favors a modular approach to the kernel while Linus favors the integrated kernel.
Both have their merits ( and arguments )
Maybe something comes out of it!
He's the guy that argued with Torvalds back in 1992, right? The one who claimed that "Linux is obsolete" and Torvalds should "[b]e thankful you are not my student. You would not get a high grade for such a design." (link)
Therefore, I'm not inclined to listen to anything he has to say about kernels/operating systems.
OS X is as much a microkernel as Windows NT I.e. it isn't one.
Syllable : It's an Operating System
Actually, it's not such a bad idea. The concept of putting important components in user-space has been around for a while, and it still has potential w.r.t. reliability. But the real question is: are only microkernel architectures capable of self-healing?
cpghost at Cordula's Web.
Now that Minix 3 is here, Linus can take his monolithic kernel and stuff it! Microkernels are the wave of the future, man!
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
According to the professor, it should soon make Linux obsolete.
Phillip.
Property for sale in Nice, France
How many times is this old chestnut going to be tossed around?
MS tried a microkernel with NT and its HAL. It didn't really work very well. Most Unix varients don't even bother to try.
I think you are right at the moment. I am not sure that you will still be right when processors are 256-core or greater. I think that at some point the overhead of microkernals will be made up for by utilisation of greater parallelisation.
I'd recommend people take a look at the source code for Minix 3. It's actually pretty easy to wrap your head around, even for a C-phobic person like I am.
Classical Liberalism: All your base are belong to you.
The other is user security. And you cannot solve that problem with technology.
The circle you have to square here is that the user/admin should be allowed and able to run his software, but at the same time he must not run harmful software. Now, how do you plan to implement that? Either he can run arbitrary software, then you cannot identify security risks before it is too late. Or he cannot run software that is a potential security risk and he is no longer the master, owner and root of his own machine.
Oh, you want a system where the user can generally do his work but has to ask for special privileges when he wants to install new software or change security critical settings? Where have I heard 'bout that before... hmmm...
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
2009 will finally be the Year of the Minix Desktop!
This is what I thought when I read the post. It really smells as if the poster, narramissic, had not been around when microkernels and minix were fashionable. And neither was the person to allow for it to show on slashdot.
Let's call the minix discussion flogging a dead horse, until these chaps have come up with something real. If they manage to come up with something that is close to the beauty the idea of microkernels has on paper.
BeOS isn't a micro kernel either, and nor is Syllable. Both use message passing heavily in user space but that's a different beast.
Syllable : It's an Operating System
I remember submitting some patches to them many years ago when I got Minix working in less that one megabyte of RAM (at the time Minix worked at 1Mb and up) and thinking that it would be nice if it were GPL and if I had the time...
As I recall some guy in Finland did have the time
...is to call this news. The grant was received in November 2008! (see http://www.minix3.org/news/)
I though Minix was dead for some 15 years....
Did netcraft confirm it?
I was just thinking recently about Microsoft's Singularity research operating system written in C#, which is cute, but somewhat useless in the real world. One big advantage though of statically verifiable byte-code languages like C# in operating systems though is security, because you can ensure a block of code is secure once and then run it at full speed without further access checks. That's almost impossible with generic C or assembler, but tractable with bytecode-based languages like Java or C#.
While a *pure* C# operating system is a bit nuts, why not allow a *hybrid* operating system? Simply create a variant of the Java or C# runtime that can execute inside the Kernel at Ring 0, and only allow verifiably safe code to run. You get the benefit of a high level garbage collected language with all the safety checks that are normally enforced by the user-space/kernel-space seperation, but with none of the overheads.
This would have been impossible some years ago, because most operating system kernels weren't properly preemtible, and Windows on 32-bit had all sorts of pre-allocated buffer size limits, but all of that has been solved or has gone away with 64-bit.
I can't think of any reason this wouldn't work. Keep in mind that the typical device driver might be written by some minimum-wage code jokey in Taiwan or China who's got a "Kernel Programming for Dummies" book on his desk. I'd rather have him working in a language that can be verified safe, instead of a language that comes with a whole array of guns to shoot all of your feet off.
All I can see is some buzzwords and them waffling about microkernels - a 1970/80s concept if ever there was one which so far has proved less than impressive in the real world.
"The current version of MINIX 3 (3.1.2) is a work in progress. It is nowhere near as mature as FreeBSD or Linux right now." /better/ than this monolithic retires and with your definitions of "near" you'd better promote yourself for the oxford english dictionary editor.
Yau, Minix is not dead, micro kernels are
Given that one of the main reasons for microkernels is to seperate dodgy drivers from the kernel and hence improve stability - it doesn't say much for the implementation of amigaDOS if it kept crashing!
I have been trying to answer that question for more than 40 years, and I can say the answer is :: sometimes. The trouble is you need lots of money (i.e. man hours + very good kit + a very well defined problem + lots of testing), unfortunately experience shows that when you get all of that, the system is obsolete by the time you hand it over to the user. It's better to aim for good enough.
nec sorte nec fato
AmigaOS couldn't separate anything from anything because it didn't have memory protection, which it didn't have because the original hardware (Motorola 68000) didn't have it. Then once MMUs became available in newer CPUs (68030/040/060) the OS couldn't be changed because applications relied on it.
Syllable : It's an Operating System
Was Amiga really a fully-functional desktop? Did it have full Unicode support? In today's global world, support for many languages and scripts displayed simultaneously is vital, but multibyte does tend to add to the size of applications, meaning that a complete system on a floppy can no longer be considered realistic.
The aim is not to produce a better operating system, the aim is to secure funding. This is what academics actually do; good research is (at best) a byproduct. This is business as usual for a research group.
Not really. The purpose is doing the research you are interested in doing (even if it's just for your career ambitions). For that you need funding. So of course you have to do some marketing to sell the research you want to do to the people deciding whom to fund. You think this guy has been doing MINIX for 20 years just to get funding? It's the other way around, you get funding, to be independent and have people work for you so you can get some interesting stuff done. Or, if you are more cynical, he's working on MINIX because it generated enough interest that he could get a ton of publications out of it.
The real research will be a low priority, because the group will need to satisfy the EU bureaucracy that they are doing something worthwhile. Consequently, most of their time will be spent writing reports.
From my experience this is a bit of an exaggeration. It's true that EU-funded projects have more strings attached than those from many other funding sources, but running the burocracy/reports/financials for an EU project that is funding 3 full time people at our university still only takes a rather small percentage of my time.
And that's a lot more freedom to do real research than in any company environment i've seen or heard of so far. Big companies (even the good ones) have IMHO more bureaucracy, not less, and short-term horizon (want returns in 3, 5 years at the most), which means very little of what is called "research and development" has anything to do with research.
As a big windows fan boy I feel pretty lousy: THERE ARE ONLY 2 SUPPORTED GAMES: adventure and tic tac toe!
Ughh, don't you also think that at least 85% of the user base of a successful OS are minesweeper and solitaire overlords?
I think it's very interesting that if you go RTFA (yeah, I'm new here), you can read the related headline[1]:
"Desktop Linux: Why it may have lost its chance"
I think the dear AST is up to no good...
[1]: http://www.itworld.com/open-source/67022/desktop-linux-why-it-may-have-lost-its-chance
The real reason there is no security and that we have the monolithic vs micro kernel is that CPUs provide process isolation and not component isolation. Within a process, CPUs do not provide any sort of component isolation. If they did, then we would not have this discussion.
I once asked Tanenbaum (via email, he was kind enough to reply) why CPUs do not have in-process module isolation. He replied:
From: Andy Tanenbaum [ast@cs.vu.nl]
Sent: Ðáñáóêåõ, 1 Öåâñïõáñßïõ 2008 4:00 ìì
To:
Subject: Re: The debate monolithic vs micro kernels would not exist if CPUs
supported in-process modules.
I think redesigning CPUs is going to be a pretty tough sell.
Andy Tanenbaum
But why? I disagree with that for two reasons:
1) the flat address space need not be sacrificed. All that is required is a paging system extension that defines the component a page belongs to. The CPU can check inter-component access in the background. No change in the current software will be required. The only extra step would be to isolate components within a process, by setting the appropriate paging system extensions.
2) The extension will require minimal CPU space and CPU designers already have great experience in such designs (TLBs, etc). Money has been invested for less important problems (hardware sound, for example), so why not for in-process components? it will be very cheap, actually.
Of course, security is not only due to the lack of in-process component isolation, but it's a big step in the right direction...
It doesn't seem a lot to me...
A number of issues I can see:
- A bug in the VM could effect EVERY driver on the system
- Drivers generally need to respond to hardware interrupts and send out data to hardware in real time. Thats unlikely to
happen if its managed code.
- A VM/JIT system would only catch memory issues. It wouldn't catch out bad logic or instructions that make the
hardware go nutes and crash the machine anyway.
http://www.minix3.org/doc/screenies.html Screenshots
For the uninformed here (ie me) what's the advantage of microkernels on multi-core processors? Does this also apply to SMP generally? Or is there a better way to do MP with microkernels in particular?
"... and more and more now there are all kinds of electronic goodies available" -- Pink Floyd 1972
Unix support is a straw-man argument of yours. Back in the days, this was irrelevant. Everybody used his own code-page.
If you want to raise the bar, and expect Unicode (and full-color, and a browser, and multimedia, and whatnot), then you have to expect it to use more resources, to be on the same level as Aimga DOS again.
How about a CD? You can put a whole Linux desktop with everything you need, on a single CD.
Or use a 120 MB mini-CD, and limit yourself to the basics.
The both would absolutely have Unicode support, while having the same code-compactness.
Even a 2.88 MB floppy could do most of Unicode.
If you want *more* than what eg. Amiga DOS did fit onto one disk, you have to allow it to use *more* space too. :)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
The only thing that could make this story more entertaining is if that Roland Pepperfuqerqueue guy submitted it.
It's interesting to a good number of people here, especially those with six-figure or shorter UIDs, for historical reasons. Pity the summary doesn't mention those reasons AT ALL.
Minix came Before Linux (yes, there is such an era) and the Minix and Gnu communities encouraged one another in the same way that Linux and FOSS cross-fertilise now.
"... and more and more now there are all kinds of electronic goodies available" -- Pink Floyd 1972
I want the crap to work as expected first of all. Self healing comes at the very bottom of any list i have. Id much rather have good error handling and logging than self healing.
Self healing is something i hate since it makes software behave inherently unpredictable, even more so than an average Windows box of /etc/random
HTTP/1.1 400
I think the dear AST is up to no good...
Don't blame IT World's linking of the Minix article with a one that gets your fanboy hackles up on Tannenbaum - it makes you look like an idiot.
basically a microkernel architecture splits subsystems such as file systems, device drivers and security out of the kernel and into separate modules. This leads to an overhead of context switching to different processes on a single processor. A user process requesting access to a file may need a context switch to the kernel, another to security, another to the filesystem and then another to the disk device driver. With multiple processors this overhead can be removed.
I dunno - will it really improve things if the FS driver has to talk to the disk driver on a different CPU? Sure, the kernel could maybe be smarter than that, but... I dunno. Either you use all those cores and take a hit on interprocess communication, or you don't use all the cores and waste some of that power.
Besides, is there any reason a macrokernel couldn't be threaded? I thought they already were.
There's an old saying that says pretty much whatever you want it to.
Too bad that as usual slashdotters talk first. Commercially available microkernel os - www.qnx.com.
This is the best OS I've programmed for. Drivers and network stacks in user space. Develop and debug just like your user-space apps. your driver crashes? No BSOD, no kernel panic, just restart it, it's a user mode process.
No monolithic kernel, no global kernel address space for thousands of people's drivers and modules to screw each other over.
It would be a dream come true if OSS developers would support Minix instead of Linux. Then we'd have a secure robust foundation for OSS software.
Doubt it will happen as most are too short-sighted and quick to spread FUD and deride things that they don't understand (just read the replies on this thread). Turns out they're just as bigoted as MS fanboys or Mac fanboys.
Too bad Linus didn't listen to his professor.
Tannenbaum designed Minix 1 and 2 in his academic and turorial work together with students.
Many students gained by his lectures - including Linus Torvalds. So what?
Giving 3 Million Euro to a University Institute is not so bad.
I do more question the BSD style license.
I would have preferred some pay-back mechanism from commercial users - not excluding them for their interest to keep own development based on it undisclosed.
I had some problems with some OSs that believed they were smarter than the user (me) (a brand that looks like a fruit comes to mind). It was difficult to convince it to do exactly what you were asking. If a system is that "smart", I think a part of its flexibility may be at risk...
(I'm not saying that *any* OS I currently use can do exactly what I had in mind, all the time ;)
As they mention in the summary, there's this button I can push, wait 30 seconds, and then the computer is fixed. There sure is a lot of work left in eliminating that 30 second wait for the fix!
stuff |
That comment totally 'addresses' the defects in current CPU design and begs the question as to why fixing these defects were never a priority.
Linux was dependent on the MINIX user space at first. With code from the GNU system freely available, it was advantageous if this could be used with the fledgling OS.
So using the slash notation, it was Minix/Linux before it was GNU/Linux.
The problem is that OS is just a part of the software system. You can't have a 100% reliable and secure system, if all codeb being executed contains millions or billions of lines. At least until we can remove the human factor.
If the software tries to do something outside of its specified protocol, then zappo, it's gone.
Bitfrost on OLPC's XO laptop tries to do something similar with a typical kernel/app separation: apps (called "activities") can specify their "protocol" as a set of privileges, and some privileges (such as scanning directories and connecting to a network) are deemed mutually exclusive unless the user grants them after the installer finishes.
Either he can run arbitrary software, then you cannot identify security risks before it is too late. Or he cannot run software that is a potential security risk and he is no longer the master, owner and root of his own machine.
Or you can implement finer grained permissions for applications. For example, does a program that views all photos in a home directory need the ability to upload photos? If not, then a program doesn't need privileges to call opendir() and socket().
Oh, you want a system where the user can generally do his work but has to ask for special privileges when he wants to install new software or change security critical settings? Where have I heard 'bout that before...
Are you thinking of Windows UAC, or possibly sudo make me a sandwich?
hmmm...
HMMM?
Andy said at LCA2007 it was a 30% hit, I don't see a 30% performance hit being 'slightly' slower.
It depends where you're measuring 30% performance hit to each system call? 30% performance hit to all floating point math? 30% performance hit under some specific normal workload? All very different. In some places, 30% is a big deal, but in others it's negligible.
There were programs like Enforcer that added 3rd-party MMU. The lack of changes to support MMU in AmigaOS itself was due to management not wanting to do it.
MS tried a microkernel with NT and its HAL.
Not really. A microkernel manages processes. The HAL only manages hardware resources. For the same reason, OSX is not really a Microkernel OS either.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I've been thinking a bit, and if you had HyperThreading in all processores, couldn't you simply assign the kernel to one instance of a core and the userspace to the other? You'd have context switches for free. Your only cost would be the pure IPC, not the context change. In fact, with some design like sending only pointers to whole pages and then remapping them to the new process, you wouldn't have to even copy memory in bulk transfers.
Why not fund Coyotos ( http://www.coyotos.org/ ) or even CapROS ( http://www.capros.org/ ) instead of reinventing the wheel?
Funding is really what those projects are in need of. They already have working concepts.
{{.sig}}
Your suggestion sounds strikingly similar to capabilities, which were implemented in a number of machines in the 1970s, e.g. Cambridge CAP.
Maybe I'm just a bit nostalgic but why isn't it mentioned that a early version of Minix* inspired Linux*?
Because, judging by the phrasing of the summary, the contributor had never heard of Minix before. Which must be some kind of sign about how far from our roots we've grown.
I think the suggestion is more like this, and would require a new CPU design, but not as radical a change as making it run some interpreter:
To address memory you have a "pointer" and an "offset" always. The CPU instruction set is designed so that all memory accesses must provide both of these. The "pointer" identifies the page of VM and an attribute of the page is that the offset cannot exceed some value, otherwise an access violation happens (the offset can't be negative either).
Moderm memory allocation involves putting objects of the same size into the same page, so this could protect many objects, not just one per page. It's probably true that object sizes would round up to the next power of 2 and protection would only happen if you addressed beyond the unused padding area, but it would provide the security problems.
The big sticking point is C. Making it compile so that a different pointer is always used and offset=0 would be compatible, but would defeat all the protection. Instead pointers could be implemented as pointer+offset pairs, with some complexity in the compiler and the annoying fact that some software is going to not work.
``'It irritates me to no end when software doesn't work,' Tanenbaum said. 'Having to reboot your computer is just a pain. The question is, can you make a system that actually works very well?'"''
You can. And it has been done. Software that doesn't work? Having to reboot your computer? This hasn't been bugging me for ages. Yet, Andy refuses to use the software I am using for some reason. Instead, he is trying to develop his own, but making it difficult for people to contribute. I like what I have heard about the plans for MINIX 3, but, this way, it's just not going to fly.
I congratulate the MINIX 3 team on what they have achieved, and I congrulate Andy and the rest on having secured funding, but I can't help but think that if they just cooperated with the great projects already out there, they could have achieved much more with much less funding.
Seriously. If you want something good today, use GNU or any of the BSDs. Or maybe a commercial Unix, or even OS X. And my guess is, if you want something good next year, the answer will be the same. Maybe even Windows will be a great choice by then. But MINIX? I'm not counting on it, grant or no grant.
Please correct me if I got my facts wrong.
Wrong. Do you even know what a microkernel is?
Besides, is there any reason a macrokernel couldn't be threaded? I thought they already were.
They are: things like kthreadd, migration/0, ksoftirqd, watchdog/0, events/0, khelper, kstop/0, kintegrityd/0, kblockd/0, kacpid, etc. you can see in the process list in Linux are all kernel threads.
Those who would give up liberty to obtain working drivers, deserve neither liberty nor working drivers.
You don't need a JIT compiler or an interpreted language to have a secure kernel - you just need a well-designed, type-safe language (which C is not).
Yup. But the "perfect" well-designed, type-safe, provabily non buggy language used by some researchers happens not to be compiled - unlike the Haskell example you cite.
Microsoft's Singularity is such an example, written in a type-safe functional language designed to be provably bug-free. .NET infrastructure.
But their language runs only on a variation of the
(And this being Microsoft, by the time the projects leaves the lab (if it ever leaves the lab one day) you can count on them completely botching the concept - like having a whole copy of WinXP running parallel to the microkernel for "backward compatibility")
Nonetheless, putting a VM in the kernel (either as a JIT, or as a full interpreter) has the advantage that although the various kernel servers of the micro kernel system are designed as separate processes (from the language running in the VM's point of view), the VM itself could run in a single hardware process thus minimizing the cost of context switching and message passing compared to a system where each kernel server runs in a different hardware context.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Not a totally new idea. As far back as 1964, IBM had protection keys in the System/360 mainframes, although with a much coarser definition of components than what you have in mind.
Quis metamoderunt ipses metamoderatores?
Actually, you don't need independent page tables per component. All that you want is a new word in the page table descriptors that includes:
1) the component id.
2) read/write/execute bits for the other components.
Then when component A tries to write or execute something in memory of component B, the CPU will check the access rights of the target page. If the access is not allowed, then an exception will be raised.
That's a trivial job for the CPU with zero overhead, as the CPU already checks the supervisor/user bit on any memory access.
A 32-bit word has 3 bits for the access writes (2 bits if a read bit is not required) and 29 bits for the component id. So the page descriptors need to fit in 64 bits instead of 32 bits (in the 80x86 CPUs).
If you don't want an extra 32-bits for a page descriptor, then the 80x86 page descriptor has 11 bits free (20 bits are reserved for the page frame and 1 bit for the valid/non valid page). With 2 bits for access writes (write/execute), you have 9 bits for the component id, i.e. you can have 2^9 = 512 different components in a process.
I am talking about a different thing here, i.e. isolation within a process address space, which provides the security of process isolation but not the relevant overhead.
The kernel defines the page table and therefore the components.
You can't jump in the middle of the other component, unless the component defines that area as public.
If you want to ensure that no jump in the middle of a subroutine is allowed, then have a jump target instruction. If the first instruction after a jump is not a jump target instruction, then throw an exception.
Arbitrary function pointers will work because the compiler will insert the jump target instruction at the appropriate places.
The stack is not a problem, unless components put critical data in it. Components today don't do that, so I don't see why they have to do it in the future. Even in microkernel architectures, a component does not put its critical data in areas shared by other processes.
If you find any more problems, please share them with us. I am interested to hear them.
The simple reason why these funds are going to a research group in an EU member state is that they come out of the EU budget. It is not the job of the European Union to make up for the research funding deficiencies of the United States of America. On the contrary, one of the goals of EU research funding is for the EU to not be dependent on non-EU countries for technology or at least to be strong enough to be an equal partner in collaborative ventures.
As for reinventing the wheel, these funds are going to an academic research group to do research on problems that have not yet been solved.
It is not only normal for other research groups to explore other approaches to solving the problems or to explore other problems in the same overall area, it is essential for progress that there are different groups looking at different ideas. Even if EU funding could go to a US research group it would not be sensible to channel all operating system research funding to the same group.
Do you pine for the nice days of minix-1.1, when men were men and wrote :-)
their own device drivers? Are you without a nice project and just dying
to cut your teeth on a OS you can try to modify for your needs? Are you
finding it frustrating when everything works on Linux? No more all-
nighters to get a nifty program working? Then this post might be just
for you
As I mentioned a month(?) ago, I'm working on a free version of a
Linux-lookalike for AT-386 computers. It has finally reached the stage
where it's even usable (though may not be depending on what you want),
and I am willing to put out the sources for wider distribution. It is
just version 0.02 (+1 (very small) patch already), but I've successfully
run bash/gcc/gnu-make/gnu-sed/compress etc under it.
Sources for this pet project of mine can be found at nic.funet.fi /pub/OS/minix. The directory also :-). Full kernel /pub/gnu.
(128.214.6.100) in the directory
contains some README-file and a couple of binaries to work under Minix
(bash, update and gcc, what more can you ask for
source is provided, as no Linux code has been used. Library sources are
only partially free, so that cannot be distributed currently. The
system is able to compile "as-is" and has been known to work. Heh.
Sources to the binaries (bash and gcc) can be found at the same place in
ALERT! WARNING! NOTE! These sources still need Linux-386 to be compiled
(and gcc-1.40, possibly 1.37.1, haven't tested), and you need Linux to
set it up if you want to run it, so it is not yet a standalone system
for those of you without Linux. I'm working on it. You also need to be
something of a hacker to set it up (?), so for those hoping for an
alternative to Linux-386, please ignore me. It is currently meant for
hackers interested in operating systems and 386's with access to Linux.
The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If
you are still interested, please ftp the README/RELNOTES, and/or mail me
for additional info.
I can (well, almost) hear you asking yourselves "why?". Hurd will be
out in a year (or two, or next month, who knows), and I've already got
Linux. This is a program for hackers by a hacker. I've enjouyed doing
it, and somebody might enjoy looking at it and even modifying it for
their own needs. It is still small enough to understand, use and
modify, and I'm looking forward to any comments you might have.
I'm also interested in hearing from anybody who has written any of the
utilities/library functions for Linux. If your efforts are freely
distributable (under copyright or even public domain), I'd like to hear
from you, so I can add them to the system. I'm using Earl Chews estdio
right now (thanks for a nice and working system Earl), and similar works
will be very wellcome. Your (C)'s will of course be left intact. Drop me
a line if you are willing to let me use your code.
Andrew
PS. to PHIL NELSON! I'm unable to get through to you, and keep getting
"forward error - strawberry unknown domain" or something.
"The latest grant will enable the three researchers and two programmers on the project to further their research into a making Minix capable of fixing itself when a bug is detected" 1) Minix?! That was a research project that was dead and buried long ago. 2) Minix?! Why reinvent the wheel? 3) "capable of fixing itself"? You mean capable of being mis-configured by an incompetent admin or capable of being tricked into auto-rooting itself. Awesome.