Fact-checking experts will appear partisan in today's political climate where one party lies much more than the other party does. Unfortunately, a popularity contest simply won't be able to distinguish what is factual and what is a false propaganda. Partisans (on both sides) will consider truthful anything that reinforces their distorted world-views or tribalism. Human brains are not good at distinguishing truth from falsehood without extensive training and practice; just think about why social engineering, magic shows, and scams are so effective.

It would be a great service to Facebook users if fact-checking expertise was available for widely forwarded political links, but I'd prefer it's visual only (not impacting the algorithm) unless the user opts-in to a higher-fact-check feed.

The treason law under which Mr. Snowden would be charged fails to consider motive and is thus a completely unjust law. Imagine committing manslaughter and being changed with first degree murder and having no legal standing to argue motive? I believe Mr. Snowden has committed a crime of treason and should either do short jail time or a suspended sentence. But his motive was to strengthen the United States, and I believe that was also the majority effect of his actions due to both his intent and his responsible handling of the data.

The biggest IETF problem I see is not enough active participation. Specifically, engineers who want the work to complete and are editing specifications, commenting based on their implementations or running working groups efficiently. Ever since the dot-com bubble burst there haven't been enough people doing that from either academic or corporate origins. Good engineers can come from either source, but unless enough engineers have the time to actually work to produce standards, the standards won't happen.

Under Sun Microsystems, a company that was having a hard time making a profit, open source projects fared badly. Staff were cut across the company, including administrative, QA and lab support staff. When all the support staff go, the software developers gets loaded down with all that extra non-development work and they'll eventually leave too, no matter how "nice" or "friendly" the company is to open source. An attitude like "let's open source now and figure out how to make money later" is a recipe for failure.

Under Oracle, things may or may not fare better. It depends if Oracle can come up with a way to make money off of support, services and add-ons for open source. If they do, then they'll continue to invest and the OSS will do well (as it did with Oracle's acquisition of Sleepycat / Berkeley DB). If they don't, then the project may not fare well (as some claim happened with InnoDB). I know some OSS fans find a way to get a foundation or edu paycheck, but those are few and far between. I like a corporate paycheck and that means there has to be a way to make money from OSS or I won't get paid to work on it. There is ample proof that OSS development can be profitable as RedHat shows, but there needs to be a business plan to pay for ongoing development.

Frankly, I'm more concerned by the loss of key Mozilla NSS developer time due to the Oracle acquisition than I am concerned about MySQL's future. Any ideas on a business plan to make money from NSS out there?

As an application programmer, one of the more common filesystem operations I want to do is "replace this file atomically; and feel free to delay commit of the replace for power/performance reasons as long as it happens atomically." The POSIX API provides no documented way to express this, so a common POSIX call sequence is used to express this semantic (write-new-file, rename on top of old-file).

The problem is that EXT4 now interprets that common calling sequence which traditionally has useful semantics on most filesystems in a way that is both useless and harmful to data integrity. And furthermore it leaves application programmers no way to express the "atomic replace defer ok" semantics. So in pursuit of filesystem performance EXT4 has broken a performance-optimizing semantic. If applications are changed to fsync when it's completely unnecessary (only sequence preservation is needed), we will all pay the performance cost.

So EXT4 may comply with POSIX, but it does so in a way that is harmful to overall system performance, harmful to data integrity and harmful to performance optimization of application file operations.

As an application developer highly concerned with optimal performance, my response will be to refuse to support EXT4, and to discourage use of EXT4+workaround as it has suboptimal performance. The correct fix is to make EXT4 guarantee to commit the rename after the data write operations, but for performance, it should delay both commits until the next flush interval. If I replace the same file twice within a flush interval, I'd prefer the intermediate version never be written to disk.

Until an "atomic replace" operation is added to POSIX, I want the filesystem to interpret that common sequence of calls with the sensible and rational interpretation.