Back in the day, when everyone was excited for the 2.4 kernels to come out, I was waiting very eagerly. You see, I had just purchased a quad-processer machine, and 2.4 was supposed to scale much better than the 2.2 series. Now, as should be imagined, this wasn't a "toy" or "testing" machine, it was a production database server that the entire company depended on.
When 2.4.1 came out, I downloaded it, compiled it, and installed it on the production machine. It purred along beautifully. I completely forgot about it.
Some time later, the o(1) scheduler patches came out, so I downloaded what was the then-current version, 2.4.17. Here's where it gets good: The database server with the 2.4.1 kernel was still running.
No, I don't mean that I was just still using it. I mean that it was *still running*. It had never been shut down, crashed, or had a reboot for any reason.
Based on that experience, I'm not terribly worried about using the 2.6 kernels.
He needs a robotic tripod to position the camera for him, so that there's less time in hand-stitching.
In fact, he could probably hook the camera to a computer directly, and with sufficiently advanced image analysis, have the computer position the camera closely enough to avoid hand-editing at all.
Creating a picture of this size by spending many hours of labor is cool to prove it can be done. Having automated tools to churn one of these out in a couple of minutes would be VERY cool.
>When I tried to save it as a JPEG (level 12 compression) the white (blank) picture came in at a whopping 23mb
Then you should have saved it as a.gif, to take advantage of the monochrome image, getting a nice, tiny file size. Then you should have named it "hottie.gif", and emailed it to all of your friends. : )
I used to feel the same way - my 1.2 megapixel camera had plenty of resolution for everything I did. Alas, a few days ago, I bought a $200 Sony DPP-EX5 dye-sublimation printer. Ooooooh-boy. Now I need a new camera.
The DPP-EX5 prints at 403 DPI. On a 4x6 borderless card, that's 1612x2418, or just over 3 megapixels.
When I print the 1.2 megapixel images from my camera, they look absolutely stunning - unless the image has very sharp-edged details, in which case the 3x upsampling does become noticeable.
So, if I'm going to go to the trouble of using a 400-DPI dye-sub printer, a ~140-DPI image just doesn't fulfill the printer's potential.
Now, I'm looking at cameras. Anything in the 3-megapixel range should work just fine with this printer, but I'm not excluding the 4- and 5-megapixel cameras, either. Just like my 1.2mp camera eventually made me want more, eventually I'll want more than a 3mp camera.
Well, since PhotoShop works on the raw image data, a 1-gigapixel photo at 24 bpp (3 bytes per pixel), you'd need a bare minimum of 3 gigabytes of RAM if you wanted to fit the image in main memory.
So, tell your friend to buy an Opteron with 4-8 gigs of memory, so that when a 64-bit version of Windows and a 64-bit version of Photoshop are available, he can actually work on files this large. : )
You mean that by 2020 we won't be able to keep up with Moore's law?
Golly-gee! That means that we'll only have another 11 doublings of transistor count, meaning we'll be limitted at about 2000 times the number of transistors we have today. Geez, what how would I ever survive with only the equivalent of 2,000 P4/Opteron processers in my desktop?
It'd still fritz out pacemakers. And people would still whine that we were immoral, baby-killing pigs for killing 300 innocent people in an attempt to topple a regime that slaughtered tens of thousands ever year.
ARM cores and P3/P4/Athlon/Opteron cores are so incredibly different that comparing them is simply stupid.
Your ARM core has what, 36,000 transistors? Try adding on a floating point unit, for starters. Then add in MMX, SSE, and SSE2 instruction sets. Then see how much power it consumes.
ARMs are great when you need a low-power, low-speed, integer-only processer. Unfortunately, when you need more muscle, an ARM just won't cut it.
The debian installer, overall, isn't all that terrible. The package selection, however, is attrocious. You have two options: Install everything, or spend hours flipping back and forth between the choices and the "fulfill your dependencies" screen a thousand times. If the package selection were designed without the intent of making your life tedious and boring, then the process would be much better. The process isn't hard, it's just long and drawn out.
Now, lest anyone think that this is a Debian-bash, other installers and package-selectors have their flaws as well. RedHat lets you choose packages quickly, and deal with dependencies afterward. However, once it's figured out your dependencies, you either have to go back and try it yourself, or make a blanket decision that will affect all of the packages. A combination of the two would be nice - pick your packages, then let it figure out the dependencies, and let you choose on a package-by-package basis what you want to do.
In RedHat's case, the dependencies are insane. While Perl is a really need programming language, the idea of having a non-working vi because Perl isn't present seems insane to me. And the idea that X-windows just won't work without openssl isn't much better!
Your biggest problem is sorting through the "... and I turned out OK" posts.
Really. With a few exceptions, people tend to justify whatever they do. If they didn't, they'd feel bad. And while some people do walk around in self-loathing from realizing everything they do wrong (or even blaming MORE on themselves), most people will subconsciously do just about anything to keep from feeling like they're doing wrong.
So, the guy who doesn't look at porn will say he turned out alright. The guy that looks at bikini pictures will say "I turned out alright, I don't look at naked pictures." The guy who looks at porn will say "But I turned out alright, I don't do {X}." The guy that's been screwed up will say "and I turned out alright, it's not like I'm doing {X}". And the guy who's been completely messed up will say that he's just living an alternative lifestyle, and that he's not hurting anyone else.
So, basing your decision on the "and I turned out alright" from some guy on the Internet is about as stupid as you can get. You're their parent, you (and they) will bear the consequences of your bad choices. If I were you, I'd start by studying up on child psychology and development, for starters. Understanding why kids do what they do will help you more than anything else.
How can you take him out? Easy. Because for the first two films, you really didn't *see* much of Saruman. All they really show in the films is that he's an old guy that bred some orcs, hates the good guys, and has a funky bowling ball.
Now, cutting him out of the realstory (the books) just wouldn't work. But his character has so little time in the movie that as it probably wouldn't be hard to do without him at all in the third.
While times *used* to be that it took expensive machines to keep routing tables, a quick trip to eBay with $1,000 will buy you a machine that will handle at least 4 full BGP feeds. If you even need two BGP feeds, chances are that your bandwidth costs greatly eclipse the cost of the router.
so, you make the writes asynchronous. Reads are still going to be terribly slow. You can get around that somewhat by using large amounts of memory for cache, but the first reads will still be pretty slow.
I'd much rather use rsync and tar/gz. In fact, that's what I did.
Really. If you're on a 100-megabit LAN, that gives you a max of about 10 megaBYTES per second. So, if you have to transmit information to two other computers for every disk write, you're effectively limitting yourself to a maximum of about 5 megabytes/second disk transfer. And that's under GOOD situations. If you're doing random I/O, where the latency will be the determining factor, then take the latency of the hard drives, add in the latency of the networking, and the latency of the software layers, and you're looking at some pretty abysmal performance.
Using rsync in a cron job will solve your backup problems. In fact, your script can use rsync to do the synchronization, and tar/gzip to archive the backup - giving you "point in time" snapshots for when someone says "I deleted this file 4 days ago, can you get it back?"
"A drawback is that the hard drive heat is basically trapped within the enclosure, and users are cautioned not to use drives that generate more than 6.8 watts of heat."
Oh, boy. A way to make the drives even hotter, which will just accelerate wear that much more. And 6.8 watts? That rules out most hard drives these days.
Hum... your argument makes sense if the two cores actually needed to communicate with each other, but, from my understanding, that's not going to happen much, as they'll typically be running separate threads.
But if the two cores aren't communicating so much, then it seems as if it'd have the opposite effect: they're contending with each other for bandwidth to L3 and/or main memory.
If this were a P3/P4 core, I'd agree. However, the Opteron is an entirely different animal. Remember that each core has it's own memory controller. That means that they're working cooperatively for main memory, and you need high throughput between them. With each core that you add, you add another memory controller (and hence, increase memory bandwidth), but you need to be able to move those bits around.
Also, there is no L3 cache on these chips. Hopefully the chips are not sharing an L2 cache.
Not sure what you're saying about server applications; you kinda contradict yourself, in terms of how compute-bound the applications are.
No, I don't contradict myself at all. In a server environment, you tend to have a good number of applications (or threads) trying to get CPU time. If it's a web server, you tend to have multiple HTTPD processes and multiple CGI processes at once. If it's a database server, you tend to have many threads or processes (depending on the design model) working at once. Even on a file server, you have lots of NFS or Samba processes at once.
For a desktop system, a single fast processer is great. For a server, multiple cores is much better. As I've said before, it's rare for a CPU to be kept 100% busy doing computational work, usually I/O, high interrupts, or context-switches keep you from getting 100% out of your processer.
By having multiple cores on the same chip under this design, you get more memory controllers for more memory bandwidth, a bigger pipe between the cores to move that data around, interrupts can be balanced between the processers, and by having two processers, you only have to execute half of the context-switches, at least in theory.
For server situations where lots of programs are trying to get CPU time, this really does make a lot of sense. For desktop application, it makes very, very little sense. As for HyperThreading letting two threads run at once, it's not quite that simple, and it doesn't buy you a very large speedup. Under heavy DBMS loads, I've seen HT give performance deltas of anywhere from -1% to +3%. Nothing to write home about. : )
Back around 1995, a friend of mine told me his story. His father was an engineer, and had what was at the time a VERY fast computer.
My friend installed Linux on it, and decided to take it off. He decided that "rm -rf/" would do the trick, so he issued the command, and left the room.
A few minutes later, he remembered that he had his father's DOS partition mounted when he issued the command. He ran back, but it was too late. All of his father's engineering work was gone. : )
Slashdot Mirror
Back in the day, when everyone was excited for the 2.4 kernels to come out, I was waiting very eagerly. You see, I had just purchased a quad-processer machine, and 2.4 was supposed to scale much better than the 2.2 series. Now, as should be imagined, this wasn't a "toy" or "testing" machine, it was a production database server that the entire company depended on.
When 2.4.1 came out, I downloaded it, compiled it, and installed it on the production machine. It purred along beautifully. I completely forgot about it.
Some time later, the o(1) scheduler patches came out, so I downloaded what was the then-current version, 2.4.17. Here's where it gets good: The database server with the 2.4.1 kernel was still running.
No, I don't mean that I was just still using it. I mean that it was *still running*. It had never been shut down, crashed, or had a reboot for any reason.
Based on that experience, I'm not terribly worried about using the 2.6 kernels.
steve
He needs a robotic tripod to position the camera for him, so that there's less time in hand-stitching.
In fact, he could probably hook the camera to a computer directly, and with sufficiently advanced image analysis, have the computer position the camera closely enough to avoid hand-editing at all.
Creating a picture of this size by spending many hours of labor is cool to prove it can be done. Having automated tools to churn one of these out in a couple of minutes would be VERY cool.
steve
>When I tried to save it as a JPEG (level 12 compression) the white (blank) picture came in at a whopping 23mb
.gif, to take advantage of the monochrome image, getting a nice, tiny file size. Then you should have named it "hottie.gif", and emailed it to all of your friends. : )
Then you should have saved it as a
steve
>I have to wonder...who would want a gigapixel camera?
... the person with a gigapixel printer! :-)
steve
I used to feel the same way - my 1.2 megapixel camera had plenty of resolution for everything I did. Alas, a few days ago, I bought a $200 Sony DPP-EX5 dye-sublimation printer. Ooooooh-boy. Now I need a new camera.
The DPP-EX5 prints at 403 DPI. On a 4x6 borderless card, that's 1612x2418, or just over 3 megapixels.
When I print the 1.2 megapixel images from my camera, they look absolutely stunning - unless the image has very sharp-edged details, in which case the 3x upsampling does become noticeable.
So, if I'm going to go to the trouble of using a 400-DPI dye-sub printer, a ~140-DPI image just doesn't fulfill the printer's potential.
Now, I'm looking at cameras. Anything in the 3-megapixel range should work just fine with this printer, but I'm not excluding the 4- and 5-megapixel cameras, either. Just like my 1.2mp camera eventually made me want more, eventually I'll want more than a 3mp camera.
steve
Well, since PhotoShop works on the raw image data, a 1-gigapixel photo at 24 bpp (3 bytes per pixel), you'd need a bare minimum of 3 gigabytes of RAM if you wanted to fit the image in main memory.
So, tell your friend to buy an Opteron with 4-8 gigs of memory, so that when a 64-bit version of Windows and a 64-bit version of Photoshop are available, he can actually work on files this large. : )
steve
It's too bad he didn't post a link to the full file. That would make for a most thorough slashdotting!
steve
You mean that by 2020 we won't be able to keep up with Moore's law?
Golly-gee! That means that we'll only have another 11 doublings of transistor count, meaning we'll be limitted at about 2000 times the number of transistors we have today. Geez, what how would I ever survive with only the equivalent of 2,000 P4/Opteron processers in my desktop?
steve
Wow. You must think that the entire world is like New York City. Maybe you should get out more.
steve
It'd still fritz out pacemakers. And people would still whine that we were immoral, baby-killing pigs for killing 300 innocent people in an attempt to topple a regime that slaughtered tens of thousands ever year.
steve
It's a perfect time to try out a completely humanless mining facility, without any unions getting upset about it!
steve
ARM cores and P3/P4/Athlon/Opteron cores are so incredibly different that comparing them is simply stupid.
Your ARM core has what, 36,000 transistors? Try adding on a floating point unit, for starters. Then add in MMX, SSE, and SSE2 instruction sets. Then see how much power it consumes.
ARMs are great when you need a low-power, low-speed, integer-only processer. Unfortunately, when you need more muscle, an ARM just won't cut it.
steve
The debian installer, overall, isn't all that terrible. The package selection, however, is attrocious. You have two options: Install everything, or spend hours flipping back and forth between the choices and the "fulfill your dependencies" screen a thousand times. If the package selection were designed without the intent of making your life tedious and boring, then the process would be much better. The process isn't hard, it's just long and drawn out.
Now, lest anyone think that this is a Debian-bash, other installers and package-selectors have their flaws as well. RedHat lets you choose packages quickly, and deal with dependencies afterward. However, once it's figured out your dependencies, you either have to go back and try it yourself, or make a blanket decision that will affect all of the packages. A combination of the two would be nice - pick your packages, then let it figure out the dependencies, and let you choose on a package-by-package basis what you want to do.
In RedHat's case, the dependencies are insane. While Perl is a really need programming language, the idea of having a non-working vi because Perl isn't present seems insane to me. And the idea that X-windows just won't work without openssl isn't much better!
Your biggest problem is sorting through the "... and I turned out OK" posts.
Really. With a few exceptions, people tend to justify whatever they do. If they didn't, they'd feel bad. And while some people do walk around in self-loathing from realizing everything they do wrong (or even blaming MORE on themselves), most people will subconsciously do just about anything to keep from feeling like they're doing wrong.
So, the guy who doesn't look at porn will say he turned out alright. The guy that looks at bikini pictures will say "I turned out alright, I don't look at naked pictures." The guy who looks at porn will say "But I turned out alright, I don't do {X}." The guy that's been screwed up will say "and I turned out alright, it's not like I'm doing {X}". And the guy who's been completely messed up will say that he's just living an alternative lifestyle, and that he's not hurting anyone else.
So, basing your decision on the "and I turned out alright" from some guy on the Internet is about as stupid as you can get. You're their parent, you (and they) will bear the consequences of your bad choices. If I were you, I'd start by studying up on child psychology and development, for starters. Understanding why kids do what they do will help you more than anything else.
steve
How can you take him out? Easy. Because for the first two films, you really didn't *see* much of Saruman. All they really show in the films is that he's an old guy that bred some orcs, hates the good guys, and has a funky bowling ball.
Now, cutting him out of the realstory (the books) just wouldn't work. But his character has so little time in the movie that as it probably wouldn't be hard to do without him at all in the third.
steve
Um... given the choice between dying of cancer and having a needle inserted into my prostate, I'm really not sure which I'd choose.
; )
steve
While times *used* to be that it took expensive machines to keep routing tables, a quick trip to eBay with $1,000 will buy you a machine that will handle at least 4 full BGP feeds. If you even need two BGP feeds, chances are that your bandwidth costs greatly eclipse the cost of the router.
steve
so, you make the writes asynchronous. Reads are still going to be terribly slow. You can get around that somewhat by using large amounts of memory for cache, but the first reads will still be pretty slow.
I'd much rather use rsync and tar/gz. In fact, that's what I did.
steve
Really. If you're on a 100-megabit LAN, that gives you a max of about 10 megaBYTES per second. So, if you have to transmit information to two other computers for every disk write, you're effectively limitting yourself to a maximum of about 5 megabytes/second disk transfer. And that's under GOOD situations. If you're doing random I/O, where the latency will be the determining factor, then take the latency of the hard drives, add in the latency of the networking, and the latency of the software layers, and you're looking at some pretty abysmal performance.
Using rsync in a cron job will solve your backup problems. In fact, your script can use rsync to do the synchronization, and tar/gzip to archive the backup - giving you "point in time" snapshots for when someone says "I deleted this file 4 days ago, can you get it back?"
steve
No need to flame, I already realized that I was talking about the wrong product. I'll go stand in the corner....
steve
"A drawback is that the hard drive heat is basically trapped within the enclosure, and users are cautioned not to use drives that generate more than 6.8 watts of heat."
Oh, boy. A way to make the drives even hotter, which will just accelerate wear that much more. And 6.8 watts? That rules out most hard drives these days.
steve
He just didn't really know what he was doing. : )
steve
Hum... your argument makes sense if the two cores actually needed to communicate with each other, but, from my understanding, that's not going to happen much, as they'll typically be running separate threads.
But if the two cores aren't communicating so much, then it seems as if it'd have the opposite effect: they're contending with each other for bandwidth to L3 and/or main memory.
If this were a P3/P4 core, I'd agree. However, the Opteron is an entirely different animal. Remember that each core has it's own memory controller. That means that they're working cooperatively for main memory, and you need high throughput between them. With each core that you add, you add another memory controller (and hence, increase memory bandwidth), but you need to be able to move those bits around.
Also, there is no L3 cache on these chips. Hopefully the chips are not sharing an L2 cache.
Not sure what you're saying about server applications; you kinda contradict yourself, in terms of how compute-bound the applications are.
No, I don't contradict myself at all. In a server environment, you tend to have a good number of applications (or threads) trying to get CPU time. If it's a web server, you tend to have multiple HTTPD processes and multiple CGI processes at once. If it's a database server, you tend to have many threads or processes (depending on the design model) working at once. Even on a file server, you have lots of NFS or Samba processes at once.
For a desktop system, a single fast processer is great. For a server, multiple cores is much better. As I've said before, it's rare for a CPU to be kept 100% busy doing computational work, usually I/O, high interrupts, or context-switches keep you from getting 100% out of your processer.
By having multiple cores on the same chip under this design, you get more memory controllers for more memory bandwidth, a bigger pipe between the cores to move that data around, interrupts can be balanced between the processers, and by having two processers, you only have to execute half of the context-switches, at least in theory.
For server situations where lots of programs are trying to get CPU time, this really does make a lot of sense. For desktop application, it makes very, very little sense. As for HyperThreading letting two threads run at once, it's not quite that simple, and it doesn't buy you a very large speedup. Under heavy DBMS loads, I've seen HT give performance deltas of anywhere from -1% to +3%. Nothing to write home about. : )
steve
Back around 1995, a friend of mine told me his story. His father was an engineer, and had what was at the time a VERY fast computer.
My friend installed Linux on it, and decided to take it off. He decided that "rm -rf
A few minutes later, he remembered that he had his father's DOS partition mounted when he issued the command. He ran back, but it was too late. All of his father's engineering work was gone. : )
steve