Nobody ever said that the people behind the scam weren't ultimately culpable. However, there's simply no helping some people. All the blame on instigating the scam falls on the originators. All the blame for it working falls on the victim's gross incompetence.
That said, she's very lucky. If it only takes her three to four years to dig herself out of almost half a million dollars in debt, she's far better off than most people. Most people would take decades to dig themselves out of that kind of debt.
SourceForge provides free unlimited webhosting for all their hosted projects. They also supply a wiki for your project, as well as a hosted MySQL database to power your site.
In other words, running a very busy site for an opensource project costs nothing from a hardware or bandwidth perspective, because SourceForge will give it to you for free.
That said, I find from experience that most people overpay for web-related services due to a perceived overestimation of their reliability requirements. A friend recently moved (after being ordered to by his boss) to a service provider that charges about a third as much as his old host. Yes, there's a certain sacrifice as far as the quality of service and reliability, but he was grossly overestimating his requirements in that regard.
The issue was that he needed a lot more resources than he was getting, and had to do it inside the same budget. He refused to do anything about it (since any change would have meant sacrificing quality) until he was ordered to. Any extra reliability from the original host were lost due to things frequently blowing up due to insufficient RAM (and no swap) anyway.
It would probably help if you said what you think is wrong with the existing map and unit making tools. Apparently the community thought they were good enough to pump out a ton of awesome custom maps and units.
From the experience running Ubuntu's AMD64 version, there isn't really anything to be a PITA; the only thing with any issues whatsoever is that you must use npviewer to get Flash running in a 64-bit browser, and it's very unreliable.
OTOH, the game is mod-friendly enough that somebody could produce a mod that rolls back the game to any previous version, or makes whatever other balance changes they like. There have always been a ton of balance-related SupCom mods.
With vanilla, the built-in AI was so horrible that Sorian was pretty much required to get any challenge out of skirmishes or comp stomps. And I'm absolutely horrible at RTS games, as much as I love them. However, by the time FA came out, the built-in AI had improved to the extent that it didn't really need help to kick my ass.
Unfortunately, even though the built-in AI was much improved, it was still dumb. One of the advantages of Sorian was that it behaved a lot more like a human, making the game more fun as well as more challenging.
So, for me, enabling Sorian in FA is just a recipe for an asskicking.
So, with FA, if you're a player of average or sub-par ability like me, you've either got the choice of an AI that's the proper difficulty but not very human, and an AI that's too hard but very human.
It's too bad there's no "easy" version of Sorian; comes with the improved logic, but not quite as difficult. Perhaps the opposite of the cheating AI would help. Or adding random delays to commands issued to slow it down. That sort of thing.
You must have missed the part where the OP said that they were already using their Blackberry as a pager, but were ditching it because it "is quiet and has a pathetic vibrate mode".
He's complaining that the volume isn't loud enough, and that the vibration isn't sufficient.
You can build a single server containing 12TB powered by ZFS and RAIDZ for about $3000-3500 Canadian, including hot-swap drive bays. And the drives.
Sure, there's probably a lot of redundancy in these Sun boxes, but if they're relying on ZFS/RAIDZ to provide much of the reliability, and you build your $3500 box (which is housed in a mid-tower case with 9 drive bays) using OpenSolaris, you're most of the way there. At that point, you've got the data reliability, you just might not have quite the same uptime.
The thing is, for the prices they charge for even a single node ($57,490), I could build half a dozen of my commodity boxes and replicate the data between them. And it would still cost less. And probably perform faster; I could also cluster with redundancy for less than they charge, and they're using commodity 7200RPM SATA drives.
I'm not referring to the wrt54g routers. Obviously the later models in the WRT54G were cut down to 2MB flash and 8MB RAM. However some of the newer N models feature 8MB flash and 32MB of RAM. One of the higher end Linksys models features 64MB of RAM with a 300MHz processor, which is an enormous boost over the WRT54GL. Newer versions of the 350N have a 500MHz processor.
Many competing models have more too. Higher end Asus models have 32 or 64MB of RAM and 256-266MHz processors. The same applies to Buffalo's products.
The WRT54G series is about 6 years old now. Back when the first version was introduced, the AthlonXP was still AMD's main CPU line! The specs seen in the WRT54GL first appeared about half a decade ago. To say that this isn't antiquated is silly; the router is old hardware, no two ways about it.
I'm one of two people maintaining a fork of the popular Tomato firmware for the WRT series. The limited CPU power in these things is a constant frustration.
These days, for only slightly more than the MSRP of the WRT54GL, you can buy a RouterBoard with an 800MHz processor and 64MB of RAM. That's the kind of hardware I'd like to see driven into mass-market consumer products. We could push past all of our current limitations with that sort of hardware.
As said in another comment, primarily, the CPU is slow. Newer routers offer significantly more performance. And the thing IS CPU limited when you try to push decent amounts of bandwidth through it.
1) Uses 802.11g (not n) 2) Uses FastE (not GigE) 3) Small amount of RAM (16MB, compared to 32 or 64 in newer routers) 4) Very slow CPU (200MHz), compared to 260MHz in newer WRTs (WRTSL54GS) or 300+ in other newer models.
I'm one of the developers maintaining a fork of Tomato that adds support for MLPPP (bonding multiple DSL lines), and the CPU is our primary limitation; you can push ~15mbit aggregate (with QoS) before you start hitting limitations on the 200MHz models. Wireless encryption takes a chunk out of that (a very big chunk), QoS is taking a chunk out of what it could do, etc.
One user boosted his speed by hacking up our firmware and disabling all routing except for packet forwarding, to use the router as nothing more than a PPP client, letting a full Linux box do the routing. Another heavily overclocked his model from 200 to 250MHz.
Where we live, 5/800 DSL is standard for wholesalers (who are the ones supporting MLPPP), and it's unlikely that the WRT54GL could handle more than 3 lines.
It's common for many smaller ISPs (around here, at least) to start out with a Cogent link until they're large enough to be able to afford being multi-homed. And some of the smaller ISPs offer excellent service, despite being single-homed.
Of course, most of these companies DO throw other providers into the mix as soon as they have enough traffic to be able to make a sufficiently large commit to the second provider to not get charged through the nose per-megabit. But everybody has gotta start somewhere, right?
I was lucky throughout this. As a consumer, my ISP is multihomed, having a Cogent link, but also numerous others. There were no connectivity issues there. As a server admin, my host is single-homed with Cogent. They have some other peering going on, but not for transit.
Of course, I don't care if my server host is single-homed; similar to my ISP example above, they provide quite good service at dirt-cheap prices (and it's a non-critical server). They're an example of a company not large enough to be able to justify going multihomed, although I know it's in the cards eventually.
My bad, it seems this is somewhat recent. Last time I heard VMWare talking about migrating nodes, they had a video with a guy tauting how they handled failure by dynamically moving the node to other hardware, but it didn't do live migration at that point.
1) If you're shutting down outside of nighttime, you're wasting resources and can consolidate by virtualizing on fewer hosts
2) Enable power management on your servers. Things like SpeedStep and HDD power management (or even spinning down certain disks) can go a long way to reducing power requirements when load is light
3) Suspend, don't power off; you can configure your servers to go to sleep after not receiving any traffic for a certain period of time, and then automatically wake up and handle the request when they receive ethernet traffic. This might add a few seconds of delay to the first request when waking up, but if it's the first request of the morning after being asleep for the night, that's probably not a big concern.
Combining these three could produce significant power savings without the downside of shutting them off; powered-down servers can't answer requests at all.
VMWare doesn't support hot migration; the action of doing those moves involve shutting down (or at least suspending, don't remember), and starting/resuming them again on the other end.
As a non-professional server admin maintaining two boxes (a VPS for myself, and a webserver for a university club I belong to), I'm happy. I chose it because I'm quite familiar with Ubuntu since I use it on the desktop, and I hate RHEL.
It's very lightweight. Server installs almost nothing by default, letting you install just what you need. After setting up the club's computer with a mail server, MySQL service, and Lighttpd, the thing was only using 37MB of RAM (nice, considering the box only has 384MB). So, not a lot of cruft there.
It's also, as I said, what I'm familiar with, so maintenance is quite smooth.
They also have easy upgrade paths (although upgrading between versions would be stupid in a production environment). Some of the other enterprise-oriented distros (RHEL, I'm looking at you) don't support upgrades very well.
On the other hand, while people like me might be an excellent target market for their server release, we're also not buying support contracts, so that's a bit of a problem.
Why would Debian's release schedule cause somebody to use a non-LTS release of Ubuntu instead of an LTS release?
Server LTS releases are supported for five years. That's pretty decent. They're also predictable, happening every two years, give or take a few months.
Furthermore, many of the benchmarks show things getting faster in newer releases, not slower. In many benchmarks, 7.04 is a distant last place. So it's not so cut and dry. It seems that if the benchmarks were done correctly (as in, figuring out why memory bandwidth was affected), the opposite of the claimed findings might be found to be true.
Youtube solution: Install flashblock, visit the YouTube page, paste the URL into VLC, which will stream it off the site without loading anything extra.
Bandwidth saving solution: Grab a cheap VPS (you can get pretty darned awesome Xen ones with 256MB RAM and 500GB of bandwidth for $13/mth or less), run a proxy on it. Have that proxy gzip all content that goes through it, and recompress images if you can find software. Alternatively, just run squid, tunnel to it over SSH, and enable SSH compression. That should produce some savings.
Ultimate bandwidth saver for the desperate: Opera Mini on a desktop.
Opera Mini is a J2ME cellphone app that is designed to make browsing fast on slow 2G handsets. It runs all data through Opera's proxy servers, compressing content, recompressing images, and packing everything into one file to reduce roundtrips.
It can actually be made to run on a desktop at arbitrary resolutions (say, 1920x1200) via MicroEmulator. Instructions can be found here:
I daresay that it's impossible to reduce bandwidth usage more than the Opera Mini approach short of using a text-only browser through a compressed link.
While Video can benefit from higher resolutions, higher framerates, and higher bitrates, audio advances at a much slower pace, and most people can't tell the difference (or don't care) anyhow.
BluRay isn't doing so hot because, despite the large difference in quality between DVD and BluRay, most people just don't care. Why should audio, with almost imperceptible differences, be any different?
It's got a ram cache and a battery backup for that ram for a reason kiddies.
Yeah, because of the write-hole; that's got nothing to do with the original issue. Such issues are also solved on a software level via atomic writes by the filesystem at substantially less cost.
There was a reason that ZFS/RAID-Z was mentioned; when you have a checksum of every block, you know which bit was flipped because all but one of your checksums match. This limits the damage if you have no parity (RAID-Z with one failed disk, RAID-Z2 with two failed disks, etc.)
The only thing keeping me from using ZFS/RAID-Z is the inability to grow an array by adding more disks (similarly sized or otherwise). You'd think this would be kind of useful, being able to take a 3x1TB RAID-Z array and add another to get a 4x1TB RAID-Z array.
Slashdot Mirror
Nobody ever said that the people behind the scam weren't ultimately culpable. However, there's simply no helping some people. All the blame on instigating the scam falls on the originators. All the blame for it working falls on the victim's gross incompetence.
That said, she's very lucky. If it only takes her three to four years to dig herself out of almost half a million dollars in debt, she's far better off than most people. Most people would take decades to dig themselves out of that kind of debt.
Think Flash sucks on AMD64? Just wait for Ubuntu on the ARM, where you can't run Flash at all.
Seriously, netbooks are useful for a small subset of tasks, and crippling web browsing doesn't exactly make them very appealing.
SourceForge provides free unlimited webhosting for all their hosted projects. They also supply a wiki for your project, as well as a hosted MySQL database to power your site.
In other words, running a very busy site for an opensource project costs nothing from a hardware or bandwidth perspective, because SourceForge will give it to you for free.
That said, I find from experience that most people overpay for web-related services due to a perceived overestimation of their reliability requirements. A friend recently moved (after being ordered to by his boss) to a service provider that charges about a third as much as his old host. Yes, there's a certain sacrifice as far as the quality of service and reliability, but he was grossly overestimating his requirements in that regard.
The issue was that he needed a lot more resources than he was getting, and had to do it inside the same budget. He refused to do anything about it (since any change would have meant sacrificing quality) until he was ordered to. Any extra reliability from the original host were lost due to things frequently blowing up due to insufficient RAM (and no swap) anyway.
It would probably help if you said what you think is wrong with the existing map and unit making tools. Apparently the community thought they were good enough to pump out a ton of awesome custom maps and units.
From the experience running Ubuntu's AMD64 version, there isn't really anything to be a PITA; the only thing with any issues whatsoever is that you must use npviewer to get Flash running in a 64-bit browser, and it's very unreliable.
OTOH, the game is mod-friendly enough that somebody could produce a mod that rolls back the game to any previous version, or makes whatever other balance changes they like. There have always been a ton of balance-related SupCom mods.
With vanilla, the built-in AI was so horrible that Sorian was pretty much required to get any challenge out of skirmishes or comp stomps. And I'm absolutely horrible at RTS games, as much as I love them. However, by the time FA came out, the built-in AI had improved to the extent that it didn't really need help to kick my ass.
Unfortunately, even though the built-in AI was much improved, it was still dumb. One of the advantages of Sorian was that it behaved a lot more like a human, making the game more fun as well as more challenging.
So, for me, enabling Sorian in FA is just a recipe for an asskicking.
So, with FA, if you're a player of average or sub-par ability like me, you've either got the choice of an AI that's the proper difficulty but not very human, and an AI that's too hard but very human.
It's too bad there's no "easy" version of Sorian; comes with the improved logic, but not quite as difficult. Perhaps the opposite of the cheating AI would help. Or adding random delays to commands issued to slow it down. That sort of thing.
You must have missed the part where the OP said that they were already using their Blackberry as a pager, but were ditching it because it "is quiet and has a pathetic vibrate mode".
He's complaining that the volume isn't loud enough, and that the vibration isn't sufficient.
You can build a single server containing 12TB powered by ZFS and RAIDZ for about $3000-3500 Canadian, including hot-swap drive bays. And the drives.
Sure, there's probably a lot of redundancy in these Sun boxes, but if they're relying on ZFS/RAIDZ to provide much of the reliability, and you build your $3500 box (which is housed in a mid-tower case with 9 drive bays) using OpenSolaris, you're most of the way there. At that point, you've got the data reliability, you just might not have quite the same uptime.
The thing is, for the prices they charge for even a single node ($57,490), I could build half a dozen of my commodity boxes and replicate the data between them. And it would still cost less. And probably perform faster; I could also cluster with redundancy for less than they charge, and they're using commodity 7200RPM SATA drives.
I'm not referring to the wrt54g routers. Obviously the later models in the WRT54G were cut down to 2MB flash and 8MB RAM. However some of the newer N models feature 8MB flash and 32MB of RAM. One of the higher end Linksys models features 64MB of RAM with a 300MHz processor, which is an enormous boost over the WRT54GL. Newer versions of the 350N have a 500MHz processor.
Many competing models have more too. Higher end Asus models have 32 or 64MB of RAM and 256-266MHz processors. The same applies to Buffalo's products.
The WRT54G series is about 6 years old now. Back when the first version was introduced, the AthlonXP was still AMD's main CPU line! The specs seen in the WRT54GL first appeared about half a decade ago. To say that this isn't antiquated is silly; the router is old hardware, no two ways about it.
I'm one of two people maintaining a fork of the popular Tomato firmware for the WRT series. The limited CPU power in these things is a constant frustration.
These days, for only slightly more than the MSRP of the WRT54GL, you can buy a RouterBoard with an 800MHz processor and 64MB of RAM. That's the kind of hardware I'd like to see driven into mass-market consumer products. We could push past all of our current limitations with that sort of hardware.
As said in another comment, primarily, the CPU is slow. Newer routers offer significantly more performance. And the thing IS CPU limited when you try to push decent amounts of bandwidth through it.
Antiquated in four ways:
1) Uses 802.11g (not n)
2) Uses FastE (not GigE)
3) Small amount of RAM (16MB, compared to 32 or 64 in newer routers)
4) Very slow CPU (200MHz), compared to 260MHz in newer WRTs (WRTSL54GS) or 300+ in other newer models.
I'm one of the developers maintaining a fork of Tomato that adds support for MLPPP (bonding multiple DSL lines), and the CPU is our primary limitation; you can push ~15mbit aggregate (with QoS) before you start hitting limitations on the 200MHz models. Wireless encryption takes a chunk out of that (a very big chunk), QoS is taking a chunk out of what it could do, etc.
One user boosted his speed by hacking up our firmware and disabling all routing except for packet forwarding, to use the router as nothing more than a PPP client, letting a full Linux box do the routing. Another heavily overclocked his model from 200 to 250MHz.
Where we live, 5/800 DSL is standard for wholesalers (who are the ones supporting MLPPP), and it's unlikely that the WRT54GL could handle more than 3 lines.
A faster CPU would really improve things.
Only buy home routers that can run opensource firmwares. I'm quite happy with my WRT54GL, although the hardware is a bit antiquated at this point.
It's common for many smaller ISPs (around here, at least) to start out with a Cogent link until they're large enough to be able to afford being multi-homed. And some of the smaller ISPs offer excellent service, despite being single-homed.
Of course, most of these companies DO throw other providers into the mix as soon as they have enough traffic to be able to make a sufficiently large commit to the second provider to not get charged through the nose per-megabit. But everybody has gotta start somewhere, right?
I was lucky throughout this. As a consumer, my ISP is multihomed, having a Cogent link, but also numerous others. There were no connectivity issues there. As a server admin, my host is single-homed with Cogent. They have some other peering going on, but not for transit.
Of course, I don't care if my server host is single-homed; similar to my ISP example above, they provide quite good service at dirt-cheap prices (and it's a non-critical server). They're an example of a company not large enough to be able to justify going multihomed, although I know it's in the cards eventually.
My bad, it seems this is somewhat recent. Last time I heard VMWare talking about migrating nodes, they had a video with a guy tauting how they handled failure by dynamically moving the node to other hardware, but it didn't do live migration at that point.
Shutting down seems wasteful. I would:
1) If you're shutting down outside of nighttime, you're wasting resources and can consolidate by virtualizing on fewer hosts
2) Enable power management on your servers. Things like SpeedStep and HDD power management (or even spinning down certain disks) can go a long way to reducing power requirements when load is light
3) Suspend, don't power off; you can configure your servers to go to sleep after not receiving any traffic for a certain period of time, and then automatically wake up and handle the request when they receive ethernet traffic. This might add a few seconds of delay to the first request when waking up, but if it's the first request of the morning after being asleep for the night, that's probably not a big concern.
Combining these three could produce significant power savings without the downside of shutting them off; powered-down servers can't answer requests at all.
VMWare doesn't support hot migration; the action of doing those moves involve shutting down (or at least suspending, don't remember), and starting/resuming them again on the other end.
As a non-professional server admin maintaining two boxes (a VPS for myself, and a webserver for a university club I belong to), I'm happy. I chose it because I'm quite familiar with Ubuntu since I use it on the desktop, and I hate RHEL.
It's very lightweight. Server installs almost nothing by default, letting you install just what you need. After setting up the club's computer with a mail server, MySQL service, and Lighttpd, the thing was only using 37MB of RAM (nice, considering the box only has 384MB). So, not a lot of cruft there.
It's also, as I said, what I'm familiar with, so maintenance is quite smooth.
They also have easy upgrade paths (although upgrading between versions would be stupid in a production environment). Some of the other enterprise-oriented distros (RHEL, I'm looking at you) don't support upgrades very well.
On the other hand, while people like me might be an excellent target market for their server release, we're also not buying support contracts, so that's a bit of a problem.
Why would Debian's release schedule cause somebody to use a non-LTS release of Ubuntu instead of an LTS release?
Server LTS releases are supported for five years. That's pretty decent. They're also predictable, happening every two years, give or take a few months.
He will now be sent to a series of jails where he will be raped by a series of new friends.
Furthermore, many of the benchmarks show things getting faster in newer releases, not slower. In many benchmarks, 7.04 is a distant last place. So it's not so cut and dry. It seems that if the benchmarks were done correctly (as in, figuring out why memory bandwidth was affected), the opposite of the claimed findings might be found to be true.
Youtube solution: Install flashblock, visit the YouTube page, paste the URL into VLC, which will stream it off the site without loading anything extra.
Bandwidth saving solution: Grab a cheap VPS (you can get pretty darned awesome Xen ones with 256MB RAM and 500GB of bandwidth for $13/mth or less), run a proxy on it. Have that proxy gzip all content that goes through it, and recompress images if you can find software. Alternatively, just run squid, tunnel to it over SSH, and enable SSH compression. That should produce some savings.
Ultimate bandwidth saver for the desperate: Opera Mini on a desktop.
Opera Mini is a J2ME cellphone app that is designed to make browsing fast on slow 2G handsets. It runs all data through Opera's proxy servers, compressing content, recompressing images, and packing everything into one file to reduce roundtrips.
It can actually be made to run on a desktop at arbitrary resolutions (say, 1920x1200) via MicroEmulator. Instructions can be found here:
http://my.opera.com/larskl/blog/2008/03/29/opera-mini-in-1280-1024?cid=4986133
I daresay that it's impossible to reduce bandwidth usage more than the Opera Mini approach short of using a text-only browser through a compressed link.
While Video can benefit from higher resolutions, higher framerates, and higher bitrates, audio advances at a much slower pace, and most people can't tell the difference (or don't care) anyhow.
BluRay isn't doing so hot because, despite the large difference in quality between DVD and BluRay, most people just don't care. Why should audio, with almost imperceptible differences, be any different?
It's got a ram cache and a battery backup for that ram for a reason kiddies.
Yeah, because of the write-hole; that's got nothing to do with the original issue. Such issues are also solved on a software level via atomic writes by the filesystem at substantially less cost.
There was a reason that ZFS/RAID-Z was mentioned; when you have a checksum of every block, you know which bit was flipped because all but one of your checksums match. This limits the damage if you have no parity (RAID-Z with one failed disk, RAID-Z2 with two failed disks, etc.)
The only thing keeping me from using ZFS/RAID-Z is the inability to grow an array by adding more disks (similarly sized or otherwise). You'd think this would be kind of useful, being able to take a 3x1TB RAID-Z array and add another to get a 4x1TB RAID-Z array.