Don't you read your own links? What part of "InnoDB Hot Backup is a non-free additional tool which is not included in the standard MySQL distribution" is unclear to you?
I honestly missed that one:( Although I haven't researched it much, it does sound like the new stuff coming in 4.0 is really cool though. Also, like I mentioned, replication might be a very good solution...
In reply to the foreign key and constraints discussion, it happens to be built into my schema. The schemas I'm creating now create type/size/regex match/etc contraints that get compiled into the program automagically. Another developer and myself have created an object to relational mapping compiler that will translate our "nifty" schema into an object based wrapper over the database. Anyone using the wrapper can be guarenteed that contraints will be enforced, etc. Also, things like foreign key contraints are handle automatically or subclassed for tricky relationships.
In addition, I hate seeing error messages come back from the db. If I can handle all the errors client side, clean data is the *only* thing that gets submitted. I know it's not the accepted way of doing things, but it works very well.
Does MySQL have support for cell constraints like limiting an integer field to a value between 15 and 90 or making sure that a text field has at least seven characters or matches a valid social security number?
I honestly don't know as I haven't needed or wanted it. See above.
This might lead me to believe that support exists though... FOREIGN KEY is ignored, but I think CHECK included and executed...
or [CONSTRAINT symbol] FOREIGN KEY index_name (index_col_name,...)
[reference_definition]
or CHECK (expr)
Another benefit of what I'm doing allows me to quickly port my apps to other databases. Once the layer for Postgres is created in the compiler, I just recompile on the schema, and boom - I have a object layer for a postgres database based on my cool schema in C++, Python, Java, and PHP (assuming the layers for those languages are present in the compiler). All in all, I should be able to write the backend for a company's point of sale GUI *and* their inventory website in a single schema definition.
Got money for the hotbackups? They cost. ??? I'm not sure if I understand your complaint. Online backup is already available and much improved support is coming in 4.0/4.x. See here and here In addition, replication is not a bad way to build some fault tolerance into your system. I'm not claiming that any of these features are perfect or that they fit your exact needs. I'm merely pointing out that they exist.
How about working FKs? I mean if I can drop an entire table that FKs pointing it, not much intergerity is there? Don't know what to tell you there. I know foreign key support is planned, but I'm handling all my data integrity inside my apps. InnoDB tables are supposed to support foriegn keys, but again, I don't know how complete the support is as I haven't used them...
On a different note, has anyone done a decent set of benchmarks comparing MySQL with transactions to PostgreSQL? That would be nice to see. Yes, but I don't see any that don't look biased towards MySQL...
Interesting... What might you consider slightly complicated SQL? I assume at least one example will address sub selects, so please include something in addition to a sub select complaint. Generally, an intelligent developer can solve a query problem without using a sub select and the end solution tends to be much faster...
Or better yet, pay for hosting on two boxes, but set both boxes to fail in either direction. Then, set the db server up as primary on one box and search/www as primary on the other box. Now if one fails, the other serves as a backup, but most of time both would be handling load...
Yes, thank you:) Either you don't factor the exchange rate in, or you have to run it both ways. Thos Barista's at Starbucks would have to be making $15 an hour here to compare with a $9 an hour job in Canada.
And Qt is soooo much easier to use:) The heavy licensing fee is something I'm willing to pay when do commercial development with a toolkit that makes my task substantially easier.
Article with more details
on
Tiny Boxen
·
· Score: 5, Informative
openbrick.org seems to be getting hit pretty hard, but Linux Max has a pretty detailed article on the Open Brick.. And it's not slashdotted.. yet... http://www.linuxmax.net/news/00816.html
Rapid Development by Steve McConnell ISBN: 1-55615-900-5 Amazon.com link
It's a Microsoft book, but the guy sure knows what he's talking about. If nothing else, Microsoft has had a whole lot of practice with regards to project management of large software projects. A good read for both you and your boss.
Your example for the documentation is a good one and your closing statements make good sense too. So far, I've been lucky enough to work with some pretty talented developers so minimal documentation is an asset. I guess I'm wishing for ideal situations:)
I'm surprised that anyone would attempt to argue the merits of using any computer language as the appropriate mechanism for communicating the intent of an algorithm/function/method. Howdy, here's one. Actually, I'll argue the merits if we remove algorithm from that list... The merits from my point of view: Concise, minimized number of changes, "documentation" is always up to date. Now, before anyone gets crazy, I did state in my last post that some documentation is necessary. In particular, high level documentation is a must and documentation of very tricky pieces of code makes it much easier for a maintainer to work with your code. Other documentation just gets in the way or, in extreme cases, misleads the maintainer.
And I regard algorithm more as a paper thing than a code thing. A function or method is the implementation of that algorithm and if you've put that much thought into a piece of code to justify it as an algorithm, you've probably got some very nifty diagrams and design docs to go along with it. Documenting the implementation is unnecessary unless it deviates from the specified algorithm. "Reference: My cool algo" is probably enough.
In your scenario, the problem was not simply that the documentation was out of date. If you're operating in a shop where a change can be made in a core component without triggering regression testing, or core components can have their functionality change without revving the API, you need to fix your process. That works. So now the code and documentation match, but the regression test fails. Or the code and regression test works, but the documentation says something like, "This should be fixed. Possible risk for thread contention" when in fact, the risk for thread contention has been removed. So which is correct? Regression testing is perhaps the best form of documentation, but it's not quite so "invisible". If a regression test fails, you know it. If documentation is incorrect, you might miss that for months or years.
In general, I prefer less high-level documentation and more at the class and library level. I know I'd much rather have a well documented class header and methods (with code fragment examples) and a good unit test than having to dive into an implementation and reverse engineer somebody else's code.
That is high level documentation, isn't it? Design documents are higher level, but not by much. The api documentation is critical and having a separate individual who's responsibility is to maintain api documentation is not too bad an idea (poor, poor soul though....). And as long as the api stays consistent, it's a write once and forget. With a rapidly change api, it's probably more of a burden initially and Leo seems to push for api solidity. I don't know about you, but I'm constently extending and improving the api of my personal libraries as I learn more or need more out of the api. Minimal documentation seems to be a better use of my time than trying to exhaustivly document a changing api.
I'm not stating either 1 or 2. The posts above are arguing both extremes and I'm leaning towards the idea that the code itself is a damn good documentation tool. I'm also pointing out that no documentation is many times better than incorrect documentation (so no, I do not agree with you). Strong regression testing would most likely catch what you call my second case, but that won't always be true. I will concede that regression tests are probably the most vaulable form of documentation that has been mentioned so far, but again, incorrect documentation (or regression tests here..) are deadly.
So again, I'm not imply or recommending that we try to get away with *no* documentation. I'm just pointing out that it's in our best interest to allow the code to document as much as absolutely possible.
I'm not the anon from above... Regardless, you have your real debate.
"Code should document the program"
Of course it should. Anywhere that the code does not "document" the program, the progammer needs to provide explicit documentation or write clearer code. That's very very simple if you just consider that the code *is* the program. What documentation could be more correct than the code if you want to know what the program does.
"Documentation should document what a program *should* do."
Very nice idea, but I've never seen this work in practice. The problem is basically this: You just introduced an entirely different vector under which bugs can occur. These new bugs do not break the program in any visible manner, they just destroy the productivity of a maintenence programmer.
Example... Client decides to change the behavior of a component of a system after the program has been released. Programmer goes in and changes the code, but never changes the documentation. While making the change, the programmer notices that another requested change will cause the first piece of code to break in a very subtle way if it had not been changed.
6 months later, another programmer makes some changes and notices that a line of code is clearly not doing what the documentation says it should be doing. Feeling almighty and powerful, he modifies the line so it fits the documentation, thus overwritting the change from 6 months ago and introducing a subtle bug.
What happened? If documentation is not kept up to date (one more bug vector to worry about), the maintenence programmer will either lose time verifying which is correct or will "fix" a bug that shouldn't be fixed. Neither case is a good thing. Documentation bugs are especially bad because they are so transparent.
So which is worse? I would warrant that the second is far worse. Any documentation that can be embeded directly into the statements of the language through variable names, function names, language constructs, data structures, etc are a great benefit as they cut down on the number of instances where doc bugs can occur.
Nonetheless, it's is definitely necessary to document particulary nasty chunks of code, but keep the documentation at the highest level possible. If it is a system overview comment, it belongs in a design doc. If it describes how a black box *should* work, it belongs at the highest level of that box (ie, class or function). If it is a single line genius piece of code, by all means, document it. But be assured that anyone who changes it will probably have a tough time understanding it, will have to read the documentation, and will likely remember to update the documentation out of appreciation if nothing else.
If this is tough to accept, look at one of your own statements..
But - every time I add NEW requirements, you'll have to massively modify the code. As the code becomes more and more complex, it will have more opportunities to gain bugs. Really? And so as it becomes more complex, it will likely need documentation to describe the additions that are being glued to the side of the original design, right? Oh, right. Maybe it will remain constant?.....
All this while, though, the documentation might remain constant, if it's written clearly enough. Yes, it might. Are you going to remember to check it, especially if it is right *most* of the time...
I just got it setup for a client running Point of Sale systems. Most of their machines are Linux based and our POS software runs just fine, but we haven't ported the printing to Windows yet, so running the software on the Windows machine is not possible.
When the client is offsite and needs a bunch more computers, we can now just grab a couple of spare Windows boxes, stick a CD in and boot up a fully functional Linux system with our software installed and configured. The process for adding your own software is listed in their English forum and I can help anyone out who's interested. Post a reply here and I'll check when I get back from Reno, NV on the 12th.
I can only see glimpses of the backgrounds in the last 6 screenshots, but they rock! Any one have any idea where I can grab them (besides checking out the KDE tree...)????
Ahhhhhh!!!!!! What the heck! It must just be too early in the morning for most of you. More than half the posts already have said basically, "So what, wouldn't you do it too?" or "What's so wrong with that?" How is it that we find it so easy to place a value on a human life? If asked the question, "What is my life worth to you?", can you really respond to me with a dollar amount?
It's one thing to offer your life for anothers and that's regarded the greatest gift a man can give, but to put a price on someone? Come on people, I know it's just a web forum so I can't reach around the world and smack you up side the head, but have a little class...
Exactly... The fasttrack network is homefree 'cause they've already got the checksum stuff in there. If you try to download a song and get the wrong one, you simply mark the checksum as bad and grab one with a different checksum. Heck, the clients could even communicate with the main fasttrack server and identify the bad files. If enough individual users marked a checksum, it could be filter.
The only way to thwart that would be to buy a very large number of unique IP address and then mark good files as bad, but I'm not sure there are even enough left;o)
Gnutella would be fighting a little rougher battle 'cause I don't think it has the checksum ability (at least none of my clients use it) and there is no centralized server. On the other hand, it wouldn't be hard to establish a communication method for nodes to report bad files across the network and the checksumming could probably be added as well (that would be so cool).
The media people are fighting a battle off of their turf and it's really showing...
And how in the world does it work? That's gotta be a huge amount of data to store. Is the database distributed in some way? Are you doing something like a decentralized distributed hash table for data lookup or using a traditional relational database? And, how much data is stored as of today and how fast is it growing?
No, no, no, no, no! We *can* control it. We *can* build fault tolerant systems. We *can* take our time to ensure that our application will only respond to valid input/requests/etc. If you build the OS, make sure that nothing using your OS has a chance of crashing it. If you build a webserver, make sure that feeding it crap in the URL will not cause it to respond "The root password is 'imadip'".
What happened to the idea of a program having a well defined set of inputs and only causing it to respond to those inputs? And if something goes wrong, where are people getting off trying to blame it on the user be it a person or another program using that well defined interface? Argh.
Word did not crash Windows. The printer driver didn't crash Windows. The stupid user who pressed the wrong things in the wrong order didn't crash Windows. Windows just crapped itself.
Mundie said. "Microsoft can't control that process. If the printer driver tanks the system, who do you hold liable?"
OMG, this is exactly the same thing a guy said to me when I was complaining about Windows stability... I mean, really, if the printer driver tanks the system? Build a solid OS and the printer driver might not work, but it sure won't tank the system. If the operating system crashes, it crashes.
If me running Microsoft Word on Windows 98 causes my system to crash, the flipping OS needs fixed (Yeah, I was stuck with that combination for the first year of school and yeah, it sucks). No wonder the old quote "If we built houses like we do software, the first woodpecker to come along would destroy civilization" holds true.
I'm probably going to get modded into oblivion for this, but I really want to know... Why is what Microsoft did considered a bad thing?
When I go to the supermarket I tend to buy the largest package of something that I think my family can consume before it goes bad because prices tend to be better in bulk. I makes a certain amount of sense too. To the producer, a sale of 1 unit package is not worth as much as a packaged sale of 5 units. Of course, this can be messed up, but the general idea still holds.
Also, I tend to work at a lower hourly rate when I know I'm going to get a project that is 3 times larger than a normal project. I do that, of course, because I'm getting more stable work.
So how is Microsoft charging less for bulk purchases somehow wrong?
It's a sign that the music labels are going to try to deal with the P2P phenomenon on its own terms, not in the courts.
I totally agree and I can't believe how long it took them to finally figure this one out. I got a whole bunch of Scorpian King adverts instead of a movie I was trying to grab. Pretty effective stuff, I must say. My next search was "Scorpian King avi";o)
Slashdot Mirror
Don't you read your own links? What part of "InnoDB Hot Backup is a non-free additional tool which is not included in the standard MySQL distribution" is unclear to you?
:( Although I haven't researched it much, it does sound like the new stuff coming in 4.0 is really cool though. Also, like I mentioned, replication might be a very good solution...
I honestly missed that one
In reply to the foreign key and constraints discussion, it happens to be built into my schema. The schemas I'm creating now create type/size/regex match/etc contraints that get compiled into the program automagically. Another developer and myself have created an object to relational mapping compiler that will translate our "nifty" schema into an object based wrapper over the database. Anyone using the wrapper can be guarenteed that contraints will be enforced, etc. Also, things like foreign key contraints are handle automatically or subclassed for tricky relationships.
In addition, I hate seeing error messages come back from the db. If I can handle all the errors client side, clean data is the *only* thing that gets submitted. I know it's not the accepted way of doing things, but it works very well.
Does MySQL have support for cell constraints like limiting an integer field to a value between 15 and 90 or making sure that a text field has at least seven characters or matches a valid social security number?
I honestly don't know as I haven't needed or wanted it. See above.
This might lead me to believe that support exists though... FOREIGN KEY is ignored, but I think CHECK included and executed...
or [CONSTRAINT symbol] FOREIGN KEY index_name (index_col_name,...)
[reference_definition]
or CHECK (expr)
Another benefit of what I'm doing allows me to quickly port my apps to other databases. Once the layer for Postgres is created in the compiler, I just recompile on the schema, and boom - I have a object layer for a postgres database based on my cool schema in C++, Python, Java, and PHP (assuming the layers for those languages are present in the compiler). All in all, I should be able to write the backend for a company's point of sale GUI *and* their inventory website in a single schema definition.
Got money for the hotbackups? They cost.
??? I'm not sure if I understand your complaint. Online backup is already available and much improved support is coming in 4.0/4.x. See here and here In addition, replication is not a bad way to build some fault tolerance into your system. I'm not claiming that any of these features are perfect or that they fit your exact needs. I'm merely pointing out that they exist.
How about working FKs? I mean if I can drop an entire table that FKs pointing it, not much intergerity is there?
Don't know what to tell you there. I know foreign key support is planned, but I'm handling all my data integrity inside my apps. InnoDB tables are supposed to support foriegn keys, but again, I don't know how complete the support is as I haven't used them...
On a different note, has anyone done a decent set of benchmarks comparing MySQL with transactions to PostgreSQL? That would be nice to see.
Yes, but I don't see any that don't look biased towards MySQL...
Interesting... What might you consider slightly complicated SQL? I assume at least one example will address sub selects, so please include something in addition to a sub select complaint. Generally, an intelligent developer can solve a query problem without using a sub select and the end solution tends to be much faster...
I assume this is just a troll, but I'll bite. MySQL has supported transactions for quick a while. Please save me some time and do your research...
Or better yet, pay for hosting on two boxes, but set both boxes to fail in either direction. Then, set the db server up as primary on one box and search/www as primary on the other box. Now if one fails, the other serves as a backup, but most of time both would be handling load...
Yes, thank you :) Either you don't factor the exchange rate in, or you have to run it both ways. Thos Barista's at Starbucks would have to be making $15 an hour here to compare with a $9 an hour job in Canada.
And Qt is soooo much easier to use :) The heavy licensing fee is something I'm willing to pay when do commercial development with a toolkit that makes my task substantially easier.
openbrick.org seems to be getting hit pretty hard, but Linux Max has a pretty detailed article on the Open Brick.. And it's not slashdotted.. yet... http://www.linuxmax.net/news/00816.html
Rapid Development by Steve McConnell ISBN: 1-55615-900-5
Amazon.com link
It's a Microsoft book, but the guy sure knows what he's talking about. If nothing else, Microsoft has had a whole lot of practice with regards to project management of large software projects. A good read for both you and your boss.
Your example for the documentation is a good one and your closing statements make good sense too. So far, I've been lucky enough to work with some pretty talented developers so minimal documentation is an asset. I guess I'm wishing for ideal situations :)
I'm surprised that anyone would attempt to argue the merits of using any computer language as the appropriate mechanism for communicating the intent of an algorithm/function/method.
Howdy, here's one. Actually, I'll argue the merits if we remove algorithm from that list... The merits from my point of view: Concise, minimized number of changes, "documentation" is always up to date. Now, before anyone gets crazy, I did state in my last post that some documentation is necessary. In particular, high level documentation is a must and documentation of very tricky pieces of code makes it much easier for a maintainer to work with your code. Other documentation just gets in the way or, in extreme cases, misleads the maintainer.
And I regard algorithm more as a paper thing than a code thing. A function or method is the implementation of that algorithm and if you've put that much thought into a piece of code to justify it as an algorithm, you've probably got some very nifty diagrams and design docs to go along with it. Documenting the implementation is unnecessary unless it deviates from the specified algorithm. "Reference: My cool algo" is probably enough.
In your scenario, the problem was not simply that the documentation was out of date. If you're operating in a shop where a change can be made in a core component without triggering regression testing, or core components can have their functionality change without revving the API, you need to fix your process.
That works. So now the code and documentation match, but the regression test fails. Or the code and regression test works, but the documentation says something like, "This should be fixed. Possible risk for thread contention" when in fact, the risk for thread contention has been removed. So which is correct? Regression testing is perhaps the best form of documentation, but it's not quite so "invisible". If a regression test fails, you know it. If documentation is incorrect, you might miss that for months or years.
In general, I prefer less high-level documentation and more at the class and library level. I know I'd much rather have a well documented class header and methods (with code fragment examples) and a good unit test than having to dive into an implementation and reverse engineer somebody else's code.
That is high level documentation, isn't it? Design documents are higher level, but not by much. The api documentation is critical and having a separate individual who's responsibility is to maintain api documentation is not too bad an idea (poor, poor soul though....). And as long as the api stays consistent, it's a write once and forget. With a rapidly change api, it's probably more of a burden initially and Leo seems to push for api solidity. I don't know about you, but I'm constently extending and improving the api of my personal libraries as I learn more or need more out of the api. Minimal documentation seems to be a better use of my time than trying to exhaustivly document a changing api.
I'm not stating either 1 or 2. The posts above are arguing both extremes and I'm leaning towards the idea that the code itself is a damn good documentation tool. I'm also pointing out that no documentation is many times better than incorrect documentation (so no, I do not agree with you). Strong regression testing would most likely catch what you call my second case, but that won't always be true. I will concede that regression tests are probably the most vaulable form of documentation that has been mentioned so far, but again, incorrect documentation (or regression tests here..) are deadly.
So again, I'm not imply or recommending that we try to get away with *no* documentation. I'm just pointing out that it's in our best interest to allow the code to document as much as absolutely possible.
Of course it should. Anywhere that the code does not "document" the program, the progammer needs to provide explicit documentation or write clearer code. That's very very simple if you just consider that the code *is* the program. What documentation could be more correct than the code if you want to know what the program does.
Very nice idea, but I've never seen this work in practice. The problem is basically this: You just introduced an entirely different vector under which bugs can occur. These new bugs do not break the program in any visible manner, they just destroy the productivity of a maintenence programmer.
Example... Client decides to change the behavior of a component of a system after the program has been released. Programmer goes in and changes the code, but never changes the documentation. While making the change, the programmer notices that another requested change will cause the first piece of code to break in a very subtle way if it had not been changed.
6 months later, another programmer makes some changes and notices that a line of code is clearly not doing what the documentation says it should be doing. Feeling almighty and powerful, he modifies the line so it fits the documentation, thus overwritting the change from 6 months ago and introducing a subtle bug.
What happened? If documentation is not kept up to date (one more bug vector to worry about), the maintenence programmer will either lose time verifying which is correct or will "fix" a bug that shouldn't be fixed. Neither case is a good thing. Documentation bugs are especially bad because they are so transparent.
So which is worse? I would warrant that the second is far worse. Any documentation that can be embeded directly into the statements of the language through variable names, function names, language constructs, data structures, etc are a great benefit as they cut down on the number of instances where doc bugs can occur.
Nonetheless, it's is definitely necessary to document particulary nasty chunks of code, but keep the documentation at the highest level possible. If it is a system overview comment, it belongs in a design doc. If it describes how a black box *should* work, it belongs at the highest level of that box (ie, class or function). If it is a single line genius piece of code, by all means, document it. But be assured that anyone who changes it will probably have a tough time understanding it, will have to read the documentation, and will likely remember to update the documentation out of appreciation if nothing else.
If this is tough to accept, look at one of your own statements..
But - every time I add NEW requirements, you'll have to massively modify the code. As the code becomes more and more complex, it will have more opportunities to gain bugs.
Really? And so as it becomes more complex, it will likely need documentation to describe the additions that are being glued to the side of the original design, right? Oh, right. Maybe it will remain constant?
All this while, though, the documentation might remain constant, if it's written clearly enough.
Yes, it might. Are you going to remember to check it, especially if it is right *most* of the time...
So, there you go
I just got it setup for a client running Point of Sale systems. Most of their machines are Linux based and our POS software runs just fine, but we haven't ported the printing to Windows yet, so running the software on the Windows machine is not possible.
When the client is offsite and needs a bunch more computers, we can now just grab a couple of spare Windows boxes, stick a CD in and boot up a fully functional Linux system with our software installed and configured. The process for adding your own software is listed in their English forum and I can help anyone out who's interested. Post a reply here and I'll check when I get back from Reno, NV on the 12th.
The listed address had an extra space and HTML isn't too tough ;o)
1 /CVS.html
http://linux.oreillynet.com/pub/a/linux/2002/01/3
I can only see glimpses of the backgrounds in the last 6 screenshots, but they rock! Any one have any idea where I can grab them (besides checking out the KDE tree...)????
It's not a BUG, it's a culture... If you don't like the culture, then switch back. cya
Ahhhhhh!!!!!! What the heck! It must just be too early in the morning for most of you. More than half the posts already have said basically, "So what, wouldn't you do it too?" or "What's so wrong with that?" How is it that we find it so easy to place a value on a human life? If asked the question, "What is my life worth to you?", can you really respond to me with a dollar amount?
It's one thing to offer your life for anothers and that's regarded the greatest gift a man can give, but to put a price on someone? Come on people, I know it's just a web forum so I can't reach around the world and smack you up side the head, but have a little class...
Exactly... The fasttrack network is homefree 'cause they've already got the checksum stuff in there. If you try to download a song and get the wrong one, you simply mark the checksum as bad and grab one with a different checksum. Heck, the clients could even communicate with the main fasttrack server and identify the bad files. If enough individual users marked a checksum, it could be filter.
;o)
The only way to thwart that would be to buy a very large number of unique IP address and then mark good files as bad, but I'm not sure there are even enough left
Gnutella would be fighting a little rougher battle 'cause I don't think it has the checksum ability (at least none of my clients use it) and there is no centralized server. On the other hand, it wouldn't be hard to establish a communication method for nodes to report bad files across the network and the checksumming could probably be added as well (that would be so cool).
The media people are fighting a battle off of their turf and it's really showing...
And how in the world does it work? That's gotta be a huge amount of data to store. Is the database distributed in some way? Are you doing something like a decentralized distributed hash table for data lookup or using a traditional relational database? And, how much data is stored as of today and how fast is it growing?
No, no, no, no, no! We *can* control it. We *can* build fault tolerant systems. We *can* take our time to ensure that our application will only respond to valid input/requests/etc. If you build the OS, make sure that nothing using your OS has a chance of crashing it. If you build a webserver, make sure that feeding it crap in the URL will not cause it to respond "The root password is 'imadip'".
What happened to the idea of a program having a well defined set of inputs and only causing it to respond to those inputs? And if something goes wrong, where are people getting off trying to blame it on the user be it a person or another program using that well defined interface? Argh.
Word did not crash Windows. The printer driver didn't crash Windows. The stupid user who pressed the wrong things in the wrong order didn't crash Windows. Windows just crapped itself.
Mundie said. "Microsoft can't control that process. If the printer driver tanks the system, who do you hold liable?"
OMG, this is exactly the same thing a guy said to me when I was complaining about Windows stability... I mean, really, if the printer driver tanks the system? Build a solid OS and the printer driver might not work, but it sure won't tank the system. If the operating system crashes, it crashes.
If me running Microsoft Word on Windows 98 causes my system to crash, the flipping OS needs fixed (Yeah, I was stuck with that combination for the first year of school and yeah, it sucks). No wonder the old quote "If we built houses like we do software, the first woodpecker to come along would destroy civilization" holds true.
I'm probably going to get modded into oblivion for this, but I really want to know... Why is what Microsoft did considered a bad thing?
When I go to the supermarket I tend to buy the largest package of something that I think my family can consume before it goes bad because prices tend to be better in bulk. I makes a certain amount of sense too. To the producer, a sale of 1 unit package is not worth as much as a packaged sale of 5 units. Of course, this can be messed up, but the general idea still holds.
Also, I tend to work at a lower hourly rate when I know I'm going to get a project that is 3 times larger than a normal project. I do that, of course, because I'm getting more stable work.
So how is Microsoft charging less for bulk purchases somehow wrong?
doh, what can I say? ;o)
It's a sign that the music labels are going to try to deal with the P2P phenomenon on its own terms, not in the courts.
;o)
I totally agree and I can't believe how long it took them to finally figure this one out. I got a whole bunch of Scorpian King adverts instead of a movie I was trying to grab. Pretty effective stuff, I must say. My next search was "Scorpian King avi"