No, no, no. *BSD isn't dead, it's just dying -- it's official, Netcraft has been confirming it for about ten years. And PC Week has already told us that Apple is dead -- they're closely tied because Apple uses a BSD user space on top of a Mach kernel.
Posted on Mozilla on FreeBSD 5.2--a dead browser on a dead OS. Dead on.
Priceless! I was trying to figure out how the hell this could possibly work, until I hit the last paragraph.
Somebody mark the parent as the best troll of the year! (look at the name of the comment's submitter if you're wondering why I think it's a troll, not just a clever posting.)
You didn't read the article, did you? What you're describing as good management practice is exactly what he's advocating.
Anyone who manages developers knows that there stars on your team, the guys that you give the really gnarly problems to, the women who know the subtle details of a particular issue. You know who they are, rock-solid, dependable, hard-working. You trust them to turn out good work even when the world is going to hell around them.
Problem is, they need to be supported. It's easy to let a star go dark, trusting that what will come out the back will be great code. Most of the time, it will be. Management is about preventing the minority case when it's possible to do so -- and you do that by not letting the star be completely isolated.
Naturally, we'll exclude non-profit and free-software vendors because they couldn't possibly have the financial resources necessary to produce quality software.
So you're saying that Linux and its graphical work environments, upon the development of which large companies spend billions of dollars each year, don't have much money? Or are you claiming that a Linux 2.6 box running Gnome or KDE is a piece of shit? Inquiring minds want to know...
The problem with your "new" way of doing business is (1) it isn't new and (2) it doesn't work now any more than it ever did.
Having an itch to scratch does nothing for the guy who's gambled his way under a mountain of debt and who goes from being completely trustworthy to being willing to steal from his best friend, to say nothing of his employer. That's not a hypothetical case; I'm thinking of a particular person with whom I worked about a decade ago. (Luckily for me, I wasn't one of his friends, so he didn't rip me off.) People change, and someone who's completely trustworthy today may not be five years from now. Worse, people are not always what they seem, and only observation over a very long term reveals them for what they are.
Who watches the watchers? I don't know -- but they need to be there in any org which handles things of value.
When I was a young man, a bank in New York hired an ourside consultant to find out how to protect their data against their programmers. The response was one of the shortest lists of recommendations ever:
No -- it's good engineering. If you know that something can fail in ordinary usage, you drive it to collapse during testing to determine whether you can recover, and, if so, how to do that. It's like randomly triggering out of memory situations in your code -- no, you don't ever want to run out of memory, but it's always possible that you will. Best to find out what's going to happen when you're testing instead of when you're live.
You might want to read the comment that the parent of the parent post to yours was responding to. It's been modded down to oblivion as redundant, but it sets the framework in which to interpret the word "sharing". There can be good reasons that having somebody else use your work is not "sharing" it but "abusing" it.
"And since Fall, there's all there `gatherers` and `sharers` going around. I reckon that there's a lot more gathering than sharing."
RMS is not the first person to try to paint forced taking as sharing, you know, and I'm sure he won't be the last. It's an old rhetorical trick, to paint the extortion as redistribution for the good of the many at the expense of the greedy few. But there's a good name for the tactic: demagoguery.
Why not want my work remixed by anyone? Because I'm an artist, and my work may express other things than just its acoustic content. Suppose I'd made an acoustic collage of the environment of a particular event in memory of the event. I might not want you to remix it, even though I wanted it performed and heard.
Or maybe I don't want you to remix my work. If I want to get a sense of what you'd do with it, I can listen to what you did with other, similar, works and judge from that. That's how people pitch projects all the time. Maybe, having heard those works, I'll conclude that they're political polemic, and maybe I don't think I want you to exploit the impact that my work had to push your politics forward.
And notice something here: there's no mention of money in either of these cases. What these are is artistic uses of copyright to protect artistic integrity.
That would be really troubling. Are you sure? It used to be that most Symbian phones rebooted about once a week as a result of the CPM kicking in, which would make this self-propagating.
Why is software different from a road surface, or from police and fire protection? I payed for those, and I expect them to be available to me in the normal order of things. Companies exploit that fact for profit all the time. Why is code different?
The current system is basically a way to shame the vendors into acting proactively to fix a vulnerability, before an exploit is found in the wild. The hazards of it were debated long and hard by the IT community, but in the end it was decided that they had to force vendors to act.
Rescorla's paper is looking at the consequence of this "decision". He finds that the value of reporting vulnerabilities is likely to be nil. Given that the cost of publishing a vulnerability is clearly quite high, there's a clear question about whether a white hat should ever publicly report a vulnerability.
If his analysis stands, then we should reconsider the notion of public disclosure as a desirable endpoint. Perhaps the real cost of publishing patches is high enough that the value of those patches is exceeded by the cost of the exploits that they make possible.
In Google's case, no -- in fact, their IPO weakens shareholder control instead of strengthening it.
Google is going forward with a two-tiered stock-ownership plan. A small coterie of people (mostly Sergei, Larry, and Eric) will hold "class A" stock, and everybody else will hold "class B" stock. Each share of Class A stock has ten votes in shareholder's meeting; each share of class B stock has one. As a result, the Class A shares exercise 90% of the control over each shareholder decision, even though they make up only a very small fraction of the total share burden.
Translated into English, this setup means that the triumvirate controls the company absolutely, without any real shareholder oversight except their own. That's not necessarily bad, but it certainly isn't answerability.
Microsoft went public back in '86 for another reason, too. Employee stock options weren't worth much until the shares they represented could be traded. The company itself didn't benefit very much from the IPO -- it was ten years old, and highly profitable already -- but the employees did.
If you spend all your time around Linux boxes, it isn't a complete surprise that people with ovaries aren't terribly intrigued by you. In my experience, ovary-bearing individuals find Linux knowledge an interesting property for testicle-carriers to have, but not sufficient in itself to compel complementarity.
Whether or not you have the right people, you misunderstand the role of at least one of them. Blum, the program manager, would have been a front line worker, involved in the day-to-day work of building the interface.
A program manager at Microsoft does not manage people; he or she manages programs. Pointy-haired bosses don't propose features; PMs do -- but PMs have no authority to make a feature happen. They only have the authority to negotiate for one. The purpose is to have someone who does all the undefiable things which make a project work -- keep the devs from introducing cool and useless features that no one will ever use, make sure that test doesn't filibuster a project by requiring excessive SQA, work with usability to make sure the UI actually works, etc.
They sound totally useless - but they make the world go round. (Ob disc. My wife's a PM, so I'm a trifle biased.)
Graham himself acknowledges that Microsoft has a patent with a grant date of 1997 and covering his method, as well as all other Bayesian spam filtering methods on the market. (In fact, the classifier system that Microsoft patented shipped as a part of Outlook Express in 1997.)
Nonsense. The Microsoft KB you cite is specific to installation on top of 95/98/ME -- the Linux bug occurs on top of NT/2K/XP installs. Those are totally different situations.
Repeating a lie doesn't make it true, you know. This is a new issue, and it is Linux specific, and it's a total fsck up.
The standard attack returns into the stack, not the heap. Now, stacks are page-based (they need to be paged in and out along with the threads they represent.) On x86 architectures, discrete execute protection is offered for sections, but not for pages.
There are such attacks, but they are extremely subtle. Basically, instead of jumping to their own code on the stack, they write a different overflow which patches in a call to exec(). (Unix only, but on a Windows box, ShellExec will do just as well.) Hey presto, direct shell.
[I]sn't that a problem with the way that Windows executable are directly mapped to memory?
Nope, although it might seem that it would matter. (BTW: absolute mapping of critical OS entry points is enforced in most operating systems. Invoking the loader to relocate OS entry points breaks a lot of things...like the loader itself.)
In this case, though, that's a red herring. The jump in most buffer overruns is into the stack itself. The BO allows the attacker to overwrite the return pointer -- and the stack starts at a fixed address, so the attacker can compute the address to return to. Yes, you could move the stack's root around, but that only reduces the probability of success of a single instance of an attack. It doesn't prevent the attack in all cases. Most attackers are willing to try thousands of times to make an attack succeed if that's what is required.
(And, again, there's nothing special about Windows here. Linux and even OpenBSD make the same choice. As I said, the actual security benefit of moving the stack is very limited. The perf consequences, by contrast, are drastic.)
Slashdot Mirror
No, no, no. *BSD isn't dead, it's just dying -- it's official, Netcraft has been confirming it for about ten years. And PC Week has already told us that Apple is dead -- they're closely tied because Apple uses a BSD user space on top of a Mach kernel.
Posted on Mozilla on FreeBSD 5.2--a dead browser on a dead OS. Dead on.
Priceless! I was trying to figure out how the hell this could possibly work, until I hit the last paragraph.
Somebody mark the parent as the best troll of the year! (look at the name of the comment's submitter if you're wondering why I think it's a troll, not just a clever posting.)
You didn't read the article, did you? What you're describing as good management practice is exactly what he's advocating.
Anyone who manages developers knows that there stars on your team, the guys that you give the really gnarly problems to, the women who know the subtle details of a particular issue. You know who they are, rock-solid, dependable, hard-working. You trust them to turn out good work even when the world is going to hell around them.
Problem is, they need to be supported. It's easy to let a star go dark, trusting that what will come out the back will be great code. Most of the time, it will be. Management is about preventing the minority case when it's possible to do so -- and you do that by not letting the star be completely isolated.
Naturally, we'll exclude non-profit and free-software vendors because they couldn't possibly have the financial resources necessary to produce quality software.
So you're saying that Linux and its graphical work environments, upon the development of which large companies spend billions of dollars each year, don't have much money? Or are you claiming that a Linux 2.6 box running Gnome or KDE is a piece of shit? Inquiring minds want to know...
This has nothing to do with IIS 5 -- a compromised Apache server could be caused to do the same thing., at least as easily.
The problem with your "new" way of doing business is (1) it isn't new and (2) it doesn't work now any more than it ever did.
Having an itch to scratch does nothing for the guy who's gambled his way under a mountain of debt and who goes from being completely trustworthy to being willing to steal from his best friend, to say nothing of his employer. That's not a hypothetical case; I'm thinking of a particular person with whom I worked about a decade ago. (Luckily for me, I wasn't one of his friends, so he didn't rip me off.) People change, and someone who's completely trustworthy today may not be five years from now. Worse, people are not always what they seem, and only observation over a very long term reveals them for what they are.
Who watches the watchers? I don't know -- but they need to be there in any org which handles things of value.
No -- it's good engineering. If you know that something can fail in ordinary usage, you drive it to collapse during testing to determine whether you can recover, and, if so, how to do that. It's like randomly triggering out of memory situations in your code -- no, you don't ever want to run out of memory, but it's always possible that you will. Best to find out what's going to happen when you're testing instead of when you're live.
You might want to read the comment that the parent of the parent post to yours was responding to. It's been modded down to oblivion as redundant, but it sets the framework in which to interpret the word "sharing". There can be good reasons that having somebody else use your work is not "sharing" it but "abusing" it.
"And since Fall, there's all there `gatherers` and `sharers` going around. I reckon that there's a lot more gathering than sharing."
RMS is not the first person to try to paint forced taking as sharing, you know, and I'm sure he won't be the last. It's an old rhetorical trick, to paint the extortion as redistribution for the good of the many at the expense of the greedy few. But there's a good name for the tactic: demagoguery.
Why not want my work remixed by anyone? Because I'm an artist, and my work may express other things than just its acoustic content. Suppose I'd made an acoustic collage of the environment of a particular event in memory of the event. I might not want you to remix it, even though I wanted it performed and heard.
Or maybe I don't want you to remix my work. If I want to get a sense of what you'd do with it, I can listen to what you did with other, similar, works and judge from that. That's how people pitch projects all the time. Maybe, having heard those works, I'll conclude that they're political polemic, and maybe I don't think I want you to exploit the impact that my work had to push your politics forward.
And notice something here: there's no mention of money in either of these cases. What these are is artistic uses of copyright to protect artistic integrity.
That would be really troubling. Are you sure? It used to be that most Symbian phones rebooted about once a week as a result of the CPM kicking in, which would make this self-propagating.
Why is software different from a road surface, or from police and fire protection? I payed for those, and I expect them to be available to me in the normal order of things. Companies exploit that fact for profit all the time. Why is code different?
If his analysis stands, then we should reconsider the notion of public disclosure as a desirable endpoint. Perhaps the real cost of publishing patches is high enough that the value of those patches is exceeded by the cost of the exploits that they make possible.
In Google's case, no -- in fact, their IPO weakens shareholder control instead of strengthening it.
Google is going forward with a two-tiered stock-ownership plan. A small coterie of people (mostly Sergei, Larry, and Eric) will hold "class A" stock, and everybody else will hold "class B" stock. Each share of Class A stock has ten votes in shareholder's meeting; each share of class B stock has one. As a result, the Class A shares exercise 90% of the control over each shareholder decision, even though they make up only a very small fraction of the total share burden.
Translated into English, this setup means that the triumvirate controls the company absolutely, without any real shareholder oversight except their own. That's not necessarily bad, but it certainly isn't answerability.
Microsoft went public back in '86 for another reason, too. Employee stock options weren't worth much until the shares they represented could be traded. The company itself didn't benefit very much from the IPO -- it was ten years old, and highly profitable already -- but the employees did.
Whether or not you have the right people, you misunderstand the role of at least one of them. Blum, the program manager, would have been a front line worker, involved in the day-to-day work of building the interface.
A program manager at Microsoft does not manage people; he or she manages programs. Pointy-haired bosses don't propose features; PMs do -- but PMs have no authority to make a feature happen. They only have the authority to negotiate for one. The purpose is to have someone who does all the undefiable things which make a project work -- keep the devs from introducing cool and useless features that no one will ever use, make sure that test doesn't filibuster a project by requiring excessive SQA, work with usability to make sure the UI actually works, etc.
They sound totally useless - but they make the world go round. (Ob disc. My wife's a PM, so I'm a trifle biased.)
Graham himself acknowledges that Microsoft has a patent with a grant date of 1997 and covering his method, as well as all other Bayesian spam filtering methods on the market. (In fact, the classifier system that Microsoft patented shipped as a part of Outlook Express in 1997.)
This limits the NAI patent considerably.
Nope -- there's no contract in a gift. A contract requires an exchange of value; a promise of a gift is never a contract.
Nonsense. The Microsoft KB you cite is specific to installation on top of 95/98/ME -- the Linux bug occurs on top of NT/2K/XP installs. Those are totally different situations.
Repeating a lie doesn't make it true, you know. This is a new issue, and it is Linux specific, and it's a total fsck up.
The standard attack returns into the stack, not the heap. Now, stacks are page-based (they need to be paged in and out along with the threads they represent.) On x86 architectures, discrete execute protection is offered for sections, but not for pages.
There are such attacks, but they are extremely subtle. Basically, instead of jumping to their own code on the stack, they write a different overflow which patches in a call to exec(). (Unix only, but on a Windows box, ShellExec will do just as well.) Hey presto, direct shell.
In this case, though, that's a red herring. The jump in most buffer overruns is into the stack itself. The BO allows the attacker to overwrite the return pointer -- and the stack starts at a fixed address, so the attacker can compute the address to return to. Yes, you could move the stack's root around, but that only reduces the probability of success of a single instance of an attack. It doesn't prevent the attack in all cases. Most attackers are willing to try thousands of times to make an attack succeed if that's what is required.
(And, again, there's nothing special about Windows here. Linux and even OpenBSD make the same choice. As I said, the actual security benefit of moving the stack is very limited. The perf consequences, by contrast, are drastic.)