I doubt Ellison has any love loss for MySQL considering A) he is ruthless and B) MySQL and other open source DB's have cost him billions over the years.
Or so he would love for you to believe.
Use of MySQL does not mean that those users would have used Oracle if MySQL (or other) was not available. They could have easily turned to any of a dozen other commercial database products.
- Battery - Common complaint, my books don't run out of battery
My Sony Reader PRS-505 (from 2 years) ago lasts 2-4 weeks on a single charge.
- Space - I can fit a paperback in my pocket.
The Sony Readers are really thin and come in 2 or 3 form factors now. Plus with the e-reader, I can tuck multiple books into my laptop bag instead of maybe one. They're also easier to read one-handed when I have a cat in my lap.
- DRM
Buy from vendors that don't use DRM.
- Physicality
Physical books suck, especially fiction/leisure reading. I'm too much of a packrat (I moved about 2500lbs of books in my last move). With e-books, I can cut down on that, yet still stimulate my mind with reading.
- Obsolesence
Once a book is in a widely understood digital format, I have no worries that I'll be able to read it in 25-50 years. Someone will make a format converter. However, to hedge my bets, when I buy books at Baen, I download it in multiple formats.
The only big disadvantage of e-readers is price. I was happy when the readers first dropped below $300. I also took full advantage of Project Gutenberg and Baen's website to get inexpensive or free books. But if you find the reader cost + book cost to be too expensive... then you're not (yet) the target market.
I've trialed half a dozen open-source database project this year in an attempt to find a replacement for what MSAccess offers. None of them come close for managing small (sometimes large) data sets that almost completely differ between jobs.
My needs are:
- Easy management. I want either one file, or a group of files in the same sub-folder. If I want to checkout a data set from our SVN repository, I should be able to simply double-click the primary file and have it open up. In a server/client model; I would have to setup a new database, load the data, then use some client program to look at it. Which takes a lot more time.
- These are not data sets that need to be permanently online. Their lifespan is often measured in days or maybe weeks, with the data stored for future reference down the road. And that data is rarely accessed. So shoving the data into a file, and tossing that file in SVN makes a lot more sense then maintaining it indefinitely in a DB server.
- The data set does get loaded into a DB server while the data is being generated. So we know when to size up to a real DB. But it's still nice to be able to export to a format that is easily worked with for archives or snapshots of the data set.
- Often there are ad-hoc queries created, which are useful to store alongside the data. We don't want to jump through half a dozen hoops when I need to quickly reference old data.
- MSAccess plays nicely with disparate data sources in a single MDB. ooBase doesn't. I can't link in remote data sources and work with local tables at the same time. Or at least I couldn't when I looked at 3.1.
- Import/Export in ooBase is rudimentary at best. Back in 3.1, the expected path for getting data from a CSV into ooBase? Open up the CSV in Calc, save it out as an ooCalc file, then load it into ooBase. Which is not a solution, it's a dirty hack and a waste of the user's time.
- Ease of copy/paste. With MSAccess, I can copy paste data, or individual cells or a range of cells to/from a spreadsheet. Sometimes it's easier to massage data in a spreadsheet, then copy it back when done.
Bottom line, when you generate a few hundred data sets per year, which are very rarely related, ooBase can't hack it. MSAccess can. It (and the old dBase IV, and Foxpro) works extremely well where you don't need multi-user access and just need a down and dirty way to store data, queries, and maybe reports.
So, have they finally made OOBase useful for things like:
- import/export data to CSV files?
- The ability to query remote DBs and write the data into a local table?
- Done away with the compressed zip format that makes working with a few dozen/hundred MB of data impossible?
(I swear that nobody in the Open Office project truly understands Microsoft Access' strong points and why it is so hard to replace. MSAccess is a great glue program, allowing you to easily move data sets around, deal with ad-hoc databases, quickly look at a table, copy/paste to/from a spreadsheet.)
Every game uses a different engine, which means you pretty much have to write the AI from scratch for every game. Since very few developers want to spend lots of money on a non-visible feature, the AI gets short-changed.
Smarter companies make the AI mod'able. So you end up with Civ IV's "Better AI" project.
(The best FPS AI that I've seen so far is FEAR's. Those enemies are nasty and fairly capable.)
FO3 is *far* better then Oblivion. Yes, you can do the MQ at level 3 and all you'll see are Super Mutants and regular Feral Ghouls.
What happens instead in FO3 is that tougher enemies start appearing at higher levels. They don't take low level bandits and give them uber armors/weapons. The Raiders are typically limited to nasty things like full-auto weapons or maybe a flamer. Which means that past level 10 or so, Raiders are pretty easy to kill, yet still drop loot useful to you.
In addition, FO3 does a good job of basing the level system off of XP instead of nebulous skill activity. And you can assign your skill points as desired when you level up, rather then it being dictated to you based on what you did during the previous level.
- Tanks were immune to sniper fire and could make life hellish for a discovered sniper position. Either with HE rounds from the main gun, or volumes of large caliber rounds from the machine gun.
- Artillery Fire. You could call down artillery fire on a sniper's position.
Both were effective at suppressing the sniper until killed or you could send in infantry to sweep the position. Infantry, who could now get close enough to the sniper's position while the sniper is hunkered down trying to stay alive.
(I really really liked the balance of mixed arms in CoD:UO. Tanks were strong, but also weak at the same time. Infantry could simply hide from the tank, then one-shot kill it using a bazooka/etc from the rear. A tank without infantry support is a big fat target.)
Which is absolutely going to suck in the long-term for a social game like WoW.
People on RP servers are going to say "no thanks" to grouping with the l33t immature idiots from the other servers. Plus the internet fuckwad theory will be in FULL effect here, where you can ninja to your heart's content because you'll never see these players again. "Do not PUG" lists will be useless, because there will be thousands of names on them, instead of only needing to know a few dozen who are on your server.
Then there's the fun that grouping with people from other servers might allow for all sorts of weird cross-server interactions (moving gold, items) or just not being able to hand someone supplies mid-instance when they run out of water/food?
Homogenization of the servers... whee. Let's do away with all the uniqueness that the different servers have.
That's because while encryption is simple, key management is horribly complex.
(And a lot of those standards were developed back when crypto was considered a munition, which causes a lot of pain and roadblocks to easy interoperability.)
Offhand, game support, OS control of wifi rather then unique and often buggy vendor-written software, and a few other thing like better support for laptops.
I used Win2k on my first laptop. XP was much better at it. Games simply worked better in XP then Win2k for me.
The only reason that EVE's model works is because every star system is pretty much like dozens or hundreds of other star systems. (Out of a few thousand star systems.) And asteroid belt 1 is a lot like asteroid belt 9 within a system. There's minimal design work that goes into each star system.
In fantasy MMOs, locations tend to be a lot more varied, unique, and important. There is only one Ironforge in WoW. The closest that EVE has to unique locations are the trade capitals (Jita 4-4 CNAP) or the high quality / high level mission stations.
WoW, would need at least 10x more landmass (if not 100x) in order to support populations equal to what EVE supports on a single "server". There would need to be dozens of starter zones, and at least 10 different versions and locations for each of the Outland / Northrend zones. Instead of one racial capital city, each race would need to be spread across a dozen or two cities and towns, to keep the players spread out.
Hard DRAM errors are rather hard to explain if the cells are good -- maybe a bad write. After much DRAM testing (I use memtest86+ weeklong), I've yet to find bad cells.
Try something like Prime95 in torture test mode for a day or two if you really want to find bad / flaky memory systems. Or memory that can't handle the timings, even though it's supposed to. It pegs the CPU at 100% and uses all available memory. (You'll have to run multiple copies, last I looked, to bog down a multi-core system though.)
And rip Subversion and CVS out because of their continuing practice of storing your account passwords in plain-text.
For public-facing SVN systems where authentication matters, it is best to use svn+ssh authentication which relies on SSH to do the authentication. No storage of passwords in plain text. Plus you can lockdown SSH keys used for SVN so that they can only run the svnserve command. We even use svn+ssh for our internal clients, because it's simple, it works, and it's secure.
(As for other authentication methods using passwords - it's a problem of key handling. There is no good way to store the password, and obscuring it doesn't make it any more secure. There's simply no possible way to secure it that works. Which is the whole reason that public key encryption was invented.)
Just moving the external SSH port to something other then 22 will drop the quantity of brute-force attacks by at least 2 orders of magnitude. Maybe 3.
That's generally enough of an exposure reduction (combined with only allowing public key authentication.)
(Use of port-knocking would be useful if you setup a 2nd SSH instance that does allow password authentication. And you don't have more then 3 users, all of which are willing to put up with port-knocking. SSH public keys are a lot easier to configure and support.)
At this time, XP home is only licensed for single CPU use, for dual or more you have to go with Vista or 7.
XP Pro? I've never used Home, but I've had XP Pro running on a dual-CPU system since back when Socket 940 Opterons were current tech. (So probably '02 or '03.)
One box was an Athlon64 X2 4600+ (2.4GHz), the other is a Opteron 2210 HE (1.8GHz) based system. Both have Intel PRO/1000 NICs. Running CentOS 5.x 64-bit on both systems. Probably both connected to the same 3com gigabit switch (1U rackmount, 24 ports, one of the early baseline business-class models).
I remember double-digit CPU usage in "atop" (10-20%), but don't remember that being the bottleneck. Might have even been eating up most of a CPU core.
It's been a month or two since I did those multi-gigabyte transfers. We were migrating our SVN repositories between boxes. Really though, I'm content with 20 MB/sec or better on gigabit networks.
Our nightly backups are one with rsync or rdiff-backup over SSH. Which are typically disk-bound.
Like the other poster, I've see 30-50 MB/s (300-500 Mbps) over a gigabit network when copying between boxes using scp. The limitations were more the frame size (not using jumbo frames on that network) along with the read/write speeds of the system on each end.
More importantly though, by 2012-2015, we'll have what, petabyte hard drives? We'll just be downloading and/or streaming our HD videos.
Streaming/downloading - yes. With modern codecs (XVid, h264), you can easily fit 720p into 2-3Mbps, and figure 3-5Mbps for 1080p.
HD size... probably not. 2TB 3.5" drives have only just arrived in 2009 and are close to the upper end of where Perpendicular Recording density was supposed to top out at. Although they've pushed the upper-end back a few times in the past 2 years. The original estimate was 250-300 gigabits per square inch, and now the estimate is up to 1 terabit per square inch as the upper limit. Current 2TB drives are using somewhere around 300-400 gigabits per square inch designs.
So 4-6TB 3.5" disks are likely by 2012.
After that, you get into the next tech (HAMR or bit patterned media or both) which is still a few years away and might raise the limit to about 50 terabits per square inch. More likely is maybe 10-20TB 3.5" disks by 2015.
And that ignores what is happening on the flash media front in the 2.5" size. The big units right now are already close to catching up with magnetic media in the 2.5" size. You can buy 256GB SSDs in 2.5" size and magnetic 2.5" drives are just creeping past 500GB (I think there's a 1TB 2.5" drive out now). Prices are still ridiculously high ($600 for 256GB), but are dropping very fast.
Figure 512GB MLC SSDs for $500-ish in 2010, with 1TB and 2TB SSDs by 2012 or so. The equivalent densities for magnetic storage in the 2.5" size will probably only be up around 2-4TB by 2012. So there's a good chance that MLC SSDs will catch up in size, if not in price by then.
Why are they now recreating holographic media as Yet Another Spinning Disc device with parts that wear out quickly, go out of alignment, and put the media at risk of damage?
Cost? Spinning the disk and moving the read/write head in a single axis is probably a lot less expensive then a 2-axis controller setup.
Slashdot Mirror
Because Thunderbird is one of the few good IMAP clients?
(I've looked..)
http://www.itwatchdogs.com/products_mon.shtml
Basically, you're looking at $300-$1000 in hardware, but it can interface with Nagios.
If we ever move our servers to the basement, I'll be setting these up to monitor for flooding or temperature issues.
We called it "brightsizing" at UPS back in the mid-90s.
All your bright employable people head for the exits.
I doubt Ellison has any love loss for MySQL considering A) he is ruthless and B) MySQL and other open source DB's have cost him billions over the years.
Or so he would love for you to believe.
Use of MySQL does not mean that those users would have used Oracle if MySQL (or other) was not available. They could have easily turned to any of a dozen other commercial database products.
- Battery - Common complaint, my books don't run out of battery
My Sony Reader PRS-505 (from 2 years) ago lasts 2-4 weeks on a single charge.
- Space - I can fit a paperback in my pocket.
The Sony Readers are really thin and come in 2 or 3 form factors now. Plus with the e-reader, I can tuck multiple books into my laptop bag instead of maybe one. They're also easier to read one-handed when I have a cat in my lap.
- DRM
Buy from vendors that don't use DRM.
- Physicality
Physical books suck, especially fiction/leisure reading. I'm too much of a packrat (I moved about 2500lbs of books in my last move). With e-books, I can cut down on that, yet still stimulate my mind with reading.
- Obsolesence
Once a book is in a widely understood digital format, I have no worries that I'll be able to read it in 25-50 years. Someone will make a format converter. However, to hedge my bets, when I buy books at Baen, I download it in multiple formats.
The only big disadvantage of e-readers is price. I was happy when the readers first dropped below $300. I also took full advantage of Project Gutenberg and Baen's website to get inexpensive or free books. But if you find the reader cost + book cost to be too expensive... then you're not (yet) the target market.
And, you prove my point.
I've trialed half a dozen open-source database project this year in an attempt to find a replacement for what MSAccess offers. None of them come close for managing small (sometimes large) data sets that almost completely differ between jobs.
My needs are:
- Easy management. I want either one file, or a group of files in the same sub-folder. If I want to checkout a data set from our SVN repository, I should be able to simply double-click the primary file and have it open up. In a server/client model; I would have to setup a new database, load the data, then use some client program to look at it. Which takes a lot more time.
- These are not data sets that need to be permanently online. Their lifespan is often measured in days or maybe weeks, with the data stored for future reference down the road. And that data is rarely accessed. So shoving the data into a file, and tossing that file in SVN makes a lot more sense then maintaining it indefinitely in a DB server.
- The data set does get loaded into a DB server while the data is being generated. So we know when to size up to a real DB. But it's still nice to be able to export to a format that is easily worked with for archives or snapshots of the data set.
- Often there are ad-hoc queries created, which are useful to store alongside the data. We don't want to jump through half a dozen hoops when I need to quickly reference old data.
- MSAccess plays nicely with disparate data sources in a single MDB. ooBase doesn't. I can't link in remote data sources and work with local tables at the same time. Or at least I couldn't when I looked at 3.1.
- Import/Export in ooBase is rudimentary at best. Back in 3.1, the expected path for getting data from a CSV into ooBase? Open up the CSV in Calc, save it out as an ooCalc file, then load it into ooBase. Which is not a solution, it's a dirty hack and a waste of the user's time.
- Ease of copy/paste. With MSAccess, I can copy paste data, or individual cells or a range of cells to/from a spreadsheet. Sometimes it's easier to massage data in a spreadsheet, then copy it back when done.
Bottom line, when you generate a few hundred data sets per year, which are very rarely related, ooBase can't hack it. MSAccess can. It (and the old dBase IV, and Foxpro) works extremely well where you don't need multi-user access and just need a down and dirty way to store data, queries, and maybe reports.
So, have they finally made OOBase useful for things like:
- import/export data to CSV files?
- The ability to query remote DBs and write the data into a local table?
- Done away with the compressed zip format that makes working with a few dozen/hundred MB of data impossible?
(I swear that nobody in the Open Office project truly understands Microsoft Access' strong points and why it is so hard to replace. MSAccess is a great glue program, allowing you to easily move data sets around, deal with ad-hoc databases, quickly look at a table, copy/paste to/from a spreadsheet.)
Engine that hasn't really been invented yet might rhubarb rhubarb rhubarb rhubarb....
Ah, a fellow Goon Show fan?
128Kbps for what codec? AAC, 128Kbps is good. MP3? 128Kbps sucks for cymbals and similar sounds and is much better at 160Kbps or 192Kbps.
The big problem with game AI.
Every game uses a different engine, which means you pretty much have to write the AI from scratch for every game. Since very few developers want to spend lots of money on a non-visible feature, the AI gets short-changed.
Smarter companies make the AI mod'able. So you end up with Civ IV's "Better AI" project.
(The best FPS AI that I've seen so far is FEAR's. Those enemies are nasty and fairly capable.)
FO3 is *far* better then Oblivion. Yes, you can do the MQ at level 3 and all you'll see are Super Mutants and regular Feral Ghouls.
What happens instead in FO3 is that tougher enemies start appearing at higher levels. They don't take low level bandits and give them uber armors/weapons. The Raiders are typically limited to nasty things like full-auto weapons or maybe a flamer. Which means that past level 10 or so, Raiders are pretty easy to kill, yet still drop loot useful to you.
In addition, FO3 does a good job of basing the level system off of XP instead of nebulous skill activity. And you can assign your skill points as desired when you level up, rather then it being dictated to you based on what you did during the previous level.
CoD:UO had a few good counter-sniper additions.
- Tanks were immune to sniper fire and could make life hellish for a discovered sniper position. Either with HE rounds from the main gun, or volumes of large caliber rounds from the machine gun.
- Artillery Fire. You could call down artillery fire on a sniper's position.
Both were effective at suppressing the sniper until killed or you could send in infantry to sweep the position. Infantry, who could now get close enough to the sniper's position while the sniper is hunkered down trying to stay alive.
(I really really liked the balance of mixed arms in CoD:UO. Tanks were strong, but also weak at the same time. Infantry could simply hide from the tank, then one-shot kill it using a bazooka/etc from the rear. A tank without infantry support is a big fat target.)
Which is absolutely going to suck in the long-term for a social game like WoW.
People on RP servers are going to say "no thanks" to grouping with the l33t immature idiots from the other servers. Plus the internet fuckwad theory will be in FULL effect here, where you can ninja to your heart's content because you'll never see these players again. "Do not PUG" lists will be useless, because there will be thousands of names on them, instead of only needing to know a few dozen who are on your server.
Then there's the fun that grouping with people from other servers might allow for all sorts of weird cross-server interactions (moving gold, items) or just not being able to hand someone supplies mid-instance when they run out of water/food?
Homogenization of the servers... whee. Let's do away with all the uniqueness that the different servers have.
SC2 = Star Craft 2 (Real Time Strategy game played in 3rd person god mode.)
That's because while encryption is simple, key management is horribly complex.
(And a lot of those standards were developed back when crypto was considered a munition, which causes a lot of pain and roadblocks to easy interoperability.)
Offhand, game support, OS control of wifi rather then unique and often buggy vendor-written software, and a few other thing like better support for laptops.
I used Win2k on my first laptop. XP was much better at it. Games simply worked better in XP then Win2k for me.
The only reason that EVE's model works is because every star system is pretty much like dozens or hundreds of other star systems. (Out of a few thousand star systems.) And asteroid belt 1 is a lot like asteroid belt 9 within a system. There's minimal design work that goes into each star system.
In fantasy MMOs, locations tend to be a lot more varied, unique, and important. There is only one Ironforge in WoW. The closest that EVE has to unique locations are the trade capitals (Jita 4-4 CNAP) or the high quality / high level mission stations.
WoW, would need at least 10x more landmass (if not 100x) in order to support populations equal to what EVE supports on a single "server". There would need to be dozens of starter zones, and at least 10 different versions and locations for each of the Outland / Northrend zones. Instead of one racial capital city, each race would need to be spread across a dozen or two cities and towns, to keep the players spread out.
Hard DRAM errors are rather hard to explain if the cells are good -- maybe a bad write. After much DRAM testing (I use memtest86+ weeklong), I've yet to find bad cells.
Try something like Prime95 in torture test mode for a day or two if you really want to find bad / flaky memory systems. Or memory that can't handle the timings, even though it's supposed to. It pegs the CPU at 100% and uses all available memory. (You'll have to run multiple copies, last I looked, to bog down a multi-core system though.)
And rip Subversion and CVS out because of their continuing practice of storing your account passwords in plain-text.
For public-facing SVN systems where authentication matters, it is best to use svn+ssh authentication which relies on SSH to do the authentication. No storage of passwords in plain text. Plus you can lockdown SSH keys used for SVN so that they can only run the svnserve command. We even use svn+ssh for our internal clients, because it's simple, it works, and it's secure.
(As for other authentication methods using passwords - it's a problem of key handling. There is no good way to store the password, and obscuring it doesn't make it any more secure. There's simply no possible way to secure it that works. Which is the whole reason that public key encryption was invented.)
Just moving the external SSH port to something other then 22 will drop the quantity of brute-force attacks by at least 2 orders of magnitude. Maybe 3.
That's generally enough of an exposure reduction (combined with only allowing public key authentication.)
(Use of port-knocking would be useful if you setup a 2nd SSH instance that does allow password authentication. And you don't have more then 3 users, all of which are willing to put up with port-knocking. SSH public keys are a lot easier to configure and support.)
At this time, XP home is only licensed for single CPU use, for dual or more you have to go with Vista or 7.
XP Pro? I've never used Home, but I've had XP Pro running on a dual-CPU system since back when Socket 940 Opterons were current tech. (So probably '02 or '03.)
One box was an Athlon64 X2 4600+ (2.4GHz), the other is a Opteron 2210 HE (1.8GHz) based system. Both have Intel PRO/1000 NICs. Running CentOS 5.x 64-bit on both systems. Probably both connected to the same 3com gigabit switch (1U rackmount, 24 ports, one of the early baseline business-class models).
I remember double-digit CPU usage in "atop" (10-20%), but don't remember that being the bottleneck. Might have even been eating up most of a CPU core.
It's been a month or two since I did those multi-gigabyte transfers. We were migrating our SVN repositories between boxes. Really though, I'm content with 20 MB/sec or better on gigabit networks.
Our nightly backups are one with rsync or rdiff-backup over SSH. Which are typically disk-bound.
Like the other poster, I've see 30-50 MB/s (300-500 Mbps) over a gigabit network when copying between boxes using scp. The limitations were more the frame size (not using jumbo frames on that network) along with the read/write speeds of the system on each end.
So, it's no slouch and better then SMB/CIFS.
More importantly though, by 2012-2015, we'll have what, petabyte hard drives? We'll just be downloading and/or streaming our HD videos.
Streaming/downloading - yes. With modern codecs (XVid, h264), you can easily fit 720p into 2-3Mbps, and figure 3-5Mbps for 1080p.
HD size... probably not. 2TB 3.5" drives have only just arrived in 2009 and are close to the upper end of where Perpendicular Recording density was supposed to top out at. Although they've pushed the upper-end back a few times in the past 2 years. The original estimate was 250-300 gigabits per square inch, and now the estimate is up to 1 terabit per square inch as the upper limit. Current 2TB drives are using somewhere around 300-400 gigabits per square inch designs.
So 4-6TB 3.5" disks are likely by 2012.
After that, you get into the next tech (HAMR or bit patterned media or both) which is still a few years away and might raise the limit to about 50 terabits per square inch. More likely is maybe 10-20TB 3.5" disks by 2015.
And that ignores what is happening on the flash media front in the 2.5" size. The big units right now are already close to catching up with magnetic media in the 2.5" size. You can buy 256GB SSDs in 2.5" size and magnetic 2.5" drives are just creeping past 500GB (I think there's a 1TB 2.5" drive out now). Prices are still ridiculously high ($600 for 256GB), but are dropping very fast.
Figure 512GB MLC SSDs for $500-ish in 2010, with 1TB and 2TB SSDs by 2012 or so. The equivalent densities for magnetic storage in the 2.5" size will probably only be up around 2-4TB by 2012. So there's a good chance that MLC SSDs will catch up in size, if not in price by then.
Why are they now recreating holographic media as Yet Another Spinning Disc device with parts that wear out quickly, go out of alignment, and put the media at risk of damage?
Cost? Spinning the disk and moving the read/write head in a single axis is probably a lot less expensive then a 2-axis controller setup.