I'm fairly sure that whatever CPU you have it'd have to work pretty hard to beat a 1 GHz Nehemiah CPU at doing AES encryption. The reason is that somebody had a great idea to integrate it into the CPU, so it can encrypt one block per clock cycle.
Pure brute force of course helps, but what's better? A 1 GHz CPU that can encrypt a block in a clock cycle, using somewhere about 20W for the motherboard and CPU, or a 4 GHz CPU that needs 200 clock cycles to do it in software, and needs more than 100W for just the CPU?
You have two drives, split each in half, and make two arrays with it, RAID 0 and RAID 1. Now, one of your disks dies. The RAID 1 part still works, because you have a disk left. The RAID 0 is dead, but hopefully you didn't use it for anything important anyway.
This way you can both have high speed and reliability with just two drives.
Just one thing to add to that: Having more than a drive on the same cable can be dangerous as well. I had problems when a misbehaving drive would also cause problems with another that was perfectly good, just on the same cable.
On my screen I have 1280x1024 pixels. Every pixel is formed from 3 elements: red, green and blue, but they're small enough so that a yellow pixel appears really yellow to me.
Now, printers print using Cyan, Magenta, Yellow and black. Most cheap printers can't mix colors, which means they have to combine them by dithering. And to make matters even worse, they can't control the intensity. If you have a color printer, try printing colored text. Often it looks pretty ugly.
This means that in order to print my screen on paper and have it look identical, my printer has to either have a much higher resolution so that dithering isn't visible, or mix colors.
If you print your photo on a inkjet without scaling, you'll lose detail due to dithering. If you make it bigger, and print it on a really good printer, then it'll come out pixelated. Jagged lines on a printer are much easier to see, probably because on a screen the pixels glow and to some extend mix with the nearby ones, and on a good printer they won't.
JIT is not something magical that just the JVM can do. A C program can also do that, for example by generating code itself, modifying its own code, or using lots of pointers to functions. If you really wanted, you could even make your own mini-VM in C optimized for your application. But I doubt it's necessary to get that far.
C also allows doing things that Java can't, like using specific instructions like MMX, and controlling memory allocation in a way that's optimal for your program.
JIT might be able to do some nice tricks, but it'll probably never be as effective as coding the optimal algorithm for a task.
Nope, a compiled language is still faster. It's easy to explain:
Runtime optimization analyzes the bytecode that's running and can come up with ways of optimizing things at runtime. However, this optimization was coded into the JVM, and there's absolutely nothing that stops you from emulating that approach in C.
Let's say I have the function drawPixel(), which draws a picture on the screen. Inside it's got a switch statement, that selects different ways depending on the screen's bit depth.
Well, the JVM might realize that we're always selecting 16 bit depth, and optimize that. Perhaps it will move the test for 16 bit to the first place.
Now, in C we won't have that, but there's nothing stopping the programmer from coding a separate function for every possible bit depth, putting pointers to that function into an array, and selecting the right function to call during the beginning of the loop. Say:
The biggest problem with Windows is that once it breaks it's really hard to fix. A few times Win2K was left unbootable, and it took me a week to figure out how to get it to install.
Linux, while it may be less intuitive is at least trivial to troubleshoot once you understand how it works. Windows though... it just freezed during the logo screen with the progress bar. You can't really get any less informative than that.
Besides that, stability. Not having to worry about the exploit of the day, spyware, and what every program will do with my registry is also very nice.
Heh. Then I wonder what issue you have, since this exists already. See the bash manpage for the nocaseglob setting, and completion-ignore-case readline setting. Seems to do exactly what you want.
Excuse me, but that's extremely self-centered. While I and many other people know English well enough to use english-centered programs, many other people have environments completely in their own language. For example, in Spain pretty much everybody sees Spanish and other Spanish on the screen.
Also, "e" != "é" in many languages. For example in Spanish, some words have completely different meanings depending on whether they have an accent or not. Here's a quote of the mess you have to deal with:
Case folding is not easily defined in many European languages, both because many of them use characters outside the US ASCII alphabetic set, and because:
In Spanish, the digraph "ll" is considered to be a single letter, the capitalized form of which may be either "Ll" or "LL" , depending on context.
In French, the capitalized form of a letter with an accent may or may not retain the accent, depending on the country in which it is written.
In German, the sharp ess may be represented as a single character resembling a Greek beta (ß) in lowercase, but as the digraph "SS" in uppercase.
In Greek, there are several lowercase forms of some letters; the one to use depends on its position in the word. Arabic has similar rules.
Another problem you have is that Unix doesn't really know how to deal with Unicode properly. Unix is largely ASCII-only, evidenced for example by the fact that a text terminal can only have 256 different characters.
Then there are more problems. Don't think there's only Unicode. You'd have to deal with all the existing different encodings. There are different encodings for the same language, which contain letters in different orders. For example, take the russian koi8-r, which has the russian letters in the same order as their english equivalent. Removing the first bit converts russian text into an understandable english transcription. There's another one with the russian letters in alphabetical order.
If you move from the 'filenames are sequences of bytes' concept you suddenly have to implement lots and lots of stuff. Things like having the OS know about every encoding out there, how to change case, what characters are equivalent... and there's no API or support for all of this anyway. Say, 99% of all programs assume a filename should be stored in a char *, and on virtually every modern architecture, char == 1 byte.
Next, you'll have problems with similar looking characters. I send you a file with the name "answers.txt", and you won't be able to TAB-complete it, because the "a" is the russian one, even though it looks exactly the same.
Even if you added the OS support for Unicode (which probably would require making Unicode fonts and having the console display on a framebuffer to begin with), no existing program would see the improvement anyway.
Right, Joe Sixpack doesn't have any idea of what say, "C:\WINNT\assembly\GAC\System.EnterpriseServices" is for, and that doesn't stop them from using Windows for some reason. It's not like using long filenames makes these things much easier to understand.
A Linux user doesn't have to know what's/usr for. There's/home, and it it there's joe's home directory, and that's pretty easy to understand.
Go and try to read the LFS standard some time. The current layout actually makes sense. And I don't really see how renaming/usr to/System or whatever is going to make things any simpler, anyway.
There are several languages where lowercase -> uppercase -> lowercase can't be done without losing data, for example. Then there is the problem of how many languages you can support. Say, English is easy, but what happens when you find a disk with filenames in an encoding the filesystem doesn't know about?
In Linux, it's just all bytes, it doesn't care if it's english, cyrillic or whatever. With case insensitivity it suddenly has to know what to do with cyrillic letters as well.
Quite a while ago I had this idea for a popup blocker that hides ads, but still loads them, and simulates a clickthrough. It'd also log all the blocked ads and periodically load them. Perhaps it could be extended to share ad addresses and have volunteers hit them once in a while.
The objective of all this is simple: If the advertisers can't know if thir ads are being viewed, or what is the real clickthrough rate, they'll have a much harder time. The ultimate challenge is of course make all ad statistics worthless.
I find this perhaps the best way possible of getting rid of them, since it'd attack the advertisers instead of the site getting paid for showing them, might bring a little extra income to the site's owner.
since I'm quite interested in this I've investigated it a bit. Turns out JFFS is useless for CompactFlash, since it does its own wear levelling already. JFFS is something like what CF does internally, and is supposed to be used on raw Flash chips. I think some of the other memory cards are pretty much flash chips with a plastic case, and that's where you'd use JFFS.
I don't really see it as very immoral. If the game is in perfect condition, I don't really see why it couldn't be sold for almost the full price. Let's see how these things can happen:
Retailer buys game for $x, sells for $y + n% Somebody buys game for that price Somebody sells the game to another retailer Retailer resells game for a price depending on the condition
Now, if you got some game you know you won't like or can't run for your birthday, you could perfectly go and sell it, and I don't see how your posession of the box for a week devalues it at all. Especially if you didn't open it.
The producer doesn't get any money for this? Well, duh. First the game went to somebody who didn't want it. The retailer made some extra money for finding somebody who did want it, offering a small discount to the gamer who bought it, and paying some money to whoever didn't want it.
So tell me, why does the producer deserve selling a new copy instead? All that happened that a game moved from somebody who didn't want it to somebody who wanted it, through a reseller that deservedly got a profit for the useful service. If the person who didn't want it didn't get the game, and the one who bought the second hand copy bought the original instead, the profit would have been exactly the same for the producer: one game sold.
Well, mostly because it's my main computer, and my bedroom is the only room I have since I live with my parents. I have two other computers that run all the time, that's why I'm working on replacing them with something quiet.
The server's going to be a challenge because it's going to need a hard disk, but I want to see if I can come up with some way of making a box like this firewall, that has a hard disk but uses the flash card as a kind of cache to get the disk to turn off at night.
Besides, it's a technically interesting project:-)
Well, let's count. It's an Athlon 2000+ in a Lian Li case, with a GeForce FX 5600
Two CPUs: 2 fans, logically Lian Li PC68: 2 intake fans in front, 1 fan on top, 1 fan behind Enermax 460W power supply: 1 intake fan, 1 exhaust fan GeForce: 1 fan
Although the case fans add noise, they're pretty nice. They keep the hard disks cool because the intake fans blow right on them, and they have a filter that keeps most dust out.
Why, the system I have in mind is fairly modern. I've heard that the 1 GHz Eden CPU is not really on the same level as a 1 GHz Athlon, but I suppose it should still be enough for a decent amount of modern software. It's supposed to have some 3D and crypto acceleration as well.
Now, I won't argue it won't compare very favorably to my dual Athlon on speed terms, but the Athlon has 9 fans (!) that make impossible to sleep near it and this one will have none.
That sounds pretty silent, but not completely, excepting the Palm maybe. In this computer NOTHING will move. The others did have moving parts that made noise:
VIC-20: Cassette tape Commodore: Floppy drive Mac Plus: Floppy drive, hard disk
I started with a 386, which had a hard disk and power supply fan, so no computers of mine were completely silent.
Or maybe I should have written that in some other way. English is my third language, so I still make lots of mistakes. If you can think of a better way of saying it, I will try to remember it for next time.
Well, I'd love these to come down in price. Flash is *nice*.
Here I'm going to try to set up a router with no moving parts at all. VIA motherboard with no CPU or power supply fans, no floppies, no CD drives (after install). Just a 512MB flash card in a CF-IDE adapter, with a small Debian install on it.
That should be the first computer I have to be completely silent.
The big problems happen when you have WAY too much *active* stuff at the same time. Then the kernel has no choice but to swap out one thing, swap in another, swap it out, swap in something else... The way of avoiding that is having your swap small enough to make things crash due to lack of memory before this situation can happen.
Slashdot Mirror
Oh the horror. People used the word "leverage" twice in a row on Slashdot. I'm about to run away screaming.
Bah. Clock rate means very little.
I'm fairly sure that whatever CPU you have it'd have to work pretty hard to beat a 1 GHz Nehemiah CPU at doing AES encryption. The reason is that somebody had a great idea to integrate it into the CPU, so it can encrypt one block per clock cycle.
Pure brute force of course helps, but what's better? A 1 GHz CPU that can encrypt a block in a clock cycle, using somewhere about 20W for the motherboard and CPU, or a 4 GHz CPU that needs 200 clock cycles to do it in software, and needs more than 100W for just the CPU?
It's exactly as you say.
You have two drives, split each in half, and make two arrays with it, RAID 0 and RAID 1. Now, one of your disks dies. The RAID 1 part still works, because you have a disk left. The RAID 0 is dead, but hopefully you didn't use it for anything important anyway.
This way you can both have high speed and reliability with just two drives.
Just one thing to add to that: Having more than a drive on the same cable can be dangerous as well. I had problems when a misbehaving drive would also cause problems with another that was perfectly good, just on the same cable.
That's funny, but how about trying the other way? Like linking SCO to something informative.
Pretty easy. Printers work differently.
On my screen I have 1280x1024 pixels. Every pixel is formed from 3 elements: red, green and blue, but they're small enough so that a yellow pixel appears really yellow to me.
Now, printers print using Cyan, Magenta, Yellow and black. Most cheap printers can't mix colors, which means they have to combine them by dithering. And to make matters even worse, they can't control the intensity. If you have a color printer, try printing colored text. Often it looks pretty ugly.
This means that in order to print my screen on paper and have it look identical, my printer has to either have a much higher resolution so that dithering isn't visible, or mix colors.
If you print your photo on a inkjet without scaling, you'll lose detail due to dithering. If you make it bigger, and print it on a really good printer, then it'll come out pixelated. Jagged lines on a printer are much easier to see, probably because on a screen the pixels glow and to some extend mix with the nearby ones, and on a good printer they won't.
No, you're wrong again :-)
JIT is not something magical that just the JVM can do. A C program can also do that, for example by generating code itself, modifying its own code, or using lots of pointers to functions. If you really wanted, you could even make your own mini-VM in C optimized for your application. But I doubt it's necessary to get that far.
C also allows doing things that Java can't, like using specific instructions like MMX, and controlling memory allocation in a way that's optimal for your program.
JIT might be able to do some nice tricks, but it'll probably never be as effective as coding the optimal algorithm for a task.
Nope, a compiled language is still faster. It's easy to explain:
m e();
Runtime optimization analyzes the bytecode that's running and can come up with ways of optimizing things at runtime. However, this optimization was coded into the JVM, and there's absolutely nothing that stops you from emulating that approach in C.
Let's say I have the function drawPixel(), which draws a picture on the screen. Inside it's got a switch statement, that selects different ways depending on the screen's bit depth.
Well, the JVM might realize that we're always selecting 16 bit depth, and optimize that. Perhaps it will move the test for 16 bit to the first place.
Now, in C we won't have that, but there's nothing stopping the programmer from coding a separate function for every possible bit depth, putting pointers to that function into an array, and selecting the right function to call during the beginning of the loop. Say:
for(;;) {
drawPixel = draw_pixel_functions[current_bit_depth];
drawFra
}
There you go, a faster algorhitm in C. Code every version of drawPixel in assembler, and there's no way Java can beat that.
Actually, some idiots in collaboration with Steve Gibson are trying to sell exactly this idea for $30. The first time I heard of it, it cost $40.
It's called PathLock e100 NETimer
The biggest problem with Windows is that once it breaks it's really hard to fix. A few times Win2K was left unbootable, and it took me a week to figure out how to get it to install.
Linux, while it may be less intuitive is at least trivial to troubleshoot once you understand how it works. Windows though... it just freezed during the logo screen with the progress bar. You can't really get any less informative than that.
Besides that, stability. Not having to worry about the exploit of the day, spyware, and what every program will do with my registry is also very nice.
Heh. Then I wonder what issue you have, since this exists already. See the bash manpage for the nocaseglob setting, and completion-ignore-case readline setting. Seems to do exactly what you want.
Also, "e" != "é" in many languages. For example in Spanish, some words have completely different meanings depending on whether they have an accent or not. Here's a quote of the mess you have to deal with:
Another problem you have is that Unix doesn't really know how to deal with Unicode properly. Unix is largely ASCII-only, evidenced for example by the fact that a text terminal can only have 256 different characters.
Then there are more problems. Don't think there's only Unicode. You'd have to deal with all the existing different encodings. There are different encodings for the same language, which contain letters in different orders. For example, take the russian koi8-r, which has the russian letters in the same order as their english equivalent. Removing the first bit converts russian text into an understandable english transcription. There's another one with the russian letters in alphabetical order.
If you move from the 'filenames are sequences of bytes' concept you suddenly have to implement lots and lots of stuff. Things like having the OS know about every encoding out there, how to change case, what characters are equivalent... and there's no API or support for all of this anyway. Say, 99% of all programs assume a filename should be stored in a char *, and on virtually every modern architecture, char == 1 byte.
Next, you'll have problems with similar looking characters. I send you a file with the name "answers.txt", and you won't be able to TAB-complete it, because the "a" is the russian one, even though it looks exactly the same.
Even if you added the OS support for Unicode (which probably would require making Unicode fonts and having the console display on a framebuffer to begin with), no existing program would see the improvement anyway.
Huh.
/usr for. There's /home, and it it there's joe's home directory, and that's pretty easy to understand.
Right, Joe Sixpack doesn't have any idea of what say, "C:\WINNT\assembly\GAC\System.EnterpriseServices" is for, and that doesn't stop them from using Windows for some reason. It's not like using long filenames makes these things much easier to understand.
A Linux user doesn't have to know what's
Go and try to read the LFS standard some time. The current layout actually makes sense. And I don't really see how renaming /usr to /System or whatever is going to make things any simpler, anyway.
There is plenty.
There are several languages where lowercase -> uppercase -> lowercase can't be done without losing data, for example. Then there is the problem of how many languages you can support. Say, English is easy, but what happens when you find a disk with filenames in an encoding the filesystem doesn't know about?
In Linux, it's just all bytes, it doesn't care if it's english, cyrillic or whatever. With case insensitivity it suddenly has to know what to do with cyrillic letters as well.
I'm not worried.
Quite a while ago I had this idea for a popup blocker that hides ads, but still loads them, and simulates a clickthrough. It'd also log all the blocked ads and periodically load them. Perhaps it could be extended to share ad addresses and have volunteers hit them once in a while.
The objective of all this is simple: If the advertisers can't know if thir ads are being viewed, or what is the real clickthrough rate, they'll have a much harder time. The ultimate challenge is of course make all ad statistics worthless.
I find this perhaps the best way possible of getting rid of them, since it'd attack the advertisers instead of the site getting paid for showing them, might bring a little extra income to the site's owner.
since I'm quite interested in this I've investigated it a bit. Turns out JFFS is useless for CompactFlash, since it does its own wear levelling already. JFFS is something like what CF does internally, and is supposed to be used on raw Flash chips. I think some of the other memory cards are pretty much flash chips with a plastic case, and that's where you'd use JFFS.
I don't really see it as very immoral. If the game is in perfect condition, I don't really see why it couldn't be sold for almost the full price. Let's see how these things can happen:
Retailer buys game for $x, sells for $y + n%
Somebody buys game for that price
Somebody sells the game to another retailer
Retailer resells game for a price depending on the condition
Now, if you got some game you know you won't like or can't run for your birthday, you could perfectly go and sell it, and I don't see how your posession of the box for a week devalues it at all. Especially if you didn't open it.
The producer doesn't get any money for this? Well, duh. First the game went to somebody who didn't want it. The retailer made some extra money for finding somebody who did want it, offering a small discount to the gamer who bought it, and paying some money to whoever didn't want it.
So tell me, why does the producer deserve selling a new copy instead? All that happened that a game moved from somebody who didn't want it to somebody who wanted it, through a reseller that deservedly got a profit for the useful service. If the person who didn't want it didn't get the game, and the one who bought the second hand copy bought the original instead, the profit would have been exactly the same for the producer: one game sold.
So where's the problem?
Well, mostly because it's my main computer, and my bedroom is the only room I have since I live with my parents. I have two other computers that run all the time, that's why I'm working on replacing them with something quiet.
:-)
The server's going to be a challenge because it's going to need a hard disk, but I want to see if I can come up with some way of making a box like this firewall, that has a hard disk but uses the flash card as a kind of cache to get the disk to turn off at night.
Besides, it's a technically interesting project
Well, let's count. It's an Athlon 2000+ in a Lian Li case, with a GeForce FX 5600
Two CPUs: 2 fans, logically
Lian Li PC68: 2 intake fans in front, 1 fan on top, 1 fan behind
Enermax 460W power supply: 1 intake fan, 1 exhaust fan
GeForce: 1 fan
Although the case fans add noise, they're pretty nice. They keep the hard disks cool because the intake fans blow right on them, and they have a filter that keeps most dust out.
Why, the system I have in mind is fairly modern. I've heard that the 1 GHz Eden CPU is not really on the same level as a 1 GHz Athlon, but I suppose it should still be enough for a decent amount of modern software. It's supposed to have some 3D and crypto acceleration as well.
Now, I won't argue it won't compare very favorably to my dual Athlon on speed terms, but the Athlon has 9 fans (!) that make impossible to sleep near it and this one will have none.
That sounds pretty silent, but not completely, excepting the Palm maybe. In this computer NOTHING will move. The others did have moving parts that made noise:
VIC-20: Cassette tape
Commodore: Floppy drive
Mac Plus: Floppy drive, hard disk
I started with a 386, which had a hard disk and power supply fan, so no computers of mine were completely silent.
Or maybe I should have written that in some other way. English is my third language, so I still make lots of mistakes. If you can think of a better way of saying it, I will try to remember it for next time.
Well, I'd love these to come down in price. Flash is *nice*.
Here I'm going to try to set up a router with no moving parts at all. VIA motherboard with no CPU or power supply fans, no floppies, no CD drives (after install). Just a 512MB flash card in a CF-IDE adapter, with a small Debian install on it.
That should be the first computer I have to be completely silent.
It's not that easy.
The big problems happen when you have WAY too much *active* stuff at the same time. Then the kernel has no choice but to swap out one thing, swap in another, swap it out, swap in something else... The way of avoiding that is having your swap small enough to make things crash due to lack of memory before this situation can happen.