Ok, sure, I understood all of that already. My point is that it just shows natural selection, not evolution. It doesn't take mutation to get uglier bugs, it just takes predators eating (more of) the pretty ones.
Likewise, it doesn't take mutation to explain the reappearance of the pretty bugs when resources got scarce - the ugly ones weren't equipped and didn't breed (as much).
genetic mutations don't happen that quickly nor that conveniently. I could buy the ugly bug adaptation, but not changing back to a pretty bug "to save energy". Way too fast, way too convenient. Something else is going on.
The time to deal with the PHB and the security consultant is before the report comes. Define a level of security your company finds acceptable.
It doesn't take much to quickly set the right tone for a security audit. Even the Pointiest of HBs can understand the basic rules:
You're never totally secure. The goal is to find a level of safety that we can tolerate and still get satisfactory service from our systems. (Do we change our passwords every day? No, too much hassle.) Security must be balanced with usefulness, and that balance point is different for each machine in each company.
We layer security measures on top of one another and hope that our effort is enough to make someone seek an easier target.
Bosses understand cost/benefit ratios, and they understand that you get more usefulness for more dollars. They'll also understand that you get more security with more dollars - what are they willing to pay (either for labor or devices)?
If you have a chance, take them through this:
The only way to really secure a system is to turn it off. Not very useful, but highly secure. Ok, so maybe turn it on, but unplug the network cable. And lock the door. (Who has a key? Who cleans the room? ) But it's a server, so it sort of has to be on the network to be useful. So plug it in, but use a firewall it off from the rest of the network with every service but files blocked. Well,... you get the idea.
It's all about tradeoffs. Sometimes something comes along that makes life better, easier, and cheaper at the same time, but usually you only get one or two out of three.
About 80 years ago, when the predators were all over the place, the Daphnia retrocurva extended the size of its helmet and spines to make itself less appetizing. Later, when the number of predators shrank, the animal reduced the size of those features, thus conserving its energy for other uses.
The researchers had hit pay dirt. The changes in Daphnia retrocurva were precisely what would have been expected as part of the predator-prey interaction.
Furthermore, DNA analysis shows that the changes were passed on genetically from one generation to the next, until they were no longer needed, thus confirming that the researchers had caught evolution in the act.
I'm not a Creationist. But I can't help thinking critically about stuff like this. There are a few holes in the picture that make it hard for me to buy TFA's conclusions.
For instance, the bugs grew uglier so they wouldn't get eaten. How did they do that? But let's suppose they did. The article claims their DNA actually changed. I don't get that at all.
It seems more likely that when there were more predators only the ugly bugs survived to leave eggs. The others got eaten. But their DNA didn't change, the tasty-looking bugs just got weeded out.
In other words the DNA of the uglier bugs looks different because their parents were ugly. The problem with calling it an evolutionary change is that a subsequent generation was pretty again. If the DNA had in fact changed, they would have stayed ugly.
Reverse engineering is not just grabbing the binary and disassembling it. Using the code you get that way is called plagiarism.
Reverse engineering is also looking at what the program does and figuring out a way to do it yourself. If the way you figure is exactly the way the original works, so much the better - but you haven't plagiarized.
It's the first method, disassembly and copying, that Linus and everyone else should be against. The second method is just interoperability, and everyone should be in favor of that.
Marketing 101: you only look as good as your competition. If there isn't anyone else in your product space, find someone, or no one will think your product is worthwhile.
And another thing: they say the free BitKeeper is costing them $500M/year. That sounds like a load of hooey. What they mean is that if they could sell the free one for the price of the non-free one, it would total $500M in revenue. That still sounds fishy, but at least it's easier to swallow than their implication that they spend $500M in cash every year.
It's sort of like the "law" that I drive to work every day. Just because ever since I can remember I've done that doesn't mean I'll always do it.
There is also a self-fulfilling aspect to the Law. Engineers know that density is expected to double, and that it's been extrapolated into hard disk capacity and dishwasher memory capacity. There is industry-wide pressure not to let it fail in your generation of engineers.
I foresee a period of massively of parallel circuits with parity checking, which will increase transistor counts exponentially with only a logarithmic (or linear, depending on your viewpoint) increase in speed.
In the limited technical sense of transistor density on a chip, the law is bound to fail when we figure out how to avoid using transistors altogether. Some bright boy or girl will come up with AND, OR, NAND, etc. gates that are formed not of transistors but are themselves discrete components.
The most brilliant marketing spin evar. You have a warehouse full of chips that don't do floating point correctly. What do you do?
Design a motherboard that disables floating point and ramp up the marketing on the "486SX", a chip that "is cheaper because it doesn't have features most users never care about."
I guess I'm just finding it difficult to imagine what I would ever need, say, 32Ghz for, other than gaming--which would be what my ultra-hip game console would be for.
Speech recognition. Not the easy kind, where a user sitting at his laptop controls the mouse cursor, but the hard kind, which listens to a room full of people and nails the transcript in real time.
Robots. Not the easy kind, that do a few simple preprogrammed maneuvers, but the hard kind, which do what you would have told them if you'd thought of it first. Then they take over and hunt us down like rats to use as an energy source, but that's a different story (or two stories).
There is a whole class of problems (computer scientists call them "NP-hard") which essentially take as much computing power as you have. Examples include completing the timetable for a university's class schedule based on which students want which class at which time, etc. (a form of the "Traveling Salesman Problem").
Three-dimensional interfaces. Bitmap images currently use only 2-D; imagine how much more horsepower it will take to manipulate and display 3-D bitmaps. And that's just the bitmaps themselves, not the a whole 3-D space that the user manipulates instead of this little flat thing you're looking at now.
Real-time cartoons. It's currently impractical to generate realistic animation from a script. With enough computing power, you could do all the sprite movement and ray-tracing in something like Display Postscript.
Whatever is next. We'll always find things to do with more processor cycles.
Their mistake is not in thinking that their profits will increasingly come from services. It's in saying that their profits should come from services, deemphasizing hardware.
It's a matter of the heart of the company. Selling big iron is what separates IBM from everybody else. They're saying their bread-and-butter is no longer a cash cow, to mix metaphors, so out with the bathwater goes the baby. That kind of thinking is short-sighted and small-minded, IMO (rural imagery aside).
What they really need is a few years of anti-bureaucracy zealotry and reorganization.
...offering free support services, including credit bureau reports, credit monitoring for one year and fraud insurance...
<sarcasm>
Out of the kindness of their hearts, no less. They're unconcerned with any bad press they might get for offering these services and boldly doing what they can to help their customers.
Why, the idea that they might be liable for thousands of stolen identity cases and a jarmungulous class action suit doesn't seem to have affected them at all.
I meant "most commonly used FOSS license, in number of FOSS packages choosing it". After thinking about it, I think probably The Artistic License actually has more users, since Perl is almost ubiquitous. Sendmail's BSD-like license is another contender.
I think I'll ask Google... hmm, interesting. Here is a cached page listing some numbers:
In the early '90s I was a support tech for a university which shall remain nameless (ok, Illinois). Working at home one Saturday, I managed to spill a tiny bit of coffee on my laptop keyboard. Ok, so it was a cupful.
Not wanting to be known as the idiot who spilled coffee on his laptop, I got a blow drier and dried off the keyboard. It fused the 'f' and 'g' keys together.
After the Dell guy quit laughing, he grudgingly replaced my keyboard. I think they didn't want to give one of their machines to someone with a demonstrably high Klutz rating.
...whenever somebody "defers" on defending themself, it sure looks like they have something to hide.
On the other hand, he's probably answering a lot of questions from a lot of corners, and doesn't want to spend much time defending himself. Also, to say anything more he would have to talk about the differences in the motivation and ethos of all the players, which is a can of worms. Better just to say what he said and leave it at that.
The key piece of information he did provide, though, is that he "did not use BitKeeper at all in writing this tool". If that means he didn't look at the binary, the the BitKeeper folks are just being petty.
If all he did was write a tool to manage the same data format that BitKeeper uses, then he's not doing anything wrong. If he had disassembled the BitKeeper binaries to figure out how they worked, I'd call that cheating, which is not the way to go about making software free.
Low-gee life for the aged, disabled, et al. While muscle atrophy is a problem, I think some people would trade a shorter lifespan at 1/6G on the moon for a longer lifespan on Earth at full gravity.
Survival of the race. If Giant Meteors or terrorists with nukes or superpox don't get us, something else might. Having people off-planet could keep some of these things from killing us all.
Because it's there. We've always wanted to see what was beyond the next ridge, or on the other side of the sea. Now we can see a huge frontier, just waiting to be explored.
If we could make a nanobot small enough, and make enough of them, then their movement would look like fluid flow.
Imagine companies competing on the viscosity of their nanobot lines.
Imagine billions of nanobots programmed to stay very close to a human's skin, but not to touch it. They could be waterproof and/or airtight from the outside, but allow various things to escape from the inside.
Oh well. Somebody has probably already written a whole series of sci-fi novels about it.
Maybe your experience differs from mine, but I usually have to explain to my clients that no, they don't get to keep the software all to themselves. They think they get a business advantage by hiding their internal practices, which may or may not be true generally, but in the case of software it's pretty easy to demonstrate for them the advantages of community maintenance.
And I may have been around longer than you have, because I've dealt with countless people who say "Bill Jones wrote this for us ten years ago, but he {died, moved to Bechualaland, doesn't support this version any more}. Yes, they "just want it to work", and no, they don't want to spend the money to upgrade or replace it.
The worst case is some bozo who encrypts his code, so he can sell his stinking BASIC app. Ack. A close runner up is the nimrod who builds in date traps, so that unless he unlocks the trap the app doesn't run. That's just poor-man's licensing, but it's usually done in a really ugly way.
The few times when I've had the source code available the problem has invariably be easy to fix. It's amazing how shallow bugs are when you have the source, since you know that the program worked fine until some circumstance changed.
Why is it so wrong to like the free beer? I like giving away the beer. I do charge for delivery and cleanup, though, at $100, $75, or $50/hour depending on whether they buy by the glass, pitcher, or keg.
So tell me again why should I spend my money developing software and just give it away?
First, let me address your question as you stated it. You should spend your money developing software and just give it away because it will enhance your reputation. For the respect of your peers, in other words.
But the real answer to your question comes from the twin misconceptions contained in it. I spend my money developing software, but so do IBM, the University of Illinois, Linus Torvalds / OSDL, and thousands of people all over the world. I accept the benefit of their work, building on it with my tiny contributions, and to pay for their work return my little contribution to the public. And I don't just give it away, I give it away and charge cash money to support it (and other free software).
The other business model (trying to hide your source code) results in distrust between you and your users. It also means a support nightmare in ten years when your software is still limping along but no one understands it and you're nowhere to be found.
Slashdot Mirror
Ok, sure, I understood all of that already. My point is that it just shows natural selection, not evolution. It doesn't take mutation to get uglier bugs, it just takes predators eating (more of) the pretty ones.
Likewise, it doesn't take mutation to explain the reappearance of the pretty bugs when resources got scarce - the ugly ones weren't equipped and didn't breed (as much).
genetic mutations don't happen that quickly nor that conveniently. I could buy the ugly bug adaptation, but not changing back to a pretty bug "to save energy". Way too fast, way too convenient. Something else is going on.
It doesn't take much to quickly set the right tone for a security audit. Even the Pointiest of HBs can understand the basic rules:
If you have a chance, take them through this: ... you get the idea.
The only way to really secure a system is to turn it off. Not very useful, but highly secure. Ok, so maybe turn it on, but unplug the network cable. And lock the door. (Who has a key? Who cleans the room? ) But it's a server, so it sort of has to be on the network to be useful. So plug it in, but use a firewall it off from the rest of the network with every service but files blocked. Well,
It's all about tradeoffs. Sometimes something comes along that makes life better, easier, and cheaper at the same time, but usually you only get one or two out of three.
I'm not a Creationist. But I can't help thinking critically about stuff like this. There are a few holes in the picture that make it hard for me to buy TFA's conclusions.
For instance, the bugs grew uglier so they wouldn't get eaten. How did they do that? But let's suppose they did. The article claims their DNA actually changed. I don't get that at all.
It seems more likely that when there were more predators only the ugly bugs survived to leave eggs. The others got eaten. But their DNA didn't change, the tasty-looking bugs just got weeded out.
In other words the DNA of the uglier bugs looks different because their parents were ugly. The problem with calling it an evolutionary change is that a subsequent generation was pretty again. If the DNA had in fact changed, they would have stayed ugly.
Or is it late and I'm missing something obvious?
new ad models, especially if they dress appropriately.
sorry.,
Reverse engineering is not just grabbing the binary and disassembling it. Using the code you get that way is called plagiarism.
Reverse engineering is also looking at what the program does and figuring out a way to do it yourself. If the way you figure is exactly the way the original works, so much the better - but you haven't plagiarized.
It's the first method, disassembly and copying, that Linus and everyone else should be against. The second method is just interoperability, and everyone should be in favor of that.
Marketing 101: you only look as good as your competition. If there isn't anyone else in your product space, find someone, or no one will think your product is worthwhile.
And another thing: they say the free BitKeeper is costing them $500M/year. That sounds like a load of hooey. What they mean is that if they could sell the free one for the price of the non-free one, it would total $500M in revenue. That still sounds fishy, but at least it's easier to swallow than their implication that they spend $500M in cash every year.
It's sort of like the "law" that I drive to work every day. Just because ever since I can remember I've done that doesn't mean I'll always do it.
There is also a self-fulfilling aspect to the Law. Engineers know that density is expected to double, and that it's been extrapolated into hard disk capacity and dishwasher memory capacity. There is industry-wide pressure not to let it fail in your generation of engineers.
I foresee a period of massively of parallel circuits with parity checking, which will increase transistor counts exponentially with only a logarithmic (or linear, depending on your viewpoint) increase in speed.
In the limited technical sense of transistor density on a chip, the law is bound to fail when we figure out how to avoid using transistors altogether. Some bright boy or girl will come up with AND, OR, NAND, etc. gates that are formed not of transistors but are themselves discrete components.
The most brilliant marketing spin evar. You have a warehouse full of chips that don't do floating point correctly. What do you do?
Design a motherboard that disables floating point and ramp up the marketing on the "486SX", a chip that "is cheaper because it doesn't have features most users never care about."
Profit!
hehe.
I think they're making a mistake.
Their mistake is not in thinking that their profits will increasingly come from services. It's in saying that their profits should come from services, deemphasizing hardware.
It's a matter of the heart of the company. Selling big iron is what separates IBM from everybody else. They're saying their bread-and-butter is no longer a cash cow, to mix metaphors, so out with the bathwater goes the baby. That kind of thinking is short-sighted and small-minded, IMO (rural imagery aside).
What they really need is a few years of anti-bureaucracy zealotry and reorganization.
...offering free support services, including credit bureau reports, credit monitoring for one year and fraud insurance...
<sarcasm>Out of the kindness of their hearts, no less. They're unconcerned with any bad press they might get for offering these services and boldly doing what they can to help their customers.
Why, the idea that they might be liable for thousands of stolen identity cases and a jarmungulous class action suit doesn't seem to have affected them at all.
</sarcasm>I meant "most commonly used FOSS license, in number of FOSS packages choosing it". After thinking about it, I think probably The Artistic License actually has more users, since Perl is almost ubiquitous. Sendmail's BSD-like license is another contender.
... hmm, interesting. Here is a cached page listing some numbers:
I think I'll ask Google
http://www.google.com/help/features.html#cached
GPL/LGPL ~77%,
BSD et al 12%.
So do something cool. It's your turn.
Loren Heal BS(CS) '91.
They'll be clearly the best engineering team, but will lose in the finals to the more talented squad from MIT.
In the early '90s I was a support tech for a university which shall remain nameless (ok, Illinois). Working at home one Saturday, I managed to spill a tiny bit of coffee on my laptop keyboard. Ok, so it was a cupful.
Not wanting to be known as the idiot who spilled coffee on his laptop, I got a blow drier and dried off the keyboard. It fused the 'f' and 'g' keys together.
After the Dell guy quit laughing, he grudgingly replaced my keyboard. I think they didn't want to give one of their machines to someone with a demonstrably high Klutz rating.
On the other hand, he's probably answering a lot of questions from a lot of corners, and doesn't want to spend much time defending himself. Also, to say anything more he would have to talk about the differences in the motivation and ethos of all the players, which is a can of worms. Better just to say what he said and leave it at that.
The key piece of information he did provide, though, is that he "did not use BitKeeper at all in writing this tool". If that means he didn't look at the binary, the the BitKeeper folks are just being petty.
If all he did was write a tool to manage the same data format that BitKeeper uses, then he's not doing anything wrong. If he had disassembled the BitKeeper binaries to figure out how they worked, I'd call that cheating, which is not the way to go about making software free.
Either way, it's a tempest in a teapot.
Assembly Instruction of Very Fine Device.
Step 1: You should be opening the box now.
Step 2: Complete assembly is easy for you.
Step C: Begin use Very Fine Device.
I hate it when I come up with a sure-fire, can't miss post and blow it with a typo or incorrect usage that ruins the whole thing.
Like the time I posted about a girl who drank so much she blew chunks, but I put "drunks" instead of "chunks", which changed the meaning slightly.
"Every writer can use a good editor, and we see no reason that community contributors deserve any less."
That's a sneaky way to spin the question of user-edited vs. MS-edited.
But then, if they let the users edit themselves, why would anyone need Microsoft?
Come to think of it, that's a good question. Why does anyone need Microsoft?
If we could make a nanobot small enough, and make enough of them, then their movement would look like fluid flow.
Imagine companies competing on the viscosity of their nanobot lines.
Imagine billions of nanobots programmed to stay very close to a human's skin, but not to touch it. They could be waterproof and/or airtight from the outside, but allow various things to escape from the inside.
Oh well. Somebody has probably already written a whole series of sci-fi novels about it.
>most businesses don't care about the source
Maybe your experience differs from mine, but I usually have to explain to my clients that no, they don't get to keep the software all to themselves. They think they get a business advantage by hiding their internal practices, which may or may not be true generally, but in the case of software it's pretty easy to demonstrate for them the advantages of community maintenance.
And I may have been around longer than you have, because I've dealt with countless people who say "Bill Jones wrote this for us ten years ago, but he {died, moved to Bechualaland, doesn't support this version any more}. Yes, they "just want it to work", and no, they don't want to spend the money to upgrade or replace it.
The worst case is some bozo who encrypts his code, so he can sell his stinking BASIC app. Ack. A close runner up is the nimrod who builds in date traps, so that unless he unlocks the trap the app doesn't run. That's just poor-man's licensing, but it's usually done in a really ugly way.
The few times when I've had the source code available the problem has invariably be easy to fix. It's amazing how shallow bugs are when you have the source, since you know that the program worked fine until some circumstance changed.
Why is it so wrong to like the free beer? I like giving away the beer. I do charge for delivery and cleanup, though, at $100, $75, or $50/hour depending on whether they buy by the glass, pitcher, or keg.
First, let me address your question as you stated it. You should spend your money developing software and just give it away because it will enhance your reputation. For the respect of your peers, in other words.
But the real answer to your question comes from the twin misconceptions contained in it. I spend my money developing software, but so do IBM, the University of Illinois, Linus Torvalds / OSDL, and thousands of people all over the world. I accept the benefit of their work, building on it with my tiny contributions, and to pay for their work return my little contribution to the public. And I don't just give it away, I give it away and charge cash money to support it (and other free software).
The other business model (trying to hide your source code) results in distrust between you and your users. It also means a support nightmare in ten years when your software is still limping along but no one understands it and you're nowhere to be found.