"...but perhaps it is whatever side of Korea Seuol is on"
Of course it is South Korea but then, why don't they say "South Korea". Please note that as to date, there's no country known as Korea, just as there's no state within USA known as Carolina. Why don't use its proper name, then?
"Basically, an homogeneous corporate network (all *NIX, all Windows, all Mac, etc) is great for administration, but horrid for security"
Yeah! That's why each and every cell on a state prision is different from the next ones. Being all of them equal with the same security mechanisms would be a security nigthmare!
It's good for you to bring back the "monoculture" paradigm, but don't forget evil lives in those pesky details. Any corporation is better secured by homogeneus systems (at least at the organizational unit level) *because* it is great for administration. On the other hand, what good brings your, say, workgroup fileservers being up when your workstations go nuts?
"It's irrelevant to the end user the technical reasons behind a crash"
So what? an uninformed opinion won't change the fact it is the OS's fault.
"they aren't going to test it on other systems to troubleshoot the fault, they'll simply find something else that works."
That's not my problem. They can choose the wrong choice ten times out of ten. I'll try to make a better choice and I'll be more productive, so that's OK to me.
"In general, the attitude of OSS..."
What the heck has any "OSS attitude" to be here? If OOo crashes Windows is Windows' fault. If it crashes Linux, is Linux' fault. It is not about OSS vs privative, it is about Operative Systems vs Apps, here.
All I said is that if your wanna know (please note the *if*) if you have the same problem on other operative systems, you should try other operative systems.
"It's the non-technical users that will ultimately decide if OSS is adopted or not"
Oh, for sure! those miriads of non-technical users are just going to come over me to say what I'll adopt.
Just the same they are doing now, won't they?
*I* am the one that simply want stuff that works. And since I am more savvy than the average non-technical, my choice is probably going to be more fitted to my interests than theirs, just exactly the same a professional taylor is going to choose a better jacket than me everything else being equal.
"Be fair - the microwave background was discovered accidentally"
And that's exactly the point. I think was Picasso the one who said "inspiration does exist, but she have to find you at work when she comes".
Penzias and Wilson did discover microwave background by accident because they were working on "extrange" and "non-profitting" fields. The only way to find things "by accident" is by looking where almost no people usually go, and that was exactly what labs "researching for the sake of resarching" did (like ol'IBM, Nixdorf or AT&T). Now, more and more "extrange research" goes only public founded or defense-related since bigger companies are too focused on next quarter results.
"I know, I work for one."
Good for you then. That doesn't mean it is as common as it were in the 50s to the 70s.
"My personal view is that Microsoft is terrible on points 1 and 3 whereas linux is terrible on points 2 and 4"
Your personal view is flawed.
Microsoft is terrible on points 1, 2, 3 and 4. Let's see:
1/ Aquiring the software: Microsoft isn't cheap, is it? It is not only that it isn't cheap, but it is a legal nigthmare to follow its lot of different license schemes. Of course, any suitable open source product is much better on this aspect.
2/ Paying someone to set it up. Of course, Microsoft doesn't pay for it. That Microsoft is easy to setup is nothing but a myth. Except on the most trivial scenarios (where any alternative is equally easy to set up) Microsoft products are *extremely* stubborn about how things have to be deployed. For the most part, it is the Microsoft way or no way. Any unix-like environment is much easier to set up the way it fits and much easier for automation and further maintenance. Probably a Microsoft-savvy monkey is cheaper than a seasoned unix sysadmin, but as you can learn for instance, on the recent article about Ms Exchange software alternatives, that kind of monkeys are much more expensive on the long run, since they can't do much more that click here and there on the wizzards with not too much knowledge about what's really going on. And then, a seasoned Microsoft sysadmin which, more or less, can develop and maintain a stable and functional environment (usually over a mountain of quite expensive hardware and a hill of not so cheap third-party software) is not any cheaper nor any more productive than a seasoned unix sysadmin, so there goes "IT worker" advantage.
3/ Maintaining software: Microsoft has an outstanding record regarding patches that break systems by introducing new bugs and non-desired behaviour changes. On the other hand it is popular knowledge you *will* have non-trivial problems when upgrading any major component (ie. a lot of short companies depend on Access apps that break each time Access is upgraded, for instance), and that upgrading any major component will lead inexorably to the upgrading of all the others on a short time-frame, so making point 1 even worse. Even "evilesque" companies like Oracle or -arrgghh... SCO have better records regarding maintainability, not to talk about the wider alternatives open source brings to this field.
4/ Desktop support: From the very beginning the non-told motto from Microsoft is "even a dumbass can use our products"; the net result is that Microsoft users tend to behave as dumbasses because of this very fact. Entry on Ms systems is quite easy but they don't promote users to learn how the system works (well, it is not that it would be of any use; after all, next version will behave quite differently from the end-user perspective), thus increasing desktop assistance costs on the long run. Again, any unix-like system promotes user's knowledge far more.
"I've never seen an unbiased survey on TCO including all these points. Its hard enough to get unbiased surveys."
All in all, the expectable results arising is that for a company without legacy systems, provided software that fits the needs is available, an open source unix-like solution is clearly the way to go, even without the need to make the numbers.
Of course, once your scenario is not as "pristine" as the one above, your mileage may vary.
"Open source software will never win out on point 2 (setup)"
Open source software already DO win on point 2 nine times out of ten; you surely are talking about what you ignore.
"The biggest set back to Linux now is that a beginner searches to web to find the following:"
We are talking here about professional/corporate environments. A beginner simply has no place here, and his opinions no weight.
"This discourages corporate adoption as CEOs..."
Second mistake. It is not about CEOs, it is about CIOs, and they should know better. Being a CIO an incompetent won't make Microsoft a better choice but only a most common choice by uncompetent people.
"Wikipedia is at best filled with commonly accepted myths and partial truths"
Just as any "dead trees" encyclopedia. In fact, that would be a rather good definition of encyclopedia: connundrum made out of commonly accepted myths and partial truths.
"In a lot of ways wikipedia is worse. If I post something to wikipedia that's factually incomplete or incorrect, it stays like that until someone changes it for better or for worse."
How can make that any worse? When an entry on an "standard" encyclopedia is factually incomplete or incorrect, it stays like that until only one side (the editor) wants to change it, for the better or the worse, and that will only happen on newer editions of the encyclopedia, while older will remain unchanged.
So, all in all, something like Wikipedia stands better as an encyclopedia than its paper counterparts (while you can probably dislike encyclopedias as a whole, which is a different issue: a really nasty odoring shit is better as a shit than a plastic madeon, but that won't make you like the original the more).
"one would have the freedom to release something GPL'd under a different, proprietary license."
For this to be able to be done, you should have the "freedom" about breaking the laws, since GPL doesn't allow you to do that. After all, hey! what kind of freedom you can have if you still have to stand by the laws?
Now, you can do what you want under the BSD license. Use BSD code all you want and develop as much BSD code as you fell OK with.
Others don't think BSD-like licenses is not the way to achieve freedom, so they pursue it by other means, i.e. the GPL license.
"Agreed, install Postfix, and hire yourself a competant Postfix admin for 10 hours/week (whether he works them or not)."
Go the other way around. Go and hire a competant sysadmin and pay him whatever he sees fit for installing Postfix+[POP | IMAP] server+explain to you basic administration, and then pay no more than 1 hour/week of day-to-day administration. If the one you want to hire doesn't like the bussiness you immediatly know he is not the person you want to installing the system: a properly installed e-mail server doesn't need more than half an hour/week to maintain (and I'm being generous), so if someone asks for much more than this, you know it is one that doesn't know how to properly server your bussiness.
Provided you have a stable fixed IP, host the e-mail server yourself.
You said you are a small company, but you haven't said what do you mean with "small".
Let's say 500 mail accounts. OK; let's say 1000 accounts.
Your easiest and safest bet is looking for a savvy Linux sysadmin/free lancer to implement it for you. Provided everything is in place (hardware, connection and your VISA card if you don't own an Internet Domain) it won't take more than two days (I'd say 5-10 hours of -relaxed, work). He will do the "hard tricks" (it is not so hard, really, it is only e-mail is VERY visible within a company, so mistakes hurt badly, as you surely now), and then 95% of daily administration can be delegated to you (maybe with the aid of a dirty hacked web interface), or even remotely managed by him (no more than ten minutes a day on average).
I for one do this for my clients, and it is probably the easiest service for me to have them satisfied about. Easy, efficient, secure and reasonably priced.
"Do reliable email hosts actually exist?" you questioned. Of course, it depends quite a bit on what you exactly mean with "reliable" but, yes, they exist to the (definable) extent you need, and it is probably easier and cheaper to hold it within your own company than you seem to believe.
Oh, my god! Too much effort, I'm a lazy sysadmin (creative lazyness is a virtue on a sysadmin, not a sin).
Just have a look at cron-apt and you'll forget about your daily apt-get update && apt-get upgrade. You just will recieve an e-mail when something is waiting for you to upgrade.
"Well, boss, we're having problems with Linux at our datacenter, but don't worry, I can go on IRC and ask someone to help me."
Terribly different from "Well, boss we're having problems with Linux at our datacenter, but don't worry, I can go to Red Hat's support and ask someone to help me."
Specially when going to Red Hat's support is GUARANTEED you will be talking with a first tier support drone, at least on the begining while chances are, if you know your work, that you can talk to the problematic program's AUTHOR, LIVE, on the proper IRC channel.
That PHBs don't like "free support" doesn't make it less valuable regarding its technical foundations.
1/ I didn't read the letter. It is too much time ago that Darl McBride can write something of my interest. You can't be a bitch for a couple of years and then wanting your reputation being that of a virgin.
2/ As it already has been stated, probably "manual" cracking migth be well under 1% of all cracking attempts (bots, script kiddies, worms, viruses), so *all* unix-like (both Unix (TM), Linux, *BSD, etc.) are probably statistically neglectable when talking about cracking as a general matter. That means not only that McBride's talking is uninteresting because it comes from McBride, but that forgetting about who comes it from, he is talking about something as interesting as say, Sahara's UV lamps market.
3/ Even if we forget this comes from an uninteresting guy, talking about a non-issue, what he says is "Linux, accounting for 65.64% of all hacker breaches reported". Since Linux is well above 65.64% of all open-to-the-internet unix-like systems, what McBride is really telling is chances for a Linux system to be cracked are LESS than that of the other unix-like systems.
I told it from the very beginning: McBride is long ago out of interest. Letters like this are of course not going to make him any better.
"Thus, you are locked-in to Trolltech, because you are dependent on Trolltech-controlled protocols."
No, you aren't. You are only somehow "locked" to Qt as long as you yourself "lock" your own clients (which seems to me quite a reasonable situation). If you distribute your code under the GPL, you are bound to GPL Qt. Would Troll Tell decide to do something "nasty" with a future version of Qt, you are free to modify Qt (as per the GPL) in any way you see fit.
Even if you are distributing proprietary software linked to Qt libraries, you are not bound to any future Troll Tech development: you are only bound to your current agreement with Troll Tech, regarding current Qt libraries, which are the ones you use with your code, and which you already decieded was OK with you.
This is quite different from say, Microsoft lock in. Only Microsoft can further develop any Microsoft-controlled API while ANYONE can further develop Qt- dependant API, at least under GPL, so if your -even proprietary, software is distributed respecting Qt's GPL (by making only "normal" system calls to Qt libraries or Qt-dependant code, for instance) you can rest assured Troll Tech will never be able to lock you in.
"The GPL doesn't force all software using the libraries to be GPL software"
Yes, it does. As long as you distribute it, it must be GPL.
"It forces all software distributed with the GPL libraries to be GPL software."
No, it doesn't. It forces all software distributed to be GPL, full stop.
It is both the letter and the spirit of the GPL to be so.
You need LGPL libraries if you want to distribute non-GPL software linked to them. That's why LGPL exists in first place.
All the Indiana schools would be considered "within the organization" so as long as they don't send out a CD to their students with GPL Qt and Proprietary-App-Of-Choice both together, they'll be fine."
It is not Indiana schools the ones at stake, but the proprietary software vendor: Indiana schools would be in their perfect right to ask the vendor for the source code of the sold product, which the vendor doesn't want to distribute or it shouldn't have sold it under a proprietary license to begin with.
"This is the same way that nVidia gets away with binary kernel modules"
No, it is not. The "COPYING" file distributed with each and every source of the kernel clearly states:
"NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work"."
nVidia and the like use a "trick" to stay within license terms: they provide a GPL "wrap" module to interface the kernel and then they just use "kernel services [as provided by the open source module] by normal system calls" from their proprietary drivers.
FSF probably doesn't agree with this understandment of the GPL, FSF is not copyright holder of the Linux kernel code, so anyway it has nothing to say about.
"Therefore, when you download and install them, you aren't distributing anything proprietary linked with GPL code."
So what? The problem is not me breaking the GPL, but the one that distributes software TO me. Should it be under GPL violation, I would be able to ask my distributor for the source code of such software.
"Of course, that means if you sell a computer with Linux and the nVidia drivers pre-installed, you've broken the GPL"
Non-sense. nVidia drivers are developed in such a way not to break the GPL (nVidia obviously distributes nVidia drivers which work with the Linux kernel, if this were a GPL violation, even Linus Torvalds would be able to ask nVidia for the drivers' source, no to talk about each and every people that recieved the code from nVidia).
"...and probably nVidia's licence also."
nVidia binary drivers license clearly states that you shouldn't redistribute them so it is not "probably" but "surely", unless you hold an special agreement from nVidia.
True enough: that's the word I was looking for (I'm sorry, I'm not English spoken and sometimes my vocabulary fails me).
Now, once this has been stated, my post thesis remains the same: since you need your developer's craftmanship, it is clear there should be (at least) some times when you can't change one expert with ten rookies, just the same than with any other craftmanship.
"The main point here though is that it doesn't matter quite so much if an average craftsman or brilliant craftsman builds your chair, what matters is who designed the chair. If you design the chair well, then that design includes very specific instructions on how to build the chair. Given that sort of specified design a master craftsman and me with the right tools are not going to make an appreciably different looking chair."
And that's what make software ingeneering quite a different beast. Here the DESIGN is the product.
Ikea surely hires quite expensive designers so their chairs are high quality regarding their design requeriments about modularity, inexpensivity, formal lines, etc. Then, truly enough, no matter who mounts the chair, it is going to look just the same. But then, in the case of software, the design IS the implementation, the programmer is the chair designer, and you become... well, the cp command. And that makes the difference. Even if we consider the different roles between the software architect and the junior developer, even from the junior developer much more knowledge is expected that just "take screw 1a and put into 1A hole mounting Arm A into Leg 1" and it seems this isn't going to change in the near future (we COULD formalice COBOL so much that even machines could sput standard code -more or less like you being able to mount an Ikea chair, problem is noone uses COBOL now for new developments. Maybe in twenty years, Java and Java projects will be so well known we will have the ever-promised CASE tools The Way It Should Be, at least for "standard" projects, but hey, then nobody will be programming Java anyway so, again, you will have to depend on humans -and their talent, from the engineer to the junior devel again).
"You want the best programmers, no question. A great programmer is EASILY 4 times as efficient as a mediocre one (as his numbers suggest), and isn't 4 times as expensive (the unstated part)."
And then, there is another unstated part (on your side). Currently programming is more an art than a technology (while most of the dislike it), and when you go on that kind of things, number cannot superseed quality. Just the same you can't have a Michelangelo's Moses just hiring ten average sculptors instead of one true Michelangelo, you can't get the amazing results one guru can offer you changing him with a dozen code monkeys.
Well, Michelangelo's example can be a bit of overrating. Now, you won't hire a fresh-from-the-academy pilot to test the last Grumman fighter no matter how cheap he is since you know that, no matter how well he knows the theory, you need a seasoned veteran for experimental flights. But then, any software project is an experimental project since you never build exactly the same software twice (quite extrange for an engineering: you can build twice the same building, even exactly -and even then you need a proper architect to tell you that indeed it is feasible to use the same plans, but you won't build the same program twice -you would copy it instead).
Just to tell it shortly: in order to produce software you are better using talent, and talent can't be subtituted with masses.
Your pet theory is just what TFA told you first: It seems cheaper as the per-hour rate to choose cheap proffesionals, but you will end up better choosing good professionals -even if you are not specially interested about having a good job done.
That makes take gurus for arch/developing; take good graph/ergo people for the interface (while the programmers would probably be able to develop a decent UI -kindof), etc....and specilly, take a seasoned tough project manager to link all of them and to know when a professional is a good professional an when is just a mock up, and to know when things that look good on paper are just nonsense in reality (like your "Formally specify all user-visible behavior by writing the complete user documentation before the first line of code gets written" assertion, for instance).
Slashdot Mirror
"The worst thing to do is to think you are smarter than your users and artificially limit them..."
On the other hand, that's what Microsoft has been doing for more than a decade.
"...but perhaps it is whatever side of Korea Seuol is on"
Of course it is South Korea but then, why don't they say "South Korea". Please note that as to date, there's no country known as Korea, just as there's no state within USA known as Carolina. Why don't use its proper name, then?
"Basically, an homogeneous corporate network (all *NIX, all Windows, all Mac, etc) is great for administration, but horrid for security"
Yeah! That's why each and every cell on a state prision is different from the next ones. Being all of them equal with the same security mechanisms would be a security nigthmare!
It's good for you to bring back the "monoculture" paradigm, but don't forget evil lives in those pesky details. Any corporation is better secured by homogeneus systems (at least at the organizational unit level) *because* it is great for administration. On the other hand, what good brings your, say, workgroup fileservers being up when your workstations go nuts?
"It's irrelevant to the end user the technical reasons behind a crash"
So what? an uninformed opinion won't change the fact it is the OS's fault.
"they aren't going to test it on other systems to troubleshoot the fault, they'll simply find something else that works."
That's not my problem. They can choose the wrong choice ten times out of ten. I'll try to make a better choice and I'll be more productive, so that's OK to me.
"In general, the attitude of OSS..."
What the heck has any "OSS attitude" to be here? If OOo crashes Windows is Windows' fault. If it crashes Linux, is Linux' fault. It is not about OSS vs privative, it is about Operative Systems vs Apps, here.
All I said is that if your wanna know (please note the *if*) if you have the same problem on other operative systems, you should try other operative systems.
"It's the non-technical users that will ultimately decide if OSS is adopted or not"
Oh, for sure! those miriads of non-technical users are just going to come over me to say what I'll adopt.
Just the same they are doing now, won't they?
*I* am the one that simply want stuff that works. And since I am more savvy than the average non-technical, my choice is probably going to be more fitted to my interests than theirs, just exactly the same a professional taylor is going to choose a better jacket than me everything else being equal.
"If the same app crashs the system all the time when others you use don't, it is an application problem since it renders the application unusable."
No matter what you think, when the system crashes is an OS problem. No app is able to crash a proper designed and implemented OS.
On the other hand, you migth have a try to that very same OOo version on that machines... over Linux. Then you could see if it crashes or it doesn't.
"I suspect just "OpenOffice" would have more mindshare for this very reason"
Do you think they like OpenOffice.Org?
But there is the "little" problem, Open Office is already a Trade Mark, as the OOo people learnt only too late, thus the OOo thingie.
"A regular encyclopedia is produced by a respected publisher"
No, it isn't. It is the encyclopedia the one that brings respect to its publisher, provided it earns it, not the other way around.
But then, Wikipedia is in just the same situation.
"the guy said INVENT stuff not copy it..."
Do you really think the fact THEY INVENTED IT will stop OUR PATENT LAWYERS to go after them?
"Be fair - the microwave background was discovered accidentally"
And that's exactly the point. I think was Picasso the one who said "inspiration does exist, but she have to find you at work when she comes".
Penzias and Wilson did discover microwave background by accident because they were working on "extrange" and "non-profitting" fields. The only way to find things "by accident" is by looking where almost no people usually go, and that was exactly what labs "researching for the sake of resarching" did (like ol'IBM, Nixdorf or AT&T). Now, more and more "extrange research" goes only public founded or defense-related since bigger companies are too focused on next quarter results.
"I know, I work for one."
Good for you then. That doesn't mean it is as common as it were in the 50s to the 70s.
"My personal view is that Microsoft is terrible on points 1 and 3 whereas linux is terrible on points 2 and 4"
Your personal view is flawed.
Microsoft is terrible on points 1, 2, 3 and 4. Let's see:
1/ Aquiring the software: Microsoft isn't cheap, is it? It is not only that it isn't cheap, but it is a legal nigthmare to follow its lot of different license schemes. Of course, any suitable open source product is much better on this aspect.
2/ Paying someone to set it up. Of course, Microsoft doesn't pay for it. That Microsoft is easy to setup is nothing but a myth. Except on the most trivial scenarios (where any alternative is equally easy to set up) Microsoft products are *extremely* stubborn about how things have to be deployed. For the most part, it is the Microsoft way or no way. Any unix-like environment is much easier to set up the way it fits and much easier for automation and further maintenance. Probably a Microsoft-savvy monkey is cheaper than a seasoned unix sysadmin, but as you can learn for instance, on the recent article about Ms Exchange software alternatives, that kind of monkeys are much more expensive on the long run, since they can't do much more that click here and there on the wizzards with not too much knowledge about what's really going on. And then, a seasoned Microsoft sysadmin which, more or less, can develop and maintain a stable and functional environment (usually over a mountain of quite expensive hardware and a hill of not so cheap third-party software) is not any cheaper nor any more productive than a seasoned unix sysadmin, so there goes "IT worker" advantage.
3/ Maintaining software: Microsoft has an outstanding record regarding patches that break systems by introducing new bugs and non-desired behaviour changes. On the other hand it is popular knowledge you *will* have non-trivial problems when upgrading any major component (ie. a lot of short companies depend on Access apps that break each time Access is upgraded, for instance), and that upgrading any major component will lead inexorably to the upgrading of all the others on a short time-frame, so making point 1 even worse. Even "evilesque" companies like Oracle or -arrgghh... SCO have better records regarding maintainability, not to talk about the wider alternatives open source brings to this field.
4/ Desktop support: From the very beginning the non-told motto from Microsoft is "even a dumbass can use our products"; the net result is that Microsoft users tend to behave as dumbasses because of this very fact. Entry on Ms systems is quite easy but they don't promote users to learn how the system works (well, it is not that it would be of any use; after all, next version will behave quite differently from the end-user perspective), thus increasing desktop assistance costs on the long run. Again, any unix-like system promotes user's knowledge far more.
"I've never seen an unbiased survey on TCO including all these points. Its hard enough to get unbiased surveys."
All in all, the expectable results arising is that for a company without legacy systems, provided software that fits the needs is available, an open source unix-like solution is clearly the way to go, even without the need to make the numbers.
Of course, once your scenario is not as "pristine" as the one above, your mileage may vary.
"Open source software will never win out on point 2 (setup)"
Open source software already DO win on point 2 nine times out of ten; you surely are talking about what you ignore.
"The biggest set back to Linux now is that a beginner searches to web to find the following:"
We are talking here about professional/corporate environments. A beginner simply has no place here, and his opinions no weight.
"This discourages corporate adoption as CEOs..."
Second mistake. It is not about CEOs, it is about CIOs, and they should know better. Being a CIO an incompetent won't make Microsoft a better choice but only a most common choice by uncompetent people.
"Wikipedia is at best filled with commonly accepted myths and partial truths"
Just as any "dead trees" encyclopedia. In fact, that would be a rather good definition of encyclopedia: connundrum made out of commonly accepted myths and partial truths.
"In a lot of ways wikipedia is worse. If I post something to wikipedia that's factually incomplete or incorrect, it stays like that until someone changes it for better or for worse."
How can make that any worse? When an entry on an "standard" encyclopedia is factually incomplete or incorrect, it stays like that until only one side (the editor) wants to change it, for the better or the worse, and that will only happen on newer editions of the encyclopedia, while older will remain unchanged.
So, all in all, something like Wikipedia stands better as an encyclopedia than its paper counterparts (while you can probably dislike encyclopedias as a whole, which is a different issue: a really nasty odoring shit is better as a shit than a plastic madeon, but that won't make you like the original the more).
"one would have the freedom to release something GPL'd under a different, proprietary license."
For this to be able to be done, you should have the "freedom" about breaking the laws, since GPL doesn't allow you to do that. After all, hey! what kind of freedom you can have if you still have to stand by the laws?
Now, you can do what you want under the BSD license. Use BSD code all you want and develop as much BSD code as you fell OK with.
Others don't think BSD-like licenses is not the way to achieve freedom, so they pursue it by other means, i.e. the GPL license.
"Exchange can be complicated if you want it to be, but once it is set up, it should run smooth as silk."
How many of your clients were using say, Kmail or Evolution through IMAP, for instance?
"Agreed, install Postfix, and hire yourself a competant Postfix admin for 10 hours/week (whether he works them or not)."
Go the other way around. Go and hire a competant sysadmin and pay him whatever he sees fit for installing Postfix+[POP | IMAP] server+explain to you basic administration, and then pay no more than 1 hour/week of day-to-day administration. If the one you want to hire doesn't like the bussiness you immediatly know he is not the person you want to installing the system: a properly installed e-mail server doesn't need more than half an hour/week to maintain (and I'm being generous), so if someone asks for much more than this, you know it is one that doesn't know how to properly server your bussiness.
Provided you have a stable fixed IP, host the e-mail server yourself.
You said you are a small company, but you haven't said what do you mean with "small".
Let's say 500 mail accounts. OK; let's say 1000 accounts.
Your easiest and safest bet is looking for a savvy Linux sysadmin/free lancer to implement it for you. Provided everything is in place (hardware, connection and your VISA card if you don't own an Internet Domain) it won't take more than two days (I'd say 5-10 hours of -relaxed, work). He will do the "hard tricks" (it is not so hard, really, it is only e-mail is VERY visible within a company, so mistakes hurt badly, as you surely now), and then 95% of daily administration can be delegated to you (maybe with the aid of a dirty hacked web interface), or even remotely managed by him (no more than ten minutes a day on average).
I for one do this for my clients, and it is probably the easiest service for me to have them satisfied about. Easy, efficient, secure and reasonably priced.
"Do reliable email hosts actually exist?" you questioned. Of course, it depends quite a bit on what you exactly mean with "reliable" but, yes, they exist to the (definable) extent you need, and it is probably easier and cheaper to hold it within your own company than you seem to believe.
"For my server (Debian):
apt-get update
apt-get upgrade"
Oh, my god! Too much effort, I'm a lazy sysadmin (creative lazyness is a virtue on a sysadmin, not a sin).
Just have a look at cron-apt and you'll forget about your daily apt-get update && apt-get upgrade. You just will recieve an e-mail when something is waiting for you to upgrade.
"Well, boss, we're having problems with Linux at our datacenter, but don't worry, I can go on IRC and ask someone to help me."
Terribly different from "Well, boss we're having problems with Linux at our datacenter, but don't worry, I can go to Red Hat's support and ask someone to help me."
Specially when going to Red Hat's support is GUARANTEED you will be talking with a first tier support drone, at least on the begining while chances are, if you know your work, that you can talk to the problematic program's AUTHOR, LIVE, on the proper IRC channel.
That PHBs don't like "free support" doesn't make it less valuable regarding its technical foundations.
1/ I didn't read the letter. It is too much time ago that Darl McBride can write something of my interest. You can't be a bitch for a couple of years and then wanting your reputation being that of a virgin.
2/ As it already has been stated, probably "manual" cracking migth be well under 1% of all cracking attempts (bots, script kiddies, worms, viruses), so *all* unix-like (both Unix (TM), Linux, *BSD, etc.) are probably statistically neglectable when talking about cracking as a general matter. That means not only that McBride's talking is uninteresting because it comes from McBride, but that forgetting about who comes it from, he is talking about something as interesting as say, Sahara's UV lamps market.
3/ Even if we forget this comes from an uninteresting guy, talking about a non-issue, what he says is "Linux, accounting for 65.64% of all hacker breaches reported". Since Linux is well above 65.64% of all open-to-the-internet unix-like systems, what McBride is really telling is chances for a Linux system to be cracked are LESS than that of the other unix-like systems.
I told it from the very beginning: McBride is long ago out of interest. Letters like this are of course not going to make him any better.
Well, you just need to remember that in Soviet Russia white Linux machines NAKE and PETRIFY YOU!!!
"Thus, you are locked-in to Trolltech, because you are dependent on Trolltech-controlled protocols."
No, you aren't. You are only somehow "locked" to Qt as long as you yourself "lock" your own clients (which seems to me quite a reasonable situation). If you distribute your code under the GPL, you are bound to GPL Qt. Would Troll Tell decide to do something "nasty" with a future version of Qt, you are free to modify Qt (as per the GPL) in any way you see fit.
Even if you are distributing proprietary software linked to Qt libraries, you are not bound to any future Troll Tech development: you are only bound to your current agreement with Troll Tech, regarding current Qt libraries, which are the ones you use with your code, and which you already decieded was OK with you.
This is quite different from say, Microsoft lock in. Only Microsoft can further develop any Microsoft-controlled API while ANYONE can further develop Qt- dependant API, at least under GPL, so if your -even proprietary, software is distributed respecting Qt's GPL (by making only "normal" system calls to Qt libraries or Qt-dependant code, for instance) you can rest assured Troll Tech will never be able to lock you in.
"The GPL doesn't force all software using the libraries to be GPL software"
Yes, it does. As long as you distribute it, it must be GPL.
"It forces all software distributed with the GPL libraries to be GPL software."
No, it doesn't. It forces all software distributed to be GPL, full stop.
It is both the letter and the spirit of the GPL to be so.
You need LGPL libraries if you want to distribute non-GPL software linked to them. That's why LGPL exists in first place.
All the Indiana schools would be considered "within the organization" so as long as they don't send out a CD to their students with GPL Qt and Proprietary-App-Of-Choice both together, they'll be fine."
It is not Indiana schools the ones at stake, but the proprietary software vendor: Indiana schools would be in their perfect right to ask the vendor for the source code of the sold product, which the vendor doesn't want to distribute or it shouldn't have sold it under a proprietary license to begin with.
"This is the same way that nVidia gets away with binary kernel modules"
No, it is not. The "COPYING" file distributed with each and every source of the kernel clearly states:
"NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work"."
nVidia and the like use a "trick" to stay within license terms: they provide a GPL "wrap" module to interface the kernel and then they just use "kernel services [as provided by the open source module] by normal system calls" from their proprietary drivers.
FSF probably doesn't agree with this understandment of the GPL, FSF is not copyright holder of the Linux kernel code, so anyway it has nothing to say about.
"Therefore, when you download and install them, you aren't distributing anything proprietary linked with GPL code."
So what? The problem is not me breaking the GPL, but the one that distributes software TO me. Should it be under GPL violation, I would be able to ask my distributor for the source code of such software.
"Of course, that means if you sell a computer with Linux and the nVidia drivers pre-installed, you've broken the GPL"
Non-sense. nVidia drivers are developed in such a way not to break the GPL (nVidia obviously distributes nVidia drivers which work with the Linux kernel, if this were a GPL violation, even Linus Torvalds would be able to ask nVidia for the drivers' source, no to talk about each and every people that recieved the code from nVidia).
"...and probably nVidia's licence also."
nVidia binary drivers license clearly states that you shouldn't redistribute them so it is not "probably" but "surely", unless you hold an special agreement from nVidia.
"Programming is NOT art [...] It's a craft."
True enough: that's the word I was looking for (I'm sorry, I'm not English spoken and sometimes my vocabulary fails me).
Now, once this has been stated, my post thesis remains the same: since you need your developer's craftmanship, it is clear there should be (at least) some times when you can't change one expert with ten rookies, just the same than with any other craftmanship.
"The main point here though is that it doesn't matter quite so much if an average craftsman or brilliant craftsman builds your chair, what matters is who designed the chair. If you design the chair well, then that design includes very specific instructions on how to build the chair. Given that sort of specified design a master craftsman and me with the right tools are not going to make an appreciably different looking chair."
And that's what make software ingeneering quite a different beast. Here the DESIGN is the product.
Ikea surely hires quite expensive designers so their chairs are high quality regarding their design requeriments about modularity, inexpensivity, formal lines, etc. Then, truly enough, no matter who mounts the chair, it is going to look just the same. But then, in the case of software, the design IS the implementation, the programmer is the chair designer, and you become... well, the cp command. And that makes the difference. Even if we consider the different roles between the software architect and the junior developer, even from the junior developer much more knowledge is expected that just "take screw 1a and put into 1A hole mounting Arm A into Leg 1" and it seems this isn't going to change in the near future (we COULD formalice COBOL so much that even machines could sput standard code -more or less like you being able to mount an Ikea chair, problem is noone uses COBOL now for new developments. Maybe in twenty years, Java and Java projects will be so well known we will have the ever-promised CASE tools The Way It Should Be, at least for "standard" projects, but hey, then nobody will be programming Java anyway so, again, you will have to depend on humans -and their talent, from the engineer to the junior devel again).
"You want the best programmers, no question. A great programmer is EASILY 4 times as efficient as a mediocre one (as his numbers suggest), and isn't 4 times as expensive (the unstated part)."
And then, there is another unstated part (on your side). Currently programming is more an art than a technology (while most of the dislike it), and when you go on that kind of things, number cannot superseed quality. Just the same you can't have a Michelangelo's Moses just hiring ten average sculptors instead of one true Michelangelo, you can't get the amazing results one guru can offer you changing him with a dozen code monkeys.
Well, Michelangelo's example can be a bit of overrating. Now, you won't hire a fresh-from-the-academy pilot to test the last Grumman fighter no matter how cheap he is since you know that, no matter how well he knows the theory, you need a seasoned veteran for experimental flights. But then, any software project is an experimental project since you never build exactly the same software twice (quite extrange for an engineering: you can build twice the same building, even exactly -and even then you need a proper architect to tell you that indeed it is feasible to use the same plans, but you won't build the same program twice -you would copy it instead).
Just to tell it shortly: in order to produce software you are better using talent, and talent can't be subtituted with masses.
"My pet theory"
...and specilly, take a seasoned tough project manager to link all of them and to know when a professional is a good professional an when is just a mock up, and to know when things that look good on paper are just nonsense in reality (like your "Formally specify all user-visible behavior by writing the complete user documentation before the first line of code gets written" assertion, for instance).
Your pet theory is just what TFA told you first: It seems cheaper as the per-hour rate to choose cheap proffesionals, but you will end up better choosing good professionals -even if you are not specially interested about having a good job done.
That makes take gurus for arch/developing; take good graph/ergo people for the interface (while the programmers would probably be able to develop a decent UI -kindof), etc.