Computers

Really, Apple? That’s It?

Posted by

0

I’m a developer.  I run Windows in a virtual machine on my MacBook Pro for the explicit purpose of running Visual Studio and SQL Server to do application development.  Those are some memory-hogging beasts, too, let me tell you.

I bought the maximum of 16GB of RAM when I bought my Retina MacBook Pro back in 2012.  It was spacious then.  Now, however, it’s getting to be not enough to speedily run everything I want to be running during my daily work.

So, I was excited that Apple was going to refresh the MacBook Pro.  It’s about time I upgrade.

I want one thing in a new laptop: more RAM. Several manufacturers out there currently have 32GB buildouts.  I’m quite jealous, let me tell you.

So, imagine my disappointment when Apple “upgrades” their professional laptop, and proceeds to *remove* more than it adds.  *And*, keeps the same maximum amount of memory as my four-year old laptop.

I’m pretty pissed off about that design choice, and moreso because of the mealy-mouthed “32GB would cut down on battery life” reason that Apple gave.

OK, fine.  So my battery life might be less.  You don’t think I’m big enough to make that kind of tradeoff choice for myself?  So give me a warning about it.  BUT give me the choice, too.

Because I work with my laptop plugged in far more often than not, anyway.

So now, I’m contemplating buying a non-Apple computer for the first time in about 15 years.  I can get much better hardware specs, much better performance, and pay much less money elsewhere.

I’m pretty bummed about how drastically Apple has lost the drive to be in the lead since Steve shuffled off the mortal coil.

This might just be the last straw for me, though.

Feh.

 

Mac OS X Lion’s Full Screen Apps Are Cool, But Not Fully Baked

Posted by

2

Full-screen apps in the newest iteration of Mac OS X (Lion) are very cool things when viewed from the simplest use case scenarios.  Especially if you’re using a trackpad to interface with your computer.  Everything else gets out of the way, and you can concentrate on that one app while you work.  Excellent.

Wait. Hold on a second.

Do you have more than one display attached to your computer?  Don’t bother using full screen apps.  You’ll get that app full-screen alright, but at the expense of the ability to use any of your other screens.  That’s right: the app will zoom full screen on your primary display, while all others will display a lovely gray linen background (and do nothing else) until you come back out of full screen. Useless. Dare I say: “fail”? Yes.

Fail.

Why on earth can I no longer use my other screens for anything?

Another area where full-screen apps are less than bright and shiny is in how they deal with notifications from other (now background) applications.  In short, they don’t.  If you are, for instance, browsing in Safari full-screen, and also have Mail running full-screen in the background, you have no really effective way of being notified when new messages are received by Mail.  There’s no Dock visible, and therefore no badge on the Mail app’s dock icon to inform you there are now messages waiting.  Instead, you have to continually go switch to Mail to see.

Fail.

Yes, yes, I know you could hook up GrowlMail and let it notify you via Growl.  The point is that something like this needs to be baked into the OS itself if you’re going to suddenly take away all of the existing options for gaining the user’s attention for something like an incoming mail message.  Speaking of which, I vote for directly embedding Growl into Mac OS X, and directly embedding Growl notifications into all of the built-in apps.  Probably not feasible due to licensing restrictions, I know.  But it sure would be cool.

Do these two warts keep me from using full screen apps? No. At least not on my laptop, where I’m typically limited to one display.  Swiping between the full-screened apps is very convenient and cool.  I use it there.  On my desktop workstation, however, where I have dual screens, yes this absolutely makes me not use full screen apps at all.

I’d really like it if full-screening an app zoomed that app to the display it happened to currently be on, while leaving all of the other displays on the system alone.  I’d love to have the ability to zoom an app on each attached display.  Very useful.  I realize that this capability would require some thought on how to most effectively use the swipe gestures to switch between zoomed apps.  Perhaps the swipe could switch between apps that are zoomed on the display where the cursor currently resides?  Dunno.  Anything is better, however, than essentially taking away all of my other screens when I switch an app to full screen.  That’s just dumb.

A rant about passwords

Posted by

0

Okay.  Having just attempted to change my password on a site which shall remain nameless, and having my desired password be rejected, I confess that I’m upset.  My grandmother told me never to write angry, but I’m going to ignore that advice for a moment.

Why is it that some website designers, in their supposed infinite wisdom, decree that they know better than their users what can comprise an acceptable password?  It’s my password, it’s my account, it’s my information: let me secure it how I want.  It’s bad enough when you get a message that your password is not secure enough to meet the lofty requirements of the site:

“Your password is too easy for you to remember, please add more punctuation and numbers and capital letters, and don’t use any words out of the dictionary.  Here’s a suggestion for your password: @#$S59u01Cxx7*(6. Perfect! We’ll just set that for you, rather than the password that you chose.”

Do these masters of security not realize that the first thing that happens when you force someone to use a completely incomprehensible, completely non-intuitive password like that is that the user WRITES THE PASSWORD DOWN???!! How on earth is this secure?  Indeed, I submit that these types of passwords are actually less secure, because they are not easy for the person to remember, and therefore leave records for someone else to discover.

Worse, though, from my perspective are those designers that decree from their lofty perches that your chosen password can’t be used because those same designers have decided that their users’ passwords must be constructed from a very limited set of allowable characters:

“I’m sorry, but your secure password is not acceptable because you must make your password out of only lower-case letters and numbers.  Here’s a good password for you: pa55w0rd

No one will ever, ever, ever guess that one, we promise!”

Dammit, get over yourselves.  Just let me use the password that I want to use, please, and let’s both move on about our business.

By the way: when I encountered the first type of message this morning, the password that I had wanted to use was this: ‘I like gibberish.’ That’s right: it was a passphrase, rather than a password: easy and intuitive for me to remember, but very difficult for someone to guess, and also difficult to crack.  Brute-force tactics against that password would statistically take many more years to break it than either I or the designer of the site would likely be alive, but it was decreed to be unsuitable because it contained no numbers.

When I encountered the second type of message this morning, the password that I had wanted to use was this: ‘Twas brillig, and the Hobbits did roam.’ Which was rejected because passwords for that particular site had to be eight characters or less and comprised of only A-Z, a-z or 0-9.

So, putting on my professional’s hat for a moment, to give a small piece of advice to website designers:

  1. Let your user choose whatever password they want.
  2. It doesn’t matter to you what characters are in it, or how long it is, because you shouldn’t store that actual password at all.
  3. You should store an irreversible hash of the password, instead, which, when done correctly will:
    1. produce a value of a known and constant length.
    2. not reveal your user’s actual password in the event of your database being compromised by an attacker.
  4. All pages involved in either creating the password or logging in with the password should be on pages protected by SSL.
  5. You should then compare the hash of what the user submits to you to the hash you’ve stored in the database.

Okay, rant finished.