It depends on how you look at it. If the big boys (eg IBM) start charging prices for distros that more accurately reflect the costs of the enhancements they contribute, the support, marketing, and distribution aspects, I don't think it would be a bad thing. It would ensure that the bug companies have a revenue stream that justifies their efforts.
If, on the other hand, the big companies simply continue to rebrand their own distros based on the work of others (a la Corel), and don't contribute to the spirit, energy, and development of Linux, then it is certainly a bad thing. The smaller companies like SuSE, Slackware, Debian, etc. bring more than just code to the table. They contribute to the driving force and energy that has really helped to propel Linux.
I think any large DB project should be treated as an infrastructure project...
When you're dealing with clients who have (relatively) massive data requirements (ie., data requirements that outstrip the smaller DB services such as MySQL that can be hosted on cheap, commodity hardware), you've got to step back and take a second look at the requirements of their business.
Before you start looking at particular DB packages, and their relative merits, you should really start by identifying the business requirements for the database. For example, what are the uptime and recoverability requirements? If your client requires 24x365 uptime, and also wants a hot standby site, you've got to start spec'ing out the system at the hardware and network level.
Identify the infrastructure that will sustain the requirements of your client, and then begin the process of selecting a DB package that works well within the constraints of that environment. When dealing with larger clients, always keep in mind that you are fundamentally delivering a DB infrastructure, not simply a DB.
A couple things you might want to consider:
Availability - does the system have to be redundant? Does it have to support automatic failover between redundant server?
Scalability - does the DB need to grow beyond the constraints of a single server? Can you forsee this data existing on a large array (ala EMC), and do all nodes of the DB complex need simultaneous access at some level?
Middleware - If it's a large DB, possibly being accessed from multiple physical locations, does it look like a queued middleware (ala IBM MQ) is needed, or perhaps appropriate?
Disaster recovery - If the client is a 24x7 shop, or even if they aren't, are you going to have a sufficient window to back this beast up? Are they going to ask you to architect an off-site recovery strategy? If so, does it have to be a "hot" standby site? If so, does your hardware/network infrastructure support dynamic mirroring over a WAN?
Once you've hammered out these kind of questions (and there are lots more..), then you are in a position to start evaluating DB packages that will work well withing the infrastructure you've designed.
As with any project, getting the requirements defined out front is going to save you a lot of time and agony, and is going to save your client a lot of money and aggravation.
That's not a fair comment, that a "high school student or MCSE could do it". If someone is trained primarily, or exclusively, on one OS, what makes you think it would be easy for them to set up a cluster on a foreign OS? That's like asking Linus Torvalds to set up a Win2K cluster; it's just not fair to the respective persons talents.
Clustering is complex, and the design decisions behind implementing one are complex, regardless of architecture or OS issues. When you consider how few people in the world even ever have the proper hardware to implement clustering (and don't preach about cheap PC's and Linux as an easy entrance..shared storage in a clustered environment is hard & expensive to do at home), it becomes totally unnecessary to take potshots at where/how they obtained their training.
But seriously, what's the big deal? Do you really find this so amusing, and sit there snickering to yourself? What if the DNS boxes are actually the rumoured Unix boxes the MS uses? Is it less funny then?
"commodity hardware" is the crap that you buy from computer stores, not what you get in a server from a large vendor like Compaq or HP.
I've seen far more "servers" built using PC-grade parts fail, than I have seen servers (and I admin 280 HP servers) go down due to failed power supplies. The amount of cooling, as well as the quality and size of the power supply components is vastly better in those custom power supplies you disklike so much.
If your server availability is important enough to you to have redundant power supplies, then it should be important enough to get at least a 24-hour service level agreement in place with your hardware vendor (you could also stockpile a few spare parts).
Whatever...
MS runs a lot of their web site on 2000.
Machines that never crash are universally spoonfed. Good power/cooling, competent administrators, strong, enforced management and operations policies, etc.
Without these types of things, any system is going to be (or at least become) unstable
The really interesting aspect of this experiment is that the guy managed to generate electrical power from simple bacteria.
Imagine a machine with a miniaturized, balanced eco-system on board, where the production of algae or some other easily grown form of life provided enery to bacteria or some other life form, which in turn provided waste products that fostered algae growth.
They would be low powered machines (akin, I would think, to sloths), but given the exponential growth of new technology these days, I bet somebody could come up with a fairly efficient machine.
If you can execute arbitrary code, who says it even has to conform to the Linux API? Just code up some assembler that performs sector-level writes to the hard disk, and you could trash the filesystem regardless of whether you are root or not.
First, cross platform compilation isn't the issue. You took benchmark software specifically designed for POSIX compliant systems, and used it to measure performance on a system supporting Win32. The only way you were able to do this was via the Cygwin kludges
Second, library load times are not the issue. Yes, Cygwin does try to map POSIX calls to Win32 API calls, but the translation is far from one to one. If it was, you could have compiled directly against the POSIX subsystem already built into NT based systems (and anybody who's tried knows how futile that it). Don't try and tell me that performance intensive API's such as threading, pipes, etc, are a simple one-to-one translation for the Cygwin layer. They aren't.
Wow, what a realistic and impartial test of Windows 2000...Compiling your benchmark software with the Cygwin libraries adds an additional layer of overhead to the Windows 2000 benchmarks. Next time, why don't you run a Windows based benchmark program under WINE, and see how Linux fares...
That's good, unbiased, and well planned research all right..sheesh!
What's the value of an open source decoder, without a similarly open sourced encoder? I checked the website, and can't find any mention of the encoder and its source code.
This company just wants unpaid help to port their player around in the hopes of gaining market share...
Didn't mean to spread FUD. I visited Lithuania a year ago (I'm from Canada), and loved it. My wife was working there on an internship, and is Lithuanian-Canadian.
My favorite part of the trip? Cepelinai (hope I spelled it correctly)
I think you'll be pretty happy with the V3-2000. I know it doesn't compete with a GeForce2, but I like mine. It was affordable, and it lets me run the games I enjoy at an acceptable framerate, especially Unreal Tournament.
That there are still several aging Chernobyl class reactors still in use.
In Lithuania, for example, the Ignalina plant provides something like 80% of the countries electricity, and is rapidly approaching the end of it's life. The problem is that they can't afford to shut it down, and they can barely afford to keep it running.
We're not out of the woods yet; the Chernobyl legacy will play out for many years to come.
I find it hard to believe that this be all that viable, especially for data. Imagine spinning a CD-ROM at 40x, when it is flexible enough to be curled around things. I sure wouldn't want any high speed flutter (which is already a problem with some of my CD-ROMS), or warping from being curled around things, to mess up the insides of my CDROM drive.
Anybody remember that slashdot article that said caffeine improves memory...maybe sufficient coffee offsets this...I dunno, I can't remember what the article said:)
Slashdot Mirror
Isn't Debian a non-profit organization? That's why I lumped them in.
Regardless, Debian is a major player in the distro scene.
> Is this good or bad for linux?
It depends on how you look at it. If the big boys (eg IBM) start charging prices for distros that more accurately reflect the costs of the enhancements they contribute, the support, marketing, and distribution aspects, I don't think it would be a bad thing. It would ensure that the bug companies have a revenue stream that justifies their efforts.
If, on the other hand, the big companies simply continue to rebrand their own distros based on the work of others (a la Corel), and don't contribute to the spirit, energy, and development of Linux, then it is certainly a bad thing. The smaller companies like SuSE, Slackware, Debian, etc. bring more than just code to the table. They contribute to the driving force and energy that has really helped to propel Linux.
That was really informative. Thanks.
It's cool to see a company take such a low-key "we're OK, you're OK" approach.
Wow..really smart sounding post. When you get past grade 9, send me a resume (btw, that's french for "where the fuck I've worked".
I think any large DB project should be treated as an infrastructure project...
When you're dealing with clients who have (relatively) massive data requirements (ie., data requirements that outstrip the smaller DB services such as MySQL that can be hosted on cheap, commodity hardware), you've got to step back and take a second look at the requirements of their business.
Before you start looking at particular DB packages, and their relative merits, you should really start by identifying the business requirements for the database. For example, what are the uptime and recoverability requirements? If your client requires 24x365 uptime, and also wants a hot standby site, you've got to start spec'ing out the system at the hardware and network level.
Identify the infrastructure that will sustain the requirements of your client, and then begin the process of selecting a DB package that works well within the constraints of that environment. When dealing with larger clients, always keep in mind that you are fundamentally delivering a DB infrastructure, not simply a DB.
A couple things you might want to consider:
Availability - does the system have to be redundant? Does it have to support automatic failover between redundant server?
Scalability - does the DB need to grow beyond the constraints of a single server? Can you forsee this data existing on a large array (ala EMC), and do all nodes of the DB complex need simultaneous access at some level?
Middleware - If it's a large DB, possibly being accessed from multiple physical locations, does it look like a queued middleware (ala IBM MQ) is needed, or perhaps appropriate?
Disaster recovery - If the client is a 24x7 shop, or even if they aren't, are you going to have a sufficient window to back this beast up? Are they going to ask you to architect an off-site recovery strategy? If so, does it have to be a "hot" standby site? If so, does your hardware/network infrastructure support dynamic mirroring over a WAN?
Once you've hammered out these kind of questions (and there are lots more..), then you are in a position to start evaluating DB packages that will work well withing the infrastructure you've designed.
As with any project, getting the requirements defined out front is going to save you a lot of time and agony, and is going to save your client a lot of money and aggravation.
It's about $4.00 Canadian a tin...I actually don't mind the stuff (in the tin, that is)
Seriously, how long until Harmel (or whatever their name is) decides to go after various net companies, suing that the word Spam is a trademark?
Wouldn't it be ironic if the biggest cost of Spam (tm) turned out to be the litigation costs?
That's not a fair comment, that a "high school student or MCSE could do it". If someone is trained primarily, or exclusively, on one OS, what makes you think it would be easy for them to set up a cluster on a foreign OS? That's like asking Linus Torvalds to set up a Win2K cluster; it's just not fair to the respective persons talents.
Clustering is complex, and the design decisions behind implementing one are complex, regardless of architecture or OS issues. When you consider how few people in the world even ever have the proper hardware to implement clustering (and don't preach about cheap PC's and Linux as an easy entrance..shared storage in a clustered environment is hard & expensive to do at home), it becomes totally unnecessary to take potshots at where/how they obtained their training.
#include obvious MS joke here
But seriously, what's the big deal? Do you really find this so amusing, and sit there snickering to yourself? What if the DNS boxes are actually the rumoured Unix boxes the MS uses? Is it less funny then?
I thought so..
"commodity hardware" is the crap that you buy from computer stores, not what you get in a server from a large vendor like Compaq or HP.
I've seen far more "servers" built using PC-grade parts fail, than I have seen servers (and I admin 280 HP servers) go down due to failed power supplies. The amount of cooling, as well as the quality and size of the power supply components is vastly better in those custom power supplies you disklike so much.
If your server availability is important enough to you to have redundant power supplies, then it should be important enough to get at least a 24-hour service level agreement in place with your hardware vendor (you could also stockpile a few spare parts).
Whatever... MS runs a lot of their web site on 2000. Machines that never crash are universally spoonfed. Good power/cooling, competent administrators, strong, enforced management and operations policies, etc. Without these types of things, any system is going to be (or at least become) unstable
Good one! loved this post
The really interesting aspect of this experiment is that the guy managed to generate electrical power from simple bacteria.
Imagine a machine with a miniaturized, balanced eco-system on board, where the production of algae or some other easily grown form of life provided enery to bacteria or some other life form, which in turn provided waste products that fostered algae growth.
They would be low powered machines (akin, I would think, to sloths), but given the exponential growth of new technology these days, I bet somebody could come up with a fairly efficient machine.
They like TMBG so much because they are now paying for banner adds on Slashdot...
If you can execute arbitrary code, who says it even has to conform to the Linux API? Just code up some assembler that performs sector-level writes to the hard disk, and you could trash the filesystem regardless of whether you are root or not.
OS/2 2.0 supported IDE out of the box. It also supported MFM, some SCSI cards, and ESDI. In fact, I remember running it on an MFM based 386.
Come to think of it, I'm pretty sure OS/2 1.3 ran on IDE based systems as well.
BS!
First, cross platform compilation isn't the issue. You took benchmark software specifically designed for POSIX compliant systems, and used it to measure performance on a system supporting Win32. The only way you were able to do this was via the Cygwin kludges
Second, library load times are not the issue. Yes, Cygwin does try to map POSIX calls to Win32 API calls, but the translation is far from one to one. If it was, you could have compiled directly against the POSIX subsystem already built into NT based systems (and anybody who's tried knows how futile that it). Don't try and tell me that performance intensive API's such as threading, pipes, etc, are a simple one-to-one translation for the Cygwin layer. They aren't.
Wow, what a realistic and impartial test of Windows 2000...Compiling your benchmark software with the Cygwin libraries adds an additional layer of overhead to the Windows 2000 benchmarks. Next time, why don't you run a Windows based benchmark program under WINE, and see how Linux fares...
That's good, unbiased, and well planned research all right..sheesh!
What's the value of an open source decoder, without a similarly open sourced encoder? I checked the website, and can't find any mention of the encoder and its source code.
This company just wants unpaid help to port their player around in the hopes of gaining market share...
Didn't mean to spread FUD. I visited Lithuania a year ago (I'm from Canada), and loved it. My wife was working there on an internship, and is Lithuanian-Canadian.
My favorite part of the trip? Cepelinai (hope I spelled it correctly)
I think you'll be pretty happy with the V3-2000. I know it doesn't compete with a GeForce2, but I like mine. It was affordable, and it lets me run the games I enjoy at an acceptable framerate, especially Unreal Tournament.
Enjoy, and don't worry.
That there are still several aging Chernobyl class reactors still in use.
In Lithuania, for example, the Ignalina plant provides something like 80% of the countries electricity, and is rapidly approaching the end of it's life. The problem is that they can't afford to shut it down, and they can barely afford to keep it running.
We're not out of the woods yet; the Chernobyl legacy will play out for many years to come.
Right...four years of development, and no product demonstration..
How does a snap in plastic ring indicate that there won't be problems with flutter on the outer edges of the disk?
Think about it...five times thinner is _really_ thin
I find it hard to believe that this be all that viable, especially for data. Imagine spinning a CD-ROM at 40x, when it is flexible enough to be curled around things. I sure wouldn't want any high speed flutter (which is already a problem with some of my CD-ROMS), or warping from being curled around things, to mess up the insides of my CDROM drive.
Anybody remember that slashdot article that said caffeine improves memory...maybe sufficient coffee offsets this...I dunno, I can't remember what the article said :)