> I still play Descent from time to time. It's just fun and scary and these robots have their personality.
between carpal tunnel and lack of time I don't get a chance to play games much any more. But if I did, this is one of the few I'd still play. Even the circa-1996 version of Descent II was a such a good game (especially with teams) that it's still a lot of fun.
Re:My thoughts exactly: Will IBMers have Dells?
on
Lenovo To Shun Linux
·
· Score: 0
> I know that almost NOBODY uses Linux on their desktops and laptops right now.
really? that's odd - since about 80% of the people in my department run linux on their thinkpads.
maybe what you mean is: NOBODY who uses linux on a desktop bothers with desktop support?
> Maybe its because I put a high value on my family, but I would never take a job that required me to be away > from them with such regularity. You're talking about missing a quarter or more of their lives. No amount of money is worth that.
That's fair - but what about the value to a family of living in a good community? If you have strong attachments to a positive local friend & family network, you're well-interated with the schools, churches, etc...
Then moving to chase a job can be worse than being out of town a few days a week. Especially since you'll likely change jobs again in another few years.
Bottom line - it really is about the family. Working out of town for 5 days a week will probably lose you your family. Working out of town for 2-3 days a week might be doable. Moving from a great and supportive community to a strange one could also lose you your family.
> Postgres isn't threaded so even though it's a dual proc dual core 252, I am still cpu bound. I really > need some sort of lazy index/index chunker that can run in parallel to utilize the multiple processors more > efficently so I can have more than a single index on the table.
Actually, if this is a critical part of your database, you're probably using the wrong product: postgresql is a great product, but this is definitely its weak spot.
For something like this you're far better off with db2 or oracle. My preference is db2 since it lacks a larry ellison and can be far cheaper than oracle. What you'd get with db2 for example is:
- query parallelism: work split across all cpus
- load parallelism: loads split across all cpus
- partitioning: rather than using btree indexes that won't work when you're selecting more than 5-15% of the data, partitioning works linearly when you're selecting 2%, 20%, or 80% of the data.
- query optimization: better query planning means your queries need less tweaking to run the way they should
- fine-grained memory control: to allow you to get the most out of memory, which is very valuable on databases like this. Sort memory, tablespace caches, etc
- automatic summarization: db2 can automatically update summary tables for you
- query rewrite: db2 can automatically rewrite incoming queries to hit summary tables when it makes sense
DB2 Express is free for small systems. I think the limit is 2 cpus & 4 gbytes of memory, with no limit on data size. Beyond those limits you can get workstation edition which is (going from memory here) $1500/CPU list price plus $250/named user. If you want it on the net then it's $7500/CPU for unlimited users. That's list, and you can probably get 50% off.
The only disadvantage with db2 in this configuration is that you'd want to use MDC for partitioning, which is slower to load than a regular table. You'd probably hit just 25-35k rows/sec with mdc. Right now DB2 viper is in beta, that allow you to use MDC, range partitioning, or hash partitioning. All in combination. This means that if you really wanted to scale up you could spread the data across a dozen two-way boxes with each one partitioning its local data. This isn't cheap to do (licensing db2 this way is expensive), but if you wanted to get adhoc queries against a 100 million row table returning results in 1-4 seconds - this is the way to do it.;-)
Oracle is similar, just 2x as expensive, more knobs to twiddle, better skills & third-party availability, and highly unpleasant sales staff to deal with.
Of course, Netezza might also hit the spot using postgresql. It wouldn't have all the benefits of db2 or oracle, but has some. And not sure if they have a lot cost entry-level product either.
> Your mythical man month theory may apply to certain advanced software dev. But business logic is pretty > damn easy and there are qualified workers outside the US who can do it.
Argument #1: some stuff is easily done well offshore
But, I'd have to disagree for a few reasons:
1. business logic might be easy, but it's often encapsulated within systems that might not be. So, you can't generally just move business logic offshore without moving the entire application dev/support structure offshore with it.
2. by hiring the best & brightest you find that they discover innovative ways to eliminate the grunt work.
3. if you're using an agile method (back to best & brightest) then your developers are working very closely with the business. Moving that team offshore will push you towards less frequent releases due to communication difficulties. Moving to outsourcing will push you towards waterfall methods due to the way most contracts are written. Both of these side-effects are bad. Note that this isn't an Anti-Indian/Chinese argument, I'd recommend Indians & Chinese to locally support their own business using agile methods as well.
> So, if you want to force everything to buy onshore products, be prepared for a reduction in quality of > life and reduced access to modern technologies.
Argument #2: offshore stuff is cheaper
Sure, but who cares that you can get Chinese manufactured goods at Wallmart for 10% less than others sell them for - when you don't have a job?
And much that is cheaper is cheaper because it was completely pirated. If the manufacturer was an American company they would be sued for patent infringements, copy rights, trade-mark infringements, etc. So, the Chinese manufacturer has leveraged western IP - without having to pay the R&D costs. No idea exactly how often this happens, but it is easy to find examples of older western-made equipment that now has an *identical* Chinese alternative.
> Well i doubt logic matters when hate is involved.
Argument #3: there must be some deep-seated emotional issues behind your resistance to off-shoring
No, I'm not talking about "stealing jobs from mericans". I'm talking about the best way to run a successful project and most economical way to support a staff: hire the best and brightest, recognize them well, treat them like princes and use an iterative methodology. Nothing hatred-oriented there.
Now, there are a few other arguments I've heard for offshoring:
Argument #4: they work when you sleep, you work when they sleep! Twice the productivity!
Yay, except it really seldom works that way. It's typically the opposite - they ask for clarification when you're asleep, you respond when they're asleep. Then they send a second email asking for further clarification when you're sleep and you respond when they're asleep. Eventually, over a few days things are sorted out. But that "few days" could have been "few minutes" if they were down the hallway.
Argument #5: but it's good for everyone to westernize China
Sure, but can we do it without wrecking the economies of the west? Will it really be better for the West to move all of their best jobs to China? The economists disagree on how long it'll take before the playing fields are balanced. In the meanwhile we're seeing one of the biggest migrations of technology and skills the world has ever seen. Hopefully it'll end up good in the end, but we're rolling dice right now.
> I work for a very large international company that does network monitoring for large enterprise clients. > We monitor from Toronto, Boulder, Rochester and Bangalore. The support we get from the group in India > is no worse that the support that is delivered from North America.
I've seen the same - when the company in the US insists on hiring only low-dollar employees. Then the work out of the US is pretty much the same as what you'd get from India. Simply because highly experienced (> 5-10 years) Indian technologies are so rare.
Of course, a company *could* just follow the wisdom from the Mythical Man Month (published when? 1966?) in which the author (project manager for OS development on first mainframe) stated that there was a 7:1 difference in productivity between best & mediocre developers. Since then Gates stated he thought more sophisticated technology has increased the ratio to 100:1.
But lets assume the more conservative number of 7:1:
- so for about 50% additional cost (higher salary), you can get 600% additional productivity
- so the work being done by a team of 100 mediocre system & network admins could probably be perform by 15 really sharp engineers (~80% savings)
- so the cost savings of just moving to available sharp engineers in the US would exceed the cost savings of shipping work to India (which is now often calculated at merely 25-50% savings best case)
But that would require insightful management - capable of learning from well established lessons of 40 years ago. Kind of a hopeless proposition at some companies. And apparently the 7:1 difference in productivity doesn't apply to managment. Aha, that's the ticket - outsource the low-skilled management!
> You want a site that hooks/controls multiple DBs, or want to stray too far from the paradigm? Not so much.
Note that if you're using databases like DB2, Oracle or SQL Server that support database federation, you can easily connect to multiple databases through a single one. Sometimes this is easier than connecting to multiples anyway (for example when writing sql). There are potential performance issues, so you may need to be thoughtful when configurating the databases this way.
No idea if postgresql supports this yet, and I doubt that mysql does.
Note also that a full-featured database allows you more capability to match the RoR paradigms with legacy components: yet another reason for views (yay, mysql now supports them) is that they can allow you to rename tables to match RoR preferences if that is your desire.
> Methinks a better analogy is: Snap your timing chain on a high performance engine and watch the > entire machine tear itself into a piece of junk. Snap a belt or two on a more pedestrian engine and > watch it stop until the belt is replaced.
And just to be a complete nitpicker:
Or just go completely nuts in the opposite direction with timing *gears* and never have to worry about breakage or stretch:-)
and yep, some vehicles came stock with timing gears. I've got two international harvester scouts in my driveway that can attest to this
>> Not to be too fanboyish, but GURPS beats any other tabletop RPG hands down for >> clarity, simplicity, realism, and playability.
> The biggest problem with GURPS is that it tries to be all things to all people (hence the Generic > Universal part). That's what kills it. GURPS is just...boring. It's a clear and fairly straightforward > system, to be sure. But it's just not at all fun. GURPS is what a role playing system would be if it were invented by IBM.
Hmmm, no. The game and supplements are produced quickly by a small team of people. Some of the supplements also show quite a lot of humor and author personality. None of these traits are common in IBM products. I say this as an ibmer that wishes it was otherwise.
Additionally, your comment looks more like a generic boilerplate response to anything with the term "Generic" in it than something specifically aimed at GURPS. I'll grant you that the rules are relatively dry, but then again rules generally are. And the settings are seldom "adventures in a box", instead they typically introduce an entire genre or world to play in. Consider:
- places (Imperial Rome, Greece, Egypt, Vikings, Celtic Myth, Arabian Nights, WWII, Napoleon, Medieval, Old West, etc)
- myth/literature(Voodoo, DiscWorld, Lensman, Witch World, etc)
- complete oddities (Goblins, IOU, Girl Genius - pending, Atomic Horror)
If you're looking for "modules", well GURPS isn't big into those. They do exist, just not on the D&D scale. And while they can be handy when you're in a time crunch, in reality you're usually better off creating your own adventures anyway. So, not much of a loss there.
> OMG - Pink Ponies!. I can't believe you actually state the (indeed "fake") message in a BETA version > of Windows as the reason for DR-Dos being killed. Unfortunatelly for you I am not 9 years old. I > REMEMBER! I also remember how DR-Dos died... At a time when everyone (at least everyone I knew) > was using DR Dos 6, Digital Research was bought by Novell. And they planned DR Dos 7, and > planned... and planned... and didn't really ever release something better...
Hmm, being a user of DR DOS 5, I remember them having compatibility messages in the production not beta windows product. And although they spurred MS to improve on the nasty & buggy PC DOS 4.01 & more primitive MS DOS 3.3 I don't think that MS DOS was ever as good as DR DOS 5. DR sold its dos for something like $60 when MS DOS was going for over $100. So, then MS developed MS DOS 5.0 (very sub-par compared to DR DOS 5.0), dropped the price to $19 and meanwhile had the compatibility warnings. DR got to 6.0 reasonably soon, but I never did see (or care by that time) for DR DOS 7.
> I want my OS to include a browser.
Oh please no, do not integrate the browser into the os.
> There is OpenOffice. What? It is not viable? Of course it is not! It's a bigger memory hog than > Windows Me itself! Whenever I try to use it I run into problems. Being a professional in the software > engineering business I cannot but admire how such a huge project like MS Office worked out so well. I > get pissed every time Word changes what I type thinking it knows better, but that is a minor complain. > Yes, I do feel obliged to pay the people behind office - it got the monopoly because there was never better competition.
The reason that it's so difficult to find a good alternative today is because MS has killed off the alternatives: Excel is a good spreadsheet, but Lotus 1-2-3 is good enough for almost everyone. Word is a disaster for large documents and not noticably better than wordperfect or ami pro (depending on your exact needs). Etc. Of course it's a lot of work for OpenOffice to compete - they've got to build from scratch without almost no revenue, while MS gets a ton of revenue from these products that can then go into completely different product lines. Meanwhile, in spite of pulling in probably billions a year in revenue from the Office product line they've shown no significant improvements in eight years. What crap.
Why should I pay $200 to license a product that hasn't gotten an upgrade in eight years? Thanks anyway, but openoffice is good enough. I'm using it in the office, the kids have it on their pcs, my wife and i use it at home. And I'm not using pirated software or blowing $1000+ on antiquated MS stuff. Now the thing to do is to send a fraction of that figure to the OpenOffice folks. Hmm, need to remember to do that...
> And start a topic about Time Warner, because > I still get interruptions in my service after months of delibarations;)
Not sure about that, the telecoms are so incredibly incompetent that it makes for too easy of a target.
> If you want to push this argument, I have to tell you that Google is very close to being a monopoly, > and that is exactly how they got Firefox to default to them.
Not only are there completely viable options to Google - Google has never been convicting of abusing a monopoly. Note that later point, many people don't mind a monopoly as long as it doesn't abuse it (see Microsoft).
> And as a personal rant I have to say that as a consumer I have never felt hurt by MS's monopoly
Great, neither has my nine-year-old son, so what? He isn't aware either of how - Microsoft killed DR Dos (a *far* better dos) by creating fake incompatibility messages - Microsoft killed OS2 (a *far* better OS) by ensuring incompatibility between its applications and OS2 ones - Microsoft killed Netscape by giving their browser away for free. Once they had the market share they allowed it to stagnate. - etc, etc, etc
No, my nine-year-old isn't aware of how he's been harmed by Microsoft's abuse of its monopoly. But there are plenty of people who are. These are people who've had to pay for expensive license fees for MS Office in order to have a compatible tool, who've spent a ton of money fighting viruses in the MS world, etc.
> I have been hurt by telco monopoly numerous times. Maybe some articles devoted to the woes that our > dependance on companies like Time Warner Cable on monopoly markets would be a refreshing change to > all the MS bashing on slashdot.
I think there's room to honestly evaluate and consider both actually.
Ugh, you're unfortunately wrong on just about every account:
> a) is faster than Oracle
The only situation that mysql can beat oracle in is probably highly-indexed read-mostly content management use with its caching front-end. In reporting read-only environments mysql's lack of parallelism & partitioning means that Oracle can easily be *40x* the speed of mysql.
> b) supports all the features of Oracle
Don't even know where to start on this one. MySQL doesn't even support all the features of Postgresql yet, let alone Oracle. Of course, that's ok - nobody says that it needs to support all of the features. But it doesn't, and that means that there are plenty of uses for oracle that won't work well for MySQL. For example: financial auditing regulations and increasing government security requirements are driving quite a bit of features in oracle. It has extensive capabilities here that are completely missing in mysql. That are required for many applications in these industries.
> can be clustered easier than Oracle
wait, you mean to compare the mysql cluster that requires all data to fit into memory with Oracle RAC? Well, sure - Oracle's cluster set up is more complex. Then again it solves general real-world problems of uptime with zero data loss. The MySQL solution is only useful for a small niche of databases (tiny data volumes that can afford to lose data).
> it does not cost $200,000 per copy
yeah, neither does Oracle. Which can be free for small databases, can cost a few thousand for something a little bigger, can cost what? $32-40k list / CPU at the high-side. And probably $60k/CPU if you want some additional features. Sure that's a ton of cash, but that's list - with frequent 50% discounts and isn't $200,000 / copy.
> If anything, MySQL is largely responsible for this
No, i think jboss is responsible for this. It will compete directly with oracle application servers.
> Their market share is fading away.
Yeah, eventually. Eventually, Postgresql/MySQL/etc will be fast enough, have enough features, secure enough, etc. By that time Postgresql will still be free, who know's what the mysql licensing will look like. Or what storage engine they'll be migrating users to, or if oracle will own them.
> The RAM only bit will go away once MySQL 5.1 is released. It's currently in early beta. It doesn't > mean you lose your data if there's a power failure; the data is backed up to disk regularly.
Seems backwards, but this is probably because mysql bought a product and has had to figure out how to bolt persistence onto it. A much simpler approach is to go the direction of most commercial databases: provide fine-tuned memory controls that easily ensure that the most-used data is kept in memory.
In this scenario (with a database like db2 or oracle) you simply organize tables into tablespaces, dedicate however much memory you want to each tablespace. If you want a table to live in memory - just give it enough memory and it will. If a different table is 100 GB in size, then give it as much memory as you want and the database will manage the memory cache accordingly.
With a solution like the above you don't need completely separate products, but instead see clustering, in-memory databases, and reliable persistence as all just different aspects of a robust and mature database.
The Oracle server works on a variety of linux distros already (plus unix, plus windows, etc). Why they would want to own their own distro is beyond me, but if they did - the worst possible one would be one focused upon desktops.
Seriously, you don't normally want to put open office, mp3 players and tux racer on a database server. You want support & tuning for raid adapters, multiple cpus, etc. And what of the ubuntu community? They *barely* support server installations & questions. Go ahead, just try to find information about print server *without* gnome/kde/etc. Like this community is going to embrace changing its entire philosophy to support oracle.
Of course, there's nothing stopping Oracle from putting their admin client (OEM) onto Ubuntu. That's a perfect fit for a desktop distro. Of course, maybe they do already, I know db2's clients already run on ubuntu. But why bother purchasing it for that?
> What would be the list of priorities for you for features/changes to be made to MySQL in order for > you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers > so delivering on all of them overnight would not happen.
Now that MySQL has implemented most of the standard database features, the next step is to harden them and the rest of the codebase. At this point I'm not interested so much in features as I am high-quality & robust implementations.
- this means that if I add a column to a table I won't have to spend hours copying the data back & forth under the covers
- it means no more gotchas - with broken date handling, exception handling, type conversions, value truncations, etc.
- it means that individuals clients shouldn't be able to turn off strict mode.
- it means that non-strict mode should be deprecated - and gone in a few years
- it means that the optimizer should be able to handle very complex joins and almost always come back with the very best possible query
Now, *after* the above have been addressed there are some additional features to add. These are mostly oriented towards reporting functionality, where I think mysql is pretty weak right now. My list would include:
- oracle-style range partitioning: this means that you can using mysql for large reporting & warehousing applications. We're not talking union-all-views here, but the ability to attach & detach partitions, and disregard partitions of data from queries. I often see 10x performance gains from partitioning over indexing in this kind of app.
- query parallelism: need to be able to split reporting query work across CPUs. These large queries, often scanning a 100,000+ rows can typically get linear performance improvements in my experience from query parallelism.
- automatic query rewrite: need to be able to automatically rewrite queries in order to hit summary tables if they exist. This is critical for some types of powerful reporting tools, or reporting performance boosts for commercial apps.
- materialized views: simple method to manage summary tables. Not critical since this can be developed in other ways, but this has become the preferred way to manage summary tables.
- federation: the ability to redirect a query against a table to another database to be resolved. This allows you to define reference tables on one database, then share them across many.
- query failover: the ability for the mysql client to automatically reroute a query to a failover server. This allows you to provide failover without any code changes at the application layer.
that's all i've got time to write, but should cover most of what I'd look for first.
> Isn't it better to have a choice of technologies?
uh, better than what? If the answer is stability, then no.
So, MySQL has the following storage plug-ins: MyISAM, Innodb, Sleepycat, etc, etc, etc. as an enterprise data architect (ok, sounds pompous, how about someone that implements a *lot* of database solutions) I really don't care about a wide variety of storage engines that mostly don't meet my needs. Of all of the above, only Innodb is a good general-purpose solution. The others are useful only in specialized circumstances or are obsolete.
The idea that multiple storage engines is a great idea is just market spin.
Oracle, DB2, Informix, Sybase, SQL Server, Teradata, Postgresql, Firebird, etc - all have their own. There is no risk to the user that another company is going to buy out their storage engine, force the database vendor to perform an expensive switch and possibly impact functionality or licensing for my applications.
If MySQL wants to support multiple storage engines that's fine. Not terribly attractive to me, but fine. But first - it needs to own its own. And its own needs to support ACID as well as non-logged activity. This shouldn't be news to anyone: this is what every single commercial database provides and has been the way to do it for 20+ years. It's still the way to do it.
> Freedom of choice is always a good thing. > MySQL is not about having cheap database... MySQL is about Freedom of choice.
How about cheap, full-featured, standards compliant & stable RDBMS? Why isn't this a possibility? This is what I want, not freedom to pick from a pack of obsolete, special-purpose or dead-end storage options.
> Replication is important to oracle users and that's one area where mysql is a bigger threat then > postgres. Clustering is another by the way.
No, replication isn't that big of a deal to most enterprise databases. About the only people who really think it's important seem to be MySQL content-management users that want failover. That's fine, but enterprise data management is more likely to focus on hot or cold standby solutions for failover, or ETL for copying to a reporting database.
As a side-note, I'm currently yanking a bunch of replication out of a db2 architecture that some fool put in. It makes life much more complicated when you've got multiple replication interfaces all over the place. It'll be replaced by Federation - which simply redirects queries against original database, instead of copies data.
And clustering? Although a very small number of Oracle users are using their product for clustering at least there they can handle more than a few gbytes of data. The solution that MySQL purchased a few years ago is limited to the amount of data that will fit into memory. This is pretty much a useless feature for most enterprise projects. Obviously any that have tens of gbytes of data or any that get frequent writes.
The one thing that MySQL has over Postgresql is third-party support: due to its huge lead over postgresql 4+ years ago most developers based their apps on it. So, now it's ubiquitous. That's a genuine advantage. No real technical advantages that I can imagine however.
So, what happens if after spending a bunch of time working the kinks out of a Solid io plug-in Oracle buys them? Oracle is quickly robbing mysql of storage options, and is positioned to do this indefinitely.
Looks to me that mysql only has two options: 1. do what *every* other database vendor does - and build their own backend 2. use postgresql as a storage plug-in
Of the above option #1 is obviously the most attractive in the long-term, but option #2 has quite a few benefits:
* faster to implement than option #1
* postgresql can't be bought by Oracle
* immediately benefit from the most mature open source database technology
* stop any drain of mysql users to postgresql
I have no idea how the licensing would work, but would love to see postgresql & mysql have a positive relationship in which they could each benefit from each other's technology, market, etc.
> All normal database admin can be done with various programs that access the server remotely (by which > I don't mean ssh!). Abnormal admin that requires actually logging into the server pretty well always > requires root. The same goes for everything else.
> There's just no need to be on your server unless you are root.
Hmmm, i've got to disagree. What database product are you thinking of?
I'm using db2 to manage a large data warehouse & set of reporting databases. DB2 is notorious for requiring root, but even here:
- root is required to install or uninstall db2 or its fixpacks
- root is required to run a few odd utilities
and that's it. Server admin can be run remotely by db2 java clients, but most suck as much as Oracle's OEM, etc. This is usually used by junior dbas with no unix skills. Limited server admin can also be performed remotely over command line. Limited.
So, most server actions are then performed locally by a dba without root or sudo:
- start server
- stop server
- backup database
- load table
- check tablespace container allocations
- add/remote containers (files, devices, file systems) from tablespaces
- check memory utilization
- check process utilization
I've seen a few organizations that refused to allow dbas to login to their database servers. On closer inspection I discovered that all databases that the organization supported were trivial: less than a 1 gbyte of content-management stuff, or 50 mbytes of transactional data. Needless to say I didn't move multiple terabytes of reporting data into their environment - to be at the whim of their untested theories on what a dba needs to do.
> The devil is in the details, and that 1% you so blithely dismiss can chomp down quite firmly on your backside > when you least expect it.
Sure, if you're using partitioning then there will be some major differences. Of course, most os/390 db2 databases in my experience don't. The other major difference is that new features are released much earlier on LUW than on OS/390 - so if you coded for MDC, MQT, etc on DB2 you may have to wait to get it on 0S/390. And of course, given the nature of how upgrades happen on a mainframe - even once it's available it may be another 1-2 years before you see the mainframe db2 version get updated to support it.
> You can migrate an Oracle database from z/OS to z/Linux with import/export. You cannot migrate a DB2 > database from z/OS to z/Linux without possibly having to redesign and reimplement various schema objects.
Right, if you're the one guy in the world running oracle on a mainframe then the migration easy. If you're one of thousands running db2 on a mainframe then it is usually easy assuming that you're not using partitioning or building database management software that works at a low-level of the database. If you are running a major data warehouse on the mainframe or are a tools developer like BMC or Quest then yeah, you'll have a lot of work to do.
Saying that DB2 has three lines of code:
- unix/linux/windows
- mainframe
- as/400
while oracle only has one for:
- unix/linux/windows
is a nonsensical comparison: Oracle doens't have any product on the as/400, and their product for the os/390 (mainframe) is practically non-existent. A more reasonable statement is:
"db2 and oracle each have just one codebase for the common distributed platforms" db2 has a slightly different codebase for platforms that oracle doesn't support anyway.
Next point: migration of db2 code from mainframe to/from linux/unix/windows isn't necessarily a big deal. Sure, the file systems are different, memory model is a little different, and partitioning is different. However, some of those differences are unavoidable - the mainframe simply works differently than linux or windows (doesn't have concept of directories & files, etc). And 99% of all features and skills are the same.
My team just picked up a db2 dba who's work is primarily on the mainframe. We're not at all concerned that she doesn't have aix or linux experience - the small differences are quick to learn. Of course, she is going to have to learn linux & aix in order to run jobs, view logs, etc, etc but that's not a database issue.
> Ya, MySQL was missing more of the "core" features, but for us, replication and large database > buffers was more important two years ago than stored procedures, triggers or views.
But core comes first:
- views have been around since about 1983 or earlier in DB2 and probably earlier than that in Oracle
- triggers, stored procs, etc have been around for 10-15 years in most commercial products This is all stuff that commercial products have had for decades, postgresql has had in place for years. MySQl has a *.0 release supporting it. It's essential for portability, managability and flexibility.
As for the other stuff:
- data partitioning - we're still not talking anything like DB2, Oracle, Informix. This is union-all views or merely spreading data across containers. This is where the commercial products were in 1992.
- clusters - mysql didn't beat postgresql to clusters, it bought a completely separate product that supports it. In memory only. Not even remotely useful to 99% of the people out there, not even remotely comparable to Oracle RAC.
- 64-bit support - ok, that's a good thing.
- replication - typically a nasty work-around to performance or failover. In most large database architectures it's the first thing I rip out to replace with better solutions. There are situations in which you can get forced to use it, but that's the only time I'd use it.
> I can remember a time when I wished my computer was faster, 10 years ago... no more, and I do more with my machine that most people.
Here's three arguments:
First off, I working on a 1ghz laptop right now that isn't nearly fast enough for me: for my job I run a vpn, lotus notes, have twenty sametime message clients running, quite a few firefox browsers open, thunderbird, excel, word, acrobat, a db2 client, open office, firewall, anti-virus, etc. I'm not using everyone simultaneously, but like to keep leave things open that i'm generally working on. While the biggest hit is to memory (1gbyte apparently isn't enough), these apps also suck up a lot of cpu just sitting there. And that precludes any attempt to stream internet radio, rip a cd, run an anti-virus disk scan, etc. Faster and more CPUs would definitely help here.
Now, my kids are working on 500 mhz PIII workstations (running ubuntu with 500 mbytes of memory) that work just fine for browsing the web, running open office, etc. Newer games are way too slow for them, but I can live with that. NetHack works fine:-)
Secondly, as hardware becomes faster software designers will continually adjust the trade-off between program efficiency and labor to create & maintain it. That means
- more code written in python and ruby (interpreted) and less in c
- applications will simply muscle their way through problems rather than efficiently solve them
- it means the use of inefficient but easy algorithms
- it means more powerful applications that you wouldn't have considered using years ago
The only thing that will check the above is the growth of browser-based apps. But even there I'm sure that we'll continue to leverage the client-side cpus. And who knows? Maybe even more than a typical client app would.
Third, with more general-purpose CPUs I would guess that we would see hardware manufacturers more interested in using these to power peripherals: graphics, sound, etc.
> Nothing is wrong with it. It has always been the case - a minority of the population have a certain look that everyone drools over, and others in the > population want to degrade that because they do not have it.
What? bulimia, silicon injections and air-brushing?
> Reason number 6 is the damnned Postgres zealots that feel the need to bash everyone else's > database rather than promote their own.
Hmmm, I don't see that.
I've extensively used db2, oracle, sybase, informix, sql server and used mysql and postgresql as well. Now, I've got opinions about all:
- oracle: too expensive, crazy ceo, dirty business practices, but sometimes slick
- db2: fringe tools are clunky, but very fast & reliable
- sybase: evil company
- informix: best database ever developed
- sql server: too gui-driven, too windows-dependent
- postgresql: in position to take "best database" away from informix - eventually
- mysql: tricky licensing, company told people that transactions were *not* important, data integrity problems, least portable sql
And I get the same feeling from most other people. In other words, I don't see much in the way of pro-postgresql zealotry. But I do see experienced users of *every* other database who are extremely uncomfortable with the short-cuts taken by MySQL AB with their product.
These people have legitimate criticisms of MySQL. And while MySQL is definitely getting better (well except for the whole oracle monster owning their most critical components), it still has a long way to go. And just like Oracle & Sybase, MySQL AB is a company who's proven that they aren't very trustworthy (see their comments on transactions). So, until they've got a solid track-record with a highly ansi-compliant product few experienced data heads are going to trust them much.
Slashdot Mirror
> I still play Descent from time to time. It's just fun and scary and these robots have their personality.
between carpal tunnel and lack of time I don't get a chance to play games much any more. But if I did, this is one of the few I'd still play. Even the circa-1996 version of Descent II was a such a good game (especially with teams) that it's still a lot of fun.
> I know that almost NOBODY uses Linux on their desktops and laptops right now.
really? that's odd - since about 80% of the people in my department run linux on their thinkpads.
maybe what you mean is: NOBODY who uses linux on a desktop bothers with desktop support?
> Maybe its because I put a high value on my family, but I would never take a job that required me to be away
> from them with such regularity. You're talking about missing a quarter or more of their lives. No amount of money is worth that.
That's fair - but what about the value to a family of living in a good community? If you have strong attachments to a positive local friend & family network, you're well-interated with the schools, churches, etc...
Then moving to chase a job can be worse than being out of town a few days a week. Especially since you'll likely change jobs again in another few years.
Bottom line - it really is about the family. Working out of town for 5 days a week will probably lose you your family. Working out of town for 2-3 days a week might be doable. Moving from a great and supportive community to a strange one could also lose you your family.
> Postgres isn't threaded so even though it's a dual proc dual core 252, I am still cpu bound. I really
;-)
> need some sort of lazy index/index chunker that can run in parallel to utilize the multiple processors more
> efficently so I can have more than a single index on the table.
Actually, if this is a critical part of your database, you're probably using the wrong product: postgresql is a great product, but this is definitely its weak spot.
For something like this you're far better off with db2 or oracle. My preference is db2 since it lacks a larry ellison and can be far cheaper than oracle. What you'd get with db2 for example is:
- query parallelism: work split across all cpus
- load parallelism: loads split across all cpus
- partitioning: rather than using btree indexes that won't work when you're selecting more than 5-15% of the data, partitioning works linearly when you're selecting 2%, 20%, or 80% of the data.
- query optimization: better query planning means your queries need less tweaking to run the way they should
- fine-grained memory control: to allow you to get the most out of memory, which is very valuable on databases like this. Sort memory, tablespace caches, etc
- automatic summarization: db2 can automatically update summary tables for you
- query rewrite: db2 can automatically rewrite incoming queries to hit summary tables when it makes sense
DB2 Express is free for small systems. I think the limit is 2 cpus & 4 gbytes of memory, with no limit on data size. Beyond those limits you can get workstation edition which is (going from memory here) $1500/CPU list price plus $250/named user. If you want it on the net then it's $7500/CPU for unlimited users. That's list, and you can probably get 50% off.
The only disadvantage with db2 in this configuration is that you'd want to use MDC for partitioning, which is slower to load than a regular table. You'd probably hit just 25-35k rows/sec with mdc. Right now DB2 viper is in beta, that allow you to use MDC, range partitioning, or hash partitioning. All in combination. This means that if you really wanted to scale up you could spread the data across a dozen two-way boxes with each one partitioning its local data. This isn't cheap to do (licensing db2 this way is expensive), but if you wanted to get adhoc queries against a 100 million row table returning results in 1-4 seconds - this is the way to do it.
Oracle is similar, just 2x as expensive, more knobs to twiddle, better skills & third-party availability, and highly unpleasant sales staff to deal with.
Of course, Netezza might also hit the spot using postgresql. It wouldn't have all the benefits of db2 or oracle, but has some. And not sure if they have a lot cost entry-level product either.
> Your mythical man month theory may apply to certain advanced software dev. But business logic is pretty
> damn easy and there are qualified workers outside the US who can do it.
Argument #1: some stuff is easily done well offshore
But, I'd have to disagree for a few reasons:
1. business logic might be easy, but it's often encapsulated within systems that might not be. So, you can't generally just move business logic offshore without moving the entire application dev/support structure offshore with it.
2. by hiring the best & brightest you find that they discover innovative ways to eliminate the grunt work.
3. if you're using an agile method (back to best & brightest) then your developers are working very closely with the business. Moving that team offshore will push you towards less frequent releases due to communication difficulties. Moving to outsourcing will push you towards waterfall methods due to the way most contracts are written. Both of these side-effects are bad. Note that this isn't an Anti-Indian/Chinese argument, I'd recommend Indians & Chinese to locally support their own business using agile methods as well.
> So, if you want to force everything to buy onshore products, be prepared for a reduction in quality of
> life and reduced access to modern technologies.
Argument #2: offshore stuff is cheaper
Sure, but who cares that you can get Chinese manufactured goods at Wallmart for 10% less than others sell them for - when you don't have a job?
And much that is cheaper is cheaper because it was completely pirated. If the manufacturer was an American company they would be sued for patent infringements, copy rights, trade-mark infringements, etc. So, the Chinese manufacturer has leveraged western IP - without having to pay the R&D costs. No idea exactly how often this happens, but it is easy to find examples of older western-made equipment that now has an *identical* Chinese alternative.
> Well i doubt logic matters when hate is involved.
Argument #3: there must be some deep-seated emotional issues behind your resistance to off-shoring
No, I'm not talking about "stealing jobs from mericans". I'm talking about the best way to run a successful project and most economical way to support a staff: hire the best and brightest, recognize them well, treat them like princes and use an iterative methodology. Nothing hatred-oriented there.
Now, there are a few other arguments I've heard for offshoring:
Argument #4: they work when you sleep, you work when they sleep! Twice the productivity!
Yay, except it really seldom works that way. It's typically the opposite - they ask for clarification when you're asleep, you respond when they're asleep. Then they send a second email asking for further clarification when you're sleep and you respond when they're asleep. Eventually, over a few days things are sorted out. But that "few days" could have been "few minutes" if they were down the hallway.
Argument #5: but it's good for everyone to westernize China
Sure, but can we do it without wrecking the economies of the west? Will it really be better for the West to move all of their best jobs to China? The economists disagree on how long it'll take before the playing fields are balanced. In the meanwhile we're seeing one of the biggest migrations of technology and skills the world has ever seen. Hopefully it'll end up good in the end, but we're rolling dice right now.
> I work for a very large international company that does network monitoring for large enterprise clients.
> We monitor from Toronto, Boulder, Rochester and Bangalore. The support we get from the group in India
> is no worse that the support that is delivered from North America.
I've seen the same - when the company in the US insists on hiring only low-dollar employees. Then the work out of the US is pretty much the same as what you'd get from India. Simply because highly experienced (> 5-10 years) Indian technologies are so rare.
Of course, a company *could* just follow the wisdom from the Mythical Man Month (published when? 1966?) in which the author (project manager for OS development on first mainframe) stated that there was a 7:1 difference in productivity between best & mediocre developers. Since then Gates stated he thought more sophisticated technology has increased the ratio to 100:1.
But lets assume the more conservative number of 7:1:
- so for about 50% additional cost (higher salary), you can get 600% additional productivity
- so the work being done by a team of 100 mediocre system & network admins could probably be perform by 15 really sharp engineers (~80% savings)
- so the cost savings of just moving to available sharp engineers in the US would exceed the cost savings of shipping work to India (which is now often calculated at merely 25-50% savings best case)
But that would require insightful management - capable of learning from well established lessons of 40 years ago. Kind of a hopeless proposition at some companies. And apparently the 7:1 difference in productivity doesn't apply to managment. Aha, that's the ticket - outsource the low-skilled management!
> You want a site that hooks/controls multiple DBs, or want to stray too far from the paradigm? Not so much.
Note that if you're using databases like DB2, Oracle or SQL Server that support database federation, you can easily connect to multiple databases through a single one. Sometimes this is easier than connecting to multiples anyway (for example when writing sql). There are potential performance issues, so you may need to be thoughtful when configurating the databases this way.
No idea if postgresql supports this yet, and I doubt that mysql does.
Note also that a full-featured database allows you more capability to match the RoR paradigms with legacy components: yet another reason for views (yay, mysql now supports them) is that they can allow you to rename tables to match RoR preferences if that is your desire.
> Methinks a better analogy is: Snap your timing chain on a high performance engine and watch the
:-)
> entire machine tear itself into a piece of junk. Snap a belt or two on a more pedestrian engine and
> watch it stop until the belt is replaced.
And just to be a complete nitpicker:
Or just go completely nuts in the opposite direction with timing *gears* and never have to worry about breakage or stretch
and yep, some vehicles came stock with timing gears. I've got two international harvester scouts in my driveway that can attest to this
>> Not to be too fanboyish, but GURPS beats any other tabletop RPG hands down for
>> clarity, simplicity, realism, and playability.
> The biggest problem with GURPS is that it tries to be all things to all people (hence the Generic
> Universal part). That's what kills it. GURPS is just...boring. It's a clear and fairly straightforward
> system, to be sure. But it's just not at all fun. GURPS is what a role playing system would be if it were invented by IBM.
Hmmm, no. The game and supplements are produced quickly by a small team of people. Some of the supplements also show quite a lot of humor and author personality. None of these traits are common in IBM products. I say this as an ibmer that wishes it was otherwise.
Additionally, your comment looks more like a generic boilerplate response to anything with the term "Generic" in it than something specifically aimed at GURPS. I'll grant you that the rules are relatively dry, but then again rules generally are. And the settings are seldom "adventures in a box", instead they typically introduce an entire genre or world to play in. Consider:
- places (Imperial Rome, Greece, Egypt, Vikings, Celtic Myth, Arabian Nights, WWII, Napoleon, Medieval, Old West, etc)
- myth/literature(Voodoo, DiscWorld, Lensman, Witch World, etc)
- complete oddities (Goblins, IOU, Girl Genius - pending, Atomic Horror)
If you're looking for "modules", well GURPS isn't big into those. They do exist, just not on the D&D scale. And while they can be handy when you're in a time crunch, in reality you're usually better off creating your own adventures anyway. So, not much of a loss there.
> OMG - Pink Ponies!. I can't believe you actually state the (indeed "fake") message in a BETA version
;)
> of Windows as the reason for DR-Dos being killed. Unfortunatelly for you I am not 9 years old. I
> REMEMBER! I also remember how DR-Dos died... At a time when everyone (at least everyone I knew)
> was using DR Dos 6, Digital Research was bought by Novell. And they planned DR Dos 7, and
> planned... and planned... and didn't really ever release something better...
Hmm, being a user of DR DOS 5, I remember them having compatibility messages in the production not beta windows product. And although they spurred MS to improve on the nasty & buggy PC DOS 4.01 & more primitive MS DOS 3.3 I don't think that MS DOS was ever as good as DR DOS 5. DR sold its dos for something like $60 when MS DOS was going for over $100. So, then MS developed MS DOS 5.0 (very sub-par compared to DR DOS 5.0), dropped the price to $19 and meanwhile had the compatibility warnings. DR got to 6.0 reasonably soon, but I never did see (or care by that time) for DR DOS 7.
> I want my OS to include a browser.
Oh please no, do not integrate the browser into the os.
> There is OpenOffice. What? It is not viable? Of course it is not! It's a bigger memory hog than
> Windows Me itself! Whenever I try to use it I run into problems. Being a professional in the software
> engineering business I cannot but admire how such a huge project like MS Office worked out so well. I
> get pissed every time Word changes what I type thinking it knows better, but that is a minor complain.
> Yes, I do feel obliged to pay the people behind office - it got the monopoly because there was never better competition.
The reason that it's so difficult to find a good alternative today is because MS has killed off the alternatives: Excel is a good spreadsheet, but Lotus 1-2-3 is good enough for almost everyone. Word is a disaster for large documents and not noticably better than wordperfect or ami pro (depending on your exact needs). Etc. Of course it's a lot of work for OpenOffice to compete - they've got to build from scratch without almost no revenue, while MS gets a ton of revenue from these products that can then go into completely different product lines. Meanwhile, in spite of pulling in probably billions a year in revenue from the Office product line they've shown no significant improvements in eight years. What crap.
Why should I pay $200 to license a product that hasn't gotten an upgrade in eight years? Thanks anyway, but openoffice is good enough. I'm using it in the office, the kids have it on their pcs, my wife and i use it at home. And I'm not using pirated software or blowing $1000+ on antiquated MS stuff. Now the thing to do is to send a fraction of that figure to the OpenOffice folks. Hmm, need to remember to do that...
> And start a topic about Time Warner, because
> I still get interruptions in my service after months of delibarations
Not sure about that, the telecoms are so incredibly incompetent that it makes for too easy of a target.
> If you want to push this argument, I have to tell you that Google is very close to being a monopoly,
> and that is exactly how they got Firefox to default to them.
Not only are there completely viable options to Google - Google has never been convicting of abusing a monopoly. Note that later point, many people don't mind a monopoly as long as it doesn't abuse it (see Microsoft).
> And as a personal rant I have to say that as a consumer I have never felt hurt by MS's monopoly
Great, neither has my nine-year-old son, so what? He isn't aware either of how
- Microsoft killed DR Dos (a *far* better dos) by creating fake incompatibility messages
- Microsoft killed OS2 (a *far* better OS) by ensuring incompatibility between its applications and OS2 ones
- Microsoft killed Netscape by giving their browser away for free. Once they had the market share they allowed it to stagnate.
- etc, etc, etc
No, my nine-year-old isn't aware of how he's been harmed by Microsoft's abuse of its monopoly. But there are plenty of people who are. These are people who've had to pay for expensive license fees for MS Office in order to have a compatible tool, who've spent a ton of money fighting viruses in the MS world, etc.
> I have been hurt by telco monopoly numerous times. Maybe some articles devoted to the woes that our
> dependance on companies like Time Warner Cable on monopoly markets would be a refreshing change to
> all the MS bashing on slashdot.
I think there's room to honestly evaluate and consider both actually.
Ugh, you're unfortunately wrong on just about every account:
> a) is faster than Oracle
The only situation that mysql can beat oracle in is probably highly-indexed read-mostly content management use with its caching front-end. In reporting read-only environments mysql's lack of parallelism & partitioning means that Oracle can easily be *40x* the speed of mysql.
> b) supports all the features of Oracle
Don't even know where to start on this one. MySQL doesn't even support all the features of Postgresql yet, let alone Oracle. Of course, that's ok - nobody says that it needs to support all of the features. But it doesn't, and that means that there are plenty of uses for oracle that won't work well for MySQL. For example: financial auditing regulations and increasing government security requirements are driving quite a bit of features in oracle. It has extensive capabilities here that are completely missing in mysql. That are required for many applications in these industries.
> can be clustered easier than Oracle
wait, you mean to compare the mysql cluster that requires all data to fit into memory with Oracle RAC? Well, sure - Oracle's cluster set up is more complex. Then again it solves general real-world problems of uptime with zero data loss. The MySQL solution is only useful for a small niche of databases (tiny data volumes that can afford to lose data).
> it does not cost $200,000 per copy
yeah, neither does Oracle. Which can be free for small databases, can cost a few thousand for something a little bigger, can cost what? $32-40k list / CPU at the high-side. And probably $60k/CPU if you want some additional features. Sure that's a ton of cash, but that's list - with frequent 50% discounts and isn't $200,000 / copy.
> If anything, MySQL is largely responsible for this
No, i think jboss is responsible for this. It will compete directly with oracle application servers.
> Their market share is fading away.
Yeah, eventually. Eventually, Postgresql/MySQL/etc will be fast enough, have enough features, secure enough, etc. By that time Postgresql will still be free, who know's what the mysql licensing will look like. Or what storage engine they'll be migrating users to, or if oracle will own them.
> The RAM only bit will go away once MySQL 5.1 is released. It's currently in early beta. It doesn't
> mean you lose your data if there's a power failure; the data is backed up to disk regularly.
Seems backwards, but this is probably because mysql bought a product and has had to figure out how to bolt persistence onto it. A much simpler approach is to go the direction of most commercial databases: provide fine-tuned memory controls that easily ensure that the most-used data is kept in memory.
In this scenario (with a database like db2 or oracle) you simply organize tables into tablespaces, dedicate however much memory you want to each tablespace. If you want a table to live in memory - just give it enough memory and it will. If a different table is 100 GB in size, then give it as much memory as you want and the database will manage the memory cache accordingly.
With a solution like the above you don't need completely separate products, but instead see clustering, in-memory databases, and reliable persistence as all just different aspects of a robust and mature database.
Bad idea.
The Oracle server works on a variety of linux distros already (plus unix, plus windows, etc). Why they would want to own their own distro is beyond me, but if they did - the worst possible one would be one focused upon desktops.
Seriously, you don't normally want to put open office, mp3 players and tux racer on a database server. You want support & tuning for raid adapters, multiple cpus, etc. And what of the ubuntu community? They *barely* support server installations & questions. Go ahead, just try to find information about print server *without* gnome/kde/etc. Like this community is going to embrace changing its entire philosophy to support oracle.
Of course, there's nothing stopping Oracle from putting their admin client (OEM) onto Ubuntu. That's a perfect fit for a desktop distro. Of course, maybe they do already, I know db2's clients already run on ubuntu. But why bother purchasing it for that?
Once again, bad idea.
> What would be the list of priorities for you for features/changes to be made to MySQL in order for
> you to seriously concider it. Bear in mind that MySQL does not have an infinite amount of developers
> so delivering on all of them overnight would not happen.
Now that MySQL has implemented most of the standard database features, the next step is to harden them and the rest of the codebase. At this point I'm not interested so much in features as I am high-quality & robust implementations.
- this means that if I add a column to a table I won't have to spend hours copying the data back & forth under the covers
- it means no more gotchas - with broken date handling, exception handling, type conversions, value truncations, etc.
- it means that individuals clients shouldn't be able to turn off strict mode.
- it means that non-strict mode should be deprecated - and gone in a few years
- it means that the optimizer should be able to handle very complex joins and almost always come back with the very best possible query
Now, *after* the above have been addressed there are some additional features to add. These are mostly oriented towards reporting functionality, where I think mysql is pretty weak right now. My list would include:
- oracle-style range partitioning: this means that you can using mysql for large reporting & warehousing applications. We're not talking union-all-views here, but the ability to attach & detach partitions, and disregard partitions of data from queries. I often see 10x performance gains from partitioning over indexing in this kind of app.
- query parallelism: need to be able to split reporting query work across CPUs. These large queries, often scanning a 100,000+ rows can typically get linear performance improvements in my experience from query parallelism.
- automatic query rewrite: need to be able to automatically rewrite queries in order to hit summary tables if they exist. This is critical for some types of powerful reporting tools, or reporting performance boosts for commercial apps.
- materialized views: simple method to manage summary tables. Not critical since this can be developed in other ways, but this has become the preferred way to manage summary tables.
- federation: the ability to redirect a query against a table to another database to be resolved. This allows you to define reference tables on one database, then share them across many.
- query failover: the ability for the mysql client to automatically reroute a query to a failover server. This allows you to provide failover without any code changes at the application layer.
that's all i've got time to write, but should cover most of what I'd look for first.
> Isn't it better to have a choice of technologies?
uh, better than what? If the answer is stability, then no.
So, MySQL has the following storage plug-ins: MyISAM, Innodb, Sleepycat, etc, etc, etc. as an enterprise data architect (ok, sounds pompous, how about someone that implements a *lot* of database solutions) I really don't care about a wide variety of storage engines that mostly don't meet my needs. Of all of the above, only Innodb is a good general-purpose solution. The others are useful only in specialized circumstances or are obsolete.
The idea that multiple storage engines is a great idea is just market spin.
Oracle, DB2, Informix, Sybase, SQL Server, Teradata, Postgresql, Firebird, etc - all have their own. There is no risk to the user that another company is going to buy out their storage engine, force the database vendor to perform an expensive switch and possibly impact functionality or licensing for my applications.
If MySQL wants to support multiple storage engines that's fine. Not terribly attractive to me, but fine. But first - it needs to own its own. And its own needs to support ACID as well as non-logged activity. This shouldn't be news to anyone: this is what every single commercial database provides and has been the way to do it for 20+ years. It's still the way to do it.
> Freedom of choice is always a good thing.
> MySQL is not about having cheap database... MySQL is about Freedom of choice.
How about cheap, full-featured, standards compliant & stable RDBMS? Why isn't this a possibility? This is what I want, not freedom to pick from a pack of obsolete, special-purpose or dead-end storage options.
> Replication is important to oracle users and that's one area where mysql is a bigger threat then
> postgres. Clustering is another by the way.
No, replication isn't that big of a deal to most enterprise databases. About the only people who really think it's important seem to be MySQL content-management users that want failover. That's fine, but enterprise data management is more likely to focus on hot or cold standby solutions for failover, or ETL for copying to a reporting database.
As a side-note, I'm currently yanking a bunch of replication out of a db2 architecture that some fool put in. It makes life much more complicated when you've got multiple replication interfaces all over the place. It'll be replaced by Federation - which simply redirects queries against original database, instead of copies data.
And clustering? Although a very small number of Oracle users are using their product for clustering at least there they can handle more than a few gbytes of data. The solution that MySQL purchased a few years ago is limited to the amount of data that will fit into memory. This is pretty much a useless feature for most enterprise projects. Obviously any that have tens of gbytes of data or any that get frequent writes.
The one thing that MySQL has over Postgresql is third-party support: due to its huge lead over postgresql 4+ years ago most developers based their apps on it. So, now it's ubiquitous. That's a genuine advantage. No real technical advantages that I can imagine however.
So, what happens if after spending a bunch of time working the kinks out of a Solid io plug-in Oracle buys them? Oracle is quickly robbing mysql of storage options, and is positioned to do this indefinitely.
Looks to me that mysql only has two options:
1. do what *every* other database vendor does - and build their own backend
2. use postgresql as a storage plug-in
Of the above option #1 is obviously the most attractive in the long-term, but option #2 has quite a few benefits:
* faster to implement than option #1
* postgresql can't be bought by Oracle
* immediately benefit from the most mature open source database technology
* stop any drain of mysql users to postgresql
I have no idea how the licensing would work, but would love to see postgresql & mysql have a positive relationship in which they could each benefit from each other's technology, market, etc.
> All normal database admin can be done with various programs that access the server remotely (by which
> I don't mean ssh!). Abnormal admin that requires actually logging into the server pretty well always
> requires root. The same goes for everything else.
> There's just no need to be on your server unless you are root.
Hmmm, i've got to disagree. What database product are you thinking of?
I'm using db2 to manage a large data warehouse & set of reporting databases. DB2 is notorious for requiring root, but even here:
- root is required to install or uninstall db2 or its fixpacks
- root is required to run a few odd utilities
and that's it. Server admin can be run remotely by db2 java clients, but most suck as much as Oracle's OEM, etc. This is usually used by junior dbas with no unix skills. Limited server admin can also be performed remotely over command line. Limited.
So, most server actions are then performed locally by a dba without root or sudo:
- start server
- stop server
- backup database
- load table
- check tablespace container allocations
- add/remote containers (files, devices, file systems) from tablespaces
- check memory utilization
- check process utilization
I've seen a few organizations that refused to allow dbas to login to their database servers. On closer inspection I discovered that all databases that the organization supported were trivial: less than a 1 gbyte of content-management stuff, or 50 mbytes of transactional data. Needless to say I didn't move multiple terabytes of reporting data into their environment - to be at the whim of their untested theories on what a dba needs to do.
> The devil is in the details, and that 1% you so blithely dismiss can chomp down quite firmly on your backside
> when you least expect it.
Sure, if you're using partitioning then there will be some major differences. Of course, most os/390 db2 databases in my experience don't. The other major difference is that new features are released much earlier on LUW than on OS/390 - so if you coded for MDC, MQT, etc on DB2 you may have to wait to get it on 0S/390. And of course, given the nature of how upgrades happen on a mainframe - even once it's available it may be another 1-2 years before you see the mainframe db2 version get updated to support it.
> You can migrate an Oracle database from z/OS to z/Linux with import/export. You cannot migrate a DB2
> database from z/OS to z/Linux without possibly having to redesign and reimplement various schema objects.
Right, if you're the one guy in the world running oracle on a mainframe then the migration easy. If you're one of thousands running db2 on a mainframe then it is usually easy assuming that you're not using partitioning or building database management software that works at a low-level of the database. If you are running a major data warehouse on the mainframe or are a tools developer like BMC or Quest then yeah, you'll have a lot of work to do.
Saying that DB2 has three lines of code:
- unix/linux/windows
- mainframe
- as/400
while oracle only has one for:
- unix/linux/windows
is a nonsensical comparison: Oracle doens't have any product on the as/400, and their product for the os/390 (mainframe) is practically non-existent. A more reasonable statement is:
"db2 and oracle each have just one codebase for the common distributed platforms"
db2 has a slightly different codebase for platforms that oracle doesn't support anyway.
Next point: migration of db2 code from mainframe to/from linux/unix/windows isn't necessarily a big deal. Sure, the file systems are different, memory model is a little different, and partitioning is different. However, some of those differences are unavoidable - the mainframe simply works differently than linux or windows (doesn't have concept of directories & files, etc). And 99% of all features and skills are the same.
My team just picked up a db2 dba who's work is primarily on the mainframe. We're not at all concerned that she doesn't have aix or linux experience - the small differences are quick to learn. Of course, she is going to have to learn linux & aix in order to run jobs, view logs, etc, etc but that's not a database issue.
> Ya, MySQL was missing more of the "core" features, but for us, replication and large database
> buffers was more important two years ago than stored procedures, triggers or views.
But core comes first:
- views have been around since about 1983 or earlier in DB2 and probably earlier than that in Oracle
- triggers, stored procs, etc have been around for 10-15 years in most commercial products
This is all stuff that commercial products have had for decades, postgresql has had in place for years. MySQl has a *.0 release supporting it. It's essential for portability, managability and flexibility.
As for the other stuff:
- data partitioning - we're still not talking anything like DB2, Oracle, Informix. This is union-all views or merely spreading data across containers. This is where the commercial products were in 1992.
- clusters - mysql didn't beat postgresql to clusters, it bought a completely separate product that supports it. In memory only. Not even remotely useful to 99% of the people out there, not even remotely comparable to Oracle RAC.
- 64-bit support - ok, that's a good thing.
- replication - typically a nasty work-around to performance or failover. In most large database architectures it's the first thing I rip out to replace with better solutions. There are situations in which you can get forced to use it, but that's the only time I'd use it.
> I can remember a time when I wished my computer was faster, 10 years ago... no more, and I do more with my machine that most people.
:-)
Here's three arguments:
First off, I working on a 1ghz laptop right now that isn't nearly fast enough for me: for my job I run a vpn, lotus notes, have twenty sametime message clients running, quite a few firefox browsers open, thunderbird, excel, word, acrobat, a db2 client, open office, firewall, anti-virus, etc. I'm not using everyone simultaneously, but like to keep leave things open that i'm generally working on. While the biggest hit is to memory (1gbyte apparently isn't enough), these apps also suck up a lot of cpu just sitting there. And that precludes any attempt to stream internet radio, rip a cd, run an anti-virus disk scan, etc. Faster and more CPUs would definitely help here.
Now, my kids are working on 500 mhz PIII workstations (running ubuntu with 500 mbytes of memory) that work just fine for browsing the web, running open office, etc. Newer games are way too slow for them, but I can live with that. NetHack works fine
Secondly, as hardware becomes faster software designers will continually adjust the trade-off between program efficiency and labor to create & maintain it. That means
- more code written in python and ruby (interpreted) and less in c
- applications will simply muscle their way through problems rather than efficiently solve them
- it means the use of inefficient but easy algorithms
- it means more powerful applications that you wouldn't have considered using years ago
The only thing that will check the above is the growth of browser-based apps. But even there I'm sure that we'll continue to leverage the client-side cpus. And who knows? Maybe even more than a typical client app would.
Third, with more general-purpose CPUs I would guess that we would see hardware manufacturers more interested in using these to power peripherals: graphics, sound, etc.
> Nothing is wrong with it. It has always been the case - a minority of the population have a certain look that everyone drools over, and others in the
> population want to degrade that because they do not have it.
What? bulimia, silicon injections and air-brushing?
> Reason number 6 is the damnned Postgres zealots that feel the need to bash everyone else's
> database rather than promote their own.
Hmmm, I don't see that.
I've extensively used db2, oracle, sybase, informix, sql server and used mysql and postgresql as well. Now, I've got opinions about all:
- oracle: too expensive, crazy ceo, dirty business practices, but sometimes slick
- db2: fringe tools are clunky, but very fast & reliable
- sybase: evil company
- informix: best database ever developed
- sql server: too gui-driven, too windows-dependent
- postgresql: in position to take "best database" away from informix - eventually
- mysql: tricky licensing, company told people that transactions were *not* important, data integrity problems, least portable sql
And I get the same feeling from most other people. In other words, I don't see much in the way of pro-postgresql zealotry. But I do see experienced users of *every* other database who are extremely uncomfortable with the short-cuts taken by MySQL AB with their product.
These people have legitimate criticisms of MySQL. And while MySQL is definitely getting better (well except for the whole oracle monster owning their most critical components), it still has a long way to go. And just like Oracle & Sybase, MySQL AB is a company who's proven that they aren't very trustworthy (see their comments on transactions). So, until they've got a solid track-record with a highly ansi-compliant product few experienced data heads are going to trust them much.
But that has nothing to do with Postgresql.