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.
Unix mailbox format is the most widely supported format and has the convenience of single file. But it has a terrible design and corrupts messages due to the stupid message delimiter used.
Maildir has nice parallelism for POP/SMTP-only access, but is a poor choice for IMAP.
The Cyrus mailbox format used by the Cyrus IMAP server is the best open-source format for IMAP or mixed IMAP/POP/SMTP access.
X.509 is a digital certificate standard from ISO. ISO is a government oriented bureaucratic standards organization. As a result, X.509 certificates are vastly more complex than and anyone interested in doing a security review of the source code has to purchase the standard. In addition, the trust model forces users to trust a hierarchy which they have no reason to trust in most cases. Netscape has awkward, but functional support for X.509 certificates, including the S/MIME standard which uses them to sign/encrypt email.
PGP has a much simpler format and a default trust model which is much more secure. Unfortunately, the default PGP trust model generally requires a user to manually set up a trust relationship with every other individual. As a result the average person finds S/MIME much easier to use and that's what companies deploy. PGP seems to be relegated to techno-geeks, the paranoid, and people who really need strong security and got good advice.
A good module API is far simpler to design than a good object model (although neither is easy) and provides more potential for code re-use since it can be in a more portable programming language. Given the lack of good programmers with real-world experience, it's foolish to use OOP techniques unless there's a very strong need for the paradigm.
The article is a bit weak, although the list of myths at the start is good. I also liked the observation that grouping procedures with data in OOPS tables is a bad idea. Seems a lot like grouping web page logic and source in the same file -- something experienced web designers know is almost always a bad idea.
I recently hosted a small room party at a science fiction convention. To prepare, I took a bunch of CDs that I legally purchased and copied the music onto my laptop so I could play background music unattended. Doing this with DVD videos, something I'd like to do, would be illegal thanks to the DCMA.
When a person is so intent on making money that they harm others or harm society, we call that person a bad person. The same should apply to corporations. Corporations are part of society and when they put profits above all else, they are bad. Microsoft has set the computer industry back several years by leveraging a near monopoly to push innovators out of business, rather than competing honorably on the basis of quality and service.
User complaints, interoperability testing, compliance testing, conscientious developers (aka "standards weenies"), and validation utilities can all help enforce standards to some degree. But ultimately it's the most widely deployed software that determines the standards. If the most widely deployed software accepts non-compliant syntax without complaint, that almost guarantees that non-compliant software will eventually be deployed (usually because of developer ignorance or a simple bug). So if you're creating a new standard and don't want it to creep away from the spec in practice, release a quality open-source implementation which complains about every spec violation you can imagine. Also make sure your spec never says or implies "implementation defined" unless you're sure it can't be abused.
Slashdot Mirror
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.
Maildir has nice parallelism for POP/SMTP-only access, but is a poor choice for IMAP.
The Cyrus mailbox format used by the Cyrus IMAP server is the best open-source format for IMAP or mixed IMAP/POP/SMTP access.
PGP has a much simpler format and a default trust model which is much more secure. Unfortunately, the default PGP trust model generally requires a user to manually set up a trust relationship with every other individual. As a result the average person finds S/MIME much easier to use and that's what companies deploy. PGP seems to be relegated to techno-geeks, the paranoid, and people who really need strong security and got good advice.
A good module API is far simpler to design than a good object model (although neither is easy) and provides more potential for code re-use since it can be in a more portable programming language. Given the lack of good programmers with real-world experience, it's foolish to use OOP techniques unless there's a very strong need for the paradigm. The article is a bit weak, although the list of myths at the start is good. I also liked the observation that grouping procedures with data in OOPS tables is a bad idea. Seems a lot like grouping web page logic and source in the same file -- something experienced web designers know is almost always a bad idea.
I recently hosted a small room party at a science fiction convention. To prepare, I took a bunch of CDs that I legally purchased and copied the music onto my laptop so I could play background music unattended. Doing this with DVD videos, something I'd like to do, would be illegal thanks to the DCMA.
When a person is so intent on making money that they harm others or harm society, we call that person a bad person. The same should apply to corporations. Corporations are part of society and when they put profits above all else, they are bad. Microsoft has set the computer industry back several years by leveraging a near monopoly to push innovators out of business, rather than competing honorably on the basis of quality and service.
User complaints, interoperability testing, compliance testing, conscientious developers (aka "standards weenies"), and validation utilities can all help enforce standards to some degree. But ultimately it's the most widely deployed software that determines the standards. If the most widely deployed software accepts non-compliant syntax without complaint, that almost guarantees that non-compliant software will eventually be deployed (usually because of developer ignorance or a simple bug). So if you're creating a new standard and don't want it to creep away from the spec in practice, release a quality open-source implementation which complains about every spec violation you can imagine. Also make sure your spec never says or implies "implementation defined" unless you're sure it can't be abused.