Slashdot Mirror
Is Fear Reducing the Publicity for Open Source?
sebFlyte writes "Are companies deliberately keeping quiet about moves to open source because they are afraid of the reactions of proprietary vendors they still have relationships with? ZDNet raises and tries to answer this question in a two-part special report, 'Open source behind closed doors'. It comes to the conclusion that, in all probability, companies are keeping quiet to avoid reprisals of one sort or another. One part of the fear of publicizing migrations is nicely summed up in the second part by Tristan Nitot of Mozilla Europe: 'Guys are really shy -- it's the Munich Linux thing. They start talking about it and suddenly Ballmer comes in and twists your arm until you cry.'"
You live in fear of the 100% markup that you will pay if you go against MS (for all Windows based software, not just MS's). MS has a long history of penalizing those that do not do exactly what MS wants. Yes, MS will offer 80 % off of this years prices to keep you. But they expect high prices next year, and they expect that you will not even toy with OSS anymore. Simply read what Dell had to say at the MS monopoly trial.
I prefer the "u" in honour as it seems to be missing these days.
They start talking about it and suddenly Ballmer comes in and twists your arm until you cry.
Better that than a monkey dance!
Each of those companies are primarily technology providers in some form.
I think the article pertains mostly to companies whose primary market isn't technology, where they use tech, but don't sell that tech as a product to itself.
Of course it's never the fault of the programmer. From the description of PASSWORD() from the MySQL docs:
"Calculates and returns a password string from the plaintext password str, or NULL if the argument was NULL. This is the function that is used for encrypting MySQL passwords for storage in the Password column of the user grant table.
Note: The PASSWORD() function is used by the authentication system in MySQL Server; you should not use it in your own applications. For that purpose, use MD5() or SHA1() instead. Also see RFC 2195 for more information about handling passwords and authentication securely in your applications."
This has been in the docs for years, long before 4.1 (the version in which the internal hash algorithm was updated) was released. The possibility for application breakage from this change was also fully documented in the upgrade release notes. In fact, it's mentioned in the first real step. As if that wasn't enough, you actually have to want to use the new password algorithm. If after you upgrade the grants table isn't manually altered to support the new hash length, the PASSWORD() function works exactly as it did in versions 4.0 and earlier.
Unhuh. And why is it you're not validating user input? Bad data should never have a chance to get to the database in the first place.
Jesus H... Here it is 2005, and people still say stuff like this.
First of all, the fundamental purpose of the DBMS is data integrity. If you're doing data integrity in your app, you are doing the DBMS' job. Of course, you are welcomed to *repeat* some of the constraints in your app, since "modern" databases have shitty exception handling, but that's a separate issue.
Second, whatever constraints you have in your DB define your data model. If your DB allows blank user names, then that's part of your data model. You better be able to handle it in your app, and not assume that your validation code ever ran. Because your app is not a DBMS.. it's not the most general layer for accessing the data.
Third: data management has a solid theory behind it. I don't think your app does. Putting validation in your app just means you're even less likely to see future DBMS products that use that information for optimizing queries, for instance.
Fourth: are you ready to go and update all your apps every time the constraints change? How about apps that you don't have any control over (like, say, the "mysql" command line program??). (Aside: it makes me chuckle when greenhorn programmers claim that spreading arbitrary constraints over all their apps is more "agile" than putting it in the DBMS).
Fifth: If you DBMS doesn't support this arguably *correct* methodology, STOP USING IT. Don't make excuses for it. If your DBMS doesn't let you declare *arbitrary* constraints, it's not a true DBMS. It's like a calculator with a missing division key. Good for some tasks, but what's the point when you can make it general with no loss of performance or functionality?
Application-centric data management should've died in the 60's, when it was popular. Let's let it die now, at least.. please.