No, that is debt, and in many cases it is the biggest single source of debt, as Darinbob said. Failing to rewrite your kludge app is just failing to pay down your debt. Whether or not the moment you get a giant wad of funding is the right time to do that depends on the context.

This is a 'troll'? Somebody must have changed the moderation guidelines again.

No, this is about old stuff, so they are clearly trying to protect Earth Orbit Station.

Passphrases composed entirely of dirty words need to be much longer than a dozen entries. The dirty word space is low-entropy.

Bah.

Oh, there's no doubt that cryptographers are continually creating and breaking new ciphers. But there are well-proven ciphers that have stood unbroken for decades. DES, for example, although the key size is now too small, has stood strong for 40 years, and in fact if you don't mind applying it three times is still proof against anyone in the world, as long as you keep the keys safe.

I have little doubt that AES will do just as well, and its much larger key size means that we won't face brute force becoming tractable, not unless actual breaks in the algorithm are discovered.

The fundamental algorithms, like AES, are relied upon by governmental entities, which the NSA is tasked with securing. We do have evidence that the NSA has been working in various ways to compromise implementations, but they can't really do that with ciphers, because if you modify a cipher, it won't pass the standard test vectors. The NSA can try to introduce things like side channel attacks, but if the NSA is actively monitoring your machine while you encrypt and decrypt (which is needed to exploit a side channel), you should just give up and flee to Russia now.

Really, if you use standard, widely-trusted cryptographic algorithms and are careful with how you generate and manage your keys, no one is going to get your data. Not even the NSA. Generation can be a little tricky to get right, but there are lots of good solutions. Probably the best is to randomly (e.g. with diceware) select a string of a dozen or so dictionary words, then use them with a standard key derivation function to produce a key, then use that to encrypt your data.

If that sounds complicated... it's really not. "gnupg -c" does a fine job. Run that on your files and upload them to the cloud. Since you're apparently happy with the security of your home machines (ha!), you can store a copy of the passphrase on the machine that does the backups, so you can automate everything. So that you can recover your data in the event of a fire, write down the passphrase on a piece of paper and store it somewhere offsite and secure. Give it to a friend or family member that you trust, or put it in a bank safe deposit box.

Encryption, cloud storage and an offsite copy of the decryption key are the way to go here.

If you want a nicely-automated version of all of that, you might want to look into the services provided by leastauthority.com.

Once you verify there are no tabs in your source code (which is trivial, e.g. grep -l '\t'), then any indentation or alignment problems are visible and the needed fix obvious (insert or remove spaces). The problem with mixed tabs and spaces is that since both are non-printable characters, you can't easily see which is which, which makes finding lines with improper mixtures difficult. You can write a regexp to identify lines with tabs that follow non-tab characters, then go fix them up, and you can even do things like create commit hooks to find such problems and deny commit, but its much less effort to simply disallow tabs from the outset. In theory it seems like it's roughly the same problem (identifying files with tabs vs identifying files with tabs that follow non-tabs), but in practice if you simply ban tabs you almost never end up with files that contain them. Trying to enforce the "correct" ordering of tab and non-tab characters always results in work.

In addition to that, the point of mixing tabs and spaces is to provide variable indentation size, to match developer preference... but even when that works it creates yet another problem: disagreements about line wrapping. Developers who use larger tab sizes naturally need to wrap lines earlier (shorter lines), and those who use smaller tab sizes want to wrap them later (longer lines). This pretty much guarantees inconsistent line wrapping.

This, of course, all assumes that you're doing manual formatting. The best way to handle formatting is to use a tool (e.g. clang-format) and ban all manual formatting. If you do that, then you can actually have the tool do the tabs-and-spaces mixture thing (e.g. for clang-format "UseTab: ForIndentation"), and, assuming the tool works, your tabs and spaces will always be applied correctly. But if you're using a tool like that, then there's really no point in mixing tabs and spaces, because any developer who wants a different tab size can simply run the tool with their preferred settings (including line wrapping), work on the code, then before submitting run the tool with the project settings. Ideally, the preferred settings should be applied by an editor load hook, and the project settings applied by a commit hook.

In short, with proper tool support, mixing tabs and spaces provides no value. Without proper tool support, it creates more hassle than its worth. Particularly since it really doesn't take long for a developer to get used to any given indent size.

Finally, among the whole space of developer code formatting preferences, indentation level is a trivial thing. If you want your team's code to have a consistent look (and you do... it really matters for maintainability), then you're going to have to specify a LOT of other things that different developers will disagree on, and which their editors can't paper over. So they're going to have to suck it up and accept some team style guidelines anyway. May as well include indentation level.

Nothing is free, but using only spaces is the cheapest policy.

Been there, tried that. It inevitably gets screwed up, meaning it adds yet another maintenance burden, unnecessarily.

The code is the documentation, therefore I always write both.

Thanks. That article is a couple of years old, though, and I don't think the numbers for Google were correct even when it was published.

I actually do most of my work in public, directly in AOSP. This is different from most Android engineers, who work on an internal tree which gets dumped to AOSP with each major release. So, not only can I tell you what I'm working on, anyone who cares can follow my work in near real-time.

Perhaps. Personally, I see quite a lot of creativity.

Unless you have deep philosophical reasons to never ever run Microsoft software, for almost any cutting-edge hardware youmay be better off just running VMWare (Workstation or Player) on Windows, then running your Linux within the VM. You may lose convenient access to some features, but you'll also get the advantage of better hardware compatibility and with most usage you probably won't much notice the performance hit.

Yeah, although keep in mind that the GNex was an unusual case. There are binary components that Google doesn't have source to and the SoC maker is out of business, and the code seems to have gone with them. After learning a lesson from the GNex, Google has worked to ensure contractually that no Nexus device will be left in the same situation.

The same convergence happened in the phone industry for exactly the same reason... regulations give only one provider in an area the right to run wires to your house. There's huge incentive for such local monopolies to consolidate to form regional monopolies. But the basis is the government-mandated local monopolies. Now, granted that there are some good reasons for the local monopolies; it would be a pain to have a dozen companies all tearing up your street to install their own wires... but there are lots of ways that could be addressed.