I have to think that they just -increased- the odds of draconian legislation being passed to help contain outbreaks just like this.
You can't contain these sorts of attacks using legislation or the current web infrastructure. It's just pissing in the wind, and you're only going to get wet. Solving DDoS attacks requires a switch to content-centric networking, or something like it.
Apple is approaching a similar inflection point, and their need to innovate goes well beyond a slightly larger, slightly faster iPhone.
What evidence do you have that Apple is approaching this "inflection point"? In fact, I don't see any parallels between Apple and Kodak at all, that don't equally apply to every other successful company, like Microsoft. Kodak stagnated over a decade ago, and Apple innovation hasn't decreased in pace. Why caution people about Apple specifically and not Microsoft and others?
However hard you write your web app, if its running anything important, it WILL get hacked. there's nothing on this planet that cannot get hacked if it is a software.
I disagree. You can mitigate many risks by using a proper language (memory safe) or web framework which handles user input and session/CSRF protection. You can mitigate all risks by properly using a theorem prover to guarantee your implementation has all the important properties to guarantee safety.
The vulnerabilities web applications present are in fact very different. You won't find CSRF or clickjacking attacks in many other domains. There are also many DoS opportunities.
However, if he honestly doesn't understand why the abuse of children should be illegal then hes a sick individual.
I highlighted your bait-and-switch so you can see the problem with your comment. Of course Stalman is opposed to child abuse, he's just not sure that pedophilia necessarily implies abuse. Below a certain age or mental maturity, it almost certainly does, but there's a lot of wiggle room in the teen years where it's not so clear.
Or maybe you are just indulging yourself in an older man's fantasy of rape and seduction, with no real understanding of what the experience would have been like for a twelve year old boy.
Entirely possible. But pedophilia leaves no room for determination of actual harm under the law. Regardless of the circumstances and the outcome, it's a life long punishment.
this should scare the living daylights out of us and not be some kind a source for celebration.
When their position is in the interests of all citizens, it is cause for celebration. When their position is not in our interests, then it's cause for protest. There's no need to always consider corporations as the enemy. Sometimes they're on the right side.
Apple and Boxee are on the right path to convergence. You should be able to view videos and pictures from your phone or cameras on your TV, you should be able to watch your online/offline content whenever you like, you should be able to share content you like with friends and family, and this should all be relatively painless. There's still a lot of room for improvement.
Asking if TV really requires improvement is like asking whether computers really need improvement. After all, computers already compute right? What more could we possibly need them to do?
Firefox's new versioning scheme wouldn't be a problem at all if they had a stable API that didn't break a user's extensions on each update. Chrome has managed this, and they follow the same fast-paced version upgrades that Firefox is now doing. Chrome is just doing it right.
To be fair, I think Firefox has improved this quite a bit, because I've experience fewer breaks during upgrades recently.
Here are a series of questions which will determine which of us is deluding themselves:
1. is every program you write flawless and secure? 2. do you agree that coarse-grained protection boundaries result in more vulnerable, less robust systems than systems constructed with fine-grained protection boundaries? 3. do you agree that it's trivial to remove protection boundaries without changing the communication interface between components, perhaps with dynamic link-time configuration options, but it's impossible to add or infer the desired protection boundaries at any stage of compilation, linking or deployment? 4. do microkernels encourage systems with finer-grained protection boundaries? 5. do monolithic kernels encourage systems with coarser-grained protection boundaries? 6. can microkernel systems with full protection boundaries, or partial protection boundaries removed match or exceed the performance of monolithic systems?
There is irrefutable evidence implying that the answer to all of these questions is "yes", so all of your objections are plain rubbish, and your attempts to deflect from these basic facts and their consequences is transparent.
Your only legitimate complaint against microkernels is the paucity of tooling to support decomposed program construction. It's gotten better with IDLs, but traditional systems programming languages (C/C++) are invariably designed around a single-address space linking model that requires outside tooling to reason about protection boundaries. But without more attention, this tooling will never improve.
Even without better tooling, microkernels still result in safer, more secure, more robust systems. The L4 microkernel is the only general purpose OS kernel, period, to achieve EAL-7 assurance. You will never have a monolithic kernel achieve that level of assurance, unless you replace the hardware protection exploited by microkernels with some other means of protection (like proof-carrying code).
So peel as many apples as you like, just know that your singing is simply drowning out the facts that are crying for your attention.
There's lots of flack over the binary log format. Syslog entries are pretty clearly delineated, so why not just store the hashes for each entry separately from the text-based log file? You can then just provide a tool to check the integrity, without losing any of the advantages of the current log format.
I'm amazed you still don't understand, nor don't seem to be able to distinguish a circular reasoning from a legitimate argument.
I'll break it down to Brawndo-speak for you: monolithic kernel is to microkernel, as assembly is to Ada. Simple as that. Everything expressible in assembly can be expressed in Ada, but plenty of properties expressible in Ada and ensured by the compiler, cannot be expressed in assembly.
If you don't understand the parallels, your CS education has failed you.
Indeed. AMD would have had a winner if they had just produced 12 core 32nm Phenom II chip. Would have had the same TDP as Bulldozer except higher IPC, 4 more cores, would have come out a year earlier and kept the pressure on Intel.
Intel did the same with the Q6600 the first "quad core", and many people were quite happy with it. AMD took a huge gamble, and it's not looking good right now.
So if one of your drivers crashes in a microkernel-based system, you can just "reboot" the driver rather than the whole machine?
Assuming the hardware isn't buggy and thus supports being reset, then yes. There is a lot of ongoing work in this domain, under headings like "self-healing systems".
In short, you more or less ignored my example and went with yet another theoretical explanation why micro-kernel is the kernel design to rule them all.
Then you didn't understand my post. Microkernels lead to better structured programs because it allows you to decompose a program into structured abstract modules. Each module is an individual failure domain that is enforced by the kernel. A kernel is exactly analogous to a language runtime which enforces safety between abstract modules (objects). Languages that are safe are strictly more expressive than languages that are unsafe. This is simply a fact.
As for a monolithic design, you were essentially asserting you can't achieve your design on a microkernel, and I countered with the point that any program you can express on a monolithic design, you can express on a microkernel design except express programs that crash the whole system, which are a useless subset of programs. If you actually had strong evidence that a decomposed design was actually the bottleneck, you can break down protection barriers to achieve the performance needed with no change to the programs, but you can't do the reverse to achieve more safety in a monolithic design. This too is a fact.
And no, a decomposed design that has had some of its protection boundaries broken down doesn't necessarily require a full reboot, because the decomposed design means you can restart the whole subsystem without restarting the whole system.
Finally, your comment about the kernels being well structured and documented and reusable is completely irrelevant. This has nothing to do with the kernel, we're talking about the components of your program. Microkernels make it feasible to decompose a design, which makes recovery and other properties feasible. Whether recovery is achievable is domain-specific and subject to the skill of the developer. Either way, you're still better off on microkernels because at least they give you the tools to make it possible.
As for evidence, there have been plenty of papers achieving high bandwidth, low latency networking on microkernels like EROS and L4. It's certainly challenging to design them in separate failure domains with recovery, but it's not impossible. Your posts contain as little evidence as mine do, so I don't exactly feel the need to do your research for you.
You're making an awful lot of assumptions. Firstly, there's nothing preventing you from having a monolithic networking stack on top of a microkernel. Consider that a Xen hypervisor is a microkernel with Linux running as a user process.
The idea here is the same: you can choose to break down protection domains if you want/have to with microkernels, but you can't reasonably decompose a program into multiple protection domains with monolithic kernels because the latter don't have the well-structured, fast IPC of the former which makes the decomposition feasible to begin with.
So no, you don't have to place the DPI and network device into separate address spaces, but the more protection domains you have, the more reusable your components are, the more structured your system is, and thus the more understandable and recoverable it will be. And if the hardware can get into an unrecoverable state, well no software except verification can help you with that.
Your whole argument basically reduces to: decomposed, well structured, reusable software components are harder to design than ad-hoc designs with no constraints on structure or reuse. I don't think anyone ever expected the contrary to be true. The extent to which you care about these issues is the extent to which you will decompose programs on a microkernel. It's not all-or-nothing.
If your video driver dies, something has to recover its state when you restart it, which is far from a trivial task.
Recovering state is indeed a difficult problem. State management has been made more difficult because it's easy or tempting to place state in places where it results in many DoS vulnerabilities (like putting state in the kernel or the display server). See the EROS window system design for how this is was reasonably addressed in UI systems.
Personally, I don't think we always have to recover everything. Not killing the whole system is still an improvement, because at least you can delegate to the user how to proceed, even if that delegation is: what do you want me to do with all these GUI programs whose UI state is now invalid? Once you're able to get into that position, you can at least ask yourself what can be done. An obvious answer would be to define a standard signal which attempts to save the current program state for future recovery. Many programs already do this, ie. saving a temporary/scratch file in case the program crashes, and this is just a natural extension of that.
Has it occurred to you that some people don't share your view that everyone should be forced to use their code in a way consistent with Stallman's ideologies?
That's irrelevant to his point of software dominance via natural selection. His point was simply that the GPL is a better survivor given software market dynamics and the human mindset, and that's why it's thrived more than BSD. Nobody cares what license you choose, but it's undeniable that the GPL is more successful.
Truth be told, if one of your drivers crashes, there's little hope of maintaining a useful system and you'll likely want to reboot anyway.
Except this isn't true of microkernel systems like Minix. And this is the point: microkernels enforce protection boundaries between components so failure and recovery become feasible. That simply isn't possible in a monolithic kernel without resorting to proof-carrying code of some sort.
The motherboard is always the point of failure in my experience. I've never wrecked a CPU. I suppose it's possible with overheating, but that's pretty much it.
Seriously. Ditch the old computer ports and put in some composite and component video ports. Every motherboard for "media centers" lack these basic video connectors.
Slashdot Mirror
You can't contain these sorts of attacks using legislation or the current web infrastructure. It's just pissing in the wind, and you're only going to get wet. Solving DDoS attacks requires a switch to content-centric networking, or something like it.
What evidence do you have that Apple is approaching this "inflection point"? In fact, I don't see any parallels between Apple and Kodak at all, that don't equally apply to every other successful company, like Microsoft. Kodak stagnated over a decade ago, and Apple innovation hasn't decreased in pace. Why caution people about Apple specifically and not Microsoft and others?
The more this escalates, the better the chance we'll get some meaningful reform.
I disagree. You can mitigate many risks by using a proper language (memory safe) or web framework which handles user input and session/CSRF protection. You can mitigate all risks by properly using a theorem prover to guarantee your implementation has all the important properties to guarantee safety.
The vulnerabilities web applications present are in fact very different. You won't find CSRF or clickjacking attacks in many other domains. There are also many DoS opportunities.
I highlighted your bait-and-switch so you can see the problem with your comment. Of course Stalman is opposed to child abuse, he's just not sure that pedophilia necessarily implies abuse. Below a certain age or mental maturity, it almost certainly does, but there's a lot of wiggle room in the teen years where it's not so clear.
Entirely possible. But pedophilia leaves no room for determination of actual harm under the law. Regardless of the circumstances and the outcome, it's a life long punishment.
Maybe free software wouldn't have helped, but a free software CULTURE would have significant influence had it spread more widely.
this should scare the living daylights out of us and not be some kind a source for celebration.
When their position is in the interests of all citizens, it is cause for celebration. When their position is not in our interests, then it's cause for protest. There's no need to always consider corporations as the enemy. Sometimes they're on the right side.
Using their private property to stage a protest is not electioneering.
This is how the handset market was already structured. Google has nothing to do with this.
Apple and Boxee are on the right path to convergence. You should be able to view videos and pictures from your phone or cameras on your TV, you should be able to watch your online/offline content whenever you like, you should be able to share content you like with friends and family, and this should all be relatively painless. There's still a lot of room for improvement.
Asking if TV really requires improvement is like asking whether computers really need improvement. After all, computers already compute right? What more could we possibly need them to do?
Firefox's new versioning scheme wouldn't be a problem at all if they had a stable API that didn't break a user's extensions on each update. Chrome has managed this, and they follow the same fast-paced version upgrades that Firefox is now doing. Chrome is just doing it right.
To be fair, I think Firefox has improved this quite a bit, because I've experience fewer breaks during upgrades recently.
Here are a series of questions which will determine which of us is deluding themselves:
1. is every program you write flawless and secure?
2. do you agree that coarse-grained protection boundaries result in more vulnerable, less robust systems than systems constructed with fine-grained protection boundaries?
3. do you agree that it's trivial to remove protection boundaries without changing the communication interface between components, perhaps with dynamic link-time configuration options, but it's impossible to add or infer the desired protection boundaries at any stage of compilation, linking or deployment?
4. do microkernels encourage systems with finer-grained protection boundaries?
5. do monolithic kernels encourage systems with coarser-grained protection boundaries?
6. can microkernel systems with full protection boundaries, or partial protection boundaries removed match or exceed the performance of monolithic systems?
There is irrefutable evidence implying that the answer to all of these questions is "yes", so all of your objections are plain rubbish, and your attempts to deflect from these basic facts and their consequences is transparent.
Your only legitimate complaint against microkernels is the paucity of tooling to support decomposed program construction. It's gotten better with IDLs, but traditional systems programming languages (C/C++) are invariably designed around a single-address space linking model that requires outside tooling to reason about protection boundaries. But without more attention, this tooling will never improve.
Even without better tooling, microkernels still result in safer, more secure, more robust systems. The L4 microkernel is the only general purpose OS kernel, period, to achieve EAL-7 assurance. You will never have a monolithic kernel achieve that level of assurance, unless you replace the hardware protection exploited by microkernels with some other means of protection (like proof-carrying code).
So peel as many apples as you like, just know that your singing is simply drowning out the facts that are crying for your attention.
There's lots of flack over the binary log format. Syslog entries are pretty clearly delineated, so why not just store the hashes for each entry separately from the text-based log file? You can then just provide a tool to check the integrity, without losing any of the advantages of the current log format.
I'm amazed you still don't understand, nor don't seem to be able to distinguish a circular reasoning from a legitimate argument.
I'll break it down to Brawndo-speak for you: monolithic kernel is to microkernel, as assembly is to Ada. Simple as that. Everything expressible in assembly can be expressed in Ada, but plenty of properties expressible in Ada and ensured by the compiler, cannot be expressed in assembly.
If you don't understand the parallels, your CS education has failed you.
Indeed. AMD would have had a winner if they had just produced 12 core 32nm Phenom II chip. Would have had the same TDP as Bulldozer except higher IPC, 4 more cores, would have come out a year earlier and kept the pressure on Intel.
Intel did the same with the Q6600 the first "quad core", and many people were quite happy with it. AMD took a huge gamble, and it's not looking good right now.
Assuming the hardware isn't buggy and thus supports being reset, then yes. There is a lot of ongoing work in this domain, under headings like "self-healing systems".
Then you didn't understand my post. Microkernels lead to better structured programs because it allows you to decompose a program into structured abstract modules. Each module is an individual failure domain that is enforced by the kernel. A kernel is exactly analogous to a language runtime which enforces safety between abstract modules (objects). Languages that are safe are strictly more expressive than languages that are unsafe. This is simply a fact.
As for a monolithic design, you were essentially asserting you can't achieve your design on a microkernel, and I countered with the point that any program you can express on a monolithic design, you can express on a microkernel design except express programs that crash the whole system, which are a useless subset of programs. If you actually had strong evidence that a decomposed design was actually the bottleneck, you can break down protection barriers to achieve the performance needed with no change to the programs, but you can't do the reverse to achieve more safety in a monolithic design. This too is a fact.
And no, a decomposed design that has had some of its protection boundaries broken down doesn't necessarily require a full reboot, because the decomposed design means you can restart the whole subsystem without restarting the whole system.
Finally, your comment about the kernels being well structured and documented and reusable is completely irrelevant. This has nothing to do with the kernel, we're talking about the components of your program. Microkernels make it feasible to decompose a design, which makes recovery and other properties feasible. Whether recovery is achievable is domain-specific and subject to the skill of the developer. Either way, you're still better off on microkernels because at least they give you the tools to make it possible.
As for evidence, there have been plenty of papers achieving high bandwidth, low latency networking on microkernels like EROS and L4. It's certainly challenging to design them in separate failure domains with recovery, but it's not impossible. Your posts contain as little evidence as mine do, so I don't exactly feel the need to do your research for you.
You're making an awful lot of assumptions. Firstly, there's nothing preventing you from having a monolithic networking stack on top of a microkernel. Consider that a Xen hypervisor is a microkernel with Linux running as a user process.
The idea here is the same: you can choose to break down protection domains if you want/have to with microkernels, but you can't reasonably decompose a program into multiple protection domains with monolithic kernels because the latter don't have the well-structured, fast IPC of the former which makes the decomposition feasible to begin with.
So no, you don't have to place the DPI and network device into separate address spaces, but the more protection domains you have, the more reusable your components are, the more structured your system is, and thus the more understandable and recoverable it will be. And if the hardware can get into an unrecoverable state, well no software except verification can help you with that.
Your whole argument basically reduces to: decomposed, well structured, reusable software components are harder to design than ad-hoc designs with no constraints on structure or reuse. I don't think anyone ever expected the contrary to be true. The extent to which you care about these issues is the extent to which you will decompose programs on a microkernel. It's not all-or-nothing.
Recovering state is indeed a difficult problem. State management has been made more difficult because it's easy or tempting to place state in places where it results in many DoS vulnerabilities (like putting state in the kernel or the display server). See the EROS window system design for how this is was reasonably addressed in UI systems.
Personally, I don't think we always have to recover everything. Not killing the whole system is still an improvement, because at least you can delegate to the user how to proceed, even if that delegation is: what do you want me to do with all these GUI programs whose UI state is now invalid? Once you're able to get into that position, you can at least ask yourself what can be done. An obvious answer would be to define a standard signal which attempts to save the current program state for future recovery. Many programs already do this, ie. saving a temporary/scratch file in case the program crashes, and this is just a natural extension of that.
That's irrelevant to his point of software dominance via natural selection. His point was simply that the GPL is a better survivor given software market dynamics and the human mindset, and that's why it's thrived more than BSD. Nobody cares what license you choose, but it's undeniable that the GPL is more successful.
Except this isn't true of microkernel systems like Minix. And this is the point: microkernels enforce protection boundaries between components so failure and recovery become feasible. That simply isn't possible in a monolithic kernel without resorting to proof-carrying code of some sort.
The motherboard is always the point of failure in my experience. I've never wrecked a CPU. I suppose it's possible with overheating, but that's pretty much it.
Seriously. Ditch the old computer ports and put in some composite and component video ports. Every motherboard for "media centers" lack these basic video connectors.