16kB of RAM could fetch text off the internet, but not actually store it in memory, let alone decode and display it. This very Slashdot page is over 100kB of HTML.
The best you could do with 16kB RAM is display a constant advertisement, stored in ROM, for the laptop the consumer should have bought instead.
Well that's not quite true. It depends entirely on *how* you express your program logic. You can't make a C compiler that makes use of a GPU, but you can make use of a mathematical kernel compiler which can use x86 and a GPU to almost their fullest performance.
That's where the trend is going with OpenCL. OpenCL will let you run mathematical code reasonably well on a CPU (maybe not as well as equivalent C, but that gap should close), and without modification, run it stupidly well on a GPU. So you'd just link it with your Python program and benefit from whatever hardware/software combination you have available, (hopefully) without having to modify the Python or the math kernel.
Current Windows inherited most of its security problems from DOS and Win16. In fact Windows XP was the first "home desktop" Windows (given 2000 was marketed for office use) to use memory protection at all. Prior to that a process could read/write anywhere, which effectively meant there was no security of any kind.
And since most applications require administrator access to run at all, including most server applications, even having memory protection is reduced to the effectiveness of chewing gum. With administrator access, any application can insert itself as a shim into any other application.
Then even when you do narrow down to the few applications that run with pure user access, and run that way all the time, there are plenty of privilege escalation holes to get that administrator access back.
It's swiss cheese from the ground up. Users cannot be expected to be tech geeks just to be basically secure. Certainly if they run an untrusted binary, their personal files are forfeit, but by no means should that be allowed to spread to the whole system (of potentially thousands of users) nor the whole network via server software running as administrator.
Just a data point, several releases of the JVM as supplied with JRE6 would break Eclipse on amd64. It's fixed now, but during that time, explicitly blacklisting certain classes/methods from JIT compilation, or using -Xint, were recommended just so you could work at all.
Not my point - the point is the filesystem doesn't guarantee anything, fsync just gets it one layer further (which may or may not be enough depending on your controller, disk, etc.)
No, disk caching is now considered the default. Nothing is written until the disk decides it is time, and this is completely up to them. It doesn't even have to occur in the same order the writes were issued in, especially with TCQ.
A UPS that lasts more than 1 minute on a high-watt machine is already going to cost several hundred. So you'd need to pair this with a "forced write" (is sync(1) enough?) as soon as the power cut is detected.
His is at least possible. SSDs as they are now have only been around for a very short time, much shorter than 10 years. We can certainly start to say how early the failed ones failed, but not how long it would take for currently running ones to fail, until the dots start appearing on the plot.
nVidia wants to make chipsets which are potentially not covered by their agreement with Intel. Intel seems to want to take that market back, and as anticompetitive as it is, it might just work. nVidia will be stuck making only niche products which are guaranteed to be crippled by anticompetitive behavior. If you think this can't possibly work, look where it got Microsoft.
Interrupts, DMA, memory control, etc. are NOT implemented in software, they require cooperation from the motherboard at minimum. Your GPU would need significant hardware extensions to be able to function as a CPU sufficiently that a BIOS could use it to bootstrap and access host hardware directly. At that point it may as well be a CPU.
There's a "cycle of reincarnation" with hardware. First new hardware is created to meet new requirements, then as it is refined, optimised and physically shrunk, it is integrated deeper into its host system. Sometimes the external version is never marketed again since it has no remaining advantages. Examples:
Card -> motherboard integration * Onboard audio (good enough for 99% of users) * Onboard LAN (99%) * Onboard video (maybe 80%, I don't have figures)
Board device -> CPU component integration: * Floating point coprocessors (integrated into the instruction set itself) * Memory controllers (in CPU since Athlon64 and Core i7) * Temperature sensors (integrated into the CPU per-core) * RAM (now 3 layers of CPU cache, each larger than entire computers used to have, but we still use RAM for general purposes)
And very soon, GPU in CPU, thanks to projects from Intel and AMD.
This is the way of things. nVidia will drag out a few more years providing high-performance GPUs, but they're kidding themselves if they think they won't also be absorbed into the motherboard or CPU.
Modern CPUs perform branch prediction (partly guided by the binary itself) and will import a weighted portion of the possible code following a branch. There is still a cost to branching of course but it is far lower than it was in the old days - it's down to barely more than a static jump. Also, that's why Profile Guided Optimisation makes such a big difference even to an already "optimised" binary.
No, the number represents how far it is from perfection. Perfection is when there is nothing left to take away. The ultimate CPU will be x0. I'm going to trademark it ahead of time.
That's not quite true - the CPU's MMU handles some housekeeping on used RAM. However that's none of the motherboard's business, especially with memory controllers being integrated into the CPU these days. And even that information is far too limited to implement page replacement, which is still the responsibility of a sophisticated kernel.
Easy - you already have a separation between volatile and non-volatile storage in all operating system kernels. It doesn't matter whether the underlying technology is the same - in fact you can deliberately blur the line by using part of your RAM as a virtual disk (tmpfs + file + losetup in Linux, memory-backed vnode in FreeBSD).
Wow, now all we need is to connect the GPU to the FSB/QPI, make it support pagetables, interrupts, DMA, CPU-style L1/2/3 coherent cache, memory controller with synchronous fencing, legacy and long modes for pointers and instructions, etc.... and then we'll have something that can possibly emulate an x86 CPU at only 99.9% performance penalty!!
Null dates wouldn't have avoided the millenium bug mess. Implementing such a beast is far more complicated than just extending the data field. You'd need to select a specific value for the data word and treat it specially everywhere it's referenced.
In fact, virtually everything you have said is wrong in some way. Return null when reading null? No, that's just stupid. It would make it extremely difficult to find bugs where you actually did end up with a null pointer. And what if you write to it? Should it come out zeroed as well? I hope you don't seriously mean that PRIMITIVE types such as int should support a null value distinct from zero. Have you ever actually written systems code?
The what now? You can dock any number of editors and tool panels in any way, and start a whole new window for your second monitor if that's not enough.
It's not a grid-like split if that's what you are after. Request it on the bug tracker if you like.
That sounds strangely like racketeering, and could be presented as such by a legal team. Having good intentions does not absolve you of such flexible laws.
Besides that, there is the Open Innovation Network, which is basically a bubble inside of which patents are harmless. Any companies joining agree not to assert patent claims against other companies in the network. There are many high-profile members, of which Microsoft is of course not one.
Will the US nationalists make up their collective mind? If capitalism and competition are good, then Microsoft can only be bad for stifling competition.
Successful companies are a good thing, they can help improve the industry's efficiency through reduced prices and increased quality. But monopolistic companies like Microsoft rarely do either.
If it wasn't for the monopoly, Microsoft would have been dead between XP and Vista. Six years between incremental product releases? Instant death in any *normal* industry. Fast-paced competitors like Apple and Linux would have eaten it for breakfast. And the economy would benefit. So does the US still need more Microsofts?
Slashdot Mirror
16kB of RAM could fetch text off the internet, but not actually store it in memory, let alone decode and display it. This very Slashdot page is over 100kB of HTML.
The best you could do with 16kB RAM is display a constant advertisement, stored in ROM, for the laptop the consumer should have bought instead.
Well that's not quite true. It depends entirely on *how* you express your program logic. You can't make a C compiler that makes use of a GPU, but you can make use of a mathematical kernel compiler which can use x86 and a GPU to almost their fullest performance.
That's where the trend is going with OpenCL. OpenCL will let you run mathematical code reasonably well on a CPU (maybe not as well as equivalent C, but that gap should close), and without modification, run it stupidly well on a GPU. So you'd just link it with your Python program and benefit from whatever hardware/software combination you have available, (hopefully) without having to modify the Python or the math kernel.
Current Windows inherited most of its security problems from DOS and Win16. In fact Windows XP was the first "home desktop" Windows (given 2000 was marketed for office use) to use memory protection at all. Prior to that a process could read/write anywhere, which effectively meant there was no security of any kind.
And since most applications require administrator access to run at all, including most server applications, even having memory protection is reduced to the effectiveness of chewing gum. With administrator access, any application can insert itself as a shim into any other application.
Then even when you do narrow down to the few applications that run with pure user access, and run that way all the time, there are plenty of privilege escalation holes to get that administrator access back.
It's swiss cheese from the ground up. Users cannot be expected to be tech geeks just to be basically secure. Certainly if they run an untrusted binary, their personal files are forfeit, but by no means should that be allowed to spread to the whole system (of potentially thousands of users) nor the whole network via server software running as administrator.
Just a data point, several releases of the JVM as supplied with JRE6 would break Eclipse on amd64. It's fixed now, but during that time, explicitly blacklisting certain classes/methods from JIT compilation, or using -Xint, were recommended just so you could work at all.
Ooh. Ok, I bow out.
Which is why it lagged behind x86-64 Linux, BSD, etc. for a few years, and even today still doesn't have nearly as much driver support.
If that's "easy to produce", it is very clear why Microsoft runs behind schedule on everything else they do as well.
The same superior generic hardware that is now threatened by this licensing war.
Urgh, that was not an alliteration at all. Allow me.
Your post poses probable perfect Peter Principle patrondom.
Do you have publicly viewable documentation on that? That sounds awesome and I'm very interested in reading the details.
Not my point - the point is the filesystem doesn't guarantee anything, fsync just gets it one layer further (which may or may not be enough depending on your controller, disk, etc.)
No, disk caching is now considered the default. Nothing is written until the disk decides it is time, and this is completely up to them. It doesn't even have to occur in the same order the writes were issued in, especially with TCQ.
A UPS that lasts more than 1 minute on a high-watt machine is already going to cost several hundred. So you'd need to pair this with a "forced write" (is sync(1) enough?) as soon as the power cut is detected.
You fail at math.
80Mb/s * 8bits/byte = 640MB/s.
480MB/s / 8bits/byte = 60Mb/s.
His is at least possible. SSDs as they are now have only been around for a very short time, much shorter than 10 years. We can certainly start to say how early the failed ones failed, but not how long it would take for currently running ones to fail, until the dots start appearing on the plot.
nVidia wants to make chipsets which are potentially not covered by their agreement with Intel. Intel seems to want to take that market back, and as anticompetitive as it is, it might just work. nVidia will be stuck making only niche products which are guaranteed to be crippled by anticompetitive behavior. If you think this can't possibly work, look where it got Microsoft.
Interrupts, DMA, memory control, etc. are NOT implemented in software, they require cooperation from the motherboard at minimum. Your GPU would need significant hardware extensions to be able to function as a CPU sufficiently that a BIOS could use it to bootstrap and access host hardware directly. At that point it may as well be a CPU.
There's a "cycle of reincarnation" with hardware. First new hardware is created to meet new requirements, then as it is refined, optimised and physically shrunk, it is integrated deeper into its host system. Sometimes the external version is never marketed again since it has no remaining advantages. Examples:
Card -> motherboard integration
* Onboard audio (good enough for 99% of users)
* Onboard LAN (99%)
* Onboard video (maybe 80%, I don't have figures)
Board device -> CPU component integration:
* Floating point coprocessors (integrated into the instruction set itself)
* Memory controllers (in CPU since Athlon64 and Core i7)
* Temperature sensors (integrated into the CPU per-core)
* RAM (now 3 layers of CPU cache, each larger than entire computers used to have, but we still use RAM for general purposes)
And very soon, GPU in CPU, thanks to projects from Intel and AMD.
This is the way of things. nVidia will drag out a few more years providing high-performance GPUs, but they're kidding themselves if they think they won't also be absorbed into the motherboard or CPU.
Modern CPUs perform branch prediction (partly guided by the binary itself) and will import a weighted portion of the possible code following a branch. There is still a cost to branching of course but it is far lower than it was in the old days - it's down to barely more than a static jump. Also, that's why Profile Guided Optimisation makes such a big difference even to an already "optimised" binary.
No, the number represents how far it is from perfection. Perfection is when there is nothing left to take away. The ultimate CPU will be x0. I'm going to trademark it ahead of time.
That's not quite true - the CPU's MMU handles some housekeeping on used RAM. However that's none of the motherboard's business, especially with memory controllers being integrated into the CPU these days. And even that information is far too limited to implement page replacement, which is still the responsibility of a sophisticated kernel.
Easy - you already have a separation between volatile and non-volatile storage in all operating system kernels. It doesn't matter whether the underlying technology is the same - in fact you can deliberately blur the line by using part of your RAM as a virtual disk (tmpfs + file + losetup in Linux, memory-backed vnode in FreeBSD).
Wow, now all we need is to connect the GPU to the FSB/QPI, make it support pagetables, interrupts, DMA, CPU-style L1/2/3 coherent cache, memory controller with synchronous fencing, legacy and long modes for pointers and instructions, etc.... and then we'll have something that can possibly emulate an x86 CPU at only 99.9% performance penalty!!
Or, you know, not.
Null dates wouldn't have avoided the millenium bug mess. Implementing such a beast is far more complicated than just extending the data field. You'd need to select a specific value for the data word and treat it specially everywhere it's referenced.
In fact, virtually everything you have said is wrong in some way. Return null when reading null? No, that's just stupid. It would make it extremely difficult to find bugs where you actually did end up with a null pointer. And what if you write to it? Should it come out zeroed as well? I hope you don't seriously mean that PRIMITIVE types such as int should support a null value distinct from zero. Have you ever actually written systems code?
The what now? You can dock any number of editors and tool panels in any way, and start a whole new window for your second monitor if that's not enough.
It's not a grid-like split if that's what you are after. Request it on the bug tracker if you like.
That sounds strangely like racketeering, and could be presented as such by a legal team. Having good intentions does not absolve you of such flexible laws.
Besides that, there is the Open Innovation Network, which is basically a bubble inside of which patents are harmless. Any companies joining agree not to assert patent claims against other companies in the network. There are many high-profile members, of which Microsoft is of course not one.
Will the US nationalists make up their collective mind? If capitalism and competition are good, then Microsoft can only be bad for stifling competition.
Successful companies are a good thing, they can help improve the industry's efficiency through reduced prices and increased quality. But monopolistic companies like Microsoft rarely do either.
If it wasn't for the monopoly, Microsoft would have been dead between XP and Vista. Six years between incremental product releases? Instant death in any *normal* industry. Fast-paced competitors like Apple and Linux would have eaten it for breakfast. And the economy would benefit. So does the US still need more Microsofts?