The company I work for builds our custom software environment for specialty networking hardware on top of FreeBSD specifically so we can avoid crap like this.
What, actually having to do something and let others modify what you've modified?
this is why so many companies don't want to get involved with Linux or GPL solutions.
Yah.. what a bunch of jerks these people who write GPL code are. Sharing it in exchange for agreeing to a set of relatively simple rules to follow!
You don't have to like the GPL, modify the code, or accept the license. But don't go around with this attitude like people who write GPL code owe you something simply because you prefer a different license. The truth is there's a LOT of companies that are perfectly fine with the GPL. There's some that aren't. That's fine. Why do you believe we have to attempt to appease everyone?
a quick telling them that they might want to correct that one little mistake is better strategy than yelling out "OMFG, you violated the holy GPL, you burn in hell forever, kthxbye!"
A false dichotomy. Why are those the only two options? Why does naming names have to be your extreme example of dickishness?
Yes, of course I would. Why on earth (or in low earth orbit for that matter) wouldn't you?
Because I realize words aren't just things we all look up in the dictionary and that's the "right answer". Words are defined by usage, and dictionaries are always incomplete. If you asked the vast majority of people whether the space shuttle is a satellite or not, they'd say "No! It's a space ship". That's why I don't think it's at best confusing to use the word "satellite" for the space shuttle, or for this thing.
The names should be protected at this stage. It's not clear whether they're doing something wrong or not
It's not clear if they're violating the GPL because there's not enough information given. We have no idea if this is GPL 2 or GPL 3, no idea what build tools are/are not available, no idea what the product is, etc. (see the Visual Studio example in a nearby comment),
The relevant part of the GPL2 is:
For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
I read "normally distributed" as the build tools are readily available (it doesn't say free). It sounds at least close enough to a violation to warrant some pressure applied to these companies to give some sort of response. This isn't murder, and nobodies life is going to be ruined simply by letting it be known who and what we're actually talking about here.
Anyway, if any traction is to be gained the OP needs to provide specifics. That really means naming names, and specifics about what product is in potential violation. Maybe the companies aren't doing anything wrong, but keeping it all a big secret and releasing tidbits of generalized information helps nobody but the potential violators. It seems pretty obvious the OP doesn't know if they're in violation either, so why not turn to the crowd to figure out if they are? Without specifics, it's just a series of bad guesses.
It sounds like you don't work for either of these companies. So why are you protecting them?
If you really want them to do the right thing, start making a stink about it. There's very little chance anything is going to change because one guy asked them to. There's at least some chance that they will if the companies start getting a bloody nose from it.
Does this look like a satellite to you? Does this?
Yes, and yes.
What would have to change about the X-37B to make you think it's a satellite, anyway?
Maybe take the wings off, and make it non-reusable? Would you consider the space shuttle a "satellite" in any conventional sense of the word? I realize that a satellite is anything that orbits the earth, but you're missing the point here. The GP is implying that this is something MORE than a satellite.
When I cook biscuits from scratch, I don't start with baking mix, or leftovers. I start with flour, and eggs, and water, and milk, and baking powder,
All of which are components you didn't create yourself. You didn't, for instance start out with flour seeds, chickens, cows, hydrogen, oxygen, an acre of farmland and whatever you'd need to create baking powder.
The point of my analogy is of course that much like in cooking, everyone in software development starts with some ready made component. Is taking NextSTEP off the shelf and starting with that really any different than buying eggs at the grocery store?
Your problem is not one of software development, but a business problem. It sounds like you're trying to please every customer with every feature they ask for. Try to learn there's some customers you don't want, and there's really certain features they think they want, but really don't need. Some people get into this mode of trying to find every special case they might ever possibly need. Those kind of customers will bleed you dry unless you can either convince them otherwise, or fire them.
It also sounds like you're trying to generalize your products and re-use them. That's good, but if you're going to do that you really have to be disciplined about what you will do and won't do, and be willing to let a customer go if it doesn't suit your larger business strategy.
Pfft. An interesting story, but irrelevant. You assume the outcome is based on the approach, and not the individual programmers or the original code. Given two different programmers with different skill sets and a different code base, how sure are you that the outcome wouldn't have been reversed?
Reworking is faster than starting over. Even if the design is a complete mess, there's typically SOME modules that can be reused, and that's time saved
Only if: There's a module to begin with that's not dependent on some other crazy parts of the code. The module was written in a sane manner that doesn't require a crazy architecture to support it, Supporting the modules in question isn't more difficult than just starting over. The modules themselves are either well written and easy to modify, or would never have to be modified to support a new feature.
Your example is also poorly chosen, since it's a game. Typically games are developed once, sold for a couple years, and then the vast majority of the code is simply discarded. There's no real maintenance of the thing, and nobody really reuses any of the code after the game is finished. This obviates much of the advantages of re-writing the software. Most software isn't a game, is maintained over decades, and typically need new features tacked on.
We're getting into the realm of semantics and definitions here, which usually isn't terribly interesting.
So the question is really "What does it mean to re-write something from scratch"?
What I think it doesn't mean is starting from 0. I think it means starting over and abandoning the vast majority of the original code base for a new one. Nobody really goes and tries to re-write every single line of code of something without using some pre-built components. Just like in cooking you wouldn't try to create every ingredient yourself. (Who makes their own Worcestershire sauce for instance).
So while I think your distinction is important, it doesn't really degrade the original point of the article that starting over has certainly worked in the past.
Do you have experience rewriting huge enterprise software which started small, got lot of features added over the years & now has 5-10 teams of developers working fulltime on it?
Yes.
If you want rewrite huge software, do it in small chunks across different releases after adding a lot of automated test suites & bug fix verification tests.
It's an approach. It may be a good approach given the specific case. Too many people like to generalize their own specific experience across all cases. Sometimes a complete re-write really is the best approach.
The general idea I'm trying to present is you need to look past the actual code, and look at how you arrived at what you have. The process that produced the mess is as important as the mess itself. Maybe your specific case it makes sense to go the incremental route. But I guess I'm just extremely wary of this approach, given what I've seen what scope creep produces. I've also seen a lot of bad code written by people that didn't know what the hell they were doing in the first place. In that case, there's nothing really that's salvageable as often times the code wasn't written in any sort of modular way, so you can't re-write in small chunks. In any case, I'm mostly opposed to the idea that there's one approach that works for everyone and every situation. YMMV.
Bernstein is a bit of a blow-hard that thinks the major component of software has to be is SECURE. He wrote some small securely designed applications like DNS, and then goes on to challenge everyone else about how THEIR product isn't secure while HIS is. He likes to ignore the fact that real life often intervenes, requiring software to be more complex than you'd really like it to be.
I've never heard of the 37 signals people. I've used basecamp though. It's OK, but it seems over hyped for what essentially amounts to a discussion board linked to email with some todo items thrown in.
That old crappy code has undecipherable bug fixes for 100's of obscure difficult to reproduce bugs. Many of them which could be hit only under really strange customer usage scenarios & which tooks days to reproduce, days to fix & many more days to fix whatever the fixes broke.
Sounds like code that was just poorly written in the first place, and then endlessly patched and re-patched to try to "get it right this time".
Listen, software development is about software developers and the development process not about software. If a boob wrote it in the first place, that same boom is unlikely to produce anything much better the second time around. Boobs produce crap. If your process produce an enormous amount of scope creep, and the code suffered because of it producing all your crazy errors, then its the process that's at fault. Bad process produces crap. Re-writing it without the scope-creep involved in the process is likely to produce better quality code.
So unless you original software fully automated testsuites covering every functionality & you have added a bug fix verification test for each bug which has been fixed since then, do not rewrite something from scratch.
An utterly ridiculous statement. What makes you think you'll make the same mistakes when re-writing the software, and not completely different ones? If you do it right you should get LESS bugs to begin with, which is the justification for re-writing the thing. Test suites are nice and all, and they'll help you. But the idea that they're the only road to quality is silly at best. You can't test all scenarios, period. You've also made the grand assumption that the test suite is testing the right things in the first place.
rewrite ONLY if it means it yields less lines of code to maintain with the same functionality.
I have to register a huge protest to this idea that "less lines of code" == "more maintainable". Perhaps on a grand scale across several orders of magnitude this is true, but on the small scale of say a factor of 2 or 3 it's most definitely false.
I don't know that there's any one single simple rule that correlates well with maintainability. Maintainability has something to do with complexity, and quality which also can't be defined in simple terms. You could have a LOT of really simple, well written code that's easily understandable and simple to maintain, or you could have a small amount of complex, hard to understand code that blows up every time you touch the thing.
But only for one reason: I am a lot better programmer now than 5 years ago. And 5 years ago, I was a lot better than 10 years ago. And in 5 more years, I have no doubt I'll feel the same way.
These strike me as not terrible reasons to re-write your code, but also not particularly good ones either. It seems more ego driven than an economic one.
In the end, the major expense of software development is time. Time to fix bugs in the code, time to add new features to the code, etc. It doesn't matter if its OSS code for your own pet project, or something you're making a million bucks off of. If by re-writing the code you think there's a justifiable payoff in terms of time you'll save in bug fixing and maintenance, and is not time better spent elsewhere, then do it. The key word is of course "justifiable", and entails an honest attempt at calculating how much less time you'll spend maintaining the code compared to the cost of re-writing it as well as the risks of being off significantly in both calculations. But no, I don't think being a better software developer is a particularly good reason to re-write code in and of itself.
Yes, I never understood why so many pay attention to Joel's inflammatory rants.
Partly because he's a fairly good writer, and partly because he seems to offer simple solutions to the larger problems of software, and partly because he's right at least some of the time.
I DO think he's just dead wrong on this issue though. In my experience starting from scratch is something that should be very carefully considered, but rejecting it outright on general principles is wrong. I really don't care much about his bona-fides or how successful he's been. People with big impressive resumes working for some fashional part of the industry writing in the cool language of the day can say some really stupid things.
The problem starts when people start believing someone PURELY on the reputation alone, and turn their brain off. There's a few figures like that that gain a lot of hero status. Joel is one of them, Bernstein is another. A lot of people actually don't like thinking very much, and prefer ANSWERS to hard questions (even if they're the wrong answers). The cult figures in software offer these answers, defend them to the death, and attract people with similar attitudes. It winds up looking like these guys have large followings, when in reality they have minuscule, but extremely dedicated and vocal ones.
It would appear that BFG cards sucked, hence lack of geek support.
Heh. If only it were true that technically superior products succeed, and inferior ones fail. The real world is driven by things such as marketing, margin, unfair competition, collusion, and a million other aspects of business that have nothing to do with the actual performance of the product delivered to the consumer.
What it was that killed BFG from Video cards, who knows. But I don't see much of anyone saying they're glad the company is dead because of a sucky product.
I hope everyone who chanted "drill baby drill!" during the last election cycle is willing to go down to the gulf coast and help with the cleanup.
That would mean they'd have to admit they were wrong.
No, what they're now doing is trying to already downplay the spill and its effects. See, it's just those hippie liberals that think spilling 10s of millions of gallons of oil a couple hundred miles from shore is bad for the environment. I mean, there's already millions of gallons of oil released over the entire gulf over a whole year, so having it all in one place over a month isn't any different than that, right?
Yup. Oh, and you can bet those oil companies have learned their lesson this time. They didn't learn it last time, or the time before that, or the time before that. But this time.. they mean it.
You're assuming that people willing to buy and sell exploits, something at the very edge of legality and ethics, is going to obey a contract?
These kind of relationships are enforced through fear, and the desire to maintain the relationship. Do you think drug dealers try to sue someone when a drug deal goes bad?
I think omnivorous humans need to stop using weak logic to defend their habits.
I think morality based vegans/vegetarians need to start killing all the predators who cause suffering of the vegetarian animals. Those bastard wolves are killing sheep! The swine anteaters are killing and eating ants! Better to just slaughter them all and all the peace loving animals can live in harmony.
It's as if nature is cruel and unforgiving. Humans of course, are entirely separate from nature and live outside of it. Yup, we can't kill and eat animals like other animals do because we're separate from nature.
For every friend they make and funnel into a life of sad social marginality and constant maudlinity, they make a dozen enemies that after having contact with PETA will never, ever consider going vegetarian or vegan for any reason whatsoever.
So in reality, you're saying they're a force for good then? I never thought of it quite that way.
Slashdot Mirror
I guess we disagree about what's written between the lines and the attitude inherent in the post.
Examples?
The company I work for builds our custom software environment for specialty networking hardware on top of FreeBSD specifically so we can avoid crap like this.
What, actually having to do something and let others modify what you've modified?
this is why so many companies don't want to get involved with Linux or GPL solutions.
Yah.. what a bunch of jerks these people who write GPL code are. Sharing it in exchange for agreeing to a set of relatively simple rules to follow!
You don't have to like the GPL, modify the code, or accept the license. But don't go around with this attitude like people who write GPL code owe you something simply because you prefer a different license. The truth is there's a LOT of companies that are perfectly fine with the GPL. There's some that aren't. That's fine. Why do you believe we have to attempt to appease everyone?
a quick telling them that they might want to correct that one little mistake is better strategy than yelling out "OMFG, you violated the holy GPL, you burn in hell forever, kthxbye!"
A false dichotomy. Why are those the only two options? Why does naming names have to be your extreme example of dickishness?
Yes, of course I would. Why on earth (or in low earth orbit for that matter) wouldn't you?
Because I realize words aren't just things we all look up in the dictionary and that's the "right answer". Words are defined by usage, and dictionaries are always incomplete. If you asked the vast majority of people whether the space shuttle is a satellite or not, they'd say "No! It's a space ship". That's why I don't think it's at best confusing to use the word "satellite" for the space shuttle, or for this thing.
The names should be protected at this stage. It's not clear whether they're doing something wrong or not
It's not clear if they're violating the GPL because there's not enough information given. We have no idea if this is GPL 2 or GPL 3, no idea what build tools are/are not available, no idea what the product is, etc.
(see the Visual Studio example in a nearby comment),
The relevant part of the GPL2 is:
I read "normally distributed" as the build tools are readily available (it doesn't say free). It sounds at least close enough to a violation to warrant some pressure applied to these companies to give some sort of response. This isn't murder, and nobodies life is going to be ruined simply by letting it be known who and what we're actually talking about here.
Anyway, if any traction is to be gained the OP needs to provide specifics. That really means naming names, and specifics about what product is in potential violation. Maybe the companies aren't doing anything wrong, but keeping it all a big secret and releasing tidbits of generalized information helps nobody but the potential violators. It seems pretty obvious the OP doesn't know if they're in violation either, so why not turn to the crowd to figure out if they are? Without specifics, it's just a series of bad guesses.
It sounds like you don't work for either of these companies. So why are you protecting them?
If you really want them to do the right thing, start making a stink about it. There's very little chance anything is going to change because one guy asked them to. There's at least some chance that they will if the companies start getting a bloody nose from it.
A few years ago there was something on Nova about a New Mexico company that would rent out telescopes you can robotically control.
http://www.arnierosner.com/rent-a-scope/index.html
I'm guessing you'll get better observing conditions than where you are.
Does this look like a satellite to you? Does this?
Yes, and yes.
What would have to change about the X-37B to make you think it's a satellite, anyway?
Maybe take the wings off, and make it non-reusable? Would you consider the space shuttle a "satellite" in any conventional sense of the word? I realize that a satellite is anything that orbits the earth, but you're missing the point here. The GP is implying that this is something MORE than a satellite.
When I cook biscuits from scratch, I don't start with baking mix, or leftovers. I start with flour, and eggs, and water, and milk, and baking powder,
All of which are components you didn't create yourself. You didn't, for instance start out with flour seeds, chickens, cows, hydrogen, oxygen, an acre of farmland and whatever you'd need to create baking powder.
The point of my analogy is of course that much like in cooking, everyone in software development starts with some ready made component. Is taking NextSTEP off the shelf and starting with that really any different than buying eggs at the grocery store?
Your problem is not one of software development, but a business problem. It sounds like you're trying to please every customer with every feature they ask for. Try to learn there's some customers you don't want, and there's really certain features they think they want, but really don't need. Some people get into this mode of trying to find every special case they might ever possibly need. Those kind of customers will bleed you dry unless you can either convince them otherwise, or fire them.
It also sounds like you're trying to generalize your products and re-use them. That's good, but if you're going to do that you really have to be disciplined about what you will do and won't do, and be willing to let a customer go if it doesn't suit your larger business strategy.
Pfft. An interesting story, but irrelevant. You assume the outcome is based on the approach, and not the individual programmers or the original code. Given two different programmers with different skill sets and a different code base, how sure are you that the outcome wouldn't have been reversed?
Reworking is faster than starting over. Even if the design is a complete mess, there's typically SOME modules that can be reused, and that's time saved
Only if:
There's a module to begin with that's not dependent on some other crazy parts of the code.
The module was written in a sane manner that doesn't require a crazy architecture to support it,
Supporting the modules in question isn't more difficult than just starting over.
The modules themselves are either well written and easy to modify, or would never have to be modified to support a new feature.
Your example is also poorly chosen, since it's a game. Typically games are developed once, sold for a couple years, and then the vast majority of the code is simply discarded. There's no real maintenance of the thing, and nobody really reuses any of the code after the game is finished. This obviates much of the advantages of re-writing the software. Most software isn't a game, is maintained over decades, and typically need new features tacked on.
We're getting into the realm of semantics and definitions here, which usually isn't terribly interesting.
So the question is really "What does it mean to re-write something from scratch"?
What I think it doesn't mean is starting from 0. I think it means starting over and abandoning the vast majority of the original code base for a new one. Nobody really goes and tries to re-write every single line of code of something without using some pre-built components. Just like in cooking you wouldn't try to create every ingredient yourself. (Who makes their own Worcestershire sauce for instance).
So while I think your distinction is important, it doesn't really degrade the original point of the article that starting over has certainly worked in the past.
Do you have experience rewriting huge enterprise software which started small, got lot of features added over the years & now has 5-10 teams of developers working fulltime on it?
Yes.
If you want rewrite huge software, do it in small chunks across different releases after adding a lot of automated test suites & bug fix verification tests.
It's an approach. It may be a good approach given the specific case. Too many people like to generalize their own specific experience across all cases. Sometimes a complete re-write really is the best approach.
The general idea I'm trying to present is you need to look past the actual code, and look at how you arrived at what you have. The process that produced the mess is as important as the mess itself. Maybe your specific case it makes sense to go the incremental route. But I guess I'm just extremely wary of this approach, given what I've seen what scope creep produces. I've also seen a lot of bad code written by people that didn't know what the hell they were doing in the first place. In that case, there's nothing really that's salvageable as often times the code wasn't written in any sort of modular way, so you can't re-write in small chunks. In any case, I'm mostly opposed to the idea that there's one approach that works for everyone and every situation. YMMV.
Not too familiar with Bernstein
Bernstein is a bit of a blow-hard that thinks the major component of software has to be is SECURE. He wrote some small securely designed applications like DNS, and then goes on to challenge everyone else about how THEIR product isn't secure while HIS is. He likes to ignore the fact that real life often intervenes, requiring software to be more complex than you'd really like it to be.
I've never heard of the 37 signals people. I've used basecamp though. It's OK, but it seems over hyped for what essentially amounts to a discussion board linked to email with some todo items thrown in.
That old crappy code has undecipherable bug fixes for 100's of obscure difficult to reproduce bugs. Many of them which could be hit only under really strange customer usage scenarios & which tooks days to reproduce, days to fix & many more days to fix whatever the fixes broke.
Sounds like code that was just poorly written in the first place, and then endlessly patched and re-patched to try to "get it right this time".
Listen, software development is about software developers and the development process not about software. If a boob wrote it in the first place, that same boom is unlikely to produce anything much better the second time around. Boobs produce crap. If your process produce an enormous amount of scope creep, and the code suffered because of it producing all your crazy errors, then its the process that's at fault. Bad process produces crap. Re-writing it without the scope-creep involved in the process is likely to produce better quality code.
So unless you original software fully automated testsuites covering every functionality & you have added a bug fix verification test for each bug which has been fixed since then, do not rewrite something from scratch.
An utterly ridiculous statement. What makes you think you'll make the same mistakes when re-writing the software, and not completely different ones? If you do it right you should get LESS bugs to begin with, which is the justification for re-writing the thing. Test suites are nice and all, and they'll help you. But the idea that they're the only road to quality is silly at best. You can't test all scenarios, period. You've also made the grand assumption that the test suite is testing the right things in the first place.
rewrite ONLY if it means it yields less lines of code to maintain with the same functionality.
I have to register a huge protest to this idea that "less lines of code" == "more maintainable". Perhaps on a grand scale across several orders of magnitude this is true, but on the small scale of say a factor of 2 or 3 it's most definitely false.
I don't know that there's any one single simple rule that correlates well with maintainability. Maintainability has something to do with complexity, and quality which also can't be defined in simple terms. You could have a LOT of really simple, well written code that's easily understandable and simple to maintain, or you could have a small amount of complex, hard to understand code that blows up every time you touch the thing.
But only for one reason: I am a lot better programmer now than 5 years ago. And 5 years ago, I was a lot better than 10 years ago. And in 5 more years, I have no doubt I'll feel the same way.
These strike me as not terrible reasons to re-write your code, but also not particularly good ones either. It seems more ego driven than an economic one.
In the end, the major expense of software development is time. Time to fix bugs in the code, time to add new features to the code, etc. It doesn't matter if its OSS code for your own pet project, or something you're making a million bucks off of. If by re-writing the code you think there's a justifiable payoff in terms of time you'll save in bug fixing and maintenance, and is not time better spent elsewhere, then do it. The key word is of course "justifiable", and entails an honest attempt at calculating how much less time you'll spend maintaining the code compared to the cost of re-writing it as well as the risks of being off significantly in both calculations. But no, I don't think being a better software developer is a particularly good reason to re-write code in and of itself.
Yes, I never understood why so many pay attention to Joel's inflammatory rants.
Partly because he's a fairly good writer, and partly because he seems to offer simple solutions to the larger problems of software, and partly because he's right at least some of the time.
I DO think he's just dead wrong on this issue though. In my experience starting from scratch is something that should be very carefully considered, but rejecting it outright on general principles is wrong. I really don't care much about his bona-fides or how successful he's been. People with big impressive resumes working for some fashional part of the industry writing in the cool language of the day can say some really stupid things.
The problem starts when people start believing someone PURELY on the reputation alone, and turn their brain off. There's a few figures like that that gain a lot of hero status. Joel is one of them, Bernstein is another. A lot of people actually don't like thinking very much, and prefer ANSWERS to hard questions (even if they're the wrong answers). The cult figures in software offer these answers, defend them to the death, and attract people with similar attitudes. It winds up looking like these guys have large followings, when in reality they have minuscule, but extremely dedicated and vocal ones.
It would appear that BFG cards sucked, hence lack of geek support.
Heh. If only it were true that technically superior products succeed, and inferior ones fail. The real world is driven by things such as marketing, margin, unfair competition, collusion, and a million other aspects of business that have nothing to do with the actual performance of the product delivered to the consumer.
What it was that killed BFG from Video cards, who knows. But I don't see much of anyone saying they're glad the company is dead because of a sucky product.
You folks also understand that this well is in international waters, right?
I don't understand that, because it's not. The 200 mile limit you speak of is actually accepted by the United Nations, and has been since 1982. http://en.wikipedia.org/wiki/Exclusive_economic_zone
The leaking well is about 50 miles from shore. Well within the internationally accepted limit of 200 miles.
But hey, I wouldn't mistrust anything else you said, given you're dead wrong about a well established fact that's existed for the past 28 years.
I hope everyone who chanted "drill baby drill!" during the last election cycle is willing to go down to the gulf coast and help with the cleanup.
That would mean they'd have to admit they were wrong.
No, what they're now doing is trying to already downplay the spill and its effects. See, it's just those hippie liberals that think spilling 10s of millions of gallons of oil a couple hundred miles from shore is bad for the environment. I mean, there's already millions of gallons of oil released over the entire gulf over a whole year, so having it all in one place over a month isn't any different than that, right?
Yup. Oh, and you can bet those oil companies have learned their lesson this time. They didn't learn it last time, or the time before that, or the time before that. But this time.. they mean it.
You're assuming that people willing to buy and sell exploits, something at the very edge of legality and ethics, is going to obey a contract?
These kind of relationships are enforced through fear, and the desire to maintain the relationship. Do you think drug dealers try to sue someone when a drug deal goes bad?
I think omnivorous humans need to stop using weak logic to defend their habits.
I think morality based vegans/vegetarians need to start killing all the predators who cause suffering of the vegetarian animals. Those bastard wolves are killing sheep! The swine anteaters are killing and eating ants! Better to just slaughter them all and all the peace loving animals can live in harmony.
It's as if nature is cruel and unforgiving. Humans of course, are entirely separate from nature and live outside of it. Yup, we can't kill and eat animals like other animals do because we're separate from nature.
For every friend they make and funnel into a life of sad social marginality and constant maudlinity, they make a dozen enemies that after having contact with PETA will never, ever consider going vegetarian or vegan for any reason whatsoever.
So in reality, you're saying they're a force for good then? I never thought of it quite that way.