Eh, I'm looking forward to Systemd because it will be an improvement over init.d scripts. Especially when you have multiple services that depend on other services being up and running.

In today's world, you have to write some other non-standard script or use some other non-standard hack of the original init scripts to make sure that X starts before Y and that Z also gets notified that X restarted. That's a major pain point for anyone who doesn't depend solely on monolithic apps. Such as a mail server... (clamd, amavisd, postfix, dovecot, sogod all intertwined).

That being stated - there's no way I will roll out RHEL 7 or CentOS 7 until the 7.1 or 7.2 release (i.e. sometime in late 2015). I'm not convinced yet that systemd is fully baked yet. I have the same stance on btrfs, which is still a technology preview.

And binary logs are not a huge deal when it will make it far easier to find an event without having to look at a dozen different log files, each with a slightly different naming scheme or location. While the current log viewing tools are rudimentary, I expect that we'll see improved tools as people scratch the itches. The problem with binary logs is that people have really only dealt with Window's proprietary implementation (which is has been sucky for a decade-plus). There's no way to copy the log files off to a second server (if you can get the drives mounted) and the built-in log viewing tool is just horrible.

Try seafile - not saying they cover everything, but for file sync, it seems to work very well (and scales better then Owncloud when you have a few thousand files).

Writing down a password is not the big bug-a-boo that you make it out to be.

Writing it down and leaving it stuck to the monitor / keyboard is a problem (a social problem). Writing it down and keeping it in a secure location, not such a big deal (password manager software falls into the second category).

The trap that many system admins fall into is that they think requiring long and complex passphrases meshes well when combined with forced password expiration of less then a few years. When you force password resets on everyone on a week/monthly/quarterly basis, your users will figure out some trivial method that gets past your system or resort to just sticking passwords on notes stuck to monitors.

Far better to let them choose something reasonably complex (which is 14+ characters these days) then monitor for signs of unauthorized activity. And add in two-factor authentication using their corporate assigned phone or smart card or token thingy that kicks in if things look iffy.

Eh, I have the HTC One (m8) and my main wish for it when I got it was that it would be about 1/2" to 3/4" smaller. I'm not unhappy with the phone except that I wish it was just slightly smaller.

When every developer in the offices pulls out every thing in the repository and tries to check the whole repo in after modifying the 1-2 files they changed, that is the problem.

That causes zero issues in SVN, because in SVN it only commits the files that have changed... now, if you have a developer editing dozens and dozens of files and doing a massive commit, that's a separate management issue. (i.e. they should be doing a feature branch)

Where SVN falls down is in complicated branch/merge scenarios, and they're constantly working to improve it. Git, Mercurial or other DVCS systems are just better at that.

(shrugs) I've looked at git, mercurial and subversion - and SVN is just easier for regular users to understand. The main hurdle they have is learning the update / modify / commit cycle and that the shorter the cycle, the better things work. Plus, learning not to leave their working copy / development areas dirty with uncommitted changes.

Battery life depends on a bunch of things...
- What you leave running in the background
- Whether bluetooth / wifi / cell / GPS are on/off
- Whether you have a good cellular signal (more bars = less power needed to talk with tower)
- Quality of the WiFi signal / network congestion
- Screen brightness

With the HTC One (m8), I have to charge it every 2-4 days. Depends on how much I'm using it, what the weather is like outside, how many hours I spent on the phone that day, and where it spent most of the day.

I spent about 2.5 hours on conference/phone calls today and the phone has been off the charger for about 18hrs. Battery is at 66%. GPS, WiFi and Bluetooth are all turned on. That's not fabulous but not horrible either.

It does matter. When I compare my older Asus TF700T (tablet, but same resolution as the phone) with a Quad-core 1.6 GHz Cortex-A9 compared to my HTC One (m8) with 2.3 GHz quad-core Snapdragon 801, the difference is immense. The HTC device is extremely responsive and snappy in comparison.

On the tablet, I'm constantly having to wait on it to pull up email, or switch to the chat program, or open browser pages. I'm not sure if that is because it is one Android revision behind the HTC or if Asus did something with the UI or if the Cortex A9 chip is just that much worse then the Snapdragon 801.

Now, once you get past the "knee" where you can switch apps in under about 0.25sec and where you are not stuck waiting 3-10 seconds for something to happen, then further performance increases won't matter anywhere near as much.

(It's just more obvious if you use multiple devices for a few weeks.)

VSS (Visual SourceSafe) was okay - as long as you locked it up behind a SourceOffSite (3rd party) server. The SOS service as the primary interface between the VSS repository and the clients prevented about 99% of corruption issues.

This was back when your options amounted to VSS, Perforce, and a few other high priced version control systems. About the only free solution back around 2000 was CVS, and that was just bad for other reasons.

(Some teams benefit from distributed version control systems like Mercurial/Git. Others benefit more from centralized VCS like SVN / TFS / Perforce. We prefer SVN because it is far easier for non-technical members, i.e. mere mortals, to understand and much harder for them to do the wrong thing.)

I greatly enjoy my (m8) that I got this past spring. The phone is very responsive, makes my 2-year old Asus TF700T tablet feel like a slug (even though both are quad-core and the speed on the HTC is not that much more).

BlinkFeed thing is eh... doesn't bother me and sometimes I use it to pass the time, but I wouldn't miss it either.

It's not a Google phone, but I am pretty happy with my HTC One (m8) and there's a newer less expensive version (HTC Desire?). Five inch, 1080p, and very little bloatware / UI lag. HTC did a good job and it's a very responsive UI, better then my Asus tablet.

Ebola would have to shed about 80% of its mass to get airborne. At which point, it probably would not be Ebola any longer. There's just a huge difference between fluid-borne and air-borne viruses in terms of mass.

Droplets are the big issue, small enough not to be visible to the naked eye, but with a range of 1-2m (3m if the wind blows hard).

Even if it never scales up past cell-phone battery size, the increased recharge ability (10,000 cycles) would make it far better then today's batteries which start to fade after ~200 to ~1000 cycles.

Which was one of the more annoying features of early Lithium Ion batteries...

BoLS says unemployment is down to around 6%.

Now, you may argue with the specifics, but the general trend has been downward since 2009. Or a more detailed article.

Estimates are that care like that costs $800-$1000 per hour, possibly as much as double that (if isolation wards are needed).

So for 20 days, that would be in the realm of $500,000.

Thanks, my HTC One (m8) has "hardware backed" security.

My older Asus tablet does not.