one way or the other, what will it really mean? Having majored in finance and having played a few of these types of games it's pretty clear that there is little in the curriculum in most business courses that would apply to these computer strategy games. For one, a large part of running a business comes down to operational skills (i.e., the day to day elements of making a product and/or providing a service with the zillion problems that ALWAYS pop up), which is well outside of the scope of most of what is taught. I also don't think games really test these kinds of skills. For one, they're largely tactical, in my opinion, despite their title. Secondly, most of the rules behind these games can be reduced to simple algorithms. Once you figure out the algorithms approximately, you're set. So much of the game is wrapped up in figuring those out. The only way I can see a business degree possibly helping much is in knowing some of the fundamental concepts behind those algorithms. However, those are so fundamental in my opinion as to be taught in introductory level courses, many of which many people already know.
that this supposedly accurate prediction was just drastically corrected. If it can change from 3.x to 5.8 degrees, then clearly these "brilliant" scientists' science is not that exact of a science. It seriously suggests that they could also be estimating too high, especially when taken in context of previously inflated and failed predictions.
I'm not saying there is _no_ danger, but for anyone to say they _know_ with absolute certainty is ridiculous. What's more, given the political, economic, and social implications of what the proponents of global warming advocate, I think we SHOULD scrutinize their predictions. Perhaps we DO need to take corrective action, but perhaps we DON'T. This matter needs further study.
This is one of the most common and most idiotic arguments against the increased security of open source. It just plain isn't true. It assumes that my ability to have the source code suddenly precludes any other method to finding security problems. Obviously such an argument is flawed.
That is not what I meant at all. Perhaps my statement was a little confusing, but this is slashdot after all, we can't always review every last word. What I meant to say (and I still think is quite obvious) is that the only necessary, positive, and significant contribution to security that Open Source can make over and above what is offered by Closed Source, is the opportunity for wide "peer review". Most everyone would agree with that. What I do disagree with is the assumption that code DOES get reviewed properly.
If I have the source code, I have every method of finding security holes available to closed source projects to me, IN ADDITIION TO the source code. If I find a problem, I can then study the pertinent code, report it to others that are interested, and even try to fix it myself. The fact that it's open gives me more options, and one extra avenue toward finding and closing security holes. It doesen't take away any of the traditional closed source methods.
Yes, you have the opportunity to review the code, in addition to potentially reviewing the benefits of other people's security reviews. However, I feel that you, and many others, also overlook the countervailing side effects of it being open--its vastly increased exposure to blackhats through easier spotting of vulnerabilities and easier exploitation of them. In my opinion, if you're not looking at these two elements, the opportunity for peer review and the potential for blackhat review, as counteracting forces, then you're not fully grasping the situation.
In other words, different situations can totally change the balance. In one situation, closed source may be much more appropriate, while in another open source will be. This is a view that is simply not taken by a large part of the community, thus I shall continue making my point.
Let's just compare the time to fix most security problems between Microsoft products, and Linux. Under the closed source Microsoft products, most security problems are fixed in 'the next service pack', often the next service pack doesn't fix the problem. When a security problem is encountered in a Linux based system, it is often fixed within a couple of days. One example was a security hole found to be present in most Linux systems (I don't feel like looking it up right now), the person writing about it had intended to inform the Linux distributions, then wait a while to give them the opportunity to fix it before he posted to bugtraq. He was complainig because long before he could post to bugtraq, half of the Linux distributiors had already made a fix, and posted it on their website.
It's hardly fair to draw conclusions about closed source software based on MS's products and then compare it to a very limited open source kernel; even the apple has more in common with the orange. Though you may disagree, Linux is JUST a kernel and a rather simple one at that (not necessarily a bad thing, but it's relevant to the question), what's more it's highly modularized. These things fundamentally alter any comparison.
With Open Source software, I am not limited to when the person who owns the software decides to fix it, I can fix it myself if I have the skill. With closed source software, I am completely dependant on someone else.
Sure, with closed source code you're completely dependent on the developers. However, you're overlooking, or not pointing out, other important factors. For instance, you're highly dependent on the developers anyways (be they open or closed). With, say, an RDBMS, your concerns extend not just to security but also data intergrity. So you're trusting them already; you're not entirely self-sufficient, no matter how smart, educated, skilled, or available you are. Furthermore, most closed source products are powered by a market driven mechanism. Any developer that alienates his consumers for too long with security concerns, faces their wrath, and hence, loss of profits. In addition, not all fixes are trivial. Few people have the time, skill, and ability to fix the problem for themselves. If the community cannot or does not fix the problems and you cannot, then you're up shit creek without a paddle. (Which is why the community's efforts are terribly relevant).
One issue that many people ignore is the importance of the developer that actually writes the code. The original developer has a HUGE impact on the security of the code. If that developer is either malicious or careless, security problems WILL happen--patches are not necessarily adequate (both from a timing and an implimentation POV). I would argue that given the "Openess" of Open Source code, you are potentially exposed to the laziness (or maliciousness) of hundreds of developers. Though it is true that many closed source firms pay little attention to security during the release process, closed source firms can also hold their developers more responsible. It's not necessarily always better one way or the other, but it can (and does) come into play.
I wouldn't say they even get one of the major benefits to Open Source. Open source allows many people to look at, and fix (always remember the and fix part it is very important) the code. Yes an internal code audit would turn up several of the security problems that get found by people pouring over an Open Source project, but still, the security problem remains until it is fixed, during which time the black hats can either find or exploit it.
Under Open Source there exists the opportunity to have numerous code audits going on all the time by numerous groups.
Yes, but as I have said numerous times, this doesn't necessarily happen. If it doesn't, it can have tremendous negative effects on the effective security of the product. I would argue that it often doesn't at all and when it does the quality is all over the map.
What's more, much like sofware development in general, 99% of the work is performed by a relatively small group of "experts". (If you don't believe me, try reading bugtraq and other similar forums--you'll generally see the same people) In other words, I question the "wideness" of the review; if it's not wide, it hardly has an edge on properly reviewed closed source.
You're missing the point. Having access to the source does not make it secure, and no one is making that argument. The argument is that access to the source provides you with the opportunity to make it secure. An opportunity you absolutely positively do not have with closed source. Thats the entireity of the argument.
First off, it's my point. I can't miss my own point, in terms of direction, unless I'm totally incompetent.
Second, the reason I make my point is because there are a lot of different mantras that are OFTEN repeated by open source advocates, so-called security-buffs, slashdot zealots, etc. Just because you have not heard them does not mean they do not exist. It's awefully presumptious of you to ASSUME that you have heard it all. If you doubt what I say, then simply go to numerous forums and read them more carefully, even slashdot, and I assure you that you will hear words to that effect.
Third, I submit to you that Open Source's contribution to security is neglibible for 99.99% of the population, if the "entirity" of the argument is that "YOU" (as an individual, without the hyped "sharing" of security amongst those individuals) can fix everything yourself. In other words, unless you know C, security, kernel architecture, etc. well, the odds are that your argument simply does not apply to yourself. What's more, even if you have the skills to detect a bug or two, you probably don't have the inhuman ability to fix them all--it just takes ONE to send you up shitcreek.
Fourth, many people CARE about my point, because I'm arguing effective security--not your moralistic "liberty", "freedom", or what have you. The upwards moderation would suggest that at least a few people think my comment worthy.
Fifth, I have other related points, that apply directly to the comment I was replying to one level above this (his viewpoint ties into one of the mantras). For instance, he essentially stated that it's impossible to put a backdoor in Open Source code, while it's possible in Closed Source. Well, there is no real defence for his position and I attacked it.
The "security thru obscurity does not work" argument refers to security that depends on obscurity to succeed.
No, that depends entirely on who you ask. Many people take "security through obscurity" to mean that the only way that closed source software is secure is because it's obscure. Thus any closed source software is percieved as insecure and, conversely, open source software is necessarily (more) secure.
If your entire security model rests on the proposition that no one must even find out how it works, then your security model fails the moment that obscurity evaporates. Which is a bad security model. Plain and simple.
Sure, I'd generally agree with that statement. However, it is a little too broad. It depends on the environment, the users, etc. Much like the argument for certain cryptography, if cracking it costs more time, effort, and resources then what you could gain, it IS effectively secure. So plain and simple? No.
Likewise, the same applies to Open Source code (as so many people ignore). You can't merely code something, make it open, and just trust it to be secure--no matter how long you wait. Which raises another point (if you accept the previous position), you MUST trust the developers if you CAN'T entirely trust the "peer review" process (or yourself).
these same types of vulnerabilities into their products time and time again. It's one thing when a vulnerability is truely ORIGINAL, but 99% of these are derivative and much older vulnerabilities that could have been detected IF someone checked for them. As a product of carelessness, sure it can happen, but for supposedly legendary "peer review" where thousands of programmers are supposed to check, it should RARELY ever happen. Yet RedHat and most other distributions never fail to release a new distribution with at least 5 remote vulnerabilities, many with the same servives--over and over. I'd at least expect RedHat to check....
Oh well, I've got to run. I believe in the POTENTIAL for Open Source to be a mechanism for secure code (at least for certain TYPES of code), but it's generally not happening today.
Saying that deregulation is part of the problem is sort of like saying that "freedom" is part of the problem for any number of problems. Though this so-called deregulation effort may brought about the current events to some extent, saying that it's deregulation's fault confuses the matter. It's been done successfully in a great many markets. Furthermore, it's quite clear that the issue is the MANNER in which it was implemented (i.e., fixed retail prices) by WHOM and other particular preexisting elements in California's energy market.
. I don't understand why the government was willing to sit back and watch the power companies fuck up California's power supply, through their idiotic cartels.
Any reasonably responsible government anywhere else in the world would have kicked serious ass, and ordered the incompetents to build more power stations. And whether its against the American way or not for the government to interfere with the private sector is just so much twaddle. Our government should damn well pull its finger out of its ass and start ordering private companies to do its bidding, at least when these companies are the crux of the most econimcally powerful state od the union. It's in the best interests of everyone that they do so.
First, they're NOT operating at maximum capacity. This means that LACK of power is not the issue per se, it's economics. The wacko way in which this so-called deregulation was implimented the retail power companies are forced to deliver power below cost (e.g., fix/regulated retail prices, with higher market prices). Though this may tie back into supply and demand, in the sense that increased demand makes that power more expensive, don't confuse this with lack of power.
Second, most of the power retailers are LOSING money hand over hand because of the current situation. If anyone is a cartel it's the wholesalers--which is a much more complex situation.
Third, the reason why the government can't merely say "build more powerplants or else" (as if that is the real problem right now), is because money doesn't grow on trees. If power costs more for the companies to acquire (or produce) then they can sell it for, then companies will simply not sell. The companies are not some magical entity that can just absorb these costs. In fact, given their relatively low margins, operating at below cost will QUICKLY put them out of business (as is being demonstrated now). This means that shareholders and lenders will not supply money to the power companies. In other words, the power companies either raise their retail prices OR the government itself starts paying. If the government pays this is coming out of tax payer pockets anyways. Either way, you're back at square one.
Deregulation has SUCCESSFULLY circumvented these problems in many markets by allowing the companies to respond economically to demand. For instance, when demand starts to rise relative to supply, prices increase. This increases the incentive for the companies to build powerplants. Whereas in California's poorly deregulated market, they're not allowed to raise prices. Furthermore, they are (rightly) nervous that the government will step in shortly after they've spent billions on new powerplants.
What this probably protects from the most is security holes introduced intentionally by the authors, whether that is sanctioned by the vendor or not. Take the case of so many systems with backdoor passwords. Open Source exposes this, if someone were to be stupid enough to do it.
Does it though? Sure, in any popular piece of Open Source code it's unlikely that I could hide a backdoor trigged by a trivial string like, say, "MY VOICE IS MY PASSWORD", where that is entirely possible with unreviewed closed source code. However, I'd argue that the existence of a significant number of security flaws in many Open SOurce projects is proof that a backdoor CAN be hidden, if so desired. Afterall, if a backdoor can be added and remain in closed source code entirely as the product of an accident, what is to stop a coder from doing the exact same thing, only intentionally? If they're smart enough to code that piece of code, they're smart enough to plant a backdoor in there that can escape detection. Whether this backdoor requires a machine code overflow, a race condition, or a simple string is virtually irrelevant. What's more, I'd assert that while the bar may be raised normally for coding a backdoor, the opportunity for the hacker to insert MALICIOUS code increases by at least a factor of 10. In addition, entirely beyond the scope of "peer review" when these products are actually consumed by the user, it's rare that the consumer will himself be able to CHECK all the code. The vast majority of users either install with./config scripts and such automatically or they use pre-compiled binaries/rpms--which are definitely vulnerable.
I do suspect the whitehats way outnumber the blackhats.
Maybe, maybe not. That's an important assumption that the open source community makes and tends to pay little attention to. I'm not saying it IS, but it's quite possible that there is more incentive to be a blackhat (ethics aside) then a whitehat on certain projects. Is there any real empirical evidence one way or the other? Can you say with certainty that the black hat community has discovered a significant number of flaws long before the white hat community with closed source software? It seems to me that they're quite rare in both cases, at least in terms of what is publicised. And if it's not publicised, we have a hard time knowing.
I would not make that choice. Of course exploits are harder to find with closed source. But this just results in a greater time delay before they are discovered. The number of blackhats is reduced somewhat while the number of whitehats is reduced radically, with closed source.
All of this comes down to numbers, which none of us really has. If it's a matter of mere delay and open source is so superior, then we'd expect there to be a clear difference empirically. I'd argue that this difference is not nearly as wide as many suggest, and often times is less than favorable for Open Source.
Anyways, I dont have time to finish this argument off, I've got a bunch of work to finish off. Maybe later...
Before I begin, let me state that there is some merit to the Open Source security "process" (if you could call it that) AND there are legitimate concerns with companies merely shirking off ALL concern for security while depending 100% on so-called obscurity. That being said, I have real issue with going from "security through obscurity" is not a cure-all, to the Open Source mantra that "security through obscurity" has absolutely no merit. A couple key points that all too many just glaze over:
First, the only way the Open Source security philosophy really works is if people ACTUALLY (as opposed to theoretically) sit down and read the code for security flaws in its entirity. I would argue that in a great many cases, no one even approaches this level. Because the Open Source community has very little centralization of effort, there is going to be a great deal of redundancy. In other words, even if you believe that 1000 security "experts" will spend some time reviewing the code, they may well be looking at the same piece of code (which in and of itself, can be a good thing), while leaving other pieces of code largely unscrutinized. Furthermore, I suspect that very few people truely give the code the time of day.
Second, while Open Source makes it easier for white hats to find flaws, it also makes it easier for blackhats to find and exploit flaws. This is particularly relevant if, as I point out, the code is not getting the right kind of attention from white hats.
Third, Closed Source can make it HARDER and DULLER to find flaws. Many people seem to assume that just because obscure products have been cracked, that there is absolutely no reedeeming value to it being closed. In other words, at any given moment in time, if we could some how have two parallel universes that would allow you to have the same piece of code (let's say the latest stable linux kernel with all patches applied) in Open Source and Closed Source at the same time, without knowledge leaking either way, most reasonable people would prefer the Closed Source option.
Fourth, security flaws are found all the time in Open Source code projects. A lot of them are presumably stable pieces of code that have already been put into production. These systems get hacked REGULARLY. Now this isn't to say the same doesn't apply to closed source, but you can't ignore the problem either way.
Fifth, many people constantly bring up the point "well if you just patch regularly...". While I agree that everyone SHOULD do this if possible, it's not always possible, and it's frequently not economical. If there is a piece of closed source code that hasn't had any published (or suspected) security flaws in 4 years of existence, while the competing Open Source alternatives have had many (constantly forcing their admins to patch), then that's a real issue for any competent admin.
Sixth, it's entirely possible for a Closed Source company to do a full internal security audit of their code. It may not be perfect, but it's better than nothing. Although I fully realize that hardly anyone does this, it'd be a mistake to ignore this as an option. If a company can get _most_ of the (presumed) benefits of an Open Source security audit without the corresponding exposure of their source code to blackhats (or at least less "risk" of that), then that might be very good indeed.
In summation, this is not nearly as black and white as people protray it. It comes down to numbers and many other unquantifiable elements. A simple philosophy is a not a one time cure-all. For instance, as I have alluded to, if there are very few white hats reviewing the code (say 50) and those white hats are mostly replicating their own work (say 15% efficiency) while allowing any black hat with proper monetary motivation to put the effort into cracking easy to read source code, then you might well be worse off. The same goes the other way around, if a software company, as all too many do, rush their product out with little to no review and depend entirely on obscurity, they might well use some routines that are well known security problems that can be easily searched for....
The bottom line is that it is just as stupid to assume your carelessness will be automatically covered by "peer review" (or "Open Source") as it is to assume it will be covered by "obscurity".
What is "at large" exactly? If you're talking about a town with 99% white population, then the odds are very high that you'll get an all white jury. Likewise, if you sample the country as a whole, the majority is still non-black; it is very possible (in fact, it happens regularly) that you'll get an all white jury. What you're presumably looking for is balance and impartiality. Though a larger or more "even" sampling may flatten out some unbalances, it's far from a guarantee of impartiality.
As long as you're talking about humans, there is always the possibility that there is bias one way or the other. I remember just a couple months ago, businessweek, or some similar magazine, did a survey on Americans' attitudes towards business. A rather alarming percentage of those polled showed definite suspicion against companies in general. That's a bias right there. If the situations were different, if the accused was a black person and the jury, white, with a majority having suspicions of black people then you'd never hear the end of it.
This is not to say that i'm sympathetic towards MS at all (i'm not), but I'm simply making my point. Juries are not guaranteed to be impartial, never mind intelligent, sophisticated, intellectual, educated, etc. In fact, quite the opposite, they tend to be less capable than society as a whole. Furthermore, on the balance, most companies PREFER trial by judge, not jury. It removes a great deal of unpredicability.
First, you're mistaken if you believe that juries are "incapable" of being biased. Go back to your history books and you'll see hundreds of cases where juries have overlooked vast amounts of evidence to arrive at a guilty (or not guilty) verdict.
Second, one of the fundamental aspects to a jury is the right to have a jury of your so-called peers. No single person is nearly as wealthy or pervasive of MS. Hell, no one on any jury is even going to remotely approach Bill Gates' wealth. How is the average jury supposed to know the difference between, say, 50m dollars and 5b dollars to a companies bottom line? If you look at a great many tort cases, some clearly haven't the foggiest idea.
Third, just because a case requires some sophistication to fully comprehend doesn't mean it is not worth while. If we're going to talk about, say, medical malpractice, then we want someone that understands medicine or, if not that, at least someone that has enough sophistication to understand junk science and poor logic.
Fourth, many of us as consumers _know_ MS broke the law. That doesn't necessarily mean we want to convict a company or a person soley on that basis, but to say we don't "know" before a jury tells us a poppycock. That's like stating that a rape victim doesn't know she (or he) was raped until the jury says so.
oh well, that's enough for now
Well said, moderate this up!
on
'Thirteen Days'
·
· Score: 2
of this summer camp I went to way back when. On this one island they had this campground of sorts with a primative outhouse, basically comprising a few sheets of plywood, built into a primitive toilet over a dirt ditch no more than 6 feet deep. One year a girl fell in when the plywood broke on her. Apparently she was stuck in there for 30 minutes or so before anyone discovered her. When she got out, she was absolutely non-linear....
I can't even imagine. *Barf* Especially in the heat...ugg
heh, i'm the other way around. I simply hate handwriting. Whenever I do it I spend far more time trying to write somewhat legibly then I do producing quality work. Of course, I started doing most of papers on computer in 4th grade. The problem is that I can't generally afford to lug a computer (just for notes) into class and meetings. Although I doubt this thing in the solution for me, it'll be nice when the form factor and price of these laptops improves, not to mention their acceptance.
He's also a Democrat and the trial lawyers spend a great amount of money lobbying them. This is not to say that all democrats are in their pockets, but it's certainly a reason to be skeptical of his absolute unwillingness to budge on anything relating to tort law.
You are wrong about the time aspect, the second any backdoor is introduced, there is a security problem - not when someone other than the person that coded it finds it.
That is the big difference - in an open source project, a security flaw is accidental, and not exploitable until someone finds it - and hopefully it is the comunity that finds it and not a hacker. With a backdoor in a closed source project, security is broken immediately. The person that coded it knows about, his friends, the person that asked him to put it there, etc....
Huh? This strikes me as a rather semantic argument. It all depends on how you define the word "problem". In any event, I'd say (and I think most others would agree to) that the most pressing security concern of any product consumer, be it open source or closed, is the effective security of the product. How the problem came to be is not nearly as relevant to the consumer as IF and WHEN it becomes known. Notice: This is not the same thing as saying that just because a problem is unknown at some point in time that it is irrelevant...as long as there is an (actual) risk it is relevant. However, it is equally stupid to somehow imply that any closed source product with any backdoor (no matter WHEN or IF it is discovered) is somehow, necessarily, more problematic for everyone then an Open Source product with a zillion "accidental" security flaws that are discovered haphazardly in great number.
Put simply, I'd rather face the risk of ONE developer knowing a backdoor (or bug or flaw) exists than face a zillion hackers armed with many different exploits on the comparable open source product long before. One might argue this empirically: the percentage of highly exposed interbase dbs that were hacked versus the somewhat equivelent MySQL database (which, incidentally, has seen it's fair share of security problems).
All of this, however, is entirely besides my original point. The point is that the poster I was replying to, and indeed a great deal of open source dogma, says that such backdoors are impossible to hide for an extended period of time in a popular Open Source project. I simply assert that: If security flaws can lay dormant for years as the result of improper coding in popular Open Source products, then an honest to god backdoor can certainly be hidden in there by an intelligent coder with equal or greater success, even if it isn't trigged by something as trivial as "MY VOICE IS MY PASSWORD".
Uh. First off, that doesn't mean open source products are any more secure. Second, many of them do not involve buffer overflows at all, but rather race conditions, poor checking of passwords, fundamentally flawed security architecture, terribly stupid flaws (remember phf?), etc. Third, more difficult for whom and in what way?
It would take a hacker a significant amount of time to discover a properly hidden and hardcoded backdoor in a closed source product. Notice how many years it took ANYONE to discover this. That is "difficult", or rather time consuming for the hacker. You might say it's easy to reproduce, but that's true for literally hundreds of Open Source security flaws. Once a hacker discovers a means and releases an exploit, the work is done. It doesn't matter to the hax0r, aka script kiddy, if exploit.c sends "LET ME IN BACKDOOR" or a bunch of machine code to the target host. Furthermore, it's quite easy to test for the existence (or at least the probable existence) of a security flaw via improper bounds checking. In other words, you just send a bunch of different programs extra long strings on various inputs until something crashes, then you simply do the work to make the exploit happen. Compare this with trying to find a well hidden backdoor in a closed source product, you either try to reverse engineer the binary or you can try brute force. In either case, it's much harder to detect.
So the question remains, easier for whom and how is that relevant? It's really not terribly relevant if you ask me. The question is how secure is YOUR product at the end of the day in YOUR environment for YOUR needs. If you start overgeneralizing by saying "Open Source is secure, Closed Source is not" then you're making a fundamental mistake. Rhetoric and dogma are not conducive to practical security.
Oh bullshit. There are security flaws found all the time in Open Source products, many of them quite old. If careless coding can create a security flaw on accident that can slip past so-called "peer review", then certainly a reasonably intelligent person could slip in a very subtle backdoor that is infinititely harder to detect. About all you can really say generally about Open source security is that an ultra-trivial backdoor opened with a string like "I AM BACKDOOR" is unlikely, because even the casual reader it apt to notice.
Well, sweetie, you just haven't been paying attention. It's flamin' gay, or lesbian.
Or maybe you just don't know it as well as you think you do. I lived there for 7 years, I know full well what is and is not there. Granted, there are still _some_ in many areas, but not more so than other parts of the country, and especially not more than Seattle on average. If you venture a little further North than Volunteer Park (or even adjacent parts of Federal Avenue), for instance, you'll find some very nice / conservative houses. Likewise, if you step back away from those little clusters surrounding Broadway, particularly to the more expensive parts, you'll find a dramatic difference. And yes, I have been back there since, those neighborhoods are largely the same, only substantially more expensive.
Put simply, you're over-generalizing. You might say Capital Hill, when taken on whole has a larger gay presence than other parts of Seattle (because of those clusters), but you're simply wrong if you imply that the entire neighborhood is "flaming."
Ahem. I used to live in Capital Hill. It's neither gay nor bohemian, only certain clusters of it are. Like some parts of Broadway and the surrounding areas have a high gay population, but others have no more than most any other area (especially relative to Seattle in general)
Slashdot Mirror
one way or the other, what will it really mean? Having majored in finance and having played a few of these types of games it's pretty clear that there is little in the curriculum in most business courses that would apply to these computer strategy games. For one, a large part of running a business comes down to operational skills (i.e., the day to day elements of making a product and/or providing a service with the zillion problems that ALWAYS pop up), which is well outside of the scope of most of what is taught. I also don't think games really test these kinds of skills. For one, they're largely tactical, in my opinion, despite their title. Secondly, most of the rules behind these games can be reduced to simple algorithms. Once you figure out the algorithms approximately, you're set. So much of the game is wrapped up in figuring those out. The only way I can see a business degree possibly helping much is in knowing some of the fundamental concepts behind those algorithms. However, those are so fundamental in my opinion as to be taught in introductory level courses, many of which many people already know.
Haha, too true. Perhaps 13221 bytes in BODY, but only 20 bytes in HEAD is more apropos? ;P
You're a washed up hack, face it. Why don't you go back to writing fortune cookies or something?
that this supposedly accurate prediction was just drastically corrected. If it can change from 3.x to 5.8 degrees, then clearly these "brilliant" scientists' science is not that exact of a science. It seriously suggests that they could also be estimating too high, especially when taken in context of previously inflated and failed predictions.
I'm not saying there is _no_ danger, but for anyone to say they _know_ with absolute certainty is ridiculous. What's more, given the political, economic, and social implications of what the proponents of global warming advocate, I think we SHOULD scrutinize their predictions. Perhaps we DO need to take corrective action, but perhaps we DON'T. This matter needs further study.
But you should have blamed yt!
- Grasshopa
Yes, you have the opportunity to review the code, in addition to potentially reviewing the benefits of other people's security reviews. However, I feel that you, and many others, also overlook the countervailing side effects of it being open--its vastly increased exposure to blackhats through easier spotting of vulnerabilities and easier exploitation of them. In my opinion, if you're not looking at these two elements, the opportunity for peer review and the potential for blackhat review, as counteracting forces, then you're not fully grasping the situation.
In other words, different situations can totally change the balance. In one situation, closed source may be much more appropriate, while in another open source will be. This is a view that is simply not taken by a large part of the community, thus I shall continue making my point.
It's hardly fair to draw conclusions about closed source software based on MS's products and then compare it to a very limited open source kernel; even the apple has more in common with the orange. Though you may disagree, Linux is JUST a kernel and a rather simple one at that (not necessarily a bad thing, but it's relevant to the question), what's more it's highly modularized. These things fundamentally alter any comparison.
Sure, with closed source code you're completely dependent on the developers. However, you're overlooking, or not pointing out, other important factors. For instance, you're highly dependent on the developers anyways (be they open or closed). With, say, an RDBMS, your concerns extend not just to security but also data intergrity. So you're trusting them already; you're not entirely self-sufficient, no matter how smart, educated, skilled, or available you are. Furthermore, most closed source products are powered by a market driven mechanism. Any developer that alienates his consumers for too long with security concerns, faces their wrath, and hence, loss of profits. In addition, not all fixes are trivial. Few people have the time, skill, and ability to fix the problem for themselves. If the community cannot or does not fix the problems and you cannot, then you're up shit creek without a paddle. (Which is why the community's efforts are terribly relevant).
One issue that many people ignore is the importance of the developer that actually writes the code. The original developer has a HUGE impact on the security of the code. If that developer is either malicious or careless, security problems WILL happen--patches are not necessarily adequate (both from a timing and an implimentation POV). I would argue that given the "Openess" of Open Source code, you are potentially exposed to the laziness (or maliciousness) of hundreds of developers. Though it is true that many closed source firms pay little attention to security during the release process, closed source firms can also hold their developers more responsible. It's not necessarily always better one way or the other, but it can (and does) come into play.
Yes, but as I have said numerous times, this doesn't necessarily happen. If it doesn't, it can have tremendous negative effects on the effective security of the product. I would argue that it often doesn't at all and when it does the quality is all over the map.
What's more, much like sofware development in general, 99% of the work is performed by a relatively small group of "experts". (If you don't believe me, try reading bugtraq and other similar forums--you'll generally see the same people) In other words, I question the "wideness" of the review; if it's not wide, it hardly has an edge on properly reviewed closed source.
Second, the reason I make my point is because there are a lot of different mantras that are OFTEN repeated by open source advocates, so-called security-buffs, slashdot zealots, etc. Just because you have not heard them does not mean they do not exist. It's awefully presumptious of you to ASSUME that you have heard it all. If you doubt what I say, then simply go to numerous forums and read them more carefully, even slashdot, and I assure you that you will hear words to that effect.
Third, I submit to you that Open Source's contribution to security is neglibible for 99.99% of the population, if the "entirity" of the argument is that "YOU" (as an individual, without the hyped "sharing" of security amongst those individuals) can fix everything yourself. In other words, unless you know C, security, kernel architecture, etc. well, the odds are that your argument simply does not apply to yourself. What's more, even if you have the skills to detect a bug or two, you probably don't have the inhuman ability to fix them all--it just takes ONE to send you up shitcreek.
Fourth, many people CARE about my point, because I'm arguing effective security--not your moralistic "liberty", "freedom", or what have you. The upwards moderation would suggest that at least a few people think my comment worthy.
Fifth, I have other related points, that apply directly to the comment I was replying to one level above this (his viewpoint ties into one of the mantras). For instance, he essentially stated that it's impossible to put a backdoor in Open Source code, while it's possible in Closed Source. Well, there is no real defence for his position and I attacked it.
No, that depends entirely on who you ask. Many people take "security through obscurity" to mean that the only way that closed source software is secure is because it's obscure. Thus any closed source software is percieved as insecure and, conversely, open source software is necessarily (more) secure.
Sure, I'd generally agree with that statement. However, it is a little too broad. It depends on the environment, the users, etc. Much like the argument for certain cryptography, if cracking it costs more time, effort, and resources then what you could gain, it IS effectively secure. So plain and simple? No.
Likewise, the same applies to Open Source code (as so many people ignore). You can't merely code something, make it open, and just trust it to be secure--no matter how long you wait. Which raises another point (if you accept the previous position), you MUST trust the developers if you CAN'T entirely trust the "peer review" process (or yourself).
these same types of vulnerabilities into their products time and time again. It's one thing when a vulnerability is truely ORIGINAL, but 99% of these are derivative and much older vulnerabilities that could have been detected IF someone checked for them. As a product of carelessness, sure it can happen, but for supposedly legendary "peer review" where thousands of programmers are supposed to check, it should RARELY ever happen. Yet RedHat and most other distributions never fail to release a new distribution with at least 5 remote vulnerabilities, many with the same servives--over and over. I'd at least expect RedHat to check....
Oh well, I've got to run. I believe in the POTENTIAL for Open Source to be a mechanism for secure code (at least for certain TYPES of code), but it's generally not happening today.
First, they're NOT operating at maximum capacity. This means that LACK of power is not the issue per se, it's economics. The wacko way in which this so-called deregulation was implimented the retail power companies are forced to deliver power below cost (e.g., fix/regulated retail prices, with higher market prices). Though this may tie back into supply and demand, in the sense that increased demand makes that power more expensive, don't confuse this with lack of power.
Second, most of the power retailers are LOSING money hand over hand because of the current situation. If anyone is a cartel it's the wholesalers--which is a much more complex situation.
Third, the reason why the government can't merely say "build more powerplants or else" (as if that is the real problem right now), is because money doesn't grow on trees. If power costs more for the companies to acquire (or produce) then they can sell it for, then companies will simply not sell. The companies are not some magical entity that can just absorb these costs. In fact, given their relatively low margins, operating at below cost will QUICKLY put them out of business (as is being demonstrated now). This means that shareholders and lenders will not supply money to the power companies. In other words, the power companies either raise their retail prices OR the government itself starts paying. If the government pays this is coming out of tax payer pockets anyways. Either way, you're back at square one.
Deregulation has SUCCESSFULLY circumvented these problems in many markets by allowing the companies to respond economically to demand. For instance, when demand starts to rise relative to supply, prices increase. This increases the incentive for the companies to build powerplants. Whereas in California's poorly deregulated market, they're not allowed to raise prices. Furthermore, they are (rightly) nervous that the government will step in shortly after they've spent billions on new powerplants.
Maybe, maybe not. That's an important assumption that the open source community makes and tends to pay little attention to. I'm not saying it IS, but it's quite possible that there is more incentive to be a blackhat (ethics aside) then a whitehat on certain projects. Is there any real empirical evidence one way or the other? Can you say with certainty that the black hat community has discovered a significant number of flaws long before the white hat community with closed source software? It seems to me that they're quite rare in both cases, at least in terms of what is publicised. And if it's not publicised, we have a hard time knowing.
All of this comes down to numbers, which none of us really has. If it's a matter of mere delay and open source is so superior, then we'd expect there to be a clear difference empirically. I'd argue that this difference is not nearly as wide as many suggest, and often times is less than favorable for Open Source.
Anyways, I dont have time to finish this argument off, I've got a bunch of work to finish off. Maybe later...
Before I begin, let me state that there is some merit to the Open Source security "process" (if you could call it that) AND there are legitimate concerns with companies merely shirking off ALL concern for security while depending 100% on so-called obscurity. That being said, I have real issue with going from "security through obscurity" is not a cure-all, to the Open Source mantra that "security through obscurity" has absolutely no merit. A couple key points that all too many just glaze over:
First, the only way the Open Source security philosophy really works is if people ACTUALLY (as opposed to theoretically) sit down and read the code for security flaws in its entirity. I would argue that in a great many cases, no one even approaches this level. Because the Open Source community has very little centralization of effort, there is going to be a great deal of redundancy. In other words, even if you believe that 1000 security "experts" will spend some time reviewing the code, they may well be looking at the same piece of code (which in and of itself, can be a good thing), while leaving other pieces of code largely unscrutinized. Furthermore, I suspect that very few people truely give the code the time of day.
Second, while Open Source makes it easier for white hats to find flaws, it also makes it easier for blackhats to find and exploit flaws. This is particularly relevant if, as I point out, the code is not getting the right kind of attention from white hats.
Third, Closed Source can make it HARDER and DULLER to find flaws. Many people seem to assume that just because obscure products have been cracked, that there is absolutely no reedeeming value to it being closed. In other words, at any given moment in time, if we could some how have two parallel universes that would allow you to have the same piece of code (let's say the latest stable linux kernel with all patches applied) in Open Source and Closed Source at the same time, without knowledge leaking either way, most reasonable people would prefer the Closed Source option.
Fourth, security flaws are found all the time in Open Source code projects. A lot of them are presumably stable pieces of code that have already been put into production. These systems get hacked REGULARLY. Now this isn't to say the same doesn't apply to closed source, but you can't ignore the problem either way.
Fifth, many people constantly bring up the point "well if you just patch regularly...". While I agree that everyone SHOULD do this if possible, it's not always possible, and it's frequently not economical. If there is a piece of closed source code that hasn't had any published (or suspected) security flaws in 4 years of existence, while the competing Open Source alternatives have had many (constantly forcing their admins to patch), then that's a real issue for any competent admin.
Sixth, it's entirely possible for a Closed Source company to do a full internal security audit of their code. It may not be perfect, but it's better than nothing. Although I fully realize that hardly anyone does this, it'd be a mistake to ignore this as an option. If a company can get _most_ of the (presumed) benefits of an Open Source security audit without the corresponding exposure of their source code to blackhats (or at least less "risk" of that), then that might be very good indeed.
In summation, this is not nearly as black and white as people protray it. It comes down to numbers and many other unquantifiable elements. A simple philosophy is a not a one time cure-all. For instance, as I have alluded to, if there are very few white hats reviewing the code (say 50) and those white hats are mostly replicating their own work (say 15% efficiency) while allowing any black hat with proper monetary motivation to put the effort into cracking easy to read source code, then you might well be worse off. The same goes the other way around, if a software company, as all too many do, rush their product out with little to no review and depend entirely on obscurity, they might well use some routines that are well known security problems that can be easily searched for....
The bottom line is that it is just as stupid to assume your carelessness will be automatically covered by "peer review" (or "Open Source") as it is to assume it will be covered by "obscurity".
What is "at large" exactly? If you're talking about a town with 99% white population, then the odds are very high that you'll get an all white jury. Likewise, if you sample the country as a whole, the majority is still non-black; it is very possible (in fact, it happens regularly) that you'll get an all white jury. What you're presumably looking for is balance and impartiality. Though a larger or more "even" sampling may flatten out some unbalances, it's far from a guarantee of impartiality.
As long as you're talking about humans, there is always the possibility that there is bias one way or the other. I remember just a couple months ago, businessweek, or some similar magazine, did a survey on Americans' attitudes towards business. A rather alarming percentage of those polled showed definite suspicion against companies in general. That's a bias right there. If the situations were different, if the accused was a black person and the jury, white, with a majority having suspicions of black people then you'd never hear the end of it.
This is not to say that i'm sympathetic towards MS at all (i'm not), but I'm simply making my point. Juries are not guaranteed to be impartial, never mind intelligent, sophisticated, intellectual, educated, etc. In fact, quite the opposite, they tend to be less capable than society as a whole. Furthermore, on the balance, most companies PREFER trial by judge, not jury. It removes a great deal of unpredicability.
First, you're mistaken if you believe that juries are "incapable" of being biased. Go back to your history books and you'll see hundreds of cases where juries have overlooked vast amounts of evidence to arrive at a guilty (or not guilty) verdict.
Second, one of the fundamental aspects to a jury is the right to have a jury of your so-called peers. No single person is nearly as wealthy or pervasive of MS. Hell, no one on any jury is even going to remotely approach Bill Gates' wealth. How is the average jury supposed to know the difference between, say, 50m dollars and 5b dollars to a companies bottom line? If you look at a great many tort cases, some clearly haven't the foggiest idea.
Third, just because a case requires some sophistication to fully comprehend doesn't mean it is not worth while. If we're going to talk about, say, medical malpractice, then we want someone that understands medicine or, if not that, at least someone that has enough sophistication to understand junk science and poor logic.
Fourth, many of us as consumers _know_ MS broke the law. That doesn't necessarily mean we want to convict a company or a person soley on that basis, but to say we don't "know" before a jury tells us a poppycock. That's like stating that a rape victim doesn't know she (or he) was raped until the jury says so.
oh well, that's enough for now
EOF
All I want to know is: How can Katz even say this with a straight face? He is king of hysteria and hype...
of this summer camp I went to way back when. On this one island they had this campground of sorts with a primative outhouse, basically comprising a few sheets of plywood, built into a primitive toilet over a dirt ditch no more than 6 feet deep. One year a girl fell in when the plywood broke on her. Apparently she was stuck in there for 30 minutes or so before anyone discovered her. When she got out, she was absolutely non-linear....
I can't even imagine. *Barf* Especially in the heat...ugg
heh, i'm the other way around. I simply hate handwriting. Whenever I do it I spend far more time trying to write somewhat legibly then I do producing quality work. Of course, I started doing most of papers on computer in 4th grade. The problem is that I can't generally afford to lug a computer (just for notes) into class and meetings. Although I doubt this thing in the solution for me, it'll be nice when the form factor and price of these laptops improves, not to mention their acceptance.
He's also a Democrat and the trial lawyers spend a great amount of money lobbying them. This is not to say that all democrats are in their pockets, but it's certainly a reason to be skeptical of his absolute unwillingness to budge on anything relating to tort law.
Huh? This strikes me as a rather semantic argument. It all depends on how you define the word "problem". In any event, I'd say (and I think most others would agree to) that the most pressing security concern of any product consumer, be it open source or closed, is the effective security of the product. How the problem came to be is not nearly as relevant to the consumer as IF and WHEN it becomes known. Notice: This is not the same thing as saying that just because a problem is unknown at some point in time that it is irrelevant...as long as there is an (actual) risk it is relevant. However, it is equally stupid to somehow imply that any closed source product with any backdoor (no matter WHEN or IF it is discovered) is somehow, necessarily, more problematic for everyone then an Open Source product with a zillion "accidental" security flaws that are discovered haphazardly in great number.
Put simply, I'd rather face the risk of ONE developer knowing a backdoor (or bug or flaw) exists than face a zillion hackers armed with many different exploits on the comparable open source product long before. One might argue this empirically: the percentage of highly exposed interbase dbs that were hacked versus the somewhat equivelent MySQL database (which, incidentally, has seen it's fair share of security problems).
All of this, however, is entirely besides my original point. The point is that the poster I was replying to, and indeed a great deal of open source dogma, says that such backdoors are impossible to hide for an extended period of time in a popular Open Source project. I simply assert that: If security flaws can lay dormant for years as the result of improper coding in popular Open Source products, then an honest to god backdoor can certainly be hidden in there by an intelligent coder with equal or greater success, even if it isn't trigged by something as trivial as "MY VOICE IS MY PASSWORD".
Uh. First off, that doesn't mean open source products are any more secure. Second, many of them do not involve buffer overflows at all, but rather race conditions, poor checking of passwords, fundamentally flawed security architecture, terribly stupid flaws (remember phf?), etc. Third, more difficult for whom and in what way?
It would take a hacker a significant amount of time to discover a properly hidden and hardcoded backdoor in a closed source product. Notice how many years it took ANYONE to discover this. That is "difficult", or rather time consuming for the hacker. You might say it's easy to reproduce, but that's true for literally hundreds of Open Source security flaws. Once a hacker discovers a means and releases an exploit, the work is done. It doesn't matter to the hax0r, aka script kiddy, if exploit.c sends "LET ME IN BACKDOOR" or a bunch of machine code to the target host. Furthermore, it's quite easy to test for the existence (or at least the probable existence) of a security flaw via improper bounds checking. In other words, you just send a bunch of different programs extra long strings on various inputs until something crashes, then you simply do the work to make the exploit happen. Compare this with trying to find a well hidden backdoor in a closed source product, you either try to reverse engineer the binary or you can try brute force. In either case, it's much harder to detect.
So the question remains, easier for whom and how is that relevant? It's really not terribly relevant if you ask me. The question is how secure is YOUR product at the end of the day in YOUR environment for YOUR needs. If you start overgeneralizing by saying "Open Source is secure, Closed Source is not" then you're making a fundamental mistake. Rhetoric and dogma are not conducive to practical security.
Oh bullshit. There are security flaws found all the time in Open Source products, many of them quite old. If careless coding can create a security flaw on accident that can slip past so-called "peer review", then certainly a reasonably intelligent person could slip in a very subtle backdoor that is infinititely harder to detect. About all you can really say generally about Open source security is that an ultra-trivial backdoor opened with a string like "I AM BACKDOOR" is unlikely, because even the casual reader it apt to notice.
BS. I used to live there. You don't know what you're talking about.
Or maybe you just don't know it as well as you think you do. I lived there for 7 years, I know full well what is and is not there. Granted, there are still _some_ in many areas, but not more so than other parts of the country, and especially not more than Seattle on average. If you venture a little further North than Volunteer Park (or even adjacent parts of Federal Avenue), for instance, you'll find some very nice / conservative houses. Likewise, if you step back away from those little clusters surrounding Broadway, particularly to the more expensive parts, you'll find a dramatic difference. And yes, I have been back there since, those neighborhoods are largely the same, only substantially more expensive.
Put simply, you're over-generalizing. You might say Capital Hill, when taken on whole has a larger gay presence than other parts of Seattle (because of those clusters), but you're simply wrong if you imply that the entire neighborhood is "flaming."
Capitol.
Ahem. I used to live in Capital Hill. It's neither gay nor bohemian, only certain clusters of it are. Like some parts of Broadway and the surrounding areas have a high gay population, but others have no more than most any other area (especially relative to Seattle in general)