bigfoot

That was my position too, but I was recently told there's a tool called waypipe that is supposed to solve this. Haven't tried it yet, though.

Related Twitter discussion: https://twitter.com/taviso/status/1250518818197245953

Exactly: "spare" is the imperative ("save!"), "sparen" the base form ("to save").

But don't get me wrong, I'd love to see your optimism come true here.

No. For simple economic reasons, such as too much testing effort vs. too little revenue.

The saddest part of this story is that Netflix/Amazon/younameit will continue to ignore and block Linux users as the niche market they are -- even if a future Firefox or Chrome version comes with the new standardized DRM everyone asked for. Lose/lose situation.

Given that a NSA dev team was well aware that the spyware would be discovered and disassembled at some point in time, it was reasonable to intentionally leave behind evidence that points to countries other than the US. I'm not saying that's what happened, but I'd not take the cricket references too serious either.

OK, agreed. C (and C++) just suck regarding this detail.

Archaic and impractical. Example: Instead of using Linux' pragmatic approach to function prototypes:

"In function prototypes, include parameter names with their data types. Although this is not required by the C language, it is preferred in Linux because it is a simple way to add valuable information for the reader."

OpenBSD enforces this:

"Prototypes should not have variable names associated with the types; i.e., void function(int); not: void function(int a);"

Instead of letting the code tell the parameters' purposes, this now has to be deduced from informal descriptions, or the function definition in some .c file.

Under what license may I reuse those snippets -- or are they too short to provoke legal issues anyways?

Quoting from the end of the paper:

"Source code and a phase diagram generating Python script are available under the M.I.T. license on github.com at https://github.com/mattbierbaum/moshpits . An interactive Javascript version of the simulation is available at http://mattbierbaum.github.com/moshpits.js ."

C++'s template-based sorting mechanisms allow for the same optimization without manually special-casing anything. (The compiler "integrates everything", to quote the author, out of the box.) C++ port of Postgresql, anyone?

Nice. Please add more GCC versions (3.x and 4.0 through 4.3?) and the most recent clang/clang++ releases! Direct pastebin-style links would also be great.

You're being overly pessimistic on the percentage of Europeans speaking English (though not necessarily as their native language). This language has worked as a common means to communicate for a long time and definitely won't leave this web site end up being "UK/US centric".

With that argument you could invalidate any high-level language construct. They're all just "specialized syntax" of classic idioms in Assembly.

I agree on Bjarne's opinion here -- it would be nice if C and C++ had merged at some point.

Unfortunately, the reason why this hasn't happened is inherent: C++ is so utterly complex (the C++11 standard contains more than 1300 pages of highly compressed language legalese) that especially in the embedded systems domain many vendors just don't have the time and resources to build a C++ compiler. And being caught in this vicious circle, embedded developers still aren't (and probably won't be for still quite some time) accustomed to programming at higher abstraction levels than what C offers. This also allows myths like C++ being too inefficient for embedded systems programming to live on in industry.

For stationary setups, this is for the first time a real win for touchscreens in comparison to a conventional screen plus a pointing device (mouse, trackball, you name it). I'm really curious what they'll make out of this.

"As for Unity; its incomplete, buggy and complicated." -- four lines later: "The non geek will love Unity. Its simple to use [...]". The author fails to be consistent even in a single paragraph. Even the post's title contradicts its content.

The 90ies called, they want their tiled backgrounds back.

Depends on the publication date. A paper due to be published in December 2011 is not yet downloadable for obvious reasons.

PS: Sorry, YC disallows me from editing the title at this point of time. If anyone reading this has the administrative powers to do that, please go ahead.

I indeed edited the title very shortly after posting; I changed "Gparted" into "GParted". I was unaware this would pose a problem.

About the scare quotes: I agree, I should've posted this in an unbiased way. I will change the title in a second to what you suggested.

Unfortunately, as I understand it, the tools accompanying libguestfs aren't capable of resizing a file system in-place -- a major downside compared to what libparted could do, as you don't necessarily have a spare hard disk in your servers.

Because the only thing I knew up to now was: a) libparted moved to v3.0 and removed lots of filesystem specific code, and b) as a consequence, gparted cannot deal with lots of filesystems anymore since v0.9.0 (when linked to libparted 3.0).

These are the facts available to me, I wasn't trying to bait anyone. I found it of common interest that in a year or so, when these parted/gparted versions arrive in the major distributions, you won't be able to do certain things with GParted you used to do, like resizing a FAT32 partition.

I fully agree. Hopefully libguestfs support will be added to GParted soon; as changing the partition layout and resizing the file systems within these partitions is usually a hand-in-hand process, it should be controllable from a single tool.

I don't get why these libparted features were "deprecated" when their removal leads to GParted 0.9.0 effectively dropping FAT16/FAT32 and HFS(+) support.

I doubt any reasonable percentage of YC readers speaks Malaysian.

"Every best paper from CS conferences" does not really sound like what this site does -- list best papers from 11 CS conferences, a marginal fraction of how many CS conferences are out there.

Any countermeasures, besides not using a kernel supporting the Econet protocol? I.e., does there exist a fix for the first CVE addressed in the exploit's comment?

It's probably a good idea to concentrate maintenance efforts on fewer kernel trees. There should probably be some kind of synchronization going on, i.e. declaring a new "stable" kernel when there are enough major Linux distros currently basing on it.