A book is a little more involved than a story. Instead of one interview, Mitnick would have been contacted on and off for about a year. This is no simple interview.
I should note the obvious part to those of you reading this who aren't inclined to take this unbiased: if Compaq lost its license to sell Windows on its PCs, it would likely be reverted to an insignificant company, if it stayed in business.
All over an icon.
Do some reasearch; I believe ZDnet has an article in the archives.
1) Their software sucks compared to what's out there. Don't waste your time replying and talk about something you haven't tried out (more than a brief stint).
2) Their attitude and treatment of other businesses. They threatened to break their contract with Compaq when Compaq decided to remove the IE icon from the desktop. Their bastardization of the Java language. Their FUD. The list goes on.
You'll never understand all of these until you take a step back, become a bit unbiased, dodge all of the useless FUD from anti-MS slackies, and just take a fresh, broad look. I don't really care to convince you, it's something you find on your own by following the news, doing some serious reading up on their trial, and by trying other products and giving them a serious shot (note: just because something is different and you have to adjust doesn't mean it sucks; you didn't 'know' Windows overnight).
If you care to continue this, email me: duckmanins@hotmail.com
It really just comes down to when the child learns the difference between a game and life. You can abstract blood, you can deal with gibs and bodies flying and people exploding mid-air and making a fireworks show (cool!). But keeping that distinguished in your head from real life, and more importantly, NOT abstracting blood, etc., in real life, is the important thing.
Some kids get the meaning of games right away. I was convinced that the Undertaker actually hit Hulk Hogan really really hard with a fold-up chair and broke something when I was about 6.
"Hey, we know they are being paid by a Microsoft competitor, VALinux has owned slashdot for years."
Aye, I'm aware. I'm sure a lot of any bias has to do with the fact that they're working for a company such as them. I don't see the relationship the other way around. Most folks aren't puppets of their company, at least in my experience.
"The point I am making is that you can argue a case far more effectively if you choose your best points and make only those rather than trying to throw everything against the wall to see what will stick."
Very true, I completely agree. Some of that could be toned down here on Slashdot. I was just being reactionary to the typical, "Oh, it's bashing Microsoft, it must be some thoughtless zombie posting; damn the editors." Your post doesn't fit these trolls, but when I read it, I did get that same "this is just MS bashing" meaning from it.
"...it appears that... this story is yet another bash Microsoft for any reason at all story. You don't think that maybe some of the slashdot editors are getting paid by a Microsoft competitor or something?"
Most people here don't like Microsoft for very good reasons. Just because the editors seem to dislike Microsoft (which I would assume) doesn't mean they're being paid, doesn't mean they're posting articles with large bias, or only posting anti-MS articles. The editors have an interest in Microsoft and what happens to them, as do most computer geeks.
Microsoft, AFAIK the biggest software company in the world and certainly the most powerful, just lost Houston. That is news. I'm sure the editors got a smile on their face and said, "Sweet, post it, sounds cool," but that doesn't mean anyone is getting paid off or that the Slashdot editors are largely biased.
This is a site for nerds. Nerds, in a large part, dislike Microsoft for very reasonable reasons. This news is interesting. Quit reading between the lines; this isn't CNN, this is a fun community news site.
"I'm a very dynamic programmer; many things in the programs I write depends on other things, and often you don't know whether a variable exists or even if it exists."
I'm gonna go grab some coffee or something....
This should read "...often you don't know whether a variable's value was set or even its name. I use hashes a lot. =D"
Bah, I need to rephrase something that I made unclear:
>So to deal with variables that have an undefined >state, you give them a defined state, even when >their current value is in fact undefined?
"Yes. How is this any different from having no 'undefined' value? You're telling me that you find a value for every single variable you put in a program? Sometimes things are not used; regardless of doing it "my way" or not having an undef value, it is going to have some form of normal value."
Add to this: only in a case which I don't want to have to worry about or consider undefined variables. When I know I won't be testing a value for being undefined, I set their values to some default or dummy value when I create them. This negates the problem most of the time, although it can't always be done.
I'm a very dynamic programmer; many things in the programs I write depends on other things, and often you don't know whether a variable exists or even if it exists. I use hashes a lot. =D
I'm very much enjoying this discussion, I'd like to hear more of what you think so I can make a better informed decision myself. =)
"So to deal with variables that have an undefined state, you give them a defined state, even when their current value is in fact undefined?"
Yes. How is this any different from having no 'undefined' value? You're telling me that you find a value for every single variable you put in a program? Sometimes things are not used; regardless of doing it "my way" or not having an undef value, it is going to have some form of normal value.
"No insult was intended regarding variables having to be finite. The point is that any variable has a finite number of states, one of which could be defined to be the "undefined" value, such as -1 (or ULONG_MAX or whatever that #define is.)"
And here we run into the problem that I tried explaining in my previous post: what value shall you use for undefined? If you create an int that will hold a number whose possible range is that of an int, how do you determine 'undef'? -1 won't work, that's in the possible set of values. You can't using just the int itself. I disagree with using something else: read on below for more reasoning.
"But back to the main idea here. If a language has VB-style booleans, then anyone writing a function must anticipate that any boolean arguments might be passed as Undefined. That's creating significant work and increased complexity. For what gain?"
Again I think it goes back to the philosophy of complex vs simple. While your point is very valid, I'll defer to my previous reply.
"A) at one time or another, we're all stupid."
Agreed; it's all about keeping your ability to be dumb and hurt yourself within reason. You don't want *too* much rope. This is a feature to feature judgement call based on individual use, and it seems like we disagree.
"2) We're not restricting the language, we're making sure our constructs actually represent what they purport to be."
And that's how I see this. I don't want a boolean that's dynamically loaded from a config file saying it's "false" when in fact the config file specifies no value. You sometimes can give it a default value when you find that it's not defined, however when abstracting multiple config files into a data structure, it'll take an out-of-scope hack to get this working.
"having to use enumerations or the like for more complex cases, does not restrict anything."
I agree, let me rephrase: it causes me to create a new type or a workaround to do something that I would expect to be in the primary types by default.
My take is, you don't always know that a variable has a value that was set or not. When loading config files, dealing with constants and other info stored in shared memory (handled by other functions/programs altogether), it's helpful to check to ensure good data. I think this way and in languages like Perl, I use this feature often. And when I'm not in need of it and have to give variables default or dummy values or worry about undef, I just suck it up; I consider it a more robust form of programming for the reasons I just stated.
"Wrongly used global variables are the bane of my existence."
Agreed; it's ridiculous the things that some folks will put in the global namespace. However to deny this ability I find absurd.
"I don't think I've used a goto since the early 80's, so I don't exactly see much need for them."
I'll try to quickly explain this simplest example. In C, open a file. If the file is null, return -1. Then open another resource, say a socket. If that fails, close the file and return -1. Then open another resource, say malloc() something (bear with me;)). If that fails, close the file, close the socket, and return -1. Repeat ad naseum.
Now: initialize your resources, program the main body, return the proper result. Below the final return, using FILO, list all of the cleanup statements, each with a given goto label. I'm sure you can see where it goes from here.
Not only is this less code, it's easier to maintain. When adding or editing a resource, you don't have to ensure that you've cleaned up every resource that was initialized. And, depending on your application, this code is more memory efficient. In the Linux kernel, gotos are used regularly in cases like this. When writing an OS, the more you can get done using the L1 cache the better simply because it is a few magnitudes faster than the L2 and even moreso for RAM. This cache is extremely small, thus memory is very important.
"And at times this is useful, and at other times it gets in the way. You no longer can rely on a variable being true or false, you have to worry about it being undefined too."
Very true. I found this to be a big pain until I got in the habit of initializing variables in which being undefined doesn't matter. That seems to be a typically advocated programming practice. See below for more thoughts on this.
>For instance, if a function grabs and returns a >given number of infinite range from a file
"Can't be done. Computers are finite machines. That number has to be stored somewhere."
Ok, assume for a minute that since I seem to have some form of a clue about programming, I'm at least competent with computers. Now, re-evaluate what I said. You don't have to take everyone 100% literally.
"But again, [if a variable can be undefined] you have to test everywhere else."
int myvar = 0; my $var = 0; var anothervar = "";
>Think of all the instances in C where testing for null is helpful.
"...and think of all the places where people fail to do so, and the program crashes."
And because certain keyboard jockies are stupid, we should restrict the language?
This is just a philosophy, but I would rather have features and have to remember more or be more careful than be forced into using workarounds to accomplish what I need to do.
Following this philosophy, I much prefer Perl's style to Java's. Perl will let you make a mess in a hurry, but it also lets you create poetry in short time as well. Java, on the other hand, is quite anal. While Java is a very good language, IMO, there are certain, extremely valid things that are left out due to fear of programmer stupidity/laziness (or maybe just plain irrationality), which is no excuse IMO. (Examples are global vars and goto statements; if you think these aren't useful, you've likely bought into the FUD you'll get from most CS departments: do some serious searching on this. Good examples are basic OOP principles for the former, and the Linux kernel for the ladder).
Regardless of the variable, whether it's a number, string, boolean, etc., in many languages, there's a way to determine if the variable is undefined. The string "" is different from an undefined or uninitialized string, and there is a good case for the ability to test this.
For instance, if a function grabs and returns a given number of infinite range from a file, many times the program will need to determine if that value was found or not. In this case, it's impossible to return "-1" to mean "value not found" or "value not set" as the number can be anything including -1.
In the above case, I find that it's much more logical to test if (var == null) than to create another variable type for this function to return, create a function specifically to test for the value's existance, or make a function return bool and pass in a variable by reference. Think of all the instances in C where testing for null is helpful.
Aye, I've actually read parts of it. What I was referring to was the quote from Microsoft regarding the government IT change to OSS:
"It's a very popular technology today, but ultimately it's not a sustainable business model. What happens when the developers who find it exciting today move on to something which will pay the bills?"
One thing I think you're missing is the concept that most development is in-house or bundled software (with hardware; e.g. drivers). Software resellers don't make up much of the market.
And even then, the idea that you can't sell OSS is a fallacy; people will buy something they can get for free. Seriously, look at all the Linux servers (27% of all servers sold in what, Q4 2002?) being sold; AFAIK, the majority of these all have expensive OS licensing attached, although any IT guy with half a brain can install Linux for free.
It's only one tiny piece of the pie, but the company I work for is completely open sourced and our new stuff is all based on OSS tools. This was a 30-man company during the dot-com era and we're still breathing fine (now running at 50 employees). Maybe it's the exception and not the rule, but I think you'll find that more resale companies base their products on OSS than you think. And resale companies (and even moreso those with a lot of in-house programming) employ developers.
Some of you guys make it sound like the only way a developer can work is by contract.;)
It's not as clean cut as some folks think; OSS is not all that bad of a gig, money wise.
"I don't know much about VB either, but if I remember correctly I think you can test bool's for 3 values... true, false, or nothing. *SIGH*"
What's wrong with that? Imagine yourself wanting to test a boolean that's dynamically set (or not set) depending on certain conditions. For instance, loading and parsing a config file containing an optional boolean into a hash (er.. em... Dictionary object; it's sad that I know that).
Wasn't this uttered by a PR rep? Isn't that their job?
Ok, given, I've made some REALLY retarded mistakes while programming before; everyone makes dumb mistakes. But Microsoft has made putting their foot in their mouth their favorite past-time.
A big company WILL emote multiple views on things, and they will make mistakes like this; they're just that big. But for the love of God, it happens so much that it doesn't seem like *anyone* at Microsoft, save some developers, has a farking clue.
I pop up when you least expect [want] me to, eh? =P
-- "Some stuff [isn't difficult if you read the free docs]. Some stuff [is]. Whereas with commercial software, most stuff yes, because otherwise you just don't freakin' sell it."
Well, most commercial software is easy for the users to use, but not always. As for administrators, I've found (in my experience and that of the company I work for) that being an admin still takes playing around and/or reading docs [tailored to morons... *sigh*]. As for OSS software, the trend I've found is lots of flexibility, lots of options, and semi-long but concise and clean docs. I like OSS docs because they're not usually filled with fluff; they get to the point. Most are very well organized. This is in my experience, but as I said, I work with this software on a daily basis.
-- Regarding your question, I do believe I was answering it; OSS is open (free) so people can add to it without any cost to them, thus you have a mutually beneficial situation. You were asking how it makes sense to not charge for source, but charge to explain how it works. Not that I agree that it's common for OSS folks to charge for docs (it's plainly not the case; tech support, yes, but not docs), but in the handful of cases where docs are charged for, it makes sense to open up the code because the developer benefits from a wide range of ideas and knowledge.
-- >one which doesn't care about a bottom line and thus does things right
"Now you're just going into wishful thinking mode. Agree?"
Yes. Let me correct myself and replace "does" with "can do". Anyway, I'd hope I'd know this as well; I program for a living.
-- "...you're missing my point. I'm not questioning the motivations or the driving forces behind software like this."
You were asking how it makes sense to make it free but charge for docs (or more often, support)... that's how I see it.
OSS developers do favors to each other and people in general by giving out progs and docs free. Those who still can't understand, those who want support, those who want to pay to prioritize a bug fix and those who want custom solutions, pay. If someone wants a developer to go even more out of his or her way to provide them with a tool they can use/understand, they pay for it.
If that doesn't answer your question, I must have gotten lucky on all my reading comprehension tests. =P Feel free to smack me for being repetetive and restate your question. =)
Jeebus man, pay a little more attention to what you're doing. =P
Most open source stuff is not difficult at all if you read the free docs. And yes, most of them have them. I'd know; guess what I work with all day?
And that's besides the point. To answer what you're asking about, OSS is open so that developers who are interested and have the time to ADD to the project can ADD to it for free. In that situation, it benefits everyone -- some developer gets a free source-base to begin from without having to start from scratch, and the OSS project manager gets the ideas and help from the new coder. The project manager puts more into it in the long run, but these are the folks who have a real passion for what they're doing. I can personally attest to that.
In the long run, for people who don't want to put the effort in to learn what can be, but often isn't, a complex system on their own, they have to pay. If, on the other hand, they could find a closed source project that was easy to understand, the situation is even. This situation just allows for people to add features and hack things for free, which in the end, often grows the developer-base to one much larger than a corporation would have, one which doesn't care about a bottom line and thus does things right.
If you think I'm blowing smoke up your arse, I seriously hope you get a chance to meet some serious OSS developers.
Reply. I want to hear what you think. Take this point by point, if you have the time. =)
Yes, and I think you've hit on something that's much more important than most folks may realize. OSS has the philosophy that anyone can hack a project to make it better. When you have a standardized plugin interface, such as with Gaim, you make it easier for people to contribute. You can get some really innovative plugins from random joe who wants to make their own IM experience better.
A massive code structure is often a hinderance to any project, open or otherwise, but modular code bases lend themselves to OSS particularly well.
Well, it seems to me that most OSS folks just do it for the fun, but even the 50 man company I work for contracts out someone because of his OSS experience. Contracting out someone for support AND development is quite beneficial, if the project is useful. And if someone is spending their free time on it, it's likely to be useful to at least some folks.
A book is a little more involved than a story. Instead of one interview, Mitnick would have been contacted on and off for about a year. This is no simple interview.
Dear God, heaven forbit someone get paid for the time it takes to give info. for a BOOK that will make the author money...
Crawl back under your bridge.
I should note the obvious part to those of you reading this who aren't inclined to take this unbiased: if Compaq lost its license to sell Windows on its PCs, it would likely be reverted to an insignificant company, if it stayed in business.
All over an icon.
Do some reasearch; I believe ZDnet has an article in the archives.
My biggest two problems with MS are as follows:
1) Their software sucks compared to what's out there. Don't waste your time replying and talk about something you haven't tried out (more than a brief stint).
2) Their attitude and treatment of other businesses. They threatened to break their contract with Compaq when Compaq decided to remove the IE icon from the desktop. Their bastardization of the Java language. Their FUD. The list goes on.
You'll never understand all of these until you take a step back, become a bit unbiased, dodge all of the useless FUD from anti-MS slackies, and just take a fresh, broad look. I don't really care to convince you, it's something you find on your own by following the news, doing some serious reading up on their trial, and by trying other products and giving them a serious shot (note: just because something is different and you have to adjust doesn't mean it sucks; you didn't 'know' Windows overnight).
If you care to continue this, email me: duckmanins@hotmail.com
I'll have to agree, although I do have my doubts.
It really just comes down to when the child learns the difference between a game and life. You can abstract blood, you can deal with gibs and bodies flying and people exploding mid-air and making a fireworks show (cool!). But keeping that distinguished in your head from real life, and more importantly, NOT abstracting blood, etc., in real life, is the important thing.
Some kids get the meaning of games right away. I was convinced that the Undertaker actually hit Hulk Hogan really really hard with a fold-up chair and broke something when I was about 6.
Eddie Izzard? Is that you?
"Hey, we know they are being paid by a Microsoft competitor, VALinux has owned slashdot for years."
Aye, I'm aware. I'm sure a lot of any bias has to do with the fact that they're working for a company such as them. I don't see the relationship the other way around. Most folks aren't puppets of their company, at least in my experience.
"The point I am making is that you can argue a case far more effectively if you choose your best points and make only those rather than trying to throw everything against the wall to see what will stick."
Very true, I completely agree. Some of that could be toned down here on Slashdot. I was just being reactionary to the typical, "Oh, it's bashing Microsoft, it must be some thoughtless zombie posting; damn the editors." Your post doesn't fit these trolls, but when I read it, I did get that same "this is just MS bashing" meaning from it.
"...it appears that ... this story is yet another bash Microsoft for any reason at all story. You don't think that maybe some of the slashdot editors are getting paid by a Microsoft competitor or something?"
Most people here don't like Microsoft for very good reasons. Just because the editors seem to dislike Microsoft (which I would assume) doesn't mean they're being paid, doesn't mean they're posting articles with large bias, or only posting anti-MS articles. The editors have an interest in Microsoft and what happens to them, as do most computer geeks.
Microsoft, AFAIK the biggest software company in the world and certainly the most powerful, just lost Houston. That is news. I'm sure the editors got a smile on their face and said, "Sweet, post it, sounds cool," but that doesn't mean anyone is getting paid off or that the Slashdot editors are largely biased.
This is a site for nerds. Nerds, in a large part, dislike Microsoft for very reasonable reasons. This news is interesting. Quit reading between the lines; this isn't CNN, this is a fun community news site.
"I'm a very dynamic programmer; many things in the programs I write depends on other things, and often you don't know whether a variable exists or even if it exists."
I'm gonna go grab some coffee or something....
This should read "...often you don't know whether a variable's value was set or even its name. I use hashes a lot. =D"
Bah, I need to rephrase something that I made unclear:
>So to deal with variables that have an undefined
>state, you give them a defined state, even when
>their current value is in fact undefined?
"Yes. How is this any different from having no 'undefined' value? You're telling me that you find a value for every single variable you put in a program? Sometimes things are not used; regardless of doing it "my way" or not having an undef value, it is going to have some form of normal value."
Add to this: only in a case which I don't want to have to worry about or consider undefined variables. When I know I won't be testing a value for being undefined, I set their values to some default or dummy value when I create them. This negates the problem most of the time, although it can't always be done.
I'm a very dynamic programmer; many things in the programs I write depends on other things, and often you don't know whether a variable exists or even if it exists. I use hashes a lot. =D
I'm very much enjoying this discussion, I'd like to hear more of what you think so I can make a better informed decision myself. =)
"So to deal with variables that have an undefined state, you give them a defined state, even when their current value is in fact undefined?"
Yes. How is this any different from having no 'undefined' value? You're telling me that you find a value for every single variable you put in a program? Sometimes things are not used; regardless of doing it "my way" or not having an undef value, it is going to have some form of normal value.
"No insult was intended regarding variables having to be finite. The point is that any variable has a finite number of states, one of which could be defined to be the "undefined" value, such as -1 (or ULONG_MAX or whatever that #define is.)"
And here we run into the problem that I tried explaining in my previous post: what value shall you use for undefined? If you create an int that will hold a number whose possible range is that of an int, how do you determine 'undef'? -1 won't work, that's in the possible set of values. You can't using just the int itself. I disagree with using something else: read on below for more reasoning.
"But back to the main idea here. If a language has VB-style booleans, then anyone writing a function must anticipate that any boolean arguments might be passed as Undefined. That's creating significant work and increased complexity. For what gain?"
Again I think it goes back to the philosophy of complex vs simple. While your point is very valid, I'll defer to my previous reply.
"A) at one time or another, we're all stupid."
Agreed; it's all about keeping your ability to be dumb and hurt yourself within reason. You don't want *too* much rope. This is a feature to feature judgement call based on individual use, and it seems like we disagree.
"2) We're not restricting the language, we're making sure our constructs actually represent what they purport to be."
And that's how I see this. I don't want a boolean that's dynamically loaded from a config file saying it's "false" when in fact the config file specifies no value. You sometimes can give it a default value when you find that it's not defined, however when abstracting multiple config files into a data structure, it'll take an out-of-scope hack to get this working.
"having to use enumerations or the like for more complex cases, does not restrict anything."
I agree, let me rephrase: it causes me to create a new type or a workaround to do something that I would expect to be in the primary types by default.
My take is, you don't always know that a variable has a value that was set or not. When loading config files, dealing with constants and other info stored in shared memory (handled by other functions/programs altogether), it's helpful to check to ensure good data. I think this way and in languages like Perl, I use this feature often. And when I'm not in need of it and have to give variables default or dummy values or worry about undef, I just suck it up; I consider it a more robust form of programming for the reasons I just stated.
"Wrongly used global variables are the bane of my existence."
Agreed; it's ridiculous the things that some folks will put in the global namespace. However to deny this ability I find absurd.
"I don't think I've used a goto since the early 80's, so I don't exactly see much need for them."
I'll try to quickly explain this simplest example. In C, open a file. If the file is null, return -1. Then open another resource, say a socket. If that fails, close the file and return -1. Then open another resource, say malloc() something (bear with me
Now: initialize your resources, program the main body, return the proper result. Below the final return, using FILO, list all of the cleanup statements, each with a given goto label. I'm sure you can see where it goes from here.
Not only is this less code, it's easier to maintain. When adding or editing a resource, you don't have to ensure that you've cleaned up every resource that was initialized. And, depending on your application, this code is more memory efficient. In the Linux kernel, gotos are used regularly in cases like this. When writing an OS, the more you can get done using the L1 cache the better simply because it is a few magnitudes faster than the L2 and even moreso for RAM. This cache is extremely small, thus memory is very important.
"And at times this is useful, and at other times it gets in the way. You no longer can rely on a variable being true or false, you have to worry about it being undefined too."
Very true. I found this to be a big pain until I got in the habit of initializing variables in which being undefined doesn't matter. That seems to be a typically advocated programming practice. See below for more thoughts on this.
>For instance, if a function grabs and returns a
>given number of infinite range from a file
"Can't be done. Computers are finite machines. That number has to be stored somewhere."
Ok, assume for a minute that since I seem to have some form of a clue about programming, I'm at least competent with computers. Now, re-evaluate what I said. You don't have to take everyone 100% literally.
"But again, [if a variable can be undefined] you have to test everywhere else."
int myvar = 0;
my $var = 0;
var anothervar = "";
>Think of all the instances in C where testing for null is helpful.
"...and think of all the places where people fail to do so, and the program crashes."
And because certain keyboard jockies are stupid, we should restrict the language?
This is just a philosophy, but I would rather have features and have to remember more or be more careful than be forced into using workarounds to accomplish what I need to do.
Following this philosophy, I much prefer Perl's style to Java's. Perl will let you make a mess in a hurry, but it also lets you create poetry in short time as well. Java, on the other hand, is quite anal. While Java is a very good language, IMO, there are certain, extremely valid things that are left out due to fear of programmer stupidity/laziness (or maybe just plain irrationality), which is no excuse IMO. (Examples are global vars and goto statements; if you think these aren't useful, you've likely bought into the FUD you'll get from most CS departments: do some serious searching on this. Good examples are basic OOP principles for the former, and the Linux kernel for the ladder).
Regardless of the variable, whether it's a number, string, boolean, etc., in many languages, there's a way to determine if the variable is undefined. The string "" is different from an undefined or uninitialized string, and there is a good case for the ability to test this.
For instance, if a function grabs and returns a given number of infinite range from a file, many times the program will need to determine if that value was found or not. In this case, it's impossible to return "-1" to mean "value not found" or "value not set" as the number can be anything including -1.
In the above case, I find that it's much more logical to test if (var == null) than to create another variable type for this function to return, create a function specifically to test for the value's existance, or make a function return bool and pass in a variable by reference. Think of all the instances in C where testing for null is helpful.
Aye, I've actually read parts of it. What I was referring to was the quote from Microsoft regarding the government IT change to OSS:
"It's a very popular technology today, but ultimately it's not a sustainable business model. What happens when the developers who find it exciting today move on to something which will pay the bills?"
One thing I think you're missing is the concept that most development is in-house or bundled software (with hardware; e.g. drivers). Software resellers don't make up much of the market.
;)
And even then, the idea that you can't sell OSS is a fallacy; people will buy something they can get for free. Seriously, look at all the Linux servers (27% of all servers sold in what, Q4 2002?) being sold; AFAIK, the majority of these all have expensive OS licensing attached, although any IT guy with half a brain can install Linux for free.
It's only one tiny piece of the pie, but the company I work for is completely open sourced and our new stuff is all based on OSS tools. This was a 30-man company during the dot-com era and we're still breathing fine (now running at 50 employees). Maybe it's the exception and not the rule, but I think you'll find that more resale companies base their products on OSS than you think. And resale companies (and even moreso those with a lot of in-house programming) employ developers.
Some of you guys make it sound like the only way a developer can work is by contract.
It's not as clean cut as some folks think; OSS is not all that bad of a gig, money wise.
"I don't know much about VB either, but if I remember correctly I think you can test bool's for 3 values... true, false, or nothing. *SIGH*"
What's wrong with that? Imagine yourself wanting to test a boolean that's dynamically set (or not set) depending on certain conditions. For instance, loading and parsing a config file containing an optional boolean into a hash (er.. em... Dictionary object; it's sad that I know that).
Wasn't this uttered by a PR rep? Isn't that their job?
Ok, given, I've made some REALLY retarded mistakes while programming before; everyone makes dumb mistakes. But Microsoft has made putting their foot in their mouth their favorite past-time.
A big company WILL emote multiple views on things, and they will make mistakes like this; they're just that big. But for the love of God, it happens so much that it doesn't seem like *anyone* at Microsoft, save some developers, has a farking clue.
"Oh, great. My conscience =)"
I pop up when you least expect [want] me to, eh? =P
--
"Some stuff [isn't difficult if you read the free docs]. Some stuff [is]. Whereas with commercial software, most stuff yes, because otherwise you just don't freakin' sell it."
Well, most commercial software is easy for the users to use, but not always. As for administrators, I've found (in my experience and that of the company I work for) that being an admin still takes playing around and/or reading docs [tailored to morons... *sigh*]. As for OSS software, the trend I've found is lots of flexibility, lots of options, and semi-long but concise and clean docs. I like OSS docs because they're not usually filled with fluff; they get to the point. Most are very well organized. This is in my experience, but as I said, I work with this software on a daily basis.
--
Regarding your question, I do believe I was answering it; OSS is open (free) so people can add to it without any cost to them, thus you have a mutually beneficial situation. You were asking how it makes sense to not charge for source, but charge to explain how it works. Not that I agree that it's common for OSS folks to charge for docs (it's plainly not the case; tech support, yes, but not docs), but in the handful of cases where docs are charged for, it makes sense to open up the code because the developer benefits from a wide range of ideas and knowledge.
--
>one which doesn't care about a bottom line and thus does things right
"Now you're just going into wishful thinking mode. Agree?"
Yes. Let me correct myself and replace "does" with "can do". Anyway, I'd hope I'd know this as well; I program for a living.
--
"...you're missing my point. I'm not questioning the motivations or the driving forces behind software like this."
You were asking how it makes sense to make it free but charge for docs (or more often, support)... that's how I see it.
OSS developers do favors to each other and people in general by giving out progs and docs free. Those who still can't understand, those who want support, those who want to pay to prioritize a bug fix and those who want custom solutions, pay. If someone wants a developer to go even more out of his or her way to provide them with a tool they can use/understand, they pay for it.
If that doesn't answer your question, I must have gotten lucky on all my reading comprehension tests. =P Feel free to smack me for being repetetive and restate your question. =)
As always, feedback would be great. =)
I was continuing the gesture. =P I thought it was funny, but I caught that serious edge in there. ;P
Regarding keeping it going, email me: duckmanins@hotmail.com. I'd love to hear what you think of my last reply.
Jeebus man, pay a little more attention to what you're doing. =P
Most open source stuff is not difficult at all if you read the free docs. And yes, most of them have them. I'd know; guess what I work with all day?
And that's besides the point. To answer what you're asking about, OSS is open so that developers who are interested and have the time to ADD to the project can ADD to it for free. In that situation, it benefits everyone -- some developer gets a free source-base to begin from without having to start from scratch, and the OSS project manager gets the ideas and help from the new coder. The project manager puts more into it in the long run, but these are the folks who have a real passion for what they're doing. I can personally attest to that.
In the long run, for people who don't want to put the effort in to learn what can be, but often isn't, a complex system on their own, they have to pay. If, on the other hand, they could find a closed source project that was easy to understand, the situation is even. This situation just allows for people to add features and hack things for free, which in the end, often grows the developer-base to one much larger than a corporation would have, one which doesn't care about a bottom line and thus does things right.
If you think I'm blowing smoke up your arse, I seriously hope you get a chance to meet some serious OSS developers.
Reply. I want to hear what you think. Take this point by point, if you have the time. =)
Very informative. =) Thanks
Maybe you should go make a page at http://osi.org/switch/ =P
My opinion:
Yes, and I think you've hit on something that's much more important than most folks may realize. OSS has the philosophy that anyone can hack a project to make it better. When you have a standardized plugin interface, such as with Gaim, you make it easier for people to contribute. You can get some really innovative plugins from random joe who wants to make their own IM experience better.
A massive code structure is often a hinderance to any project, open or otherwise, but modular code bases lend themselves to OSS particularly well.
What were you and I discussing about trolls and flames with OS bias?
*grin*
Well, it seems to me that most OSS folks just do it for the fun, but even the 50 man company I work for contracts out someone because of his OSS experience. Contracting out someone for support AND development is quite beneficial, if the project is useful. And if someone is spending their free time on it, it's likely to be useful to at least some folks.
Don't underestimate the power of OSS. =)
I've setup Linux to run off of a printer on samba share (an HP laserjet), an officejet at home, and a lexmark z53 that I have on my desk.
I found it just as easy to set up as on Windows.
I won't say that my experience will be everyone's, but 3/3 ain't bad.