There's nothing better for turning you into a nervous wreck than knowing that your every word and motion are going to be dissected with the goal of disqualifying you...

Probably the most common cause of depression is subclinical hypothyroidism, specifically with low T3. One psychiatrist found that he could cure 90% of his patients by prescribing T3 to bring their active thyroid hormone level up to normal. (Prescribing T4 alone didn't work, probably because poor T4-to-T3 conversion is part of the problem here.)

Really? My mobile phone has a 64Gb SSD in it which is enough for several hours of video even in HD. It's significantly smaller than the tape storage devices that were used in CVRs until recently.

The pilot murdered more than a hundred people by deliberately flying a plane into the ground.

There's not much character left to assassinate.

Aircraft have two blackboxes: the cockpit voice recorder (CVR) and the flight data recorder (FDR). The former records audio in the cockpit and the latter records data from various instruments and controls. In this case, they have found the CVR but not the FDR.

Then it needs to be part of the qualifying exam, not external to that. If it's part of the exam, then it's obviously not going to be secret from the pilot examiners.

(Actually, I thought this was how it is already, at least in the U.S.)

It's only those damn Russians are doing this, all other countries are saint.

Yeah, because that makes it all OK then.

Your comment is designed to distract from the issue at hand, shut down intelligent conversation on the topic, and imply the wrongdoer is just fine because, by implication, "everybody else does it, too" (no evidence to said implication provided, certainly not proven, and probably not true), all without contributing a single creative or new thought to the discussion at all.

Nice job, (Russian?) troll.

You didn't read their paper properly. They make exactly the point that you are making. i.e. that "writing to disk", in most cases, does not mean physically writing individual bytes to the disk. The abstractions provided by both the language and the operating system help to make the obvious implementation as fast or faster than naive programmer created optimisations. In other words, this is a confirmation of the saying

There is a WTF in the paper and it is their claim that Python doesn't run in a VM.

Until systemd is removed from a major Linux distro, I would consider that distro to be less secure than even a Windows system.

Some Poettering apologist will probably mark you as a troll, but for completeness there are a number of distros that default to non-systemd init architectures, including but not limited to

Calculate, Gentoo, Funtoo, Source Mage, Dyson, indeed all kinds of distros either default or support running a systemd-free system.

This weekend I saw a guy apparently picnicking across the road from my house. After a while I went over to see WTF, and turns out he was working for a mapping company (and the company drone was flying overhead, snapping photos). He told me that their maps are accurate to within 1/8th inch.

malloc isn't the problem, though. My point was that if you write it in the style of the code in the paper (don't keep track of the string length between character appends) then it'll still have to scan the string a million times. If you know ahead of time that you're going to append exactly one million characters to the string then you need but one malloc, right? I can make this program extremely fast in that manner but that's not what they're doing.

... hm... my next home purchase might just have to have a conditional clause that if I can't get broadband, the deal is off...

You know, like how you can back out once you get an appraisal and learn that there are termites.

Well, yeah, but that's not going to work consistently. Worst case is if the string is on the stack you'll smash the stack and likely have a memory access error. If it's on the heap you'll likely get the error quicker.

I wouldn't even think of writing a program in the manner in which their sample was written, but if I was trying to solve their basic "problem" there are better ways to go about it.

I just reviewed it, but frankly, they're not my peers.

They actually understand the problem and state it near the end of the paper. The issue is pretty simple and when I read the /. summary I knew what the problem was. They're appending single bytes to a string. In both chosen languages - Java and Python - strings are immutable so the "concatenation" is way the hell more complex than simply sticking a byte in a memory location. What it involves is creating a new string object to hold both strings together. So, there's the overhead of object creation, memory copying, etc. Yes, by the time you're done it's a lot of extra work for the CPU.

I'm going to state this as nicely as I can: what they proved is that a complete moron can write code so stupidly that a modern CPU and RAM access can be slowed down to the extent that even disk access is faster. That's it.

Even if you wrote this in C in the style in which they did it the program would be slow. Since there's no way to "extend" a C string, it would require determining the length of the current string (which involves scanning the string for a null byte), malloc'ing a new buffer with one more byte, copying the old string and then adding the new character and new null byte. Scanning and copying are both going to require an operation for each byte (yeah, it could be optimized to take advantage of the computer's word length) on each iteration, with that byte count growing by "1" each time.

The sum of all integers up to N is N(N+1)/2. If N is 1,000,000 the sum is 500,000,500,000. So, counting bytes (looking for null) requires half a trillion operations and copying bytes requires another half trillion operations. Note that "operations" is multiple machine instructions for purposes of this discussion.

Yeah, modern computers are fast, but when you start throwing around a trillion operations it's going to take some time.

Writing to disk will be faster for a number of reasons, mainly because the OS is going to buffer the writes (and know the length of the buffer) and handle it much much better. It's not doing a disk operation every time they do a write. If they were to flush to disk every time they would still be waiting for it to finish.

There are a few notes, here. First, in Java and Python the string object likely holds a "length" value along with the actual character buffer. That would make it faster and not require all the operations the badly written C code that I describe above would require. But the overhead of objects, JVM, interpreter, etc. gets thrown into the mix. Second, if I were doing something like this in C I could keep the string length as part of a struct and at least make it that much faster. The point is that a good programmer wouldn't write code in this manner.

Anyway, this "paper" proves nothing except that really bad code will always suck. One would have to be an idiot to write anything close to what they've done here in a real-life scenario. I know because I've cleaned up other people's code that's on the level of this junk...