Right back at ya (History:Mac OS X is based on the Mach kernel)... I'll have to do some reading on this, but the uni library is closed. You're on the money re marketing.
I'm not sure what you mean by this.
Bear with me, I'd rather discuss this in a bar than via text. In a normal die more than 90% of the surface is lost on metal interconnects, this is for 1 core. Putting multiple cores next to each other means you have to compromise on core interconnecting. This is normally limited to neighbouring cores (although they're working towards system in package and the likes via optical interconnects). I have two objections with a comparison of multicores with SMP and cluster computing:
- in cluster computing, communication between CPUs slows the system down - so you avoid it, minimize the packets or reduce the amount of packets by stretching the amount of computation in one job per CPU or by applying smart caching that reduce sending results back and forth. So: to avoid idle waiting they normally make sure that the queue is stuffed with commands during the wait. But: clusters and SMPs have a backdoor: you can interconnect CPUs arbitrarily (like here: too much traffic? make an extra bridge or lane). In multi-cores, this is not an option, it's like traffic intersections: you can't just build a bridge or tunnel everywhere, everything is planar.
Secondly, you're restricted with what a core can do: you can't just stuff the queue as deep as with SMP and clusters. So you get these extremely complex scheduling and reservation formalisms - not to mention context switching.
- secondly: the clusters I worked with are built case by case, you can scale & design hardware infrastructure according to the jobs you're planning in the next 2 years or so. In multicores you have the opposite problem: designing an OS which must handle each quantity of cores optimally for any given piece of code. When I wrote doesn't know the exact amount of cores there will be on the die, this is the future: cpus are going to be sold with variable number of cores, the defect on a die will be isolated by disabling the core where it's located. This makes yield skyrocket per wafer and allows relaxation on defect density per wafer (cheaper wafers). So, an OS will have to figure out how many cores there are, where the holes are (disabled cores) and make a plan to manage this optimally. This is the kind of job a microkernel is meant to do: local arbitration and communication, per core. Like the internet: design it so it flows around defects. You're calling it a hypervisor, but why on earth would you design an OS which consists of both a micro-kernel-ish part (hypervisor) and an monolythic part (what you mention that runs on it) when you can do the same with a microkernel.
Regarding Linux: Linux isn't plagued by anything, but truth be told: its architecture hasn't changed a lot in 15 years. There will be a lot of opposition to a redesign and most of the anti-arguments will be irrational - but they're welcome to surprise me on that;)
Sorry for flooding you with text - I actually hate explaining things by typing.
Well, saying MacOSX is based on Mach is like saying Linux is based on Minix. They are related, but that is as far as the similarity goes.
Well, you may want to mail the people at Apple and ask them to stop all this disinformation.
Putting grub2 as an example that microkernels will never work is something I don't get. What about Cosmos ? A long way ahead but I don't see any problems on their horizon. Sorry, I'm strongly opposed to these fat monolyths, but that's probably part of the education.
not to mention the cost of building a new system from scratch.
I completely agree on this front, but the reason is not that it's not worth it. The reason is that there is no formal working model. In 2011 Intel is releasing an 80-core and we're currently seeing a trend to push computational efforts to the GPU. Trust me: you're not going to pull of a monolythic OS that doesn't know the exact amount of cores there will be on the die - or how many GPUs there are on board - and that hardware is where we're going.
All major CPU Co.s are pushing for these kind of dies because it increases the yield on the wafer in a tremendous way. The first appearance was Cell, which had an SPU turned off, but this was to increase the yield and offer a uniform product, not because the SPU had a defect. The trend is going towards production of dies which have as many cores as the amount of defects allow, every die can then be sold - but there won't be a homogenous product (the amount of co-processors won't be 16,32,64 but 40-ish or 70-ish). Monolythic kernels are lost on that, too much traffic is wasted in getting everything in sync. Compare it to the internet nodes: decentralisation means flexibility.
Hey dude, I really really like the fact that you took the time to comment (elaborately) on my post, but I typed moving towards, not owning and selling. OSX is based on Mach, MS's Singularity microkernel (and to some extent MinWin) is also a move in that direction. That's pretty much the whole PC market - which I bet nobody agrees with me here. Moving GPU hardware management to the kernel is a step in the opposite direction.
security without obscurity implies that you're willing to sacrifice temporary loss of security whenever a backdoor or exploit is discovered. The security we (as a geek community) are dealing with is not the same as government security. The first generally deals with security of infrastructure that houses the information, the second deals with the security of information.
Whenever an infrastructure security is compromised, we can restore the information from backups after the security hole has been fixed. Whenever information security is compromised it pretty much looses its reason to exist.
Why exactly should I be supporting Mozilla as a foundation instead of Mozilla as a browser ? The/. crowd normally embraces a corporation which supports (in this case pushes) FOSS. Foundations which rely on generosity are more sensitive to this kind of trends, I think time will show they're transitional in nature.
And as to google's possible future issues with add-blockers: hey people, it's open source - you can fork it or whatever... it's the kind of answer I normally get when criticizing FOSS before I'm flamebait-tagged.
Microsoft's source code is available for government applications (Government Security Programme), an NDA doesn't make any difference for this topic - it's just paperwork.
But this is besides the point. What I'm hinting at: does it matter that the source is open, given that nobody can inspect that volume in a reasonable time with a reasonable accuracy.
My question does not address open/closed source but the fact that Linux has been open to "hostile entities" since day 1.
And to answer your question directly: Linux source has grown beyond comprehension and analysis for sleeping trojans. You're under the impression that this kind of code is located in a single isolated spot in the source. It's not.
Given the fact that Linux is built mostly by anonymous contributors, kept on servers which are hacked every now and then (Fedora Signing Key Server Hacked in August - Red Hat Infrastructure Servers recently Hacked, Cracked & Compromised) what guarantee is there that Linux - God's gift to nerds - doesn't contain sleeping trojans written by Russians or Chinese ?
Do the math: what would it cost to accomplish this? I think something like less than 10.000$ (including paycheck, laptop and broadband connection).
Don't see why... submarines are renowned for not being connected to the internet. Advantages of Linux over Windows on the front of network security is lost here. Secondly, Windows source isn't open to the Russians or Chinese - can the Linux community guarantee there aren't a few trojans in Linux that date back a few years?
Apply Occam's razor and imagine what's easier to infiltrate: an American-based corporation or an open community that's mainly composed of anonymous contributors with handles like "uber1337" ? AFAIK British defence answered that question.
Slashdot Mirror
same here.
Try this [wikipedia.org] instead.
... I'll have to do some reading on this, but the uni library is closed. You're on the money re marketing.
;)
Right back at ya (History:Mac OS X is based on the Mach kernel)
I'm not sure what you mean by this.
Bear with me, I'd rather discuss this in a bar than via text.
In a normal die more than 90% of the surface is lost on metal interconnects, this is for 1 core. Putting multiple cores next to each other means you have to compromise on core interconnecting. This is normally limited to neighbouring cores (although they're working towards system in package and the likes via optical interconnects). I have two objections with a comparison of multicores with SMP and cluster computing:
- in cluster computing, communication between CPUs slows the system down - so you avoid it, minimize the packets or reduce the amount of packets by stretching the amount of computation in one job per CPU or by applying smart caching that reduce sending results back and forth. So: to avoid idle waiting they normally make sure that the queue is stuffed with commands during the wait. But: clusters and SMPs have a backdoor: you can interconnect CPUs arbitrarily (like here: too much traffic? make an extra bridge or lane).
In multi-cores, this is not an option, it's like traffic intersections: you can't just build a bridge or tunnel everywhere, everything is planar.
Secondly, you're restricted with what a core can do: you can't just stuff the queue as deep as with SMP and clusters. So you get these extremely complex scheduling and reservation formalisms - not to mention context switching.
- secondly: the clusters I worked with are built case by case, you can scale & design hardware infrastructure according to the jobs you're planning in the next 2 years or so. In multicores you have the opposite problem: designing an OS which must handle each quantity of cores optimally for any given piece of code.
When I wrote doesn't know the exact amount of cores there will be on the die, this is the future: cpus are going to be sold with variable number of cores, the defect on a die will be isolated by disabling the core where it's located. This makes yield skyrocket per wafer and allows relaxation on defect density per wafer (cheaper wafers). So, an OS will have to figure out how many cores there are, where the holes are (disabled cores) and make a plan to manage this optimally. This is the kind of job a microkernel is meant to do: local arbitration and communication, per core. Like the internet: design it so it flows around defects. You're calling it a hypervisor, but why on earth would you design an OS which consists of both a micro-kernel-ish part (hypervisor) and an monolythic part (what you mention that runs on it) when you can do the same with a microkernel.
Regarding Linux: Linux isn't plagued by anything, but truth be told: its architecture hasn't changed a lot in 15 years. There will be a lot of opposition to a redesign and most of the anti-arguments will be irrational - but they're welcome to surprise me on that
Sorry for flooding you with text - I actually hate explaining things by typing.
Well, saying MacOSX is based on Mach is like saying Linux is based on Minix. They are related, but that is as far as the similarity goes.
Well, you may want to mail the people at Apple and ask them to stop all this disinformation.
Putting grub2 as an example that microkernels will never work is something I don't get. What about Cosmos ? A long way ahead but I don't see any problems on their horizon. Sorry, I'm strongly opposed to these fat monolyths, but that's probably part of the education.
not to mention the cost of building a new system from scratch.
I completely agree on this front, but the reason is not that it's not worth it. The reason is that there is no formal working model. In 2011 Intel is releasing an 80-core and we're currently seeing a trend to push computational efforts to the GPU. Trust me: you're not going to pull of a monolythic OS that doesn't know the exact amount of cores there will be on the die - or how many GPUs there are on board - and that hardware is where we're going.
All major CPU Co.s are pushing for these kind of dies because it increases the yield on the wafer in a tremendous way. The first appearance was Cell, which had an SPU turned off, but this was to increase the yield and offer a uniform product, not because the SPU had a defect. The trend is going towards production of dies which have as many cores as the amount of defects allow, every die can then be sold - but there won't be a homogenous product (the amount of co-processors won't be 16,32,64 but 40-ish or 70-ish). Monolythic kernels are lost on that, too much traffic is wasted in getting everything in sync. Compare it to the internet nodes: decentralisation means flexibility.
Hey dude, I really really like the fact that you took the time to comment (elaborately) on my post, but I typed moving towards, not owning and selling. OSX is based on Mach, MS's Singularity microkernel (and to some extent MinWin) is also a move in that direction. That's pretty much the whole PC market - which I bet nobody agrees with me here. Moving GPU hardware management to the kernel is a step in the opposite direction.
what if they pull the ethernet cable or disable the wireless ? You just get a warning, but the document is visible.
I think you're right - that it's the frequency of the event which throws sand in my face. Still, don't get why this is worth the attention.
So after a decade of mocking BSOD's on windows it's now a sought after feature in Linux? Sorry, don't get it.
As good as the whole OS world is moving towards microkernels and Linux is pushing graphics to the kernel ?
security without obscurity implies that you're willing to sacrifice temporary loss of security whenever a backdoor or exploit is discovered. The security we (as a geek community) are dealing with is not the same as government security. The first generally deals with security of infrastructure that houses the information, the second deals with the security of information.
Whenever an infrastructure security is compromised, we can restore the information from backups after the security hole has been fixed. Whenever information security is compromised it pretty much looses its reason to exist.
an outdated console interaction doesn't mean it's built for grannies
no toolbar stuff, no harmfull websites as google blocks it, no crappy add-ons
Do you think that Microsoft would open up their code to the British Navy?
Yes, it's an agreement called the "Government Security Program", started in 2003.
Well put.
/. crowd normally embraces a corporation which supports (in this case pushes) FOSS. Foundations which rely on generosity are more sensitive to this kind of trends, I think time will show they're transitional in nature.
... it's the kind of answer I normally get when criticizing FOSS before I'm flamebait-tagged.
Why exactly should I be supporting Mozilla as a foundation instead of Mozilla as a browser ? The
And as to google's possible future issues with add-blockers: hey people, it's open source - you can fork it or whatever
I wouldn't call it disgust, but yes, it can be interpreted as such.
Cheers, but the point has been debunked pretty good.
Thanks for elaborating.
Thanks for biting.
Have these kind of fragmented trojans ever been recorded/detected in Linux, BTW ?
Microsoft's source code is available for government applications (Government Security Programme), an NDA doesn't make any difference for this topic - it's just paperwork.
But this is besides the point. What I'm hinting at: does it matter that the source is open, given that nobody can inspect that volume in a reasonable time with a reasonable accuracy.
My question does not address open/closed source but the fact that Linux has been open to "hostile entities" since day 1.
And to answer your question directly: Linux source has grown beyond comprehension and analysis for sleeping trojans. You're under the impression that this kind of code is located in a single isolated spot in the source. It's not.
before flamebait-tagging me, please read.
Given the fact that Linux is built mostly by anonymous contributors, kept on servers which are hacked every now and then (Fedora Signing Key Server Hacked in August - Red Hat Infrastructure Servers recently Hacked, Cracked & Compromised) what guarantee is there that Linux - God's gift to nerds - doesn't contain sleeping trojans written by Russians or Chinese ?
Do the math: what would it cost to accomplish this? I think something like less than 10.000$ (including paycheck, laptop and broadband connection).
Don't see why ... submarines are renowned for not being connected to the internet. Advantages of Linux over Windows on the front of network security is lost here. Secondly, Windows source isn't open to the Russians or Chinese - can the Linux community guarantee there aren't a few trojans in Linux that date back a few years?
Apply Occam's razor and imagine what's easier to infiltrate: an American-based corporation or an open community that's mainly composed of anonymous contributors with handles like "uber1337" ? AFAIK British defence answered that question.
Damn it! got fingered again.
yes, Windows runs Linux
English is only my third language. Or my turd language, as I call it.
You don't need to be an expert/consultant to evaluate crap.
I'm payed for programming, dude, no worries on that front.