Finally I've got a good excuse for not carefully reading the article:-)
Thier site is popular enoug that it would seem to be a good time to experiment with moving the http stuff to freenet, since it's only updated once per day. The people willing to download the dnet client are would seem to be some of the most willing people to download the freenet client. Freenet is designed so that the slashdot effect actually increases reliability and speed of acess for the commonly requested data. Distributed.net would seem to have reached a critical mass of readership in order to have reasonable reliability for its freenet page. Your could have the client get your team and individual scores sent to it as part of the block submission cinfirmation.
It would seem to me that they could arbitrarily reduce their bandwidth requirements by increasing the minimum size of keyspace portions they're handing out. It would seem that thier project traffic would be (or could be made) the same for each work unit, regardless of the size of the work units. Bigger work units are really only a problem for clients that are turned off and on regularly. They client still only needs to keep track of current state (current key in the case of RC5), the final state of the work unit (last key to check for RC5) and the current checksum for the work unit. None of these change in memory requirements as you increase work unit sizes. 99% of the people don't know the work unit size anyway, so changing the work unit size won't cause many people to complain, particularly if it's necessary to keep dnet hosted.
Unless I'm mistaken, the server really only needs to send the client a brief prefix identifying the message as a work unit, followed by "start" and "stop" points for the computation. For RC5, this would mean a 64-bit starting key and a 64-bit ending key. I haven't sat down and worked out the cannocalization scheme for GRs, but it seems that they are countable (in the combinatorics sense, not the kindergarten sense) and could be represented fairly compactly. The current minimum ruler length need not be sent, snce you'd probably always want the client to send back the minimum ruler length in it' work unit anyway. The client would need to send back a work unit identifier (this could be left out, but it's not strictly safe) and an MD5 sum of all of the computational results or some other way to compare results when they duplicate work units. (A certain percentage of the work units are actually sent tomultiple clients in order to check that everyone is playing fairly.)
To me, it sounded like you were using a fixed slat to gnerate your authenicators from passwords, and you somehow needed the salt kept secret.
The only issue with Kerberos is that you MUST have secure passwords. I know plenty of MIT students with bad passwords who think their kerberized telnet sessions are secure.
Too bad they don't have well analyzed systems of DH group exchange encrypted with the user's str_to_key(passwd) and the kerberos ticket encrypted with the DH negotiated key. That would hel prevnt problems with sniffing encrypted tickets and performing offline attacks against bad passwords. (You could still perform attacks against bad passwords, but you would force them to be active attacks.)
My housemate bareley missed the semifinals (and a gauranteed $1000). He's gotten several phone calls from very interested recruiters in the past three weeks. I think his rank is currently between 25 and 30 out of some 10,000.
If you're up there, there are companies looking to hire you. They seem like good companies too, really interesting work. Unfortunately, most of them want to hire immediately instead of waiting until June when he has his Master's.
Every contest has it flaws, but I think TopCoder is pretty good at keeping my Java skills up. I tend to do all of my personal programming in C/C++, so I forget my Java-isms. It also teaches me some practical Java stuff that you don't learn in books. I was suprised as hell that Java lets you add and subract from character literals, for instance.
Most of the harder problems require dynamic programming to keep you from exhausting the JVM's memory or exeeding the 8 second time limit imposed to prevent infinate loops.
MD5 is not an encryption scheme, and besides, if someone rooted slashdot it would be exceptionally easy to find anyones passwords out anyway. Expire logins, put a mailto: on the login, wait and have the passwords mailed to a disposable email address.
And SHA-1, that works great as long as your keyset isn't compromised. We're using SHA-1 at the company I work with, and using a rather obscure private/public keyset - it can't be random because it must be synched amongst a set of boxes, so it has to be calculated and predictable. However, someone would have to look at the code, and have root access to the box in order to crack the keyset. I think that's pretty secure, but it can be broken.
Off topic, but I'm intrigued. Are you saying that your company uses a single, fixed key for salting and hashing passwords for authentication, and the system relies on the key being kept secret? This sounds worse than windows networking authentication! For the love of Athena, use Kerberos or a mutually authenticated SSL system. Usually home-brew == brain-dead. There are ways to use hashes for zero-knowledge proofs, but this doesn't sound like one of them. It sounds like you're wide open to a blackhat replaying authenticators.
Has anyone analysed your system? You seem to imply that you think SHA-1 is an encryption method. SHA-1 and MD5 are both hash algorithms, which can be used as primites in a vast array of applications, including the basis for block or stream ciphers. However, your statements seem troubling. There are libraries for doing almost anything securely. The simplest to use would probably be SLL, and if you're really starved for CPU power, you can use authenticated but unencrypted SSL traffic.
Sorry, I'm just skeptical by nature. I'd love to see someone post mpeg ahowing current draw and a force scale measureing thrust. Maybe the current draw makes them impractical for deep space probes, but you'd think they'd make small lifters just to use up the extra current they're not using when they've got spare power production from their unthrottleable radioactive decay power sources.
I'm not calling you a liar, it just takes a lot to convince me. Sometimes it's one of my greatest strengths and sometimes it's one of my greatest faults.
I would love to be stumped and dumbfounded by one of these. Which polarity is more efficient?
Maybe the guys will bring a working model to the next 2600 meeting. I think they'v kinda given up on the ant-gravity machine, though, and are working on a zero-point energy device. No, I'm not making fun of you. These guys really were going to try to put together a perpetual motion machine.
the experiments on the website i looked at, certainly couldnt lift the weight of thoose power supplies and be self contained. so unless it scales really well...
i assume you plan on sending your interstellar probes out connected to the world longest extension cord?;)
Ehh... your reasoning is correct... if you're going to have 1 g acceleration all the way to Alpha Centauri. Think a little more. Satelites can't get themselves of the ground. I wasn't suggesting that they'd be using lifters as booster rockets, only as long-term acceleration for most of the journey.
I wasn't suggesting getting it to escape velocity using these things. You'd use chemical rockets to get it out of this gravity well we call home. 100 kg for an unshielded Thorium or Plutonium reactor will get you a fair ammount of power, leaving 400 kg for other stuff. You might want a small chemical rocket "bus" with solar cells for high thrust durring gravity asists inside the solar system, but you'd prbably do a sustained burn to get every last Joule out of your fuel, use the miniscule power you're getting from the slar cells to bring the reactor online, and then jettison the bus with it's empty fule tanks, useless cheical rockets and useless photovoltaic cells.
Anyway, my whole point is that these things would seem to have an absolutely fantastic power/weight/fuel ratio when coupled with unshielded reactors and used for multi-year accelerations.
Iit was just a jab at a fanciful satelite design. THere are probably many flaws in what I threw out there, but the weight of the power supply srely isn't one of them. Remember, I estimated the weight of the satelite at 1,100 pounds. It would be impractical to recieve radio commands from 10 light years away on a spacecraft traveling at.9c, so you'd do without a recieve and onlyhavea transmitter... etc., etc. you fill in the blanks. Something along those lines would be feasable ifthese things were for real. Trust me. Maybe the estimates are off by a factor of 50, but that's still performance that chemical rockets can't come close to touching. My claim is simply that these things claim to be too irresistable for NASA to pass up, and NASA has a patent on them... so why aren't they being used. Take of the tin foil hat and put out the crack pipe before you tell me that we secretly have space probes on their way to Alpha Centauri right now.
I've been in person to talks on resistogets, arcjets, and ion thrusters put on by NASA. I've held a prototype NASA ion thruster at the Experimental Aircraft Association annual airshow. NASA wouldn't be wasting their time with ion thruster technology if these fliers worked as advertised. An ion thruster won't come close to lifting itself off the ground, even if you put it in a vacuum and externally supply power and fuel. These things would completely replace ion thrusters if they were for real.
They tried making one at PumpConn (sp?) in Philly this year. They said it didn't fly, but moved arround on the table a little.
My best guess is that the demmo they saw had a hidden wire in one of the supports for the upper electrode. The wire would then be couled inside the lower electrode place before finally being electrically connected to the lower plate. This would make a hidden electromagnet to repel the hidden eectromagnet in the table or whatever it was teathered to.
If the NASA patented device actually produced enough thrust to lift one ot these things off the ground, they'd be in every satelite. The guy in france claims to left four nuts... that's what, 100g? The entire thing must way what, 1 kg. Assume NASA can make them 1.5 times as good for 1,000 times the cost. That's 15 N (1.5 kg * 10 m/s^2) of thrust indefinately and cheaper than a small rocet motor. Put 100 of them on a small satelite and you've got constant 1,500 kN of thrust. Anyone have an eastimate for the atmosperic drag (yes, there is drag, even in outer space, it's just miniscule when the molecules average 1 m appart) and solar wind forces on a small satelite? IIRC, propellant is usually the limiting factor on satlite life. If it only cost them a little bit of money to counteract drag and solar wind indefinately, they'd go for it.
Also, think about interstellar probes. If they made a small 500 kg interstellar probe, 1.5 kN would give them 3 m/s^2 acceleration. That's 94,608,000 m/s/y. That's.1c per year. relativistic affects aren't noticable until over.9 c, so you'd be at 0.9 times thespeed of light and accelerating after only 9 years. Of course, to communicate with Earth, you'd probably want t use infrared lasers or something to communicate with earth so that you get reasonable bandwidth after the dopler shirts up arround 0.98 c.
The point is that we'd have a cheap, high speed probe on its way to Alpha Centauri reight now if the NASA patented devices had anywhere near the thrust these thing claim to have.
P.S. Ladies and gentlemen that plan on reproducing, please invest in some lead gonad shields if you're going to be playing with 60 kV power supplies. I'd have to dig out my solid state chem book from freshman year, but I think you're starting to get low ammounts of X-rays being given off from the low ammounts of streaming electrons at those voltages. It'sprobably not statistically significant until one of you starts sleeping next to one of these experiments for a few years, but I wouldn't put it past some of you.. It's all fun and games until someone bears a mutant.
There's some government-assisted prior art that goes much much further back in time...
IBM had a nice system tht encrypted all of it's traffic between the terminal and mainframe using lucifer. Rekeying was done periodically by encrypting the rekeying message and new key with a special key unique to that terminal. IBM wanted help improving lucifer, so they asked the NSA for help. The NSA said "sure, as long as as the end result's intellectual property is released to the public domain" The NSA took lucifer,,, shortened the keyspace to 56 bits but appearenty maximally strengthened it against all of the shortcut attacks they knew of at the time (differential cryptanalysis). The result was called DES. So there's prior art older than DES. The newer version of the iBM system employing DES (and newer versions allow for 3DES) in most, if not all, bank automatic teller machines.
Off topic:
The end result of the NSA involvement is that it was much harder for mathemeticians to discover shortcut attacks to allow random blackhats to crack DES, while still allowing big budgeted governments to build specialized crackers or run cracking on several massive vector machines, like CRAYs.
Speaking of DES, has anyone seen optimal boolean functions for the DES s-boxes? I'd like to implement DES "sideways", putting each bit of the message in a different register. You can then run 32 (or 64, if you're lucky enough to have a 64-bit CPU) encryptions in parallel. This is much faster since DES does things like uplicating and swapping individual bits, which takes zero time in hardware, but kills the standard way of implementing DES in software gets killed by these little bit duplications and swaps. If you run DES sideways (and 32- or 64-way parallel), duplicating bits simply means usng the same register variable twice, and swapping bits means chaging the positions of varaiables in your equations. You lose some latencey for an individual encryption, but your throughput is potentially multiplied several times. (This depends alot on how compactly you can represent the s-boxes as boolean functions.) This isn't applicable to CBC-mode encryption, but it is usefull for ECB, counter, OCB, and other parallelizable encryption modes. It's also applicable to cracking any of the encryption modes, even OFB, CFB, and CBC.
I'm comming from the point of view that copyrights are valid. You may disagree, but you have to agree that Senators will listen to you beter if you come across as strongly pro-copyright but against this bill. Contact your reps and talk with them about this.
By the way, if any fo you are in the 4th Congressional district of Massachuesetts, please vote to re-elect Barny Frank when the time comes. I wrote him about the DMCA and Dmitry and his reply really impressed me. His priorities may not align perfectly with most of yours, but he strongly indicates that he knows what his priorities are and really thinks about the issues. In the end, this is what makes a politician that isn't fooled by complicated legislation. This is much better than a poilitician who completely agrees with you, but is swayed into voting for things with really bad coonsequences.
Next week is Spring break for MIT. Guess who's going to be making some calls? These are some of the points I'll stress to my reps.:
Copyright infringement is already illegal. This is basically analogous to laws requiring auto makers to limit cars to 65 MPH to prevent speeding. Sure there are cases where it's legal to go faster, but there are also some cases where the DRM software will not allow fair use. Computers simply aren't smart enough to figure it out. Current laws are sufficient.
There are better ways to fight copyright infringement. (Always call it copyright infringement, that'swhat it is. Associating it with terrorism on the high seas is an industry tactic to make it sound worse.) Technological fixes for sociological problems rearely work. When the government thought drunkeness was a huge threat, they started prohibition instead of sponsoring AA and and better encoforcing laws on drunk driving, domestic abuse, and the other real problems. This was a huge disaster. This is a similar case. Copyingisn't the real issue, just as alcohol wasn't the real issue. The real issue here is copyright infringemet. Tell your senators that you're in favor of fighting copyright infringement, but this is the wrong way to go about it. More funding for computer crimes investigation seems a good place to start. Instead of giving the FBI more laws to try and learn and enforce, give them more money to do enforc the current laws. The current laws are sufficient. Current enforcement is not sufficient.
This will increase profit margins for the big-scale providers of illegal copies of movies and such. There is not one example of content protection that has ever come close to preventing illegal copying. The large copying rings in Asia will surely have a larger incentive to put manpower into breaking DRM schemes because breaking them on US hardware and software will be much harder. On top of this, this bill will divert some efforts from tracing down copyright infringers to enforcing the provisions of this bill.
The net result is better incentive for copyright infringement overseas, which is wher most video copyright infringement happens anyway.
You're limiting consumers because DRM limits will always go on the safe side and limit fair use to avoid lawsuits from content providers.
This will kill internet performance. AOL (and many other ISPs) get away with much less badwidth to the outside world becuase they use web caching (and there is a lot of content hosted inside the AOL network, but that's beside the point). If they're forced to do validation on all of their content, it will mean much more traffic to the outside world, or at the very least, a huge inrease in CPU load on the internal caching proxies. If they kill internet performance, the modem will no longer be the bottleneck, so fewer people will buy broadband. This bill won't help broadband, it's sole purpose is to minimize piracy and fair use, both of which the movie industry hates. Look at the lawsuit they brought out against VCRs.
There are some realy cheap TV cards for computers. This bill would make it illegal to use a program to turn your computer into a VCR. If your VCR contains an embedded CPU (most do nowadays), then this would probably make your VCR illegal to manufacture one year after the bill passes. Does your Sentator want to go on the record for trying to outlaw software VCRs and maybe all modern VCRs? Depending on final wording, this may also apply to most fax machines and the newest photocoppiers, which transform (often copyrighted works) into a digital form and then intentionally duplicate them without protection.
The Movie Industry (one of Hollings's biggest contributors) tried to outlaw VCRs, claiming they would be ruined by VCRs. Only a Supreme Court vote of 5-4 saved teh VCR. Today, the movie industry makes nearly half it's profit from home viewing. The movie industry is too short sightd to look out for its own best interests. This encourages them to stay stuck in an anciet business model instead of encouraging them to create novel new industries. Had the movie industry gone ahead and worked with new technology (the VCR) from the beginning, they could have made a killing from the get-go on movie rentals. Sure there's some piracy on VHS and DVD, but informaed and sufficiently funded law enforcement has kept this to a minumum while the unencumbered technology has enhanced the experience of the American public.
This law may not be constitutional, as it may make publishing source code illegal. There are many harmful and uninteded ramifications of this bill.
Don't run for the hills quite yet, (unless you're using MSPassport or some other system that gives up all the goods with a cookie compromise).
This does not affect your filesystem integrity or directly affect the securty of the localhost. It allows an applet to haijack your HTTP Proxy connection (if you have one) and make arbitrary netweork connections if you already have a proxy set up.
As far aas I can tell:
vulnerable assets
CPU cycles
Bandwidth
??Cookies??
?? non-certificate-based SSL connections ??
They can always steal CPU cycles if you allow them to run applets.
They can use this to create a distributed mirrr if their Evil Content (TM)
or do a DDoS. If this allows them to fool the browser into connecting to the wrong site, then SSL connections without VeriSign or other pre-downloaded certificates will be vulnerable, as will all of your cookies.
DDoS and SSL connection spoofing are the only tings likely to be
large-scale problems if they are even possible at all with this exploit.
Speaking of cookies, don't give Passport your credit card number. I took Rivest's network security class at MIT last term. One group's final project was analyzing several cookie-based authentication systems. It turns out that MS lies about their implementation. The design calls for site-specific cookies, similar to broken kerberos tickets. It turns out that at least at that time, passport was issuing identical cookies for different sites. This means if you buy a $2 pair of socks from PassportClothes.com and someone steals your cookies for that site, they can authnticate themselves to PassportComputers.com and order computers. Sure they may only ship to your address, but the ocial engineering to change the shipping adress while the package is in transit isn't too tough. They could also but themselves a lifetime membership to PassportEBookOfTheMinute.com, all becuase you bought a pair of socks. If MS stuck to their design, the blackhots could only pretend to be you at PassportClothes.com and would be limited to buying casmir sweaters and leather jackets. Of course, MS could have further entrenched I.E. by implementing something sniff proof that used kerberos ticets or piblic key signatures (short durration Verisign-like certs), but they chose to use cookies in order to make adoption easier. Adoption wouldn't be any harder if they ued short-durration MS-signed certificates for mutually authenticated SLL connections. Oh well. It's not like we expected them to get it right until their fifth try anyway.
My best guess is that they ping and traceroute about 500 sights arround the world and email the response to you. There are srvices that use ping times from a few different servers to geographically locate a given IP. Of course, IPtunneling totally screws this up, so if they dial up AOL long distance from a phreaked phoneline, you've got the FBI on the wrong half of the globe looking for your computer. Then again, 99.5% of most criminals don't even wipe the HD after stealing a laptop.
Maybe it resides in the boot sector. fdisk and format don't touch the mbr without the \mbr flag. Depending on the low-level format, it might not touch the MBR either. If nothing else, most modern OSes don't use the BIOS for much, so you could put it all in a minimalistic BIOS. A driver for one ethernet card and one internal modem wouldn't need to be very big, and it doesn't need a whole network stack... just enough to do ICMP echo and TCP, or else send the data hidden in specially formatted ICMP echo packets to company headquarters, from which the email is actualy sent via TCP.
Of course, implementing this in a Curusoe laptop would be trivial if you got enough cooperation from Transmetta to have them compile your source and have it run in its own thread in the code morphing layer. And then they could provideyou with a firmware update floppy or something for your customers. They get to keep their codea secret and you get a virtually undetectable "silend alarm"... most firewalls let ICMP echo packets through without logging.
I had went and dug up some links, but Netscape caught a bus error (Netscape for Solaris is especially buggy) and I lost the entire post. Here's most of the post without the links.
One thing I forgot to mention about microkernels is that almost all of them communicate with the kernel and other processes via message passing. Messages encapsulate in network packets much more transparently than direct function calls or system interupts. This means that network transparency is much easier for microkernel architectures.
Check out L4Ka.org. Some of the L4 design papers, as well as "Hazelnut" L4 that I play with. They also have links to Linux 2.2.20 ported to run as an L4 task. I tried runnin L4Linux as my OS for a day. It locked up twice in 12 hours. However, it was an old version of Hazelnut and an old version of the glinux server. The "fiasco" L4 implementation is also pretty famous and is linked to from the l4ka site. Newer L4 implementations use something called lazy context switching to dramatically speed context switches between tasks that don't have large virtual memory requirements. (By default, Hazelnut uses lazy context switching if the two processes use fewer than 128 MB.) The GNU website has a pgae on L4-HURD, but the new L4 API hasn't been finalized, and the API for the Virtual Kernel isn't set, so it'll be a while before you see much HURD code ported to the Virtual Kernel or see a trnslation layer between teh Virtual Kernel and L4. Basically, the L4 people don't want it to be such a pain to port HURD to other kernels, so they decided to port it to some reasonable "Virtual Kernel" and make translation layers for all of the kernels the hURD will run on.
I like EROS, an OS that uses a microkernel design to complement it's capability-based security model.
GNU mach, like other Mach implementations, suffers from feature bloat. Unless you have a really good reason, you shouldn't add a feature whose functionality can be achieved through using the features you already have. Mach basically tries to be a swiss army knife of a microkernel and ends up being very large.
RTLinux uses a realtime microkernel and runs something like UserMode Linux (UML) on the side.
The realtime kernel doesn't provide any of the services provided by the Linux kernel (at least that's what the design whitepaper says).
AtheOS is a microkernel architecture with the networking stack merged into the kernel. The AtheOS kernel is written by a former Be engineer. I believe I read somewhere that BlueOS (or was it another free BeOS clone?) was going to use the AtheOS kernel.
The QNX website used to have a good overview of their microkernel architecture. QNX is marketed as a very reliable embedded microkernel that is suitable for sattelites and other mission-critical applications. On the desktop, it shows some nice network transparency. (Ever seen part of your window displayed on one machine's monitor and part on another machine's monitor while the app is actaully executing on a third? It's X-windows on steroids.)
There are many other microkernel OSes. VSTa is a copyleft microkernel OS that sometimes gets press. I believe the embedded realtime OS VXworks uses a microkernel.
V2OS is supposedly based on the "exokernel" idea. Right now I don't think it multitasks or provides any memory protection. It's pretty much a toy OS that they try to write entirely in x86 assembly. It uses self-writing object code, so I couldn't get VMware 2.0.4 to boot it. They appearently have implemented some basic C libraries since I last played with V2OS.
Then there's the XBox megakernel where the entire game is the kernel so that you get zero context switches durring gameplay. I think that you even need to statically link all the game libraries. This is completely the oposite approach from microkernels.
First off, why a microkernel? Remember, the huge stink over Linus changing the memory manger out from under the kernel somewher around 2.4.4? In many microkernels, the memory manager is a userland server. Changing memory managers is in essence no dfferent from changing from Apache to Tomcat. You like the other memory maager? Okay, no need to patch, just have an option in the bootloader or init script to run a different memory manager. The same thing goes for the scheduler. You could even conceivably swap schdulers on the fly to give better response when a user is logged in and give better agregate thoughput when all users are logged out. Maybe Apaache would come with its own scheduler optimized for webserving. The modern L4 microkernel implements recursive memory management and scheduling. This means youcan have different memory management and scheduling on a per-task basis.
The Hurd is really just like WINE except that it pretends to be a monolithic UNIX system instead of pretending to be a Win32 system. The HURD is currently ported only to Gnumach, but this may change. Darwin refers to both the Berkley UNIX translation layer and the underlying microkernel.
Imagine the ugliness of moving parts of XFree into the kernel. WinNT/XP and Darwin move parts of the video subsystem into the kernel for performance reasons. NT set out to be a true microkernel, and perhapse NeXT started with this goal as well. The HURD doesn't move any of the server code into the kernel. The HURD on Gnumach follows a clean microkernel/sever seperation. Mach is a beast of a microkernel, but in essence the system is a much more pure microkernel. Your video driver goes beserk (supposedly the cuase of most NT/XP bluescreens nowadays) and all you have to do is restart the video server. Maybe you have a watchdog server running to restart essential servers that go kaput.
Of course, there's also the liscence issue for liscence bigots. You can get Darwin's source, but IIRC, you can't redistribute changes you make. I think everyone here will gree that this is less of a Good Thing than GPL or BSD liscenced kernel code.
As for me, I'm a design bigot. Gnumach is more of the Right Way to do Mach, but it's still the beast that is Mach. Bonus points for being a microkernel, but Linux is still more elegant (as are the *BSD kernels). UNIX monolithic kernels do a pretty good job of providng a minimum numberof orthogonal services and primitives that can be well tested and well understood. This is one principle of good design. Mach has over 100 system calls implementing all kinds of non-orthogonal services and primitives. Darwin refers to Mach and the BSD userland personality tranlator designed for Mach. HURD is just the userspace POSIX translator that was supposedly designed to be microkernel agnostic, so you could easily port it to a different microkernel and have HURD running on QNX or RtLinux, or even a monolithic *BSD or Linux kernel. There are efforts to port the HURD to the L4 microkernel. They've discovered that the HURD as presently implemented is highly dependant on certain aspects of Mach. They're debating rewriting the HURD from scratch becase of all of the Mach dependancies. It looks like they'll try and port the HURD to a "Virtual Kernel" and then have a thin library that gets linked in to wrap the VK calls and translate for the actual kernel (and perhapse a few userland servers, depending on exactly how the VK and actual microkernel break up kernel and server functionality.)
If the L4-HURD people suceed, you might actually see the HURD outperform *BSD, Linux, et. al. Microkernels have inherently worse agregate throughput due to the increased coontext switching. However, some L4 implementations cheat and put several tasks in the same address space and simply change the read-write permissions on memory pages instead of actually switching contexts (and flushing the TLB) between tasks. This is called lazy context switching and may actually allow L4 to outperform all of the kernels that use conventional context switching. Of course, the monolithic kernels could also use lazy context switchng, but they are harder to modify. I have a copy of L4 on my machine that is only 49,847 bytes large. About half of that has tobe machine-specific code, so often times it's easier to rewrite L4 from scratch when "porting" to another architecture. After all, there's probably more than 50k of object code that changes between releases of the Linux kernel.
People get confused and claim that Darwin is something of a NetBSD kernel or FreeBSD kernel merged with mach. The kernel has a userland personality that translates Berkley UNIX (BSD) systm calls to mach system calls. There's not really any NetBSD or FreeBSD code in the kernel as far as I know. The kerel is basically the NeXT kernel and BSD 4.3 personality server ported from m68k to PPC and an update to BSD 4.4 personality.
The NetBSD and FreeBSD connection comes from the userland utilities. Originally, most of the userland utilities were ported from NetBSD, but now Apple has snagged one of the main FreeBSD developers, so the userland is becomming more like FreeBSD.
MCL doesn't make a distro, they do clustering and remote management stuff.
When I interviewed for an intership with them a couple of years ago, the main thing they seemed to be pushing were some encrypted, authenticated, remote admin GUI tools. IIRC, they gave away their remote admin tools and kernel dump analysis tools. They would basically admin your servers for you for a fee. Sssseemed like a pretty good businessmodel at the time, but Linux admins have become cheaper and Linux adinistration has become easier in the past couple of years.
However, I'm suprised they weren't able to market themselves to medium to large size businesses. 24-hour competant server management is hard to find and expensive. Iif you out-source it, you can effectively cost-share the admins during off hours. I guess nobody wanted to pay the premium for the difference between garunteed uptime and standard Linux uptime.
Plan 9 and Inferno are examples of people doing things the right wayinstead of the easy way. They looked at UNIX and its problems and set out to fix them.
I've read a few papers. Some of the features I attribute to Plan 9 may have also carried over to Inferno.
Private namespaces -> Inferno gives each user/app a private namespace. If you're not allowed to see a file, it'not in your namespace, so there's no way you can even ask to see it. This is a good example of capabilities-based security. This is lightyears past the MS-DOS idea of each disk partition or network share being painfully appearant to the user.
JIT optimized VM -> DIS, the Inferno VM, is based on a memory machine instead of a stack machine (a la Java and CLR/Mono). This allows for more efficient register allocation durring just-in-time compililation. Stack machines are great for writng smpleinterpreters with small memory footprints. Memoery machines are great for easily recompiling into fast native code. If I could, I'd start on an Open Source VM based on DIS. Toasters are great, but I don't want a crippled VM just so that it's easy to run on an 8-bit microprocessor in a toaster. You guys running SPARC, MIPS, POWER, PPC, IA64, etc. CPUs should notice the performance advantags of DIS more than us poor x86 users because the x86 is pretty register starved.)
Distributed resources -> in Plan 9, there is a crippled user account without a password that pretty much can't doanything but present cryptographic credentials that prove it's doing work on behalf of a priveledged user. This would allow your dnet client to run on your CPU farm, but not actually be able to log in as you if it got compromised. As far as I can tell, the system is very similar to Kerberos with more types ofcredentials and tickets that never expire. I don't like the lack of ticket expiration , but it's better security than almost anything else out there. Most Beowulf implementations use rsh for performance, so you need to isolate the Beowulf compute nodes from anything remotely hostile, since rsh gives you a root prompt without a password based on the source TCP port number.
As soon as some of the large ISPs realize that they can turn IPv6 into marketing drivel, they'll start upgrading their internal networks. The winds of change will first rustle in your television. Joe Sixpack doesn't know what Ipv6 is, but he doesn't want to get left behind.
I confess I've looked at the Aple support sight, but haven't dug too deeply. Can the "Classic" emulation layer now wrap drivers and expose them as Darwin drivers?
When I was home for Christmas, I noticed that Mom had an unopened OSX box on her shelf. She didn't know she had it. She's the kind of person that still asks me about "memory" when she means to talk about HD space and it seems that OSX would protect her from herself much better than OS 9.1 does. The only problem is that HP doesn't have printer drivers for her printer under OS X. She would get extremely confused if some apps could use the printer but others gave her error messages.
I end up solving printer issues for her every few months. Last time, I had to talk her though downloading and reinstallilng the printer drivers over the phone. (Thank God she has a second line for the modem.) Over Christmas, it was a cable that had giggled itself loose, but almost everything else seems to have been either stability or protection issues with OS 9.
BTW, those Apple guys are masters of (relatively) seamless transitions off of legacy Hardware/Software/APIs. I wish things were so good for things I can afford on my student budget. Maybe CLR/Mono will do better than Java for this problem, although I think we're going to start seeing legacy VMs being a problem. Anyone working on coding up a good java JIT to run under Mono or a bytecode cross compiler from JVM to CLR?
I think that instead of devising ways to destroy damaging emails that you send we should instead focus on not sending damaging emails. Bill Gates sent out memos that the DOJ is now using against him. That'll teach him. If you have something that important to say it's probably best said in person.
I think we should concentrate on writing invulnerable clients and servers instead of wastng all this effort on designing anddeploying firewalls. Ideally each machine, each OS, each client, and each server would be bulletproof so you shouldn't need firewalls.
Unfortunately, the world isn't perfect. Flaws will creap into software and emails. Shredding emails reduce damage from bad email writers just like firewalls minimize damage from bad software designers/coders.
Also, it's not a matter of concentrating on this or that. Your company should educate their own people about safe email practices. These people devising email shredding schemes don't waste the energy of YOUR company. These cryptographers and coders wouldn't do much good if instead of working in their cubicles, they came over to your company and lectured everyone on good emal practices. It's called division of labor. Do what you're good at and pay others to do what you aren't good at. They're good at cryptography and coding, your managers and corporate educators are much better at getting things through your employees heads. These cryptographers and coders aren't wasting energy any more than you're wasting energy at your job instead of working on an AIDS vaccine/cure for cancer/eliminating hunger/whatever people feel the most pressing NEEDS of mankind are.
All you P2P advocates (and yes that includes me) had better quit programming P2P platforms and get on your lawyer-faggot wigs because in less than 24 months, Microsoft's DRM will be COMPULSORY on all new computers, and then some.
Tell your local member of parliament you think this fucking stinks. Or bye-bye P2P, scalable or not.
----BEGIN divergence from topic
Haha! In the good 'ole US of A we kicked out thy tyrats and their tyranical parlimentary system! The American bicameral system and electoral college provide a much better form of abstraction, indirection, and power balance in order to minimize the influence of special interests and big money. The founding fathers were true visionaries and foresaw the problems the Europeans are having.
As recent events will show, we Americans could never... oh wait, sorry, I was sleep-typing again. It appears to have been a rather good and almost realistic dream. Such a shame I woke up. Maybe I should get myself some extra strongcoffee and pay extra close attention next election instead of sleep-voting again. If nobody votes with a clue, how is congress supposed to get a clue... This is representative government, remember?
Seriously, if you start voting with a clue, and cluing your neighbors in and actively helping with campaigns you beieve in, then the system will work coser to the way the founding fathers intended. THe system was designed for a bunch of riled up revolutionary citizens, not the bunch of apathetic winers we've become. (Yes, I have volunteared my time with a political campaign and I have written my congresscritters and I have ubmitted an opinion on the MSFT case.) You can't expect the legislature to have a clue unless you personally have done something to clue in the voters. It's that simple. Wasting my time doing something is better than doing nothing.
----END divergence from topic
I wish DRM circumvention wasn't driven by greed in most citizens, but it still represents some sort of civil disobedience in the same way that visiting speakeaseys durring prohibition. Writing P2P systems and using them shaws congresscritters in some sall way how we feel about DRM legislation. I just wish it was a more altruistic demostration.
Yes, I do realize that the poster's choice of language appears to place him/her on my side of the "big pond".
And how would that work, anyway, with PGP? A passphrase usually unlocks only a private key, which, erm, we don't have, as far as I know.
Symetrically encrypted messages. An md5 sum of the passphrase is ussed to encrypt the session key and this is symetrically encrypted session key is sent just like an asymetricically encrypted session key at the beginning of the message.(Hopefully the session key encryption uses the same cipher as the message. Failing that 3DES. but it's been a little while since I've read the OpenPGP spec.)
Ooops! I implied my conclusion butdidn't state it.
The conslusion is that the way OSS is developed means that code on average ends up being more easily audited. So maybe the many eyes aren't doing the auditing, but the many eyes (and mailing list readers/question askers) are making the code easier to audit for those who do audit the code. More effective audits mean better code.
People are embarassed to publish spagetti code (for serious projects at least).
Furthermore, source code and plain text emails are the only way many OSS projects communicate. This means that if any work is going to get done, the code needs to be much more legible than if coder A can just run over to coder B's cubicle if he can't understand the code. This also promotes a high degree of modularization, due to decreased communication bandwidth/increased latency between developers.
The large number of non-code-submitting members of OSS project mailing lists is also a huge plus. Many people to explain things to that haven't worked with the code since the beginning of time means that the coders need to teach others about the code. Teaching is one of the best ways of learning!
Peopple say that Microsoft must have really good coding practices to be so sucessfull. This isn't necessarily the case. I have a friend that interned for Microsoft and he was telling me about the infomal tutorial he got on Windows internals. The reason power management improved vastly between Win95 and WinME but remained basically unchanged between NT4 and Win2K was that the main guy who wrote the NT4 power managaeent code left and so they could make little tweaks, but they couldn't read the code well enough in a larger sense to make any drastic changes and predict the results.
Good idea but sort of self-defeating. The shortest connection between two sites that can be analized by that means is, of course, Google.
You forget that hyperlinks are unidirectional, so this would be the case if the sites both had links back to google.
Slashdot Mirror
Thier site is popular enoug that it would seem to be a good time to experiment with moving the http stuff to freenet, since it's only updated once per day. The people willing to download the dnet client are would seem to be some of the most willing people to download the freenet client. Freenet is designed so that the slashdot effect actually increases reliability and speed of acess for the commonly requested data. Distributed.net would seem to have reached a critical mass of readership in order to have reasonable reliability for its freenet page. Your could have the client get your team and individual scores sent to it as part of the block submission cinfirmation.
It would seem to me that they could arbitrarily reduce their bandwidth requirements by increasing the minimum size of keyspace portions they're handing out. It would seem that thier project traffic would be (or could be made) the same for each work unit, regardless of the size of the work units. Bigger work units are really only a problem for clients that are turned off and on regularly. They client still only needs to keep track of current state (current key in the case of RC5), the final state of the work unit (last key to check for RC5) and the current checksum for the work unit. None of these change in memory requirements as you increase work unit sizes. 99% of the people don't know the work unit size anyway, so changing the work unit size won't cause many people to complain, particularly if it's necessary to keep dnet hosted.
Unless I'm mistaken, the server really only needs to send the client a brief prefix identifying the message as a work unit, followed by "start" and "stop" points for the computation. For RC5, this would mean a 64-bit starting key and a 64-bit ending key. I haven't sat down and worked out the cannocalization scheme for GRs, but it seems that they are countable (in the combinatorics sense, not the kindergarten sense) and could be represented fairly compactly. The current minimum ruler length need not be sent, snce you'd probably always want the client to send back the minimum ruler length in it' work unit anyway. The client would need to send back a work unit identifier (this could be left out, but it's not strictly safe) and an MD5 sum of all of the computational results or some other way to compare results when they duplicate work units. (A certain percentage of the work units are actually sent tomultiple clients in order to check that everyone is playing fairly.)
To me, it sounded like you were using a fixed slat to gnerate your authenicators from passwords, and you somehow needed the salt kept secret.
The only issue with Kerberos is that you MUST have secure passwords. I know plenty of MIT students with bad passwords who think their kerberized telnet sessions are secure.
Too bad they don't have well analyzed systems of DH group exchange encrypted with the user's str_to_key(passwd) and the kerberos ticket encrypted with the DH negotiated key. That would hel prevnt problems with sniffing encrypted tickets and performing offline attacks against bad passwords. (You could still perform attacks against bad passwords, but you would force them to be active attacks.)
If you're up there, there are companies looking to hire you. They seem like good companies too, really interesting work. Unfortunately, most of them want to hire immediately instead of waiting until June when he has his Master's.
Every contest has it flaws, but I think TopCoder is pretty good at keeping my Java skills up. I tend to do all of my personal programming in C/C++, so I forget my Java-isms. It also teaches me some practical Java stuff that you don't learn in books. I was suprised as hell that Java lets you add and subract from character literals, for instance.
Most of the harder problems require dynamic programming to keep you from exhausting the JVM's memory or exeeding the 8 second time limit imposed to prevent infinate loops.
And SHA-1, that works great as long as your keyset isn't compromised. We're using SHA-1 at the company I work with, and using a rather obscure private/public keyset - it can't be random because it must be synched amongst a set of boxes, so it has to be calculated and predictable. However, someone would have to look at the code, and have root access to the box in order to crack the keyset. I think that's pretty secure, but it can be broken.
Off topic, but I'm intrigued. Are you saying that your company uses a single, fixed key for salting and hashing passwords for authentication, and the system relies on the key being kept secret? This sounds worse than windows networking authentication! For the love of Athena, use Kerberos or a mutually authenticated SSL system. Usually home-brew == brain-dead. There are ways to use hashes for zero-knowledge proofs, but this doesn't sound like one of them. It sounds like you're wide open to a blackhat replaying authenticators.
Has anyone analysed your system? You seem to imply that you think SHA-1 is an encryption method. SHA-1 and MD5 are both hash algorithms, which can be used as primites in a vast array of applications, including the basis for block or stream ciphers. However, your statements seem troubling. There are libraries for doing almost anything securely. The simplest to use would probably be SLL, and if you're really starved for CPU power, you can use authenticated but unencrypted SSL traffic.
I'm not calling you a liar, it just takes a lot to convince me. Sometimes it's one of my greatest strengths and sometimes it's one of my greatest faults.
I would love to be stumped and dumbfounded by one of these. Which polarity is more efficient? Maybe the guys will bring a working model to the next 2600 meeting. I think they'v kinda given up on the ant-gravity machine, though, and are working on a zero-point energy device. No, I'm not making fun of you. These guys really were going to try to put together a perpetual motion machine.
i assume you plan on sending your interstellar probes out connected to the world longest extension cord? ;)
Ehh... your reasoning is correct... if you're going to have 1 g acceleration all the way to Alpha Centauri. Think a little more. Satelites can't get themselves of the ground. I wasn't suggesting that they'd be using lifters as booster rockets, only as long-term acceleration for most of the journey.
I wasn't suggesting getting it to escape velocity using these things. You'd use chemical rockets to get it out of this gravity well we call home. 100 kg for an unshielded Thorium or Plutonium reactor will get you a fair ammount of power, leaving 400 kg for other stuff. You might want a small chemical rocket "bus" with solar cells for high thrust durring gravity asists inside the solar system, but you'd prbably do a sustained burn to get every last Joule out of your fuel, use the miniscule power you're getting from the slar cells to bring the reactor online, and then jettison the bus with it's empty fule tanks, useless cheical rockets and useless photovoltaic cells.
Anyway, my whole point is that these things would seem to have an absolutely fantastic power/weight/fuel ratio when coupled with unshielded reactors and used for multi-year accelerations.
Iit was just a jab at a fanciful satelite design. THere are probably many flaws in what I threw out there, but the weight of the power supply srely isn't one of them. Remember, I estimated the weight of the satelite at 1,100 pounds. It would be impractical to recieve radio commands from 10 light years away on a spacecraft traveling at .9c, so you'd do without a recieve and onlyhavea transmitter... etc., etc. you fill in the blanks. Something along those lines would be feasable ifthese things were for real. Trust me. Maybe the estimates are off by a factor of 50, but that's still performance that chemical rockets can't come close to touching. My claim is simply that these things claim to be too irresistable for NASA to pass up, and NASA has a patent on them... so why aren't they being used. Take of the tin foil hat and put out the crack pipe before you tell me that we secretly have space probes on their way to Alpha Centauri right now.
I've been in person to talks on resistogets, arcjets, and ion thrusters put on by NASA. I've held a prototype NASA ion thruster at the Experimental Aircraft Association annual airshow. NASA wouldn't be wasting their time with ion thruster technology if these fliers worked as advertised. An ion thruster won't come close to lifting itself off the ground, even if you put it in a vacuum and externally supply power and fuel. These things would completely replace ion thrusters if they were for real.
They tried making one at PumpConn (sp?) in Philly this year. They said it didn't fly, but moved arround on the table a little.
My best guess is that the demmo they saw had a hidden wire in one of the supports for the upper electrode. The wire would then be couled inside the lower electrode place before finally being electrically connected to the lower plate. This would make a hidden electromagnet to repel the hidden eectromagnet in the table or whatever it was teathered to.
If the NASA patented device actually produced enough thrust to lift one ot these things off the ground, they'd be in every satelite. The guy in france claims to left four nuts... that's what, 100g? The entire thing must way what, 1 kg. Assume NASA can make them 1.5 times as good for 1,000 times the cost. That's 15 N (1.5 kg * 10 m/s^2) of thrust indefinately and cheaper than a small rocet motor. Put 100 of them on a small satelite and you've got constant 1,500 kN of thrust. Anyone have an eastimate for the atmosperic drag (yes, there is drag, even in outer space, it's just miniscule when the molecules average 1 m appart) and solar wind forces on a small satelite? IIRC, propellant is usually the limiting factor on satlite life. If it only cost them a little bit of money to counteract drag and solar wind indefinately, they'd go for it.
Also, think about interstellar probes. If they made a small 500 kg interstellar probe, 1.5 kN would give them 3 m/s^2 acceleration. That's 94,608,000 m/s/y. That's .1c per year. relativistic affects aren't noticable until over .9 c, so you'd be at 0.9 times thespeed of light and accelerating after only 9 years. Of course, to communicate with Earth, you'd probably want t use infrared lasers or something to communicate with earth so that you get reasonable bandwidth after the dopler shirts up arround 0.98 c.
The point is that we'd have a cheap, high speed probe on its way to Alpha Centauri reight now if the NASA patented devices had anywhere near the thrust these thing claim to have.
P.S. Ladies and gentlemen that plan on reproducing, please invest in some lead gonad shields if you're going to be playing with 60 kV power supplies. I'd have to dig out my solid state chem book from freshman year, but I think you're starting to get low ammounts of X-rays being given off from the low ammounts of streaming electrons at those voltages. It'sprobably not statistically significant until one of you starts sleeping next to one of these experiments for a few years, but I wouldn't put it past some of you.. It's all fun and games until someone bears a mutant.
IBM had a nice system tht encrypted all of it's traffic between the terminal and mainframe using lucifer. Rekeying was done periodically by encrypting the rekeying message and new key with a special key unique to that terminal. IBM wanted help improving lucifer, so they asked the NSA for help. The NSA said "sure, as long as as the end result's intellectual property is released to the public domain" The NSA took lucifer,,, shortened the keyspace to 56 bits but appearenty maximally strengthened it against all of the shortcut attacks they knew of at the time (differential cryptanalysis). The result was called DES. So there's prior art older than DES. The newer version of the iBM system employing DES (and newer versions allow for 3DES) in most, if not all, bank automatic teller machines.
Off topic:
The end result of the NSA involvement is that it was much harder for mathemeticians to discover shortcut attacks to allow random blackhats to crack DES, while still allowing big budgeted governments to build specialized crackers or run cracking on several massive vector machines, like CRAYs.
Speaking of DES, has anyone seen optimal boolean functions for the DES s-boxes? I'd like to implement DES "sideways", putting each bit of the message in a different register. You can then run 32 (or 64, if you're lucky enough to have a 64-bit CPU) encryptions in parallel. This is much faster since DES does things like uplicating and swapping individual bits, which takes zero time in hardware, but kills the standard way of implementing DES in software gets killed by these little bit duplications and swaps. If you run DES sideways (and 32- or 64-way parallel), duplicating bits simply means usng the same register variable twice, and swapping bits means chaging the positions of varaiables in your equations. You lose some latencey for an individual encryption, but your throughput is potentially multiplied several times. (This depends alot on how compactly you can represent the s-boxes as boolean functions.) This isn't applicable to CBC-mode encryption, but it is usefull for ECB, counter, OCB, and other parallelizable encryption modes. It's also applicable to cracking any of the encryption modes, even OFB, CFB, and CBC.
By the way, if any fo you are in the 4th Congressional district of Massachuesetts, please vote to re-elect Barny Frank when the time comes. I wrote him about the DMCA and Dmitry and his reply really impressed me. His priorities may not align perfectly with most of yours, but he strongly indicates that he knows what his priorities are and really thinks about the issues. In the end, this is what makes a politician that isn't fooled by complicated legislation. This is much better than a poilitician who completely agrees with you, but is swayed into voting for things with really bad coonsequences.
Next week is Spring break for MIT. Guess who's going to be making some calls? These are some of the points I'll stress to my reps.:
This does not affect your filesystem integrity or directly affect the securty of the localhost. It allows an applet to haijack your HTTP Proxy connection (if you have one) and make arbitrary netweork connections if you already have a proxy set up.
As far aas I can tell:
They can always steal CPU cycles if you allow them to run applets. They can use this to create a distributed mirrr if their Evil Content (TM) or do a DDoS. If this allows them to fool the browser into connecting to the wrong site, then SSL connections without VeriSign or other pre-downloaded certificates will be vulnerable, as will all of your cookies.
DDoS and SSL connection spoofing are the only tings likely to be large-scale problems if they are even possible at all with this exploit.
Speaking of cookies, don't give Passport your credit card number. I took Rivest's network security class at MIT last term. One group's final project was analyzing several cookie-based authentication systems. It turns out that MS lies about their implementation. The design calls for site-specific cookies, similar to broken kerberos tickets. It turns out that at least at that time, passport was issuing identical cookies for different sites. This means if you buy a $2 pair of socks from PassportClothes.com and someone steals your cookies for that site, they can authnticate themselves to PassportComputers.com and order computers. Sure they may only ship to your address, but the ocial engineering to change the shipping adress while the package is in transit isn't too tough. They could also but themselves a lifetime membership to PassportEBookOfTheMinute.com, all becuase you bought a pair of socks. If MS stuck to their design, the blackhots could only pretend to be you at PassportClothes.com and would be limited to buying casmir sweaters and leather jackets. Of course, MS could have further entrenched I.E. by implementing something sniff proof that used kerberos ticets or piblic key signatures (short durration Verisign-like certs), but they chose to use cookies in order to make adoption easier. Adoption wouldn't be any harder if they ued short-durration MS-signed certificates for mutually authenticated SLL connections. Oh well. It's not like we expected them to get it right until their fifth try anyway.
Maybe it resides in the boot sector. fdisk and format don't touch the mbr without the \mbr flag. Depending on the low-level format, it might not touch the MBR either. If nothing else, most modern OSes don't use the BIOS for much, so you could put it all in a minimalistic BIOS. A driver for one ethernet card and one internal modem wouldn't need to be very big, and it doesn't need a whole network stack... just enough to do ICMP echo and TCP, or else send the data hidden in specially formatted ICMP echo packets to company headquarters, from which the email is actualy sent via TCP.
Of course, implementing this in a Curusoe laptop would be trivial if you got enough cooperation from Transmetta to have them compile your source and have it run in its own thread in the code morphing layer. And then they could provideyou with a firmware update floppy or something for your customers. They get to keep their codea secret and you get a virtually undetectable "silend alarm"... most firewalls let ICMP echo packets through without logging.
One thing I forgot to mention about microkernels is that almost all of them communicate with the kernel and other processes via message passing. Messages encapsulate in network packets much more transparently than direct function calls or system interupts. This means that network transparency is much easier for microkernel architectures.
Check out L4Ka.org. Some of the L4 design papers, as well as "Hazelnut" L4 that I play with. They also have links to Linux 2.2.20 ported to run as an L4 task. I tried runnin L4Linux as my OS for a day. It locked up twice in 12 hours. However, it was an old version of Hazelnut and an old version of the glinux server. The "fiasco" L4 implementation is also pretty famous and is linked to from the l4ka site. Newer L4 implementations use something called lazy context switching to dramatically speed context switches between tasks that don't have large virtual memory requirements. (By default, Hazelnut uses lazy context switching if the two processes use fewer than 128 MB.) The GNU website has a pgae on L4-HURD, but the new L4 API hasn't been finalized, and the API for the Virtual Kernel isn't set, so it'll be a while before you see much HURD code ported to the Virtual Kernel or see a trnslation layer between teh Virtual Kernel and L4. Basically, the L4 people don't want it to be such a pain to port HURD to other kernels, so they decided to port it to some reasonable "Virtual Kernel" and make translation layers for all of the kernels the hURD will run on.
I like EROS, an OS that uses a microkernel design to complement it's capability-based security model.
GNU mach, like other Mach implementations, suffers from feature bloat. Unless you have a really good reason, you shouldn't add a feature whose functionality can be achieved through using the features you already have. Mach basically tries to be a swiss army knife of a microkernel and ends up being very large.
RTLinux uses a realtime microkernel and runs something like UserMode Linux (UML) on the side. The realtime kernel doesn't provide any of the services provided by the Linux kernel (at least that's what the design whitepaper says).
AtheOS is a microkernel architecture with the networking stack merged into the kernel. The AtheOS kernel is written by a former Be engineer. I believe I read somewhere that BlueOS (or was it another free BeOS clone?) was going to use the AtheOS kernel.
The QNX website used to have a good overview of their microkernel architecture. QNX is marketed as a very reliable embedded microkernel that is suitable for sattelites and other mission-critical applications. On the desktop, it shows some nice network transparency. (Ever seen part of your window displayed on one machine's monitor and part on another machine's monitor while the app is actaully executing on a third? It's X-windows on steroids.)
There are many other microkernel OSes. VSTa is a copyleft microkernel OS that sometimes gets press. I believe the embedded realtime OS VXworks uses a microkernel.
V2OS is supposedly based on the "exokernel" idea. Right now I don't think it multitasks or provides any memory protection. It's pretty much a toy OS that they try to write entirely in x86 assembly. It uses self-writing object code, so I couldn't get VMware 2.0.4 to boot it. They appearently have implemented some basic C libraries since I last played with V2OS.
Then there's the XBox megakernel where the entire game is the kernel so that you get zero context switches durring gameplay. I think that you even need to statically link all the game libraries. This is completely the oposite approach from microkernels.
Marcus is one of the head HURD developers.
The Hurd is really just like WINE except that it pretends to be a monolithic UNIX system instead of pretending to be a Win32 system. The HURD is currently ported only to Gnumach, but this may change. Darwin refers to both the Berkley UNIX translation layer and the underlying microkernel.
Imagine the ugliness of moving parts of XFree into the kernel. WinNT/XP and Darwin move parts of the video subsystem into the kernel for performance reasons. NT set out to be a true microkernel, and perhapse NeXT started with this goal as well. The HURD doesn't move any of the server code into the kernel. The HURD on Gnumach follows a clean microkernel/sever seperation. Mach is a beast of a microkernel, but in essence the system is a much more pure microkernel. Your video driver goes beserk (supposedly the cuase of most NT/XP bluescreens nowadays) and all you have to do is restart the video server. Maybe you have a watchdog server running to restart essential servers that go kaput.
Of course, there's also the liscence issue for liscence bigots. You can get Darwin's source, but IIRC, you can't redistribute changes you make. I think everyone here will gree that this is less of a Good Thing than GPL or BSD liscenced kernel code.
As for me, I'm a design bigot. Gnumach is more of the Right Way to do Mach, but it's still the beast that is Mach. Bonus points for being a microkernel, but Linux is still more elegant (as are the *BSD kernels). UNIX monolithic kernels do a pretty good job of providng a minimum numberof orthogonal services and primitives that can be well tested and well understood. This is one principle of good design. Mach has over 100 system calls implementing all kinds of non-orthogonal services and primitives. Darwin refers to Mach and the BSD userland personality tranlator designed for Mach. HURD is just the userspace POSIX translator that was supposedly designed to be microkernel agnostic, so you could easily port it to a different microkernel and have HURD running on QNX or RtLinux, or even a monolithic *BSD or Linux kernel. There are efforts to port the HURD to the L4 microkernel. They've discovered that the HURD as presently implemented is highly dependant on certain aspects of Mach. They're debating rewriting the HURD from scratch becase of all of the Mach dependancies. It looks like they'll try and port the HURD to a "Virtual Kernel" and then have a thin library that gets linked in to wrap the VK calls and translate for the actual kernel (and perhapse a few userland servers, depending on exactly how the VK and actual microkernel break up kernel and server functionality.)
If the L4-HURD people suceed, you might actually see the HURD outperform *BSD, Linux, et. al. Microkernels have inherently worse agregate throughput due to the increased coontext switching. However, some L4 implementations cheat and put several tasks in the same address space and simply change the read-write permissions on memory pages instead of actually switching contexts (and flushing the TLB) between tasks. This is called lazy context switching and may actually allow L4 to outperform all of the kernels that use conventional context switching. Of course, the monolithic kernels could also use lazy context switchng, but they are harder to modify. I have a copy of L4 on my machine that is only 49,847 bytes large. About half of that has tobe machine-specific code, so often times it's easier to rewrite L4 from scratch when "porting" to another architecture. After all, there's probably more than 50k of object code that changes between releases of the Linux kernel.
People get confused and claim that Darwin is something of a NetBSD kernel or FreeBSD kernel merged with mach. The kernel has a userland personality that translates Berkley UNIX (BSD) systm calls to mach system calls. There's not really any NetBSD or FreeBSD code in the kernel as far as I know. The kerel is basically the NeXT kernel and BSD 4.3 personality server ported from m68k to PPC and an update to BSD 4.4 personality.
The NetBSD and FreeBSD connection comes from the userland utilities. Originally, most of the userland utilities were ported from NetBSD, but now Apple has snagged one of the main FreeBSD developers, so the userland is becomming more like FreeBSD.
When I interviewed for an intership with them a couple of years ago, the main thing they seemed to be pushing were some encrypted, authenticated, remote admin GUI tools. IIRC, they gave away their remote admin tools and kernel dump analysis tools. They would basically admin your servers for you for a fee. Sssseemed like a pretty good businessmodel at the time, but Linux admins have become cheaper and Linux adinistration has become easier in the past couple of years.
However, I'm suprised they weren't able to market themselves to medium to large size businesses. 24-hour competant server management is hard to find and expensive. Iif you out-source it, you can effectively cost-share the admins during off hours. I guess nobody wanted to pay the premium for the difference between garunteed uptime and standard Linux uptime.
Private namespaces -> Inferno gives each user/app a private namespace. If you're not allowed to see a file, it'not in your namespace, so there's no way you can even ask to see it. This is a good example of capabilities-based security. This is lightyears past the MS-DOS idea of each disk partition or network share being painfully appearant to the user.
JIT optimized VM -> DIS, the Inferno VM, is based on a memory machine instead of a stack machine (a la Java and CLR/Mono). This allows for more efficient register allocation durring just-in-time compililation. Stack machines are great for writng smpleinterpreters with small memory footprints. Memoery machines are great for easily recompiling into fast native code. If I could, I'd start on an Open Source VM based on DIS. Toasters are great, but I don't want a crippled VM just so that it's easy to run on an 8-bit microprocessor in a toaster. You guys running SPARC, MIPS, POWER, PPC, IA64, etc. CPUs should notice the performance advantags of DIS more than us poor x86 users because the x86 is pretty register starved.)
Distributed resources -> in Plan 9, there is a crippled user account without a password that pretty much can't doanything but present cryptographic credentials that prove it's doing work on behalf of a priveledged user. This would allow your dnet client to run on your CPU farm, but not actually be able to log in as you if it got compromised. As far as I can tell, the system is very similar to Kerberos with more types ofcredentials and tickets that never expire. I don't like the lack of ticket expiration , but it's better security than almost anything else out there. Most Beowulf implementations use rsh for performance, so you need to isolate the Beowulf compute nodes from anything remotely hostile, since rsh gives you a root prompt without a password based on the source TCP port number.
As soon as some of the large ISPs realize that they can turn IPv6 into marketing drivel, they'll start upgrading their internal networks. The winds of change will first rustle in your television. Joe Sixpack doesn't know what Ipv6 is, but he doesn't want to get left behind.
When I was home for Christmas, I noticed that Mom had an unopened OSX box on her shelf. She didn't know she had it. She's the kind of person that still asks me about "memory" when she means to talk about HD space and it seems that OSX would protect her from herself much better than OS 9.1 does. The only problem is that HP doesn't have printer drivers for her printer under OS X. She would get extremely confused if some apps could use the printer but others gave her error messages.
I end up solving printer issues for her every few months. Last time, I had to talk her though downloading and reinstallilng the printer drivers over the phone. (Thank God she has a second line for the modem.) Over Christmas, it was a cable that had giggled itself loose, but almost everything else seems to have been either stability or protection issues with OS 9.
BTW, those Apple guys are masters of (relatively) seamless transitions off of legacy Hardware/Software/APIs. I wish things were so good for things I can afford on my student budget. Maybe CLR/Mono will do better than Java for this problem, although I think we're going to start seeing legacy VMs being a problem. Anyone working on coding up a good java JIT to run under Mono or a bytecode cross compiler from JVM to CLR?
Remeber when he bought that MIG fighter jet and couldn't import it?
I think we should concentrate on writing invulnerable clients and servers instead of wastng all this effort on designing anddeploying firewalls. Ideally each machine, each OS, each client, and each server would be bulletproof so you shouldn't need firewalls.
Unfortunately, the world isn't perfect. Flaws will creap into software and emails. Shredding emails reduce damage from bad email writers just like firewalls minimize damage from bad software designers/coders.
Also, it's not a matter of concentrating on this or that. Your company should educate their own people about safe email practices. These people devising email shredding schemes don't waste the energy of YOUR company. These cryptographers and coders wouldn't do much good if instead of working in their cubicles, they came over to your company and lectured everyone on good emal practices. It's called division of labor. Do what you're good at and pay others to do what you aren't good at. They're good at cryptography and coding, your managers and corporate educators are much better at getting things through your employees heads. These cryptographers and coders aren't wasting energy any more than you're wasting energy at your job instead of working on an AIDS vaccine/cure for cancer/eliminating hunger/whatever people feel the most pressing NEEDS of mankind are.
----BEGIN divergence from topic
Haha! In the good 'ole US of A we kicked out thy tyrats and their tyranical parlimentary system! The American bicameral system and electoral college provide a much better form of abstraction, indirection, and power balance in order to minimize the influence of special interests and big money. The founding fathers were true visionaries and foresaw the problems the Europeans are having.
As recent events will show, we Americans could never... oh wait, sorry, I was sleep-typing again. It appears to have been a rather good and almost realistic dream. Such a shame I woke up. Maybe I should get myself some extra strongcoffee and pay extra close attention next election instead of sleep-voting again. If nobody votes with a clue, how is congress supposed to get a clue... This is representative government, remember?
Seriously, if you start voting with a clue, and cluing your neighbors in and actively helping with campaigns you beieve in, then the system will work coser to the way the founding fathers intended. THe system was designed for a bunch of riled up revolutionary citizens, not the bunch of apathetic winers we've become. (Yes, I have volunteared my time with a political campaign and I have written my congresscritters and I have ubmitted an opinion on the MSFT case.) You can't expect the legislature to have a clue unless you personally have done something to clue in the voters. It's that simple. Wasting my time doing something is better than doing nothing.
----END divergence from topic
I wish DRM circumvention wasn't driven by greed in most citizens, but it still represents some sort of civil disobedience in the same way that visiting speakeaseys durring prohibition. Writing P2P systems and using them shaws congresscritters in some sall way how we feel about DRM legislation. I just wish it was a more altruistic demostration.
Yes, I do realize that the poster's choice of language appears to place him/her on my side of the "big pond".
Symetrically encrypted messages. An md5 sum of the passphrase is ussed to encrypt the session key and this is symetrically encrypted session key is sent just like an asymetricically encrypted session key at the beginning of the message.(Hopefully the session key encryption uses the same cipher as the message. Failing that 3DES. but it's been a little while since I've read the OpenPGP spec.)
The conslusion is that the way OSS is developed means that code on average ends up being more easily audited. So maybe the many eyes aren't doing the auditing, but the many eyes (and mailing list readers/question askers) are making the code easier to audit for those who do audit the code. More effective audits mean better code.
Furthermore, source code and plain text emails are the only way many OSS projects communicate. This means that if any work is going to get done, the code needs to be much more legible than if coder A can just run over to coder B's cubicle if he can't understand the code. This also promotes a high degree of modularization, due to decreased communication bandwidth/increased latency between developers.
The large number of non-code-submitting members of OSS project mailing lists is also a huge plus. Many people to explain things to that haven't worked with the code since the beginning of time means that the coders need to teach others about the code. Teaching is one of the best ways of learning!
Peopple say that Microsoft must have really good coding practices to be so sucessfull. This isn't necessarily the case. I have a friend that interned for Microsoft and he was telling me about the infomal tutorial he got on Windows internals. The reason power management improved vastly between Win95 and WinME but remained basically unchanged between NT4 and Win2K was that the main guy who wrote the NT4 power managaeent code left and so they could make little tweaks, but they couldn't read the code well enough in a larger sense to make any drastic changes and predict the results.
Good idea but sort of self-defeating. The shortest connection between two sites that can be analized by that means is, of course, Google. You forget that hyperlinks are unidirectional, so this would be the case if the sites both had links back to google.