yeah... I've lost count of the number of throw-away passport accounts I have. Under WinXP, don't you pretty much have to have a passport account to get IE to show you webpages? This is the most irritating thing aobut setting up XP, according to my friend Justin. (Yes, he did look arround a little. He declined to setup a passport account on install, but his first attempt to view a webpage broughtback the passport dialog.)
The whole point of Free software is you can't get locked in. The FSF starts being monopolistic jerks, take the source to someone who'll do it for less/under better terms.
Enough people use GTK that it will be ported to The Next Big Thing(tm). Essentailly, the FSF people have intentionally lost controll of all of thier software. They keep just enough controll to keep someone else from seizing controll of it. There is no vendor lock-in any more than there is vendor lock-in for wav audio or mpeg video. Very low barriers to entry means that you don't get locked in.
A funny story: the another roomate in the same place was into ISOs on IRC. Someone in the channel had a rare Japanese market game
ISO. My roomate asked the guy what he wanted. The roomate then copied his windows swap file to whatever.iso (where whatever was
the name of the game the guy wanted). They then swapped "ISOs". A day later our firewall was DOSsed. We figure the guy didn't take too
kindly to the trade:)
His swap file? Did he grep his swap file to make sure IE didn't swap out his credit card number recently? His home address? Passwords? Site membership username/password pairs? Network crypto credentials? His home machine LanMan and md4 password hashes?
Your friend is a bit too brave and/or not quite smart enough. There's a reason you can encrypt your swap in *BSD and Linux.
He should have half expected to wake up the next morning to a cubic yard of elephant dung and a baker's dozen of giant monogrammed pokemon vibrators charged to his credit card and shipped overnight to his mailing address from central Mongolia. He would have deserved it, I might add. He could have at least tried to get the file on an IOU basis. It's not like the other guy's bandwidth cost him more than his time. If I were the other guy, I'd take the oportunity to make a friend. No skin off my back and a quite useful philosophy. Of course, if your friend enjoys Mongolian elephant dung, giant vibrators, and DOS attacks, who am I to judge?
Correct. Also don't forget that Linux et. al constantly gather entropy from your mouse movements, network traffic, HD seek times (influenced by turbulence inside the drive, providing "true" randomness).
Try writing a program that takes several hundred MB from/dev/random. You'll find its runtime depends on how much mouse movement and other user input is going on. I once ran a random acess file system simulation for class. I went to dinenr and came back and the stupid thing was stuck. I later emailed the prof to let him know he should use/dev/urandom instead of/dev/random if he's not hyper sensitive about the entropy content and needs time-critical random data.
Off hand, what PRNG does the Linux/dev/urandom use when it exhausts the entropy pool? My best bet is that OpenBSD uses Yarrow, but all bets are off with Linux.
If you wanted a physically remappable keyboard, do it in software.
You'd have to "re-train" the drver every time you wanted to remap your keys,
but otherwise it would be prohibitively expensive and less reliable.
Have you taken appart a modern keyboad? There are mainly two kinds of switches they use for the keys nowadays. One type uses three layers of plastic film and the other uses little rubber nipples. I'll spare you the details 'cause if you care, you've already looked. The way I see it, if you were going to use a pure hardware solution for rarranging the keys, you could have up to 127-key keyboards with 7 switches per key. Unfortunately, neither common type of keyboard switch would maintain it's reliability and durability if its foorprint was reduced to 1/7 its current value. (For intance, you'd have to reduce the height of a nipple to 1/7 it's current value as well, to prevent buckling. This would mean minor bumps and vibrations would be likely to trigger key presses.) You'd get a buggy keyboard.
Therefore, you'd need a more novel way of distinguishing keys. You could put an rf tag on each key and put a low power antenna across the entire keyboard backplane so that the tag would onlybe detctedif the key was very close to the backplane. This would be subject to interference. (Set your keyboard on your monitor or speakers and come back from lunch to see 1,000 pages of jibberish.) You could do an optical eqivalent of this, but keyboard spillswould be much more of a problem, and waveguides are more expensive than simple antennas made from circuit traces.
THe way I see it, the only cost-effective way to do what you want is to have a wizzard say "press A, now press B, now press C... now press F1... now press Help,,, now press Internet Shopping... now press Internet". Otherwise, you increase the cost of the keyboard at least 10x.
freenetproject.org can help you out. It was designed from the ground up with plauable deniability in mind. It's really really hard to track down, much less prove in a court of law, who is putting what on freenet.
Otherwise, if security is a concern, why not just set up a VPN between the client and your company and have the FTP go through that?
One compromised machine or one inside operator and the whole house of cards comes crashing down.
Kerberos is nice IFF you enforce strong passwords. Session integrity is only protected by the password (via string-to-key and excryption of your ticket-granting ticket and associated session key). Kerberos is very suceptable to ofline attacks if you have weak passwords.
There's the crux. If we actually start torturng the
terrorists with MSCE Reeducation, thn the Russians, Germans,
Finns, etc. may pullout of our alliance. We need to just intern
them in POW camps until the war has gone on long enough that
our allies are pissed off enough at the terrorists to look the
other way on torturing them.
Java BigInteger.isProbablePrime(int) !
on
Pet Bugs?
·
· Score: 2
A friend and I were implementing Diffie-Hellman cryptographic key
exchange and so we needed a large prime number p such that (p-1)/2
is also prime. We looked up the prime used for the Secure Remote
Password protocol and double checked that it had the properties we
wanted. According to BigInteger.isProbabePrime(int), (p-1)/2 is prime,
but not p. We emailed the author of the protocol spec and he
graciously provided us with some proper primality tests. My own
clean-room impleentation of the Miller-Rabin primality test agrees
with the code we were emailed. We also got a short explination of
what the problem was. The funny thing is that my own MIller-Rabin
test is faster and more accurate than BigInteger.isProbablePrime.
Also, one of the earlier JDKs (1.2, I want to say) implements
isProbablePrime() correctly. It is broken in the 1.3 and 1.4 JDKs.
Probabilistic primality tests are supposed to have a miniscule chance of declairing a composite number prime, and zero chance of declairing a prime number composite.
I guess it's nice that the Java implementation errs on the side of safety, but
it's silly that my Miller-Rabin test is faster and more accurate. The code I was sent works even faster. (The SRP people offered to email me some kind of proof of
primality for the number. I'm not sure how that works, but thier
code agrees with the stuff I coded up from Applied Crypto, so I'm
pretty convinced Sun goofed.)
<OT>
Does anyone know a way to get a File object or an InputStream object for
a file contained in a jar archive? This is my current reason
for wanting to hurt the Java engineers. I'm trying to load an image
out of a jar archive. The best solution I've come up with so far is to
use Class.getResource(String) to get me a URL and then use java.awt.Toolkit.getImage(URL)
</OT>
The games run in ring 0. Under any decent PC OS, even your setuid root
programs run in ring 3. If, for instance, you're running IIS (which runs in the System security context, IIRC) and IIS gets a buffer overflowed, the attacker has to upload and install a trojaned driver (or find and/or install some other flawed/maiicious ring 0 code) if s/she wants to overwrite, say kernel32.dll's memory space. Many imbedded systems, including the XBox do not have memory protection in place.
Think of ring 0 as the hardware version of root priveledges. Infact, the software protections that enforce the system security policy would not be possible without all of the user's code running outside ring 0.
Then they just distribute bad metafiles that claim thousands of users are spreading bad files. I like the "web of trust" idea, where I keep a budy list, and my search results are ranked by the number of degrees of seperation via buddy lists.
Ehh... they believe the Dead Sea Scrolls were hidden away in 68 C.E. The Dead Sea Scrolls contain fragments from all of the Old Testement books except Ester andcontains a nearly complete copy of Isaiah, IIRC. Maybe the earliest complete work is from 300 C.E., but there are much earlier framents that match pretty well what we have today.
Where have you read about systematic destruction? IANAJ, but it's my understanding that
at least the first 5 books were coppied very carefully, with someone double-checkinthe scribe's work and something like 3 wrong letters allowed before the copy had to be destroyed. Once an old copy got to tattered to be readable, it had to be destroyed to
prevent bad copies from floating arround. Is this the systematic destruction you speak
of? My reading of you post sounds more like some kind of evil rabinical conspiracy. Once again, IANAJ. (Not that there's anything wrong with being Jewish.)
Don't forget that the LanMan hash you're talking about converts everything to upper case and doesn't use a salt. I have no idea which idiot at MicroSoft came up with that scheme after the UNIX crypt password scheme had been out for a long time. LanMan is obviously based on crypt (itteratively encrypting a known string with DES, using the password as the encryption key), but it's much worse (except that it can use extended ASCII characters, but this doesn't help much at all since 99.99% of people don't go outside ASCII for thier passwords). There's a newer NT hash based on md4 (yes, md4, the precursor to md5) that also does not use salts. When will MS learn?
Somewhat On-topic: 1024+ bit C math library,where?
Gnu MP for mult-precission numbers. They use the fastest known algorithms and hand-optimized asm on most platforms. I prefer to do crypto in Java and use the BigInteger class 'cause I'm lazy.
FYI, Sun's BigInteger.isProbablePrime(int) function is broken... don't use it. I was rather embarassed when a collegue and I emailed some people about a possible bug in the Secure Remote Password protocol, only to discover the problem was a known bug in the JVM... which Sun refuses to fix. I don't know why they won't fix it. My personal implementation of the Miller-Rabin primality test runs faster and correctly identifies the SRP modulus as probably prime. (Look in Applied Cryptography by Schneier for how to code it up.)
Fisrt of all, VLIW instructions aren't complex. They're a bunch of RISC instructions taken together as a block. You could make a non-supersclar RISC CPU to run the TM8000 instructions, it'd just take *almost* 8x as long. (It's hard to find 8-way parallelism. I think superscalar x86 CPUs pretty much max out at an average of 2.5 way parallelism. Maybe the TM8000 is using SMT to run two threads on the same chip. Maybe tehy dedicate one of the threads to code-morphing and runtime optimizations)
It does hurt them that they code morph on the same chip that they run the x86 software on. However, they can get away with it becuase they can cache the translated code segments. Self-modifying code and stuff with "debugger bombs" in it may destroy performance and/or prevent proper execution. In general, though, they get saved because, on average, 90% of the time is spent in 10% of the code. This means their translation cache gives them a huge performance boost in most applications. The P4 also uses an on-chip microOp translation cache, probably creating huge savings in terms of power usage due to the x86 decoder unit.
In it's purest form, VLIW would be like taking several MIPS chips and giving them the same cache and register file and demuxing the instructions out to the different chips. The chips would trust the compiler and not check for data dependancies.
Itanium doesn't know what it wants to be. Intel doesn't call ia64 VLIW, they call it "EPIC : Explicitly Parallel Instruction Computing". It's a beast with lots of registers (RE: really long context switches. The ia64 Linux porters decided to cut down on the number of user-space avalable registers in order to shorten context switches.) and register windowing (windowing didn't help SPARC very much, and eats up a fair number of transistors). On the other had, they neglected to give it a full floating point unit, so any floating point op causes an FPSWA (floating point software assist) interupt. Furthermore, the decided not to match the instructions to the bare hardware, but instead made the CPU pretend to hav infinately many execution units and inserted some flags in the instructions to indicate where the parallelism breaks. This is needlessly complex. Don't ofrget on-chip slow-ass x86 emulation. Do a google search for Elburus, or look backa couple of days on/. They've gotsome good arguments about why EPIC (and Itanium, in particular) is worse than VLIW. They also say their approach is better than the Transmetta approach, but say Transmetta is onthe right track. Basically, they would like to see a partiall static and partialy dynamic recompilation solution rather than an all-dynamic solution used by Transmetta. I think the Elburus approach is better for geeks, but may be hard to make seamless for the general populace.
But I think it's safe to say that an L4-based kernel would be better than Mach, even if written in C++. A well-optimized design is more important than well-optimized code.
The latest "Hazelnut" L4 kernel (written in C++) finally passed the fastest L4 x86 assembly kernel for interprocess communication performance. This is very important for microkernel performance, since many things traditionally handled by system calls (setting some registers then trapping an interupt in the kernel) are instead handled via IPC with user-space drivers. I'd like to point out that without some crazy high-level macros in your compiler, it still seems like you need a minimum of about 32k of your ring 0 code is written in assembly (on x86) to properly manipulate the hardware. (You could come up with some funky architecture where not all of your ring 0 code is in what you call the kernel. Doesn't NT/2K/XP have some non-bootstrapping ring 0 code outside of kernel32.dll?) (This is from what I remember of L4 and QNX documentation.)
Have no fear, the X.2 API is bein sorted out. People are holding off on porting the HURD to L4 until the L4 X.2 API is finalized. My guess is that porting will begin this Summer.
Do you think you'd feel silly if you found out it actually runs on Linux?
At least as of last year, Carnivore/DCS-1000 ran on NT 4.0 (not sure which service pack). Yeah, the poster prbably would be a little embarassed if s/he discovered Carnivore was deployed on Linux, but the poster need not worry. Most people arround here know that Carnivore runson NT 4. That's part of a lot of people's concerns. I'd feel much better if my government used more robust means to collect evidence. If someone cracks a Carnivore box, it comes with nice GUI tools to facilitate blackmail and information theft.
The FBI comes in with the box and hooks it up to the same LAN as the mail server to be monitored. I think it sniffs traffic instead of passing all of the traffic in one NIC and out another.
Don't forget about the 32 rings of protection on the Honneywell hardware instead of the 4 found on i386. As long as you have 2 rings, you can emulate as many rings as you want, but it's slow and a PITA. MULTICS was a beast of an OS that need a beast of a machine. Thank G_d your classic arcade machines didn't run MULTICS, or it'd take decades to write a good efficient emulator to run them.
So, would owning the net mean that my ISP would be obliged to give me some sort of discount on what I'm paying them every month?
Kinda... I hear the net acess is free in "federal pound-me-in-the-ass" prisons, so you could think of it as a 1000% rebate on $0, after they figured out who 0wn3z the net and locked you up.
Re:Security is impossible
on
California Hax0red
·
· Score: 3, Insightful
Ehh... critical servers should stand on their own. There are always inside jobs or ways arround firewalls. Firewalls should be the backup plan. Too many people think "on, no, it's not behind a firewall" and "oh, don't worry about it, it's behind a frewall". If you're not extremely confident that your critiical server could survive outside the firewall, you need to start ripping software components out of the system. MIT Network Security's policy is to never deploy firewalls. They continually port scan all of the machines and run vulnerability checks against the latest bugs.
Perfect security is impossible, but firewalls are bandaidsfor bullet holes. Don't fool yourselves. A good IDS box is much more usefull than a good firewall, or at least should be if you're doing htings right.
>I don't know how this fits in with keys being leaked from Dell, though.
MS gives big convinience breaks to big companies. Thier "datacenter" program makes you a custom XP install CD, and I think that requires no keys, to facilitate rapid installation without the admin having to sit there and type things in to the console.
In similar ways, I wouldn't be surprised if the keys given to OEMs don't require acess to the outside world for verification. (You have to type in the product key from teh sticker the first time you boot a new Dell, right?) I would imagine MS would get swamped with calls if every Dell customer without an internet connection (and some people with modems that don't want to waste ISP minutes on registration) had to give them a call. It's a small percentage, but a small percentage of a lot of people.
Of the (true?? I think I read this for my computer systems engineering class) story about the australian company that wrote battlefield simulation software. They were preparing to show off the stuff to some American military personaell,so they decided to add some brand recognition by adding cangaroos to the demo. They only had a week or two to get the demo going, so they took a standard infantryman object, subclassed it, changingthe graphics, upped the speed alot, and upped the tendancy to panic alot.
Durring the demo, the helicopters spooked the kangaroos as planned, and they ran off at lightning speed, only to regroup and come back at lightning speed and fire stinger shoulder-launched andti-aircraft missles back at the helicopters. A good example of how code reuse without thought can get you into trouble. At least the visitors thought it was funny.
Slashdot Mirror
yeah... I've lost count of the number of throw-away passport accounts I have. Under WinXP, don't you pretty much have to have a passport account to get IE to show you webpages? This is the most irritating thing aobut setting up XP, according to my friend Justin. (Yes, he did look arround a little. He declined to setup a passport account on install, but his first attempt to view a webpage broughtback the passport dialog.)
Enough people use GTK that it will be ported to The Next Big Thing(tm). Essentailly, the FSF people have intentionally lost controll of all of thier software. They keep just enough controll to keep someone else from seizing controll of it. There is no vendor lock-in any more than there is vendor lock-in for wav audio or mpeg video. Very low barriers to entry means that you don't get locked in.
His swap file? Did he grep his swap file to make sure IE didn't swap out his credit card number recently? His home address? Passwords? Site membership username/password pairs? Network crypto credentials? His home machine LanMan and md4 password hashes?
Your friend is a bit too brave and/or not quite smart enough. There's a reason you can encrypt your swap in *BSD and Linux.
He should have half expected to wake up the next morning to a cubic yard of elephant dung and a baker's dozen of giant monogrammed pokemon vibrators charged to his credit card and shipped overnight to his mailing address from central Mongolia. He would have deserved it, I might add. He could have at least tried to get the file on an IOU basis. It's not like the other guy's bandwidth cost him more than his time. If I were the other guy, I'd take the oportunity to make a friend. No skin off my back and a quite useful philosophy. Of course, if your friend enjoys Mongolian elephant dung, giant vibrators, and DOS attacks, who am I to judge?
Try writing a program that takes several hundred MB from /dev/random. You'll find its runtime depends on how much mouse movement and other user input is going on. I once ran a random acess file system simulation for class. I went to dinenr and came back and the stupid thing was stuck. I later emailed the prof to let him know he should use /dev/urandom instead of /dev/random if he's not hyper sensitive about the entropy content and needs time-critical random data.
Off hand, what PRNG does the Linux /dev/urandom use when it exhausts the entropy pool? My best bet is that OpenBSD uses Yarrow, but all bets are off with Linux.
You'd have to "re-train" the drver every time you wanted to remap your keys, but otherwise it would be prohibitively expensive and less reliable.
Have you taken appart a modern keyboad? There are mainly two kinds of switches they use for the keys nowadays. One type uses three layers of plastic film and the other uses little rubber nipples. I'll spare you the details 'cause if you care, you've already looked. The way I see it, if you were going to use a pure hardware solution for rarranging the keys, you could have up to 127-key keyboards with 7 switches per key. Unfortunately, neither common type of keyboard switch would maintain it's reliability and durability if its foorprint was reduced to 1/7 its current value. (For intance, you'd have to reduce the height of a nipple to 1/7 it's current value as well, to prevent buckling. This would mean minor bumps and vibrations would be likely to trigger key presses.) You'd get a buggy keyboard.
Therefore, you'd need a more novel way of distinguishing keys. You could put an rf tag on each key and put a low power antenna across the entire keyboard backplane so that the tag would onlybe detctedif the key was very close to the backplane. This would be subject to interference. (Set your keyboard on your monitor or speakers and come back from lunch to see 1,000 pages of jibberish.) You could do an optical eqivalent of this, but keyboard spillswould be much more of a problem, and waveguides are more expensive than simple antennas made from circuit traces.
THe way I see it, the only cost-effective way to do what you want is to have a wizzard say "press A, now press B, now press C... now press F1 ... now press Help ,,, now press Internet Shopping ... now press Internet". Otherwise, you increase the cost of the keyboard at least 10x.
freenetproject.org can help you out. It was designed from the ground up with plauable deniability in mind. It's really really hard to track down, much less prove in a court of law, who is putting what on freenet.
One compromised machine or one inside operator and the whole house of cards comes crashing down.
Kerberos is nice IFF you enforce strong passwords. Session integrity is only protected by the password (via string-to-key and excryption of your ticket-granting ticket and associated session key). Kerberos is very suceptable to ofline attacks if you have weak passwords.
Would some AC be so kind as to post XBox MAME to Freenet and post the key here anonymously?
There's the crux. If we actually start torturng the terrorists with MSCE Reeducation, thn the Russians, Germans, Finns, etc. may pullout of our alliance. We need to just intern them in POW camps until the war has gone on long enough that our allies are pissed off enough at the terrorists to look the other way on torturing them.
Probabilistic primality tests are supposed to have a miniscule chance of declairing a composite number prime, and zero chance of declairing a prime number composite. I guess it's nice that the Java implementation errs on the side of safety, but it's silly that my Miller-Rabin test is faster and more accurate. The code I was sent works even faster. (The SRP people offered to email me some kind of proof of primality for the number. I'm not sure how that works, but thier code agrees with the stuff I coded up from Applied Crypto, so I'm pretty convinced Sun goofed.)
<OT>
Does anyone know a way to get a File object or an InputStream object for a file contained in a jar archive? This is my current reason for wanting to hurt the Java engineers. I'm trying to load an image out of a jar archive. The best solution I've come up with so far is to use Class.getResource(String) to get me a URL and then use java.awt.Toolkit.getImage(URL)
</OT>
Think of ring 0 as the hardware version of root priveledges. Infact, the software protections that enforce the system security policy would not be possible without all of the user's code running outside ring 0.
Then they just distribute bad metafiles that claim thousands of users are spreading bad files. I like the "web of trust" idea, where I keep a budy list, and my search results are ranked by the number of degrees of seperation via buddy lists.
Where have you read about systematic destruction? IANAJ, but it's my understanding that at least the first 5 books were coppied very carefully, with someone double-checkinthe scribe's work and something like 3 wrong letters allowed before the copy had to be destroyed. Once an old copy got to tattered to be readable, it had to be destroyed to prevent bad copies from floating arround. Is this the systematic destruction you speak of? My reading of you post sounds more like some kind of evil rabinical conspiracy. Once again, IANAJ. (Not that there's anything wrong with being Jewish.)
So you need to do a destructive read. That doesn't mean that a software bug won't cause multiple reproductions of that read state.
Don't forget that the LanMan hash you're talking about converts everything to upper case and doesn't use a salt. I have no idea which idiot at MicroSoft came up with that scheme after the UNIX crypt password scheme had been out for a long time. LanMan is obviously based on crypt (itteratively encrypting a known string with DES, using the password as the encryption key), but it's much worse (except that it can use extended ASCII characters, but this doesn't help much at all since 99.99% of people don't go outside ASCII for thier passwords). There's a newer NT hash based on md4 (yes, md4, the precursor to md5) that also does not use salts. When will MS learn?
IRIX 6.5 also uses crypt passwords. Shadowed passwords are not on by default. You may want to fix that.
Gnu MP for mult-precission numbers. They use the fastest known algorithms and hand-optimized asm on most platforms. I prefer to do crypto in Java and use the BigInteger class 'cause I'm lazy.
FYI, Sun's BigInteger.isProbablePrime(int) function is broken... don't use it. I was rather embarassed when a collegue and I emailed some people about a possible bug in the Secure Remote Password protocol, only to discover the problem was a known bug in the JVM... which Sun refuses to fix. I don't know why they won't fix it. My personal implementation of the Miller-Rabin primality test runs faster and correctly identifies the SRP modulus as probably prime. (Look in Applied Cryptography by Schneier for how to code it up.)
It does hurt them that they code morph on the same chip that they run the x86 software on. However, they can get away with it becuase they can cache the translated code segments. Self-modifying code and stuff with "debugger bombs" in it may destroy performance and/or prevent proper execution. In general, though, they get saved because, on average, 90% of the time is spent in 10% of the code. This means their translation cache gives them a huge performance boost in most applications. The P4 also uses an on-chip microOp translation cache, probably creating huge savings in terms of power usage due to the x86 decoder unit.
In it's purest form, VLIW would be like taking several MIPS chips and giving them the same cache and register file and demuxing the instructions out to the different chips. The chips would trust the compiler and not check for data dependancies.
Itanium doesn't know what it wants to be. Intel doesn't call ia64 VLIW, they call it "EPIC : Explicitly Parallel Instruction Computing". It's a beast with lots of registers (RE: really long context switches. The ia64 Linux porters decided to cut down on the number of user-space avalable registers in order to shorten context switches.) and register windowing (windowing didn't help SPARC very much, and eats up a fair number of transistors). On the other had, they neglected to give it a full floating point unit, so any floating point op causes an FPSWA (floating point software assist) interupt. Furthermore, the decided not to match the instructions to the bare hardware, but instead made the CPU pretend to hav infinately many execution units and inserted some flags in the instructions to indicate where the parallelism breaks. This is needlessly complex. Don't ofrget on-chip slow-ass x86 emulation. Do a google search for Elburus, or look backa couple of days on /. They've gotsome good arguments about why EPIC (and Itanium, in particular) is worse than VLIW. They also say their approach is better than the Transmetta approach, but say Transmetta is onthe right track. Basically, they would like to see a partiall static and partialy dynamic recompilation solution rather than an all-dynamic solution used by Transmetta. I think the Elburus approach is better for geeks, but may be hard to make seamless for the general populace.
The latest "Hazelnut" L4 kernel (written in C++) finally passed the fastest L4 x86 assembly kernel for interprocess communication performance. This is very important for microkernel performance, since many things traditionally handled by system calls (setting some registers then trapping an interupt in the kernel) are instead handled via IPC with user-space drivers. I'd like to point out that without some crazy high-level macros in your compiler, it still seems like you need a minimum of about 32k of your ring 0 code is written in assembly (on x86) to properly manipulate the hardware. (You could come up with some funky architecture where not all of your ring 0 code is in what you call the kernel. Doesn't NT/2K/XP have some non-bootstrapping ring 0 code outside of kernel32.dll?) (This is from what I remember of L4 and QNX documentation.)
Have no fear, the X.2 API is bein sorted out. People are holding off on porting the HURD to L4 until the L4 X.2 API is finalized. My guess is that porting will begin this Summer.
At least as of last year, Carnivore/DCS-1000 ran on NT 4.0 (not sure which service pack). Yeah, the poster prbably would be a little embarassed if s/he discovered Carnivore was deployed on Linux, but the poster need not worry. Most people arround here know that Carnivore runson NT 4. That's part of a lot of people's concerns. I'd feel much better if my government used more robust means to collect evidence. If someone cracks a Carnivore box, it comes with nice GUI tools to facilitate blackmail and information theft.
The FBI comes in with the box and hooks it up to the same LAN as the mail server to be monitored. I think it sniffs traffic instead of passing all of the traffic in one NIC and out another.
Don't forget about the 32 rings of protection on the Honneywell hardware instead of the 4 found on i386. As long as you have 2 rings, you can emulate as many rings as you want, but it's slow and a PITA. MULTICS was a beast of an OS that need a beast of a machine. Thank G_d your classic arcade machines didn't run MULTICS, or it'd take decades to write a good efficient emulator to run them.
Kinda... I hear the net acess is free in "federal pound-me-in-the-ass" prisons, so you could think of it as a 1000% rebate on $0, after they figured out who 0wn3z the net and locked you up.
Perfect security is impossible, but firewalls are bandaidsfor bullet holes. Don't fool yourselves. A good IDS box is much more usefull than a good firewall, or at least should be if you're doing htings right.
MS gives big convinience breaks to big companies. Thier "datacenter" program makes you a custom XP install CD, and I think that requires no keys, to facilitate rapid installation without the admin having to sit there and type things in to the console.
In similar ways, I wouldn't be surprised if the keys given to OEMs don't require acess to the outside world for verification. (You have to type in the product key from teh sticker the first time you boot a new Dell, right?) I would imagine MS would get swamped with calls if every Dell customer without an internet connection (and some people with modems that don't want to waste ISP minutes on registration) had to give them a call. It's a small percentage, but a small percentage of a lot of people.
Durring the demo, the helicopters spooked the kangaroos as planned, and they ran off at lightning speed, only to regroup and come back at lightning speed and fire stinger shoulder-launched andti-aircraft missles back at the helicopters. A good example of how code reuse without thought can get you into trouble. At least the visitors thought it was funny.