Java has so many bugs in it that it can't be hacked? No, but your English parser does. There was a small defect in the input and instead of handling it gracefully it corrupted the discussion.
That's why you just got the uncontrollable urge to eat brains.
perfect security is impossible, somehow "bringing the fight to the enemy" isn't a solution. Changing the way you think about the internet is. The internet is fine security-wise. Our network organization is fine security-wise. What is not fine is our actual software. There is no reason why software should be hackable. Buffer and heap overflows are not a necessary condition. Kernel bugs do not need to allow arbitrary code to be run. These are fundamental security problems in how we program computers, not in the systems themselves.
For example, programs that are written in Java effectively cannot be hacked due to bugs. Operating system kernels like Singularity or jxos or JavaOS written in typesafe languages cannot be hacked due to any but an extremely small set of possible bugs in them. Bugs can cause these to do things they would otherwise do when they should not, but they effectively cannot be hacked to run arbitrary code. Even a properly designed HTML would not have inline scripts so it would be impossible to run arbitrary code due to not escaping strings (ie scripts could come only after the end of the document and then be referenced by id in the doc instead of appearing inline).
Regardless of whether you are a kernel or application or web developer if you choose to program in C, C++, or any other language where it is possible for bugs to cause arbitrary code to run then you are choosing in your own way to support viruses and spam and security breeches.
If you go to the system preferences and change the keyboard layout options it fixes most of the vmware keyboard problems (like stuck/unusable crtl keys, or any key typed closing the window typed into). In gnome I toggle the 'caps lock is another ctrl key' option.
In computers we have "laws" that we call the "system interface". It can behave predictably and reliably for years under all sorts of conditions, but then once somebody comes along and really starts purposefully really messing with it occasionally something completely unexpected happens. Sometimes the whole system panics even though no theory or math could predict that.
Just because your physics says something 'can't happen' and that the 'exact same stuff' has been going on for eons with no problem does not mean that once you start purposefully messing with it that something bad will not happen. It's just that simple. And if we already knew exactly what was going to happen, we wouldn't need to do the experiments in the first place.
What would make this even more awesome if it came with a windows qemu already set up to run your ubuntu from the virtual disk file with all your installed programs and config while inside Windows. So when you have to dual boot back into windows you can still access your files (although slowly).
It might need to boot into a special image that just mounts from the disk file to keep ubuntu from detecting new hardware and stuff like that. But I think it should be pretty easy to do really.
Most of your points about physical ballots go away if observers can see the empty ballot box before polls open and watch it all day long until the votes are taken out and counted locally. You know, like in Canada. The kind of system we don't have, since we rig our votes.
* You can't pre-stuff the box with your fake votes. * You can't 'swap the ballot box'. * You can't add more than one votes without being detected since observers can count how many people vote.
Furthermore your evaluation of electronic voting security is flawed:
* Clearing logs files is easy * You don't need physical access, your hack can be spread 'by floppy' over time. * You can't ask a computer to 'md5sum' itself to verify its correctness -- that's as possible as solving the halting problem. * It is even theoretically possible to alter the specific memory address of the counts using radiation./target yourmods/sigh
and these get run on two or more processors faster than it runs on one you'll never get much use out of the extra ones. Our current operating systems can't take a small loop like say 100 iterations and divide it up across processors and have it run faster than just doing it on one. That's the problem. Just a rough guess but I bet.function would have to take well over 10k cycles to make it worth attempting on a modern operating system like Linux or Mac Os X.
The most benefit from parallel execution is at the really fine-grained level. We already have threads and processes. Threads are really great at doing multiple actions at once... but really bad at speeding up any one particular action. What's needed is some kind of operating system support for running small loops on multiple processors.
Setting aside those problems which exhibit no parallelism (for whom there is no solution but a faster CPU really), there are many classes of problems which would benefit enormously from better programming models, which are more efficiently tied to the operating system and hardware rather than going through an OS level threading package. The programming models we have are just fine. By far the vast majority of program time is spent in a loop of some kind, but languages which could easily parallelize loops don't. There is no reason why 'foreach' or 'collect' cannot use other processors (whereas 'inorder' or 'inject' would always be sequential). So our programming models are not the problem. The real problem is trying to use them with a 40 year old operating system design.
Current operating system could run code in parallel if they stop scheduling threads a timeslice on a processor but instead schedule a timeslice across multiple processors. Take an array of 1000 strings and a regex to match them against. If the program is allocated 10 processors it can do a simple interrupt and have them start working on 100 strings each. By having the processors allocated can you avoid the overhead of switching memory spaces and of scheduling, making this kind of fine-grained parallelism feasible.
But the problem here is that most programs will use one or two processors most of the time and all the available processors at other times. And if your parallel operation had to synchronize at some point then you'd have all your other allocated processors doing nothing while waiting for one to finish with its current work. So there is a huge amount of wasted time by allocating a thread to more than one processor.
A solution to the unused processor problem is to have a single memory space, and so as a consequence only run typesafe code -- an operating system like JavaOS or Singularity or JXOS. This lets any processor be interrupted quickly to run any process's code in parallel, so CPU's can be dynamically assigned to different threads. Even small loops can be effectively run across many CPUs, and there is no waste from the heavyweight allocations and clunkiness that is caused ultimately by separate memory spaces needed to protect C-style programs from each other. This is why it is the operating system, not the programming models, that is the main problem.
That works very well. The problem is when you have a single CPU-intensive task, and you want to split that over multiple processors. That, in general, is a difficult problem. It is in general, an impossible problem.
Most existing code is imperative. Most programmers write in imperative programming languages. Object orientation does not change this. Imperative code is not suited for multiple CPU implementation. Stapling things together with threads and messaging does not change this. Actually it is not really a hard problem at all, but a solution won't magically make every program use every processor with 100% efficiency -- that seems to be the only result that people consider a solution. But what is impossible is solving it with today's operating systems and language implementations.
Modern operating systems just cannot schedule and manage running fragments of code across multiple processors. Suppose you wanted to do a regex match against a list of 10,000 lines across upto 80 processors. First you would have to have created a pool of 80 threads, each locked to a different CPU. Then add some work to them so they each perform a subset of the matches. Then the OS has to switch to each thread, probably involving a tlb flush, and using large time slices since context switching is so costly. So even in the best case with already existing threads you're talking at least a couple thousand cycles and a few time slices lost in overhead per CPU. So this is a net loss in terms of realtime unless the regex is very costly.
Now consider an operating system that gave a program a timeslice across a certain number of processors instead of for each thread on a per-cpu basis. Then the program could do things like run the regex on each line across multiple CPUs, and the overhead would be only say a hundred cycles on each CPU to interrupt what it was currently doing. Now replace regex with some generic closure... this approach would let that closure *also* be able to do work across multiple CPUs, so that if some processors completed their assigned work quickly they would be helping the processors that had harder work assigned to them.
The other part of the solution is to have a typesafe operating system, like Singularity or JXOS or JavaOS. First, running an action across multiple CPUs means memory will be allocated by one CPU and freed by another. Having garbage collection reduces the problem of locking this, since you essentially do a lock once to start/stop gc instead of at every malloc and every free. And much of this work can be done by other CPUs while a program is running in a 'narrow' part that can only be done in order. Also, if every program shares the same memory space then doing a multiple-CPU timeslice has much less overhead, and in fact CPUs can be dynamically redistributed between processes with so little waste that it is practical to do so.
So you see, what you ask is impossible in practice with current operating systems and most C-style programming environments (anything not type safe). But it is possible, and our operating systems and programming will adapt to it, because purely linear execution will not scale. Fundamentally there will be limits on how fast operations can be done in sequence, and practically speaking it will be cheaper to make 80 cores than to make a core 80 times faster.
Actually, if you are running vmware for high security and server isolation you are running it on ESX, or at least VMware Server. Neither of which are vulnerable to this exploit. You're probably also running it on a unix.
The description says basically that Windows' MultiByteToWideChar takes invalid UTF8 and unless you specifically tell it not to it allows errors such as expressing 7-bit characters as several bytes (or probably also allowing the longer variations of any character). Valid UTF8 only allows the smallest possible representation of a character. So vmware checks for "..", but the string is really more like "{4 zero bit}.{4 zero bits}." that when converted from utf8 to wide becomes just "..".
So this not likely to affect unix as well, where mbsrtowcs function stops on invalid sequences. In my view Microsoft is more to blame for this defect than the vmware authors since Microsoft created a function that hides input errors by default. The whole reason why UTF8 only allows the minimal representation is entirely to avoid these kinds of ambiguities and errors.
So for quantum coins, your only recourse is to always flip all of them at once, and then keep track of the number of times you see each of the 2^N possible outcomes Generally in a simulation you do exactly that. You advance the simulation one unit by going through and applying some function to each element, if it is discrete units of time, or taking the earliest event and performing it. I think what you are talking about is using a simulation to determine all possible outcomes, but this is not possible to compute for any non trivial simulation as you point out.
In terms of programming, a function passed a set of coins can observe their values (ie coin.value()) and keep track of the number of times it sees each combination -- this is your 2^N. The function can even test each coin to see if some of them are actually the same coin, but this still doesn't necessarily tell them what value each will be. For example, if coin.value() adds one to the value then you could come up with all sorts of weird conjoined or *impossible* outcomes, like having all the coins be 0. Or you could have all the coins give the same value, or any other weird quantum effect you allude to.
In other words, what you are describing is yet another aspect of quantum mechanics that makes more sense when thought of as a simulation.
You joke, but consider if the universe were a simulation -- quantum mechanics makes a lot more sense in term of a simulation. Things like spooky action at a distance become lazy evaluation. Quanta become memory locations, variables. And so on. Quantum mechanics is easy to simulate.
But how does one simulate gravity? It has to propagate in every direction at the something like speed of light or else -- god forbid -- information could travel faster than light. The whole concept of gravity, that every individual particle affects however slightly every other particle, is not possible to compute directly.
Now suppose the universe were simulated as a sparse matrix. Each cell could contain a gravity component that stored the aggregate gravity force from each of a certain number of directions (perhaps expressed as several point masses). Depending on the number of directions this would give highly accurate simulation at a small scale, where error is absorbed as noise, while being computable for the overall universe as a whole. However the error would magnify over great distances due to 'floating point' type errors accumulating.
What if what these people are seeing as dark matter is not matter at all, but simulation error. Perhaps even dark matter is related to a sparse simulation of the universe where intervening space is approximated by invisible masses that gravity affects but nothing else does. These mass would act to consolidate cells in the matrix to reduce the overall memory requirements.
When AMD came out with low priced CPUs... When they changed their mind and decided to price-match Intel... why they can't keep the prices low like in the past What are you talking about? I don't remember a time in the past 10+ years where AMD cost as much as Intel in price/performance, except very brief windows like around core duo.
Compare Core 2 e6550 conroe to Athlon x2 5000+ brisbane. Both are 65nm and have mostly the same power and heat. The core 2 is ~5%-20% faster in benchmarks (see tom's) but costs 80% more. Or compare phenom to extreme... extreme is no more than twice as fast but costs four times the amount.
I don't know if AMD can keep it up but they are by far the most cost effective CPUs at the moment and historically.
1. Bluray discs have menus, usually done with standardized scripts running on top of Java. 2. Content that looks good > content that may crash sometimes 3. Java > assembly for a consumer product
HDDVD also had a path to higher capacities. From a movie-watcher's perspective, BluRay has absolutely 0 technical advantages. In terms of a storage medium it has some advantage, but not one HDDVD couldn't have matched easily enough. Bluray uses Java, so the menus and scripting can be more more advanced than that of HDDVD -- in fact most of the reason for HDDVD to even exist as a serious contender in the first place was to kill Java (see MS backing of). Compared to some xml/javascript hackery for HDDVD.
As for Bluray having more space... if that is not a technical advantage then you might as well say regular dvd's with a couple minutes of high def content are 'just as good'. The difference between say 180 and 185 minutes might not be an advantage in the market, but it's still a technical one.
On the other hand, a slight difference in the kernel can have a huge effect on how easy it is for a program to do something, and so how easy to make the OS easier to use. Take for instance file notifications... as in a file window getting notified when files change. Linux kernel has a really backward way to do this called inotify, which replaces an even more backward way called dnotify.
Until recently you could only by default have 8 applications at a time on the entire system getting notifications of files changing -- this has been expanded, but still arbitrarily limiting. Also, each application has to specifically add a 'watch' to every file or folder individually, and folders are not watched recursively. And there's a limit to the number of watches you can have at a time. And this limit is (was) too small to watch all the files on the system. And if you want to watch all the files on a system, or under a root like a home folder, there are race conditions. And because the notification is so limited you have to maintain your own tree of files and folders in order to do something with the events you receive.
Mac OS X and Windows both have much better ways to receive notifications. They don't have arbitrary limits that cause people not to rely on them, they recurse, and the events are far more informative to the application. FreeBSD also has a method that can do all these things. The result is that only a tiny few programs in linux use file notifications, like beagle, and those are glitchy and inefficient.
There are other little differences like this that may not seem like a drastic difference, but make higher level apps much easier. Another related example is going from a file descriptor or inode to a path (ala realpath()). In most cases this requires scanning all folders in Linux. This is something the kernel could do in no time, but it does not provide this capability to applications so if you ever find yourself in that situation you're screwed -- for instance when receiving file change notifications that contain only an inode number.
So there are cases where the kernel has a huge effect on the usability of the system.
To get rid of assembler or C... Obviously you need some asm and possibly C to bootstrap the kernel, and you may need a few lines here and there for broken hardwares. But this is less than 1%, and done once with the port to that arch.
And TLBs, the weird 64 GB RAM ppro extensions to allow more ram on a 32bit CPU, DMA where the hardware needs physical memory addresses, MTRRs and a number of other wonderful limitations. Right now correct cache use is as important as correct swap use was. You can't get rid of an MMU without severely impacting performance. Yes, you can. For instance caching is done with pages in a monolithic OS so it avoids copies, but with a safe OS the object could be shared across multiple processes all using the same physical address (since they don't need to be protected from each other), or each process can be given a 'view'. You don't need TLBs if you don't have virtual addresses, which are not a requirement with a safe os. Since there is only one memory space (kernel + all running code) you can use physical addresses for DMA.
You still want virtual memory since it can make a lot of the os simpler (in contrast to monolithic kernels where it makes them more complicated but is used because it has to be). But an architecture without virtual addressing could run faster and with less power -- if mainstream processors were to be designed that way.
Oh, and your apps will still be written in C -- at least some. So what? In monolithic like linux your apps will still be written in Java -- at least some.
The difference is whether everything suffers from the overhead of memory protection or whether just some of your old-style programs do.
Ok I see your point, but in practice if your code is not typesafe then that means any interface between it any other code (or the OS) is going to be through deep copies, only public fields, and with sanity checks... so basically ints, strings, and maybe some really simple structs like we have now with traditional syscalls. Gross. I know singularity does some kind of copying like that, but I wouldn't say it's a great idea...
Besides, these languages are in a sense simply doing all their work inside a byte[], thus the code is still typesafe -- you have to do the same work to prove 'not doing anything bad' as to prove bounds on an array.
We don't need a microkernel written in any language, especially not C. What we need is a kernel where everything is protected by being typesafe (a 'safe' kernel). Like a kernel written in Java (jxos) or.net (singularity), or limbo (inferno), or maybe D. People forget the original purpose of the "memory management unit" was for swap on mainframes and not for process protection. And anybody who has looked at the mess that is fork, mmap, etc dealing with memory protection in a monolithic system should know it's not good at process protection. It's absurd how much complexity and overhead is caused by this.
A 'safe' kernel sounds slow, because it is probably interpreting bytecodes and has garbage collection. But you get many performance advantages also:
1) idle thread can actually do something, by making programs take less room (compacting gc), offloading some of the work of free(), and optimizing code. So programs respond faster when you switch back to them.
2) lack of data copying. Current systems often copy a *lot* of data from calls to read(2), write(2) and friends, and attempts to reduce this with calls like sendfile or page sharing is very complicated and has a lot of overhead. With a 'safe' kernel you can just give a read-only view, or any number of other very simple methods where no copying takes place.
3) mmu can be used to optimize garbage collection. Only pages written to since the last collection need to be checked for references to new objects, which can improve performance drastically if the instructions inserted to implement a software 'memory barrier' can be removed. It can also help run a gc in parallel since it can easily know if the objects it is looking at have changed during the collection.
4) can eliminate all TLB flushes and stalls from swapping page tables
5) much faster context switch means programs can have smaller time slices, so responsiveness is improved. Meaning less latency in audio (and everything else) without special hacks like magic 'realtime' processes.
6) can run on all hardware, even when lacking memory protection
7) hardware access safer than micro or monolithic kernel, and easier to write drivers
So they obviously are really, really committed to vote fraud in Ohio. If this doesn't work out, could I suggest:
* Voters drop their ballot in the box themselves, instead a poll worker has to 'reset' the voting booth after the voter leaves by taking the vote and dropping it in the box before the next voter uses it.
* Some voters get special "not" votes, where they select all the candidate they DON"T want to vote for rather than the on they DO want to vote for. Which ballot they get can be at the discretion of the poll workers, and look identical.
* Have two sets of boxes to drop votes into, marked "republican" and "democrat". If your vote was not filed in the correct box it doesn't count. Also, the "democrat" box is half the size.
* At closing, the votes are tallied separately by each poll worker. They each write their counts on a piece of paper and drop it in a hat. One is pulled out of the hat and that is the official tally. Then the votes are shredded so they can't be tampered with.... seriously, wtf ohio?
With a typesafe kernel like monotone or jxos everybody has a personal force field bubble around them that nothing crosses, and they just point at stuff outside their bubbles. Also, there are no laws because the force fields keep everybody perfectly safe all the time.
Yet how is a student supposed to know what the JVM is doing if he's never had to scrounge for bytes? If he's never had a practical need for a linked list? If he's never had to implement memory management? If he doesn't have the first clue how to balance a tree? If he can't understand how a garbage collector works? If he doesn't know what a circular reference is? If he can't explain what a pointer is and how a reference is related but different to a pointer? If he doesn't even know what "Turing Complete*" means? Respectfully, I have done all those things. I often write code in low level C (with inline assembly and such). I've even seen the JVM code, but I couldn't tell you the first thing about wtf it is actually doing. The JVM is hard core, and you certainly aren't going to understand it from your 1000-level CS class using C instead of Java.
Slashdot Mirror
That's why you just got the uncontrollable urge to eat brains.
perfect security is impossible, somehow "bringing the fight to the enemy" isn't a solution. Changing the way you think about the internet is. The internet is fine security-wise. Our network organization is fine security-wise. What is not fine is our actual software. There is no reason why software should be hackable. Buffer and heap overflows are not a necessary condition. Kernel bugs do not need to allow arbitrary code to be run. These are fundamental security problems in how we program computers, not in the systems themselves.
For example, programs that are written in Java effectively cannot be hacked due to bugs. Operating system kernels like Singularity or jxos or JavaOS written in typesafe languages cannot be hacked due to any but an extremely small set of possible bugs in them. Bugs can cause these to do things they would otherwise do when they should not, but they effectively cannot be hacked to run arbitrary code. Even a properly designed HTML would not have inline scripts so it would be impossible to run arbitrary code due to not escaping strings (ie scripts could come only after the end of the document and then be referenced by id in the doc instead of appearing inline).
Regardless of whether you are a kernel or application or web developer if you choose to program in C, C++, or any other language where it is possible for bugs to cause arbitrary code to run then you are choosing in your own way to support viruses and spam and security breeches.
If you go to the system preferences and change the keyboard layout options it fixes most of the vmware keyboard problems (like stuck/unusable crtl keys, or any key typed closing the window typed into). In gnome I toggle the 'caps lock is another ctrl key' option.
In computers we have "laws" that we call the "system interface". It can behave predictably and reliably for years under all sorts of conditions, but then once somebody comes along and really starts purposefully really messing with it occasionally something completely unexpected happens. Sometimes the whole system panics even though no theory or math could predict that.
Just because your physics says something 'can't happen' and that the 'exact same stuff' has been going on for eons with no problem does not mean that once you start purposefully messing with it that something bad will not happen. It's just that simple. And if we already knew exactly what was going to happen, we wouldn't need to do the experiments in the first place.
What would make this even more awesome if it came with a windows qemu already set up to run your ubuntu from the virtual disk file with all your installed programs and config while inside Windows. So when you have to dual boot back into windows you can still access your files (although slowly).
It might need to boot into a special image that just mounts from the disk file to keep ubuntu from detecting new hardware and stuff like that. But I think it should be pretty easy to do really.
So... don't burn coal for power and don't use compact fluorescents. When did two wrongs become a right?
Most of your points about physical ballots go away if observers can see the empty ballot box before polls open and watch it all day long until the votes are taken out and counted locally. You know, like in Canada. The kind of system we don't have, since we rig our votes.
/target yourmods /sigh
* You can't pre-stuff the box with your fake votes.
* You can't 'swap the ballot box'.
* You can't add more than one votes without being detected since observers can count how many people vote.
Furthermore your evaluation of electronic voting security is flawed:
* Clearing logs files is easy
* You don't need physical access, your hack can be spread 'by floppy' over time.
* You can't ask a computer to 'md5sum' itself to verify its correctness -- that's as possible as solving the halting problem.
* It is even theoretically possible to alter the specific memory address of the counts using radiation.
...problem of properly implementing electronic voting machines... There is no proper implementation for an electronic voting machine.There can be proper vote printing machines.
There can be proper vote tabulating machines.
But the same device can never do both properly.
The votes must be inspectable by humans between these steps.
EOT.
Until you can take
.function would have to take well over 10k cycles to make it worth attempting on a modern operating system like Linux or Mac Os X.
(1..100).foreach { |e| e.function() }
And turn it into
(1..50).foreach { |e| e.function() }
(50..100).foreach { |e| e.function() }
and these get run on two or more processors faster than it runs on one you'll never get much use out of the extra ones. Our current operating systems can't take a small loop like say 100 iterations and divide it up across processors and have it run faster than just doing it on one. That's the problem. Just a rough guess but I bet
The most benefit from parallel execution is at the really fine-grained level. We already have threads and processes. Threads are really great at doing multiple actions at once... but really bad at speeding up any one particular action. What's needed is some kind of operating system support for running small loops on multiple processors.
Current operating system could run code in parallel if they stop scheduling threads a timeslice on a processor but instead schedule a timeslice across multiple processors. Take an array of 1000 strings and a regex to match them against. If the program is allocated 10 processors it can do a simple interrupt and have them start working on 100 strings each. By having the processors allocated can you avoid the overhead of switching memory spaces and of scheduling, making this kind of fine-grained parallelism feasible.
But the problem here is that most programs will use one or two processors most of the time and all the available processors at other times. And if your parallel operation had to synchronize at some point then you'd have all your other allocated processors doing nothing while waiting for one to finish with its current work. So there is a huge amount of wasted time by allocating a thread to more than one processor.
A solution to the unused processor problem is to have a single memory space, and so as a consequence only run typesafe code -- an operating system like JavaOS or Singularity or JXOS. This lets any processor be interrupted quickly to run any process's code in parallel, so CPU's can be dynamically assigned to different threads. Even small loops can be effectively run across many CPUs, and there is no waste from the heavyweight allocations and clunkiness that is caused ultimately by separate memory spaces needed to protect C-style programs from each other. This is why it is the operating system, not the programming models, that is the main problem.
Most existing code is imperative. Most programmers write in imperative programming languages. Object orientation does not change this. Imperative code is not suited for multiple CPU implementation. Stapling things together with threads and messaging does not change this. Actually it is not really a hard problem at all, but a solution won't magically make every program use every processor with 100% efficiency -- that seems to be the only result that people consider a solution. But what is impossible is solving it with today's operating systems and language implementations.
Modern operating systems just cannot schedule and manage running fragments of code across multiple processors. Suppose you wanted to do a regex match against a list of 10,000 lines across upto 80 processors. First you would have to have created a pool of 80 threads, each locked to a different CPU. Then add some work to them so they each perform a subset of the matches. Then the OS has to switch to each thread, probably involving a tlb flush, and using large time slices since context switching is so costly. So even in the best case with already existing threads you're talking at least a couple thousand cycles and a few time slices lost in overhead per CPU. So this is a net loss in terms of realtime unless the regex is very costly.
Now consider an operating system that gave a program a timeslice across a certain number of processors instead of for each thread on a per-cpu basis. Then the program could do things like run the regex on each line across multiple CPUs, and the overhead would be only say a hundred cycles on each CPU to interrupt what it was currently doing. Now replace regex with some generic closure... this approach would let that closure *also* be able to do work across multiple CPUs, so that if some processors completed their assigned work quickly they would be helping the processors that had harder work assigned to them.
The other part of the solution is to have a typesafe operating system, like Singularity or JXOS or JavaOS. First, running an action across multiple CPUs means memory will be allocated by one CPU and freed by another. Having garbage collection reduces the problem of locking this, since you essentially do a lock once to start/stop gc instead of at every malloc and every free. And much of this work can be done by other CPUs while a program is running in a 'narrow' part that can only be done in order. Also, if every program shares the same memory space then doing a multiple-CPU timeslice has much less overhead, and in fact CPUs can be dynamically redistributed between processes with so little waste that it is practical to do so.
So you see, what you ask is impossible in practice with current operating systems and most C-style programming environments (anything not type safe). But it is possible, and our operating systems and programming will adapt to it, because purely linear execution will not scale. Fundamentally there will be limits on how fast operations can be done in sequence, and practically speaking it will be cheaper to make 80 cores than to make a core 80 times faster.
The description says basically that Windows' MultiByteToWideChar takes invalid UTF8 and unless you specifically tell it not to it allows errors such as expressing 7-bit characters as several bytes (or probably also allowing the longer variations of any character). Valid UTF8 only allows the smallest possible representation of a character. So vmware checks for "..", but the string is really more like "{4 zero bit}.{4 zero bits}." that when converted from utf8 to wide becomes just "..".
So this not likely to affect unix as well, where mbsrtowcs function stops on invalid sequences. In my view Microsoft is more to blame for this defect than the vmware authors since Microsoft created a function that hides input errors by default. The whole reason why UTF8 only allows the minimal representation is entirely to avoid these kinds of ambiguities and errors.
In terms of programming, a function passed a set of coins can observe their values (ie coin.value()) and keep track of the number of times it sees each combination -- this is your 2^N. The function can even test each coin to see if some of them are actually the same coin, but this still doesn't necessarily tell them what value each will be. For example, if coin.value() adds one to the value then you could come up with all sorts of weird conjoined or *impossible* outcomes, like having all the coins be 0. Or you could have all the coins give the same value, or any other weird quantum effect you allude to.
In other words, what you are describing is yet another aspect of quantum mechanics that makes more sense when thought of as a simulation.
You joke, but consider if the universe were a simulation -- quantum mechanics makes a lot more sense in term of a simulation. Things like spooky action at a distance become lazy evaluation. Quanta become memory locations, variables. And so on. Quantum mechanics is easy to simulate.
But how does one simulate gravity? It has to propagate in every direction at the something like speed of light or else -- god forbid -- information could travel faster than light. The whole concept of gravity, that every individual particle affects however slightly every other particle, is not possible to compute directly.
Now suppose the universe were simulated as a sparse matrix. Each cell could contain a gravity component that stored the aggregate gravity force from each of a certain number of directions (perhaps expressed as several point masses). Depending on the number of directions this would give highly accurate simulation at a small scale, where error is absorbed as noise, while being computable for the overall universe as a whole. However the error would magnify over great distances due to 'floating point' type errors accumulating.
What if what these people are seeing as dark matter is not matter at all, but simulation error. Perhaps even dark matter is related to a sparse simulation of the universe where intervening space is approximated by invisible masses that gravity affects but nothing else does. These mass would act to consolidate cells in the matrix to reduce the overall memory requirements.
Compare Core 2 e6550 conroe to Athlon x2 5000+ brisbane. Both are 65nm and have mostly the same power and heat. The core 2 is ~5%-20% faster in benchmarks (see tom's) but costs 80% more. Or compare phenom to extreme... extreme is no more than twice as fast but costs four times the amount.
I don't know if AMD can keep it up but they are by far the most cost effective CPUs at the moment and historically.
1. Bluray discs have menus, usually done with standardized scripts running on top of Java.
2. Content that looks good > content that may crash sometimes
3. Java > assembly for a consumer product
So many fanboys.
As for Bluray having more space... if that is not a technical advantage then you might as well say regular dvd's with a couple minutes of high def content are 'just as good'. The difference between say 180 and 185 minutes might not be an advantage in the market, but it's still a technical one.
On the other hand, a slight difference in the kernel can have a huge effect on how easy it is for a program to do something, and so how easy to make the OS easier to use. Take for instance file notifications... as in a file window getting notified when files change. Linux kernel has a really backward way to do this called inotify, which replaces an even more backward way called dnotify.
Until recently you could only by default have 8 applications at a time on the entire system getting notifications of files changing -- this has been expanded, but still arbitrarily limiting. Also, each application has to specifically add a 'watch' to every file or folder individually, and folders are not watched recursively. And there's a limit to the number of watches you can have at a time. And this limit is (was) too small to watch all the files on the system. And if you want to watch all the files on a system, or under a root like a home folder, there are race conditions. And because the notification is so limited you have to maintain your own tree of files and folders in order to do something with the events you receive.
Mac OS X and Windows both have much better ways to receive notifications. They don't have arbitrary limits that cause people not to rely on them, they recurse, and the events are far more informative to the application. FreeBSD also has a method that can do all these things. The result is that only a tiny few programs in linux use file notifications, like beagle, and those are glitchy and inefficient.
There are other little differences like this that may not seem like a drastic difference, but make higher level apps much easier. Another related example is going from a file descriptor or inode to a path (ala realpath()). In most cases this requires scanning all folders in Linux. This is something the kernel could do in no time, but it does not provide this capability to applications so if you ever find yourself in that situation you're screwed -- for instance when receiving file change notifications that contain only an inode number.
So there are cases where the kernel has a huge effect on the usability of the system.
You still want virtual memory since it can make a lot of the os simpler (in contrast to monolithic kernels where it makes them more complicated but is used because it has to be). But an architecture without virtual addressing could run faster and with less power -- if mainstream processors were to be designed that way. Oh, and your apps will still be written in C -- at least some. So what? In monolithic like linux your apps will still be written in Java -- at least some.
The difference is whether everything suffers from the overhead of memory protection or whether just some of your old-style programs do.
Ok I see your point, but in practice if your code is not typesafe then that means any interface between it any other code (or the OS) is going to be through deep copies, only public fields, and with sanity checks... so basically ints, strings, and maybe some really simple structs like we have now with traditional syscalls. Gross. I know singularity does some kind of copying like that, but I wouldn't say it's a great idea...
Besides, these languages are in a sense simply doing all their work inside a byte[], thus the code is still typesafe -- you have to do the same work to prove 'not doing anything bad' as to prove bounds on an array.
We don't need a microkernel written in any language, especially not C. What we need is a kernel where everything is protected by being typesafe (a 'safe' kernel). Like a kernel written in Java (jxos) or .net (singularity), or limbo (inferno), or maybe D. People forget the original purpose of the "memory management unit" was for swap on mainframes and not for process protection. And anybody who has looked at the mess that is fork, mmap, etc dealing with memory protection in a monolithic system should know it's not good at process protection. It's absurd how much complexity and overhead is caused by this.
... and so on.
A 'safe' kernel sounds slow, because it is probably interpreting bytecodes and has garbage collection. But you get many performance advantages also:
1) idle thread can actually do something, by making programs take less room (compacting gc), offloading some of the work of free(), and optimizing code. So programs respond faster when you switch back to them.
2) lack of data copying. Current systems often copy a *lot* of data from calls to read(2), write(2) and friends, and attempts to reduce this with calls like sendfile or page sharing is very complicated and has a lot of overhead. With a 'safe' kernel you can just give a read-only view, or any number of other very simple methods where no copying takes place.
3) mmu can be used to optimize garbage collection. Only pages written to since the last collection need to be checked for references to new objects, which can improve performance drastically if the instructions inserted to implement a software 'memory barrier' can be removed. It can also help run a gc in parallel since it can easily know if the objects it is looking at have changed during the collection.
4) can eliminate all TLB flushes and stalls from swapping page tables
5) much faster context switch means programs can have smaller time slices, so responsiveness is improved. Meaning less latency in audio (and everything else) without special hacks like magic 'realtime' processes.
6) can run on all hardware, even when lacking memory protection
7) hardware access safer than micro or monolithic kernel, and easier to write drivers
So they obviously are really, really committed to vote fraud in Ohio. If this doesn't work out, could I suggest:
... seriously, wtf ohio?
* Voters drop their ballot in the box themselves, instead a poll worker has to 'reset' the voting booth after the voter leaves by taking the vote and dropping it in the box before the next voter uses it.
* Some voters get special "not" votes, where they select all the candidate they DON"T want to vote for rather than the on they DO want to vote for. Which ballot they get can be at the discretion of the poll workers, and look identical.
* Have two sets of boxes to drop votes into, marked "republican" and "democrat". If your vote was not filed in the correct box it doesn't count. Also, the "democrat" box is half the size.
* At closing, the votes are tallied separately by each poll worker. They each write their counts on a piece of paper and drop it in a hat. One is pulled out of the hat and that is the official tally. Then the votes are shredded so they can't be tampered with.
With a typesafe kernel like monotone or jxos everybody has a personal force field bubble around them that nothing crosses, and they just point at stuff outside their bubbles. Also, there are no laws because the force fields keep everybody perfectly safe all the time.
When the system started there was the v00d.
Then the User created 1 and there was l1ght
And it was g00d.
TRON 11:01