Yes, that explains why Unix is so secure. Thank goodness it was designed to use OpenSSH and shadow passwords so many years back. Can you imagine how hard it would be to "add" something like that later, like some feature?
Well, MULTICS was the only OS to ever get an orange book A1 security rating. UNIX was basically a slimmed down MULTICS, the idea being that MULTICS was too late and too over budget (and was dog slow), so they cut down the feature count (and ditched the 32-ring hardware).
Asother posters have pointed out, UNIX was also designed to be extensible, with very well thought out abstraction. (Too bad the MS OSen still don't have a virtual filesystem. ) This allows easy integration and replacement.
BTW, shadow passwords are a hack to get arround a bug, a bug in the user. Unshadowed md5 pass phrases with strict complexity and age restrictions would be much better than shadowed crypt passwords. (crypt passwords max out at 56-bits of entropy, maybe a few bits fewer based on the typable characters accepted by login. Stealing the password file is not the only "offline" password cracking method. Observing Kerberos session establishment, for example, also provides a passive "oracle" for the cracking engine to test against. Keep trying passwords until you can decrypt the ticket and get a session key that shows sensable plaintext.)
So nobody has found an economical way to individually press CDs. Therfore, all of the
CD images should be identical.
[insert devious grin]
Simply grab disk images of these things from your favorite P2P client. (Anything that'll get read by a diskman should still be available via dd if=/dev/cdrom of=/home/me/LimeWire/Shared/CactusSucks.img.) Email customer service claiming your CD is broken... that your CD player won't play it. Make sure to include the image as an attachment and ask if your drive read it properly. Make sure to word it so that after reading it 3 times, they figure out that your computer is the core of your entertainment center.
Enough "gosh, my there CD done gone not play in the player. Cuzin Jeffro showd me how uh send you the CD, rigt off the player like. See, it's attached to this here email." and they'll realize that
1.Breaking standards combined with the average American mean lots of customer service complaints.
2.Joe Average doesn't need a lot of intelligence to trade and burn raw disk images and they can't mess with anything at that low of a level (redefine the representation of 1s and 0s) without releasing their own players and abandoning all hopes of reverse compatability with the HUGE installed base of CD players. (Economic ritual self-disembowelment with a rusty spoon.)
However, if you have used Office XP, you will notice that it prevents you from executing attachments, by default.
This still leaves the user with the "Janitor and the Vault" problem. Does Bill gates use the same key for his office door and the company vault full of bearer bonds? If he does, hten he needs to either not allow the janitor to clean his office, or he needs to give the janitor acess to his office and the vault.
The propper way of doing this is to allowte user by default to xecute attachments, but the attachments are sandboxed so they can't make network connections, can't create file handles, and basically canonly play sounds and display pretty graphics. If an email attachment needs to do more than this, then something's wrong.
The *nix world isn't much better, btw. I'd love to see the Unix process model modifed so that executables by default ran as a seperate uid from the user invoking them, and unable to do anything except write tings to the screen, ply sounds, and open files owned by the execuatable. If an executable needs a file handle for one off my files, it needs to pop up a dialog box and ask me nicely for me to open the file for it, This wouldn't necessarily mean major code changes, but it would cause problems for many daemons unless the daemons were run setuid root or something almost as bad.
Ah well, Apple has always ahead of its time.. maybe Apple will ge this right and really force me to go out and go get one of those meaty SMP RISC boxes.
Is anyone really insane enough to leave their CC# on their computer?
Not their own CC#. There are many small home businesses arround.
If I were a CC theif, I'd focus on the smallest businesses I could find.. easiest pickings and smalest risk of someone putting much effort into the investigation.
Coupled with all drives shared (needing the user's password, but for 90% of their market, this is effectively a moot point) by default (C$, D$, etc.) and a single namespace, this means "login as Administrator with drowssap and find (CC or Credit). Copy to victims.xls" and come back 3 days later with 40,000 CC numbers.
Okay, well hopefully it won't be shipped with the ability to search for every Win32 machine on the net and attempt to log in as Administrator on every machine it finds, but you can find programs now to bruit force passwords on SMB shares.
I think any consumer OS's default behavior should be to tell the user a new passwrd when commanded, not to ask. A word database of 2048 words in each supported language and
the ability to capitalize the first and last letter of each word means 14 bits of entropy per word. 5 words means 70 bits of entropy, which is stronger than 95% of the passwords out there. Joe average can be expected to remember 5 words muchbetter
than, say the random default passwords for slashdot accounts.
Well, perhaps it will allow the GCC compiler folks a glimps into some of the optimizations Intel managed (by studying the output produced), which will in turn allow the GCC writers to rethink GCC's optimization strategies. Those improvements would hopefully benefit more platforms than just Intel.
The article itself explains that a lot of the optimization is agressive translation of loops into operations on vectors, usng the SIMD (MMX, SSE, SSE2, etc.) opcodes,
I don't think GCC ever uses SIMD instructions unless you explicitly inline them in assembly. I know there are some vector-aware versions of GCC available on PPCLinux that use special data types for vectors and will then use SIMD (AltiVect) instructions on those vector data types.
I'm not familiar with the RTL intermediate representation GCC uses, but I wouldn't be surprised if the intermediate representation in GCC needs to be reworked to be able to clearly express vector operations. Either that, or this relatively generic optimization (would work at least on x86 and PPC) would need to be recoded in each of the applicable platform-specific areas of GCC. It's a relatively simple task for the platform-specific sections to generate loops from vector operations where they don't exist, but very difficult to go the other way. Also, this sort of higher-level optimization could be used to reorder indexing of multi-dimensional arrays acessed in an innefient order (such as sloppy ports of FORTRAN to C. (The major advance in Sun's new compiler is speculated to be this sort of optimization, since it's major speed increase is on a SpecINT benchmark poarted from FORTRAN to C.)
In any case, a lot of work would need to be done on the compiler to get it to agressively convert loops into vector ops. Interpreting the intent of nested loops can be a very complex task, as evidenced by one poster's claim that the new Intel compiler taes about 4 times as long to compile things as the MS compiler.
Also, don't forget that a major rework to get performance gains on (perhapse) only x86 and PPC platforms would probably be met with lots of resisistance from the community.
You've read enough examples of other people's letters, so you have no excuse for not writing the DOJ. I'm not telling you to write in favour or in oposition to the settlement. There simply need to be more infomed opinions submitted.
There's a 95 % chance you're going to read through all of these comments and then never get around to writing anything. You know this and I know this. Have more respect for yourself than just sitting there and preaching to the choir.
Oh, and if you're sitting there modding people's posts up and down without having submitted your own opinion, what gives yourlazy ass the right to judge the opinions of someone who actually has an opinion and the motivation to say something meaningful about their opinions to someone who can do something about it?
Yes, I'm going to piss off 95% of the slashdot crowd, including 95% of the moderators, but I've got karma to burn, especially for a good cause. (Say what you will about burning karma on a loosing battle.)
I think the key is encrypted with a pin number on the card.
You need the pin AND the card.
Unfortunately, they don't have sufficiently advanced biometric technology to implement signatures yet. You just don't send a picture of your retina along with the signature, as this would be too easyto replay (with a slight photoshhop rotation, magnifiction, ad shift to make it less obvious). They need much better parametrization and specialized threshold hashing algorithms for bioetric data so they can actually use your retinal scan/fingerprint as a symetric encryption key for encrypting your pin-encrypted public signing key on the tamper-resistant card.
Without better biometric data hashing algorithms, you'd never be able to get your decryption key generated the same twice, so you'd never be able to decrypt your signing key. Iiiiiiit's a dificult problem, and there's ongoing research, but replay attacks and trust issues are a huge problem right now.
Hmm... what if auto makers started marketing their cars based on engine displacement?
You could go out and make a boiler and count the diplacement of the pistons of your steam engine under the hood. Oh wait, power matters too?
Those Italias marketing their cars based on skidpad results and 0-60 times? Hogwash! Just marketing drivel... everyone knows there are little tricks to those tests... they side-step the clutch and double-cutch to get those 0-60 times! They're ruining the trannies in the testing. Those Italian liars! I won't believe anything they say unlesss they've got the cubes to back it up!
You can cook results, but you can only cook them so much. In the end, I think the consumer is better off by having performance-based mareting, even if the numbers are cooked a bit.
After all, those Intell cars have 5.7 liter engines vs. the AMD 3.5 liter engines. Oh, but the Intel engines are pushrod hemis breathing through the same carb I have on my lawn mower? The AMD engine is a clone of the Ferrari F355 engine derived from the Ferrari Formula 1 engine?
A big Americav 351 hemi (5.7 L) with a moderate flow 2-barrel carb really can't compete with a 5 valve-per-cylinder clean-breathing high-reving Formula 1 race engine descendant, even if it is only 3.5 L. Fereri was getting 108 HP/L out of that thing, when it's hard to get 60 HP/L out of an old technology low-reving hemi unless you put a high flow carb or a 6-2 setup with a really clean intake and exhaust system.
This last analogy has a lot more merrit than you might think. The P4 has a post-decoder cache, but it still "breathes" through a single x86 decoder. The AthlonXP is much more like the Ferrari engine feeding itscylinderrs through 3 intake valves per cylinder... The Athlon XP has 3 distinct x86 decoder units onboard.
The Athlon XP;s ALUs spend a lot less time executing NOOPs because of those 3 decoder units. The P4 has the cubes, but itdoesn't keep e'm fed, or it's turning them over much more slowly (fewer instructions per cycle). Clock for clock, the PIII is much better than the P4.
I can't wait until the ia-64 and x86-64 architectures are mare widespread. I like the ia64 better, but it'll be out of my price range. Once the product lines diffferentiate eachother a bit more, you'll see those performance benchmarks becomming more important as the AMD consumer chips are x86-64 and the Intell chips are still ia32.
It's really a shame the PPC and UltraSPARC chips don't get more marketshare tobring prices down (and bring out the OEM sales on PriceWatch) those chips really perform well an much lower clock speeds than the P4. For had care number crunching, a G4 isn't far behind a PIII at twice the clock speed. I would supsect that double-precission floating point ops or 64-bit integer ops allow the 64 to pull ahead of any x86 chip.
I would guess their efforts would be better spent cracking the password file... very few people who have neglected to apply SP2 would use passwords that are stronger than 40-bits. Even if that isn't the case, they need to crack the user's passwords just once, but each file has it's own encryption key stored using RSA.
The password file in Win2K is hashed, but not truly encrypted, so they can grab it off the hard disk and start cracking it. Ooh... new Distributed.net project, the most popular ever! Distributed Win2K password cracker. A good Arabic, English, Fresh, and German disctionary hybrid cracker should work very well. Run each password cndidate in parallel against each account for maximum efficiency.
People talk about how exportrest rictions shoul be lifted or kept or defaults should be at 40-bit encryption. However, they fail to realize that for people who don't care enough to download PGPdisk or change the crypto settings, the file encryption weakness is almost certainly the user's pssword, not the individual file encryption keys.
Most citizens use such poor passwords (even here at MIT, the few passwords I've seen look good at first glance, but are pitifully easy to crack via haybrid dictionary crackers) that I would guess 32-bit encryption with random keys would be better.
Also, based on my experience, 5 days on severl supercomputers seems a bit fishy...
I took Rivest's Network security class last term and one of mytclassmates failed to see a weakness in a 32-bit hash function based on RC5, so he bruit forced it in about 3 hours. Granted flukes mappen, I'll have to write a 32-bit encryption cracking benchmark, but it seems like his slow machine should be able to crack 40-bit encryption in 16 days. I think he ran his calcs on a shared dialup workstation, a SPARC 5, IIRC.
I'll bet that a single task machine (a 2 GHz P4 or a 1 Ghz G4) would crack it about 10x as fast.
"The equivalent of several supercomputers running for 5 days" probably transates to a pair of slow G4s (they're considered supercomputers by some definitions) running for 5 days. Granted, DESX is slow, but they should have at least 4 bytes of known plaintext based on the file extension. 4 bytes of known plaintext and 40 bit encryption means that you should end up with an average of only 256 candidate keys, so even hand-checking the cndidates shouldn't take 5 days. Don't believe the hype. 40-bits is cracker-jack-box-secret-decoder-ring encryption. 5 days sounds like an upper bound, not an average, and an upper bound on some decently slow "super computers".
I took Professor Ron Rivest's (as in one of the nvenors of RSA) networksecurity last term. Oneweek's homework assignment was cracking a hash algorytm based on 32-bit RC5.
(Acually, 64-bit keys, but 32 bit block size, so as a hash algoryhtm fining a collision was equivalent to breaking 32-bit encryption.)
Another student I talked to didn't realize the hash was poorly constructed and subject to a meet-in-the-middle attack, so he ended up buit forcing the algoritm. He said his solutiontook about 3 hours to run. I assume this was on on of the MIT shared dialup servers, which usually have enough people on them that they're fairly slow. My 226 MHz PII usually seems faster. So, I usually ballpark that my machine could bruit force 32-bit encryption in 3 hours.
Given this, we can assume that a single 2.2 GHz P4 could bruit force 32-bit encryption about 10 to 12 times as fast. That would mean bruit-forcing 34-bit (yes, I uped the work factor by 4x) in about 2 hours. That would mean bruit forcing 40-bit encryption in about 64 hours. This means about 2^31 RC5-16/32/8 key setups and encryptions. If a different algorythm was used, you're probably looking at plus or minus 50% and a lot of assumptions have been made. However 3 days is a reasonable estimate for the time required to bruit force 40-bit encryption on a single desktop purchased today. The problem is infinately parlelizable, and if you cade it right, you can take advantage of SSE/AltiVec to double your speed. This means about 1.5 days if you use the __VECTOR__ aware version of gcc on LinuxPPC. I would guess that a 1 GHz PPC chip is equivalent to a 2 GHz P4 for these kinds of calculations, so an overclocked new iMac could probably crack 40-bit encryption in about 1.5 days, as could a good dual P4 or AthlonXP.
Hmm... if I wrote a portable C encyption cracking benchmark, would/.ers be game for running it on thier home systems? I could make it 32-bit or 34-bit encryption to make sure this story doesn't die before you can post your results. The only thing is I'd need to know the Mac and Win32 header fil names for time().
I did my first real kernel programming (besides a little "hello, woeld!! This is the kernel speaking" module). Last week. My keyboard died a few months ago and I didn't have time to mess with it, so I went out and baught and IBM USB/PS2 keyboard (Rapid Acess Pro) and hooked it upto my machine as a PS/2 keyboard.
When I had time, I went and fixed the old keyboard, and rearranged the keys as a Devorak keyboard while I was at it. Unfortunately, the USB-PS/2 dongle that came with my IBM keyboard doesn't work with my Dell PS2 keyboard. However, I currently have the IBM keyboard hooked up to my USB port and my old Dell keyboard (with rearranged keys) as my PS/2 keyboard.
Luckily, keybdev.c (both the one in drivers/input and the one in drivers/usb) is astonishingly short. There's all of about 5 functions in there and most of the complexity is hidden in other modules.
The USB keyboard driver interfaces the PS/2 subsystem IIRC (don't know where I read this, maybe the hid.c documentation on linux-usb) so you can't have seperate keyboard mappings, unless you munge the keycodes inside the USBdriver. As long as you don't lock up your USB keyboard driver or have a buffer overun, you should always be able to restart.
I have LILO (GRUB, actually) setup to boot me into either a 2.2.20 kernel or a 2.4.17 kernel. That way, I can ensure that my hacked module won't be loaded by hotplug if I screw it up.
The Steps I took Downloads I downloaded the 2.4.17 source code and used apt-get to install kernel-package (makes Debian kernel packages, so your nightly apt-get upgrades won't destroy your work). Renaming I went into/usr/src/linux (after untarring the 2.4.17 source) and changed the line near the to from "EXTRAVERSION = " to "EXTRAVERSION = -maxmodular"
this changes the name of the kernel from vmlinuz-2.4.17 to vmlinuz-2.4.17-maxmodular and
makesa seperate directory in/lib/modules for your hacked modules. (I called it maxmodular because I even made the "misc binary support", "a.out binary support" and "floppy drive support" as modules.) Potential Gottcha: IDE support is no enabled by default, and comes after the IDE-parport questions in the config menu, so I must have recompiled 10 times trying to figure out why it couldn't mount the root partition. Snooping arroundI poked around the drivers/usb/ kernel source and documentation some to try and figure out what needed to be hacked. I incorreclty identified drivers/usb/keybdev.c and after none of my printk's worked, I tried drivers/input/keybdev.c (this does not affect the PS/2 keyboard). Printk() is your friend. Add printk()s (printk() works just like printf(). Make sure to do your kernel module insertion from a non-X virtual terminal to minimize the time it takes prints to get to you in the case of an impending crash.) to the beginning of every function in the driver, letting you know that it's being called (and optionally the arguments). Then recompile and load your module. This gives you a feel for how the driver works and confirms that you have the right driver. Trim prink()s to only print out the information you need. In my case, I got rid of the printks from everything but the keyboard event handling function and the emulate_raw function kalled by the event handler. I printed out every keycode that was pressed (but not it's release) so that I could write down the keycode for each key I needed to remap. (And some of the neat colorful buttons IBM added above the funtion keys. I later used these to turn on and off the devorak remapping and turn on and off the printks in my module.
After that, what you do is pretty specific to your module.
For keyboards, they send a 16-number, called a scancode that
is one of the arguments to the keyboard event hadler function.
All of the normal keys have scancodes less than 256, so I just
made an unsigned char[256] usb_key_remap_table and did something like
if (code < 256 && code >= 0) {code = usb_key_remap_table[code];}
The more astute amoung you will remeber that I'm only remapping the USB keyboard, which is my good keyboard and therefore unmodified. Oh well, I figure having the incorrect letters written on the keys discourages me from looking down.
Anyway, the USB subsystem seems very readable for the higher level drvers and USB
keeps getting more and more devices, so I'd recomed starting with
a USB subsystem... too bad RadioShack is out of USB cue:cats:-D
Sorry, I should have been more clear. Yes, there are many ways to sandbox applications in most Unices, but it's not the default behavior. Sandboxing methods are basically ways of emulating capabilities-based security, but sandboxing does nothing to prevent the "confused deputy" problem. See the intro to capabilities page I referenced earlier to see an example of how capabilities can be used to prevent the confused deputy problem.
You could claim that the confused deputy problem is a result of sloppy sanity checking, but very few compiler programmers would think anyone would be insane enough to type "cc MySource.c -o/etc/cc/compiler-time-billing-log.txt". It's a subtle case that would only be the result of malicious users and a case that is only covered in security litterature and security classes. You really can't fault the programers for missing that one.
... or case manufacturers are going to need to realize that they can just add a little extra metal and actually
CONDUCT the heat out through the case,...
Yet another instance of Apple being ahead of its time. The fanless G4 cubes had the CPU in contact with the side of the case and a little thermal paste. See the slashdot article about converting the cubes to run dual G4s; they had to add some metal to the case to get both CPUs in contact with the case.
Now... if only I could find G4 CPUs and G4 mobos on pricewatch...:-)
Integrating capabilities with the OS's security model would eliminate many of the problems we see currently with email viruses, macro viruses, browser buffer overflows, etc.
If anything Unix needs to push it over the top as far as a secure server operating systems is the ability to tell the OS that "This File can never be deleted and can only be appended to by...
More importantly, I think UNIX needs a better security model. Right now one of the big problems is that all of your executables have the same permissions that you do. In a capability based system, your email program may own capabilities for reading its configuration files, but an open() on a file owned by the user would require active user input to succeed. (Someone wrote a paper about using a Windows-like GUI to make capabities more understandable to the user, but I can't find the url at the moment.)
In any case, here are some links. "E", a capability-secure language. Capabilitiesvs. Microsoft's signed execuatables solution. (Part of a good introduction to capabilities). Linux Kernel Capabilities vs. the standard definition of capabilities.
If they already have
copies of some of the clear text that resides in the encrypted archive, it will be child's play to find your
encryption keys and decrypt the entire archive.
False. One of the criteria for a strong encryption algorithm is resistance to known plaintext attacks. For symetric key algorithms this means the fastest attack is bruit forcing all of the keys, even if you have an arbitrary ammount of known plaintext. In other words, you cannot recover the key any faster than guess-and-check.
For AES with a 256-bit key, this means an average of about 32,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,0 00 tries. All of the world's computers (assuming current trends, and remembering that symetric ciphers are not obviously broken by quantum computation) will not cover this many keys until long after the formaldehide diffuses out of your corpse and soil microbes have devowered all but your coffin.
Re:I doubt this is windows in disguise
on
LindowsOS Marches On
·
· Score: 5, Insightful
Case 4) Lindows is Linux running CodeWeaver's Wine to launch windows apps on demand.
Case 4 is correct. They've taken WINE and improved it a bit without releasing changes back to the community. I'm not even sure WINE will get much recognition out of it. This has caused some people to push for future releases of WINE under the LGPL instead of the current BSD-like liscence.
WINE had been getting along pretty well. Let's hope MS doesn't return to the old "The Job's not through 'til it doesn't run on OS/2!" days.
You have ignored the posibility of the attacker using raw sockets to send messages directly to the victim with a source IP faked to look like the AOL Oscar servers.
I breifly looked at the exploit code and it looks like the cient and server may be using nonces to provide very week message integrity. However, as the poster implied, non-filtered IP networks are still vunerable.
Yeah, if the message wasn't ascii English, the stego findoer would still a pattern in the image. Unfortunately, they ran thier ~20,000 "suspect" images through a dictionary checker, with the implication being that the 1,800,000 words and phrases were all English ascii. This was their difinative test of the suspect images. In any case, they can't say anything about the suspect images containing conventioanlly encrypted messages. All they can say is that the images look like they're hiding info, but the hidden info looks like white noise.
Good idea about making an image of the message and stegoing that into an image, except that the stego content is typically much smaller than the original file size. Encrypting before using stego should make it much less detectable. I would guess that any intelligent stego search would include checks for standard file headers.
I think the main problem is inertia. There's still lots of libraries writen in FORTRAN77 and C. Were you even taught F90? I think my brother was taught F77 two years ago.
There's also inertia in the teaching world. What percentage of the Mech. E. professors were arround before OOP was widely accepted? How many of them have gone back and learned to do OOP properly? If the profs and masters of industry haven't learned OOP, then the advanced codes will be in C/F77. You go to learn about the advanced coding, and you end up learning how to do all of the advanced stuff in functional languages.
For the beginning student, the fastest way to learn to code up some problem is C or Java with only one object. Once a student is proficient in one language, most of them will push as far and fast as they can in their subject matter instead of learning to code better or learning a new language.
OOP is mainly necessary as a tool to clean up large programming projects to make them manageable and to help keep you from hurting yourself through disorganization. OOP really shines when you're doing a lot of dynamic allocation and freeing of data, as destructor methods are a big help in preventing memory leaks. The really big Mech. E. codes (FEA) are gigantic matrix inversions. (There are some other methods, but FEA is by far dominant.) There are plenty of C and F77/F90 libraries out there to handle the messiness of matrix manipulation for the coder. And, truth be told, matrix manipulation is not messy at all by comparison. You have a large ammount of memory allocation at the beginning of the executable, but then you just manipulate the data you have for a while, save your results, and exit, perhapse without even free()ing your matricies.
On the extreme end, some people may not want to take the small performance hit in going from C to C++. For compuationally intensive tasks, I believe you still take a 10x hit going from C/C++ to Java. The MIT 6.270 Lego robotics contest still gets won by teams that use purely mechanical methods of steering (the winner ~3 years ago) or use a single java object and do functional programming inside that object. The boards are still a bit too underpowered to pull a full JVM on top of NetBSD and not care about the various OOP overheads. Some teams use huge switch statements to virtually illiminate method calls. For small projects, this can be done without sacrificing too much robustness, and the performance gains are noticable.
about my girlfriend being less technically minded and detail-oriented than I am. I also feel much better about her lack of ability (and interest to improve) in multivarible calculus and differntial equations. (Considered basic math skills here.)
I'm also looking at some of the other MIT couples I know and wondering if their children have a very high risk of autism. As a t-shirt from a nearby women's college (Wellesley) says "MIT men: the goods are odd, but the odds are good." Maybe the old MIT frternity saying "B.U. to bed, Wellesley to wed, and MIT to talk to." has some positive implications for the gene pool in the Boston area:-) (Sorry, I know MIT girls really hate that saying. Stereotypes are just stereotypes. My MIT GF is simply the best.)
I wonder if there is also a higher risk of autism among children of two mechanical enginners. I was drawn to mechanical engineering because of a fascination with complex machines and an appearent ability to model three dimentional machines in my head much better than my peers. (This sounds a lot like one of the autistic people quoted in the article.)
Granted, mechanical engineering is considered one of the easier subjects at MIT, so you get some wash outs from other programs diluting the field, but I wouldn't be surprised if mechanical engineering couples from top schools have a much higher incidence of autism, provided the theories layed out in the article are correct. Mechanical engineers should be a self-selecting group of 3D visual thinkers.
As an aside, is it true about what I've heard about yelling out "LSC" in a movie theater in Silicon Valley? (It's been an MIT cultural thing for at least 15 years now.) How often do you get the propper repsonse from more than one person in an audience? If any of you are curious and want to try it, please do so only when the screen is black before the previews begin or when there is a screw up that has already distracted the audience.
Hey is it just me, or deos it seem like at least 2% of the regular slashdot posters are MIT students?
We're diverging off topic here, but we're getting into one of my favorite areas...
Yeah, NeXT was waayyy ahead of it's time. The same thing goes for apple, just somewhat less so. As my friend Eric said, "Apple's problem is that it tries to sell stuff that's ahead of it's time to people who don't appreciate it." I REALLY like Apple hardware, and if I weren't a poor college student, I'd have a G4 machine (or a used UltraSPARC). Did anyone notice that the slashdot article last week about the dual CPU machines for artists had some benchmarks with dual 400 MHZ G4s lagging not so far behind dual 1.7 GHz Xeons?
Now, if only Apple would throw a more modern micokernel (caugh port l4 caugh) under Darwin, I'd pretty much be forced to sell my soul for a new machine. Provided of course, the kernel was still open source.
Microsoft wanted NT to be a microkernel OS, but they couldn't quite pull it off for performance reasons. Apple managed to pull it off with an old microkernel. Imagine how OS XI would fly with a higher performance (and smaller and simpler) micokernel under the hood.
Warning: Micokernel rant
I don't mean to start a flame war, but Mach has way too many features to make implementation and optimization easy. Small micokernels rock! I had to benchmark the memory latency of several systems for my systems design class. I chose my personal box running Linux and my personal box running QNX for two of the systems. Linux showed the expected gradual transition from cache latency to RAM latency as the size of the buffer used in the benchmark approached the cache size. However, under QNX the memory latency managed to stay very low until the benchmark buffer size got very close to the cache size, and then there was a rapid transition to the RAM latency. This shows that small microkernels are more resistant to cache thrashing (yes, I did boot Linux into runlevel 2 and kept applications to a minimum) because you have fewer bites of kernel code that are continually pushing stuff out of the cache. I'm not sure why the user-level servers didn't offset this. Maybe QNX tries to buffer system requests and run the user-level servers in batches for performance reasons. In any case, there was a marked difference in the benchmarks on the same hardware. If you combine this with L4's very fast messge passing, modern microkernels make a lot more sense than older microkernels like Mach. If you've got x86 or ARM hardware, check out the L4Ka site. Uwe posted an updated snapshot of the Hazelnut implementation of L4 today. (Supposedly the IPC is blazingly fast. I don't know how they teaked their C to be faster than Jochen's x86 assembly kernel but they did it. I suppose that with only about 11 system calls, you have a lot of time to tweak them all.) It's been almost a year since the last snapshot was posted, but the mailing lists show that devlopment is going strong. L4 really shows the elegance of simplicity. It has a very small set of well designed features that are very flexible and powerful, which allows L4 to get away with fewer than 10% of the number of system calls used by Mach.
Slashdot Mirror
Well, MULTICS was the only OS to ever get an orange book A1 security rating. UNIX was basically a slimmed down MULTICS, the idea being that MULTICS was too late and too over budget (and was dog slow), so they cut down the feature count (and ditched the 32-ring hardware).
Asother posters have pointed out, UNIX was also designed to be extensible, with very well thought out abstraction. (Too bad the MS OSen still don't have a virtual filesystem. ) This allows easy integration and replacement.
BTW, shadow passwords are a hack to get arround a bug, a bug in the user. Unshadowed md5 pass phrases with strict complexity and age restrictions would be much better than shadowed crypt passwords. (crypt passwords max out at 56-bits of entropy, maybe a few bits fewer based on the typable characters accepted by login. Stealing the password file is not the only "offline" password cracking method. Observing Kerberos session establishment, for example, also provides a passive "oracle" for the cracking engine to test against. Keep trying passwords until you can decrypt the ticket and get a session key that shows sensable plaintext.)
[insert devious grin]
Simply grab disk images of these things from your favorite P2P client. (Anything that'll get read by a diskman should still be available via dd if=/dev/cdrom of=/home/me/LimeWire/Shared/CactusSucks.img .) Email customer service claiming your CD is broken... that your CD player won't play it. Make sure to include the image as an attachment and ask if your drive read it properly. Make sure to word it so that after reading it 3 times, they figure out that your computer is the core of your entertainment center.
Enough "gosh, my there CD done gone not play in the player. Cuzin Jeffro showd me how uh send you the CD, rigt off the player like. See, it's attached to this here email." and they'll realize that
1.Breaking standards combined with the average American mean lots of customer service complaints.
2.Joe Average doesn't need a lot of intelligence to trade and burn raw disk images and they can't mess with anything at that low of a level (redefine the representation of 1s and 0s) without releasing their own players and abandoning all hopes of reverse compatability with the HUGE installed base of CD players. (Economic ritual self-disembowelment with a rusty spoon.)
This still leaves the user with the "Janitor and the Vault" problem. Does Bill gates use the same key for his office door and the company vault full of bearer bonds? If he does, hten he needs to either not allow the janitor to clean his office, or he needs to give the janitor acess to his office and the vault.
The propper way of doing this is to allowte user by default to xecute attachments, but the attachments are sandboxed so they can't make network connections, can't create file handles, and basically canonly play sounds and display pretty graphics. If an email attachment needs to do more than this, then something's wrong.
The *nix world isn't much better, btw. I'd love to see the Unix process model modifed so that executables by default ran as a seperate uid from the user invoking them, and unable to do anything except write tings to the screen, ply sounds, and open files owned by the execuatable. If an executable needs a file handle for one off my files, it needs to pop up a dialog box and ask me nicely for me to open the file for it, This wouldn't necessarily mean major code changes, but it would cause problems for many daemons unless the daemons were run setuid root or something almost as bad.
Ah well, Apple has always ahead of its time.. maybe Apple will ge this right and really force me to go out and go get one of those meaty SMP RISC boxes.
Not their own CC#. There are many small home businesses arround. If I were a CC theif, I'd focus on the smallest businesses I could find.. easiest pickings and smalest risk of someone putting much effort into the investigation.
Okay, well hopefully it won't be shipped with the ability to search for every Win32 machine on the net and attempt to log in as Administrator on every machine it finds, but you can find programs now to bruit force passwords on SMB shares.
I think any consumer OS's default behavior should be to tell the user a new passwrd when commanded, not to ask. A word database of 2048 words in each supported language and the ability to capitalize the first and last letter of each word means 14 bits of entropy per word. 5 words means 70 bits of entropy, which is stronger than 95% of the passwords out there. Joe average can be expected to remember 5 words muchbetter than, say the random default passwords for slashdot accounts.
The article itself explains that a lot of the optimization is agressive translation of loops into operations on vectors, usng the SIMD (MMX, SSE, SSE2, etc.) opcodes,
I don't think GCC ever uses SIMD instructions unless you explicitly inline them in assembly. I know there are some vector-aware versions of GCC available on PPCLinux that use special data types for vectors and will then use SIMD (AltiVect) instructions on those vector data types.
I'm not familiar with the RTL intermediate representation GCC uses, but I wouldn't be surprised if the intermediate representation in GCC needs to be reworked to be able to clearly express vector operations. Either that, or this relatively generic optimization (would work at least on x86 and PPC) would need to be recoded in each of the applicable platform-specific areas of GCC. It's a relatively simple task for the platform-specific sections to generate loops from vector operations where they don't exist, but very difficult to go the other way. Also, this sort of higher-level optimization could be used to reorder indexing of multi-dimensional arrays acessed in an innefient order (such as sloppy ports of FORTRAN to C. (The major advance in Sun's new compiler is speculated to be this sort of optimization, since it's major speed increase is on a SpecINT benchmark poarted from FORTRAN to C.)
In any case, a lot of work would need to be done on the compiler to get it to agressively convert loops into vector ops. Interpreting the intent of nested loops can be a very complex task, as evidenced by one poster's claim that the new Intel compiler taes about 4 times as long to compile things as the MS compiler.
Also, don't forget that a major rework to get performance gains on (perhapse) only x86 and PPC platforms would probably be met with lots of resisistance from the community.
You should really let the FBI know about the details.
There's a 95 % chance you're going to read through all of these comments and then never get around to writing anything. You know this and I know this. Have more respect for yourself than just sitting there and preaching to the choir.
Oh, and if you're sitting there modding people's posts up and down without having submitted your own opinion, what gives yourlazy ass the right to judge the opinions of someone who actually has an opinion and the motivation to say something meaningful about their opinions to someone who can do something about it?
Yes, I'm going to piss off 95% of the slashdot crowd, including 95% of the moderators, but I've got karma to burn, especially for a good cause. (Say what you will about burning karma on a loosing battle.)
You need the pin AND the card.
Unfortunately, they don't have sufficiently advanced biometric technology to implement signatures yet. You just don't send a picture of your retina along with the signature, as this would be too easyto replay (with a slight photoshhop rotation, magnifiction, ad shift to make it less obvious). They need much better parametrization and specialized threshold hashing algorithms for bioetric data so they can actually use your retinal scan/fingerprint as a symetric encryption key for encrypting your pin-encrypted public signing key on the tamper-resistant card.
Without better biometric data hashing algorithms, you'd never be able to get your decryption key generated the same twice, so you'd never be able to decrypt your signing key. Iiiiiiit's a dificult problem, and there's ongoing research, but replay attacks and trust issues are a huge problem right now.
You could go out and make a boiler and count the diplacement of the pistons of your steam engine under the hood. Oh wait, power matters too?
Those Italias marketing their cars based on skidpad results and 0-60 times? Hogwash! Just marketing drivel... everyone knows there are little tricks to those tests... they side-step the clutch and double-cutch to get those 0-60 times! They're ruining the trannies in the testing. Those Italian liars! I won't believe anything they say unlesss they've got the cubes to back it up!
You can cook results, but you can only cook them so much. In the end, I think the consumer is better off by having performance-based mareting, even if the numbers are cooked a bit.
After all, those Intell cars have 5.7 liter engines vs. the AMD 3.5 liter engines. Oh, but the Intel engines are pushrod hemis breathing through the same carb I have on my lawn mower? The AMD engine is a clone of the Ferrari F355 engine derived from the Ferrari Formula 1 engine?
A big Americav 351 hemi (5.7 L) with a moderate flow 2-barrel carb really can't compete with a 5 valve-per-cylinder clean-breathing high-reving Formula 1 race engine descendant, even if it is only 3.5 L. Fereri was getting 108 HP/L out of that thing, when it's hard to get 60 HP/L out of an old technology low-reving hemi unless you put a high flow carb or a 6-2 setup with a really clean intake and exhaust system.
This last analogy has a lot more merrit than you might think. The P4 has a post-decoder cache, but it still "breathes" through a single x86 decoder. The AthlonXP is much more like the Ferrari engine feeding itscylinderrs through 3 intake valves per cylinder... The Athlon XP has 3 distinct x86 decoder units onboard.
The Athlon XP;s ALUs spend a lot less time executing NOOPs because of those 3 decoder units. The P4 has the cubes, but itdoesn't keep e'm fed, or it's turning them over much more slowly (fewer instructions per cycle). Clock for clock, the PIII is much better than the P4.
I can't wait until the ia-64 and x86-64 architectures are mare widespread. I like the ia64 better, but it'll be out of my price range. Once the product lines diffferentiate eachother a bit more, you'll see those performance benchmarks becomming more important as the AMD consumer chips are x86-64 and the Intell chips are still ia32.
It's really a shame the PPC and UltraSPARC chips don't get more marketshare tobring prices down (and bring out the OEM sales on PriceWatch) those chips really perform well an much lower clock speeds than the P4. For had care number crunching, a G4 isn't far behind a PIII at twice the clock speed. I would supsect that double-precission floating point ops or 64-bit integer ops allow the 64 to pull ahead of any x86 chip.
The password file in Win2K is hashed, but not truly encrypted, so they can grab it off the hard disk and start cracking it. Ooh... new Distributed.net project, the most popular ever! Distributed Win2K password cracker. A good Arabic, English, Fresh, and German disctionary hybrid cracker should work very well. Run each password cndidate in parallel against each account for maximum efficiency.
People talk about how exportrest rictions shoul be lifted or kept or defaults should be at 40-bit encryption. However, they fail to realize that for people who don't care enough to download PGPdisk or change the crypto settings, the file encryption weakness is almost certainly the user's pssword, not the individual file encryption keys.
Most citizens use such poor passwords (even here at MIT, the few passwords I've seen look good at first glance, but are pitifully easy to crack via haybrid dictionary crackers) that I would guess 32-bit encryption with random keys would be better.
Also, based on my experience, 5 days on severl supercomputers seems a bit fishy...
I took Rivest's Network security class last term and one of mytclassmates failed to see a weakness in a 32-bit hash function based on RC5, so he bruit forced it in about 3 hours. Granted flukes mappen, I'll have to write a 32-bit encryption cracking benchmark, but it seems like his slow machine should be able to crack 40-bit encryption in 16 days. I think he ran his calcs on a shared dialup workstation, a SPARC 5, IIRC. I'll bet that a single task machine (a 2 GHz P4 or a 1 Ghz G4) would crack it about 10x as fast.
"The equivalent of several supercomputers running for 5 days" probably transates to a pair of slow G4s (they're considered supercomputers by some definitions) running for 5 days. Granted, DESX is slow, but they should have at least 4 bytes of known plaintext based on the file extension. 4 bytes of known plaintext and 40 bit encryption means that you should end up with an average of only 256 candidate keys, so even hand-checking the cndidates shouldn't take 5 days. Don't believe the hype. 40-bits is cracker-jack-box-secret-decoder-ring encryption. 5 days sounds like an upper bound, not an average, and an upper bound on some decently slow "super computers".
That 2^31 encryptions line was oprhaned. It was supposed to go at the end of the previos paragraph.
Another student I talked to didn't realize the hash was poorly constructed and subject to a meet-in-the-middle attack, so he ended up buit forcing the algoritm. He said his solutiontook about 3 hours to run. I assume this was on on of the MIT shared dialup servers, which usually have enough people on them that they're fairly slow. My 226 MHz PII usually seems faster. So, I usually ballpark that my machine could bruit force 32-bit encryption in 3 hours.
Given this, we can assume that a single 2.2 GHz P4 could bruit force 32-bit encryption about 10 to 12 times as fast. That would mean bruit-forcing 34-bit (yes, I uped the work factor by 4x) in about 2 hours. That would mean bruit forcing 40-bit encryption in about 64 hours. This means about 2^31 RC5-16/32/8 key setups and encryptions. If a different algorythm was used, you're probably looking at plus or minus 50% and a lot of assumptions have been made. However 3 days is a reasonable estimate for the time required to bruit force 40-bit encryption on a single desktop purchased today. The problem is infinately parlelizable, and if you cade it right, you can take advantage of SSE/AltiVec to double your speed. This means about 1.5 days if you use the __VECTOR__ aware version of gcc on LinuxPPC. I would guess that a 1 GHz PPC chip is equivalent to a 2 GHz P4 for these kinds of calculations, so an overclocked new iMac could probably crack 40-bit encryption in about 1.5 days, as could a good dual P4 or AthlonXP.
Hmm... if I wrote a portable C encyption cracking benchmark, would /.ers be game for running it on thier home systems? I could make it 32-bit or 34-bit encryption to make sure this story doesn't die before you can post your results. The only thing is I'd need to know the Mac and Win32 header fil names for time().
When I had time, I went and fixed the old keyboard, and rearranged the keys as a Devorak keyboard while I was at it. Unfortunately, the USB-PS/2 dongle that came with my IBM keyboard doesn't work with my Dell PS2 keyboard. However, I currently have the IBM keyboard hooked up to my USB port and my old Dell keyboard (with rearranged keys) as my PS/2 keyboard.
Luckily, keybdev.c (both the one in drivers/input and the one in drivers/usb) is astonishingly short. There's all of about 5 functions in there and most of the complexity is hidden in other modules.
The USB keyboard driver interfaces the PS/2 subsystem IIRC (don't know where I read this, maybe the hid.c documentation on linux-usb) so you can't have seperate keyboard mappings, unless you munge the keycodes inside the USBdriver. As long as you don't lock up your USB keyboard driver or have a buffer overun, you should always be able to restart.
I have LILO (GRUB, actually) setup to boot me into either a 2.2.20 kernel or a 2.4.17 kernel. That way, I can ensure that my hacked module won't be loaded by hotplug if I screw it up.
The Steps I took /usr/src/linux (after untarring the 2.4.17 source) and changed the line near the to from "EXTRAVERSION = " to "EXTRAVERSION = -maxmodular"
this changes the name of the kernel from vmlinuz-2.4.17 to vmlinuz-2.4.17-maxmodular and
makesa seperate directory in /lib/modules for your hacked modules. (I called it maxmodular because I even made the "misc binary support", "a.out binary support" and "floppy drive support" as modules.) Potential Gottcha: IDE support is no enabled by default, and comes after the IDE-parport questions in the config menu, so I must have recompiled 10 times trying to figure out why it couldn't mount the root partition.
Downloads I downloaded the 2.4.17 source code and used apt-get to install kernel-package (makes Debian kernel packages, so your nightly apt-get upgrades won't destroy your work).
Renaming I went into
Snooping arroundI poked around the drivers/usb/ kernel source and documentation some to try and figure out what needed to be hacked. I incorreclty identified drivers/usb/keybdev.c and after none of my printk's worked, I tried drivers/input/keybdev.c (this does not affect the PS/2 keyboard).
Printk() is your friend. Add printk()s (printk() works just like printf(). Make sure to do your kernel module insertion from a non-X virtual terminal to minimize the time it takes prints to get to you in the case of an impending crash.) to the beginning of every function in the driver, letting you know that it's being called (and optionally the arguments). Then recompile and load your module. This gives you a feel for how the driver works and confirms that you have the right driver.
Trim prink()s to only print out the information you need. In my case, I got rid of the printks from everything but the keyboard event handling function and the emulate_raw function kalled by the event handler. I printed out every keycode that was pressed (but not it's release) so that I could write down the keycode for each key I needed to remap. (And some of the neat colorful buttons IBM added above the funtion keys. I later used these to turn on and off the devorak remapping and turn on and off the printks in my module.
After that, what you do is pretty specific to your module. For keyboards, they send a 16-number, called a scancode that is one of the arguments to the keyboard event hadler function. All of the normal keys have scancodes less than 256, so I just made an unsigned char[256] usb_key_remap_table and did something like
if (code < 256 && code >= 0) {code = usb_key_remap_table[code];}
The more astute amoung you will remeber that I'm only remapping the USB keyboard, which is my good keyboard and therefore unmodified. Oh well, I figure having the incorrect letters written on the keys discourages me from looking down.
Anyway, the USB subsystem seems very readable for the higher level drvers and USB keeps getting more and more devices, so I'd recomed starting with a USB subsystem... too bad RadioShack is out of USB cue:cats :-D
You could claim that the confused deputy problem is a result of sloppy sanity checking, but very few compiler programmers would think anyone would be insane enough to type "cc MySource.c -o /etc/cc/compiler-time-billing-log.txt". It's a subtle case that would only be the result of malicious users and a case that is only covered in security litterature and security classes. You really can't fault the programers for missing that one.
Yet another instance of Apple being ahead of its time. The fanless G4 cubes had the CPU in contact with the side of the case and a little thermal paste. See the slashdot article about converting the cubes to run dual G4s; they had to add some metal to the case to get both CPUs in contact with the case.
Now... if only I could find G4 CPUs and G4 mobos on pricewatch... :-)
If anything Unix needs to push it over the top as far as a secure server operating systems is the ability to tell the OS that "This File can never be deleted and can only be appended to by ...
More importantly, I think UNIX needs a better security model. Right now one of the big problems is that all of your executables have the same permissions that you do. In a capability based system, your email program may own capabilities for reading its configuration files, but an open() on a file owned by the user would require active user input to succeed. (Someone wrote a paper about using a Windows-like GUI to make capabities more understandable to the user, but I can't find the url at the moment.)
In any case, here are some links.
"E", a capability-secure language.
Capabilitiesvs. Microsoft's signed execuatables solution. (Part of a good introduction to capabilities).
Linux Kernel Capabilities vs. the standard definition of capabilities.
False. One of the criteria for a strong encryption algorithm is resistance to known plaintext attacks. For symetric key algorithms this means the fastest attack is bruit forcing all of the keys, even if you have an arbitrary ammount of known plaintext. In other words, you cannot recover the key any faster than guess-and-check. For AES with a 256-bit key, this means an average of about 32,000,000,000,000,000,000,000,000,000,000,000,000 ,000,000,000,000,000,000,000,000,000,000,000,000,0 00 tries. All of the world's computers (assuming current trends, and remembering that symetric ciphers are not obviously broken by quantum computation) will not cover this many keys until long after the formaldehide diffuses out of your corpse and soil microbes have devowered all but your coffin.
Case 4 is correct. They've taken WINE and improved it a bit without releasing changes back to the community. I'm not even sure WINE will get much recognition out of it. This has caused some people to push for future releases of WINE under the LGPL instead of the current BSD-like liscence.
WINE had been getting along pretty well. Let's hope MS doesn't return to the old "The Job's not through 'til it doesn't run on OS/2!" days.
I breifly looked at the exploit code and it looks like the cient and server may be using nonces to provide very week message integrity. However, as the poster implied, non-filtered IP networks are still vunerable.
Good idea about making an image of the message and stegoing that into an image, except that the stego content is typically much smaller than the original file size. Encrypting before using stego should make it much less detectable. I would guess that any intelligent stego search would include checks for standard file headers.
There's also inertia in the teaching world. What percentage of the Mech. E. professors were arround before OOP was widely accepted? How many of them have gone back and learned to do OOP properly? If the profs and masters of industry haven't learned OOP, then the advanced codes will be in C/F77. You go to learn about the advanced coding, and you end up learning how to do all of the advanced stuff in functional languages.
For the beginning student, the fastest way to learn to code up some problem is C or Java with only one object. Once a student is proficient in one language, most of them will push as far and fast as they can in their subject matter instead of learning to code better or learning a new language.
OOP is mainly necessary as a tool to clean up large programming projects to make them manageable and to help keep you from hurting yourself through disorganization. OOP really shines when you're doing a lot of dynamic allocation and freeing of data, as destructor methods are a big help in preventing memory leaks. The really big Mech. E. codes (FEA) are gigantic matrix inversions. (There are some other methods, but FEA is by far dominant.) There are plenty of C and F77/F90 libraries out there to handle the messiness of matrix manipulation for the coder. And, truth be told, matrix manipulation is not messy at all by comparison. You have a large ammount of memory allocation at the beginning of the executable, but then you just manipulate the data you have for a while, save your results, and exit, perhapse without even free()ing your matricies.
On the extreme end, some people may not want to take the small performance hit in going from C to C++. For compuationally intensive tasks, I believe you still take a 10x hit going from C/C++ to Java. The MIT 6.270 Lego robotics contest still gets won by teams that use purely mechanical methods of steering (the winner ~3 years ago) or use a single java object and do functional programming inside that object. The boards are still a bit too underpowered to pull a full JVM on top of NetBSD and not care about the various OOP overheads. Some teams use huge switch statements to virtually illiminate method calls. For small projects, this can be done without sacrificing too much robustness, and the performance gains are noticable.
I'm also looking at some of the other MIT couples I know and wondering if their children have a very high risk of autism. As a t-shirt from a nearby women's college (Wellesley) says "MIT men: the goods are odd, but the odds are good." Maybe the old MIT frternity saying "B.U. to bed, Wellesley to wed, and MIT to talk to." has some positive implications for the gene pool in the Boston area :-) (Sorry, I know MIT girls really hate that saying. Stereotypes are just stereotypes. My MIT GF is simply the best.)
I wonder if there is also a higher risk of autism among children of two mechanical enginners. I was drawn to mechanical engineering because of a fascination with complex machines and an appearent ability to model three dimentional machines in my head much better than my peers. (This sounds a lot like one of the autistic people quoted in the article.) Granted, mechanical engineering is considered one of the easier subjects at MIT, so you get some wash outs from other programs diluting the field, but I wouldn't be surprised if mechanical engineering couples from top schools have a much higher incidence of autism, provided the theories layed out in the article are correct. Mechanical engineers should be a self-selecting group of 3D visual thinkers.
As an aside, is it true about what I've heard about yelling out "LSC" in a movie theater in Silicon Valley? (It's been an MIT cultural thing for at least 15 years now.) How often do you get the propper repsonse from more than one person in an audience? If any of you are curious and want to try it, please do so only when the screen is black before the previews begin or when there is a screw up that has already distracted the audience.
Hey is it just me, or deos it seem like at least 2% of the regular slashdot posters are MIT students?
I think you mean gnu/kernel32.dll ;-)
Yeah, NeXT was waayyy ahead of it's time. The same thing goes for apple, just somewhat less so. As my friend Eric said, "Apple's problem is that it tries to sell stuff that's ahead of it's time to people who don't appreciate it." I REALLY like Apple hardware, and if I weren't a poor college student, I'd have a G4 machine (or a used UltraSPARC). Did anyone notice that the slashdot article last week about the dual CPU machines for artists had some benchmarks with dual 400 MHZ G4s lagging not so far behind dual 1.7 GHz Xeons?
Now, if only Apple would throw a more modern micokernel (caugh port l4 caugh) under Darwin, I'd pretty much be forced to sell my soul for a new machine. Provided of course, the kernel was still open source.
Microsoft wanted NT to be a microkernel OS, but they couldn't quite pull it off for performance reasons. Apple managed to pull it off with an old microkernel. Imagine how OS XI would fly with a higher performance (and smaller and simpler) micokernel under the hood.
Warning: Micokernel rant
I don't mean to start a flame war, but Mach has way too many features to make implementation and optimization easy. Small micokernels rock! I had to benchmark the memory latency of several systems for my systems design class. I chose my personal box running Linux and my personal box running QNX for two of the systems. Linux showed the expected gradual transition from cache latency to RAM latency as the size of the buffer used in the benchmark approached the cache size. However, under QNX the memory latency managed to stay very low until the benchmark buffer size got very close to the cache size, and then there was a rapid transition to the RAM latency. This shows that small microkernels are more resistant to cache thrashing (yes, I did boot Linux into runlevel 2 and kept applications to a minimum) because you have fewer bites of kernel code that are continually pushing stuff out of the cache. I'm not sure why the user-level servers didn't offset this. Maybe QNX tries to buffer system requests and run the user-level servers in batches for performance reasons. In any case, there was a marked difference in the benchmarks on the same hardware. If you combine this with L4's very fast messge passing, modern microkernels make a lot more sense than older microkernels like Mach. If you've got x86 or ARM hardware, check out the L4Ka site. Uwe posted an updated snapshot of the Hazelnut implementation of L4 today. (Supposedly the IPC is blazingly fast. I don't know how they teaked their C to be faster than Jochen's x86 assembly kernel but they did it. I suppose that with only about 11 system calls, you have a lot of time to tweak them all.) It's been almost a year since the last snapshot was posted, but the mailing lists show that devlopment is going strong. L4 really shows the elegance of simplicity. It has a very small set of well designed features that are very flexible and powerful, which allows L4 to get away with fewer than 10% of the number of system calls used by Mach.