It is only a matter of time before the US uses these robotic bees to spy on "evil" nations' activities. I just had an interesting thought. If the same research happened in Iran or N. Korea, then the western media would have, by now, successfully crafted false stories like "Iran prepares robotic spies for spying on US". It is very sad that we are not seeing stories like "US preparing to dispatch robotic bees to all evil parts of the world."
If THEY don't back-port fixes, so what? YOU or ANYBODY else can. The only guy who can patch Microsoft software is Microsoft itself. That is not the case with open source software. That's basically my point.
It could be that the USA's cyber-warfare department is doing its best to disrupt Iranian networks. Or it could be that government shills are "reporting" fake news so as to create antagonism towards Iran in order to reduce the number of protests that the USA government would face during its future war against Iran.
is the part that gives rise to inefficiency. Calling a variable function is, in general, more expensive than calling a fixed function. The one instance where it's not all that expensive is when the pointer is an interrupt vector. CPUs have optimized circuits that make branching to a variable interrupt handler faster than branching to a variable function. Of course, it doesn't matter in academic projects where microsecond differences in scheduling latencies don't mean much. Good for you.
It seems you mean compile-time pluggability when you say "to replace". Your scheme works just fine until we want run-time pluggable scheduler in which case, the general rescheduling routine will have to dynamically decide which scheduler is to be used. This decision-making will consume CPU time and hence increase scheduling latency. So I think the only proper way to run-time pluggable scheduling is to change the interrupt vector (for timer interrupt) dynamically.
Alternatively, maybe pluggability would have to be done with self modifying code which left no indirection in place?
No. In most modern CPU architectures, schedulers are implemented by handling a timer interrupt. The address for the handling code is put in the interrupt vector table during kernel start-up. For implementing pluggable-scheduling, all you need to do is to change the contents of the interrupt vector table. Once that is done, scheduling happens the same way as when there's only a single scheduler. So no. It doesn't require self modifying code and it's not a performance overhead to have pluggable schedulers.
Why does Linux not have pluggable schedulers already? You can choose the scheduler in FreeBSD by changing a compile-time option and in OpenSolaris and Xen by changing a boot-time parameter. I think HURD can swap them out at run time, but I only know one person who actually runs HURD, and he also runs other systems for real work. If your system already has clean interfaces for the scheduler, then making them pluggable at compile time is trivial and making them pluggable at boot time is only a small amount of effort (although a bit more to make sure this has no performance side-effects). If it doesn't already have clean interfaces to the scheduler, then it probably has more serious problems than the lack of plug-support.
In the context of this discussion, "pluggable" means at-least boot-time selection (but some people want run-time selection too). Linux doesn't have it. And Linux's scheduler code does not even have clean interfaces as those other OSes. The problem is made worse by the politics of sponsoring companies. Like Con Kolivas said a long time back, these companies are willing to have 10% latency increase on desktops if it gives a 1% throughput increase on servers. So I don't expect things to change in the near future.
It doesn't matter that it runs linux. It runs a pretty locked-down linux-based distribution. It doesn't even have a terminal application. How do I create shell scripts? What kind of freedom is this? It's absolutely not for power users. I'd rather buy an OpenMoko or Android rather than this.
Well, i'll give them this point. But Microsoft has added support for ODF in Office 2007 SP2, however it was the ODF guys who weren't even able to spec out something basic as formulas in a spreadsheet specification.
And, since Windows 7, it even has integrated ODF support in WordPad.
The claimed support is incompatible with ODF spec in every way imaginable.
I can't help but notice one thing. If the same happened with Iran, N. Korea, China or any other political enemies of US, the media would be promoting more hatred towards those countries... would have tagged "tyranny" or "dictatorship", would have edited wikipedia pages about those countries to display false facts, would have created stories about "hackers" from those countries "stealing sensitive information from internet" (as if sensitive information is put on internet. oh wait! i'm sorry, i forgot. creating such stories is CIA's job. not media's.) The question is: does any one notice the amount of influence of US government (or its agencies) on media?
SELinux makes the problem worse. Without SELinux, there's a variable that specifies the lowest page in memory that a process can map. If you can't put anything at address 0, jumping through a NULL function pointer isn't as big a deal.
With SELinux on, that variable is ignored, and you can map at address 0 to your heart's content.
It is for times like these, that I always disable SELinux as soon as I install a distribution.
If you want to make an x86 chip commercially, then you need several patent licenses from Intel. x86 is a closed and monopolized architecture. Most people just don't know that because of its wide usage. You might ask: how does AMD...? AMD has cross-patent deal with Intel. Intel was forced by a court-ruling to make a cross-patent deal. Sadly, most people (including courts and EC) treat AMD's existence as a proof of x86's "openness" and Intel's "fair behavior".
Slashdot Mirror
It is only a matter of time before the US uses these robotic bees to spy on "evil" nations' activities.
I just had an interesting thought. If the same research happened in Iran or N. Korea, then the western media would have, by now, successfully crafted false stories like "Iran prepares robotic spies for spying on US". It is very sad that we are not seeing stories like "US preparing to dispatch robotic bees to all evil parts of the world."
What's that? I've always thought USB is Intel's child. Why would Intel create a competitor to its own standard?
If THEY don't back-port fixes, so what? YOU or ANYBODY else can. The only guy who can patch Microsoft software is Microsoft itself. That is not the case with open source software. That's basically my point.
That is also the problem. Everyone adds pieces and eventually it starts to become a mess. Then someone else should fix it.
Or we can just use an old version. Unlike to the case of proprietary software, we are not being forced to upgrade to "bloated mess".
It could be that the USA's cyber-warfare department is doing its best to disrupt Iranian networks. Or it could be that government shills are "reporting" fake news so as to create antagonism towards Iran in order to reduce the number of protests that the USA government would face during its future war against Iran.
The Iranian people have a natural right to communicate with one another even if their current turd of a leader does not respect it at this time.
Of course, that is a natural right. Nobody should question it. I think the other person was referring to USA's big brother role.
In Atom, a frontend is needed to translate x86 operations to uops. However, something similar is needed in ARM...
similar, but simpler. That's the point.
open source it so that people can fix bugs themselves.
Look at latency people. Not just the throughput.
"open format" would be more accurate.
a pointer to the scheduling function
is the part that gives rise to inefficiency. Calling a variable function is, in general, more expensive than calling a fixed function. The one instance where it's not all that expensive is when the pointer is an interrupt vector. CPUs have optimized circuits that make branching to a variable interrupt handler faster than branching to a variable function. Of course, it doesn't matter in academic projects where microsecond differences in scheduling latencies don't mean much. Good for you.
It seems you mean compile-time pluggability when you say "to replace". Your scheme works just fine until we want run-time pluggable scheduler in which case, the general rescheduling routine will have to dynamically decide which scheduler is to be used. This decision-making will consume CPU time and hence increase scheduling latency. So I think the only proper way to run-time pluggable scheduling is to change the interrupt vector (for timer interrupt) dynamically.
It has everything to do with Windows' broken support of standards and Microsoft's own broken standards.
Alternatively, maybe pluggability would have to be done with self modifying code which left no indirection in place?
No. In most modern CPU architectures, schedulers are implemented by handling a timer interrupt. The address for the handling code is put in the interrupt vector table during kernel start-up. For implementing pluggable-scheduling, all you need to do is to change the contents of the interrupt vector table. Once that is done, scheduling happens the same way as when there's only a single scheduler. So no. It doesn't require self modifying code and it's not a performance overhead to have pluggable schedulers.
Why does Linux not have pluggable schedulers already? You can choose the scheduler in FreeBSD by changing a compile-time option and in OpenSolaris and Xen by changing a boot-time parameter. I think HURD can swap them out at run time, but I only know one person who actually runs HURD, and he also runs other systems for real work. If your system already has clean interfaces for the scheduler, then making them pluggable at compile time is trivial and making them pluggable at boot time is only a small amount of effort (although a bit more to make sure this has no performance side-effects). If it doesn't already have clean interfaces to the scheduler, then it probably has more serious problems than the lack of plug-support.
In the context of this discussion, "pluggable" means at-least boot-time selection (but some people want run-time selection too). Linux doesn't have it. And Linux's scheduler code does not even have clean interfaces as those other OSes. The problem is made worse by the politics of sponsoring companies. Like Con Kolivas said a long time back, these companies are willing to have 10% latency increase on desktops if it gives a 1% throughput increase on servers. So I don't expect things to change in the near future.
Divert it to the third-world.
Why don't they just use Xine? It gives much better quality than GStreamer and is free (in both senses).
It doesn't matter that it runs linux. It runs a pretty locked-down linux-based distribution. It doesn't even have a terminal application. How do I create shell scripts? What kind of freedom is this? It's absolutely not for power users. I'd rather buy an OpenMoko or Android rather than this.
Well, i'll give them this point. But Microsoft has added support for ODF in Office 2007 SP2, however it was the ODF guys who weren't even able to spec out something basic as formulas in a spreadsheet specification.
And, since Windows 7, it even has integrated ODF support in WordPad.
The claimed support is incompatible with ODF spec in every way imaginable.
I can't help but notice one thing. If the same happened with Iran, N. Korea, China or any other political enemies of US, the media would be promoting more hatred towards those countries... would have tagged "tyranny" or "dictatorship", would have edited wikipedia pages about those countries to display false facts, would have created stories about "hackers" from those countries "stealing sensitive information from internet" (as if sensitive information is put on internet. oh wait! i'm sorry, i forgot. creating such stories is CIA's job. not media's.) The question is: does any one notice the amount of influence of US government (or its agencies) on media?
SELinux makes the problem worse. Without SELinux, there's a variable that specifies the lowest page in memory that a process can map. If you can't put anything at address 0, jumping through a NULL function pointer isn't as big a deal.
With SELinux on, that variable is ignored, and you can map at address 0 to your heart's content.
It is for times like these, that I always disable SELinux as soon as I install a distribution.
These days, there are BIOS-based root-kits too. So 'back to bare metal' can't be the 100% trustable solution.
Fixed it.
If you want to make an x86 chip commercially, then you need several patent licenses from Intel. x86 is a closed and monopolized architecture. Most people just don't know that because of its wide usage. You might ask: how does AMD...? AMD has cross-patent deal with Intel. Intel was forced by a court-ruling to make a cross-patent deal. Sadly, most people (including courts and EC) treat AMD's existence as a proof of x86's "openness" and Intel's "fair behavior".
Agreed.