(cmake is probably the best, since it's more portable than autoconf).
As a user of autoconfed packages, I find autoconf superior to cmake. Packages built with autoconf have standardized mechanisms for uninstallation (a cmake package may generate an install-manifest file, an uninstall target, or none of the two), to specify where to put documentation, for cross-compilation, and to fine-tune the build and the installation. With cmake, I can't even tell the package where to install libraries (most packages will allow you to do it, but each package has a different standard about the way to be told); with autoconf, I can even specify a sed to be run on the name of the installed binaries (useful if different packages provide different implementations of the same binary) and still have the installed package work. Also, with cmake packages building both static and dynamic libraries at the same time is usually impossible.
Moreover, modern autoconf scripts are (relatively) easy to debug and patch when they don't work; cmake scripts are more scattered and they're written in an obscure mainframish language.
That said, I imagine that using autoconf on non-posix systems might be less funny.
But in this case, well, Apple does something wrong (not even remotely comparable to the trainwreck that Microsoft did with Metro, I'll concede) that devalues the largest part of its already expensive product line, with the exception of the most expensive products, and without adding any value to those either, but Apple fan are happy nonetheless because... it's good to be shown how Apple does not care about who doesn't spend the most?
What is this, an exercise of asceticism in the path of the true Apple worship?
From reading the linked discussion (before people started having shitfits), a dev suggested removing extFS support as "an unnecessary feature"
A dev announced that extFS support had been removed in beta. To people protesting, they replied that the feature was going away full stop. They even modified the ChromeOS feature page stating that ChromeOS had ext support.
because of theoretical security issues
Because of FUD. Stating that supporting the ext file system poses a security issue is FUD: it is FUD by definition, and it is FUD in particular because ext is massively used in security-critical contexts including Google's servers and Google's Android operating system. Why, ext4's key developer is a Google employee IIRC!
and because it interfered with implementing file system renaming (which looks to be surprisingly tricky to do right).
Because they didn't want to implement the few lines of code supposed to invoke the already existing facilities that set the file system label. A thing that, for tricky that it may be, was done right by the Commodore 64's 1541 floppy drive OS, by MS-DOS, by all versions of Windows, by all Linux-based desktops, by AmigaDOS, by OSX, and probably most existing operating system.
In no time at all, objections were posted, some of them rather aggressive in tone.
One of the last comments before disallowing further comments was that they were looking into keeping extFS support, but throwing an error message if you try to rename an extFS volume, and possibly implementing extFS support in userspace for security reasons.
After the slashdot story was published, after my comment was written, when more and more people started stating, most of them politely, that removing ext support would make ChromeOS unsuitable for their work, and that they were upset because there was no credible explanation for the removal of the feature, only after that developers stopped ignoring their discontent and decided to leave ext support in for the time being, but still without writing the code required to alter the filesystem label.
All of this seems quite reasonable when considering what ChromeOS is and its usual usecase.
And when did I say otherwise? I even said the same thing in another comment.
In terms of the ratio of Linux distributions which use Bash as the default shell versus those that do not, the vast majority still use Bash.
Even if this is true, and no I haven't checked it, it has no relevance over the reality of how many people are effectively using Bash together with the Linux kernel, which is a matter of which distributions people effectively use. I do aknowledge that RedHat-derived distributions are probably more common on servers, but I'm just guessing that out of prejudice.
Debian-based distributions use dash as the default system shell, but Bash remains the default interactive shell,
If you really had a server of any kind which spawned a *real user login shell* as a result of a remote client request of any kind, then you would already have a huge security problem. Moreover, I expect lots of people will use Bash as their persoanl shell even on BSDs as it's so much better than Tcsh.
and many scripts specify #!/bin/bash in their shebang line.
Then they are as broken on FreeBSD (or any other OS) as well as they are on Linux distributions that haven't Bash as the system shell.
That last bit is important, because we're living in times where an increasing number of developers are releasing code for network daemons which are designed to be easily run under unprivileged user accounts by those same users. Regardless of how secure the daemons themselves may be, the simple fact that they're executed with Bash as their parent process means they're vectors for system compromise from bugs like Shellshock.
How so? The bug is triggered when you start a buggy Bash shell having a malicious environment variable set up by the parent. Having Bash itself as a parent isn't a problem, because the bug is triggered when the environment is parsed at Bash's startup time (the shell might even crash afterwards).
The karma bonus posting option is enabled by default for a reason. When people who have an established track record of saying meaningful things (as determined by the up-modded metric) post comments, those comments are automatically ranked higher. Likewise, the moderation system provides for down-modding of any given comment, which has the side effect of karma reduction for the "offending" poster. The fact that you don't like what someone has to say is really of little consequence unless you have mod points; this is by design.
The karma bonus is there as a measure to let *you* moderate your own comments. If you consider 2,000 characters of condescendension as something that is worth promoting, good for you, but don't expect other readers to share your conviction.
The biggest difference between time and space is that you can't reuse time. -- Merrick Furst