If you have to cram a long term storage device into a small package then SSDs may win that battle

Depends on how you define "long term". A powered off SSD only retains data for as little as 6 months up to a few years (and as cell sizes get smaller, that will get worse).

Traditional magnetic media is still going to be better for 5-15 year lifespans on a shelf.

Even my SMTP server lets you talk TLS to it if you try. Not everyone who emails me tries, of course, but it will let you do it so my "end" is secure.

I just checked our server logs for the last month. Out of the connections, less then 4-5% negotiated TLS.

Now, granted, about 90% of those connections were probably spam, so maybe as much as half of legitimate mail servers now negotiate TLS.

(Anyone got better data? I didn't feel like trying to figure out whether a particular connection was or was not a spam connection.)

If it gets stored as a hash of the values, and is salted properly with a random 32bit salt (unique per user), then even if a thief steals the database of hashes, they don't gain much. They can't use that hash to attack another system. There are ways to protect against replay attacks like this.

Biometrics (something you are) will never work on their own as a sole source of authentication, you're still going to have to have passwords (something you know) possibly combined with something you carry (something you have).

Maybe. Let's assume that all of the words in the sentence are within the 4096 most common words. That's 12 bits of entropy per word. So a six word sentence would, at the upper end, have 6x12 bits (72).

However, you can probably count on "the" and a few of the other 32 most common words being at various positions. So for those words, there's only 5 bits of entropy. And if it is a grammatically correct sentence, then markov-chaining or other tricks like n-grams might reduce your search space from 12 bits per word down to 8-10 bits per word.

Real quickly we're down into the 50-60 bit range... which is not very promising. Still enough to prevent the $10 of CPU time attacks, but vulnerable to the $1000 ($10k?) of CPU time attacks. And CPU costs do get cheaper over time...

That being said... password input forms should allow lengths of up to 100 UTF-8 glyphs. Let the user decide how long they want to go.

How well does it work for project-based businesses. Most ERPs seem to be designed around inventory management and manufacturing - which is not a good fit for businesses where what you are providing is expertise.

The problem is that people move around... a lot. Ebola has an incubation period of up to 21 days so that gives an infected person lots of symptom free time to travel to visit his neighboring village or go to the city or get on a plane to visit relatives anywhere in the world.

From doing a layman's reading... you are not infectious until you start showing symptoms around day 21. This is, fortunately, not like influenza where you are infectious before showing frank symptoms. It is also, again fortunately, difficult to transmit only through casual contact.

Scary yes, but not end of the world scary.

That's what Cisco does, they do regular bottom 5% cuts where those who are ranked in the bottom 5% on their performance reviews are let go.

And as a result, Cisco keeps putting out crappier and crappier products and their brand is swirling the drain.

The 5% cut of the bottom is not something that you do more then once. Because the second, third, and fourth round of cuts means that employees will start throwing each other under the bus, just so that they aren't in that 5%. Inter-department cooperation takes a shitter and your teams of very good employees constantly get gutted instead of being left alone. Just because there has to be a sacrifice.

If you're in a company that does that every year... it's time to find a new job. Or become a psychopath and enjoy throwing your co-workers under the bus each year.

I don't own a tablet - I use a desktop machine for every day work, a laptop around the house and an Android smartphone. I wouldn't really want to read books on my smartphone except in an emergency - screen's too small to be comfortable. And I don't want a bigger smart phone because then it wouldn't be convenient to carry around and I honestly can't think how a higher resolution display would make my phone better.

I took my HTC One (m8) smartphone on a long flight a month or three ago. Ended up reading almost an entire fiction book on the flights on a little 5" screen. This is a 1920x1080 display packed into a 5" screen.

It actually worked quite well - far better then I was expecting. The higher DPI on the modern phones (441ppi on the HTC) makes for easy reading.

Meanwhile, other game developers have stated that discrete soundcards just don't matter in terms of performance. A lot of the game developers need to do special processing on the audio files in the CPU before handing them off to the sound system to be played. Because the Windows API doesn't allow them to do that special processing on the card (and nobody wants to go back to the days of supporting a dozen different cards).

The "advanced functionality" of the add-in cards is mostly mythical these days, hardly any developers are willing to jump through the hoops to support it.

(It used to be true that your PC would offload a lot of the audio work to the soundcard, lessening the demand on the CPU. But that is no longer true.)

So these days, it boils down to whether the add-in cards have better S/N ratios for your analog speaker / headphone / microphone jacks, or work better with whatever you are outputting audio to then the built-in solution. And while I'm a happy ASUS Xonar user, I feel that built-in audio on most motherboards is good enough for most of the time, so it's a shrinking market. I don't even recommend an add-in card unless there is evidence that the on-board audio is just pure shite.

And how did you learn to write good code that's efficient and make sense to others? Maybe you're the rare case of a person that can just intuit what is good code and what isn't, but I think most developers (including myself) learn how to write good code by first writing lots of bad code, and then suffering the consequences until they learn from experience what works and what doesn't.

We learned by reading tomes like Code Complete which forced us to examine why we coded in a particular style and whether what we were doing was efficient or made sense. In short, we took it upon ourselves to improve.

Or you can do it the hard way as you stated and just write bad code until it bites you in the arse.

Java in the web client is dead (so is Silverlight / Flash)... go Javascript / HTML5 if you have to do things on the client. Java on the server side... isn't going away for many decades.

The only downside of Java is that it's rather heavy for "one-of-a-kind" web pages. There's a lot of setup that you have to learn (Maven archtypes help) before you get HTML on the web browser. But as soon as you need something that can scale, talk to disparate systems, support unit testing, etc., it's far better then PHP. PHP just falls apart once you get past a handful of PHP pages.

If by SSD support you mean TRIM, that came in around the era of Vista or Win7. WinXP definitely didn't have it and SSDs definitely got slower after a year or two of use (until you redid the system).

The HTC One (m8), released this year, also has a battery stretch feature.

Overall, very happy with the HTC One (m8) other then I wish it was about 1/2" to 3/4" smaller. HTC did a good job with the UI and it's very snappy, makes my 18 month old Asus TF700T Transformer tablet feel slow (both are quad-core units).

You really don't know what you're missing. For business laptops, we've made the switch to 100% SSDs for 2-3 years now (ever since they dropped down to $1.50-$1.75 per GB). Granted, these are all uses who can function with only a 128GB SSD. Which holds true for probably 90% of office workers who have access to a file server (instead of storing business critical data on their HD).

Now, instead of waiting on their HD to seek around and find information (a boot process measured in minutes, program loading times measured in 10s of seconds), boot-up takes under 20-30s and program loading times are near instant. What you *will* notice is that your CPU is now the bottleneck (oops). For development work or any thing where you need to do two or three things at once, or run something disk-intensive like a scan or search of files, SSDs are a must-have. I will regularly kick off compiles / version control updates / searches, and still be able to use the machine for other things while it thinks.

Just makes sure you have a good backup system in place. On the Windows-side, I recommend Acronis True Image writing to a 2nd old-style HD inside the case. Or an external 1TB USB3 drive that you leave connected during the backup window. That is not because SSDs are unreliable (unless you buy crap like OCZ), it's because their failure modes are such (if the controller goes crazy) that data recovery is highly unlikely.

No, becasue the only food they can afford is salt laden fatty food.

If you are willing to spend a minimum amount of time cooking, things like rice, lentils, beans that you soaked overnight in the fridge, potatoes, budget cuts of meat, frozen veggies, quick-oats are all easily affordable and don't come laden with salt unless you add it. None of it requires special expertise to cook (most of that consists of "put in pot of boiling water for 10-20 minutes"). It's not going to be high cuisine, but it will be nutritious and filling.

Once you learn how to boil water and cook things in the boiling water, then you can graduate to "make a stew on Sunday, serve it as leftovers on top of rice / potatoes the rest of the week". You know, like your grandparents did back during the 1920s and 1930s.