|
|
And how does a single node effortlessly simulate the data propagation delays that are inevitable in a distributed system? Do you have a solution that involves work less than the worth of $1000? (Well, I suppose building up the RPi cluster took some time as well..)
It would be a more general solution if such software was written, but I wouldn't say cheaper.
I'm not sure what you expect to win by porting FreeDOS to RPi. RPi doesn't run in 16-bit mode, and certainly it won't run x86 executables in any sense, so even if you ported FreeDOS to RPi, you would have no ARM-based DOS-software to along with it, unless you ported them as well.
It gives them the possibility of giving a cash discount up to 4%, but it is not free either to deal with lots of cash. Someone will count them, someone will transfer them securely into bank, and surely the bank will charge for dealing with that kinds of amounts as well. In addition you probably will get new paper money from the bank.
No idea how many % these count up to, though.
The display seems pretty large. Does this mean we are finally going to get proper devices for reading PDFs?
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.
Someday your prints will come. -- Kodak