If you don't want "the legacy", compile it out of the kernel, but don't remove it, for crying out loud! Some people still use that, and for good reasons.
64-bit arithmetic can be easily implemented on 8-bit devices. The problem will be upgrading the software on them, although it seems like it's doable in 25 years, even if that means going to some harder to reach place such as the North Pole.
Of course, that's a much bigger problem if you don't have the original sources and/or if you work with legacy technologies (think: COBOL) that are more difficult to maintain these days due to the lack of people that are competent in those areas. But that just means that the demand for such solutions will rise and someone will come with one or more ways to tackle it.
Mod parent up. It's called the Principle of least privilege, which Unix systems implement using mechanisms like sudo. Having root access on Android systems breaks this to some extent.
In fact games involve massively parallel tasks at the data level. It's why dedicated hardware for graphics use architectures with tens or hundreds of cores. IMHO games would benefit a lot from multiple lower-frequency CPU even for non-graphics tasks (think: simulating a unit in a some real-time strategy game using a thread).
it means the battery lasts longer - if you can twice the work in the same time, that means the same amount of work takes half the time - so you've cut your CPU usage by half.
Not necessarily. If the code you run results in usage of extra hardware, the cost of using that might result in a less efficient behaviour power-wise. What I'm saying is yes, Hurry Up and Get Idle is a good principle in theory, but it doesn't always work in practice because different instructions incur different power/time costs.
So the problem might be a tad trickier, there's other measures to be taken into account, such as how that affects lock contention, caches and so on. I personally can't make any statements until I see actual power usage results and comparisons.
Not really. Mechanisms are patentable, algorithms aren't.
In this case slide to unlock is a mechanism with a clear description and such, while range checking is (as far as I can see) something too abstract to become a patent.
Ok, so imagine you want to teach computer architectures. Which aren't quite electrical engineering but they aren't theoretical computer science either. Which department would you assign that to?
I'd also add that any good computer architect should be skilled in both hardware and software-related issues, in electronics, electrical engineering as well as some discrete math. I don't see how you can put all those together outside of a CS department.
Actually things aren't that simple. I find the field of Game Theory to provide pretty good measures for such things as social and individual welfare. And from what I managed to understand, a non-centralized system (that is, where everyone is mainly interested in their own well-being) doesn't necessarily lead to a non-optimal social welfare. Reversely, a centralized system (where some entity makes decisions to try and satisfy everyone) doesn't guarantee optimal social welfare.
So while some social measures might be good (protecting children and disabled people for example), most of them can actually prove to have a bad effect on the society as a whole. And even though communism is pretty much the mother of all bad socially-oriented decisions, the idea of bad socialism has the chance to apply to any society, including the ones that are democratic in nature.
Actually a lot of the functionality of Renault cars has been designed and built by Romanian engineers for quite some time now. I'm not saying that's necessarily state of the art, but it surely invalidates your statement.
That sounds simple but it isn't. While you could theoretically do this from a virtual machine, the difference between visualising” it and testing it on real hardware is significant especially when it comes to device drivers, which are known to be the most common source of bugs in kernels.
Plus verifying a kernel or a compiler is a pretty hard problem, it's a miracle if you manage to do it in decent time, let alone manage to visualise it in any way.
I don't know if I got the "hypertext literature" bit too well, but I think blogs are literature as much as books. So I don't believe that only because the format is different, "hypertext literature" is in itself dead.
This post kind of reminds me of H.G. Wells' Time Machine. That book describes a future in which human society is split along two evolutionary paths, albeit different from the one described above.
Mod parent up. Virtualization isn't the latest-hardware-resource-hogging-thing like some other pieces of software, it's been here since the 60s. There already are projects for paravirtualization-oriented (micro)kernels on embedded architectures (namely ARM), many of them based on the L4 family. They aren't exactly made for the mobile market yet, but with the proper hardware support these could really rock on OS-level power management and security.
AT&T did a documentary on the (then) present and future of computers, narrated by William Shatner. It's similar to the videos in TFA. Youtube link goes here.
...without efficient static memory, mostly because of the CPU-Memory gap. A faster CPU would require the memory and the bus to keep up at a similar frequency. That's already a problem, and even if that were possible then it would lead to increased power consumption using dynamic RAM and frankly, I think that's the last thing we need.
So faster CPUs will only be a viable alternative when we manage to get something like those memristors they keep talking about. Until then, it's larger caches and higher-frequency DRAM.
I agree with that, but developers often sacrifice portability for performance, that's a fact. CUDA isn't any more portable than assembly, yet it can improve performance a great deal if used correctly. IBM Cell processors can be programmed at assembly level, which is why a Playstation 3 can perform better than a PC, marketing and everything else aside. When a computer architecture like those mentioned is odd enough that the compiler isn't able to optimize, you just have to go there.
Your argument would hold if DirectX were portable. I don't really see it running natively anywhere except Windows and Xbox.
I really don't understand some people's aversion towards assembly language. Yes, sure, we all want a user-friendly programming environment, but not when it comes to squeezing all we can out of the hardware. My two cents.
He does make a point though. Some of the best releases I played last year or the year before (like Machinarium, Trine or World of Goo) came from small companies. I can't remember when was the last time EA made a really enjoyable game, like those mentioned.
Wouldn't that be a bit rough for such a drone? And by that I mean: flying in such conditions is rougher than flying a 747 in Earth's atmosphere. How will they be able to come out with something efficient for this problem? Just wondering.
Slashdot Mirror
Short answer: yes.
If you don't want "the legacy", compile it out of the kernel, but don't remove it, for crying out loud! Some people still use that, and for good reasons.
64-bit arithmetic can be easily implemented on 8-bit devices. The problem will be upgrading the software on them, although it seems like it's doable in 25 years, even if that means going to some harder to reach place such as the North Pole.
Of course, that's a much bigger problem if you don't have the original sources and/or if you work with legacy technologies (think: COBOL) that are more difficult to maintain these days due to the lack of people that are competent in those areas. But that just means that the demand for such solutions will rise and someone will come with one or more ways to tackle it.
Mod parent up. It's called the Principle of least privilege, which Unix systems implement using mechanisms like sudo. Having root access on Android systems breaks this to some extent.
In fact games involve massively parallel tasks at the data level. It's why dedicated hardware for graphics use architectures with tens or hundreds of cores. IMHO games would benefit a lot from multiple lower-frequency CPU even for non-graphics tasks (think: simulating a unit in a some real-time strategy game using a thread).
No. (IBM) PC is a computing platform, while x86 is a processor architecture. Better if we don't confuse those two.
Does it? other ex-USSR states seem to have done just fine.
It should be noted though that Romania wasn't part of the USSR before 1990, as weren't Hungary, Czechoslovakia, eastern Germany etc.
it means the battery lasts longer - if you can twice the work in the same time, that means the same amount of work takes half the time - so you've cut your CPU usage by half.
Not necessarily. If the code you run results in usage of extra hardware, the cost of using that might result in a less efficient behaviour power-wise. What I'm saying is yes, Hurry Up and Get Idle is a good principle in theory, but it doesn't always work in practice because different instructions incur different power/time costs.
So the problem might be a tad trickier, there's other measures to be taken into account, such as how that affects lock contention, caches and so on. I personally can't make any statements until I see actual power usage results and comparisons.
Yep, and here's something even funnier (this time on purpose): http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD475.html
I mean I'm not saying people always make good decisions.
Not really. Mechanisms are patentable, algorithms aren't.
In this case slide to unlock is a mechanism with a clear description and such, while range checking is (as far as I can see) something too abstract to become a patent.
That wouldn't make sense. I mean what marketing person would use "Linux machine" and "graphics" in the same sentence?
Ok, so imagine you want to teach computer architectures. Which aren't quite electrical engineering but they aren't theoretical computer science either. Which department would you assign that to?
I'd also add that any good computer architect should be skilled in both hardware and software-related issues, in electronics, electrical engineering as well as some discrete math. I don't see how you can put all those together outside of a CS department.
Actually things aren't that simple. I find the field of Game Theory to provide pretty good measures for such things as social and individual welfare. And from what I managed to understand, a non-centralized system (that is, where everyone is mainly interested in their own well-being) doesn't necessarily lead to a non-optimal social welfare. Reversely, a centralized system (where some entity makes decisions to try and satisfy everyone) doesn't guarantee optimal social welfare.
So while some social measures might be good (protecting children and disabled people for example), most of them can actually prove to have a bad effect on the society as a whole. And even though communism is pretty much the mother of all bad socially-oriented decisions, the idea of bad socialism has the chance to apply to any society, including the ones that are democratic in nature.
Actually a lot of the functionality of Renault cars has been designed and built by Romanian engineers for quite some time now. I'm not saying that's necessarily state of the art, but it surely invalidates your statement.
That sounds simple but it isn't. While you could theoretically do this from a virtual machine, the difference between visualising” it and testing it on real hardware is significant especially when it comes to device drivers, which are known to be the most common source of bugs in kernels.
Plus verifying a kernel or a compiler is a pretty hard problem, it's a miracle if you manage to do it in decent time, let alone manage to visualise it in any way.
I don't know if I got the "hypertext literature" bit too well, but I think blogs are literature as much as books. So I don't believe that only because the format is different, "hypertext literature" is in itself dead.
Bad guys use the toilet too. They also eat and sleep and such, and we could argue that this does indirectly help them make better malware. So?
This post kind of reminds me of H.G. Wells' Time Machine. That book describes a future in which human society is split along two evolutionary paths, albeit different from the one described above.
Mod parent up. Virtualization isn't the latest-hardware-resource-hogging-thing like some other pieces of software, it's been here since the 60s. There already are projects for paravirtualization-oriented (micro)kernels on embedded architectures (namely ARM), many of them based on the L4 family. They aren't exactly made for the mobile market yet, but with the proper hardware support these could really rock on OS-level power management and security.
AT&T did a documentary on the (then) present and future of computers, narrated by William Shatner. It's similar to the videos in TFA. Youtube link goes here.
...without efficient static memory, mostly because of the CPU-Memory gap. A faster CPU would require the memory and the bus to keep up at a similar frequency. That's already a problem, and even if that were possible then it would lead to increased power consumption using dynamic RAM and frankly, I think that's the last thing we need.
So faster CPUs will only be a viable alternative when we manage to get something like those memristors they keep talking about. Until then, it's larger caches and higher-frequency DRAM.
I agree with that, but developers often sacrifice portability for performance, that's a fact. CUDA isn't any more portable than assembly, yet it can improve performance a great deal if used correctly. IBM Cell processors can be programmed at assembly level, which is why a Playstation 3 can perform better than a PC, marketing and everything else aside. When a computer architecture like those mentioned is odd enough that the compiler isn't able to optimize, you just have to go there.
Your argument would hold if DirectX were portable. I don't really see it running natively anywhere except Windows and Xbox.
I really don't understand some people's aversion towards assembly language. Yes, sure, we all want a user-friendly programming environment, but not when it comes to squeezing all we can out of the hardware. My two cents.
He does make a point though. Some of the best releases I played last year or the year before (like Machinarium, Trine or World of Goo) came from small companies. I can't remember when was the last time EA made a really enjoyable game, like those mentioned.
"Google is working on a service that finds information before a user has even started looking for it."
Isn't that called advertising?
Wouldn't that be a bit rough for such a drone? And by that I mean: flying in such conditions is rougher than flying a 747 in Earth's atmosphere. How will they be able to come out with something efficient for this problem? Just wondering.