Your laptop HD is probably 5400 RPM or slower. Resierfs did poorly in these benchmarks primarily because it uses a lot of CPU cycles to get good performance. If you have spare CPU cycles, but your HD is being taxed to the max (as is especially likely in a laptop), Reiserfs will probably work well for you.
I heard that around 1999, there was a course at MIT that pretty much guaranteed you an offer from ArsDigita if you got a decent grade.
There's a decent chance the ArsDigita course was put together by an MIT grad.
Of course, if ArsDigita aren't the people that had their own add-on package for AOL Server and gave a Honda S2000 to the employee that recruited the most number of new employees, then I'm talking about the wrong company.
Bruce is one of the patron saints of cryptography. While I'm sure it wouldn't be fun for him to lose his job, I'm sure he'd do fine. He has an oustanding reputation for inegrity and quality of work. How many 100k+ job offers do you think he'd have within 12 hours of word getting out?
Threatening to fire Schneier is kinda like threatening to fire Knuth. Sure, they might have to take a pay cut, but their "mean free path" is quite low.
Autoupdate is also free. It goes and examines the RedHat ftp mirrors for updates to your installed packages and doesn't require you giving any info to RedHat (expcept in the form of information leaked through traffic analysis).
I think most of the automated tools will cover their tracks pretty well. Most buffer overflows will fork off sh instead of bash. At best, bash_history is an unreliable means of detecting careless intruders.
It has lots of uses nowadays. Cracker-jacks now come with a 40-bit DES decoder ring in the box. Millions of elementary school kids are passing notes that it would take their teachers hours to read. It's one step up from the Vernier cipher they used to use in their decoder rings.
Thank goodness nobody has clued in elementary school kids that a deck of cards can be used for encryption stronger than 80-bits (Schneier's Solitaire algorithm).
I may be missing something, but I thought that even these "sufficiently advanced" encryption algorithms can be more easily broken if the attacker knows both the cyphertext (the encrypted disk) and part of the cleartext. Knowing both, you can recover the key much more easily than a brute-force attack.
Incorrect. A strong encryption algorithm not only resistant to known plaintext attacks, but also itterative chosen plaintext attacks. (Assume the attacker gets to send you something and you have to encrypt it and send the result back to him/her before they submit the next thing for you to encrypt.) Imagine an attacker has a tamper-resisant smart token with an encryption key locked inside and is set only to encrypt. Even though the attacker can make as many arbitrary encryptions as s/he likes, with information gained between each encryption, a strong encryption algorithm will still not allow the attacker to decrypt a message more easily than attempting half of the possible keys (on average). For a 128-bit key, this is 2^127 ~ 130,000,000,000,000,000,000,000,000,000,000,000,00 0. "Not going anywhere for a while? Try a trillion Snickers bars!"
This is believed to be the case for 3DES, Twofish, Blowfish, and RC5 for all key strengths. There is a theoretical itterative chosen plaintext attack that reduces Serpent to an effective key strength of about 192 bits and AES to about 128 bits. I'm not aware of any theorectical attacks against full-round RC6, but it barely has enough rounds to make differential cryptanalysis impractical (or was it linear cryptanalysis?), so a small breakthough could break RC6 wide open. (Yes, RC6 is really a family of encrpytion algorithms with a variable number of rounds, block size, and key strength. I'm referring to the version of RC6 submitted to the AES competition.)
Now, someone posted somethign saying it uses 40-bit DES, which is a really crappy algorithm that most likely would not take the government weeks to crack. However, a known plaintext attack against 256-bit Twofish would probably take the government more than a year. (I've heard that the amount of energy available in our solar system is much less than 2^255 quanta. This means that you'll need interstellar travel to even count to 2^255.)
Quantum computing is one possbility, but last I heard they were up to a whopping 4 qbits and nobody had (yet) developed a quantum algorithm for breaking any of the common block ciphers. With quantum computing, you start out with a quantum sperposition of all of the possible answers and you perform a bunch of quantum manipulations on your q-bits such that the incorrect answers interefere destructively with eachother. Comming up with the proper manipulations is non-trivial.
I would much rather have some standard whereby the HD controller sends a smart-card or PCMCIA card blocks to encrypt and decrypt. If you wanted to upgrade encryption, it would be a simple matter of a different card. Of course, you'd need to copy the data off the drive first. Government employees could have the cards on lanyards around their necks, so they wouldn't forget to pull out the card when they took a break. A set of buttons on the card itself could be used to encrypt and decrypt the encryption key so a stolen card would be useless (assuming the card forgets the decrypted key when it is removed). The buttons would be on the card itself to offer a small amount of protection over trojaned software.
Darwin is not a microkernel. Mach is a microkerel, but Darwin is Mach with the BSD personaility running in the kernel's address space (and I believe the BSD personality runs with the CPU in ring 0/supervisor/kernel mode).
I am unsure if it would be possible to run other OS personalities on top of Darwin. It would be nice if they had a copy of the BSD personality that could run in userspace. I think a lot of people would be willing to trade the speed for stability. Imagine running all of your daemons under one copy of the BSD personality and all of the other apps under another. A bug in the BSD personality would only take out the copy of the BSD personality in which it was triggered. Of course, all of the processes dependent on that copy of the personality would die or become zombies.
The HURD approach is nice. Each driver runs in its own address space, similar to BeOS servers. I had some problems with my BeOS network server dying on a regular basis. With a monolithic kernel like Linux or Darwin, the system would have hung or dropped into the kernel debugger. With a microkernel and monoserver (like L4 with L4Linux, GNUMach with mkLinux, or Mach with a BSD userspace personality) the kernel would have been fine, but all of the processes dependent on the monoserver (nearly everything in most systems) would have been toast, incuding any way to start new processes. Under BeOS, I got a little error message and was able to restart my networking server. The only consequence was that all open network sockets at the time of the crash were toast. My web browser acted just like it would if I pulled out my networking cable and then put it back in a few seconds later.
The main thing I didn't like about BeOS was that it didn't like the way I tried to use semaphores and would kernel panic every time. I eventually got some kernel corruption on disk (I think related to semaphores trouncing all over the running kernel's address space). I woke up one morning to my floppy drive running constantly. The floopy had been spinning for hours and had a notch in it. The floppy drive was ruined. I tarred up my browser bookmarks and reinstalled the OS. It turns out that the BeOS webbrowser stores the URLs in the metadata of the bookmark files, which doesn't get coppied by tar. Whoever decided to make bookmarks zero-size files with _all_ of the data in the metadata fork should be shot.
Whoah... you switch from criticizing Stallman for not being innovative to more or less claiming all free software developers aren't innovative (at least lately).
As for the "most" clause. Most commercial software isn't innovative (looking at a product from a distance), either. There are few innovations in any human endevour. We know pretty good ways of doing almost anything. The unwashed masses don't want innovation, they want comfort. Comfort often stifles innovation.
X11, Kerberos, AFS, Emacs, the BSD IPv4 stack, etc. aren't very new, but they are all very good systems that have stood the test of time.
More recntly, the Python language and Zinc (the virtual machine used by non-native O'caml object code) are pretty innovative. Last I checked, a member of the L4 microkernel family had the fastest IPC of any x86 kernel. Two-kernel-monte has been around and I hear is being integrated into the main branch of Linux 2.6 (under a new name). I'd like to see
prior art (from a commercial product) for swapping kernels without restarting or a usermode port of a full OS kernel. Blowfish, Twofish, and Helix have been Free algorithms from the start.
My primary areas of interest are cryptography, kernels, and virtual machines. If you dig deep enough in almost any software subfield, I would guess you will find free software innovation that could not be ouched by commercial entities because it is too speculative.
FreeNet and IIP are also pretty innovative and we're seeing commercial P2P apps starting to follow suit.
Yes, most OSS is not innovative, but that is the nature of software. Unless you're a Mechanical Engineer that designs food processors, you probably can't see much innovation in food processors in the past 30 years. Unless you're a Petroleum Engineer, you probably can't see much innovation in oil wells in the past 50 years. We've simply gotten to the point that big innovations are very rare in most fields. This is the case for most mundane software people use in their everyday lives.
an Indy is probably best compared to a Pentium Pro or PII. Indys came as fast as 180 MHz, and use 64-bit CPUs (MIPS R44000, R4600, or R5000) with relativey low instruction latency. Clock for clock, they probably perform somewhere beteen x86 and PowerPC chips, except maybe for 64-bit integer operations (which would need to be emulated on x86 and pre-G5 PPC).
What I don't understand is that at the same time, the developers are talking about changing the way that the IDE drivers work so that they use the SCSI driver backend processing routines.
SCSI is a more flexible protocol than IDE (according to my friend that used to do kernel development at EMC). The SCSI back end is probably fairly close to what they want for a generic nonvolatile storage back end. They can increase reliablility and reduce the size of the kernel (both the source and any binary that is compiled for both IDE and SCSI) by refactoring allof the common HD functionality into a generic back end. This may or may not minimally hurt performance in the short run, but will increase performance by increasing development speed in the long run. This would also greatly increase the amount of testing and stress testing on a good chunk of the SCSI back end.
I doubt they want to use some of the SCSI back end for IDE b/c it's SCSI. Rather, they want to use some of the SCSI back end for IDE b/c the SCSI backend is probably pretty close to a generic storage back end.
While we're on the subject, does anyone know of an IDE RAID controller that pretends to be a normal SCSI controller with a single device attached? How much of the normal IDE CPU load gets offloaded into a typical IDE RAID controller? I would assume the easy way to offload most of the IDE CPU load would to have the controller emulate a SCSI controller.
Can anyone point to some relatively unbiased scientific studies that show ultrasonic mosquito repellers or ultrasonic rodent repellers work?
Then again, ever since I took wilderness survival merit badge at Tomahawk Scout Ranch, I got used to being bitten. I stopped wearing DEET when I realized it solvated the logo on our troop t-shirts and ruined other plastic items. The dirty oily feel of rubbing DEET into your skin is also pretty gross. I don't even get the slightest bump from being bitten by most varieties of mosquito any more. If you stop letting it bother you and accept it as a minor cost of enjoying the outdoors, your body somehow adapts.
BTW, WEP/128 should be ever so slightly faster than WEP/64 because internally, the rc4 keying algorithym either treats the key as an infinate loop (the way I code it up), or else puts enough copies of the key end-to-end to make a 2048-bit key (most example code I see). A 2048-bit rc4 key would theoretically be the fastest in rekeying. However, one would need to be very careful with chosing which bits of the key constituted the initialization vector, since the key schedule displays poor diffusion properties.
Very few encryption algorithyms share this property of increasing speed as key size increases. (At least in an ideal implementation with properly unrolled loops, etc.)
Some cards will do the rc4 in hardware, and most systems are lighty enough loaded that the CPU will easily pick up the slack. Unless you have run tests wth your particular stup under your particular usage patterns, quit your belly aching. My PII 266 MHz box can saturate an 11 Mb/s link with rc4 encryption.
I like OS X. I'll be getting a G5 laptop soon after they arrive and will probably run OS X on it at last 90% of the time, with some forrays into Linux and hopefully the boys in Dresden will have a PPC-64 verion of L4 out by that time. In most ways I prefer OS X to Linux, but your arguments need improvement. You must also remember that there is non-Mac G3 and G4 hardware out there that does not have the Mac firmware necessary for OS X. This hardware is mostly for scientific computing and embedded applications.
1. PowerPC hardware, PowerPC operating system
Linux has its origins on IA32, Intel's 32-bit architecture. Every platform Linux has migrated to since then has been beset with porting problems-- Linux runs 32% more efficiently on Intel than PowerPC. This is very telling as PowerPC is in general much faster per clock than Intel. Somewhere in the translation from PowerPC to IA32 something got lost.
Mac OS is 100% native for PowerPC. The Mach kernel has been optimized for the G3, G4, and 970 since Apple began writing the operating system back in 1996. Why choose a hacked and kludged OS from another platform when you can have an environment tailor-made for the system you'll be running it on? Mac OS certainly isn't plagued by same driver problems Linux is (in)famous for.
OS X began life on m68k NeXT boxes, not PPC hardware. Linux is also 100% native on PPC hardware. The last numbers I saw showed Linux PPC outperformed OS X on the same hardware. I like some of the ideas behind Mach w/ a BSD server. Too bad they put the BSD server in the kernel address space for performance reasons. The driver gap is largely historical at this point, but still a valid but minor concern.
2. Control over the source code
In Linux, the development model is highly irrational: anyone is allowed to submit patches, and one man (Linus Torvalds) sorts through gigabyte after gigabyte of amateurish code, attempting to integrate it into the kernel. Apple's model is much more modern and decisive: the code for the low levels of Mac OS is available for anyone to download and modify, while the more complex parts of the system (QuickTime and OpenGL) are kept closed-source so those that know better-- the Apple programmers-- are the only ones allowed to tinker.
The results because of these differing development models are clear. Apple released a major update to the OS once a year, and releases about five minor updates to the OS, as well as several dozen security patches and driver updates, in the interim. Since March of 2001 we've gone from 10.0 to 10.2.5! Linux is still stuck at some sort of bizarre "in-between" 2.5 kernel patch and won't move on to 2.6 until well after Apple has released Mac OS 10.3.
It's not hard to see the difference here is a bunch of kids playing with source code instead of doing their homework vs. highly qualified professionals pushing their skills to the limits. The Mac OS user benefits.
You missed your opportunity to jab Linux in the ribs. The tender spot here is Linus switching the entire VM subsystem out in the middle of the 2.4 serries. The weakness in the development model is that it is less conservative with no PHB breathing down Linus's neck. The "bunch of punk kids writing a kernel" argument just doesn't hold water. Some of the most respected coders of our day contribute to the Linux kernel, including some very telented professionals at IBM. Sure lots of rubbish gets submitted, but it gets filtered through a heirarchy or very good coders. Linus may be a little overwhelmed, but that results in some good improvements getting dropped on the cutting room floor rather than rubbish making it into the kernel. Per man-hour, the Linux kernel development is therefore very inneficient, but you have an absolutely huge number of coders.
Your argument about not letting people see the QuickTime and OpenGL code is way off. The same effect could be gotten by opening the cod
You could think of it as a very constrained form of GOTO. The problem with GOTOs are they are often used to jump into the middle of blocks and other convoluted control flow "tricks". GOTOs are sometimes useful, but often abused, particulalry in the early years of C. Read Dijkstra's famous paper on the subject.
It would be difficult to use labeled breaks to make code less readable. However, GOTOs are nearly essential in obfuscated C competitions.
Microsoft needs to stop the GPL, before it ruins the whole US economy, if we could just outlaw the GPL Microsoft wouldnt need to hire Indian programmers anymore.
Nice troll.
MS doesn't need to use Indian programmers. MS would use Indian programers in the absence of OSS. You have a poor understanding of economics.
FYI, it's the X11 server that would need to be distributed w/ Panther. Each X11-using program is an X11 client.
Re:Quazikotel & The End Of The World + compuro
on
Incas Used Binary?
·
· Score: 1
What's interesting about the calendar ending in 2012 is that this is a generally accepted year for The AntiChrist to appear by Bibilical eschatologists. It is also generally the year that is predicted by the Hebrew calendars for the Messiah (the true year 2000 to them I believe) - someone correct my factoids if I'm wrong.
Bzzt... try again. I'm not Jewish, but the *nix hcal program tells me 2012 is the Jewish year 5773. Quetzalcoatl was one of the main Aztec gods (god of life, IIRC), similar to dieties of other peoples in the region, but I think other peoples used different names for the god.
How do you get two Biblical Eschatologists to agree? Shoot one. Jesus himself is quoted (Mark 13:32) as saying "hey loonies, you will not know when the world will end ahead of time, so quit trying to predict it."
Somehow I doubt the Aztec calendar shows knowledge of differentiation and integration. You need to stop watching so much FOX. The human mind is great at finding patterns that aren't there. If you look hard enough, the dunes on Mars clearly describe linear-, differential-, and a previously unkown form of cryptanalysis that renders all cryptography useless and can be applied in reverse to compress random data. As soon as I finish deciphering my map of Mars, I'm going to crack 2048-bit RSA in 13 seconds on my abacus.
Sure, maybe the Myan caledar ends very clearly in 2012, but this I Ching and other stuff is really subjective interpretation done by someone who probably has knowledge of the Mayan calendar. Maybe if you measure the distance from the top of Mount Everest to the top of the Pyramid of the Moon in Teohuatican (near Mexico City) using King Tut's fake beard as your unit of measure, divide by Pi, E, and the golden ratio then factor the answer you get, you'll get a prime number times the number of days between an innacurate estimate of the date of birth of a particular Hebrew carpenter and Dec 10, 2012, but that doesn't prove that Tut had been to the Himalayas and the Americas, knew advanced math and when the world would end, and had been visited by Christ before his birth. It proves that someone with a lot of time on their hands and a lot of practice with a calculator knows about the Mayan calendar.
BTW, Jesus was probably born in the year 3 or 4 B.C.
So we have the Incas to blame for the internet still not being 8-bit clean and having to base64-encode everything so our 8-bit/byte data is in a subset of our 7-bit ASCII alphabet? The Spanish should have burned all those khipu and started them over on a 128-bit system so we'd have widepsread IPv6 back in 1905, and Unicde built into the first computers! Stupid legacy systems!
A ring 0 exploit or a virus infecting ring 0 code would allow the malicious code to directly terminate the application, regardless of cryptograhic keys used in messages. I stand by my claim.
Slashdot Mirror
Your laptop HD is probably 5400 RPM or slower. Resierfs did poorly in these benchmarks primarily because it uses a lot of CPU cycles to get good performance. If you have spare CPU cycles, but your HD is being taxed to the max (as is especially likely in a laptop), Reiserfs will probably work well for you.
I heard that around 1999, there was a course at MIT that pretty much guaranteed you an offer from ArsDigita if you got a decent grade.
There's a decent chance the ArsDigita course was put together by an MIT grad.
Of course, if ArsDigita aren't the people that had their own add-on package for AOL Server and gave a Honda S2000 to the employee that recruited the most number of new employees, then I'm talking about the wrong company.
The texts are copyrighted, and most of this year's lecture notes haven't been written yet.
Threatening to fire Schneier is kinda like threatening to fire Knuth. Sure, they might have to take a pay cut, but their "mean free path" is quite low.
Autoupdate is also free. It goes and examines the RedHat ftp mirrors for updates to your installed packages and doesn't require you giving any info to RedHat (expcept in the form of information leaked through traffic analysis).
I think most of the automated tools will cover their tracks pretty well. Most buffer overflows will fork off sh instead of bash. At best, bash_history is an unreliable means of detecting careless intruders.
It has lots of uses nowadays. Cracker-jacks now come with a 40-bit DES decoder ring in the box. Millions of elementary school kids are passing notes that it would take their teachers hours to read. It's one step up from the Vernier cipher they used to use in their decoder rings.
Thank goodness nobody has clued in elementary school kids that a deck of cards can be used for encryption stronger than 80-bits (Schneier's Solitaire algorithm).
Incorrect. A strong encryption algorithm not only resistant to known plaintext attacks, but also itterative chosen plaintext attacks. (Assume the attacker gets to send you something and you have to encrypt it and send the result back to him/her before they submit the next thing for you to encrypt.) Imagine an attacker has a tamper-resisant smart token with an encryption key locked inside and is set only to encrypt. Even though the attacker can make as many arbitrary encryptions as s/he likes, with information gained between each encryption, a strong encryption algorithm will still not allow the attacker to decrypt a message more easily than attempting half of the possible keys (on average). For a 128-bit key, this is 2^127 ~ 130,000,000,000,000,000,000,000,000,000,000,000,00 0. "Not going anywhere for a while? Try a trillion Snickers bars!"
This is believed to be the case for 3DES, Twofish, Blowfish, and RC5 for all key strengths. There is a theoretical itterative chosen plaintext attack that reduces Serpent to an effective key strength of about 192 bits and AES to about 128 bits. I'm not aware of any theorectical attacks against full-round RC6, but it barely has enough rounds to make differential cryptanalysis impractical (or was it linear cryptanalysis?), so a small breakthough could break RC6 wide open. (Yes, RC6 is really a family of encrpytion algorithms with a variable number of rounds, block size, and key strength. I'm referring to the version of RC6 submitted to the AES competition.)
Now, someone posted somethign saying it uses 40-bit DES, which is a really crappy algorithm that most likely would not take the government weeks to crack. However, a known plaintext attack against 256-bit Twofish would probably take the government more than a year. (I've heard that the amount of energy available in our solar system is much less than 2^255 quanta. This means that you'll need interstellar travel to even count to 2^255.)
Quantum computing is one possbility, but last I heard they were up to a whopping 4 qbits and nobody had (yet) developed a quantum algorithm for breaking any of the common block ciphers. With quantum computing, you start out with a quantum sperposition of all of the possible answers and you perform a bunch of quantum manipulations on your q-bits such that the incorrect answers interefere destructively with eachother. Comming up with the proper manipulations is non-trivial.
I would much rather have some standard whereby the HD controller sends a smart-card or PCMCIA card blocks to encrypt and decrypt. If you wanted to upgrade encryption, it would be a simple matter of a different card. Of course, you'd need to copy the data off the drive first. Government employees could have the cards on lanyards around their necks, so they wouldn't forget to pull out the card when they took a break. A set of buttons on the card itself could be used to encrypt and decrypt the encryption key so a stolen card would be useless (assuming the card forgets the decrypted key when it is removed). The buttons would be on the card itself to offer a small amount of protection over trojaned software.
I am unsure if it would be possible to run other OS personalities on top of Darwin. It would be nice if they had a copy of the BSD personality that could run in userspace. I think a lot of people would be willing to trade the speed for stability. Imagine running all of your daemons under one copy of the BSD personality and all of the other apps under another. A bug in the BSD personality would only take out the copy of the BSD personality in which it was triggered. Of course, all of the processes dependent on that copy of the personality would die or become zombies.
The HURD approach is nice. Each driver runs in its own address space, similar to BeOS servers. I had some problems with my BeOS network server dying on a regular basis. With a monolithic kernel like Linux or Darwin, the system would have hung or dropped into the kernel debugger. With a microkernel and monoserver (like L4 with L4Linux, GNUMach with mkLinux, or Mach with a BSD userspace personality) the kernel would have been fine, but all of the processes dependent on the monoserver (nearly everything in most systems) would have been toast, incuding any way to start new processes. Under BeOS, I got a little error message and was able to restart my networking server. The only consequence was that all open network sockets at the time of the crash were toast. My web browser acted just like it would if I pulled out my networking cable and then put it back in a few seconds later.
The main thing I didn't like about BeOS was that it didn't like the way I tried to use semaphores and would kernel panic every time. I eventually got some kernel corruption on disk (I think related to semaphores trouncing all over the running kernel's address space). I woke up one morning to my floppy drive running constantly. The floopy had been spinning for hours and had a notch in it. The floppy drive was ruined. I tarred up my browser bookmarks and reinstalled the OS. It turns out that the BeOS webbrowser stores the URLs in the metadata of the bookmark files, which doesn't get coppied by tar. Whoever decided to make bookmarks zero-size files with _all_ of the data in the metadata fork should be shot.
As for the "most" clause. Most commercial software isn't innovative (looking at a product from a distance), either. There are few innovations in any human endevour. We know pretty good ways of doing almost anything. The unwashed masses don't want innovation, they want comfort. Comfort often stifles innovation.
X11, Kerberos, AFS, Emacs, the BSD IPv4 stack, etc. aren't very new, but they are all very good systems that have stood the test of time.
More recntly, the Python language and Zinc (the virtual machine used by non-native O'caml object code) are pretty innovative. Last I checked, a member of the L4 microkernel family had the fastest IPC of any x86 kernel. Two-kernel-monte has been around and I hear is being integrated into the main branch of Linux 2.6 (under a new name). I'd like to see prior art (from a commercial product) for swapping kernels without restarting or a usermode port of a full OS kernel. Blowfish, Twofish, and Helix have been Free algorithms from the start.
My primary areas of interest are cryptography, kernels, and virtual machines. If you dig deep enough in almost any software subfield, I would guess you will find free software innovation that could not be ouched by commercial entities because it is too speculative.
FreeNet and IIP are also pretty innovative and we're seeing commercial P2P apps starting to follow suit.
Yes, most OSS is not innovative, but that is the nature of software. Unless you're a Mechanical Engineer that designs food processors, you probably can't see much innovation in food processors in the past 30 years. Unless you're a Petroleum Engineer, you probably can't see much innovation in oil wells in the past 50 years. We've simply gotten to the point that big innovations are very rare in most fields. This is the case for most mundane software people use in their everyday lives.
an Indy is probably best compared to a Pentium Pro or PII. Indys came as fast as 180 MHz, and use 64-bit CPUs (MIPS R44000, R4600, or R5000) with relativey low instruction latency. Clock for clock, they probably perform somewhere beteen x86 and PowerPC chips, except maybe for 64-bit integer operations (which would need to be emulated on x86 and pre-G5 PPC).
Longhorn is NT 6.66, a marketing ploy to make you think it's only one percent evil from concentrate.
SCSI is a more flexible protocol than IDE (according to my friend that used to do kernel development at EMC). The SCSI back end is probably fairly close to what they want for a generic nonvolatile storage back end. They can increase reliablility and reduce the size of the kernel (both the source and any binary that is compiled for both IDE and SCSI) by refactoring allof the common HD functionality into a generic back end. This may or may not minimally hurt performance in the short run, but will increase performance by increasing development speed in the long run. This would also greatly increase the amount of testing and stress testing on a good chunk of the SCSI back end.
I doubt they want to use some of the SCSI back end for IDE b/c it's SCSI. Rather, they want to use some of the SCSI back end for IDE b/c the SCSI backend is probably pretty close to a generic storage back end.
While we're on the subject, does anyone know of an IDE RAID controller that pretends to be a normal SCSI controller with a single device attached? How much of the normal IDE CPU load gets offloaded into a typical IDE RAID controller? I would assume the easy way to offload most of the IDE CPU load would to have the controller emulate a SCSI controller.
Then again, ever since I took wilderness survival merit badge at Tomahawk Scout Ranch, I got used to being bitten. I stopped wearing DEET when I realized it solvated the logo on our troop t-shirts and ruined other plastic items. The dirty oily feel of rubbing DEET into your skin is also pretty gross. I don't even get the slightest bump from being bitten by most varieties of mosquito any more. If you stop letting it bother you and accept it as a minor cost of enjoying the outdoors, your body somehow adapts.
Very few encryption algorithyms share this property of increasing speed as key size increases. (At least in an ideal implementation with properly unrolled loops, etc.)
Some cards will do the rc4 in hardware, and most systems are lighty enough loaded that the CPU will easily pick up the slack. Unless you have run tests wth your particular stup under your particular usage patterns, quit your belly aching. My PII 266 MHz box can saturate an 11 Mb/s link with rc4 encryption.
OS X began life on m68k NeXT boxes, not PPC hardware. Linux is also 100% native on PPC hardware. The last numbers I saw showed Linux PPC outperformed OS X on the same hardware. I like some of the ideas behind Mach w/ a BSD server. Too bad they put the BSD server in the kernel address space for performance reasons. The driver gap is largely historical at this point, but still a valid but minor concern.
You missed your opportunity to jab Linux in the ribs. The tender spot here is Linus switching the entire VM subsystem out in the middle of the 2.4 serries. The weakness in the development model is that it is less conservative with no PHB breathing down Linus's neck. The "bunch of punk kids writing a kernel" argument just doesn't hold water. Some of the most respected coders of our day contribute to the Linux kernel, including some very telented professionals at IBM. Sure lots of rubbish gets submitted, but it gets filtered through a heirarchy or very good coders. Linus may be a little overwhelmed, but that results in some good improvements getting dropped on the cutting room floor rather than rubbish making it into the kernel. Per man-hour, the Linux kernel development is therefore very inneficient, but you have an absolutely huge number of coders.
Your argument about not letting people see the QuickTime and OpenGL code is way off. The same effect could be gotten by opening the cod
It would be difficult to use labeled breaks to make code less readable. However, GOTOs are nearly essential in obfuscated C competitions.
Nice troll.
MS doesn't need to use Indian programmers. MS would use Indian programers in the absence of OSS. You have a poor understanding of economics.
FYI, it's the X11 server that would need to be distributed w/ Panther. Each X11-using program is an X11 client.
Bzzt... try again. I'm not Jewish, but the *nix hcal program tells me 2012 is the Jewish year 5773. Quetzalcoatl was one of the main Aztec gods (god of life, IIRC), similar to dieties of other peoples in the region, but I think other peoples used different names for the god.
How do you get two Biblical Eschatologists to agree? Shoot one. Jesus himself is quoted (Mark 13:32) as saying "hey loonies, you will not know when the world will end ahead of time, so quit trying to predict it."
Somehow I doubt the Aztec calendar shows knowledge of differentiation and integration. You need to stop watching so much FOX. The human mind is great at finding patterns that aren't there. If you look hard enough, the dunes on Mars clearly describe linear-, differential-, and a previously unkown form of cryptanalysis that renders all cryptography useless and can be applied in reverse to compress random data. As soon as I finish deciphering my map of Mars, I'm going to crack 2048-bit RSA in 13 seconds on my abacus.
Sure, maybe the Myan caledar ends very clearly in 2012, but this I Ching and other stuff is really subjective interpretation done by someone who probably has knowledge of the Mayan calendar. Maybe if you measure the distance from the top of Mount Everest to the top of the Pyramid of the Moon in Teohuatican (near Mexico City) using King Tut's fake beard as your unit of measure, divide by Pi, E, and the golden ratio then factor the answer you get, you'll get a prime number times the number of days between an innacurate estimate of the date of birth of a particular Hebrew carpenter and Dec 10, 2012, but that doesn't prove that Tut had been to the Himalayas and the Americas, knew advanced math and when the world would end, and had been visited by Christ before his birth. It proves that someone with a lot of time on their hands and a lot of practice with a calculator knows about the Mayan calendar.
BTW, Jesus was probably born in the year 3 or 4 B.C.
So we have the Incas to blame for the internet still not being 8-bit clean and having to base64-encode everything so our 8-bit/byte data is in a subset of our 7-bit ASCII alphabet? The Spanish should have burned all those khipu and started them over on a 128-bit system so we'd have widepsread IPv6 back in 1905, and Unicde built into the first computers! Stupid legacy systems!
Jura qvq gurl gnxr ebg13 bhg bs Argfpncr'f gbbyf zrah?
A ring 0 exploit or a virus infecting ring 0 code would allow the malicious code to directly terminate the application, regardless of cryptograhic keys used in messages. I stand by my claim.
Hmm... I was going under the assumption that distributing the alphabetized source counts as distribution of a derrivative of the GPLed work.