Except they don't write data straight to disk. They write to an OS-controlled buffer. Their code only forces the buffer to be passed to the OS for it to do with as it pleases.
Except they don't write to disk. They wrote to an OS controlled buffer. Simply calling flush does not force a disk write. It signals the OS to take control of the buffer.
Except everyone alreadys know that using that method of string concatenation is slow. This paper was just pages of waste for what is a one sentence guideline: "Use Stringbuilder to more efficiently do string concatenation." But any compentent Java programmer already knows that.
Except any half-decent Java developer uses Stringbuilder not + concat because everyone knows the latter is slower and causes more to be objects created. The only thing they proved is by purposefully doing something wrong you can make it crappy.
Flush in Java doesn't actually force the OS to write to disk.
If the intended destination of this stream is an abstraction provided by the underlying operating system, for example a file, then flushing the stream guarantees only that bytes previously written to the stream are passed to the operating system for writing; it does not guarantee that they are actually written to a physical device such as a disk drive.
It's even more simple than that. Their "writes to disk" are just being stored in disk cache hence the "faster" speed. On the other hand, they do basically the most inefficient in-memory operations possible.
"This was probably overkill, but I’m a perfectionist when it comes to these things. The subtitles in the driver's license seal were no match for Photoshop's 'content aware and replace' feature. It wasn't perfect, so the majority of my time was spent pushing pixels until it looked right. A little blur and grain go a long way to making something look authentic," Mr. Troia said.
No, it's not. As I explained to you above, the origin of "herstory" was based on the flawed etymology of thinking "history" came from the combination of "his" and "story". Hence why they coined the term "herstory".
Slashdot Mirror
Unless you're implying the editurs are idiots
No need to imply anything. That's already long-established fact.
You know, I would argue that saying "everyone knows" is overly optimistic, bordering on naive.
As would I which is why I never used that phrase. Your quote is not my words.
Except they don't write data straight to disk. They write to an OS-controlled buffer. Their code only forces the buffer to be passed to the OS for it to do with as it pleases.
Except they don't write to disk. They wrote to an OS controlled buffer. Simply calling flush does not force a disk write. It signals the OS to take control of the buffer.
Except everyone alreadys know that using that method of string concatenation is slow. This paper was just pages of waste for what is a one sentence guideline: "Use Stringbuilder to more efficiently do string concatenation." But any compentent Java programmer already knows that.
But they didn't do direct disk write. They merely flushed to disk cache handled by the OS.
Except any half-decent Java developer uses Stringbuilder not + concat because everyone knows the latter is slower and causes more to be objects created. The only thing they proved is by purposefully doing something wrong you can make it crappy.
Flush in Java doesn't actually force the OS to write to disk.
If the intended destination of this stream is an abstraction provided by the underlying operating system, for example a file, then flushing the stream guarantees only that bytes previously written to the stream are passed to the operating system for writing; it does not guarantee that they are actually written to a physical device such as a disk drive.
It's on arXiv so probably not yet. Hopefully it gets sufficiently mocked.
It's even more simple than that. Their "writes to disk" are just being stored in disk cache hence the "faster" speed. On the other hand, they do basically the most inefficient in-memory operations possible.
Pretty much. This entire article is basically saying that if you do things in the most stupid way possible you can make it slow.
Why bother? Their entire "research" is bogus. Everyone knows that buffered writes are going to be faster than doing byte-by-byte writes.
Even the slowest DDR3 SDRAM has more memory bandwidth and magnitudes faster access time.
So it's okay to use your large marketshare to be anti-competitive as long as your Google?
No, more like purposefully underfunded and understaffed agency can't afford enforcement against megacorps.
I did read the article. The guy worked with someone else to get access to his own account.
The Slashdot effect is pretty weak these days. It's just a poorly configured webserver.
Yes, they are sure.
"This was probably overkill, but I’m a perfectionist when it comes to these things. The subtitles in the driver's license seal were no match for Photoshop's 'content aware and replace' feature. It wasn't perfect, so the majority of my time was spent pushing pixels until it looked right. A little blur and grain go a long way to making something look authentic," Mr. Troia said.
Wow, guy who owns the account managed to get access... to his own account. Wow, what a great story, bro.
Maybe Linux Voice needs to learn to engineer a working database?
No, it's not. As I explained to you above, the origin of "herstory" was based on the flawed etymology of thinking "history" came from the combination of "his" and "story". Hence why they coined the term "herstory".
*crickets*
Of course they were wrong, but not for what you say. 'History' was not made from the words "his" and "story".
Microsoft afraid of the YOTLD?
Nah, couldn't be.
Maybe in some alternate universe, but certainly not in this one.
I don't buy prebuilts but any manufacturer that locks secureboot will no longer be recommended to any of my non-tech-savvy friends.
So they'll lose what? 2 whole sales out of 10s of millions?
You would be wrong. The coiners of the neologism called it "herstory".