Slashdot Mirror
Domain: tu-dresden.de
Stories and comments across the archive that link to tu-dresden.de.
Comments · 171
-
Re:Will they have to change the name?
Here here!
No doubt a good microkernel is a nontrivial thing to write but it can be done, has been done and as far as I can tell Mach isn't it
Even Mac OS X seem to have some fairly major latency issues and it isn't even a micorkernel [though it does have Mach inside]. I think mach tries to do too many things and has too many of its own system calls to be easily done well.
L4 compliant microkernels [L4 is a spec and there are implementations of that spec... like Fiasco,/A>] conentrate on doing only a few things very well.
If indeed the port of the Hurd servers ever happens to go to L4... I will be sure to try it out but as it stands now GNU/Hurd seems to have the same basic problems it did back 1998 when I last dared to run it. -
Re:Running NT and BIND?
You should really take a look at recent proof efforts before mouthing off like this.
If I may point you to two examples:
Another point (and this is an important one): personal experiences don't generalise
- -Shane
-
Re:Nothing wrong with logging in principleBy logging usage, the order specifically refers to storing URL's of visited web sites. Depending on the naming/directory structure of individual sites, it is possible to have a good guess at what you may be up to (e.g. guess what I am looking at with http://www.euro.dell.com/countries/uk/enu/dhs/pro
d ucts/model_inspn_inspn_8200.htm). With many search engines, the search terms themselves are included with the returned URL (e.g. http://www.google.com/search?q=slashdot&sourceid=o pera&num=0&ie=utf-8&oe=utf-8).As such, this sort of logging will give a good idea of your activities online and when you consider that the UK government has not only leaked copious amounts of personal data in the past (it was possible to buy the name and address for any given National Insurance number for just £10 at one point) but that all this information is now held and maintained by EDS.
There is a solution to this - use software that encrypts your web traffic and URLs and routes them via a proxy server outside the UK. One I have used and can recommend (outside of peak times) is the Java Anonymising Proxy described here. Currently free...
-
JAP
Try JAP, it's a Java proxy program that you run on your system, which connects to a network of anonymizer servers. It is a breeze to setup and use, even your grandmother could use it. It is also more secure than many other systems, because it makes use of a network of anonymizing servers in a way that if one server owner went evil and decided to log your traffic, he couldn't. One would need to have control of all the nodes of the anonymizing network in order to successfully track you, which is much more difficult and unlikely. BTW, the project is sponsored by the German government (!) and FREE (for the moment at least).
-
Anonymous proxiesAnonymizer works ok as long as you are not trying to hide from the government. Use SSH to tunnel your traffic to anonymizer proxy and you are safe from your ISP monitoring and the site you are going to knowing where you are coming from. Go get a bunch of kiddie porn or terrorist stuff and Anonymizer will have to give you up when the FBI comes knocking on their door.
Someone already mentioned multiproxy. Also check out Java Anonymous Proxy and Peekabooty. You seem kind of new to the game of paranoia. Why not just start here and do some reading.
It's important to understand exactly what these anonymous services get you and who and what they are protecting against so take some time and realistically educate yourself to the risks and threats.
Oh, and don't forget to check out Freenet
-
Re:What about exokernels?
The main purported advantage to microkernels are stability and flexibility, along with all the other good stuff that comes from modularity of course. A microkernel can run different personalities which present what we generally think of as a kernel interface to the outside, as user processors. So for instance the same box, the same microkernel, could be running a Windows personality for one user, a Mac for another, *nix for a third, all with effective root priveliges if need be, but without actually being able to do any damage outside their virtual sandbox... from a developers standpoint it's an incredible potential, I really can't do it justice but you should read this.
The potential here has never been exploited, unfortunately. Every existing microkernel AFAIK has wound up ditching the microkernel design at some point down the road, aiming to produce a particular personality (whether win32, the near-BSD personality of Darwin, etc.) and integrating key features of that personality into kernel space for performance reasons, essentially nullifying the whole microkernel idea. The HURD is the exception, and yes it's been a long time making, and it's still not ready yet, but if it ever does hit primetime it will be a very interesting system.
As to the performance hits, you're right that they are there, however there is a long history of some very smart people working on that problem, and it's gotten a LOT better. I think the current performance winner among microkernels is L4 and you can run a Linux personality on it without seeing a noticeable performance loss over running real Linux on the same processor - that's some very nice optimisation. There has been talk of porting the HURD to run on L4 instead of GNU Mach at some point, I think actually some people working on the problem areas, but for the moment there is no need - HURD is still very much in the developers only phase, it's not for production systems yet so performance isn't critical.
-
First flywheel bus
In Yverdon, Switzerland, a bus which stored electric energy by a flywheel and recharged at every stop, the recharging took about 30 to 40 seconds. It entered regular line service in Yverdon's public transportation system in 1953.
There's an article about the past, present and future of flywheel systems at the University of Dresden. (Language: German). -
Government-subsidized anonymizer
Use JAP (translation), a German government-subsidized still-free Internet Anonymizer service. It makes it virtually impossible to track you.
-
Re:VA Software
i think it's because of this
-
RISC != fewer instructions (despite acronym)How many times do we need to go through this crap? Despite the reputed meaning of the acronym, RISC doesn't have anything to do with the number of instructions!
gelfling wrote
Clearly this is no longer a RISC design because the original PPC instruction set had what, 174 instructions? So add 160 more and you have 334.
and, earlier, autopr0n wrote
Yet Mac zealots will still be going on and on about how PPC is better because "Its RISC!". Never mind that the 486 only had 142 instructions total or anything like that.
RISC is about reduced complexity and designing architectures for best use by optimizing compilers.
If anyone actually wants to learn something (rather than simply spouting ignorant marketing propaganda) you can check out John Mashey's periodic RISC vs. CISC article from the comp.arch newsgroup.
The essence of the RISC philosophy can be summed up in this quote from Hennessey & Patterson: "Make the common case fast and rare case correct." The question is, however, how do we know what is the common case? The answer from H&P is to look at the occurrance of various instructions in actual programs. Since most programs are generated by compilers, this amounts to looking at what is used most commonly by compiler code generation engines.
Once you have made an inventory of instruction usage, what you find is that lots of time and instructions are spent moving data between registers and memory because you don't have enough registers, and over 80% of the addressing is done with only a couple of addressing modes. In other words, compilers are simply no good at making use of most complicated instructions common in most pre-RISC architectures (including the 80x86).
When you design an architecture that caters to the kind of usage a compiler likes, you come up with an architecture that has lots of registers and performs all arithmetic operations on values in the registers, only accessing memory with simple load and store instructions supporting a few simple addressing modes (absolute address, register direct, and, possibly, register direct with immediate index). Along the way, in order to make various CPU bookkeepping tasks as simple as possible, you will use a fixed length instruction word with only a few instruction formats, and ensure than any single instruction can only cause one fault condition (memory access fault, instruction operand fault, etc.)
This general description is a pretty good match for almost all, so-called, RISC architectures: MIPS, M88000, ROMP, POWER, PowerPC, PA-RISC, Alpha, AMD29000, Sparc, ARM, Clipper, etc. The fact that all of these architectures share so many common features says something profound about the descriptive power of the term 'RISC' which cannot, easily, be said of the converse term, 'CISC'.
Just to head off the other popular mis-conception concerning RISC vs. CISC: RISC has nothing to do with the implementation features of a given processor, only with the programmer visible architectural features (number of registers, instructions, instruction encoding, etc.). Hence, no matter what name Intel or AMD use to describe the current dynamic micro-coding scheme used to salvage another generation of bloated, power guzzling, 8-bit microcontroller follow-ons, the 80x86 will never be considered a RISC processor.
-
Re:OT: IBM SawMill project
The L4 microkernel puts the Linux kernel to shame. There is a distro called Debian Hurd. Hurd is a set of servers that runs on Mach but is slowly being ported over to L4. The home page for the L4 Hurd port is here. There is also an L4Linux project that runs Linux as an app in user space over top of L4, more info on that is here
-
mirrors
Australia
ftp://ftp.planetmirror.com/pub/Mandrake/8.2/i586/ (Brisbane)
Austria
ftp://ftp.univie.ac.at/systems/linux/Mandrake/8.2
/ i586/ (Vienna)ftp://gd.tuwien.ac.at/pub/linux/Mandrake/8.2/i586
/ (Vienna)
Belgium
ftp://ftp.belnet.be/packages/mandrake/8.2/i586/
Costa Rica
ftp://ftp.ucr.ac.cr/pub/Unix/linux/mandrake/Mandr
a ke/8.2/i586/
Czech Republic
ftp://ftp.cesnet.cz/OS/Linux/Mandrake/mandrake/8.
2 ftp://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)
ftp://klobouk.fsv.cvut.cz/pub/linux-mandrake/Mand
r ake/8.2/i586/ (Prague)ftp://mandrake.redbox.cz/Mandrake/8.2/i586/
ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Mandrake/
m andrake/8.2/i586/ (Prague)http://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586
/ (Brno)
Denmark
ftp://ftp.dkuug.dk/pub/mandrake/8.2/i586/ (Koebenhavn)
ftp://ftp.sunsite.dk/mirrors/mandrake/8.2/i586/ (Aalborg)
Estonia
ftp://ftp.aso.ee/pub/os/Linux/distributions/mandr
a ke/8.2/i586/
Finland
ftp://ftp.song.fi/pub/linux/Mandrake/8.2/i586/ (Espoo)
France
ftp://ftp.ciril.fr/pub/linux/mandrake/8.2/i586/ (Nancy)
ftp://ftp.club-internet.fr/pub/unix/linux/distrib
u tions/Mandrake/8.2/i586/ (Paris)ftp://ftp.info.univ-angers.fr/pub/linux/distribut
i ons/mandrake/8.2/i586/ (Angers)ftp://ftp.lip6.fr/pub/linux/distributions/mandrak
e ftp://ftp.proxad.net/pub/Distributions_Linux/Mand
r ake/8.2/i586/ (Paris)ftp://ftp.u-strasbg.fr/pub/linux/distributions/ma
n drake/8.2/i586/ (Strasbourg)ftp://linux.ups-tlse.fr/Mandrake/8.2/i586/ (Toulouse)
Germany
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandr
a ke/8.2/i586/ (Esslingen)ftp://ftp.de.uu.net/pub/linux/mandrake/8.2/i586/
ftp://ftp.fh-giessen.de/pub/linux/mandrake/8.2/i5
8 6/ (Giessen)ftp://ftp.fh-wolfenbuettel.de/pub/os/linux/mandra
k e/dist/8.2/i586/ (Wolfenbuettel)ftp://ftp.gwdg.de/pub/linux/mandrake/8.2/i586/ (Goettingen)
ftp://ftp.join.uni-muenster.de/pub/linux/distribu
t ions/mandrake/8.2/i586/ (Muenster)ftp://ftp.leo.org/pub/comp/os/unix/linux/Mandrake
/ Mandrake/8.2/i586/ (Munchen)ftp://ftp.tu-chemnitz.de/pub/linux/mandrake/8.2/i
5 86/ (Chemnitz)ftp://ftp.tu-clausthal.de/pub/linux/mandrake/8.2/
i 586/ (Clausthal)ftp://ftp.uasw.edu/pub/os/linux/mandrake/dist/8.2
/ i586/ (Wolfenbuettel)ftp://ftp.uni-bayreuth.de/pub/linux/Mandrake/8.2/
i 586/ (bayreuth)ftp://ftp.uni-kassel.de/pub/linux/mandrake/8.2/i5
8 6/ (Kassel)ftp://ftp.uni-mannheim.de/systems/linux/mandrake/
8 ftp://ftp.vat.tu-dresden.de/pub/Mandrake/8.2/i586
/ (Dresden)ftp://ramses.wh2.tu-dresden.de/pub/mirrors/mandra
k e/8.2/i586/ (Dresden)ftp://sunsite.informatik.rwth-aachen.de/pub/Linux
/ mandrake/8.2/i586/ (Aachen)
Greece
ftp://ftp.duth.gr/pub/Mandrake/8.2/i586/ (Thrace)
ftp://ftp.ntua.gr/pub/linux/mandrake/8.2/i586/ (Athens)
Hong Kong
ftp://ftp.wisr.eie.polyu.edu.hk/linux/mandrake/8.
2
Hungary
ftp://ftp.linuxforum.hu/mirror/Mandrake/8.2/i586/
Ireland
ftp://ftp.esat.net/pub/linux/mandrake/8.2/i586/
Italy
ftp://bo.mirror.garr.it/mirrors/Mandrake/8.2/i586
/ (Bologna)ftp://ftp.edisontel.it/pub/Mandrake_Mirror/Mandra
k e/8.2/i586/
Latvia
ftp://ftp.latnet.lv/linux/mandrake/8.2/i586/
Netherlands
ftp://ftp.nl.uu.net/pub/linux/mandrake/8.2/i586/
ftp://ftp.nluug.nl/pub/os/Linux/distr/Mandrake/Ma
n drake/8.2/i586/ftp://ftp.surfnet.nl/pub/os/Linux/distr/Mandrake/
M andrake/8.2/i586/ftp://ftp.wau.nl/pub/Mandrake/8.2/i586/ (Wageningen)
Poland
ftp://ftp.ps.pl/mirrors/mandrake/8.2/i586/ (Szczecin)
ftp://ftp.task.gda.pl/pub/linux/Mandrake/8.2/i586
/ (Gdansk)
Portugal
ftp://ftp.dei.uc.pt/pub/linux/Mandrake/Mandrake/8
. 2/i586/ (Coimbra)ftp://tux.cprm.net/pub/Mandrake/8.2/i586/
Russia
ftp://ftp.chg.ru/pub/Linux/mandrake/8.2/i586/ (Chernogolovka)
Singapore
ftp://ftp.singnet.com.sg/opensource/linux/Mandrak
e
Slovakia
ftp://spirit.profinet.sk/mirrors/Mandrake/8.2/i58
6
Spain
ftp://ftp.cesga.es/pub/linux/Mandrake/8.2/i586/ (Galicia)
ftp://ftp.cica.es/pub/Linux/Mandrake/8.2/i586/ (Sevilla)
ftp://ftp.rediris.es/pub/linux/distributions/mand
r ake/8.2/i586/
Sweden
ftp://ftp.chello.se/pub/Linux/Mandrake/8.2/i586/
ftp://ftp.chl.chalmers.se/pub/Linux/distributions
/ Mandrake/8.2/i586/ (Gothenburg)ftp://ftp.du.se/pub/os/mandrake/8.2/i586/ (Dalarma)
Switzerland
ftp://ftp.pcds.ch/pub/Mandrake/8.2/i586/ (Neuhausen)
ftp://sunsite.cnlab-switch.ch/mirror/mandrake/8.2
/ i586/ (Zurich)
Taiwan
ftp://linux.cdpa.nsysu.edu.tw/pub/Mandrake/mandra
k e/8.2/i586/ftp://linux.csie.nctu.edu.tw/distributions/mandra
k e/Mandrake/8.2/i586/ftp://mdk.linux.org.tw/pub/mandrake/8.2/i586/
Turkey
ftp://ftp.ankara.edu.tr/pub/linux/dagitimlar/Mand
r ake/8.2/i586/ (Ankara)
United Kingdom
ftp://ftp.mirror.ac.uk/sites/sunsite.uio.no/pub/u
n ix/Linux/Mandrake/Mandrake/8.2/i586/ (Canterbury)
United States
ftp://ftp-linux.cc.gatech.edu/pub/linux/distribut
i ons/mandrake/8.2/i586/ (Georgia)ftp://ftp.cise.ufl.edu/pub/mirrors/mandrake/Mandr
a ke/8.2/i586/ (Florida)ftp://ftp.cse.buffalo.edu/pub/Linux/Mandrake/mand
r ake/8.2/i586/ (NY)ftp://ftp.nmt.edu/pub/linux/mandrake/8.2/i586/ (New Mexico)
ftp://ftp.orst.edu/pub/mandrake/8.2/i586/ (Oregon)
ftp://ftp.tux.org/pub/distributions/mandrake/8.2/
i 586/ (Virginia)ftp://ftp.umr.edu/pub/linux/mandrake/Mandrake/8.2
/ i586/ (Missouri)ftp://ftp.uwsg.indiana.edu/linux/mandrake/8.2/i58
6 ftp://linux-cs.tccw.wku.edu/pub/linux/distributio
n s/Mandrake/8.2/i586/ (WKU-Linux, Western Kentucky University)ftp://mirror.aca.oakland.edu/linux/mandrake/8.2/i
5 86/ (Michigan)ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandra
k e/8.2/i586/ (Wisconsin)ftp://mirror.mcs.anl.gov/pub/Mandrake/8.2/i586/ (Illinois)
ftp://mirrors.ptd.net/mandrake/8.2/i586/ (Pensylvania)
ftp://mirrors.secsup.org/pub/linux/mandrake/Mandr
a ke/8.2/i586/ftp://uml-pub.ists.dartmouth.edu/mirrors/ftp.mand
r akesoft.com/pub/Mandrake/mandrake/8.2/i586/ (New Hampshire)ftp://videl.ics.hawaii.edu/mirrors/mandrake/Mandr
a ke/8.2/i586/ (Hawaii)http://mandrake.dsi.internet2.edu/Mandrake/8.2/i5
8 6/ (For Internet2 academic institutions only)
-
mirrors
Australia
ftp://ftp.planetmirror.com/pub/Mandrake/8.2/i586/ (Brisbane)
Austria
ftp://ftp.univie.ac.at/systems/linux/Mandrake/8.2
/ i586/ (Vienna)ftp://gd.tuwien.ac.at/pub/linux/Mandrake/8.2/i586
/ (Vienna)
Belgium
ftp://ftp.belnet.be/packages/mandrake/8.2/i586/
Costa Rica
ftp://ftp.ucr.ac.cr/pub/Unix/linux/mandrake/Mandr
a ke/8.2/i586/
Czech Republic
ftp://ftp.cesnet.cz/OS/Linux/Mandrake/mandrake/8.
2 ftp://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)
ftp://klobouk.fsv.cvut.cz/pub/linux-mandrake/Mand
r ake/8.2/i586/ (Prague)ftp://mandrake.redbox.cz/Mandrake/8.2/i586/
ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Mandrake/
m andrake/8.2/i586/ (Prague)http://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586
/ (Brno)
Denmark
ftp://ftp.dkuug.dk/pub/mandrake/8.2/i586/ (Koebenhavn)
ftp://ftp.sunsite.dk/mirrors/mandrake/8.2/i586/ (Aalborg)
Estonia
ftp://ftp.aso.ee/pub/os/Linux/distributions/mandr
a ke/8.2/i586/
Finland
ftp://ftp.song.fi/pub/linux/Mandrake/8.2/i586/ (Espoo)
France
ftp://ftp.ciril.fr/pub/linux/mandrake/8.2/i586/ (Nancy)
ftp://ftp.club-internet.fr/pub/unix/linux/distrib
u tions/Mandrake/8.2/i586/ (Paris)ftp://ftp.info.univ-angers.fr/pub/linux/distribut
i ons/mandrake/8.2/i586/ (Angers)ftp://ftp.lip6.fr/pub/linux/distributions/mandrak
e ftp://ftp.proxad.net/pub/Distributions_Linux/Mand
r ake/8.2/i586/ (Paris)ftp://ftp.u-strasbg.fr/pub/linux/distributions/ma
n drake/8.2/i586/ (Strasbourg)ftp://linux.ups-tlse.fr/Mandrake/8.2/i586/ (Toulouse)
Germany
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandr
a ke/8.2/i586/ (Esslingen)ftp://ftp.de.uu.net/pub/linux/mandrake/8.2/i586/
ftp://ftp.fh-giessen.de/pub/linux/mandrake/8.2/i5
8 6/ (Giessen)ftp://ftp.fh-wolfenbuettel.de/pub/os/linux/mandra
k e/dist/8.2/i586/ (Wolfenbuettel)ftp://ftp.gwdg.de/pub/linux/mandrake/8.2/i586/ (Goettingen)
ftp://ftp.join.uni-muenster.de/pub/linux/distribu
t ions/mandrake/8.2/i586/ (Muenster)ftp://ftp.leo.org/pub/comp/os/unix/linux/Mandrake
/ Mandrake/8.2/i586/ (Munchen)ftp://ftp.tu-chemnitz.de/pub/linux/mandrake/8.2/i
5 86/ (Chemnitz)ftp://ftp.tu-clausthal.de/pub/linux/mandrake/8.2/
i 586/ (Clausthal)ftp://ftp.uasw.edu/pub/os/linux/mandrake/dist/8.2
/ i586/ (Wolfenbuettel)ftp://ftp.uni-bayreuth.de/pub/linux/Mandrake/8.2/
i 586/ (bayreuth)ftp://ftp.uni-kassel.de/pub/linux/mandrake/8.2/i5
8 6/ (Kassel)ftp://ftp.uni-mannheim.de/systems/linux/mandrake/
8 ftp://ftp.vat.tu-dresden.de/pub/Mandrake/8.2/i586
/ (Dresden)ftp://ramses.wh2.tu-dresden.de/pub/mirrors/mandra
k e/8.2/i586/ (Dresden)ftp://sunsite.informatik.rwth-aachen.de/pub/Linux
/ mandrake/8.2/i586/ (Aachen)
Greece
ftp://ftp.duth.gr/pub/Mandrake/8.2/i586/ (Thrace)
ftp://ftp.ntua.gr/pub/linux/mandrake/8.2/i586/ (Athens)
Hong Kong
ftp://ftp.wisr.eie.polyu.edu.hk/linux/mandrake/8.
2
Hungary
ftp://ftp.linuxforum.hu/mirror/Mandrake/8.2/i586/
Ireland
ftp://ftp.esat.net/pub/linux/mandrake/8.2/i586/
Italy
ftp://bo.mirror.garr.it/mirrors/Mandrake/8.2/i586
/ (Bologna)ftp://ftp.edisontel.it/pub/Mandrake_Mirror/Mandra
k e/8.2/i586/
Latvia
ftp://ftp.latnet.lv/linux/mandrake/8.2/i586/
Netherlands
ftp://ftp.nl.uu.net/pub/linux/mandrake/8.2/i586/
ftp://ftp.nluug.nl/pub/os/Linux/distr/Mandrake/Ma
n drake/8.2/i586/ftp://ftp.surfnet.nl/pub/os/Linux/distr/Mandrake/
M andrake/8.2/i586/ftp://ftp.wau.nl/pub/Mandrake/8.2/i586/ (Wageningen)
Poland
ftp://ftp.ps.pl/mirrors/mandrake/8.2/i586/ (Szczecin)
ftp://ftp.task.gda.pl/pub/linux/Mandrake/8.2/i586
/ (Gdansk)
Portugal
ftp://ftp.dei.uc.pt/pub/linux/Mandrake/Mandrake/8
. 2/i586/ (Coimbra)ftp://tux.cprm.net/pub/Mandrake/8.2/i586/
Russia
ftp://ftp.chg.ru/pub/Linux/mandrake/8.2/i586/ (Chernogolovka)
Singapore
ftp://ftp.singnet.com.sg/opensource/linux/Mandrak
e
Slovakia
ftp://spirit.profinet.sk/mirrors/Mandrake/8.2/i58
6
Spain
ftp://ftp.cesga.es/pub/linux/Mandrake/8.2/i586/ (Galicia)
ftp://ftp.cica.es/pub/Linux/Mandrake/8.2/i586/ (Sevilla)
ftp://ftp.rediris.es/pub/linux/distributions/mand
r ake/8.2/i586/
Sweden
ftp://ftp.chello.se/pub/Linux/Mandrake/8.2/i586/
ftp://ftp.chl.chalmers.se/pub/Linux/distributions
/ Mandrake/8.2/i586/ (Gothenburg)ftp://ftp.du.se/pub/os/mandrake/8.2/i586/ (Dalarma)
Switzerland
ftp://ftp.pcds.ch/pub/Mandrake/8.2/i586/ (Neuhausen)
ftp://sunsite.cnlab-switch.ch/mirror/mandrake/8.2
/ i586/ (Zurich)
Taiwan
ftp://linux.cdpa.nsysu.edu.tw/pub/Mandrake/mandra
k e/8.2/i586/ftp://linux.csie.nctu.edu.tw/distributions/mandra
k e/Mandrake/8.2/i586/ftp://mdk.linux.org.tw/pub/mandrake/8.2/i586/
Turkey
ftp://ftp.ankara.edu.tr/pub/linux/dagitimlar/Mand
r ake/8.2/i586/ (Ankara)
United Kingdom
ftp://ftp.mirror.ac.uk/sites/sunsite.uio.no/pub/u
n ix/Linux/Mandrake/Mandrake/8.2/i586/ (Canterbury)
United States
ftp://ftp-linux.cc.gatech.edu/pub/linux/distribut
i ons/mandrake/8.2/i586/ (Georgia)ftp://ftp.cise.ufl.edu/pub/mirrors/mandrake/Mandr
a ke/8.2/i586/ (Florida)ftp://ftp.cse.buffalo.edu/pub/Linux/Mandrake/mand
r ake/8.2/i586/ (NY)ftp://ftp.nmt.edu/pub/linux/mandrake/8.2/i586/ (New Mexico)
ftp://ftp.orst.edu/pub/mandrake/8.2/i586/ (Oregon)
ftp://ftp.tux.org/pub/distributions/mandrake/8.2/
i 586/ (Virginia)ftp://ftp.umr.edu/pub/linux/mandrake/Mandrake/8.2
/ i586/ (Missouri)ftp://ftp.uwsg.indiana.edu/linux/mandrake/8.2/i58
6 ftp://linux-cs.tccw.wku.edu/pub/linux/distributio
n s/Mandrake/8.2/i586/ (WKU-Linux, Western Kentucky University)ftp://mirror.aca.oakland.edu/linux/mandrake/8.2/i
5 86/ (Michigan)ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandra
k e/8.2/i586/ (Wisconsin)ftp://mirror.mcs.anl.gov/pub/Mandrake/8.2/i586/ (Illinois)
ftp://mirrors.ptd.net/mandrake/8.2/i586/ (Pensylvania)
ftp://mirrors.secsup.org/pub/linux/mandrake/Mandr
a ke/8.2/i586/ftp://uml-pub.ists.dartmouth.edu/mirrors/ftp.mand
r akesoft.com/pub/Mandrake/mandrake/8.2/i586/ (New Hampshire)ftp://videl.ics.hawaii.edu/mirrors/mandrake/Mandr
a ke/8.2/i586/ (Hawaii)http://mandrake.dsi.internet2.edu/Mandrake/8.2/i5
8 6/ (For Internet2 academic institutions only)
-
Re:P2P
Check this out. It's a Java anonymizing proxy that should be more than adequate for casual browsing. It's not "terrorist grade" anonymity, but should keep all but the most dedicated network nazis out of your traffic.
-
Re:Snake OilHere is a paper on the subject. Not very well written though, IMO.
(from a steg researcher)
-
Re:Wake me when HURD runs on top of L4
Let me bum you out some more. Check out the L4 pages on implementations.
There are 2-4 implementations of L4 that are geared towards the x86 family. The assembler one is implemented by someone who appears to have lost interest in it. The other implementations are in C++!
I can't find it anymore, but there was a page buried there that mentioned that L4 requiring some redesign to better support SMP (I think). I'm guessing part of the reason why HURD doesn't flat out switch to L4 is that L4's interface is still a moving target. -
Re:great news - Linux is NOT a microkernelJust to clarify, Linux is not a microkernel.
Microkernels like Mach, L4, Spin, and QNX run as much of the operating system as possible in user space (the processors unprivildged execution mode). Device drivers, virtual memory managers (pagers), all run in user space, as normal applications. Alternate resource allocation policies (processor scheduling) can often be implemented on top of the microkernel. This allows a lot of flexibility, as parts of the os can be stopped, started, replaced, and debugged just like any other user applications.
You can even run entrie alternate operating systems on top of a microkernel. MkLinux (Linux on Mach) and L4Linux (Linux on L4) are examples of this. Traditionally microkernels have been slower than conventional kernels, but that's chaning. Linux in user space on top of L4 (L4Linux) runs only 5% to 10% slower than native linux.
Linux does have loadable modules, which can be loaded and unloaded at run time. However, the the loaded code run as part of the kernel, in the prividged execution mode.
Nathan Wiebe -
Worst-case interrupt latencies - RTLinux and L4RTLHave a look at this paper: ``RTLinux with Address Spaces'' by Frank Mehnert and others.
In this paper, we measured ``worst-case'' interrupt delays of two real-time systems:
- RTLinux and
- L4RTL, a reimplementation of the RTLinux API on top of Fiasco (a real-time L4-compatible microkernel) and L4Linux. In comparison to RTLinux, L4RTL sports address spaces for real-time tasks.
On a 800-MHz Pentium III, the worst-case latency for RTLinux was 68 s. For L4RTL, it was 85 s.
Note that 68 s is considerably higher than what other sources quote as RTLinux's worst-case delay (in this thread, someone said 30--50 s). We believe that other researchers forget to take into account caching effects.
Anyway, it looks like both systems would be adequate for your application.
-
Worst-case interrupt latencies - RTLinux and L4RTLHave a look at this paper: ``RTLinux with Address Spaces'' by Frank Mehnert and others.
In this paper, we measured ``worst-case'' interrupt delays of two real-time systems:
- RTLinux and
- L4RTL, a reimplementation of the RTLinux API on top of Fiasco (a real-time L4-compatible microkernel) and L4Linux. In comparison to RTLinux, L4RTL sports address spaces for real-time tasks.
On a 800-MHz Pentium III, the worst-case latency for RTLinux was 68 s. For L4RTL, it was 85 s.
Note that 68 s is considerably higher than what other sources quote as RTLinux's worst-case delay (in this thread, someone said 30--50 s). We believe that other researchers forget to take into account caching effects.
Anyway, it looks like both systems would be adequate for your application.
-
Worst-case interrupt latencies - RTLinux and L4RTLHave a look at this paper: ``RTLinux with Address Spaces'' by Frank Mehnert and others.
In this paper, we measured ``worst-case'' interrupt delays of two real-time systems:
- RTLinux and
- L4RTL, a reimplementation of the RTLinux API on top of Fiasco (a real-time L4-compatible microkernel) and L4Linux. In comparison to RTLinux, L4RTL sports address spaces for real-time tasks.
On a 800-MHz Pentium III, the worst-case latency for RTLinux was 68 s. For L4RTL, it was 85 s.
Note that 68 s is considerably higher than what other sources quote as RTLinux's worst-case delay (in this thread, someone said 30--50 s). We believe that other researchers forget to take into account caching effects.
Anyway, it looks like both systems would be adequate for your application.
-
Worst-case interrupt latencies - RTLinux and L4RTLHave a look at this paper: ``RTLinux with Address Spaces'' by Frank Mehnert and others.
In this paper, we measured ``worst-case'' interrupt delays of two real-time systems:
- RTLinux and
- L4RTL, a reimplementation of the RTLinux API on top of Fiasco (a real-time L4-compatible microkernel) and L4Linux. In comparison to RTLinux, L4RTL sports address spaces for real-time tasks.
On a 800-MHz Pentium III, the worst-case latency for RTLinux was 68 s. For L4RTL, it was 85 s.
Note that 68 s is considerably higher than what other sources quote as RTLinux's worst-case delay (in this thread, someone said 30--50 s). We believe that other researchers forget to take into account caching effects.
Anyway, it looks like both systems would be adequate for your application.
-
Worst-case interrupt latencies - RTLinux and L4RTLHave a look at this paper: ``RTLinux with Address Spaces'' by Frank Mehnert and others.
In this paper, we measured ``worst-case'' interrupt delays of two real-time systems:
- RTLinux and
- L4RTL, a reimplementation of the RTLinux API on top of Fiasco (a real-time L4-compatible microkernel) and L4Linux. In comparison to RTLinux, L4RTL sports address spaces for real-time tasks.
On a 800-MHz Pentium III, the worst-case latency for RTLinux was 68 s. For L4RTL, it was 85 s.
Note that 68 s is considerably higher than what other sources quote as RTLinux's worst-case delay (in this thread, someone said 30--50 s). We believe that other researchers forget to take into account caching effects.
Anyway, it looks like both systems would be adequate for your application.
-
Re:For future reference...
Linux is a washing powder, didn't you know? Those of you who don't believe me read, read or read
-
Can you say "mach" ?
OS X is implemented on top of the Mach microkernel. This (mach) is slow. So slow that OS developers (excepting QNX) have essentially given up on microkernel designs, convinced that they added unavoidable latencies. How bad? IIRC, a null-IPC (the shortest inter-process message you can send) in mach took on the order of 30,000 cycles. Every call to an OS service requires at least 1 such round-trip, and 2 or 3 if it goes to a driver (program -> mach -> driver -> mach -> program).
Recent work (esp. by the late Dr. Jochen Liedtke) such as the L4 -Kernel has shown remarkable improvements in IPC speed and bandwidth -- on the order of 150 cycles on a Pentium-1.
If I had enough spare time, I would port Darwin (the OS X kernel) to L4/x86 and see how much faster it goes.
...
Of course, having said that, I should note that Microsoft was probably not motivated to make IE on OS X run very fast or reliably. So the answer is probably "it runs slow because of both the OS and the browser"
-
A couple of ideas
The Hurd and L 4 are some of the promising new technologies under development.
At the same time, don't go getting the idea Linux is going away any time soon. It can take over 20 years for a codebase to really mature, and a mature codebase may still be useful for many years after it is no longer cutting edge.
-
Re:what's the hurd?
The HURD is a Hird of Unix Replacing Daemons. Clearer?
What's a Hird? Hurd of Interfaces Representing Depth. There, all clear now?
Academic CS guys have been saying microkernels are the way of the future for years now. Mac OS10 runs on the Mach microkernel. Windows NT was supposed to be a microkernel, although by the time it actually made it to the light of day so much had been stuffed back into the kernel for performance reasons it really isn't one.
The number one drawbacks to microkernels, as the above might lead you to guess, is performance. On a single processor system expect a microkernel to lag significantly performancewise in comparison to a monolithic kernel with equal optimisations. That's a result of the fact that so many things we think of as system services are user processes instead, and of the communication overhead involved (message passing between components is used extensively, and this is not the fastest way to handle things on a uniprocessor system.)
Why do I say "on a uniprocessor system?" Well, some of that overhead becomes unavoidable anyway when you move to a multiprocessor system, and a microkernel is inherently multithreaded, so it's quite friendly to multiprocessor systems. So as multiprocessor systems become more common the performance gap may drop.
Currently the HURD is a collection of servers that run on top of the GNU Mach microkernel. Does that sentence make more sense for you now? I hope so.
The GNU Mach microkernel is something of a performance dog, but at this point the HURD is still at a development only stage anyway so it doesn't much matter. It will probably be moved to an L4 microkernel instead before it's used in production machines. The L4 family gives much improved performance. Still slower than a highly tuned monolithic kernel like Linux, particularly on uniprocessor systems, but much closer.
So if microkernels are slower, why use them at all? Well, they have the potential to bring an entire new world of flexibility to computing. Imagine having different "personalities" - different collections of "kernel service" daemons, so that your box can run Linux, BSD, Solaris, VMS, or even Windows sessions, on the fly. Imagine being able to switch between them, or run different ones simultaneously, without having "root" privileges and without affecting other users. This is just one of the many interesting things that could be done on a microkernel system but not on a monolithic one. Another one is a system where any user can do all sorts of things that normally require root access, except for mess up other users.
None of the pre-existing systems seem to have ever really taken advantage of microkernel design - rather they just use a microkernel to emulate a single monolithic kernel (usually BSD.) However, there are some pretty incredible microkernel only tricks out there waiting to be done, and the HURD developers plan on finally doing them.
-
Re:I agreeIt's much easier to write network applications in Java than C, and cross-platform compatibility is far better.
Now that Apple has turned to BSD, there is Unix and Windows left for the desktop. And last time I checked, JAP (Java Anon Proxy) worked ok on Win98 (except that Win98 occasionally crashes
-
Re:Open Drivers
Yes.
-
Try JAP
Go to the JAP page and see what they can do. They have a Java based proxy and are focusing on security over performance.
-
Re:Hurd Speed
What about Fiasco? It claims to be a "Real-Time" kernel.
And is BeOS really a real-time OS? I've never heard it described that way. If so then it's a damn shame that Apple nixed it for a Mach-based system.
-
Why????
This isn't a troll, I'm just trying to get a handle on why exactly the HURD exists.
1) Is it because its all GPL?
2) Is it because its a microkernel?
3) Maybe a new, improved microkernel? Not MACH.
4) Security?
5) Performance? Yea right.
6) Ease of use? Isn't that up to KDE and GNOME?
7) Translators, Namespace unification, RPC? Been there, done that.
So, exactly why does HURD exist? What does it bring to the table that hasn't been seen dozens of times before? (Besides allowing non-root users to mount partitions!) -
In Germany the converse happens ...Maybe encryption/privacy on the net goes down in the US, but at the same time it receives substantial funding by the German government.
This is not only true for GnuPG, which has funding by the government (for the development of more user-friendly frontends, I think), but there is also a project for the development of an open source anonymity service (JAP) as strong as (or even stronger than) the Freedom anonymizer service, and there is also the Sphinx project to build a PKI for the public authorities and maybe others.
One of the main drivers for the JAP project (and maybe others) seems to be that many consumers (at least in Germany) apparently avoid E-commerce because of privacy concerns.
-
Java Anon Proxy
Once again time to mention JAP, which will at least take care of HTTP.
Unluckily, it`s still under development and servers are scarce. -
Re:"Mach is a bad microkernel implementation".. HOFiasco is another C++ implementation of L4.
"The original L4 -kernel for x86 has some shortcomings which we intend to fix with this new implementation. The Fiasco kernel:- can be studied and maintained better because it has been written in a high-level language (C++)
- has better real-time properties than L4/x86 because it can be preempted at almost any time
- is freely redistributable under the GPL
See also the L4Linux project:
"L4Linux is a port of the Linux kernel to the L4/x86 and Fiasco -kernels (microkernels), two kernels implementing the L4 -kernel API.""L4Linux runs in user-mode on top of the -kernel, side-by-side with other -kernel applications such as real-time components. It is binary-compatible with the normal Linux/x86 kernel and can be used with any PC-based Linux distribution."
-- -
Re:"Mach is a bad microkernel implementation".. HOFiasco is another C++ implementation of L4.
"The original L4 -kernel for x86 has some shortcomings which we intend to fix with this new implementation. The Fiasco kernel:- can be studied and maintained better because it has been written in a high-level language (C++)
- has better real-time properties than L4/x86 because it can be preempted at almost any time
- is freely redistributable under the GPL
See also the L4Linux project:
"L4Linux is a port of the Linux kernel to the L4/x86 and Fiasco -kernels (microkernels), two kernels implementing the L4 -kernel API.""L4Linux runs in user-mode on top of the -kernel, side-by-side with other -kernel applications such as real-time components. It is binary-compatible with the normal Linux/x86 kernel and can be used with any PC-based Linux distribution."
-- -
Re:"Mach is a bad microkernel implementation".. HOFiasco is another C++ implementation of L4.
"The original L4 -kernel for x86 has some shortcomings which we intend to fix with this new implementation. The Fiasco kernel:- can be studied and maintained better because it has been written in a high-level language (C++)
- has better real-time properties than L4/x86 because it can be preempted at almost any time
- is freely redistributable under the GPL
See also the L4Linux project:
"L4Linux is a port of the Linux kernel to the L4/x86 and Fiasco -kernels (microkernels), two kernels implementing the L4 -kernel API.""L4Linux runs in user-mode on top of the -kernel, side-by-side with other -kernel applications such as real-time components. It is binary-compatible with the normal Linux/x86 kernel and can be used with any PC-based Linux distribution."
-- -
Re:"Mach is a bad microkernel implementation".. HOWill someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
I don't know enough of the Mach internals to know exactly why it's such a poor performer, but I have read alot of theories put forth. The most common(and accepted) reason is that Mach's memory management is too abstract and that because Mach is built on a hardware abstraction layer. Those two reasons are directly interrelated.
The Hardware abstraction layer(HAL) restricts the u-kernel to operation on a "generic machine". Everything is abstracted in the sense that the HAL contains the units which are common to all CPU architectures. This was done to improve portability. However, it sacrifices a great deal of performance because alot of issues are platform dependent. Things such as page size must be dictated by the architecture you are running on. But because Mach uses the HAL to abstract this away, Mach performance suffers a great deal in memory operations. Often, the HAL dictates a page size which is too small/large for the architecture. The hardware can't handle address translation anymore, so the kernel has to do this manually. This is very expensive.
In general, Mach's architecture just seems poorly designed from what I've read. Alot of research has been done on this topic, and they're coming to the realization that u-kernels are inherently non-portable. That's a very important point. This shouldn't be surprising either because the u-kernel is so small that mostly only platform dependent code end up in there. L4 is 12k, Eros is 32k(I think), VSTa is around 50k and QNX is less than 10k!
The good thing about this approach is that most(if not all) of the platform-dependent code is wrapped up in the u-kernel. The rest of the system is completely portable. So all you have to do is re-write about half of a 20k kernel for the new architecture, and you're done! Re-compile and off you go. Theoretically at least.
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel? Are any well-designed microkernels out there?
Good u-kernels that have implementations with performance comparable to or exceeding Linux:- QNX: Everyone's heard of this one. They have a very good u-kernel.
- Opearting Systems Group at Dresden: They do alot of great work with u-kernels. They have code for L3 and L4, the first very promising, high-performance u-kernels(though they may not have designed them). They even have Linux running as a service on top of L4, so you may be able to run it right now! Also see This University and the L4KA page for other implementations of L4(ie. other architectures).
- Eros: EROS is a new operating system based on the architectures of earlier high-security capability systems(KeyKOS). Very promising and has performance comparable to L4. The measurements are in the papers section(usually towards the end of the paper). System is GPL'd.
- VSTa: a cool GPL'd hobby u-kernel system(in that it has no university or company backing). This one has a somewhat complete system, ie. self-hosted with gcc, vi, emacs, etc. Runs on a windows partition and uses GRUB to boot(all of which you'll need to run it). No performance metrics that I'm aware of.
- Fluke: No working system as far as I know. The kernel is complete and some performance measurements have been made. Looks promising and source is available(GPL I think).
If there are, then what is it that repeatedly leads projects like xMach/HURD/OS X/mkLinux to embrace Mach as opposed to one of the competing microkernels?
I have no idea. Ignorance of their existence probably.
Unless i am quite confused, supposedly, because the interaction between the microkernel and the OS is somewhat abstract, you ought to be able to replace the microkernel with a better one as long as the interface is the same. Is there any reason a better microkernel with the same software-side interface as Mach could not be written, and used to replace mach?
Yes you could. But then you'd just have Mach.
someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true? How does that work in terms of sharing the hardware? How do you go about doing this?
Yes that's true, but not in the way you're thinking. Both kernels don't run as kernels at the same time. A well-engineered u-kernel is so thin and provides such a minimal interface to the hardware, that by just slightly modifying Linux(or other kernel) you can get it to run on top of the u-kernel like any other application, and it could do everything that Linux does running on the bare hardware. See L4Linux, MkLinux, Darwin/MacOS X and even this xMach project as examples. The key to good performance is to provide as small a u-kernel with as minimal an interface as feasible to avoid performance problems. It will never run as fast as on bare hardware, but you can get pretty damn close.
I am just thinking that at this point, it would be an utterly useless but nifty parlor trick to try to get Mac OS X/Darwin, MkLinux, xMach and HURD running off the same mach microkernel on the same machine at the same time.
Not so useless as you might think. The problem with any new operating system or kernel is software. There's nothing written for it yet. But what if you could run the Linux kernel on top of your new OS? You'd have near instant access to whatever drivers and applications are currently available for Linux without any porting effort! (except for the initial Linux port) Then you can have a complete system and start writing native drivers for what you need.
-----
"Goose... Geese... Moose... MOOSE!?!?!" -
When slashdotted, here are mirrors
-
GermanyI can't seem to find Germany in the previous posts, so...
Restrictive laws:
Like German laws in other areas of life, you must not publish Nazi propaganda or child pornography.
Encryption is ok, even supported by the government.
We have a discussion about some proposal that would force ISPs and communication providers in general (like all the Telcos) so save connection data (like who called who when, who had what IP when and so on) for up to six months. But then, other parts of the government actively support projects like the Java Anon Proxy (click "English" on the top right).
So, besides Nazi propaganda restrictions, it's pretty much like in the US, which gladly hosts the Nazi propaganda for us.
Oh, and downloading mp3s via napster & co for private use is legal, if uploading is is uncertain.Quality of service:
I have an aDSL connction, 768kb/s downstream and 128 up. That's some 30$/month alltogether (incl. unlimited data transfer). However, the infrastructure has yet to be build in some areas.
Alternatives are ISDN or satellite. Hardly anybody has cablemodem access. And that Powerline stuff (connection via powerline, most obviously) in quite new and again, the infrastructure has to be build (but of course the cables are already there).
Then, of course you can connect via your mobile, 9.6k with standart GSM available virtually anywhere, GPRS (depends on your mobile, >ISDN), or just wait for UMTS which will give you up to 2MBit/s on your mobile in abut 2 years (if you can afford it - the Telcos paid some $50Billion for the licences alltogether).The rest of the EU is pretty much alike.
-
L4/L3, Fiasco and Linux
Modern microkernel development has come along a fair bit since suffering such bad press in the 90's. L4, the successor to L3, now refers to a family of kernels based on the L4 API. Jochen Liedtke's implementation for 486s had a very restrictive license. Others have addressed this by offering GPL'd implementations. This list of L4s is a good starting point for thos interested in the topic.
-
Re:But he doesnt follow his own advice
-
Some words on the matter
Since my wife is one of the persons on the list of people actually working on this, I may add a few words to it. Marit has a publications list online.
How does it work? Well, have a look at project anonymity and unobservability on the Internet. A MIX network is like a system of remailers, just for IP packets. There are several kinds of attacks against a MIX network ("nix the MIX") and they are categorized and discussed in that paper.
Specifically, the problem of cooperating MIX network node operators is being discussed. Have a look at the properties of ideal MIXes: It is sufficient for the MIX network to have a single trustworthy node in your path in order to protect your anonymity (section 1.2 of that paper).
Marit has a paper on anonymity terminology online, too (txt version of that paper). Have a look at it in order to get your vocabulary. Additionally, there is a web page on identity management on her server. This relates P3P and anonymity/pseudonymity.
© Copyright 2000 Kristian Köhntopp
All rights reserved. -
Re:HURD? Not now, the worlds moved on.By core service i pressume that you here mean a service that is offered by the microkernel. Now, if you build a monolithic system on top of a microkernel (i.e., an opereating system kernel running as a single task in user-mode -- usually called an OS personality), this task will be able to perform most of the responsibilities that a normal os kernel does -- without using any of the core services. This is possible because the os kernel (running as a task) has exclusive acccess to any of the hardware resouces it needs (e.g., devices), and is the approach taken by L4Linux (running on top of L4) and MkLinux (running on top of Mach).
Of course, in a real system you also have other tasks which needs to interact with the OS task. This occurs (almost) exclusively through IPC mechanisms, and IPC mechanisms have therefore been identified as the main performance bottleneck for microkernel systems. The IPC mechanism basically deals with transferring (usually a small) amount of words from one task/thread to another, and performing a context switch between the tasks/threads. There are three sides to the cost associated with this:
- The added number of processor cycles used to actually perform the context switch.
- The added number of flushed cache lines due to the microkernel design.
- The added number of TLB invalidations/flushes.
-
s/Mach/L4/g
Aye, there was some discussion not too long ago about replacing the Mach architecture with L4. Some guy said he was going to do some thesis work involving the Hurd, and wanted to know what he could do that would be useful, and this was one of the first suggestions that came up.
Many of the debian-hurd folk were pretty excited about this possibility, as L4 is smaller and faster than Mach, is already in a working state, and is actively being worked on by its own cadre of developers.
(Man. To think-- not so many years ago, the vision for the GNU desktop system was GNUstep running on Hurd. I hope it'll still come to pass...) -
Microkernel technology and SawMillMicrokernel technology is hard to sell. Despite this fact though, people are still developing new -kernels and doing active research in the area. BeOS has been mentioned as one example. Pebble from Bell Labs is another. One would hardly call the technology a relic of the past.
As for the performance degradation that the -kernel architecture imposes on the system, there has been quite a lot of research in the last ten years indicating that this effect can be alleviated. Moreover, much of the performance degradation due to the added number of context switches in -kernel systems is due to inneficient/inapropriate hardware mechanisms and design. By harnessing state of the art hardware design (e.g., IA-64), we may come to see that the added overhead of context switches is ignorable. There is work underway to create efficient -kernels for these more arcane architectures, and only time will tell whether our hopes can be reached or not.
Also, -kernel technology is believed to pose a compelling soultion to the one-size-fits-all problem that you address in conjunction with Linux. To put it short, one would compile the operating system components so that they match the exact requirements that you meet in, e.g., pervasive computing or big irons. In fact, IBM is doing joint research with a number of universities aiming at providing a multiserver version of Linux - SawMill Linux - with these exact goals in mind. This work may of course fail (that's the beauty of research), but I think it is a bit early yet to put the last nail in the coffin for multiserver operating systems.
And just for the records: SawMill is hopefully going GPL any time soon now, enabling people to use it with the GPLed Fiasco or newly developed L4Ka -kernels. (That should probably make you GPL zealots happy.
-
Re:Open source the micro kernel!
HURD is not itself a microkernel. It is a series of servers which run on top of the Mach microkernel. Mach is very old technology, a "first generation" microkernel and not known for its performance. There aren't really any "second generation" solutions that are open source other than Fiasco, and it has serious limitations.
-
Re:He's right, of course.Either you share the data between the two things that call each other, in which case it can get corrupted if you are using C/C++, or you don't share the data, in which case you need to copy and things are slow.
That's the usual tradeoff. But it's escapeable with hardware support. Consider a system call, where the kernel has access to the stack of the caller, but the reverse isn't true. Pentiums and above support a similar mechanism for several protection rings, so you could, with suitable OS support, have non-kernel things applications could call but couldn't crash.
What you really want is a mechanism which can handle a crash on either side gracefully, just as a CORBA/Java RMI call can. This can be done inefficiently now, more efficiently with good OS support for call-type IPC, and very efficiently with some hardware support. For a while, I was thinking of working on L4/Linux and bringing it up to a usable state, but L4 isn't ready yet. Good ideas, though; it's a must-read for OS designers.
The hardware needed is already in some SPARC CPUs. It's unused, because the Spring OS people went off and did Java, but it's there.
As for getting people to convert to safe languages, I agree with jetson123 that it's desirable, but it's politically hopeless. I wish we were all using a Modula family language. I miss the Modula experience: once it compiles, it often runs correctly the first time. But even Compaq/DEC has shelved Modula.
-
Innovative open source projectsEROS, an operating system with a capability-based security model and "orthogonal persistence" - basically, you can pull the plug out of the wall, and when you reboot your apps won't even know it happened.
Berlin, a windowing system which has many of X's strengths (toolkit independence, network transparency) but few of its weaknesses (primitive framebuffer-based graphics model, bitmap fonts, no alpha channel, high bandwidth requirements).
Fiasco, a free microkernel which is a drop-in replacement for L4, used in several research operating systems.
$ cat <
-
Innovative open source projectsEROS, an operating system with a capability-based security model and "orthogonal persistence" - basically, you can pull the plug out of the wall, and when you reboot your apps won't even know it happened.
Berlin, a windowing system which has many of X's strengths (toolkit independence, network transparency) but few of its weaknesses (primitive framebuffer-based graphics model, bitmap fonts, no alpha channel, high bandwidth requirements).
Fiasco, a free microkernel which is a drop-in replacement for L4, used in several research operating systems.
$ cat <
-
Re:I don't get itI am speculating here, but my guess is that MacOS X's kernel is a descendant (at least in spirit) of the old NeXT OS (NeXTStep?) which was a Mach-2.5-based BSD system. When Apple bought NeXT, they probably decided to use NeXT's existing OS technology and talent to build their own new OS; I guess that is about the only reason why Darwin (the BSD OS core MacOS X uses) today is Mach-based.
So why did NeXT use Mach in the first place? I'm speculating again. I guess they started out from OSF/1, and the OSF/1 developers had your goals (a) and (b) in mind.
Remember: The Open Software Foundation (OSF, now a merged with the Open Group) was a group of vendors that wanted to develop an Unix platform independent from then-AT&T's UNIX. OSF/1 was to be their kernel. DEC used it to build DEC OSF/1 (now Compaq Tru64 UNIX or whatever it is called this week), and I guess that NeXT took it to build NeXTStep.
The first version of OSF/1 (the one out of which vendors made successful products) was a BSD single server on top of Mach 2.5. At the time it was developed, it was not yet well established that Mach-based systems are slow. In fact, the Mach-2.5-based OSF/1 probably was not that slow: Mach 2.5 had considerably less bloat than Mach 3.0, and it was not really a microkernel-based system as it was closely integrated with a BSD kernel - that is, the microkernel and the BSD server shared the kernel address space (this is sometimes called ``colocation''; the OSF recently rediscovered this technique to speed up MkLinux on top of Mach 3.0). Only with the advent of Mach 3.0, the first ``real'' microkernel, people started to notice that there is something wrong with Mach's original approach.
That said, it does not necessarily follow that microkernel-based system, or even Mach-based systems in particular, need to be slow. I do microkernel-related research myself, and my group has shown with L4Linux that a Unix single server can be implemented with very reasonable overhead on top of a ``real,'' second-generation microkernel - in this case, L4 (macrobenchmarks indicate that L4Linux has an overhead of about 2% to 3% when compared to the original monolithic Linux kernel).
I do not really know MacOS X's architecture well enough to give a well-informed statement, but my guess is that they have enough talent to avoid the most stupid mistakes.
