You may not be able to just take any program and prove that it works, but you can construct a program of your own in a way that it is possible to prove that it works; actually what you do is the proof and then in best-case scenario extract the machine code from that.
Of course, doing this is still very costly: 7500 lines of C-code can take 200000 lines of Isabelle proof code:
Indeed the article says 1.9 and 2.0 will be compatible. Yet there will eventually be 2.1, 2.2, and now you're stuck with 1.9 and 2.0, unless those new versions also don't introduce anything that 1.9 doesn't support or unless you're willing to consider the differences and support both in some way. Will 2.x series involve pure optimizations only? A gap will be introduced, and it won't likely take that long either.
What's the point in using 2.0 in the first place if 1.9 will do? Obviously 2.0 will have some functionality or fixes 1.9 won't. If you really want to do what you suggest, you would still have two code paths in your system, one for 2.0 and one for 1.9 (or possibly one for 2.0 and then gracefully degrade when there is no 2.0).
And even if the machines in question were backed up, don't typical rootkits (which I'm not saying Flame is) hide themselves from the filesystem in certain situations? Could be that the backups have no trace of Flame.
Well, neither libpcap nor tcpdump can do it either, they don't come with the network drivers. They are libraries/tools to access that functionality in the kernel.
And how easy is it for extension writers to ensure that they are not holding too many or too old references to objects in their code?
Given how popular it is to say Firefox consumes a lot of memory, I cannot quiet see how the Mozilla Foundation hasn't found time or will to, for example, write a tool that will track the memory usage per extension. Shouldn't be that hard, just keep track which extension created each object and then use GC to find out the number of bytes reachable from those objects. At the cost of some memory
My 'solution' to the problem is use use ulimit -v 2000000 before Firefox and start it when it dies.
Apparently I'm one of those running Firefox with little RAM, measly 6 gigabytes of it. But it still annoys the hell out of me when Firefox takes more than 4 gigabytes of memory.
Yes, I never shut down Firefox unless it dies or takes all the memory. Yes, it's probably some extension. No, there isn't a good way to track it down other than divide-and-conquer which is manual labor.
While that may be true, would having the keys of all existing iPhone devices be a sample large enough? Or maybe you could link to research that can successfully predict the keys OpenSSL generates. No, Debian OpenSSL doesn't count..
Well, here's a pro-tip that enhanced my GIMP experience tremendously: try the tab key!
This will help, but from the security POV, only the devices which have not been rooted; after that, incoming firmwares could be intercepted and applied either not at all or only partially.
I suppose they could have sign the firmware for the boot loader to check, but given the root password 'newsys', this doen't seem to go with their style..
"LulzSec" already earned waiting spots in prison with what they've already done. Not doing anymore doesn't constitute "take back".
Sure, but stopping the attacks is a good way to reduce the risk of getting caught in the future, if they aren't caught yet.
Yes, I also prefer self-checkouts.
However, should they ever choose to replace all checkouts with self-checkouts, I very much suspect that the time savings (for clients) would be gone, because it only needs a few people per checkout to stall the queue.
You know, there are other costs involved than just manufacturing the chip. For example recouping the R&D costs. I would be very surprised if the price difference between dual-core and quad-core CPU's reflected the difference between the manufacturing costs of those two.
Until we get superconducting interconnections, there will be massive efficiency losses.
Perhaps advancements in superconductivity is what will finally kick green power sources into a gear?
Internally it encodes the keyboard as MIDI and then again decodes them in the synthesizer. So basically the portable synthesizer you want is a subproject of this. I guess he figured he might want to use the synthesizer separately at times (much more portable).
Say "twenty-three-skiddoo" to logout.
