The biggest issue I have with all of these solutions, 1Password, LastPass, KeePass, the OS X Keychain, browsers storing passwords, et al, is that they basically just all store all of your passwords in their own custom ways, often on remote stores beyond your control, while leaving you with the mess of creating the passwords and keeping them "in-sync" between all of your devices. What if you're not behind your laptop? How do you log into your email?

Thought I'd mention Master Password which aims to address this issue by letting you remember a single master password (which you already do for each of these solutions anyway) and then calculating your password for a given site from it. The algorithm is completely offline, uses no inputs other than those remembered by the user and others documented by the algorithm, and the output will pass most any of those pesky "password policies".

It basically means all you need is a calculator and your password to get access to any of your sites. And if you loose your device, no data lost and you've got your identity back just by picking up any other device.

The actual app is currently in beta and only for iOS, but the algorithm is fully documented for anyone to reproduce and a Mac version is already planned.

That's exactly why I said "Nobody's claiming that free software will cure politicians of their idiocy or prevent it."
Free software gives you transparency and options. It doesn't force anybody else's hand (even if it's to *not* censor content).

Nobody's claiming that free software will cure politicians of their idiocy or prevent it. What the article is claiming is that under a world running exclusively on free software, or at least one with plentiful free alternatives, at least I'd be able to buy electronics that won't police me and turn me in under the strict regulations forced upon me by my government.

When you buy a knife, you know what it does and what it's capable of. When you buy a house, you can look in every nook and cranny of it, you can see how it's built and what it's built of. You can modify it however you like. When you buy software, or any non-free electronic equipment, you've bought a black box. It advertises features, but it's capable of so much more. What it really does behind the scenes is completely unknown to anyone but perhaps a security researcher.

Buying a computer is like voting for a politician: The features are as advertised, but the agenda is largely unknown to you; and they'll both do much that you didn't bargin for.

The article is trying to say: If we force free software on our electronics, we basically make them on equal standing with the house example. You can now look at the source, inspect it for all it's worth. Modify it however you like. That is Stallman's dream, and to tell you the truth: It won't kill the economy. It will just be a different economy and we'll all be better off for it.

Whether they have is largely irrelevant to the point the article is trying to make. What matters is, is it guaranteed that they won't? No, it's not. Thank the lack of a clear definition for terrorism for that. The point being that if you want to be able to trust your computers to not turn you over to your government for something you personally wouldn't see as terrorism but they might, then you need your computers to run free software so you can at least see what it's been programmed to do.

Showing chicks fondling a monitor isn't an illegal or misleading marketing practice. Misinformation is.

The first inventor would have prior art if he's actually doing something with that invention. If not, who cares?

Why do we have these CAs around? A completely decentralized system that has no system of control whatsoever. All you need is for some company to manage to somehow convince some browser venders that they have good security policies. And with that, everybody around the world is basically forced to follow in that "trust". How fucked up is that anyway.

At the same time, the whole thing is so tightly coupled with DNS already. The common name has to be the domain name. So why the heck are these CAs separate from that? At least DNS has a control body. CAs have nobody but the browser vendors; and they don't report to them.

I say dump the current CA trust model. Make all DNS root servers a CA, let them issue CA certificates to their registrars, and let the registrars issue certificates to their customers, and only for those domains that their customers have registered under them. Publish the certificates in the domain's DNS records. Make ICANN compose strict rules that all registrars must obey, just like they already do before they allow registrars to service TLDs. And punish violations by revoking the registrar's certificate. Install all DNS root certificates in all OSes, and force those OSes to keep a local OCSP cache that is no older than a few minutes at any given time.

What are we doing fucking around with trusting arbitrary companies that survive on charging exuberant amounts of money to do openssl commands, and have no form of oversight whatsoever?

I've found env is most commonly found in /usr/bin/env and as such #!/usr/bin/env bash is a fair attempt at a constant hashbang, but as you've indicated yourself; if you really need to write a script and deploy it to random target OS'es, you'll probably want to customize the hashbang for each to point at wherever you've got or decided to put bash in it. It's not such a major undertaking.

Writing bash code by using often broken pure-POSIX equivalent solutions just because it'll mean you'll have it easier in a few years from now if you were silly enough to consider changing the language of your script to POSIX without rewriting it is going to give you bad bash code now and bad POSIX code later. If your needs require you deploying to targets where bash is really unavailable (it rarely happens that you can't even install it), then either write specific code for those targets in ksh (or heck, perl?) or suffer restricting yourself to POSIX. In the latter case, use /bin/sh as your hashbang. Changing a hashbang from bash to something else is always silly: Either you made the wrong choice of language initially and you should rewrite your code for the new language or you made the wrong choice of hashbang initially and you should never have put a bash hashbang in your POSIX-code. Writing C++ code in a C way because maybe you'll decide to switch back to C at some point is equally dim.

The FAQ does its best to offer all the alternatives. This is indeed a convoluted method, but there is no portable alternative. GNU sed comes with a -i and BSD sed comes with a -i, both work differently, and neither is "standard" (and indeed, neither handle symlinked files well), ed is. I'm not sure what you're implying here, but if you were trying to make a case for sed's -i, it would utterly defeat your case for portable shell code in bash scripts. Non-interactively editing files is a difficult thing to do right, even more so if you want it to be "standard" or portable. You can't get a simple one-liner for everything. In this particular case, it would be better to iterate find's results with a while read loop and do non-escaped ed'ing inside, IMHO.

Your shell can do math just fine, no, you really shouldn't be forking for it. And you really shouldn't be putting leading zeros in your variables: your data should always be pure and normal. You can format it appropriately when you use it (eg. with printf).

What would you recommend? Your own arguments defeat ksh for the same reason they defeat bash, which leaves only POSIX sh, and no, you cannot write resilient code in POSIX sh, unless it involves no more than simple delegation. To be resilient in POSIX sh you need to abuse positional parameters for arrays or do nasty and convoluted eval hacks to basically write your own shell features. Thanks, but no thanks.

The Bash FAQ/Guide/Sheet are indeed, and perhaps unsurprisingly, bash-specific. They do not deal as much with "Shell scripting" as they deal with "Bash scripting". I find that a good thing. You hear people talk about "shell scripting" all the time, as though all shells behave in the same way when scripted. There is a unifying feature-set among POSIX shells, but this feature-set is so limited that it can suffice for nobody in writing decent shell scripts (no, if you need to rely on word-splitting to do your lists, you can't write a decent script). Most people really don't even have a clue about any of this and put their bashisms in .sh scripts which they commonly invoke with the sh interpreter because "it works" on their system that has /bin/sh symlinked to /bin/bash. And they think they know "shell scripting". Let's not get into (t)csh, zsh et al.

There are many shells that one can choose from and use, many with less and many with more features than bash (not to say worse and better). In the end, a great many systems come with a recent version of Bash which makes it ideally suited for general use (just because sh really isn't a reliable and decent alternative). If you use bash in your hashbangs, at least you know that you can use arrays, glob pattern matching in [[ and more. With sh you don't even know if you're talking to a POSIX shell or an old Bourne-like one. And while ksh (and dare I say, zsh) may be equally good if not better alternatives at times, the fact that they're not as widely available leaves them interesting but not my first choice, and not the choice I would recommend people invest time to learn.

On the matter of "standard equivalent that works as well", when your hashbang is /bin/bash, you'd be silly to break your script's consistency and go for a "portable" solution (whose portability is broken by your hashbang) whose bash-equivalent has nothing but advantages.

On the matter of "recommending the most complex of all possible options", sometimes doing things correctly and supporting all the edge cases is indeed more complex than supporting only filenames that contain no spaces or glob characters. But you know what, a huge amount of people that read this information every single day doesn't know or think about pathname expansion or wordsplitting during unquoted expansions and all those pitfalls. You really shouldn't recommend the "simpler" solution that falls victim to bugs caused by expected input data, just because it'll make your inside voice cry when your pipeline doesn't fit on your 80 column terminal (you probably shouldn't be pipelining it then anyway). Your code should do what it's supposed to do *regardless* of what the input data is or might become (and that's the prime principle that tends to make bash code only moderately more complex, but usually not at all).