That's the nut of it: it is OS/X the one that have Vista-like graphics, not the other way around. If you don't see what the effect of such wording is expected to be, I resign.
"but it doesn't make sense anybody'd read it that way."
It doesn't need to make sense in order to make effect.
"Thirded. The statement was poorly phrased, yet still difficult to interpret the way he did"
I don't think so. While it's clear what does it means, it's worded in a way that somehow subcontious it will produce the "feeling" that somehow Apple did copycat Microsoft.
You don't need to explain that to me. I was just taking the 'devil's advocate' role.
And you cannot have it both ways: you either explain that properly chosen open source software can be as "corporative" as any privative one, in which case your "no commercial pressure" doesn't hold water, or you try to go with the "no pressure argument" and the next you will be told is that if there's no commercial pressure is because such software is developed by pimply teenagers in their basement.
So, all in all, I find better to avoid the issue enterely and concentrate on "perceptions" the one that accept this kind of "FUD marketing campaign" cannot negate: ie the "but IBM uses it and they surely know better" argument or the "but Google is really an extremely wide open source software based around the world and they don't get cracked" one.
"As opposed to the enormous success corporations have had in recovering damages from major commercial software vendors?"
Since this FUD campaign seems to gain some success, is obvious it is not a matter of facts, but a matter or perceptions. The ignorant one that pays on the arguments of Microsoft's marketroids certainly will try the 'liability argument', so you better avoid that field.
"if the bad guy examines the source code and finds an exploit BEFORE the good guys find and fix the hole, then it's just as bad as a 0-day Microsoft attack"
And then you gave the answer. The key point is "as bad", as in "no worse". So in the worst case scenario you are "as bad", but no worse than, a 0-day Microsoft exploit.
On the other hand, if just one of the miriads of white hat hackers do find the bug in advance to the black hackers you are in a much better situation than in the 0-day Microsoft exploit case.
Now, ask yourself which scenario is more probable: the black hats wining the race against dozens of Microsoft developers in one case or against hundreds, if not thousands, of white hackers in the other?
"and now Adobe is pointing out that writing and maintaining software for Linux is difficult because, despite some good efforts, there still is no standard definition for what a linux system is or contains..."
Well, Apache Software, MySQL AB, Postgres folks, KDE Team, Gnome fanboys, Mozilla Foundation... they all don't seem to find writing and maintaing software for Linux (and *BSD, and quite some different Unix flavours) to be so terribly difficult, so maybe Adobe's efforts are not so good after all, despite what they say...
"Ask your customer a simple question in reply: Does that fact that closed source software hides it's defects mean that it doesn't have any defects?"
To attain exactly, what? Just to follow your argument, here comes the obvious answer to your "counter-question":
Of course closed software has its defects. But then, its defects are hidden, aren't they? So they are obviously more difficult to exploit, and I prefer to have a software its defects are difficult to exploit rather than one which is easy to exploit. I'm questioning my confidence on your ability to have the things done if I have to explain to you such an obvious thing!
"Would you rather be at the mercy of your vendors to disclose (against their own self-interest) and fix security issues (on their own timetable); or would you rather have a multitude of people, who are dedicated to the values of openness and transparency, constantly striving to keep open source software as secure as possible?"
Hummm... at the end of the day, a USA corporation may be held legally liable. Do you really expect me to try to recover damages from a stinky teenager deep in Soviet Russia (where teenagers stink you) that happened to develop some seemingly cute software in his spare time?
No, the answer has been already told. If they really are paying attention at such stupid arguments like those from 'M$ drones', they are ignorant about these issues, and the best course of action is enligth them in such a way they can understand:
Look at IBM: they extensively use open source and it seems they are not going into bankrupcy anytime soon. Look at Google: they critically use open source, they have an ashtounding computer-base all around the globe and still it doesn't seem like they are hacked everyday, do they?
You can ask a question *then*: Look at IBM or at Google, or at almost every Fortune 100 out there; they do well using open source. Don't you find suspicious the only ones pesting about open source are companies (Microsoft and its VARs) that *do* would go bankrupcy if open source took the computer world for a raid?
"ok, how far have you got with that urgent stock control application?"
I'm either a project manager, in which case I don't have to answer such kind of questions, or I'm a project developer, in which case the productivity tools will show how far I got (number of code lines, diff/patches, new files, milestones achieved...) and I don't have to answer such questions either. If forced to answer such a question, my answer is usually "within timeframe" (if it's such the case, of course). And if I need to say "this feature will be in ten days, not in seven as you thought" to my boss, so I do.
"do you want me to add more comments?"
I'm really sorry about you. It seems you weren't lucky about your project managers *nor* you had the guts to look for them elsewere.
If it takes a week, it takes a week, no matter how do you order it (within bounds), but doing things in the proper order is your best safeward against momentary crazyness from your bosses (as in the case I firstly was answering to). If your boss is crazy on a full-time basis, it's time to test different waters because no matter what, you'll be spoiled (so going first for half-assed functionality isn't going to work for you in the long run eiter). Of course, in order to be chooser instead of chosen, you better are high on your job abilities.
"I have to admit that exchange is probably one of the best email servers out there"
What the f*???
I can admit it's a good integration/egroupwaring tool (though most of it becomes from the almost monopoly Ms Office detents); I could even admit it has some good MDA features, but... email server!!!??? It's almost pure shit!
It's buggy, overloaded and fragile, and if nowadays talks SMTP the way it should be it's only because it came late to the field (they tried to bastardize SMTP too, but luckily enough there already were some free source mates there to stop it).
Just as a proof: noone on his mind leaves an Exchange server open to the Internet (and I mean *only* the TCP port 25). Everybody will use a front end MTA (a *real* one, I mean, be it Sendmail, Postfix, Exim, Qmail... whatever); even if you are really an MS shop, you will have a "choke server", a "front end gateway" or whatever they call it these days.
"Once configured and running, exchange is pretty robust and predictable."
Yeah: you can predict with sureness it will bog down as soon as next spam attack reaches to it.
"Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code."
Who wrote the code? You!
You can be sure *you* are the one to blame, not your boss.
If you are working on a mockup GUI, be sure no functionallity is within the demo.
If you are working on a mockup funtional unit, be sure is terrifying ugly so no PHB will think it's ready.
When you are programming, as a general matter, first comes the comments, second the bound tests, third the functionality, and last (if needed) the API or the interface.
Not only you won't have to pass through the "compile? it's production, then", but your code quality will enhance almost without you noting.
"I am, even as I type this, taking a break from trying to deploy a PHP app to a different server than the one it was developped on, and the amount of fiddling required to get both installations of PHP to work in a compatible way is mind-numbing"
What is mind-numbind is the hugh amount of completly lacking people who call themselves "php developers"; of course they are not "php developers" since they are not developers at all.
That's not exactly a demerit on the PHP side, since that means that people without almost the slighest programming acumen can produce some meritable (to an extent) things. It is a very good hobbyist language.
On the other hand, people with proper programming skills can make PHP behave properly too so we return again to paragraph one.
You would see exactly the same problems, only accrued programming multiplatform C still you can see vast amounts of software that gladly run on a dozen platforms after only a./config, make, make install run. The secret? They *know* their trade, if only because the steeper entry path of C+autotools that take away unfitted wannabies.
"Turns out that PHP broke backwards compatibility again in its last version"
Turns out that PHP devels have a very nasty tendency to work that way so turns out a wise project manager or even a wise developer will stay away from PHP for any enterprise task; another hint about the experience and maturity of the development environment you are involved.
"please don't dismiss such a study just because its findings annoys us. We have a lot of improvement to do still.:("
The only finding that study shows is that on Microsoft camp almost even a monkey can come up with a half assed semiworking solution were you can't get even this on a unix-like environment. Not precisely big news.
On the other hand what the study doesn't talk about is how long each party can reach when a knowledgeable team puts their hands on one platform or the other.
Hint: one side will simply skyrocket the other on perfomance, stability and money. Hint2: the one that will do doesn't come from Redmond.
"There's just no way to standardize the configuration of one single database"
Yes there is, an easy one. Vendors know it, still they don't want to produce it.
In case the vendors were not aware, I'll explain here:
*Go to three universities with reknowned IT areas expertise. Ask them to produce ten "Enterprise database case scenarios" so you have thirty of them. *Pass an Slashdot-like poll to Fortune 500 DBa's so they can not only vote but pose their opinions too. Go again to the universities with the poll results so they can refine their test cases till the point ten of them sum up 80% of the votes. *Invite whatever DB "vendors" (including of course open source ones too) to a closed door test with limited budget (say one million dollars per vendor; valuate the DBAs man/hour costs at the average from the Fortune 500 ones an the hardware and software by its front cover retail prices). Then allow them (within budget) to produce results on whatever the vendor-provided DBAs considered proper (say, two Oracle gurus working on their preferred 256 ways Suns, two Postgres hippies and a FreeBSD greybearded on a cluster of white brand boxes, half a dozen Windows architects on Ms Windows Enterprise Datacenter on a bunch of 16 ways DELLs... whatever) give them a two week time frame and compare the results.
You would say you are comparing apples to oranges, but all the parties worked within the same budget and time constrains and where allowed to bring whatever experts they considered proper to achieve better results so from the Fortune 500 standpoint is the clearest apples to apples comparation you can get.
Hey! your comment exactly mirror my experience on the *whole* Microsoft product portfolio from the last 15 years! (not that I'm surprised; if Microsoft policy has been one for about two decades and it made its owner the richest man in the world, why should they change it?)
"I'm simply saying that there's no 1 to 1, conversion-free or syntax-change-free way"
And then, the article is "simply saying" that while it might be no 1 to 1 conversion-free way, there is a 1 to 0.5 money free one (of course *when* such a move away is doable... warm regards to closed software lock-in strategies).
"I was one of those scientists (worked in an academic research facility) for a while and my pay wasn't so bad..."
I bet you were not a scientist but a technocrat. An engineer if you so prefer. Not to mean anything bad about engineering or engineers, on contrary, I deem these efforts as most needed, but there's a difference between researching on new materials for making shorter transistors (something companies beef and longsigthed enough will pay for) and researching the living habits of a frog which overall population is 80 individuals in some obscure place in Africa.
"where's the motivation for new developers to go open source? Not everybody operates with an altruistic "I'm giving back to the community" motivation."
Then not everybody distributes their creations under a open source license.
Easy, isn't it?
And regarding your question, motivation for those that are not moved by the money they get by developing open source, the answer is easy too: "somewhere else".
"I genuinely don't understand why anyone would want to share the fundamentals of their creation in a way that would compromise any potential future earnings."
Still, most of the creation out of Human Spirit came in ways that "compromised future earnings". Don't worry, it's simply you are not up to the highest standards of really creative souls.
"that only drives home the notion that there is no Linux OS"
Well, you have learnt at least one lesson then. You are right: there's no more "a Linux OS" than there is "a BSD OS", it seems you finally grasped the concept.
"Why do I need to upgrade to Debian Etch in order to run KDE 3.5? (...) I can run KDE 3.5 on FreeBSD 4.11, 5.5, and 6.1"
Because Debian's concept of "stability" (pay attention to this: DEBIAN's concept, nothing to do with Linux) is different than that from FreeBSD (pay attention to this: FREEBSD's concept, nothing to do with BSD), that's why; take it or leave it.
"Here's a pretty interesting thread by a BSD user who had to learn to use Debian at work and shares his experiences. He sums up the differences between FreeBSD and Debian quite nicely. Makes for an interesting read."
Well, I already read the thread, and I can assure it doesn't "make for an intersting read", it doesn't "sum up the differences between FreeBSD and Debian" at any rate and probably the only interest in there is for a psychologist about the many ways the human mind manages to confuse itself.
Just a few points: 1) The author decides to give a try to Debian because FreeBSD doesn't support critical elements of his computer's hardware. 2) Then he populates the sources list with a nightmare of unofficial an unmatching repositories. 3) Then he concludes that Debian is not an "OS" but a bunch of unconnected packages, and that finding useful software is "a royal pain"....but he absolutly "forgets" about what would had happen if he even tried to do something similar on FreeBSD:
What happens if you even try to mix the ports tree from 5.x with 6.x to mix-and-match software from both branches (not to talk if you try to install *binary* packages from 5.x and 6.x at the same time)? What happens if you even try to mix the ports tree from official FreeBSD with three or four partial ports trees from unofficial origins?
I'll tell you the answer: even if you are a FreeBSD guru you will have quite a hard day toying with CVS and customizing Makefiles to acomplish such a daunting task, still he manages to do it on Debian on his first weeks of usage with only minor headheaches but, hey! Debian is the "royal pain".
It's quite ashtonishing how the FreeBSD folk would send you happily to RTFM (quite good quality resources, I recognize) but then, as in this example, won't follow their very counsel when experimenting with a (for them) new OS; it's obvious he didn't go through the (quite good quality too) documentation at debian.org.
"I was merely pointing out that I find working on the CLI in BSD more comfortable than clicking widgets in Linux"
So you were merely comparing apples to oranges.
"compare/etc/rc.conf in BSD to all the runlevel config files in Linux"...out of ignorance.
Good work!
"Here's a pretty interesting thread by a BSD user who had to learn to use Debian at work and shares his experiences. He sums up the differences between FreeBSD and Debian quite nicely. Makes for an interesting read."
That really good make a difference from the rest of your post; I'll have a look at it.
"Yes, this is what I would think as well, but imagine you are a big insurance company (...) there seems to be a trend (see google data center post) that opposes intelligent use of computer resources as maybe SETI does."
Don't think so. Banks, insurance companies and the like are not making such big profits by being dumb.
"Bottom line: they tried to listen to customers and failed as usual. Here's what I want to see in a phone"
Bottom line: for the most part YOU ARE NOT A MOTOROLA CUSTOMER. I don't know how is it in the USA, but I know most of the world mobile sales come from the operators which buy them in bulk for their offers (either prepay or contract packs) so the mobile builders will listen to their real customers, the operators. And the operators want you to download games and ringtones and they want you (in developed countries at least) to use their more expensive "multimedia" services. That's why you will have a hard day trying to find the phone *you* like instead of the phone the operators like.
"Style---no, it isn't important to most people. It's a phone."
That would be wrong *even* if the mobile builders would listen to you (which they are not doing, as I already explained). People *think* style is not importante to them, but the only reasonable path for them to tell it to the company is with their *money*. And it demonstrates one and again that on compulsory buying (and for the most part you buy a mobile out of eye-candyness or in a hurry) style is the most important selling factor. You can cry the hell out about how style is not important, but then if the "stylish" phone sells better by far than the "ugly" one what are sellers going to do?
About all the other "like" and "don't like" you just need to think they either would make the mobile more expensive, or more difficult to stand by FCC-like regulations, or doesn't really matter to them (it's more or less "neutral", like ergonomics on the UI: there're not so much people that buy a mobile after an extended exploration of the market offers, so for the most part by the time they discover they don't like the UI they already *payed* for it), or makes sense to their real customers (like the multimedia-related crap: good for the operators, or an excess on durability: bad for everybody but you; the builder wants to sell more units, the operators want to offer new services).
Slashdot Mirror
"it describes having Vista-like graphics"
That's the nut of it: it is OS/X the one that have Vista-like graphics, not the other way around. If you don't see what the effect of such wording is expected to be, I resign.
"but it doesn't make sense anybody'd read it that way."
It doesn't need to make sense in order to make effect.
"Thirded. The statement was poorly phrased, yet still difficult to interpret the way he did"
I don't think so. While it's clear what does it means, it's worded in a way that somehow subcontious it will produce the "feeling" that somehow Apple did copycat Microsoft.
You don't need to explain that to me. I was just taking the 'devil's advocate' role.
And you cannot have it both ways: you either explain that properly chosen open source software can be as "corporative" as any privative one, in which case your "no commercial pressure" doesn't hold water, or you try to go with the "no pressure argument" and the next you will be told is that if there's no commercial pressure is because such software is developed by pimply teenagers in their basement.
So, all in all, I find better to avoid the issue enterely and concentrate on "perceptions" the one that accept this kind of "FUD marketing campaign" cannot negate: ie the "but IBM uses it and they surely know better" argument or the "but Google is really an extremely wide open source software based around the world and they don't get cracked" one.
"As opposed to the enormous success corporations have had in recovering damages from major commercial software vendors?"
Since this FUD campaign seems to gain some success, is obvious it is not a matter of facts, but a matter or perceptions. The ignorant one that pays on the arguments of Microsoft's marketroids certainly will try the 'liability argument', so you better avoid that field.
"if the bad guy examines the source code and finds an exploit BEFORE the good guys find and fix the hole, then it's just as bad as a 0-day Microsoft attack"
And then you gave the answer. The key point is "as bad", as in "no worse". So in the worst case scenario you are "as bad", but no worse than, a 0-day Microsoft exploit.
On the other hand, if just one of the miriads of white hat hackers do find the bug in advance to the black hackers you are in a much better situation than in the 0-day Microsoft exploit case.
Now, ask yourself which scenario is more probable: the black hats wining the race against dozens of Microsoft developers in one case or against hundreds, if not thousands, of white hackers in the other?
"Open Source projects never need to rush out a release to meet quarterly-revenue targets or arbitrary market windows."
Just tell that, ie. to Red Hat Inc.
"and now Adobe is pointing out that writing and maintaining software for Linux is difficult because, despite some good efforts, there still is no standard definition for what a linux system is or contains..."
Well, Apache Software, MySQL AB, Postgres folks, KDE Team, Gnome fanboys, Mozilla Foundation... they all don't seem to find writing and maintaing software for Linux (and *BSD, and quite some different Unix flavours) to be so terribly difficult, so maybe Adobe's efforts are not so good after all, despite what they say...
"Ask your customer a simple question in reply:
Does that fact that closed source software hides it's defects mean that it doesn't have any defects?"
To attain exactly, what?
Just to follow your argument, here comes the obvious answer to your "counter-question":
Of course closed software has its defects. But then, its defects are hidden, aren't they? So they are obviously more difficult to exploit, and I prefer to have a software its defects are difficult to exploit rather than one which is easy to exploit. I'm questioning my confidence on your ability to have the things done if I have to explain to you such an obvious thing!
"Would you rather be at the mercy of your vendors to disclose (against their own self-interest) and fix security issues (on their own timetable); or would you rather have a multitude of people, who are dedicated to the values of openness and transparency, constantly striving to keep open source software as secure as possible?"
Hummm... at the end of the day, a USA corporation may be held legally liable. Do you really expect me to try to recover damages from a stinky teenager deep in Soviet Russia (where teenagers stink you) that happened to develop some seemingly cute software in his spare time?
No, the answer has been already told. If they really are paying attention at such stupid arguments like those from 'M$ drones', they are ignorant about these issues, and the best course of action is enligth them in such a way they can understand:
Look at IBM: they extensively use open source and it seems they are not going into bankrupcy anytime soon.
Look at Google: they critically use open source, they have an ashtounding computer-base all around the globe and still it doesn't seem like they are hacked everyday, do they?
You can ask a question *then*:
Look at IBM or at Google, or at almost every Fortune 100 out there; they do well using open source. Don't you find suspicious the only ones pesting about open source are companies (Microsoft and its VARs) that *do* would go bankrupcy if open source took the computer world for a raid?
"ok, how far have you got with that urgent stock control application?"
I'm either a project manager, in which case I don't have to answer such kind of questions, or I'm a project developer, in which case the productivity tools will show how far I got (number of code lines, diff/patches, new files, milestones achieved...) and I don't have to answer such questions either. If forced to answer such a question, my answer is usually "within timeframe" (if it's such the case, of course). And if I need to say "this feature will be in ten days, not in seven as you thought" to my boss, so I do.
"do you want me to add more comments?"
I'm really sorry about you. It seems you weren't lucky about your project managers *nor* you had the guts to look for them elsewere.
If it takes a week, it takes a week, no matter how do you order it (within bounds), but doing things in the proper order is your best safeward against momentary crazyness from your bosses (as in the case I firstly was answering to). If your boss is crazy on a full-time basis, it's time to test different waters because no matter what, you'll be spoiled (so going first for half-assed functionality isn't going to work for you in the long run eiter). Of course, in order to be chooser instead of chosen, you better are high on your job abilities.
"I have to admit that exchange is probably one of the best email servers out there"
What the f*???
I can admit it's a good integration/egroupwaring tool (though most of it becomes from the almost monopoly Ms Office detents); I could even admit it has some good MDA features, but... email server!!!??? It's almost pure shit!
It's buggy, overloaded and fragile, and if nowadays talks SMTP the way it should be it's only because it came late to the field (they tried to bastardize SMTP too, but luckily enough there already were some free source mates there to stop it).
Just as a proof: noone on his mind leaves an Exchange server open to the Internet (and I mean *only* the TCP port 25). Everybody will use a front end MTA (a *real* one, I mean, be it Sendmail, Postfix, Exim, Qmail... whatever); even if you are really an MS shop, you will have a "choke server", a "front end gateway" or whatever they call it these days.
"Once configured and running, exchange is pretty robust and predictable."
Yeah: you can predict with sureness it will bog down as soon as next spam attack reaches to it.
"Then real life gets in the way and your first gen mock up becomes live code (after the boss sees it - "but its working, why do you need to rewrite it...") and you curse yourself every time you open that code."
Who wrote the code? You!
You can be sure *you* are the one to blame, not your boss.
If you are working on a mockup GUI, be sure no functionallity is within the demo.
If you are working on a mockup funtional unit, be sure is terrifying ugly so no PHB will think it's ready.
When you are programming, as a general matter, first comes the comments, second the bound tests, third the functionality, and last (if needed) the API or the interface.
Not only you won't have to pass through the "compile? it's production, then", but your code quality will enhance almost without you noting.
"I am, even as I type this, taking a break from trying to deploy a PHP app to a different server than the one it was developped on, and the amount of fiddling required to get both installations of PHP to work in a compatible way is mind-numbing"
./config, make, make install run. The secret? They *know* their trade, if only because the steeper entry path of C+autotools that take away unfitted wannabies.
:("
What is mind-numbind is the hugh amount of completly lacking people who call themselves "php developers"; of course they are not "php developers" since they are not developers at all.
That's not exactly a demerit on the PHP side, since that means that people without almost the slighest programming acumen can produce some meritable (to an extent) things. It is a very good hobbyist language.
On the other hand, people with proper programming skills can make PHP behave properly too so we return again to paragraph one.
You would see exactly the same problems, only accrued programming multiplatform C still you can see vast amounts of software that gladly run on a dozen platforms after only a
"Turns out that PHP broke backwards compatibility again in its last version"
Turns out that PHP devels have a very nasty tendency to work that way so turns out a wise project manager or even a wise developer will stay away from PHP for any enterprise task; another hint about the experience and maturity of the development environment you are involved.
"please don't dismiss such a study just because its findings annoys us. We have a lot of improvement to do still.
The only finding that study shows is that on Microsoft camp almost even a monkey can come up with a half assed semiworking solution were you can't get even this on a unix-like environment. Not precisely big news.
On the other hand what the study doesn't talk about is how long each party can reach when a knowledgeable team puts their hands on one platform or the other.
Hint: one side will simply skyrocket the other on perfomance, stability and money.
Hint2: the one that will do doesn't come from Redmond.
"Our government needs to more clearly delineate what software can and cannot be patented"
The only clear (and positive) way is, in fact, very easy: "noone".
"In upgrading a mission critical MS Access database..."
And then I stopped reading.
"There's just no way to standardize the configuration of one single database"
Yes there is, an easy one. Vendors know it, still they don't want to produce it.
In case the vendors were not aware, I'll explain here:
*Go to three universities with reknowned IT areas expertise. Ask them to produce ten "Enterprise database case scenarios" so you have thirty of them.
*Pass an Slashdot-like poll to Fortune 500 DBa's so they can not only vote but pose their opinions too. Go again to the universities with the poll results so they can refine their test cases till the point ten of them sum up 80% of the votes.
*Invite whatever DB "vendors" (including of course open source ones too) to a closed door test with limited budget (say one million dollars per vendor; valuate the DBAs man/hour costs at the average from the Fortune 500 ones an the hardware and software by its front cover retail prices). Then allow them (within budget) to produce results on whatever the vendor-provided DBAs considered proper (say, two Oracle gurus working on their preferred 256 ways Suns, two Postgres hippies and a FreeBSD greybearded on a cluster of white brand boxes, half a dozen Windows architects on Ms Windows Enterprise Datacenter on a bunch of 16 ways DELLs... whatever) give them a two week time frame and compare the results.
You would say you are comparing apples to oranges, but all the parties worked within the same budget and time constrains and where allowed to bring whatever experts they considered proper to achieve better results so from the Fortune 500 standpoint is the clearest apples to apples comparation you can get.
Still, they don't want you to know.
Hey! your comment exactly mirror my experience on the *whole* Microsoft product portfolio from the last 15 years! (not that I'm surprised; if Microsoft policy has been one for about two decades and it made its owner the richest man in the world, why should they change it?)
"I'm simply saying that there's no 1 to 1, conversion-free or syntax-change-free way"
And then, the article is "simply saying" that while it might be no 1 to 1 conversion-free way, there is a 1 to 0.5 money free one (of course *when* such a move away is doable... warm regards to closed software lock-in strategies).
"PostGres and MySQL are pretty good but they currently lack load-balancing and data replication across multiple data centers."
Very good Mr Marketroid, but you didn't even read the post you are answering to.
Just to save you the work, the nut of it was:
You Can Program Those Lacking Features For A Fraction Of The Cost Of Going Oracle.
Clear enough?
"I was one of those scientists (worked in an academic research facility) for a while and my pay wasn't so bad..."
I bet you were not a scientist but a technocrat. An engineer if you so prefer. Not to mean anything bad about engineering or engineers, on contrary, I deem these efforts as most needed, but there's a difference between researching on new materials for making shorter transistors (something companies beef and longsigthed enough will pay for) and researching the living habits of a frog which overall population is 80 individuals in some obscure place in Africa.
"where's the motivation for new developers to go open source? Not everybody operates with an altruistic "I'm giving back to the community" motivation."
Then not everybody distributes their creations under a open source license.
Easy, isn't it?
And regarding your question, motivation for those that are not moved by the money they get by developing open source, the answer is easy too: "somewhere else".
"I genuinely don't understand why anyone would want to share the fundamentals of their creation in a way that would compromise any potential future earnings."
Still, most of the creation out of Human Spirit came in ways that "compromised future earnings".
Don't worry, it's simply you are not up to the highest standards of really creative souls.
"that only drives home the notion that there is no Linux OS"
Well, you have learnt at least one lesson then. You are right: there's no more "a Linux OS" than there is "a BSD OS", it seems you finally grasped the concept.
"Why do I need to upgrade to Debian Etch in order to run KDE 3.5? (...) I can run KDE 3.5 on FreeBSD 4.11, 5.5, and 6.1"
Because Debian's concept of "stability" (pay attention to this: DEBIAN's concept, nothing to do with Linux) is different than that from FreeBSD (pay attention to this: FREEBSD's concept, nothing to do with BSD), that's why; take it or leave it.
"Here's a pretty interesting thread by a BSD user who had to learn to use Debian at work and shares his experiences. He sums up the differences between FreeBSD and Debian quite nicely. Makes for an interesting read."
...but he absolutly "forgets" about what would had happen if he even tried to do something similar on FreeBSD:
Well, I already read the thread, and I can assure it doesn't "make for an intersting read", it doesn't "sum up the differences between FreeBSD and Debian" at any rate and probably the only interest in there is for a psychologist about the many ways the human mind manages to confuse itself.
Just a few points:
1) The author decides to give a try to Debian because FreeBSD doesn't support critical elements of his computer's hardware.
2) Then he populates the sources list with a nightmare of unofficial an unmatching repositories.
3) Then he concludes that Debian is not an "OS" but a bunch of unconnected packages, and that finding useful software is "a royal pain".
What happens if you even try to mix the ports tree from 5.x with 6.x to mix-and-match software from both branches (not to talk if you try to install *binary* packages from 5.x and 6.x at the same time)?
What happens if you even try to mix the ports tree from official FreeBSD with three or four partial ports trees from unofficial origins?
I'll tell you the answer: even if you are a FreeBSD guru you will have quite a hard day toying with CVS and customizing Makefiles to acomplish such a daunting task, still he manages to do it on Debian on his first weeks of usage with only minor headheaches but, hey! Debian is the "royal pain".
It's quite ashtonishing how the FreeBSD folk would send you happily to RTFM (quite good quality resources, I recognize) but then, as in this example, won't follow their very counsel when experimenting with a (for them) new OS; it's obvious he didn't go through the (quite good quality too) documentation at debian.org.
"I was merely pointing out that I find working on the CLI in BSD more comfortable than clicking widgets in Linux"
/etc/rc.conf in BSD to all the runlevel config files in Linux" ...out of ignorance.
So you were merely comparing apples to oranges.
"compare
Good work!
"Here's a pretty interesting thread by a BSD user who had to learn to use Debian at work and shares his experiences. He sums up the differences between FreeBSD and Debian quite nicely. Makes for an interesting read."
That really good make a difference from the rest of your post; I'll have a look at it.
"Yes, this is what I would think as well, but imagine you are a big insurance company (...) there seems to be a trend (see google data center post) that opposes intelligent use of computer resources as maybe SETI does."
0 6-November/msg00063.shtml
Don't think so. Banks, insurance companies and the like are not making such big profits by being dumb.
As an example here you have one of biggest Spanish banks using distributed computing for financial computations: https://lists.cs.wisc.edu/archive/condor-users/20
As they explain, the resulting reduction on cost per Gigaflop was from 44 to 4EUR over a standard SMP solution (big iron).
"Bottom line: they tried to listen to customers and failed as usual. Here's what I want to see in a phone"
Bottom line: for the most part YOU ARE NOT A MOTOROLA CUSTOMER. I don't know how is it in the USA, but I know most of the world mobile sales come from the operators which buy them in bulk for their offers (either prepay or contract packs) so the mobile builders will listen to their real customers, the operators. And the operators want you to download games and ringtones and they want you (in developed countries at least) to use their more expensive "multimedia" services. That's why you will have a hard day trying to find the phone *you* like instead of the phone the operators like.
"Style---no, it isn't important to most people. It's a phone."
That would be wrong *even* if the mobile builders would listen to you (which they are not doing, as I already explained). People *think* style is not importante to them, but the only reasonable path for them to tell it to the company is with their *money*. And it demonstrates one and again that on compulsory buying (and for the most part you buy a mobile out of eye-candyness or in a hurry) style is the most important selling factor. You can cry the hell out about how style is not important, but then if the "stylish" phone sells better by far than the "ugly" one what are sellers going to do?
About all the other "like" and "don't like" you just need to think they either would make the mobile more expensive, or more difficult to stand by FCC-like regulations, or doesn't really matter to them (it's more or less "neutral", like ergonomics on the UI: there're not so much people that buy a mobile after an extended exploration of the market offers, so for the most part by the time they discover they don't like the UI they already *payed* for it), or makes sense to their real customers (like the multimedia-related crap: good for the operators, or an excess on durability: bad for everybody but you; the builder wants to sell more units, the operators want to offer new services).