Freaky

I'm very happy with Portfast. http://www.portfast.co.uk/

> Ideally what I'd want is an NFC ring or a smart band/watch that can use FIDO's U2F or a similar protocol that works through NFC

I've got my eyes on a Yubikey NEO for just this kind of use: https://www.yubico.com/products/yubikey-hardware/yubikey-neo...

IPv6 by any chance? Try http, that seems to be working better for some reason.

Dubious initial FreeBSD port: https://github.com/Freaky/lastpass-cli

Don't use the edit command on anything sensitive without a suitably secured /tmp - ideally tmpfs and encrypted swap - since it writes the data to a tempfile for your editor to open.

Just got it working - Yubikey support seems fine.

There's code for it at least. Can't verify if it works right now due to problems building on FreeBSD.

> I guess I could use FreeBSD if I didn't need KVM and/or Xen....

Have you looked at BHYVE?

Does nothing here, still an article fragment.

> is there any reason why a memory controller can't be designed that would, worst case, use every other (identical) stick just to get parity bit(s), as a BIOS configurable option?

If Intel were interested in allowing you to make use of any parity bits without buying a Xeon, they wouldn't be restricting ECC to Xeons in the first place.

Firefox is moving in that direction at least: https://wiki.mozilla.org/Electrolysis

It's responsive and fast for you in a single fullscreen 2560x1600 term while catting a large file in a split? Performance is a lot more reasonable if you're using more traditionally-sized terms and let Terminator manage the splitting.

Perhaps it's depending on some hardware acceleration feature not provided by VirtualBox.

It's less about the stability and more about data integrity. Crashes suck, but they suck a hell of a lot less than corrupt filesystems and backups.

tmux is my main use-case for a fast terminal. Even something as simple as resizing a split in my main 266x188 session while nothing else is happening makes Terminator (VTE-based) into a juddering laggy mess.

urxvt's nice and responsive even while catting a million line file into one of the splits - I can use other terms and resize splits without a problem, hitting ^C stops cat instantly, and it's done displaying the lot inside 12 seconds.

Terminator takes 5 seconds just to respond to a ^C, and is otherwise completely unusable for over a minute.

The filesystem and API support is still there, and System Restore still uses them. vssadmin doesn't offer to let you create shadows, but you can still make them via PowerShell:

    (Get-WmiObject -list win32_shadowcopy).Create("C:\","ClientAccessible")

NTFS supports snapshots, which it calls Volume Shadow Copies.

Browns are a bit quieter, but still quite clacky when you bottom the keys out. You can reduce that quite a bit using o-ring dampeners under every keycap.

You might also look at a Matias Quiet Pro - they use custom switches based off old Alps designs (much more satisfying than Cherries, imo) and are a fair bit quieter out of the box: http://matias.ca/quietpro/

> # allow up to 999999 processes with corresponding pids

This is now the default in DragonFlyBSD: http://freshbsd.org/commit/dfbsd/3a877e444fff816b8a340d35fe3...

BitLocker at least supports TRIM with SSDs on NTFS volumes: https://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q...

> When Bitlocker is first configured on a partition, the entire partition is read, encrypted and written back out. As this is done, the NTFS file system will issue Trim commands to help the SSD optimize its behavior.

It's also planned for FreeBSD's geli: http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016...

It's lacking a good deal of polish, but it's a good effort. It's more or less a direct clone of Frontier/FE, practically to a fault, though sadly without any of the original ships due to copyright restrictions. Surprised oolite hasn't had similar problems.

There's also a commercial space sim based on it in development called Paragon which might be worth keeping an eye on: http://www.paragongame.com/

And for those who preferred the sequels, we have Pioneer - http://pioneerspacesim.net/

I've experienced silent corruption on NTFS. And it still modifies data in-place, so an unlucky power failure or reboot could still cause data loss. Thankfully Microsoft already have an answer, ReFS: http://msdn.microsoft.com/en-us/library/windows/desktop/hh84...

You can set the "copies" property to 2 or 3 even with a single disk, so if one dodgy sector blats one of your files, ZFS can still recover: https://blogs.oracle.com/relling/entry/zfs_copies_and_data_p...

They do. Motherboard vendors often fail to support it, unfortunately, but the CPUs generally aren't the weak link.

> If you are getting corrupt files that's not the filesystem's fault, it's most likely a problem with the hardware.

I don't think the implication is that the fs is at fault for the corruption - it's just at fault for failing to detect it. Hardware problems tend toward certainty over long enough time scales - doesn't it make sense to defend against it given the relatively minimal cost of doing so?

> Checksums at the FS level are very rare; the majority of the ones in use don't have them .. and yet they function perfectly fine.

No, they too allow data to silently become corrupt in face of imperfectly functioning hardware. Sure, it normally doesn't happen, but it's certainly not rare enough to warrant ignoring if your data is in any way valuable to you.

> I heard scuttlebutt that they're shipping Microsoft DLLs. That's a big no-no in our offices.

Yes, exactly the same redistributable MSVC and Direct3D libs most games ship with. What's wrong with that?

Just like that.

> language website: http://swift-lang.org/

Nope, completely different. Really scummy of Apple to just nick the name of an existing language for their new one, it's been five minutes and people are already confused.

> I'm going by what the manufacturers say

Are you really? "Non-recoverable Read Errors per Bits Read, Max", say Seagate - that just means it couldn't correct, not that it couldn't detect there was an error.

> are you saying they are overestimating the error rate?

Perhaps not, as a general order-of-magnitude upper-bound on a marginal drive in poor conditions, but certainly if you're interpreting it as an average. Too many people would be seeing it happen way too often to keep quiet about it otherwise.

> Used to be you never got corruption, just success or fail

I wish :/

> It's to the point that if you read an entire disk 4TB you have a 32% chance of one bit being wrong!

If this were the case, forums would be filled to the brim with ZFS users whinging about how they get CKSUM errors practically every time they scrubbed their pools. They do happen, but nothing like that frequently.

> That means hard disks can no longer be considered reliable devices that return the data written to them

They were never such devices in the first place if you ever valued your data enough to care. Even if your disks are perfect, your cabling, backplanes, IO controllers, drivers or memory probably aren't.

A friend of mine works on ports for both platforms, and he vastly prefers the graphics driver situation on Linux, both in terms of driver quality and vendor support.