With ZoL there were issues with metadata heavy workloads (rsync being one of the prime examples) with 0.6.2, however with 0.6.3 those issues have been significantly improved by many accounts.

As part of this though, are they going to be moving to an actual open and inclusion development process for CentOS?

I just got a new Dell Precision M3800, it has one of the 3200x1800 displays, two memory slots (although max of 16GB for now until reasonable laptop 16GB mDIMMs are available), and flexible battery and storage options. For a shorter life battery both an mSATA SSD and second 2.5" drive can be used (256GB SSD + 1TB spinning) if you have high storage needs. It is definitely a breath of fresh air in some regards, and room for improvement, but overall I've been very happy with it. It really is essentially a MacBook Pro but with some options.

For single drives yes it seems to work well and so I can give you some advantages over filesystem unaware LVM. However in my experience (last tested in September) it doesn't come anywhere close to mdraid for multiple device setups. The tools don't accurately show the kernel state (drive missing or not) and there are a number of inconsistencies just in hotplugging drives. Oh and that is the only option because you can't even forcibly fail a drive from a RAID1 to replace it.

But at least "full-auto" means something concrete. "Assault rifle" as a term was invented to generally mean a gun that does something 'bad', or looks generally like a type of gun that did something bad in a movie once. A proper definition doesn't exist based on innate capability, but instead of makes and model that look dangerous, regardless of actual firearm mechanisms or functionality...

Or what I feel is the better of the two main droidwall spinoffs - AFWall+

https://play.google.com/store/apps/details?id=dev.ukanth.ufirewall

It is definitely less Google friendly named, I just noticed they added a parenthetical (Android Firewall +)

To be clear, that's not to say that is what Lavabit had in place (as far as I'm aware it really was client-side private keys), but knowing where which private key comes into play is paramount. This is just clarifying the logical incongruence between the statements when both are held to be true.

Sure, but the parent's point is that there are two assertions which are mutually incompatible, and is questioning the statement that data is encrypted with a user key:

        1. The key used to encrypt data on disk is known only to the user, or "stored email was encrypted based on a key that only the user had"

        2. Obtaining the server-side SSL private key would allow reading the plaintext.

Since lavabit was able to provide an alternative means to get the data of just one user, that tells me that #1 is invalid. If the data really was encrypted with a user key then a copy of the data in transit would be encrypted even when unpacked from the SSL stream. In cases like that, SSL is only used for data integrity, not encryption since the encryption is already in place.

Use the IMAP server - if you have control and/or space available.

I just have a single large archive IMAP folder into which everything that isn't spam gets pushed. You could optionally create subfolders for time ranges (every 1-2 years, whatever works for you). Using dovecot with good indexing support on the backend quick searching has been great. If you do a sub-archive breakout on time the searches will be quicker, you could also then create a virtual mailbox combining them all for when search really needs to span time (and take a good chunk longer)

There are scripts/utilities available to push mbox, etc. into an IMAP folder, push everything there and use it.

Windows can do that as well - Win+Left Arrow, Win+Right Arrow, and Win+Up sends the window to the left half, right half, and maximized. Not that I don't prefer the KDE version, but I think Windows may have had it first - I at least saw it on Windows first.

Sure, the nightlies are - but notice at that same location the win64-x86_64 builds also? Mozilla have themselves provided nightly 64-bit builds of FF on Windows since at least before the 4.0 release. I was running the 64-bit Minefield nightlies leading up to the 4.0 release, figuring that they would then be official releases, but alas they appear to just be considered the ignored stepchild by Mozilla.

From the actual announcement, it appears that btrfs is NOT supported for direct booting, but simply to be recognized by grub-probe, and a separate /boot is still required to have btrfs as the root fs.

"Add `grub-probe' support for the btrfs filesystem, permitting / to reside on btrfs as long as /boot is on a filesystem natively supported by GRUB."

I actually like the dark gray on light grey for collapsed comments - it provides a great visual indicator that it is there, allows a preview of the comment, but the muted color combination makes it more subtle and less prominent than higher contrast combinations would.

Now, that said, I do agree with all the "too much whitespace" comments, which certainly apply to collapsed comments as well - there is too much whitespace surrounding the text in each collapsed comment item. A collapsed comment doesn't have to be a huge bubble, just make the light gray background slightly larger than the contained text.

A text issue, unrelated to color scheme, it would be nice to display an ellipsis or some visual indicator showing that the collapsed comment does indeed have more than the one line available in the preview. It's a little thing, but I get annoyed when I click to expand a comment and there isn't any more content beyond what I read in the preview.

Finally, the light grey collapsed comment bars should NOT extend out the full width of the page. Keep the green story bars and displayed comment bars going the full width, but keep the collapsed comments visually within their parent comment (perhaps 80% of the parent comment space?).

This is a nice unit, but the CPU limits the wireless throughput. I have OpenWRT on an Asus WL-520GU, and my wireless transfer over a WPA2 link maxes out at about 6 Mbps instead of the 10 or 11 Mbps I get when connected over Ethernet cable to the box. The CPU/chipset does doesn't have enough to keep up with the encryption at the higher bitrates. I'm waiting for a good 802.11n OpenWRT supported router to be available and I'll jump right away, even though all my clients are still 802.11g only - the n routers usually have more CPU power and/or WPA2 better supported in the hardware.