But it doesn't do the job nearly as well as it could. Base 64 is virtually alphanumeric, with only two non-alphanumeric characters. You're not including any punctuation or similar characters, making things dramatically easier to crack.
Pretty much. I can't think of any of them having bought a game since getting an R4. And none of them except me even uses any homebrew. One of my friends tried out a homebrew rhythm game, but wasn't impressed. I, on the other hand, have tons of homebrew that I use regularly. It wasn't the sole reason that I bought the R4, however, and anybody who thinks that most people who buy R4s DON'T use them to pirate games is kidding themselves.
Yes. Of the people I know who own a DS Lite (and that's most), I'd guess that about 80-90% of them own an R4 or equivalent device. And such carts have certainly sold millions of units.
The limits of human visual perception aren't only limited to their resolution, or how fast they can discern different images. If that was all that mattered, you could run DooM at 2560x1600 at 60FPS and pretty much have that covered. It's the content of the image that's important.
I think we're decades away from achieving true photorealistic graphics in games. Even the best offline-rendered CG isn't close. Final Fantasy: The Spirits Within was the closest we've probably gotten, and that didn't even manage to get to the other side of the uncanny valley.
For all we know, integrated graphics might go in a completely different direction. For example, the evolution of the GPU is clearly towards the CPU; Larrabee is just that, a 32-core Pentium with a big die shrink and modern extensions and other tweaks tacked on. If that's the way we're going to go, and all 3D rendering is done via software rendering on what is essentially a simplified CPU, I rather suspect that integrated graphics will before long simply cease to exist.
I mean, we'll already be running everything on a software renderer. And there won't be any particular reason why that software renderer need be limited to the graphics CPU. I think that, relatively soon after graphics CPUs replace GPUs, it will simply make more sense to just ditch integrated graphics and run those software renderers on the system's main CPU. There would still be some sort of motherboard-mounted graphics hardware, but it would probably just consist of a DAC/DSP hooked up to the CPU that enables the hardware to take the framebuffer from system memory and convert it to VGA/DVI/DisplayPort/etc.
And I think that this will start to happen within a year of two of graphics CPUs taking over. Which might be as soon as 2010 or 2011, since Larrabee is launching in late 2009. So I'll make that prediction now; integrated graphics will become irrelevant by 2013 at the latest.
PC Gaming is indeed a large market. However when compared to the entire PC market, it's a tiny part. Sure, millions of gamers need powerful 3D graphics in their PCs. And the billions of non-gamers don't. For those non-gamers, integrated stuff is good enough. Almost overkill, these days, really.
You're exaggerating. Modern Intel integrated graphics fully support DirectX 10, and full onboard video decoding. They're comparable to discrete GPUs from about three years ago.
Do these things scream when it comes to games? No, but they don't need to. For the vast majority of people, serious gaming isn't in the cards. These GPUs need to display a 3D accelerated UI with decent performance, and help out with media decoding. Casual gaming is a plus, although businesses aren't interested in that.
By these accounts, integrated graphics are more than sufficient for the vast majority of users.
Besides, from reading most of the comments above, people are missing the point here; this article isn't talking about merging the GPU into the CPU, it's talking about how discrete graphics are becoming increasingly CPU-like, and how we're going to eventually reach the point where GPUs are so general-purpose, they're actually specialized CPUs. This is, infact, exactly what Larrabee is going to be; a very simple massively multicore CPU sitting on an add-in board. Sweeney's prediction is that AMD and nVidia are both going to take their GPUs to similar places eventually.
If the performance degradation 5 years ago was 20-30% because the things were pumping out a ton of interrupts, one would expect the resurgence of multithreaded CPUs to further reduce the impact. They should help with context switches. When you've got eight logical cores, that 30% is suddenly 4%, and much less important.
US-Robotics still sells "hardware" modems, although they're not all that cheap. But back in the day, they did cut 50-100ms of latency off a dialup connection when compared to a winmodem (or controllerless).
Does nobody remember the PicoTux (http://hardware.slashdot.org/article.pl?sid=05/03/28/2237230&from=rss) or other similar RJ-45 sized computers? This Space Cube thing is most certainly not the "smallest" Linux PC.
It's unfortunate that PicoTux hasn't upgraded their specs during the intervening years; if they could fit a 55MHz ARM processor with 8MB of RAM into an RJ-45 socket back in 2005, I'm almost certain they could do better today.
It's already fast enough to do light routing duties (plug the thing into a switch and you've got a working PPPoE DSL router), but a faster CPU and more RAM would almost certainly help.
For comparison, this thing has 4MB flash, 8MB of RAM, and a 55MHz ARM processor. The flash and RAM are the same as a current-gen WRT54G modem, and half each of the WRT54GL (needed for doing much more than basic stuff). If only they could get a faster processor on those things (the WRT54GL is a 200MHz MIPS processor, the WRTSL54G is 264MHz), you'd have equivalent flexibility (minus the WRT's onboard switch) in a far smaller package.
Their network setup is impressive. Their connection to the outside world isn't. 20mbit? Less downstream than a good DSL line. And their traffic counts? Pitifully low. 12GB in over 30 hours is under 10% average utilization.
I see three possibilities:
1) People just aren't using the internet much 2) There are so many attacks going on that the network is unusable for actual internet connectivity 3) People are too busy trying to attack things that they don't bother with the internet.
There are other indy stores that WILL do it for you. I was in an indy video/game rental store in downtown Montreal, and noticed that they were charging a few bucks a pop to resurface discs. I don't recall offhand how much, I think it was $4.
To me, the answer is clear:
Step 1: Try using EAC to extract the disc, see if any tracks can be extracted completely without error Step 2: Try some simple cleaning techniques yourself, as mentioned here. Step 3: Try EAC again to see if the remaining damaged tracks can be recovered Step 4: Download lossless versions of the songs from the net (you own the disc) Step 5: If tracks remain damaged and you can't find an online copy (or don't want to), pay to have the disc resurfaced. Step 6: After resurfacing, once again use EAC to get the remaining tracks Step 7: You should now have all tracks in error-free lossless format. Back them up and burn an audio CD. Done.
That's great. As long as they don't own a laptop (laptop audio and wireless support is still problematic out-of-the-box), run into any other unsupported software, or need to install anything. Otherwise you'll probably end up setting it up for them.
I recently switched from Vista to Kubuntu (8.04), and the process was anything but smooth. Getting full audio support working required me to write custom bash scripts to handle volume changes and muting. Wireless is still iffy, as it required ndiswrapper, doesn't work with the built-in wireless tools (custom configs required), and even still has a hacky DHCP setup that fails if it takes longer than 5 seconds to associate.
Weeks later, I'm still running into things that just don't work properly, requiring me to write scripts, edit config files, and generally muck about with things.
Oh yeah, and my printer, a $100 Canon (MP470) requires a $45 proprietary print driver (which is 32-bit only). Fun.
In short, while Ubuntu and Linux have made great strides on the desktop, I still wouldn't want my parents using it. I'd have to spend tens of hours setting things up for them, and even then it wouldn't necessarily "just work".
That assumes that Bell is recording usage as the difference between the last measurement was taken 15 minutes ago, and not as a snapshot of the current usage.
Presuming that it is an average of the previous 15 minutes, your logic is still flawed; yes, the latency will be increased on a line with 90% utilization, but not by minutes.
First of all, you have to understand that the larger the pipe (the greater the aggregation), the less impact bursts have on the line. An OC-48 is about 2.5 gigabits per second. Furthermore, the end-user connection on this network are primarily 5mbit DSL users, and we're talking about an ATM network right up until they hit the wholesaler's own network (where congestion isn't an issue).
ATM cells are 53 bytes. You can send about 6 million per second on an OC-48. And the buffers on routers don't have room for minutes of data; if the buffer is full, it drops packets. Bell isn't dropping packets (beyond ~3000 times per month network-wide), so they're obviously not filling those buffers.
You raise a good point; people have pointed out that Bell's graphs of the ATM cell loss events started going up pretty much in tune with the installation of the DPI boxes.
The relevant networks here are all ATM (the ones being throttled, the ones P2P is being used over).
My understanding is that ATM doesn't handle retransmissions. Furthermore, Bell's data shows that network wide, with millions of customers and trillions of ATM cells flying about per month, they only suffer from about 3500-4500 cell loss events per month.
You'd think that if they had even a single congested line, they'd be dropping millions (or even billions) of ATM cells per month.
You're completely incorrect because you're completely ignoring Bell's criteria for a line being considered congested.
First, their thresholds: They consider anything over the following utilization thresholds to be congested:
DS-3 61%, OC-3 84%, OC-12 and OC-48 90%.
Second, they determine usage and congestion by taking samples every 15 minutes. If five samples return percentages over those limits in a 14 day period, the line is considered to be congested for the entire 14 day period.
Their percentages are actually not all that bad; they're a useful guideline for when it's time to turn on another link. Their methodology for MEASURING the usage, on the other hand, is completely flawed. A two-hour long DDoS attack one afternoon might mark a slew of lines as congested for two entire weeks.
Further bolstering the fact that they've chosen their measurements to make the issue seem worse than it appears is that despite the supposed congestion on a given percentage of their lines, they only have about 4000 ATM cell loss events network-wide each month. This is out of the trillions of ATM cells flying around their network every month, they only drop a percentage so small that my calculator resorts to scientific notation trying to calculate it.
In short, they've pretty much made up the issue. Their figures when taken at face value don't indicate significant congestion (5% of lines congested? Why not just purchased a handful more lines?), when examined based on their methodology appear to be garbage data, and when compared against actual packetloss caused by congestion, is proven to be completely non-existent. Bell has zero actual network congestion, their own ATM loss data backs that up.
Disclaimer: I'm not a network engineer, and so I might be talking out of my ass. But I think that common sense can play a role here; their methodology makes it trivial to declare a line as congested, and having 4000 instances of ATM cell loss on a network in a month with millions of customers (and trillions of ATM cells sent per month) doesn't seem particularly bad.
I don't particularly care which is more free, or less free, or which license has which clauses and provisions. An enduser shouldn't have to care about any of that. And as an enduser, I'd like to use ZFS natively without resorting to FUSE.
Then again, Sun has already said that anybody is free to re-implement ZFS themselves under a GPL license if they feel so inclined. Unfortunate that nobody has bothered.
I think you're confused about a great many things. The 9800 GX2 (not GTX2) is equivalent to two 9800s, not two 9800 GTX.
Since the GTX 280 is consistently slower than a single 9800 GX2, and since two 9800 GTX are faster than a single 9800 GX2, it's quite obvious that the GTX 280 is slower than two 9800 GTX.
In fact, Anandtech's results show that the GTX 280 is slower than two 8800 GTs in most tests. Considering that you can buy two 8800GTs for a bit more than half the projected cost of the GTX 280, that really doesn't bear well for it.
Slashdot Mirror
The problem is that you can trivially do MORE in the same amount of space. There's no harm in including more printable characters.
But it doesn't do the job nearly as well as it could. Base 64 is virtually alphanumeric, with only two non-alphanumeric characters. You're not including any punctuation or similar characters, making things dramatically easier to crack.
That sounds a lot like what Bell Canada did; they launched a pre-spec WiMax service years ago.
Saying that "WiMax Is Finally Coming" is a bit late, though; Wikipedia lists hundreds of existing deployments:
http://en.wikipedia.org/wiki/List_of_deployed_WiMAX_networks
Pretty much. I can't think of any of them having bought a game since getting an R4. And none of them except me even uses any homebrew. One of my friends tried out a homebrew rhythm game, but wasn't impressed. I, on the other hand, have tons of homebrew that I use regularly. It wasn't the sole reason that I bought the R4, however, and anybody who thinks that most people who buy R4s DON'T use them to pirate games is kidding themselves.
Yes. Of the people I know who own a DS Lite (and that's most), I'd guess that about 80-90% of them own an R4 or equivalent device. And such carts have certainly sold millions of units.
The limits of human visual perception aren't only limited to their resolution, or how fast they can discern different images. If that was all that mattered, you could run DooM at 2560x1600 at 60FPS and pretty much have that covered. It's the content of the image that's important.
I think we're decades away from achieving true photorealistic graphics in games. Even the best offline-rendered CG isn't close. Final Fantasy: The Spirits Within was the closest we've probably gotten, and that didn't even manage to get to the other side of the uncanny valley.
For all we know, integrated graphics might go in a completely different direction. For example, the evolution of the GPU is clearly towards the CPU; Larrabee is just that, a 32-core Pentium with a big die shrink and modern extensions and other tweaks tacked on. If that's the way we're going to go, and all 3D rendering is done via software rendering on what is essentially a simplified CPU, I rather suspect that integrated graphics will before long simply cease to exist.
I mean, we'll already be running everything on a software renderer. And there won't be any particular reason why that software renderer need be limited to the graphics CPU. I think that, relatively soon after graphics CPUs replace GPUs, it will simply make more sense to just ditch integrated graphics and run those software renderers on the system's main CPU. There would still be some sort of motherboard-mounted graphics hardware, but it would probably just consist of a DAC/DSP hooked up to the CPU that enables the hardware to take the framebuffer from system memory and convert it to VGA/DVI/DisplayPort/etc.
And I think that this will start to happen within a year of two of graphics CPUs taking over. Which might be as soon as 2010 or 2011, since Larrabee is launching in late 2009. So I'll make that prediction now; integrated graphics will become irrelevant by 2013 at the latest.
PC Gaming is indeed a large market. However when compared to the entire PC market, it's a tiny part. Sure, millions of gamers need powerful 3D graphics in their PCs. And the billions of non-gamers don't. For those non-gamers, integrated stuff is good enough. Almost overkill, these days, really.
You're exaggerating. Modern Intel integrated graphics fully support DirectX 10, and full onboard video decoding. They're comparable to discrete GPUs from about three years ago.
Do these things scream when it comes to games? No, but they don't need to. For the vast majority of people, serious gaming isn't in the cards. These GPUs need to display a 3D accelerated UI with decent performance, and help out with media decoding. Casual gaming is a plus, although businesses aren't interested in that.
By these accounts, integrated graphics are more than sufficient for the vast majority of users.
Besides, from reading most of the comments above, people are missing the point here; this article isn't talking about merging the GPU into the CPU, it's talking about how discrete graphics are becoming increasingly CPU-like, and how we're going to eventually reach the point where GPUs are so general-purpose, they're actually specialized CPUs. This is, infact, exactly what Larrabee is going to be; a very simple massively multicore CPU sitting on an add-in board. Sweeney's prediction is that AMD and nVidia are both going to take their GPUs to similar places eventually.
If the performance degradation 5 years ago was 20-30% because the things were pumping out a ton of interrupts, one would expect the resurgence of multithreaded CPUs to further reduce the impact. They should help with context switches. When you've got eight logical cores, that 30% is suddenly 4%, and much less important.
US-Robotics still sells "hardware" modems, although they're not all that cheap. But back in the day, they did cut 50-100ms of latency off a dialup connection when compared to a winmodem (or controllerless).
Does nobody remember the PicoTux (http://hardware.slashdot.org/article.pl?sid=05/03/28/2237230&from=rss) or other similar RJ-45 sized computers? This Space Cube thing is most certainly not the "smallest" Linux PC.
It's unfortunate that PicoTux hasn't upgraded their specs during the intervening years; if they could fit a 55MHz ARM processor with 8MB of RAM into an RJ-45 socket back in 2005, I'm almost certain they could do better today.
It's already fast enough to do light routing duties (plug the thing into a switch and you've got a working PPPoE DSL router), but a faster CPU and more RAM would almost certainly help.
For comparison, this thing has 4MB flash, 8MB of RAM, and a 55MHz ARM processor. The flash and RAM are the same as a current-gen WRT54G modem, and half each of the WRT54GL (needed for doing much more than basic stuff). If only they could get a faster processor on those things (the WRT54GL is a 200MHz MIPS processor, the WRTSL54G is 264MHz), you'd have equivalent flexibility (minus the WRT's onboard switch) in a far smaller package.
The United States of America, where fibre-to-the-home is available in many markets at speeds of up to 50mbit down and 20mbit up?
Their network setup is impressive. Their connection to the outside world isn't. 20mbit? Less downstream than a good DSL line. And their traffic counts? Pitifully low. 12GB in over 30 hours is under 10% average utilization.
I see three possibilities:
1) People just aren't using the internet much
2) There are so many attacks going on that the network is unusable for actual internet connectivity
3) People are too busy trying to attack things that they don't bother with the internet.
They're not $7 a disc, they're (about) $7 for one disc.
If you do 10 discs with them, you'll pay about $3.80 per disc.
There are other indy stores that WILL do it for you. I was in an indy video/game rental store in downtown Montreal, and noticed that they were charging a few bucks a pop to resurface discs. I don't recall offhand how much, I think it was $4.
To me, the answer is clear:
Step 1: Try using EAC to extract the disc, see if any tracks can be extracted completely without error
Step 2: Try some simple cleaning techniques yourself, as mentioned here.
Step 3: Try EAC again to see if the remaining damaged tracks can be recovered
Step 4: Download lossless versions of the songs from the net (you own the disc)
Step 5: If tracks remain damaged and you can't find an online copy (or don't want to), pay to have the disc resurfaced.
Step 6: After resurfacing, once again use EAC to get the remaining tracks
Step 7: You should now have all tracks in error-free lossless format. Back them up and burn an audio CD. Done.
So, graphics are more important to you than gameplay? That's a rather shallow attitude.
I suggest you take a little trip to South Korea, where their national sport is a 10 year old 2D Blizzard game that runs at 640x480.
That's great. As long as they don't own a laptop (laptop audio and wireless support is still problematic out-of-the-box), run into any other unsupported software, or need to install anything. Otherwise you'll probably end up setting it up for them.
I recently switched from Vista to Kubuntu (8.04), and the process was anything but smooth. Getting full audio support working required me to write custom bash scripts to handle volume changes and muting. Wireless is still iffy, as it required ndiswrapper, doesn't work with the built-in wireless tools (custom configs required), and even still has a hacky DHCP setup that fails if it takes longer than 5 seconds to associate.
Weeks later, I'm still running into things that just don't work properly, requiring me to write scripts, edit config files, and generally muck about with things.
Oh yeah, and my printer, a $100 Canon (MP470) requires a $45 proprietary print driver (which is 32-bit only). Fun.
In short, while Ubuntu and Linux have made great strides on the desktop, I still wouldn't want my parents using it. I'd have to spend tens of hours setting things up for them, and even then it wouldn't necessarily "just work".
There's always Bell Canada's approach; use DPI equipment to throttle P2P to 30KB/s.
That assumes that Bell is recording usage as the difference between the last measurement was taken 15 minutes ago, and not as a snapshot of the current usage.
Presuming that it is an average of the previous 15 minutes, your logic is still flawed; yes, the latency will be increased on a line with 90% utilization, but not by minutes.
First of all, you have to understand that the larger the pipe (the greater the aggregation), the less impact bursts have on the line. An OC-48 is about 2.5 gigabits per second. Furthermore, the end-user connection on this network are primarily 5mbit DSL users, and we're talking about an ATM network right up until they hit the wholesaler's own network (where congestion isn't an issue).
ATM cells are 53 bytes. You can send about 6 million per second on an OC-48. And the buffers on routers don't have room for minutes of data; if the buffer is full, it drops packets. Bell isn't dropping packets (beyond ~3000 times per month network-wide), so they're obviously not filling those buffers.
You raise a good point; people have pointed out that Bell's graphs of the ATM cell loss events started going up pretty much in tune with the installation of the DPI boxes.
That particular 4-letter lobbying organization being, of course, the CRIA?
The relevant networks here are all ATM (the ones being throttled, the ones P2P is being used over).
My understanding is that ATM doesn't handle retransmissions. Furthermore, Bell's data shows that network wide, with millions of customers and trillions of ATM cells flying about per month, they only suffer from about 3500-4500 cell loss events per month.
You'd think that if they had even a single congested line, they'd be dropping millions (or even billions) of ATM cells per month.
You're completely incorrect because you're completely ignoring Bell's criteria for a line being considered congested.
First, their thresholds: They consider anything over the following utilization thresholds to be congested:
DS-3 61%, OC-3 84%, OC-12 and OC-48 90%.
Second, they determine usage and congestion by taking samples every 15 minutes. If five samples return percentages over those limits in a 14 day period, the line is considered to be congested for the entire 14 day period.
Their percentages are actually not all that bad; they're a useful guideline for when it's time to turn on another link. Their methodology for MEASURING the usage, on the other hand, is completely flawed. A two-hour long DDoS attack one afternoon might mark a slew of lines as congested for two entire weeks.
Further bolstering the fact that they've chosen their measurements to make the issue seem worse than it appears is that despite the supposed congestion on a given percentage of their lines, they only have about 4000 ATM cell loss events network-wide each month. This is out of the trillions of ATM cells flying around their network every month, they only drop a percentage so small that my calculator resorts to scientific notation trying to calculate it.
In short, they've pretty much made up the issue. Their figures when taken at face value don't indicate significant congestion (5% of lines congested? Why not just purchased a handful more lines?), when examined based on their methodology appear to be garbage data, and when compared against actual packetloss caused by congestion, is proven to be completely non-existent. Bell has zero actual network congestion, their own ATM loss data backs that up.
Disclaimer: I'm not a network engineer, and so I might be talking out of my ass. But I think that common sense can play a role here; their methodology makes it trivial to declare a line as congested, and having 4000 instances of ATM cell loss on a network in a month with millions of customers (and trillions of ATM cells sent per month) doesn't seem particularly bad.
I don't particularly care which is more free, or less free, or which license has which clauses and provisions. An enduser shouldn't have to care about any of that. And as an enduser, I'd like to use ZFS natively without resorting to FUSE.
Then again, Sun has already said that anybody is free to re-implement ZFS themselves under a GPL license if they feel so inclined. Unfortunate that nobody has bothered.
I think you're confused about a great many things. The 9800 GX2 (not GTX2) is equivalent to two 9800s, not two 9800 GTX.
Since the GTX 280 is consistently slower than a single 9800 GX2, and since two 9800 GTX are faster than a single 9800 GX2, it's quite obvious that the GTX 280 is slower than two 9800 GTX.
In fact, Anandtech's results show that the GTX 280 is slower than two 8800 GTs in most tests. Considering that you can buy two 8800GTs for a bit more than half the projected cost of the GTX 280, that really doesn't bear well for it.
I was focusing on the Linux part of "Helps in Windows and Linux".