What inspirational prose! Wish more people thought like you. IMO if free-software advocates spent more time figuring out how to best live their own lives, hack their "own" code (including public ones, like Linux), and less or no time joining causes involving tyrannizing others (such as supporting gun control, the Kyoto Treaty, forced redistribution of wealth, or laws restricting free speech), they'd revolutionize the world very quickly, since they'd not only be less distracted by the bright shiny object best known as "tyranny", but they'd learn much from putting into practice the concepts they preach about lack of central imposition, etc.
Note that I'm trying to do the opposite of playing both ends against the middle. Rather than tell the public the free-software or "mob software" approach will rule, and advocate *within* the mob the idea that, no matter what they spew out, it'll all magically work out, I prefer to tell the public to insist on quality, then advocate to the "mob" the idea that they too must insist on quality.
Do I think that approach might help a little bit? Yes, but I'm not sure. Do I believe it's necessary to ensure the success of the mob approach? I have no idea. I just don't see why I shouldn't try, a little bit, here and there, and I'd like to see more concrete steps taken towards making mob-style development actually work better than just writing about how great it'll all be, since I've been fantasizing about that myself for 20+ years, with all sorts of "great ideas" to accomplish it, and have little to show for it to date, other than a pretty good sense of a bunch of techniques that won't work!
Regarding oversight as being a "missing element" -- I don't claim that's the case. I'm saying something different: that each contributor must be willing to try to exercise his own oversight, and that, if too few contributors to mob-developed software do that sufficiently, it won't develop quality. A failed project does not demonstrate the failure of this development model to follow "survival of the fittest", of course, but I assume the point is that we'd like to think we'll produce many useful things that will survive and flourish.
Given time, this could become the dominant pool of software creation.
I hope so! And I've long believed it likely.
My concern is that "we" (the community) not give in to the belief that we need not individually establish and hold to the highest standards possible for quality.
After all, the "infinite monkeys writing Shakespeare" idea, once explored, illustrates the problem with the "many programmers holding hands and creating software, some of which might actually be good" notion, namely, how does anyone determine what is good, and how do they even find it in the first place?
Keep in mind that the data regarding whether a piece of software is "quality", as well as the data regarding where to find such software, are themselves forms of software, as far as these illustrations go (and that's where I don't see new, helpful answers in the "mob software" essay -- what makes these problems go away?).
In the infinite-monkeys case, note how the problem is reduced to merely finding a match for works already generally assumed to be of high quality, namely, Shakespeare's writings.
Now consider another facet, just as true (mathematically), of that general idea, namely this:
An infinite number of monkeys typing away on an infinite number of typewriters for an infinite amount of time
will produce a brand-new work of literature that transcends Shakespeare in every way, reaches into the core being of the reader, touches his heart, and raises his conception of himself, his fellow man, and the universe as a whole.
(Okay, I got a bit carried away there, but you get the idea.)
The problem is now clearer: in that infinite amount of output, how does anyone find that particular gem? How does anyone even assure themselves that they have found it, not something that would, if these respective works were published today, be nothing more than a cheap knock-off of the desired work?
The answer is, that search, as well as the value of "quality", are themselves just as difficult to "build" as the software they attempt to describe.
With free software, yes, we don't have an infinite amount of output, but we therefore don't have an infinite amount of time to converge on high-quality solutions, nor do we have any magic bullet for determining what is quality, what is worth keeping, what technological directions are worth following, versus what are technological cul-de-sacs.
(And, remember, our monkeys will, unlike the ones in the thought-experiment, tend to follow the "monkey see monkey do" approach, by and large -- meaning if a few "leader monkeys" start down a technological cul-de-sac, most of the rest will follow, all proclaiming the "quality" of the work they're doing.)
In the end, an infinite number of monkeys pounding away at typewriters is of little use to someone who needs a hammer.
So while these illustrations ("mob software" and the like) encourage one to believe that there are substantial advantages to the free-software-development paradigm, those advantages don't materialize until sometime after those participating in, and forwarding, the paradigm give up their belief that "the best stuff will just win out" in favor of taking a stand for high-quality, long-lasting software, and avoid creating anything less worthy than that for public use -- avoid contributing to the chatter of mediocrity. (After all, we already have the proprietary-software development model for that, don't we?;-)
Re:What if what once was scarce is now abundant?
on
Mob Software
·
· Score: 1
I assume you gave a very simplified version of the idea, since you didn't address the obvious question about the story, which is:
To
whom, specifically, would those aliens be giving the gold?
If the answer is "to the government of country X", where X is USA or North Korea or whoever, it's silly to assume country X would participate in the nuking of the aliens.
Further, it's not only silly to assume country X wouldn't look for ways to thwart the attempts by other countries to nuke the aliens, it's silly to assume country X wouldn't immediately look for collaborative and compromise solutions with the dominant military powers based on an exchange such as "you let us receive that gold, we give you a percentage", or "you let us receive that gold, we don't nuke you like you did the aliens", or something.
If the answer is "the aliens would divide up the gold and give it to all the people", well then, since individuals have little practical use for gold in daily use, you might as well change the thesis of the story to be that aliens give each citizen of the world a whole bunch of the dominant currency (let's say US dollars) in a form that cannot be detected as a forgery by any technology likely to be developed on Earth in the next several decades.
In that scenario, you are indeed looking at a risk of inflation and such, but, knowing how governments tend to work today, they'll just do stuff like consider the alien's planetwise gifts as taxable income, and increase taxes across the board (since everyone will now be "rich").
Since most governments are always looking for excuses to do that sort of thing anyway, they'd probably respond to the alien's proposal with a big wet kiss.
Lesson for today: the control government exercises over people is rarely more than partially economic. Mostly it's a matter of force, mainly military/police power. Change the gold/currency in the story to advanced phaser-like weapons easily concealed on a person, then you might have a scenario in which governments would band together and nuke the aliens. If there's one thing tyrannical governments can't abide, it's the right of the people to keep and bear arms, with which to overthrow those in power. They keep increasing taxes, yes, to preserve their hold on power, but the military/police is more crucial in the short run to collect taxes than are the taxes to fund the military/police. (That's why even dirt-poor countries often have sufficient funds to protect government officials from their own people, but the reverse -- rich countries with high taxes but government officials no better protected against citizen revolt than your average McDonald's franchise manager -- rarely occurs in nature.)
What does all this blather of mine have to do with Open Source?
Well, Open Source, or free software, is a gift to the entire world's population, including governments. In specific instances it might give individuals power to use against government, but, more generally, the only commodity it tends to deflate in value is proprietary software -- which costs governments mucho $$, money they could spend on upgrading military, police, tax-collecting efforts, and so on.
The governments that "get" this, while they might be concerned about lower tax revenues due to programmers being willing to earn less (in some cases) writing free vs. proprietary software, will realize that an open-door policy for hacking and free-software development benefits the sitting government at least as much as anyone else, if it is well-poised to take advantage of those benefits.
That's why I don't expect to see a "haven" for free-software developers (a country free of the increasingly tyrannical intellectual "property" laws like the DMCA, software patents, and such) in the near future, and especially not from Communist or Socialist countries, though it's always possible. The governments of such countries already believe they can "command" and "control" their economies, and, unless they take an especially narrow view of software -- say, that it's an infrastructure component best built via "mob software developers" or the like -- they're unlikely to treat software developers in a fashion totally out of step with how they treat, say, shoemakers, energy producers, Christians, or the Falun Gong.
And even "enlightened", "civilized" countries not generally considered infected by the Communist meme show their socialistic, tyrannical bent by looking for ways to force their trading partners to not lower taxes on their own population, so as not to "compete unfairly" with the rest of the "union". By induction (or inference?), one can see why even the USA is unlikely to accept such a "free-software-haven" country as a trading partner whose human-rights record is considered worthy of the same level of acceptance as, say, China. I mean, you can roll tanks over protesting students all you want, but you'd darn well better get those IP laws in place and enforced, okay?
(Lesson number two: you can always tell a socialist-leaning tyrant by how he urges a nation to unilaterally disarm against its sworn enemies and yet remain highly armed against its own people -- after all, how can it continue to collect high taxes?)
Re:Complexity and Software
on
Mob Software
·
· Score: 1
"You are the product of a mutational union of ~640Mbytes of genetic information."
Hey, didn't Bill Gates once claim that nobody would ever need more than 640MB of genetic information?
Youll never see an ant forced to work in a way it doesnt want to. It does what it does from its own volition. Youll also never see two ants fight over an anthill-design issue. They work as if alone, yet together, act as single whole.
Um...people aren't ants.
And discovering similarities between a software-development "ecosystem" and the "real" ecosystem, while it might give us at least a few useful insights based on our current understanding of natural selection, doesn't mean the software-development ecosystem is sufficiently like the real one to make a numbers game an adequate substitute for proper design.
I believe there's a lot that's true about the "mob software" paper, but even if a lot of the stuff that's hand-waved ("minor" problems like, how do we annotate modules with cultural information in a way that's useful to both the computing infrastructure and the human beings?) is solved down the road, the only true ecosystem will remain the one we already have.
The "mob software" ecosystem will therefore suffer from a phenomenon that every free-software project has had to deal with, but which is not generally a problem for the "real" ecosystem:
A person can decide to leave the ecosystem without leaving behind a substantial "carcass" that can be reclaimed as nutrients for it.
For this reason, I've tended to find appeals to the "if I build it, they will come" approach to explaining why sound engineering principles are rejected out-of-hand by "those in charge" of certain OSS projects to be unpersuasive. Yes, "they" might indeed come, but if "they" are incompetent at the task at hand, and, having spent several years making "contributions" that direct the project even further down a technological cul-de-sac, become sufficiently competent to recognize what's been going on, having not convinced the "leadership" -- those who say "but we've always done it that way, it works", a kind of thought that's even harder to challenge in a mob-software approach than in a proprietary-software shop (and I've tried both, believe me) -- they are not only free to leave, but they take the most important part of the investment that little ecosystem made in them: their newfound competence at the task.
At least, in the real ecosystem, when a creature "leaves" (by dying), its nutrients are reabsorbed, over a period of time, back into the living mass. (Yes, the creature's knowledge and experiences "die", but they aren't as critical an "investment" for the ecosystem, which doesn't really, in any way, "care" about that creature.)
A mob-software ecosystem will, by the definition given, depend highly on the experience and expertise of individuals, even if only collectively, so it will need a certain degree of engineering "oversight" (and this is what the author probably means to say in a few places).
The closest equivalent to that in the "ant world" might be the genetic programming. We're not ants, so we don't have the genetic programming to cooperate like they do, and we don't yet know how to build an (abstract) organic ecosystem (say, a computing network) that serves as an adequate substitute.
But the promise is there (I've certainly been thinking along the same lines for, well, over two decades), it's exciting. And while I might raise an eyebrow over the apparent bashing of capitalism (preferring if the author had more tightly focused on the raising of intellectual privilege from a society-based concept to a right-to-profit monstrosity), since I'm not prepared to agree with the notion that a gift economy can't flourish within a society that, like the USA, permits capitalism as well (after all, we do have both, however imperfect they might be, and, unlike most experiments in command-and-control economies, we haven't executed millions of innocent people in this century to impose our new utopian structure on the population), all I can think to say after reading the paper is:
Okay, Mob Software Proposer guy, what's the next step?
Can you point to a single thing I said that shows that I "forgot" this one important detail??
You replied:
By assuming that source code makes everything better.
I asked you to quote me, and instead you just make something else up out of whole cloth?
Look, I might well say that having source code hardly ever makes anything worse, but unless a person has a very poor grasp on logic, they're unlikely to believe that a) that means I believe that source code makes everything better and that b) that means I believe that even Ronald Reagan, in the throes of Alzheimer's, can personally negotiate the source code for Apache to find security flaws.
More likely, if you both valued my input and were an honest person, you'd admit that, time and time again in this thread, I've pointed out that the source code is a benefit to everyone because they, or someone they hire, can openly read, modify, discuss, and test it.
It is simply not a matter of having source code available that makes it secure.
Here you continue setting up your strawmen, imputing them to me, and knocking them down. I hope you're having fun; for myself, I tend to tire of arguing with people who pull this stunt.
Can't you simply accept my statement that I did not forget that not everyone can read source code is true? Or are you 100% convinced that I'm either a liar or somewhat self-delusional?
You still have not commented on sendmail
Indeed, I have not commented on a bloated, monolithic Mail Transfer Agent that was originally designed for use on a non-hostile Internet and has been known to have many security holes as it has been grown into something designed to be suitable for use on a hostile Internet, while adding all sorts of features that needn't be part of the core product.
Why should I? After all, you've already discussed it, and I've seen nothing you've said about it worth rebutting -- as far as I know, it's all correct.
What does that prove? I believe it shows the validity of my arguments, especially the one about how large, monolithic applications are more likely to be very difficult to secure than smaller ones built out of discrete, interchangeable components, like qmail, all else being (pertinently) equal.
My guess is, people concerned about security would flock, like birds not flies, to its source code, find out it was a stinking pile of dung, and, not being flies, decide they'd have to start from scratch rather than spend the rest of their lives trying to secure something like that. Which is probably why we now have qmail, an alternative that is radically different from sendmail in almost every way, except they both are "free software" in most ways. How many alternative MTAs for Microsoft OSes came into existence because security-conscious people looked at the source code of Exchange (or whatever it's called) and decided to start from scratch, I wonder?
(And, of course, an app like sendmail is much easier to usefully distribute in proprietary form than one like qmail; the latter is too easy to reverse-engineer in digestible chunks.)
For the same reason Ford "lets" people drive drunk? It's the government's job to protect people from each other--not Microsoft's.
Yet, as I pointed out, Microsoft certainly took it upon itself to not let people print pictures it decided they might not have a legal right to do so.
Therefore, by allowing non-admins to easily enable IIS, they have about the same level of culpability as would Ford if it made sure that any 5-year-old could successfully turn on and drive an Explorer as a means to ensure wide market share.
Remember, I made a fairly broad point about Microsoft, and other proprietary-software vendors, effectively disarming customers (willingly) by not allowing them to see the source and find/fix/discuss the security problems themselves. Do you truly see no additional culpability coming upon these vendors or their end users as a result of this unilateral disarmament against enemies who, in some cases I would think, did not similarly disarm?
Note I am not talking about legal culpability, nor trying to make a distinction regarding exactly who -- MS or a given MS customer -- is culpable. Certainly Linux developers and users aren't culpable for bugs in MS IIS, and I argue that, in the combination of IIS users and MS, its distributor, there exists substantial culpability for any security flaws that are exploited by black hats and that might have been usefully exposed earlier, had the source code been widely and publically available.
However, I guess I do hold MS and other proprietary-software vendors culpable for willingly creating an environment -- a market, if you will -- in which end users don't believe they should care or know about the very concept of source code, the security implications of not being able to view it, etc.
(Sure, they "just wanted to make a profit", which is fine, but let's not allow that priviledge, or right, to cause us to overlook the fact of their culpability by taking the actions they did, especially since that would disadvantage those vendors who did strive, more than others, to inform their customers regarding security concerns, give them some degree of access to source code at least, and so on. Just because a company X does Y to make more profit does not mean we can no longer discuss whether Y contains unfortunate, even "evil", portions. That is, I'm not debating the evilness of corporations -- I'm trying to clarify some issues I believe you've obscured in your posts regarding the value of the respective forms of software generally.)
Microsoft was not expecting a bug in their IIS server anyways.
Then the company is run by fools, which I doubt. Proper engineering, especially of large, complicated systems, includes assuming there will be failures, and handling the risks accordingly.
(You seem to not know much about software engineering, based on statements like that and the other one you made about kernels not being interchangeable. Are you seriously trying to tell people that, without understanding even the most basic concepts of software and vanilla engineering, your views on security trump those of us who do have some understanding of these issues?)
You do have to back up your claim because the original poster implied (if not outright claimed) that open source produced software that was more secure than proprietary.
I need to back up my claims because of something someone else said? Bah.
Besides, here is the first chunk of text to which you responded, as written by the original poster:
Closed source can be perfectly good at closing holes, if the company is as big as Microsoft. But Open Source is much better at closing those holes before they are shipped: many eyeballs make all bugs shallow. Open Source doesn't catch every bug, of course; but enough are found that when the odd hole is announced, it is a big enough deal that the patches are more likely to be installed.
Seems like the author of that quote left himself plenty of wiggle room between what he said and what you claim he "implied". I don't know if I'd say it quite as he did -- perhaps he has experience and expertise I don't, to back up his claims -- but I agree with the general thrust, yet don't see him as quite saying that open source produces more secure software than proprietary (a statement that can be interpreted in so many ways, it has little meaning at the point we're at, which amounts, nearly, to debating how many angels can dance on the head of a pin).
An example of one thing to which you have not responded is something I consider to be pretty much an "endgame" in a discussion like this, and that's the fact, pointed out by the original poster and myself, that no proprietary software (of the type that needs to be secure) is ever shipped after its source code has been widely available for open discussion, for testing, even for modification, by the general public. Yet that sort of activity is typical for equivalent free software, which goes through alpha and beta releases in which the source code is, put simply, "there".
Do you really, truly, honestly believe that having the source code widely reviewed and discussed by people with no financial interest in simply parroting a corporate line about security offers no substantial advantage in terms of ensuring there aren't fundamental, or even obscure, flaws in the design and/or implementation of the product?
If you do believe that, then you believe that all the bugs found during the alpha and beta periods of free-software products (including mine) were pretty much irrelevant, or would have been found anyway, i.e. without the source being available.
In that case, I can tell you first-hand that your belief is utterly without foundation. But unless you want access to my email/USENET archives, or wish to explore Linux kernel and other archives yourself, to research the importance of source-based bug-finding during alpha and beta test periods, you'll have to either a) accept that your belief is unsubstantiated or b) call me, and probably plenty of others like me who've developed free software, liars.
So you are saying lets not innovate?
Sheesh, more strawmen. Of course, I never said that. I did point out that free software gives users more choice as to when and how to innovate, upgrade, and so on. Why you insist on excluding the middle ground is beyond me, unless you really care more about appearing to win an argument (using whatever means are at your disposal) than actually learning something that might challenge your cherished assumptions.
I'm sick of Slashdot readers with their holier-than-thou attitude spreading FUD about proprietary software.
Then stop reading/.. Seriously. In fact, you might as well drop the last two words from your sentence, or the last five, or even just use the first five, to say all you, or anyone else, need say. Most of the time I'd probably agree.
The mistake I think you made is picking the wrong example, and the wrong people, to respond to as if they, and we, were "typical" of the stuff, and people, you're "sick" of.
Further, if you're thinking that/. readers somehow represent a coherent viewpoint on this or any other subject, dispense with that notion immediately. It's foolish to believe that of almost any group of more than ten people, much less one of more than 100,000, even if they are voluntarily and freely choosing to air their views in a particular forum.
I'm not trying to sound harsh or have an attitude.
I don't know which is more disturbing: to believe you are exerting an effort to do so, or to believe you aren't.
That is a far cry from denouncing all proprietary software as insecure based on just one vendor (MS).
Another strawman, since neither I nor the original poster made such a denunciation.
You can not prove beyond a shadow of doubt that the source code you have in your hand (drive, whatever) is 100% secure.
More excluding of the (incredibly wide) middle ground, in which a 99% assurance after a careful audit of clean source code is preferable to a 10% assurance that consists entirely of the vendor saying "yeah, it's secure", plus whatever experience in the field might be on hand.
You might also wish to investigate a concept called "proof-carrying code", and similar "proof-based" systems, and compare their deployability in a) a proprietary-software world versus b) a free-software world.
You seem to not trust proprietary vendors, and I do think this has much to do with Microsoft's behavior (and their negative image).
I can understand why you'd have that impression generally, but it does not apply to me. I use Microsoft in my examples of reasons to distrust proprietary vendors solely because they're such a well-understood target. But my experience goes back much further than that.
I remember discovering a bug in 64-bit floating-point comparisons in a (rather obscure, thankfully) computer (I worked for the company designing and building it at the time). Something like, if the difference began in the 33rd bit in a certain direction, the result of the comparison would be wrong.
When I pointed this out to the VP of Engineering, he made it clear the company would not be issuing notifications to the customer base, and certainly not replacing the CPUs already in the field to fix the problem, despite the fact that those particular machines' main selling point (compared with other offerings) was that they did 64-bit floating-point "natively".
How is this kind of willful ignoring, and refusal to communicate to potential victims, of the problem possible in a free-software development project large enough to support most pertinent products? (Even though I described a hardware flaw, I've had similar experiences, though harder to explain simply, in proprietary software companies.) The answer: it pretty much is not possible, because authors of free software simply aren't that interested in hiding information, especially info of that sort.
(Proprietary-software vendors, of course, spend significant human, financial, and legal resources ensuring all their employees, contractors, consultants, vendors, and so on, know the importance of keeping things secret -- even things that could be life-or-death issues.)
I seriously hope you do not go around looking at the source code for the Linux system to find flaws.
Um...why not? In fact, I did casually scroll through some Linux kernel source code around 1992 or 1993, found a bug involving group (vs. owner or world) access in the filesystem, reported it along with a proposed fix, it got accepted.
Why would you have a problem with that?
As far as I can tell, there are a variety of projects around the world that consist of people writing tools that look for certain kinds of bugs that compilers don't find in source code, and using GNU/Linux source code for input. These tools will not likely get run by proprietary vendors (besides, if they do, how will you know for sure they've been run and the results used to improve the product?); certainly their output won't be published, as it has been for the Linux kernel, at least. (Wish I could remember the name of the one project like this I'm sure came about this way, but if you skim Linux kernel discussion archives, perhaps you can find it.)
If you take into consideration the large number of Linux programs then the "eye-count" becomes diminished quickly.
Hey, I "get" your points, but they don't stand up to historical scrutiny, which you can't exactly be blamed for not realizing, because they draw no useful lines beyond which the value clearly diminishes to the point of irrelevency.
Specifically, ten-plus years ago, your predecessors (on newsgroups like gnu.misc.discuss) used pretty much the same logic you're using to explain why free software might have its "niche", beyond which it could not possibly expand, due to lack of resources, qualified programmers, etc.
Examples of things free-software solutions would "never" exist for, from memory (and some of this goes to before google/dejanews coverage of gnu.misc.discuss, which I gather is circa 1994, but I've got my own private archives):
Operating system kernels (too technical, too few people with enough expertise, wouldn't be secure since nobody would bother with things like code reviews, i.e. no OpenBSD project would exist)
Fortran compilers (not sexy enough; I fixed that one myself;-)
Decent GUIs (i.e. no Gnome or KDE at all, certainly not two completely independent and competitive projects!)
(I know, I know.. free software can make money by selling support, but this is capitalism. Make as much money as you can, right? Which leads to more ignorance; users aren't aware that cheaper alternatives exist. In many cases, users really do not care whether they pay extra or not. They just want the computer to "do as I say").
In the paragraph containing that parenthetical statement, you express much hope/optimisim about proprietary software, which might not be unfounded, but I'll note two things:
It's not clear to me proprietary vendors are going in the more lenient direction -- in fact, things like the DMCA, plus inferences based on what the MPAA and RIAA are doing (and getting away with), suggests that the vendors that succeed will be those that lock up their software even further, by "hiding" it behind network-based services (.NET?), putting even more legal and practical constraints on finding and openly discussing flaws such as security holes, etc.
To the extent such vendors do go in the direction you hope, the less they become distinguishable from free software anyway. (You've got to look beneath the labels in some cases, e.g. qmail, especially when making assessments like we're making.)
Regarding the parenthetical statement, especially the part about capitalism, if you are interested, and can be really nice and stop creating strawmen, claiming I said things I didn't (instead, please just quote, okay?), I'll be happy to respond, probably via email, since you might find my views on that subject (free software vis-a-vis market forces) fairly interesting, if not convincing.
I don't know enough about DMCA
It's worth your time to explore it, and learn who supports it, and why -- even just for the security implications of what you'll find out. (And I admit to knowing only a bit of what's going on, but enough, IMO, to speak somewhat authoritatively on the intersection of issues we're discussing.)
Re:djbdns is NOT free software
on
Windows in 2020
·
· Score: 1
But see why what Dan believes about software law strikes me as making the "breaking" of freedom 1 primarily a technicality, when it comes to software copyrighted by Dan himself, at least.
What exactly does your (and other poster's) argument, or need, for a different vendor of the same product have to do with security?
Excellent question. My best shot at an answer right now is that security (in the context of our discussion) is best achieved through a combination of factors, including robustness, clean, simple, unfettered design, solid engineering, and so on.
Components that demonstrate the ability to be interchanged with and for other components, especially those from other vendors, especially in the presence of specifications and standards agreed upon by the industry as a whole, tend to better demonstrate those very qualities.
I can also guarantee you a Linux system with FAT32 support. That does not make Linux a Windows machine, now does it?
No, of course not. What it does illustrate is that FAT32 is not so inscrutable and poorly designed that alternative vendors can't support it, and that whatever security failings it might have (and I don't know much about that offhand) are more likely to be well known and well documented by the very fact that someone else, in this case multiple other "vendors", have employed it as an interoperable component.
Where can you get the Linux kernel in FreeBSD? BeOS? NT? The kernel is not an interchangable part like an engine can be.
Sorry, you're very wrong about that. There's a reason some of us call the system "GNU/Linux" (other than the fact that some wish to associate with the popular name "Linux" the GNU name) -- because there is every possibility of creating an operating system based on the Linux kernel, but using utilities that are sufficiently compatible with, but not themselves, of GNU origin.
Ditto for GNU/Hurd, a GNU system with Hurd as its kernel. A kernel that could be used as a component in a completely different system.
Here's where you see the kinds of qualities expressed by a component that guide you towards an increased assurance regarding its security: since the Linux kernel is deployed on a huge number of devices in a form not consistent with the usual definition of "operating system" (say, in embedded devices), and since GNU utilities are widely deployed, or used to deploy, other systems that are neither GNU nor Linux, you have more assurances that both GNU and Linux are devoid of fundamentally unsound, undocumented security failings in design, and are less likely to have undiscovered bugs in their implementations, compared to proprietary-software components that don't interoperate as well.
Nor is the kernel always an open design.
What's your point? Linux, many *BSDs, Minix (?), and the Hurd are all examples of open-designed, maybe even free-software, kernels. And they enjoy a great deal of interoperability with each other, compared to almost any two proprietary kernels you can name (even two Microsoft ones, I'd guess, but certainly, say, WinNT's versus MacOS6's).
But even non-open kernels, like Solaris (I assume) and HP-UX (I'm even more sure), gain some assurances by interoperating as well as they do with the GNU utilities, and vice versa. Ditto, but not as much, for Windows and GNU, since (I gather) the Windows ports for GNU utilities are, for such a successful system, rather hard to do and still (?) somewhat incomplete.
The implications of the Windows/GNU combination include that if there are security mechanisms that are incorrectly placed in Windows, i.e. placed in a portion of userland that is replaced by a GNU utilitiy when it should have been a kernel mechanism, that will be more quickly exposed and easily demonstrated via a combination Windows/GNU system. It might even be discovered by the authors of the Windows port for the replacement GNU utility -- a great example of a "white hat", one can reasonably assume, making an important discovery, one which Microsoft would, like as not, be unwilling to expose, even though "it" would certainly know about the failing.
Further, while I've focused on the objective factors, or qualities, of deployed components, I suspect the real payoffs come during the period in which real people construct systems that use your components in ways you didn't plan, even when they toss out your component in place of another.
At times like that, they're more apt to notice, and more willing to question, document, publish, things that might be failings in your design or implementation -- perhaps based on assumptions you made regarding the components with which your component would "always" be deployed.
Further, the very act of focusing on designing and deploying an interchangeable component (much more like the Linux kernel, or the Apache web server, or qmail as well as its subcomponents) as versus a component that's intended only for use with a much larger monolith (much more like the Windos kernels, the IIS web server, or MS Exchange) causes the developers to think carefully about the exact sorts of interface and "border" issues that greatly affect real-world security. (Think about all those web-site security bugs that stemmed from the developers really believing the user's browser was actually a component in their web-site's monolithic "experience". The result? They'd shovel info to the browser for the user to interact with, then foolishly trust the (modified) information that came back, as if the user couldn't change it however they liked, even beyond what the web site's JavaScript (or whatever) was designed to allow.)
After all, the small-component developer must think first about things like "how do other components like mine work? how is it made secure? what are the pitfalls?", while the monolith-component developer tends to think about things like "the monolith will provide security; the monolith will make everything work; we needn't look at pitfalls of other systems, since this is a new, wonderful system unique from all the rest".
Which mind-set do you honestly think more describes that of the typical developer of widely deployed GNU/Linux software, and that of the typical developer of widely deployed Microsoft software?
Having plenty of experience in and with both worlds, I know the answer in specific cases aren't always clear-cut, but, overall, it's the monolith-creating culture that is more willing to ignore history and reinvent the wheel. (There are those in the component-creating culture that do that, too, but they rarely succeed in making their component important in deployed software, because they can't force it to happen so easily.)
But you forgot one important detail: not everyone is a programmer.
Can you point to a single thing I said that shows that I "forgot" this one important detail??
The fact is, I'm acutely aware, and have been since about age 12, that I'm somewhat rare in being able to read source code.
My reason for posting what I did was not to convince you, it was to counter the propaganda you posted, so others may realize there are other views, may consider the various sources for those views, and do the research, or at least the thinking, for themselves.
To meet that goal, I need not back up everything I say, any more than you did in your claims about the security of proprietary software as a model, or in any of its specific forms.
I was pointing out that people with the virus are ignorant end-users.
If they're "ignorant end-users", why is Microsoft letting them run a web server on a hostile network, allowing their systems to become launching-pads for further hostile actions against other systems?
My point is that Microsoft exerts vastly more control over the computing environment of Microsoft users (and willfully so) than any combination of GNU/Linux/*BSD/CPAN authors do over the computing environment of their users.
(As one example: Microsoft's encyclopedia software -- "Encarta"? -- disables printing of illustrations on the user's screen, apparently to satisfy some intellectual-privilege concern. I discovered this when trying to help a friend who wondered why he and his children could print some pictures out on their inkjet printer, but not all. If MS can be so conscientious about deciding, on behalf of the user as they'd surely claim, that he shouldn't print something since he might turn around and get his $100 inkjet printer's output reproduced in a national magazine without paying the licensing fee, they can certainly disable IIS for users who haven't proven they can "handle" deploying such a product on a hostile network like the Internet.)
Therefore, Microsoft and other proprietary-software developers have taken upon themselves much more responsibility for their software being insecure, out of the box, than free-software developers, because they restrict the freedom of their users to actively engage in the sorts of open discussions and reviews regarding security that are day-to-day happenings in the free-software world.
Free software is about freedom, and that and related values are what are willingly and fully extended to all end users of that software. Microsoft (and, generally, proprietary) software is about profit, but more to the point, about control, about restricting freedom of the users of that software.
To pretend that the security implications of those two very different world-views are negligible or non-existant is to delude oneself.
(Note that I have made no claims about either approach being inherently "good" or "evil". My point here is focused simply on the fact that when you put the user in a straightjacket, you, the proprietary software developer, are responsible for the care, feeding, and shelter of that user, as well as for the violence committed by that user when you allow someone else to "infect" them with some virus and fail to restrain them, especially if you allow them access to a button they can press with their nose that is labeled "Destroy Internet". Those who refuse to put users in straightjackets, yet who are willing to provide them food they can freely use as they see fit, ditto for shelter, ditto for care, ditto for recommendations as to how to avoid accepting the intellectual, or software, equivalent of viruses, have nowhere near the same level of responsibility for their behavior. They do not have zero responsibility, however! But, in allowing their end users freedom, they give them much better defensive weaponry to use against those engaging in bad behavior, which is why those of us who run GNU/Linux, for example, aren't nearly as directly affected by badly-behaving proprietary software as are users of different proprietary software -- we haven't accepted unilateral disarmament as have they.)
I am arguing proprietary software does not equal insecure, and open source does not equal secure.
With that I almost wholeheartedly agree. Except, as I pointed out, proprietary software never equals "objectively provable as secure", since the general public can never be allowed to see the details of how it works and discover security flaws for itself.
If the software shop refuses to fix a security problem...
You went off the point there. It was you who made the claim that free-software fixes aren't always funded, whereas proprietary-software fixes are. (That is a reasonable inference from the symmetry of your earlier quote.)
So, I was not arguing against the free market, or capitalism, or libertarianism, or whatever other red herrings you wish to throw into this argument.
I was simply pointing out that being dependent on free software means depending on someone, somewhere in the world, being willing and able to fix problems for you when they come up (whether they are already an employee of yours), whereas being dependent on proprietary software means depending on such a person being found (and funded) in, what, about.00001% of the world's population. (This is my attempt at a quick calculation based on an assumption of 6000 people in a typical proprietary-software company vs. 6 billion people worldwide. Of course, the entire world's population isn't capable of fixing software bugs, but the percentage that is probably isn't vastly lower than the percentage of employees of a typical software company, in my experience.)
Further, unlike the corporate environment of a proprietary-software developer, in the "real world" there is no manager threatening someone for termination if they go ahead and fix a problem based on a customer complaint. (Believe me, I know both sides of this issue very well; I've been "reprimanded", or at least hassled in performance reviews, for taking time to provide very-well-received fixes for customers, as well as for in-house users. The free-software world does not revolve around such archaic constraints on human activity. Yes, I ultimately responded to such exercises of managerial oversight by leaving the organization -- at which point, I became incapable of rendering similarly fixes for those same customers in the future! I have no such limitations placed on me when I decide to leave a free-software project like, say, g77.)
Upon which pool of available talent do you (not the poster, but the/.-reading public out there) wish to restrict yourself, in finding solutions for your computing problems, such as inadequate security -- the entire world's population, or the approximately.00001% of that population whose only real "claim to fame" is that, if they help you, there aren't probably breaking the law as well as pulling rabbits out of their hats by hacking binary code with no source available?
Buy a new computer, perhaps? One that can run the newer software.
In other words, when the software you paid for the privilege of using, but not studying or improving, fails, you have to not only buy some next-generation form of that software, but newer computers to run it?
The answer is: of course that's true, for proprietary software. That's why, of the reasonably high number of 486 CPUs out there running in production mode as mail and web servers, a vanishing percentage, I suspect, run proprietary software for those apps -- instead, they probably run a Linux or *BSD kernel, Apache, qmail, etc.
That's also why my wife's organization's IT facility decided to finally convert over from Macintoshes to IBM PC machines to address the Y2K problem. Because Macs were not Y2K compliant? No, because Microsoft Excel, the version they were running on their Macs, wasn't, and to get a version that was that would run on Macs, they would have to upgrade the Macs themselves anyway, so they "might as well" switch to the more "dominant" architecture.
That is, they punished the company that produced a largely-Y2K-compliant system and rewarded the one that boxed them into a corner by creating Y2K-buggy software for years. That's exactly the kind of perverse result one would expect from depending on obscurity rather than openness.
Of course, if they'd had the source and the freedom to hire whoever they wished to fix it, they could have had the choice to fix just the Y2K problem in Excel and continue running it on their old, but perfectly-working, Macs.
Again, you are bashing Microsoft with "M$."
It's a common abbreviation I usually succeed at avoiding, but used, what, once in that entire post?
I claim your posts contained much more, and largely uninformed or gratuitous, genuine bashing of free software than mine did of Microsoft.
Disclaimer: my sister worked for Microsoft for many years. One of her positions included Lead Program Manager for Internet Explorer version 5. And I've been a longtime proprietary software (and technical-documentation) developer. I speak on these issues not so much to advocate one side or the other, but to rebut the misinformation that's widely circulated (by people such as yourself) regarding the respective software paradigms.
And what, the original poster gets away with implying Microsoft is representative of the security-conscious?
I don't know if he did that, but your response equated the single source of unexaminable, yet widely-deployed (on a hostile network, no less) software with one of the sources long known to be a poor choice, from a security perspective anyway, among many choices for software that does not come widely represented (and heavily marketed) as a "one-stop shop" for ordinary people to get on the Internet, run web servers without sysadmin experience, and yet be responsible net citizens, from security and other perspectives.
Anyway, if your point is that people who say "Gee, if these folks would run free software, there wouldn't be so many security problems" have some serious flaws in their arguments, I agree wholeheartedly. But I don't say they're wrong, per se, just that statements like that often are oversimplified to the point of being, at least nearly, useless.
(Fortunately, there isn't a $Billion advertising budget behind that message coming from free-software developers, so the importance of rebutting the arguments from that source seems, to me, to pale compared to that of rebutting the arguments coming from other, well-funded, sources.)
Your lesson for today: learn there are other proprietary software vendors than Microsoft. I was only using MS because this thread is about their product specifically. The original poster implied that OS was inherently more secure than proprietary, and I still refuse to accept his or your reasoning.
Your arrogance is really over the top. I, of course, have worked for many proprietary-software developers, none of them Microsoft, but can't help noticing which one has survived and flourished as what most people think of as the source of software enabling them to access the Internet.
And while I agree that free software isn't, at the level of instantiation (that is, instances of free software), inherently more secure than proprietary, I do claim that it's inherently more secure as a model for software development and deployment.
Further, my impression (definitely devoid of necessary research to support it) is that, in the free-software community, well-designed, secure software is a much better predictor of deployment, especially over the long term. Look at how "poorly" qmail is "marketed", yet its installed base is pretty amazing.
After all, let's review another statement you made here:
What I am defending is the numerous secure proprietary software out in the world.
Name one. Name one that you can show is secure, in a public forum, by reviewing the most important material that should come into evidence: the source code!
And that's the crux of the debate we're having. Ultimately, you believe that security through obscurity, in the form of not only obscuring algorithms, but obscuring the fact that proprietary-software developers have a form of relationship with their customer base that cannot, even under the best of circumstances, be described as "demonstrably committed to mutual security", is the best solution. (I use "committed" in the sense that "when it comes to ham and eggs for breakfast, the hen is involved, while the pig is committed". Proprietary-software developers do exist that provide some degree of commitment to the security of their customers' installations, but that commitment is, in my experience, "earned" via distinct payments and other consideration, compared to the software they sell. That is, the mere act of acquiring and deploying proprietary software rarely earns a customer any useful commitment from the vendor regarding security. The same goes for free software, in spades, of course, but with free software the customer has not only the original vendor to go to to purchase additional security commitments, but pretty much anyone else in the world, since he has access to the source code, to open forums for discussing its security, and to source-level patches to improve and/or test that security.)
I believe that security, especially in the context we're discussing (security of systems on an open worldwide network like the Internet) is best, perhaps only, achievable through openness, in the form of open review, discussion, and testing of the models used to enforce it and the software that is written to support it.
And with the model I choose, it doesn't matter nearly as much how "friendly" a software producer is with a given software consumer, since the latter can always review the source code himself (an option that, obviously, includes paying someone to do so).
Note that I'm not representing myself as an expert on security. If you want to get an opinion from one, ask him this question:
"All else being equal, would you rather choose, to secure an installation, a one-stop-shop-type monolithic solution from a single vendor, said solution's inner workings being kept secret from you and nearly everyone else, with your being legally and practically preventing from exploring its workings, perhaps even from seriously
testing those workings? Or would you prefer to choose among a wide variety of openly developed, deployed, discussed, and tested components of an overall solution that you can either design yourself, hire someone to design, or some combination in between, where each component's inner workings is fully available to not only you, but others in your profession as well as the general public, and can, and have, been tested in open forums, with both successes and failures reported in said forums?"
I'm purposely comparing the two extremes on the continuum between free and proprietary software (and it is a continuum), but the answers from most security experts will, I believe, point to the end of that continuum that most directly coincides with free software, and rarely coincides with any particular proprietary-software solution.
Further, to the extent proprietary software tries to emulate particulars of free software in this continuum, to achieve more favorability, it becomes less proprietary. In particular, the financial advantages that accrue to the typical proprietary-software developer tend to diminish, in favor of advantages free-software developers already enjoy. At that point, as a customer, you're going to be paying the proprietary-software developer more to offset those losses (as calculated by the vendor) anyway, so you have even more funds to consider devoting to deploying free and open solutions instead.
After all, it isn't the free-software development community that pushes for things like the DMCA, is it?
Re:Here's how open source would be better...
on
Code Red: the Aftermath
·
· Score: 1, Insightful
Fact: Free software (sometimes aka Open Source software) is typically released to the public after anyone in the world has had plenty of opportunity to examine the source code of that product, try it in beta installations, beat up on it, and openly and legally discuss its performance, security, usability, and other metrics.
Fact: the same things almost never hold true for proprietary software.
Fact: Free software does not "produce more secure software than the proprietary world" per se, though such a poorly-worded phrase is often used in place of the truth, which is that free software, compared to proprietary software, i.e. when comparing software distributed to end-users (as versus in-house use only), has a greater opportunity to reach high assurances of being secure when comparing categories of software in which security is important.
For example, compare your personal ability to vet the security model of qmail vs. any of Microsoft's mail-server offerings. "They" can assure you of MS's "security", just as "we" can assure you of qmail's. But, of the two, only qmail allows you to legally examine the source before ever having to enter into a contract allowing you to do so; to discuss findings with others, out in the open; to beat up on it in a test installation before committing to a purchase (and remember that such purchase is typically followed by a strong urge to justify said purchase, rather than prove it to have been an incorrect decision); and so on.
Fact: that "people with infected IIS are not admins" is irrelevant. Given MS's position in the marketplace, I suspect they could easily ensure that only true admins would be allowed to run IIS on the Internet. (After all, they use imposing legal language to bind "licensees" to contractual requirements designed to improve MS's bottom line and warm cuddly feelings of "protecting their IP", right?) At least, they could surely make it less likely that non-admins might "accidentally" deploy IIS on an Internet-exposed host. Why don't they do this? Because they prefer playing both ends against the middle, as most businesses do -- "anyone can buy and use our products" on the marketing end becomes, on the customer-service end, "you must be doing something wrong". (Yes, there are those who claim GNU/Linux is "ready for the desktop" and such like that. Why believe them? Why not investigate these claims for yourself? I claim that since everyone has the freedom to do that with free software, such claims have nowhere near the "guilt" for security breaches that a company like MS does when it makes similar claims about what, to most everyone else in the world, is a black box -- its proprietary software.)
Fact: While it is indeed not always true that people are paid to fix free software, the exact same thing is the case for proprietary software.
The difference is, if you're depending on a free-software product that isn't being maintained by someone for $$, you have the option of hiring someone to do the work.
Whereas, if Microsoft decides, as it surely will down the road, to stop paying its programmers to fix IIS, or Windows 2000, or DOS 5.whatever, you'll be out of options if you have failed to follow the M$-recommended upgrade path.
Fact: Red Hat does not, and has never, represented the security-conscious administrator's #1 choice for a default system installation of GNU/Linux.
Fact: If you find Red Hat's choice of configuration (which I think has been improving lately; I've been using it for years) unacceptable, you have many other choices for where to obtain distributions, versions, and configurations of the Linux kernel specifically, the GNU system generally, and other free-software systems as well.
Challenge: name three vendors from which you can obtain the Microsoft Windows 2000 or Windows NT kernel in a distribution as fundamentally different from Microsoft's as Debian's, or SuSE's, is from Red Hat's.
Okay, make it two vendors. Okay, make it one vendor other than Microsoft. I'd sure love to know if they license their kernel to other software-distributor outfits to wrap with their own chosen apps, using their own chosen configurations, etc.
(And note I haven't even mentioned OpenBSD yet!)
Fact: to preserve their advantage in IP investment and security, proprietary-software distributors have an incentive to create packages as large, complex, monolothic, and, therefore, difficult-to-reverse-engineer, as possible. Free-software authors, like any software author, tend to create large, complex, monolothic programs due to natural tendencies, but they don't have nearly the bottom-line incentive to do so. That is, as their expertise, their sensitivity to security and complexity issues, might lead them to producing simpler, cleaner, more "transparent" products like qmail, they won't be rebuffed in their attempts to go down that road by managers and lawyers saying "we can't make it that easy on our competitors to reverse-engineer our IP".
Consideration: most proprietary software, especially in wide (therefore profitable) circulation, especially the sort of software where Internet-exposed security is an issue, performs some kind of license-checking to prevent "piracy" ("unauthorized coveting of intellectual privilege" is IMO a better phrase), whereas hardly any free software does that sort of thing. Which choice poses a greater security risk to the overall system, in terms of things like resistance to viruses, worms, etc., degree of inviting reverse-engineering of obscured code, etc.?
Opinion, mine: in the end, proprietary software stands opposed to secure software, because for software to be secure, it has to be easy to publically validate as secure (i.e. be validated by any third party without contractual agreement, thus allowing that party to speak freely about security concerns), whereas, for that software to be usefully proprietary, it must be obscured, intentionally, by the distributor.
Observation: The current method of choice proprietary software vendors use to obscure the IP they release into the wild is to compile and link it down to machine code and cross their fingers. With non-programming forms, they have to resort to even less workable forms, such as encryption. ("Less workable" because compiling to machine code generally makes the end product run faster, and because today's dominant software-development paradigm is predicated on the need to be able to strip out source and other "redundant" code, whereas encrypting other forms of software tends to make them less immediately useful to the end user, who then needs a more sophisticated engine to reveal the purchased IP.)
That some vendors are increasingly resorting to the legal system, rather than on complexity alone, to keep their IP obscure, does not change my claims at all -- however the software is obscured, the very act of obscuring it defeats the goal of making it secure.
(Though, as with firearms, to the degree laws are used to prevent access to source code, access to source code becomes something much more closely associated with those contemplating lawbreaking, rather than those merely very interested in learning about, and gaining expertise in, the relevant technologies. "When source code is outlawed, only outlaws [and government] will have source code." Think about the security implications of that situation, and ask whether you wish to visit houses, office buildings, and skyscrapers whose blueprints are "secured" in the same fashion.)
Hmm, I just signed up for AT&T Broadband, and it was quite clear in the FAQs and other-such things that the answer to the question "Can I run a server?" was "NO!".
For now, that's acceptable to me, and since it's a month-to-month thing, I'll go along with it...until and unless the time comes when my expertise and desire to set up an HTTP or FTP (or SSH?) server exceeds their willingness to allow me to run it (both legally, i.e. according to our mutual agreement, and technically, e.g. by not blocking the pertinent ports).
(Haven't decided yet whether to move my web site from my current ISP to one of these "AT&T Personal Page" thingys, but probably won't. I'm budgeting on the assumption that I'll pay for both AT&T Broadband access and my existing ISP, since the former is fast, while the latter has more than a clue about UNIX systems. The installation won't happen for another couple of weeks, by the way.)
Re:That's the worst idea I've ever heard
on
Fight Virus With Virus?
·
· Score: 2, Interesting
the principle of not fighting fire with fire is still reasonable
Are you unaware that firefighters often do use fire to fight fire?
(They burn away strips of forest to prevent a forest fire from being able to cross the strips and attack, say, neighborhoods.)
I think your comment in the next paragraph is right, though, because it illustrates the weakness of the forest-fire analogy.
In particular, while fighting viruses on the Internet today might be more like fighting a forest fire -- in that the trees are not "smart" at fighting fires, you want to save as many as reasonably possible, yet you're not averse to burning a few more down yourself to avert a larger disaster -- the overall goal should be to convince Internet sysadmins to do for their systems what homeowners and business owners have, over the centuries been encouraged to do: be the first line of defense against fires starting, or offense against fires spreading, etc.
(Think of elements of "progress" here -- new homes likely have smoke alarms, people are strongly encouraged to report fires quickly, flammable materials are less widely used, buildings are designed for quick exit in the event of fire.)
Until the Internet resembles something more like today's upscale suburban neighborhood (in its security against fires) than a dry, dense forest, I suggest that fighting fire with fire does have utility, if thoughtfully (rather than arbitrarily) applied by experts.
IIRC, when I first registered with/., I used my "real" email address ("craig@mydomain"). But for most of my time here, I've used "craig-sd@mydomain".
Not only do I get plenty of spam to "craig-sd", but plenty to "sd" as well.
I don't think I ever used "sd@mydomain" here myself, so perhaps some harvester munged addresses gathered over the web and it got committed to CD-ROMs sold worldwide, 'cause I've been getting spams (to both addresses) for a long time now.
(Of course, once they get tedious enough, I can filter them here or, better yet, upstream at my ISP.)
Huh, while I'm thinking about it, might as well change my email address here to a new (munged) one.
Feel free to point people to my web page on chain email. I have a small, but encouraging, amount of anecdotal evidence that it has managed to encourage a few people to break the habit.
Whoa, yeah, you hit the nail on the head with that last point especially -- it's easier to destroy than to create. And people seem more fascinated by destruction than creation too! (Well, I guess that's debatable; sure, some people like to see other people die in entertainment forums, but one could argue that there's far more profit in showing the act of creating human beings.;-) Basically, the three laws of thermodynamics do give the advantage to those who seek to destroy vs. those who seek to preserve.
For attackers seeking to obtain value, however -- not so much teenagers trying to disrupt things as people trying to break in and steal stuff -- that equation is less helpful, because acts of destruction don't preserve the value they're trying to obtain, and might tend to leave a trail, be noticed earlier by defensive systems, etc.
I think I did say something about vandal-type attacks -- like suicide bombers, they're much harder to stop, even if they're much easier to detect once they begin to succeed in their efforts.
However, I feel that's basically orthagonal to the meatspace vs. cyberspace issue, as well as the OSS vs. proprietary-software issue...
...though it does connect with another point I made about the importance of a lawful society in terms of maintaining a "positive" balance in favor of law-abiders vs. law-breakers, in that a more lawful society, especially if the laws are more likely to be simple, useful, etc., is, I think offhand, less likely to generate, and perhaps even less likely to be a target of, vandal- or suicide-bomb-type attacks.
(Not the part about the comparative ease of exploiting security holes in source code vs. binary code -- the part about OS advocates somehow "always" forgetting that fact.)
In my experience, advocates of open source are highly aware that it's easier to exploit security holes in source code.
After all, to do that, one must find them first, correct?
And unless most or all of the people looking for them also intend to exploit them in an offensive way, the result will be that said holes will be fixed in a defensive mode vs. offensive attack faster than for proprietary, binary code.
Remember, defense always has an advantage over offense, in terms of time and effort -- the "battle" is on the defender's own turf. Offense can make up for this inherent disadvantage to some extent by, for instance, having the element of surprise.
For most such offensive counter-measures, having the source code is not an advantage, in fact it's a disadvantage, if the defense also has the source code.
That's because the defense can deploy fixes to holes faster than the offense can attack them, so, assuming they both find out about them at the same time, the defense wins. (This is generalizing, by the way. Specifics always vary, of course.)
Now, ask yourself this question: when it comes to binary-only code, who is likely to know more about the internal operations of the code -- the defense, in this case, law-abiding users, or the offense, willing to obtain THE SOURCE CODE through illegal channels??
That's why Open Source has such an advantage here -- the defense, collectively, is encouraged to share, generously, insights about the software, while the offense must remain fairly isolated (a general rule about law-abiders versus law-breakers; while law-breakers sometimes pool their resources, they have an uphill battle with regard to such activities compared to law-abiders, who can do their pooling in the open and/or in hiding).
When it comes to proprietary software, law-abiders are increasingly discouraged from sharing insights, info, breakages, fixes, etc., while the opportunities for pooling resources on the law-breakers' side remains pretty much the same.
But there's a special prize law-abiders are denied that law-breakers have the opportunity to exploit should they gain access to it, when it comes to proprietary software: the source code.
Once they have that -- and they will, if the software "matters" at all -- the law-abiders will be on the losing end of things.
"If source code is outlawed, only outlaws will have source code."
Assume the following paragraph did indeed appear in the license, as quoted in another post:
Redistribution and use in source and binary forms are permitted provided that this notice is preserved and due credit is given to the original author and the contributors.
I believe that it is not unreasonable for a lay person to conclude that modification is implicitly permitted, since what is explicitly disallowed is a specific form of modification -- that of removing the notice.
Further, asking for "due credit" to be given suggests a general sort of modification to any redistribution, the wording itself up to the entity performing the modification, as long as it constitutes "due credit".
Now, a lawyer representing someone considering redistributing a modified copy of software under such a license would probably point out that such a thing is not clearly authorized, just as a lawyer representing the author would probably point out that the license is too ambiguous, needing clarification regarding modification.
Both lawyers would be right. I doubt the license was written by an experienced IP lawyer, and I also doubt the license was reviewed by one before the product was included into OpenBSD, though it would be interesting to know for sure.
(If leaving something out of the license was a 100% guaranteed way to withhold permission for it, whither all the stuff about no warrantees, for example?)
In the end, this is not a particularly big deal. To the extent anyone thinks it is, they ought to count their blessings that RMS and the FSF have IP lawyers write, as well as review, pertinent licenses, so nasty surprises are less likely for GNU.
The original language actually reads "Thou shalt not murder", from what I've read. So it applies only to people, not animals.
And it isn't Christians killing people "in some states" -- it's governments doing that, as governments have always done (the ability to get away with murder being one of their fundamental ways of maintaining control).
But, yes, a lot of people who call themselves "Christian" do believe that murder is okay in some circumstances, just as they believe taxation and other sins are okay in various circumstances. They entertain the Christ only when they find it convenient; at other times, they prefer the company, government, and judgement of Satan.
That's not the fault of the Ten Commandments, the Golden Rule, etc. That's why we have them -- because, without clear, absolute principles by which we can judge good vs. evil, we'd be even more prone to use labels ("Christian", "Democrat", "atheist", whatever) to do so, labels that are so easily attached and detached based on personal whims.
...being exposed by Democrats makes this look like
a very wise move by Bush. "Won't be the online President"?? Then neither was Clinton, according to that article anyway.
(And any past or present bashers of Ken Starr might want to look into exactly
who the Democrats in Congress decided had the integrity and non-partisan judgement
to delve into Bob Packwood's diaries, back when one's "private life" was worth exploring in every detail as long as the target was a Republican.)
We reap what we sow...and we have not yet begun to
experience the full effects of the support this nation gave
Bill Clinton and Democrats in Congress as they trampled common sense,
decency, the rule of law, over the past 10 years or so.
Whether the power companies "wanted" that bill back then is irrelevant to the fact that it is the government that passed it, imposing restrictions that prevented the power companies from more-rationally responding to the changing economies of power production and distribution.
Your post suggests that you believe the purpose of government is fulfilled by it simply responding to what the people, or some corporations, claim to want (though it's obvious you realize that what they wanted got them into trouble down the road).
That's not the purpose of government -- good government consists of saying NO loudly and clearly to most everyone most all of the time.
Had the CA government not been populated with the usual mass of meddlesome beauracrats (probably, for all I know, forcing the power companies to choose between what you claim was what they "wanted", but might well have been a huge compromise, and a much-worse alternative previously imposed by government beauracracy), they would have known better than to impose half-fast regulation (yes, I choose that spelling on purpose -- sound it out;-) then, or much in the way of regulation in the first place.
That way, when the cozy assumptions of corporate fat-cats don't pan out, the market, and the wise fat-cats who tend to it properly, can respond quickly -- much more quickly than that same beauracratic government is likely to.
Of course, the market will assert itself (it is continually doing so) -- various beauracracies serve as dikes against the flow of the market, for both good and ill, whether within businesses, families, or governments, but the biggest, slowest-to-tear-down, and often most stupidly placed dikes are usually the ones built by government beauracracies. Major dislocations of population, including extremes like mass starvation, can be the results of market forces acting to reconcile reality to long-term patterns of behavior. (Though, in this case, I certainly hope Californians don't move to other states in large numbers, bringing their penchant for electing meddlesome beauracrats with them.;-)
At least when the dikes built by other organizations (families/households, corporations, non-profits) prove to be poorly placed, too large, too small, etc., the rest of the market can quickly respond without having to relocate en masse to another nation or continent...
...that is, it's easier to "route around" bad household and corporate decisions, even those made in the aggregate, than around many government decisions, since those tend to be a) imposed arbitrarily on as large a land mass as possible and b) imposed by threat of forcible removal of one's personal property, imprisonment, and/or execution.
As to whether businesses should "lie down" with the "lion" of government at all, or just ignore it (and leave it to the whims of those, such as socialists, who can't get through a day without contemplating all sorts of ways they'd like to impose their wills on others), that's a moral argument only in the extreme -- realistically, it's a strategic and/or tactical decision.
IMO, we should resent the corporate fat-cats who grease the palms (in legal and illegal ways) of government officials less than we do the officials who are so easily greased. We didn't elect the former -- they're behaving out of self-interest, exactly "as intended" -- but the latter supposedly represent the interests of "we, the people", and thus should be able to "just say NO" even to well-meaning attempts by one group to impose its will on another via the iron fist of government.
Don't panic -- by my reading of the document, it looks like they're really focusing on having the.orgregistry operated by a non-profit org, and having it funded in a manner that allows it to cater to non-profits as it manages its domains without having to charge them lots of $$$.
How such an organization would handle existing for-profit.org domains is not actually specified (as far as I read the document anyway -- through the paragraph about how to handle.org). It might decide, in the long run, to chase 'em all away (bye-bye/..org?), but, more likely, it'd set up a multi-tiered system for maintaining the domain names -- more $$ for non-non-profits (luv them double negatives;-), for example -- or put some kind of restrictions on what they can do on sites with those names.
Various scenarios have various sorts of problems, but many of these problems are fundamental to the whole domain-naming issue (and many stem from the whole naming issue in the first place).
The idea, though, seems to be to have a non-profit org with funding provide another way for non-profits to obtain, maintain, and pay for their domain names, without being lumped in with all the high-$$ corporates.
That way, if.com addresses become more $$, as I expect will happen down the road under some formula, the non-profits won't be shut out of worthwhile names entirely.
Think of the proposal as offering a "wall of separation" between for-profits and non-profits at a higher, and more useful (since it involves funding), level than just the.org/.com distinction. The for-profit company managing the.com registry won't be tempted to extend its price increases to.org (and the corresponding non-profits) because it won't be managing that registry in the first place -- a funded non-profit org would be handling that.
Admittedly, I'm looking at this issue in a "positive-spin" way. Having heard/read about all sorts of abuses of domain-name registration by one or more companies, I hope this proposal is one means by which they intend to rectify some of these, or at least have the abuses perpetrated for something other than profit for a change...!
Slashdot Mirror
Note that I'm trying to do the opposite of playing both ends against the middle. Rather than tell the public the free-software or "mob software" approach will rule, and advocate *within* the mob the idea that, no matter what they spew out, it'll all magically work out, I prefer to tell the public to insist on quality, then advocate to the "mob" the idea that they too must insist on quality.
Do I think that approach might help a little bit? Yes, but I'm not sure. Do I believe it's necessary to ensure the success of the mob approach? I have no idea. I just don't see why I shouldn't try, a little bit, here and there, and I'd like to see more concrete steps taken towards making mob-style development actually work better than just writing about how great it'll all be, since I've been fantasizing about that myself for 20+ years, with all sorts of "great ideas" to accomplish it, and have little to show for it to date, other than a pretty good sense of a bunch of techniques that won't work!
Regarding oversight as being a "missing element" -- I don't claim that's the case. I'm saying something different: that each contributor must be willing to try to exercise his own oversight, and that, if too few contributors to mob-developed software do that sufficiently, it won't develop quality. A failed project does not demonstrate the failure of this development model to follow "survival of the fittest", of course, but I assume the point is that we'd like to think we'll produce many useful things that will survive and flourish.
I hope so! And I've long believed it likely.
My concern is that "we" (the community) not give in to the belief that we need not individually establish and hold to the highest standards possible for quality.
After all, the "infinite monkeys writing Shakespeare" idea, once explored, illustrates the problem with the "many programmers holding hands and creating software, some of which might actually be good" notion, namely, how does anyone determine what is good, and how do they even find it in the first place?
Keep in mind that the data regarding whether a piece of software is "quality", as well as the data regarding where to find such software, are themselves forms of software, as far as these illustrations go (and that's where I don't see new, helpful answers in the "mob software" essay -- what makes these problems go away?).
In the infinite-monkeys case, note how the problem is reduced to merely finding a match for works already generally assumed to be of high quality, namely, Shakespeare's writings.
Now consider another facet, just as true (mathematically), of that general idea, namely this:
(Okay, I got a bit carried away there, but you get the idea.)
The problem is now clearer: in that infinite amount of output, how does anyone find that particular gem? How does anyone even assure themselves that they have found it, not something that would, if these respective works were published today, be nothing more than a cheap knock-off of the desired work?
The answer is, that search, as well as the value of "quality", are themselves just as difficult to "build" as the software they attempt to describe.
With free software, yes, we don't have an infinite amount of output, but we therefore don't have an infinite amount of time to converge on high-quality solutions, nor do we have any magic bullet for determining what is quality, what is worth keeping, what technological directions are worth following, versus what are technological cul-de-sacs.
(And, remember, our monkeys will, unlike the ones in the thought-experiment, tend to follow the "monkey see monkey do" approach, by and large -- meaning if a few "leader monkeys" start down a technological cul-de-sac, most of the rest will follow, all proclaiming the "quality" of the work they're doing.)
In the end, an infinite number of monkeys pounding away at typewriters is of little use to someone who needs a hammer.
So while these illustrations ("mob software" and the like) encourage one to believe that there are substantial advantages to the free-software-development paradigm, those advantages don't materialize until sometime after those participating in, and forwarding, the paradigm give up their belief that "the best stuff will just win out" in favor of taking a stand for high-quality, long-lasting software, and avoid creating anything less worthy than that for public use -- avoid contributing to the chatter of mediocrity. (After all, we already have the proprietary-software development model for that, don't we? ;-)
If the answer is "to the government of country X", where X is USA or North Korea or whoever, it's silly to assume country X would participate in the nuking of the aliens.
Further, it's not only silly to assume country X wouldn't look for ways to thwart the attempts by other countries to nuke the aliens, it's silly to assume country X wouldn't immediately look for collaborative and compromise solutions with the dominant military powers based on an exchange such as "you let us receive that gold, we give you a percentage", or "you let us receive that gold, we don't nuke you like you did the aliens", or something.
If the answer is "the aliens would divide up the gold and give it to all the people", well then, since individuals have little practical use for gold in daily use, you might as well change the thesis of the story to be that aliens give each citizen of the world a whole bunch of the dominant currency (let's say US dollars) in a form that cannot be detected as a forgery by any technology likely to be developed on Earth in the next several decades.
In that scenario, you are indeed looking at a risk of inflation and such, but, knowing how governments tend to work today, they'll just do stuff like consider the alien's planetwise gifts as taxable income, and increase taxes across the board (since everyone will now be "rich").
Since most governments are always looking for excuses to do that sort of thing anyway, they'd probably respond to the alien's proposal with a big wet kiss.
Lesson for today: the control government exercises over people is rarely more than partially economic. Mostly it's a matter of force, mainly military/police power. Change the gold/currency in the story to advanced phaser-like weapons easily concealed on a person, then you might have a scenario in which governments would band together and nuke the aliens. If there's one thing tyrannical governments can't abide, it's the right of the people to keep and bear arms, with which to overthrow those in power. They keep increasing taxes, yes, to preserve their hold on power, but the military/police is more crucial in the short run to collect taxes than are the taxes to fund the military/police. (That's why even dirt-poor countries often have sufficient funds to protect government officials from their own people, but the reverse -- rich countries with high taxes but government officials no better protected against citizen revolt than your average McDonald's franchise manager -- rarely occurs in nature.)
What does all this blather of mine have to do with Open Source?
Well, Open Source, or free software, is a gift to the entire world's population, including governments. In specific instances it might give individuals power to use against government, but, more generally, the only commodity it tends to deflate in value is proprietary software -- which costs governments mucho $$, money they could spend on upgrading military, police, tax-collecting efforts, and so on.
The governments that "get" this, while they might be concerned about lower tax revenues due to programmers being willing to earn less (in some cases) writing free vs. proprietary software, will realize that an open-door policy for hacking and free-software development benefits the sitting government at least as much as anyone else, if it is well-poised to take advantage of those benefits.
That's why I don't expect to see a "haven" for free-software developers (a country free of the increasingly tyrannical intellectual "property" laws like the DMCA, software patents, and such) in the near future, and especially not from Communist or Socialist countries, though it's always possible. The governments of such countries already believe they can "command" and "control" their economies, and, unless they take an especially narrow view of software -- say, that it's an infrastructure component best built via "mob software developers" or the like -- they're unlikely to treat software developers in a fashion totally out of step with how they treat, say, shoemakers, energy producers, Christians, or the Falun Gong.
And even "enlightened", "civilized" countries not generally considered infected by the Communist meme show their socialistic, tyrannical bent by looking for ways to force their trading partners to not lower taxes on their own population, so as not to "compete unfairly" with the rest of the "union". By induction (or inference?), one can see why even the USA is unlikely to accept such a "free-software-haven" country as a trading partner whose human-rights record is considered worthy of the same level of acceptance as, say, China. I mean, you can roll tanks over protesting students all you want, but you'd darn well better get those IP laws in place and enforced, okay?
(Lesson number two: you can always tell a socialist-leaning tyrant by how he urges a nation to unilaterally disarm against its sworn enemies and yet remain highly armed against its own people -- after all, how can it continue to collect high taxes?)
Hey, didn't Bill Gates once claim that nobody would ever need more than 640MB of genetic information?
Um...people aren't ants.
And discovering similarities between a software-development "ecosystem" and the "real" ecosystem, while it might give us at least a few useful insights based on our current understanding of natural selection, doesn't mean the software-development ecosystem is sufficiently like the real one to make a numbers game an adequate substitute for proper design.
I believe there's a lot that's true about the "mob software" paper, but even if a lot of the stuff that's hand-waved ("minor" problems like, how do we annotate modules with cultural information in a way that's useful to both the computing infrastructure and the human beings?) is solved down the road, the only true ecosystem will remain the one we already have.
The "mob software" ecosystem will therefore suffer from a phenomenon that every free-software project has had to deal with, but which is not generally a problem for the "real" ecosystem:
For this reason, I've tended to find appeals to the "if I build it, they will come" approach to explaining why sound engineering principles are rejected out-of-hand by "those in charge" of certain OSS projects to be unpersuasive. Yes, "they" might indeed come, but if "they" are incompetent at the task at hand, and, having spent several years making "contributions" that direct the project even further down a technological cul-de-sac, become sufficiently competent to recognize what's been going on, having not convinced the "leadership" -- those who say "but we've always done it that way, it works", a kind of thought that's even harder to challenge in a mob-software approach than in a proprietary-software shop (and I've tried both, believe me) -- they are not only free to leave, but they take the most important part of the investment that little ecosystem made in them: their newfound competence at the task.
At least, in the real ecosystem, when a creature "leaves" (by dying), its nutrients are reabsorbed, over a period of time, back into the living mass. (Yes, the creature's knowledge and experiences "die", but they aren't as critical an "investment" for the ecosystem, which doesn't really, in any way, "care" about that creature.)
A mob-software ecosystem will, by the definition given, depend highly on the experience and expertise of individuals, even if only collectively, so it will need a certain degree of engineering "oversight" (and this is what the author probably means to say in a few places).
The closest equivalent to that in the "ant world" might be the genetic programming. We're not ants, so we don't have the genetic programming to cooperate like they do, and we don't yet know how to build an (abstract) organic ecosystem (say, a computing network) that serves as an adequate substitute.
But the promise is there (I've certainly been thinking along the same lines for, well, over two decades), it's exciting. And while I might raise an eyebrow over the apparent bashing of capitalism (preferring if the author had more tightly focused on the raising of intellectual privilege from a society-based concept to a right-to-profit monstrosity), since I'm not prepared to agree with the notion that a gift economy can't flourish within a society that, like the USA, permits capitalism as well (after all, we do have both, however imperfect they might be, and, unlike most experiments in command-and-control economies, we haven't executed millions of innocent people in this century to impose our new utopian structure on the population), all I can think to say after reading the paper is:
You replied:
I asked you to quote me, and instead you just make something else up out of whole cloth?
Look, I might well say that having source code hardly ever makes anything worse, but unless a person has a very poor grasp on logic, they're unlikely to believe that a) that means I believe that source code makes everything better and that b) that means I believe that even Ronald Reagan, in the throes of Alzheimer's, can personally negotiate the source code for Apache to find security flaws.
More likely, if you both valued my input and were an honest person, you'd admit that, time and time again in this thread, I've pointed out that the source code is a benefit to everyone because they, or someone they hire, can openly read, modify, discuss, and test it.
Here you continue setting up your strawmen, imputing them to me, and knocking them down. I hope you're having fun; for myself, I tend to tire of arguing with people who pull this stunt.
Can't you simply accept my statement that I did not forget that not everyone can read source code is true? Or are you 100% convinced that I'm either a liar or somewhat self-delusional?
Indeed, I have not commented on a bloated, monolithic Mail Transfer Agent that was originally designed for use on a non-hostile Internet and has been known to have many security holes as it has been grown into something designed to be suitable for use on a hostile Internet, while adding all sorts of features that needn't be part of the core product.
Why should I? After all, you've already discussed it, and I've seen nothing you've said about it worth rebutting -- as far as I know, it's all correct.
What does that prove? I believe it shows the validity of my arguments, especially the one about how large, monolithic applications are more likely to be very difficult to secure than smaller ones built out of discrete, interchangeable components, like qmail, all else being (pertinently) equal.
My guess is, people concerned about security would flock, like birds not flies, to its source code, find out it was a stinking pile of dung, and, not being flies, decide they'd have to start from scratch rather than spend the rest of their lives trying to secure something like that. Which is probably why we now have qmail, an alternative that is radically different from sendmail in almost every way, except they both are "free software" in most ways. How many alternative MTAs for Microsoft OSes came into existence because security-conscious people looked at the source code of Exchange (or whatever it's called) and decided to start from scratch, I wonder?
(And, of course, an app like sendmail is much easier to usefully distribute in proprietary form than one like qmail; the latter is too easy to reverse-engineer in digestible chunks.)
Yet, as I pointed out, Microsoft certainly took it upon itself to not let people print pictures it decided they might not have a legal right to do so.
Therefore, by allowing non-admins to easily enable IIS, they have about the same level of culpability as would Ford if it made sure that any 5-year-old could successfully turn on and drive an Explorer as a means to ensure wide market share.
Remember, I made a fairly broad point about Microsoft, and other proprietary-software vendors, effectively disarming customers (willingly) by not allowing them to see the source and find/fix/discuss the security problems themselves. Do you truly see no additional culpability coming upon these vendors or their end users as a result of this unilateral disarmament against enemies who, in some cases I would think, did not similarly disarm?
Note I am not talking about legal culpability, nor trying to make a distinction regarding exactly who -- MS or a given MS customer -- is culpable. Certainly Linux developers and users aren't culpable for bugs in MS IIS, and I argue that, in the combination of IIS users and MS, its distributor, there exists substantial culpability for any security flaws that are exploited by black hats and that might have been usefully exposed earlier, had the source code been widely and publically available.
However, I guess I do hold MS and other proprietary-software vendors culpable for willingly creating an environment -- a market, if you will -- in which end users don't believe they should care or know about the very concept of source code, the security implications of not being able to view it, etc.
(Sure, they "just wanted to make a profit", which is fine, but let's not allow that priviledge, or right, to cause us to overlook the fact of their culpability by taking the actions they did, especially since that would disadvantage those vendors who did strive, more than others, to inform their customers regarding security concerns, give them some degree of access to source code at least, and so on. Just because a company X does Y to make more profit does not mean we can no longer discuss whether Y contains unfortunate, even "evil", portions. That is, I'm not debating the evilness of corporations -- I'm trying to clarify some issues I believe you've obscured in your posts regarding the value of the respective forms of software generally.)
Then the company is run by fools, which I doubt. Proper engineering, especially of large, complicated systems, includes assuming there will be failures, and handling the risks accordingly.
(You seem to not know much about software engineering, based on statements like that and the other one you made about kernels not being interchangeable. Are you seriously trying to tell people that, without understanding even the most basic concepts of software and vanilla engineering, your views on security trump those of us who do have some understanding of these issues?)
I need to back up my claims because of something someone else said? Bah.
Besides, here is the first chunk of text to which you responded, as written by the original poster:
Seems like the author of that quote left himself plenty of wiggle room between what he said and what you claim he "implied". I don't know if I'd say it quite as he did -- perhaps he has experience and expertise I don't, to back up his claims -- but I agree with the general thrust, yet don't see him as quite saying that open source produces more secure software than proprietary (a statement that can be interpreted in so many ways, it has little meaning at the point we're at, which amounts, nearly, to debating how many angels can dance on the head of a pin).
An example of one thing to which you have not responded is something I consider to be pretty much an "endgame" in a discussion like this, and that's the fact, pointed out by the original poster and myself, that no proprietary software (of the type that needs to be secure) is ever shipped after its source code has been widely available for open discussion, for testing, even for modification, by the general public. Yet that sort of activity is typical for equivalent free software, which goes through alpha and beta releases in which the source code is, put simply, "there".
Do you really, truly, honestly believe that having the source code widely reviewed and discussed by people with no financial interest in simply parroting a corporate line about security offers no substantial advantage in terms of ensuring there aren't fundamental, or even obscure, flaws in the design and/or implementation of the product?
If you do believe that, then you believe that all the bugs found during the alpha and beta periods of free-software products (including mine) were pretty much irrelevant, or would have been found anyway, i.e. without the source being available.
In that case, I can tell you first-hand that your belief is utterly without foundation. But unless you want access to my email/USENET archives, or wish to explore Linux kernel and other archives yourself, to research the importance of source-based bug-finding during alpha and beta test periods, you'll have to either a) accept that your belief is unsubstantiated or b) call me, and probably plenty of others like me who've developed free software, liars.
Sheesh, more strawmen. Of course, I never said that. I did point out that free software gives users more choice as to when and how to innovate, upgrade, and so on. Why you insist on excluding the middle ground is beyond me, unless you really care more about appearing to win an argument (using whatever means are at your disposal) than actually learning something that might challenge your cherished assumptions.
Then stop reading /.. Seriously. In fact, you might as well drop the last two words from your sentence, or the last five, or even just use the first five, to say all you, or anyone else, need say. Most of the time I'd probably agree.
The mistake I think you made is picking the wrong example, and the wrong people, to respond to as if they, and we, were "typical" of the stuff, and people, you're "sick" of.
Further, if you're thinking that /. readers somehow represent a coherent viewpoint on this or any other subject, dispense with that notion immediately. It's foolish to believe that of almost any group of more than ten people, much less one of more than 100,000, even if they are voluntarily and freely choosing to air their views in a particular forum.
I don't know which is more disturbing: to believe you are exerting an effort to do so, or to believe you aren't.
Another strawman, since neither I nor the original poster made such a denunciation.
More excluding of the (incredibly wide) middle ground, in which a 99% assurance after a careful audit of clean source code is preferable to a 10% assurance that consists entirely of the vendor saying "yeah, it's secure", plus whatever experience in the field might be on hand.
You might also wish to investigate a concept called "proof-carrying code", and similar "proof-based" systems, and compare their deployability in a) a proprietary-software world versus b) a free-software world.
I can understand why you'd have that impression generally, but it does not apply to me. I use Microsoft in my examples of reasons to distrust proprietary vendors solely because they're such a well-understood target. But my experience goes back much further than that.
I remember discovering a bug in 64-bit floating-point comparisons in a (rather obscure, thankfully) computer (I worked for the company designing and building it at the time). Something like, if the difference began in the 33rd bit in a certain direction, the result of the comparison would be wrong.
When I pointed this out to the VP of Engineering, he made it clear the company would not be issuing notifications to the customer base, and certainly not replacing the CPUs already in the field to fix the problem, despite the fact that those particular machines' main selling point (compared with other offerings) was that they did 64-bit floating-point "natively".
How is this kind of willful ignoring, and refusal to communicate to potential victims, of the problem possible in a free-software development project large enough to support most pertinent products? (Even though I described a hardware flaw, I've had similar experiences, though harder to explain simply, in proprietary software companies.) The answer: it pretty much is not possible, because authors of free software simply aren't that interested in hiding information, especially info of that sort.
(Proprietary-software vendors, of course, spend significant human, financial, and legal resources ensuring all their employees, contractors, consultants, vendors, and so on, know the importance of keeping things secret -- even things that could be life-or-death issues.)
Um...why not? In fact, I did casually scroll through some Linux kernel source code around 1992 or 1993, found a bug involving group (vs. owner or world) access in the filesystem, reported it along with a proposed fix, it got accepted.
Why would you have a problem with that?
As far as I can tell, there are a variety of projects around the world that consist of people writing tools that look for certain kinds of bugs that compilers don't find in source code, and using GNU/Linux source code for input. These tools will not likely get run by proprietary vendors (besides, if they do, how will you know for sure they've been run and the results used to improve the product?); certainly their output won't be published, as it has been for the Linux kernel, at least. (Wish I could remember the name of the one project like this I'm sure came about this way, but if you skim Linux kernel discussion archives, perhaps you can find it.)
Hey, I "get" your points, but they don't stand up to historical scrutiny, which you can't exactly be blamed for not realizing, because they draw no useful lines beyond which the value clearly diminishes to the point of irrelevency.
Specifically, ten-plus years ago, your predecessors (on newsgroups like gnu.misc.discuss) used pretty much the same logic you're using to explain why free software might have its "niche", beyond which it could not possibly expand, due to lack of resources, qualified programmers, etc.
Examples of things free-software solutions would "never" exist for, from memory (and some of this goes to before google/dejanews coverage of gnu.misc.discuss, which I gather is circa 1994, but I've got my own private archives):
Operating system kernels (too technical, too few people with enough expertise, wouldn't be secure since nobody would bother with things like code reviews, i.e. no OpenBSD project would exist)
Fortran compilers (not sexy enough; I fixed that one myself ;-)
Decent GUIs (i.e. no Gnome or KDE at all, certainly not two completely independent and competitive projects!)
In the paragraph containing that parenthetical statement, you express much hope/optimisim about proprietary software, which might not be unfounded, but I'll note two things:
-
-
Regarding the parenthetical statement, especially the part about capitalism, if you are interested, and can be really nice and stop creating strawmen, claiming I said things I didn't (instead, please just quote, okay?), I'll be happy to respond, probably via email, since you might find my views on that subject (free software vis-a-vis market forces) fairly interesting, if not convincing.It's not clear to me proprietary vendors are going in the more lenient direction -- in fact, things like the DMCA, plus inferences based on what the MPAA and RIAA are doing (and getting away with), suggests that the vendors that succeed will be those that lock up their software even further, by "hiding" it behind network-based services (.NET?), putting even more legal and practical constraints on finding and openly discussing flaws such as security holes, etc.
To the extent such vendors do go in the direction you hope, the less they become distinguishable from free software anyway. (You've got to look beneath the labels in some cases, e.g. qmail, especially when making assessments like we're making.)
It's worth your time to explore it, and learn who supports it, and why -- even just for the security implications of what you'll find out. (And I admit to knowing only a bit of what's going on, but enough, IMO, to speak somewhat authoritatively on the intersection of issues we're discussing.)
Excellent question. My best shot at an answer right now is that security (in the context of our discussion) is best achieved through a combination of factors, including robustness, clean, simple, unfettered design, solid engineering, and so on.
Components that demonstrate the ability to be interchanged with and for other components, especially those from other vendors, especially in the presence of specifications and standards agreed upon by the industry as a whole, tend to better demonstrate those very qualities.
No, of course not. What it does illustrate is that FAT32 is not so inscrutable and poorly designed that alternative vendors can't support it, and that whatever security failings it might have (and I don't know much about that offhand) are more likely to be well known and well documented by the very fact that someone else, in this case multiple other "vendors", have employed it as an interoperable component.
Sorry, you're very wrong about that. There's a reason some of us call the system "GNU/Linux" (other than the fact that some wish to associate with the popular name "Linux" the GNU name) -- because there is every possibility of creating an operating system based on the Linux kernel, but using utilities that are sufficiently compatible with, but not themselves, of GNU origin.
Ditto for GNU/Hurd, a GNU system with Hurd as its kernel. A kernel that could be used as a component in a completely different system.
Here's where you see the kinds of qualities expressed by a component that guide you towards an increased assurance regarding its security: since the Linux kernel is deployed on a huge number of devices in a form not consistent with the usual definition of "operating system" (say, in embedded devices), and since GNU utilities are widely deployed, or used to deploy, other systems that are neither GNU nor Linux, you have more assurances that both GNU and Linux are devoid of fundamentally unsound, undocumented security failings in design, and are less likely to have undiscovered bugs in their implementations, compared to proprietary-software components that don't interoperate as well.
What's your point? Linux, many *BSDs, Minix (?), and the Hurd are all examples of open-designed, maybe even free-software, kernels. And they enjoy a great deal of interoperability with each other, compared to almost any two proprietary kernels you can name (even two Microsoft ones, I'd guess, but certainly, say, WinNT's versus MacOS6's).
But even non-open kernels, like Solaris (I assume) and HP-UX (I'm even more sure), gain some assurances by interoperating as well as they do with the GNU utilities, and vice versa. Ditto, but not as much, for Windows and GNU, since (I gather) the Windows ports for GNU utilities are, for such a successful system, rather hard to do and still (?) somewhat incomplete.
The implications of the Windows/GNU combination include that if there are security mechanisms that are incorrectly placed in Windows, i.e. placed in a portion of userland that is replaced by a GNU utilitiy when it should have been a kernel mechanism, that will be more quickly exposed and easily demonstrated via a combination Windows/GNU system. It might even be discovered by the authors of the Windows port for the replacement GNU utility -- a great example of a "white hat", one can reasonably assume, making an important discovery, one which Microsoft would, like as not, be unwilling to expose, even though "it" would certainly know about the failing.
Further, while I've focused on the objective factors, or qualities, of deployed components, I suspect the real payoffs come during the period in which real people construct systems that use your components in ways you didn't plan, even when they toss out your component in place of another.
At times like that, they're more apt to notice, and more willing to question, document, publish, things that might be failings in your design or implementation -- perhaps based on assumptions you made regarding the components with which your component would "always" be deployed.
Further, the very act of focusing on designing and deploying an interchangeable component (much more like the Linux kernel, or the Apache web server, or qmail as well as its subcomponents) as versus a component that's intended only for use with a much larger monolith (much more like the Windos kernels, the IIS web server, or MS Exchange) causes the developers to think carefully about the exact sorts of interface and "border" issues that greatly affect real-world security. (Think about all those web-site security bugs that stemmed from the developers really believing the user's browser was actually a component in their web-site's monolithic "experience". The result? They'd shovel info to the browser for the user to interact with, then foolishly trust the (modified) information that came back, as if the user couldn't change it however they liked, even beyond what the web site's JavaScript (or whatever) was designed to allow.)
After all, the small-component developer must think first about things like "how do other components like mine work? how is it made secure? what are the pitfalls?", while the monolith-component developer tends to think about things like "the monolith will provide security; the monolith will make everything work; we needn't look at pitfalls of other systems, since this is a new, wonderful system unique from all the rest".
Which mind-set do you honestly think more describes that of the typical developer of widely deployed GNU/Linux software, and that of the typical developer of widely deployed Microsoft software?
Having plenty of experience in and with both worlds, I know the answer in specific cases aren't always clear-cut, but, overall, it's the monolith-creating culture that is more willing to ignore history and reinvent the wheel. (There are those in the component-creating culture that do that, too, but they rarely succeed in making their component important in deployed software, because they can't force it to happen so easily.)
Can you point to a single thing I said that shows that I "forgot" this one important detail??
The fact is, I'm acutely aware, and have been since about age 12, that I'm somewhat rare in being able to read source code.
My reason for posting what I did was not to convince you, it was to counter the propaganda you posted, so others may realize there are other views, may consider the various sources for those views, and do the research, or at least the thinking, for themselves.
To meet that goal, I need not back up everything I say, any more than you did in your claims about the security of proprietary software as a model, or in any of its specific forms.
If they're "ignorant end-users", why is Microsoft letting them run a web server on a hostile network, allowing their systems to become launching-pads for further hostile actions against other systems?
My point is that Microsoft exerts vastly more control over the computing environment of Microsoft users (and willfully so) than any combination of GNU/Linux/*BSD/CPAN authors do over the computing environment of their users.
(As one example: Microsoft's encyclopedia software -- "Encarta"? -- disables printing of illustrations on the user's screen, apparently to satisfy some intellectual-privilege concern. I discovered this when trying to help a friend who wondered why he and his children could print some pictures out on their inkjet printer, but not all. If MS can be so conscientious about deciding, on behalf of the user as they'd surely claim, that he shouldn't print something since he might turn around and get his $100 inkjet printer's output reproduced in a national magazine without paying the licensing fee, they can certainly disable IIS for users who haven't proven they can "handle" deploying such a product on a hostile network like the Internet.)
Therefore, Microsoft and other proprietary-software developers have taken upon themselves much more responsibility for their software being insecure, out of the box, than free-software developers, because they restrict the freedom of their users to actively engage in the sorts of open discussions and reviews regarding security that are day-to-day happenings in the free-software world.
Free software is about freedom, and that and related values are what are willingly and fully extended to all end users of that software. Microsoft (and, generally, proprietary) software is about profit, but more to the point, about control, about restricting freedom of the users of that software.
To pretend that the security implications of those two very different world-views are negligible or non-existant is to delude oneself.
(Note that I have made no claims about either approach being inherently "good" or "evil". My point here is focused simply on the fact that when you put the user in a straightjacket, you, the proprietary software developer, are responsible for the care, feeding, and shelter of that user, as well as for the violence committed by that user when you allow someone else to "infect" them with some virus and fail to restrain them, especially if you allow them access to a button they can press with their nose that is labeled "Destroy Internet". Those who refuse to put users in straightjackets, yet who are willing to provide them food they can freely use as they see fit, ditto for shelter, ditto for care, ditto for recommendations as to how to avoid accepting the intellectual, or software, equivalent of viruses, have nowhere near the same level of responsibility for their behavior. They do not have zero responsibility, however! But, in allowing their end users freedom, they give them much better defensive weaponry to use against those engaging in bad behavior, which is why those of us who run GNU/Linux, for example, aren't nearly as directly affected by badly-behaving proprietary software as are users of different proprietary software -- we haven't accepted unilateral disarmament as have they.)
With that I almost wholeheartedly agree. Except, as I pointed out, proprietary software never equals "objectively provable as secure", since the general public can never be allowed to see the details of how it works and discover security flaws for itself.
You went off the point there. It was you who made the claim that free-software fixes aren't always funded, whereas proprietary-software fixes are. (That is a reasonable inference from the symmetry of your earlier quote.)
So, I was not arguing against the free market, or capitalism, or libertarianism, or whatever other red herrings you wish to throw into this argument.
I was simply pointing out that being dependent on free software means depending on someone, somewhere in the world, being willing and able to fix problems for you when they come up (whether they are already an employee of yours), whereas being dependent on proprietary software means depending on such a person being found (and funded) in, what, about .00001% of the world's population. (This is my attempt at a quick calculation based on an assumption of 6000 people in a typical proprietary-software company vs. 6 billion people worldwide. Of course, the entire world's population isn't capable of fixing software bugs, but the percentage that is probably isn't vastly lower than the percentage of employees of a typical software company, in my experience.)
Further, unlike the corporate environment of a proprietary-software developer, in the "real world" there is no manager threatening someone for termination if they go ahead and fix a problem based on a customer complaint. (Believe me, I know both sides of this issue very well; I've been "reprimanded", or at least hassled in performance reviews, for taking time to provide very-well-received fixes for customers, as well as for in-house users. The free-software world does not revolve around such archaic constraints on human activity. Yes, I ultimately responded to such exercises of managerial oversight by leaving the organization -- at which point, I became incapable of rendering similarly fixes for those same customers in the future! I have no such limitations placed on me when I decide to leave a free-software project like, say, g77.)
Upon which pool of available talent do you (not the poster, but the /.-reading public out there) wish to restrict yourself, in finding solutions for your computing problems, such as inadequate security -- the entire world's population, or the approximately .00001% of that population whose only real "claim to fame" is that, if they help you, there aren't probably breaking the law as well as pulling rabbits out of their hats by hacking binary code with no source available?
In other words, when the software you paid for the privilege of using, but not studying or improving, fails, you have to not only buy some next-generation form of that software, but newer computers to run it?
The answer is: of course that's true, for proprietary software. That's why, of the reasonably high number of 486 CPUs out there running in production mode as mail and web servers, a vanishing percentage, I suspect, run proprietary software for those apps -- instead, they probably run a Linux or *BSD kernel, Apache, qmail, etc.
That's also why my wife's organization's IT facility decided to finally convert over from Macintoshes to IBM PC machines to address the Y2K problem. Because Macs were not Y2K compliant? No, because Microsoft Excel, the version they were running on their Macs, wasn't, and to get a version that was that would run on Macs, they would have to upgrade the Macs themselves anyway, so they "might as well" switch to the more "dominant" architecture.
That is, they punished the company that produced a largely-Y2K-compliant system and rewarded the one that boxed them into a corner by creating Y2K-buggy software for years. That's exactly the kind of perverse result one would expect from depending on obscurity rather than openness.
Of course, if they'd had the source and the freedom to hire whoever they wished to fix it, they could have had the choice to fix just the Y2K problem in Excel and continue running it on their old, but perfectly-working, Macs.
It's a common abbreviation I usually succeed at avoiding, but used, what, once in that entire post?
I claim your posts contained much more, and largely uninformed or gratuitous, genuine bashing of free software than mine did of Microsoft.
Disclaimer: my sister worked for Microsoft for many years. One of her positions included Lead Program Manager for Internet Explorer version 5. And I've been a longtime proprietary software (and technical-documentation) developer. I speak on these issues not so much to advocate one side or the other, but to rebut the misinformation that's widely circulated (by people such as yourself) regarding the respective software paradigms.
I don't know if he did that, but your response equated the single source of unexaminable, yet widely-deployed (on a hostile network, no less) software with one of the sources long known to be a poor choice, from a security perspective anyway, among many choices for software that does not come widely represented (and heavily marketed) as a "one-stop shop" for ordinary people to get on the Internet, run web servers without sysadmin experience, and yet be responsible net citizens, from security and other perspectives.
Anyway, if your point is that people who say "Gee, if these folks would run free software, there wouldn't be so many security problems" have some serious flaws in their arguments, I agree wholeheartedly. But I don't say they're wrong, per se, just that statements like that often are oversimplified to the point of being, at least nearly, useless.
(Fortunately, there isn't a $Billion advertising budget behind that message coming from free-software developers, so the importance of rebutting the arguments from that source seems, to me, to pale compared to that of rebutting the arguments coming from other, well-funded, sources.)
Your arrogance is really over the top. I, of course, have worked for many proprietary-software developers, none of them Microsoft, but can't help noticing which one has survived and flourished as what most people think of as the source of software enabling them to access the Internet.
And while I agree that free software isn't, at the level of instantiation (that is, instances of free software), inherently more secure than proprietary, I do claim that it's inherently more secure as a model for software development and deployment.
Further, my impression (definitely devoid of necessary research to support it) is that, in the free-software community, well-designed, secure software is a much better predictor of deployment, especially over the long term. Look at how "poorly" qmail is "marketed", yet its installed base is pretty amazing.
After all, let's review another statement you made here:
Name one. Name one that you can show is secure, in a public forum, by reviewing the most important material that should come into evidence: the source code!
And that's the crux of the debate we're having. Ultimately, you believe that security through obscurity, in the form of not only obscuring algorithms, but obscuring the fact that proprietary-software developers have a form of relationship with their customer base that cannot, even under the best of circumstances, be described as "demonstrably committed to mutual security", is the best solution. (I use "committed" in the sense that "when it comes to ham and eggs for breakfast, the hen is involved, while the pig is committed". Proprietary-software developers do exist that provide some degree of commitment to the security of their customers' installations, but that commitment is, in my experience, "earned" via distinct payments and other consideration, compared to the software they sell. That is, the mere act of acquiring and deploying proprietary software rarely earns a customer any useful commitment from the vendor regarding security. The same goes for free software, in spades, of course, but with free software the customer has not only the original vendor to go to to purchase additional security commitments, but pretty much anyone else in the world, since he has access to the source code, to open forums for discussing its security, and to source-level patches to improve and/or test that security.)
I believe that security, especially in the context we're discussing (security of systems on an open worldwide network like the Internet) is best, perhaps only, achievable through openness, in the form of open review, discussion, and testing of the models used to enforce it and the software that is written to support it.
And with the model I choose, it doesn't matter nearly as much how "friendly" a software producer is with a given software consumer, since the latter can always review the source code himself (an option that, obviously, includes paying someone to do so).
Note that I'm not representing myself as an expert on security. If you want to get an opinion from one, ask him this question:
I'm purposely comparing the two extremes on the continuum between free and proprietary software (and it is a continuum), but the answers from most security experts will, I believe, point to the end of that continuum that most directly coincides with free software, and rarely coincides with any particular proprietary-software solution.Further, to the extent proprietary software tries to emulate particulars of free software in this continuum, to achieve more favorability, it becomes less proprietary. In particular, the financial advantages that accrue to the typical proprietary-software developer tend to diminish, in favor of advantages free-software developers already enjoy. At that point, as a customer, you're going to be paying the proprietary-software developer more to offset those losses (as calculated by the vendor) anyway, so you have even more funds to consider devoting to deploying free and open solutions instead.
After all, it isn't the free-software development community that pushes for things like the DMCA, is it?
Fact: the same things almost never hold true for proprietary software.
Fact: Free software does not "produce more secure software than the proprietary world" per se, though such a poorly-worded phrase is often used in place of the truth, which is that free software, compared to proprietary software, i.e. when comparing software distributed to end-users (as versus in-house use only), has a greater opportunity to reach high assurances of being secure when comparing categories of software in which security is important.
For example, compare your personal ability to vet the security model of qmail vs. any of Microsoft's mail-server offerings. "They" can assure you of MS's "security", just as "we" can assure you of qmail's. But, of the two, only qmail allows you to legally examine the source before ever having to enter into a contract allowing you to do so; to discuss findings with others, out in the open; to beat up on it in a test installation before committing to a purchase (and remember that such purchase is typically followed by a strong urge to justify said purchase, rather than prove it to have been an incorrect decision); and so on.
Fact: that "people with infected IIS are not admins" is irrelevant. Given MS's position in the marketplace, I suspect they could easily ensure that only true admins would be allowed to run IIS on the Internet. (After all, they use imposing legal language to bind "licensees" to contractual requirements designed to improve MS's bottom line and warm cuddly feelings of "protecting their IP", right?) At least, they could surely make it less likely that non-admins might "accidentally" deploy IIS on an Internet-exposed host. Why don't they do this? Because they prefer playing both ends against the middle, as most businesses do -- "anyone can buy and use our products" on the marketing end becomes, on the customer-service end, "you must be doing something wrong". (Yes, there are those who claim GNU/Linux is "ready for the desktop" and such like that. Why believe them? Why not investigate these claims for yourself? I claim that since everyone has the freedom to do that with free software, such claims have nowhere near the "guilt" for security breaches that a company like MS does when it makes similar claims about what, to most everyone else in the world, is a black box -- its proprietary software.)
Fact: While it is indeed not always true that people are paid to fix free software, the exact same thing is the case for proprietary software.
The difference is, if you're depending on a free-software product that isn't being maintained by someone for $$, you have the option of hiring someone to do the work.
Whereas, if Microsoft decides, as it surely will down the road, to stop paying its programmers to fix IIS, or Windows 2000, or DOS 5.whatever, you'll be out of options if you have failed to follow the M$-recommended upgrade path.
Fact: Red Hat does not, and has never, represented the security-conscious administrator's #1 choice for a default system installation of GNU/Linux.
Fact: If you find Red Hat's choice of configuration (which I think has been improving lately; I've been using it for years) unacceptable, you have many other choices for where to obtain distributions, versions, and configurations of the Linux kernel specifically, the GNU system generally, and other free-software systems as well.
Challenge: name three vendors from which you can obtain the Microsoft Windows 2000 or Windows NT kernel in a distribution as fundamentally different from Microsoft's as Debian's, or SuSE's, is from Red Hat's.
Okay, make it two vendors. Okay, make it one vendor other than Microsoft. I'd sure love to know if they license their kernel to other software-distributor outfits to wrap with their own chosen apps, using their own chosen configurations, etc.
(And note I haven't even mentioned OpenBSD yet!)
Fact: to preserve their advantage in IP investment and security, proprietary-software distributors have an incentive to create packages as large, complex, monolothic, and, therefore, difficult-to-reverse-engineer, as possible. Free-software authors, like any software author, tend to create large, complex, monolothic programs due to natural tendencies, but they don't have nearly the bottom-line incentive to do so. That is, as their expertise, their sensitivity to security and complexity issues, might lead them to producing simpler, cleaner, more "transparent" products like qmail, they won't be rebuffed in their attempts to go down that road by managers and lawyers saying "we can't make it that easy on our competitors to reverse-engineer our IP".
Consideration: most proprietary software, especially in wide (therefore profitable) circulation, especially the sort of software where Internet-exposed security is an issue, performs some kind of license-checking to prevent "piracy" ("unauthorized coveting of intellectual privilege" is IMO a better phrase), whereas hardly any free software does that sort of thing. Which choice poses a greater security risk to the overall system, in terms of things like resistance to viruses, worms, etc., degree of inviting reverse-engineering of obscured code, etc.?
Opinion, mine: in the end, proprietary software stands opposed to secure software, because for software to be secure, it has to be easy to publically validate as secure (i.e. be validated by any third party without contractual agreement, thus allowing that party to speak freely about security concerns), whereas, for that software to be usefully proprietary, it must be obscured, intentionally, by the distributor.
Observation: The current method of choice proprietary software vendors use to obscure the IP they release into the wild is to compile and link it down to machine code and cross their fingers. With non-programming forms, they have to resort to even less workable forms, such as encryption. ("Less workable" because compiling to machine code generally makes the end product run faster, and because today's dominant software-development paradigm is predicated on the need to be able to strip out source and other "redundant" code, whereas encrypting other forms of software tends to make them less immediately useful to the end user, who then needs a more sophisticated engine to reveal the purchased IP.)
That some vendors are increasingly resorting to the legal system, rather than on complexity alone, to keep their IP obscure, does not change my claims at all -- however the software is obscured, the very act of obscuring it defeats the goal of making it secure.
(Though, as with firearms, to the degree laws are used to prevent access to source code, access to source code becomes something much more closely associated with those contemplating lawbreaking, rather than those merely very interested in learning about, and gaining expertise in, the relevant technologies. "When source code is outlawed, only outlaws [and government] will have source code." Think about the security implications of that situation, and ask whether you wish to visit houses, office buildings, and skyscrapers whose blueprints are "secured" in the same fashion.)
For now, that's acceptable to me, and since it's a month-to-month thing, I'll go along with it...until and unless the time comes when my expertise and desire to set up an HTTP or FTP (or SSH?) server exceeds their willingness to allow me to run it (both legally, i.e. according to our mutual agreement, and technically, e.g. by not blocking the pertinent ports).
(Haven't decided yet whether to move my web site from my current ISP to one of these "AT&T Personal Page" thingys, but probably won't. I'm budgeting on the assumption that I'll pay for both AT&T Broadband access and my existing ISP, since the former is fast, while the latter has more than a clue about UNIX systems. The installation won't happen for another couple of weeks, by the way.)
Are you unaware that firefighters often do use fire to fight fire?
(They burn away strips of forest to prevent a forest fire from being able to cross the strips and attack, say, neighborhoods.)
I think your comment in the next paragraph is right, though, because it illustrates the weakness of the forest-fire analogy.
In particular, while fighting viruses on the Internet today might be more like fighting a forest fire -- in that the trees are not "smart" at fighting fires, you want to save as many as reasonably possible, yet you're not averse to burning a few more down yourself to avert a larger disaster -- the overall goal should be to convince Internet sysadmins to do for their systems what homeowners and business owners have, over the centuries been encouraged to do: be the first line of defense against fires starting, or offense against fires spreading, etc.
(Think of elements of "progress" here -- new homes likely have smoke alarms, people are strongly encouraged to report fires quickly, flammable materials are less widely used, buildings are designed for quick exit in the event of fire.)
Until the Internet resembles something more like today's upscale suburban neighborhood (in its security against fires) than a dry, dense forest, I suggest that fighting fire with fire does have utility, if thoughtfully (rather than arbitrarily) applied by experts.
Not only do I get plenty of spam to "craig-sd", but plenty to "sd" as well.
I don't think I ever used "sd@mydomain" here myself, so perhaps some harvester munged addresses gathered over the web and it got committed to CD-ROMs sold worldwide, 'cause I've been getting spams (to both addresses) for a long time now.
(Of course, once they get tedious enough, I can filter them here or, better yet, upstream at my ISP.)
Huh, while I'm thinking about it, might as well change my email address here to a new (munged) one.
For attackers seeking to obtain value, however -- not so much teenagers trying to disrupt things as people trying to break in and steal stuff -- that equation is less helpful, because acts of destruction don't preserve the value they're trying to obtain, and might tend to leave a trail, be noticed earlier by defensive systems, etc.
I think I did say something about vandal-type attacks -- like suicide bombers, they're much harder to stop, even if they're much easier to detect once they begin to succeed in their efforts.
However, I feel that's basically orthagonal to the meatspace vs. cyberspace issue, as well as the OSS vs. proprietary-software issue...
(Not the part about the comparative ease of exploiting security holes in source code vs. binary code -- the part about OS advocates somehow "always" forgetting that fact.)
In my experience, advocates of open source are highly aware that it's easier to exploit security holes in source code.
After all, to do that, one must find them first, correct?
And unless most or all of the people looking for them also intend to exploit them in an offensive way, the result will be that said holes will be fixed in a defensive mode vs. offensive attack faster than for proprietary, binary code.
Remember, defense always has an advantage over offense, in terms of time and effort -- the "battle" is on the defender's own turf. Offense can make up for this inherent disadvantage to some extent by, for instance, having the element of surprise.
For most such offensive counter-measures, having the source code is not an advantage, in fact it's a disadvantage, if the defense also has the source code.
That's because the defense can deploy fixes to holes faster than the offense can attack them, so, assuming they both find out about them at the same time, the defense wins. (This is generalizing, by the way. Specifics always vary, of course.)
Now, ask yourself this question: when it comes to binary-only code, who is likely to know more about the internal operations of the code -- the defense, in this case, law-abiding users, or the offense, willing to obtain THE SOURCE CODE through illegal channels??
That's why Open Source has such an advantage here -- the defense, collectively, is encouraged to share, generously, insights about the software, while the offense must remain fairly isolated (a general rule about law-abiders versus law-breakers; while law-breakers sometimes pool their resources, they have an uphill battle with regard to such activities compared to law-abiders, who can do their pooling in the open and/or in hiding).
When it comes to proprietary software, law-abiders are increasingly discouraged from sharing insights, info, breakages, fixes, etc., while the opportunities for pooling resources on the law-breakers' side remains pretty much the same.
But there's a special prize law-abiders are denied that law-breakers have the opportunity to exploit should they gain access to it, when it comes to proprietary software: the source code.
Once they have that -- and they will, if the software "matters" at all -- the law-abiders will be on the losing end of things.
"If source code is outlawed, only outlaws will have source code."
I believe that it is not unreasonable for a lay person to conclude that modification is implicitly permitted, since what is explicitly disallowed is a specific form of modification -- that of removing the notice.
Further, asking for "due credit" to be given suggests a general sort of modification to any redistribution, the wording itself up to the entity performing the modification, as long as it constitutes "due credit".
Now, a lawyer representing someone considering redistributing a modified copy of software under such a license would probably point out that such a thing is not clearly authorized, just as a lawyer representing the author would probably point out that the license is too ambiguous, needing clarification regarding modification.
Both lawyers would be right. I doubt the license was written by an experienced IP lawyer, and I also doubt the license was reviewed by one before the product was included into OpenBSD, though it would be interesting to know for sure.
(If leaving something out of the license was a 100% guaranteed way to withhold permission for it, whither all the stuff about no warrantees, for example?)
In the end, this is not a particularly big deal. To the extent anyone thinks it is, they ought to count their blessings that RMS and the FSF have IP lawyers write, as well as review, pertinent licenses, so nasty surprises are less likely for GNU.
And it isn't Christians killing people "in some states" -- it's governments doing that, as governments have always done (the ability to get away with murder being one of their fundamental ways of maintaining control).
But, yes, a lot of people who call themselves "Christian" do believe that murder is okay in some circumstances, just as they believe taxation and other sins are okay in various circumstances. They entertain the Christ only when they find it convenient; at other times, they prefer the company, government, and judgement of Satan.
That's not the fault of the Ten Commandments, the Golden Rule, etc. That's why we have them -- because, without clear, absolute principles by which we can judge good vs. evil, we'd be even more prone to use labels ("Christian", "Democrat", "atheist", whatever) to do so, labels that are so easily attached and detached based on personal whims.
Because that's where the fossils are, and because it's the Leakey family members who're looking for them there?
;-)
(And any past or present bashers of Ken Starr might want to look into exactly who the Democrats in Congress decided had the integrity and non-partisan judgement to delve into Bob Packwood's diaries, back when one's "private life" was worth exploring in every detail as long as the target was a Republican.)
We reap what we sow...and we have not yet begun to experience the full effects of the support this nation gave Bill Clinton and Democrats in Congress as they trampled common sense, decency, the rule of law, over the past 10 years or so.
But V >> C right-shifts V C places, making for a very small number!
Your post suggests that you believe the purpose of government is fulfilled by it simply responding to what the people, or some corporations, claim to want (though it's obvious you realize that what they wanted got them into trouble down the road).
That's not the purpose of government -- good government consists of saying NO loudly and clearly to most everyone most all of the time.
Had the CA government not been populated with the usual mass of meddlesome beauracrats (probably, for all I know, forcing the power companies to choose between what you claim was what they "wanted", but might well have been a huge compromise, and a much-worse alternative previously imposed by government beauracracy), they would have known better than to impose half-fast regulation (yes, I choose that spelling on purpose -- sound it out ;-) then, or much in the way of regulation in the first place.
That way, when the cozy assumptions of corporate fat-cats don't pan out, the market, and the wise fat-cats who tend to it properly, can respond quickly -- much more quickly than that same beauracratic government is likely to.
Of course, the market will assert itself (it is continually doing so) -- various beauracracies serve as dikes against the flow of the market, for both good and ill, whether within businesses, families, or governments, but the biggest, slowest-to-tear-down, and often most stupidly placed dikes are usually the ones built by government beauracracies. Major dislocations of population, including extremes like mass starvation, can be the results of market forces acting to reconcile reality to long-term patterns of behavior. (Though, in this case, I certainly hope Californians don't move to other states in large numbers, bringing their penchant for electing meddlesome beauracrats with them. ;-)
At least when the dikes built by other organizations (families/households, corporations, non-profits) prove to be poorly placed, too large, too small, etc., the rest of the market can quickly respond without having to relocate en masse to another nation or continent...
As to whether businesses should "lie down" with the "lion" of government at all, or just ignore it (and leave it to the whims of those, such as socialists, who can't get through a day without contemplating all sorts of ways they'd like to impose their wills on others), that's a moral argument only in the extreme -- realistically, it's a strategic and/or tactical decision.
IMO, we should resent the corporate fat-cats who grease the palms (in legal and illegal ways) of government officials less than we do the officials who are so easily greased. We didn't elect the former -- they're behaving out of self-interest, exactly "as intended" -- but the latter supposedly represent the interests of "we, the people", and thus should be able to "just say NO" even to well-meaning attempts by one group to impose its will on another via the iron fist of government.
How such an organization would handle existing for-profit .org domains is not actually specified (as far as I read the document anyway -- through the paragraph about how to handle .org). It might decide, in the long run, to chase 'em all away (bye-bye /..org?), but, more likely, it'd set up a multi-tiered system for maintaining the domain names -- more $$ for non-non-profits (luv them double negatives ;-), for example -- or put some kind of restrictions on what they can do on sites with those names.
Various scenarios have various sorts of problems, but many of these problems are fundamental to the whole domain-naming issue (and many stem from the whole naming issue in the first place).
The idea, though, seems to be to have a non-profit org with funding provide another way for non-profits to obtain, maintain, and pay for their domain names, without being lumped in with all the high-$$ corporates.
That way, if .com addresses become more $$, as I expect will happen down the road under some formula, the non-profits won't be shut out of worthwhile names entirely.
Think of the proposal as offering a "wall of separation" between for-profits and non-profits at a higher, and more useful (since it involves funding), level than just the .org/.com distinction. The for-profit company managing the .com registry won't be tempted to extend its price increases to .org (and the corresponding non-profits) because it won't be managing that registry in the first place -- a funded non-profit org would be handling that.
Admittedly, I'm looking at this issue in a "positive-spin" way. Having heard/read about all sorts of abuses of domain-name registration by one or more companies, I hope this proposal is one means by which they intend to rectify some of these, or at least have the abuses perpetrated for something other than profit for a change...!