Thanks for the one-sided argument. I could just as easily speculate that proprietary solutions work better from day one so mods and bug fixes aren't required. I have no evidence to support the statement, but it's no different than assuming that a) mods exist that could save "several man hours a week" b) that somebody actually makes the required mods and c) that those mods actually make it into the official release of the software and c) the small business user is aware that the mod is available.
The only point you made that doesn't require "cherry-picking" the scenario is the one about having to upgrade to a new OS when buying a new computer. On the other hand, you could lease a computer with Windows 95 on it as recently as 2 years ago, so there are other options.
Risk management is one factor to consider, but not the only one and you have to look at risk comprehensively, not just focusing on a single issue. Even if you do end up paying more for your software due to the lock-in, it may turn out that it's still a better economic decision even for the long term. It seems to me that many who are anti-proprietary tend to exaggerate the economic importance of things like vendor lock-in relative to overall business economics.
One should also keep in mind that for some businesses "accepting the pain NOW" may not be economically feasible. I could have saved a bundle on my house if I had paid cash for it, but I didn't have the cash.
"If you can think of a situation where choosing to reduce your options and increase your overhead makes sense for your business, then you get an A+ for Creative Writing."
Limiting options is a very effective way of managing the complexity of any endeavor, including running a business. In any case, F/OSS advocates don't really believe in increasing options, just eliminating companies like MS as an option.
As far as cost is concerned, you have to take a detailed look at each business situation. Sometimes the "lock-in" solution ends up being the most cost effective one, sometimes not. Zealots never want to do the real analysis, they just throw slogans and insults at you.
I guess you are responding on my comment about ugliness of design, not the average business person's disinterest in programming.
Sure, when you're creating a kind of boilerplate application that is similar to millions of others, there's a lot to leverage to get the job done, but when your application doesn't quite fall along the well-beaten path, things aren't so easy. Even for the common application patterns there are often well defined frameworks that eliminate much of the "glue" code from your project which results in a cleaner design.
I don't know why some F/OSS supporters seem to believe that code libraries and code reuse originated with GNU. Code libraries have been around for more than 30 years.
"Saying philosophy has no place in business if it doesn't pay off over night is idiotic"
I agree, which is why I never made such a statement. All philosophies are not equal, however, in an ethical or in a business sense. It's hard to imagine how avoiding vendor lock-in could be a key philosophy that would make the difference between being successful or being a failure.
"Many businesses exist today because they had or have some philosophy behind them and many have fallen or are falling due to lack of them."
I agree, but many of those philsophies that helped companies succeed are ones that you might very well disapprove of. No doubt MS has a philosophy that has made it very successful.
The vast majority of small businesses aren't going to be able or willing to write a single line of a PHP script let alone writing custom code to glue it all the together (which is a pretty ugly way to design a system anyway). Most of those people have as much interest in computer programming as they do with the finer points of ball-bearing design.
If the F/OSS community follows your philosophy, proprietary software will remain dominant in the small business sector for many, many years to come.
You can't just invoke the word philosophy and expect everyone to stop thinking. There's nothing unethical about getting locked in to a single vendor if it makes sense for your business. If your philosophy doesn't believe that the "bottom line" is key element in business, than your business will most probably fail.
It's OK to have a failing business and it's OK to have a philosophy that rejects basic principles of business, but philosophies get disconnected from real life when an individual's profession is in fundamental opposition to his philosophy.
Hey, that's great if you strap a CD player or laptop to your body when you go jogging. A lock-in, of course, applies to devices in the same class. Which devices that are direct competitors of the iPod can play iTunes downloads?
The vast majority of itunes users download songs to play on their iPods, not their PC, not CD's. Those people are locked in to the iPod, but that doesn't stop them from buying one. So, I say once again: Vendor lock-in is working pretty well for the iPod and thus lock-in is not currently a big liability in the marketplace.
Yes, if you don't buy anything from iTunes to play on your iPod, you won't fall victim to the lock-in. But the topic wasn't your personal way of using the iPod. Many people buy songs from iTunes and are thus locked-in to the iPod. So the general statement holds: Vendor lock-in is working pretty well for the iPod.
Well, one can know everything about Linux and Windows security without being a power user in either one. Security is only one aspect for evaluating OS's.
When I was working on military infosec systems, we weren't even allowed to use standard OS's for secure encryption, so neither Windows nor Linux could have been used.
I've never met anyone who has "power user" skill levels on both Windows and Linux. I have noticed that some Linux users talk as if Windows == Win95 though. Those individuals obviously don't qualify on the Windows side.
First of all, most embedded systems don't use the same processors as non-embedded systems. They often use microcontrollers that provide additional peripherals in a compact package. Secondly, choosing the appropriate processor is a key element of most embedded designs. Thirdly, even though embedded systems use CPUs that can be used for a variety of purposes, that doesn't make those systems general purpose.
Sure, at a very low level all computer applications do the same sort of things, but embedded product design isn't done at that level. There are real, significant differences between the goals of specific embedded systems and those of general purpose computer systems. Ignoring those differences will make it much harder to successfuly design, build, and sell your product.
I wasn't trying to suggest that a lot of small business use ccmail, but rather illustrate that real-mode Windows can be very unstable with poorly written applications.
"An embedded system usually IS a general purpose computing device. That is, most of them are built from a few standard components and are driven by a generic CPU with custom software and/or firmware."
That's not what I would call "general purpose". That definition would cover everything with a microprocessor from a toaster to a high-end server. Embedded systems generally have a purpose that is more limited in scope.
"A large research lab or skunkworks is, perhaps, technically a business but the engineers are seldom concerned with practical business matters. That's someone else's departments. And, of course, there are universities, etc"
Research labs and universities don't typically perform product development, so when we say engineers solve real-world problems, we aren't really talking about those folks.
"This is true, but it's doubtful that someone who was planning such an application would be posting to Ask Slashdot on how to find the appropriate hardware."
I think asking for help from Slashdot isn't a great idea in general, but I don't think you can really infer anything about his project simply on the basis that he asked the question here.
"It's reasonable to assume that, whatever the device in question actually is, it involves general purpose computing/manipulation of data.."
Well, it would be more reasonable to assume that if the discussion wasn't about embedded systems which aren't considered general purpose devices.
"Engineers may design systems to solve problems but business men create buisnesses to make money, and Linux can be an important part of that."
There really isn't much serious engineering product design going on outside the context of a business, so when engineers talk of "solving problems in the real world", business considerations are naturally part of the problem. Not all embedded systems require an OS and those that do may find that an OS that wasn't designed from the ground up to be embedded (Linux, Windows CE, etc) may be inadequate or too bloated to be appropriate. Linux is certainly worth considering, but as I said before, the requirements of the project should drive the selection (and one of those requirements could be cost which would favor Linux over many other OS's).
I once worked at a company that used Lotus ccmail (yuck). It could bring down every Windows 95/98/ME computer on the network at any time. I was using Windows NT, so all ccmail did on my machine was crash itself.
"Perhaps someone who's posting a piece on how they've had no trouble installing/running Vista has their own agenda?"
Perhaps someone who's posting a piece on how they've had no trouble installing/running Linux has their own agenda as well. Or not. The point is that on Slashdot saying something postive about MS is instantly suspect, but saying something postive about Linux isn't.
This is disappointing because nerds are supposed to be about logic and critical/scientific thinking, but we can be as blind as the worst sports fans when it comes to our sacred choices of technologies.
If a company uses a computer so rarely that instability is not an issue, than they could probably get along with Windows 95 or 98. On the other hand, if the computer is used as integral part of their business, then buying a new computer with a more stable OS is a very cheap way to increase the efficiency of your business.
If a technology company uses a high percentage of Windows 95 computers, however, something is deeply wrong.
Stripped-down C compilers have been available for the 8051 since the mid-eighties, so I doubt that that is keeping anyone for migrating an application away. I think the dirty-cheap cost, the simplicity of its basic design, the many variations available, and the body of knowledge for using it is what keeps the 8051 in the game.
Some things have changed, however. In the old days the 8051 was usually the main processor even in a fairly complex embedded system. Now it is more likely to be used to implement a sub-function with a more powerful microcontroller/microprocessor acting as the primary intelligence.
"Umm, no. Intel is a chip company. They've tried hard to become a hardware company, but haven't succeeded, as yet. VERY few systems ship with true intel motherboards."
I guess what you mean is taht Intel wants to become a PC system company. Chip companies are hardware companies to a much larger degree than Apple, Dell etc.
S"tupid lock-in by corporations will continue to fail, as consumers won't buy locked products."
Perhaps you mean it will start to fail in the future. Last time I checked vendor lock-in was working pretty well for the iPod.
If you want to make something useful you should be concerned about what the device is supposed to do, how compact it is, how much it should cost etc. Whatever OS is selected (if any) it should logically follow from the goals of the project. Unless this is an academic or work experience building effort, the OS selected is just a detail. Otherwise, it's a bit like asking "how can I build an embedded systems that uses 2k resistors".
Slashdot Mirror
Thanks for the one-sided argument. I could just as easily speculate that proprietary solutions work better from day one so mods and bug fixes aren't required. I have no evidence to support the statement, but it's no different than assuming that a) mods exist that could save "several man hours a week" b) that somebody actually makes the required mods and c) that those mods actually make it into the official release of the software and c) the small business user is aware that the mod is available.
The only point you made that doesn't require "cherry-picking" the scenario is the one about having to upgrade to a new OS when buying a new computer. On the other hand, you could lease a computer with Windows 95 on it as recently as 2 years ago, so there are other options.
Risk management is one factor to consider, but not the only one and you have to look at risk comprehensively, not just focusing on a single issue. Even if you do end up paying more for your software due to the lock-in, it may turn out that it's still a better economic decision even for the long term. It seems to me that many who are anti-proprietary tend to exaggerate the economic importance of things like vendor lock-in relative to overall business economics.
One should also keep in mind that for some businesses "accepting the pain NOW" may not be economically feasible. I could have saved a bundle on my house if I had paid cash for it, but I didn't have the cash.
"If you can think of a situation where choosing to reduce your options and increase your overhead makes sense for your business, then you get an A+ for Creative Writing."
Limiting options is a very effective way of managing the complexity of any endeavor, including running a business. In any case, F/OSS advocates don't really believe in increasing options, just eliminating companies like MS as an option.
As far as cost is concerned, you have to take a detailed look at each business situation. Sometimes the "lock-in" solution ends up being the most cost effective one, sometimes not. Zealots never want to do the real analysis, they just throw slogans and insults at you.
I guess you are responding on my comment about ugliness of design, not the average business person's disinterest in programming.
Sure, when you're creating a kind of boilerplate application that is similar to millions of others, there's a lot to leverage to get the job done, but when your application doesn't quite fall along the well-beaten path, things aren't so easy. Even for the common application patterns there are often well defined frameworks that eliminate much of the "glue" code from your project which results in a cleaner design.
I don't know why some F/OSS supporters seem to believe that code libraries and code reuse originated with GNU. Code libraries have been around for more than 30 years.
"Saying philosophy has no place in business if it doesn't pay off over night is idiotic"
I agree, which is why I never made such a statement. All philosophies are not equal, however, in an ethical or in a business sense. It's hard to imagine how avoiding vendor lock-in could be a key philosophy that would make the difference between being successful or being a failure.
"Many businesses exist today because they had or have some philosophy behind them and many have fallen or are falling due to lack of them."
I agree, but many of those philsophies that helped companies succeed are ones that you might very well disapprove of. No doubt MS has a philosophy that has made it very successful.
The vast majority of small businesses aren't going to be able or willing to write a single line of a PHP script let alone writing custom code to glue it all the together (which is a pretty ugly way to design a system anyway). Most of those people have as much interest in computer programming as they do with the finer points of ball-bearing design.
If the F/OSS community follows your philosophy, proprietary software will remain dominant in the small business sector for many, many years to come.
You can't just invoke the word philosophy and expect everyone to stop thinking. There's nothing unethical about getting locked in to a single vendor if it makes sense for your business. If your philosophy doesn't believe that the "bottom line" is key element in business, than your business will most probably fail.
It's OK to have a failing business and it's OK to have a philosophy that rejects basic principles of business, but philosophies get disconnected from real life when an individual's profession is in fundamental opposition to his philosophy.
"Bollocks. Avoiding vendor lock-in is a sound business philosophy for a cost sensitive small business. "
What is the dollar value of "avoiding vendor lock-in"? That's right, you did say it's a philosphy, so perhaps it's unconnected to the bottom line.
"Vista sucks, it's just an OSX knock-off, nobody is going to buy it, who cares about it - so let's have a discussion on post-Vista Windows."
Hey, that's great if you strap a CD player or laptop to your body when you go jogging. A lock-in, of course, applies to devices in the same class. Which devices that are direct competitors of the iPod can play iTunes downloads?
The vast majority of itunes users download songs to play on their iPods, not their PC, not CD's. Those people are locked in to the iPod, but that doesn't stop them from buying one. So, I say once again: Vendor lock-in is working pretty well for the iPod and thus lock-in is not currently a big liability in the marketplace.
Yes, if you don't buy anything from iTunes to play on your iPod, you won't fall victim to the lock-in. But the topic wasn't your personal way of using the iPod. Many people buy songs from iTunes and are thus locked-in to the iPod. So the general statement holds: Vendor lock-in is working pretty well for the iPod.
Well, one can know everything about Linux and Windows security without being a power user in either one. Security is only one aspect for evaluating OS's.
When I was working on military infosec systems, we weren't even allowed to use standard OS's for secure encryption, so neither Windows nor Linux could have been used.
I've never met anyone who has "power user" skill levels on both Windows and Linux. I have noticed that some Linux users talk as if Windows == Win95 though. Those individuals obviously don't qualify on the Windows side.
First of all, most embedded systems don't use the same processors as non-embedded systems. They often use microcontrollers that provide additional peripherals in a compact package. Secondly, choosing the appropriate processor is a key element of most embedded designs. Thirdly, even though embedded systems use CPUs that can be used for a variety of purposes, that doesn't make those systems general purpose.
Sure, at a very low level all computer applications do the same sort of things, but embedded product design isn't done at that level. There are real, significant differences between the goals of specific embedded systems and those of general purpose computer systems. Ignoring those differences will make it much harder to successfuly design, build, and sell your product.
I know you're just joking, but don't you mean my nickname inspires suspiciousness? You make it sound like I picked it because I'm suspicious.
I wasn't trying to suggest that a lot of small business use ccmail, but rather illustrate that real-mode Windows can be very unstable with poorly written applications.
"An embedded system usually IS a general purpose computing device. That is, most of them are built from a few standard components and are driven by a generic CPU with custom software and/or firmware."
That's not what I would call "general purpose". That definition would cover everything with a microprocessor from a toaster to a high-end server. Embedded systems generally have a purpose that is more limited in scope.
"A large research lab or skunkworks is, perhaps, technically a business but the engineers are seldom concerned with practical business matters. That's someone else's departments. And, of course, there are universities, etc"
Research labs and universities don't typically perform product development, so when we say engineers solve real-world problems, we aren't really talking about those folks.
"This is true, but it's doubtful that someone who was planning such an application would be posting to Ask Slashdot on how to find the appropriate hardware."
I think asking for help from Slashdot isn't a great idea in general, but I don't think you can really infer anything about his project simply on the basis that he asked the question here.
"It's reasonable to assume that, whatever the device in question actually is, it involves general purpose computing/manipulation of data.."
Well, it would be more reasonable to assume that if the discussion wasn't about embedded systems which aren't considered general purpose devices.
"Engineers may design systems to solve problems but business men create buisnesses to make money, and Linux can be an important part of that."
There really isn't much serious engineering product design going on outside the context of a business, so when engineers talk of "solving problems in the real world", business considerations are naturally part of the problem. Not all embedded systems require an OS and those that do may find that an OS that wasn't designed from the ground up to be embedded (Linux, Windows CE, etc) may be inadequate or too bloated to be appropriate. Linux is certainly worth considering, but as I said before, the requirements of the project should drive the selection (and one of those requirements could be cost which would favor Linux over many other OS's).
I once worked at a company that used Lotus ccmail (yuck). It could bring down every Windows 95/98/ME computer on the network at any time. I was using Windows NT, so all ccmail did on my machine was crash itself.
"Perhaps someone who's posting a piece on how they've had no trouble installing/running Vista has their own agenda?"
Perhaps someone who's posting a piece on how they've had no trouble installing/running Linux has their own agenda as well. Or not.
The point is that on Slashdot saying something postive about MS is instantly suspect, but saying something postive about Linux isn't.
This is disappointing because nerds are supposed to be about logic and critical/scientific thinking, but we can be as blind as the worst sports fans when it comes to our sacred choices of technologies.
If a company uses a computer so rarely that instability is not an issue, than they could probably get along with Windows 95 or 98. On the other hand, if the computer is used as integral part of their business, then buying a new computer with a more stable OS is a very cheap way to increase the efficiency of your business.
If a technology company uses a high percentage of Windows 95 computers, however, something is deeply wrong.
Stripped-down C compilers have been available for the 8051 since the mid-eighties, so I doubt that that is keeping anyone for migrating an application away. I think the dirty-cheap cost, the simplicity of its basic design, the many variations available, and the body of knowledge for using it is what keeps the 8051 in the game.
Some things have changed, however. In the old days the 8051 was usually the main processor even in a fairly complex embedded system. Now it is more likely to be used to implement a sub-function with a more powerful microcontroller/microprocessor acting as the primary intelligence.
"Umm, no. Intel is a chip company. They've tried hard to become a hardware company, but haven't succeeded, as yet. VERY few systems ship with true intel motherboards."
I guess what you mean is taht Intel wants to become a PC system company. Chip companies are hardware companies to a much larger degree than Apple, Dell etc.
S"tupid lock-in by corporations will continue to fail, as consumers won't buy locked products."
Perhaps you mean it will start to fail in the future. Last time I checked vendor lock-in was working pretty well for the iPod.
If you want to make something useful you should be concerned about what the device is supposed to do, how compact it is, how much it should cost etc. Whatever OS is selected (if any) it should logically follow from the goals of the project. Unless this is an academic or work experience building effort, the OS selected is just a detail. Otherwise, it's a bit like asking "how can I build an embedded systems that uses 2k resistors".
Google wasn't started by somebody with the initials B.G. either.