Big Sur problems

Posted in Apple, Computer Science, Hardware, Software on December 27th, 2020 by michael

I gave Mac OS Big Sur every possible chance. I really did. And there are just too many problems.

I currently own six(!) Macintoshes. Also two Windows computers, one very old Chromebook, and three Raspberry Pi single-board Linux computers, with one more RasPi in the mail (Update: the fourth one is now here and working). I also have a nice Synology server.  They all have a job. I admit that I could safely eliminate a few, but I  don’t want to. So I don’t.

Anyway, I looked forward with some trepidation to the release of this year’s Mac OS update: Big Sur. It looks a lot more like iOS and it comes with several exciting new features, like … hmm … thinking … well, I’m sure there’s something.

Here’s how my Macs stack up:

  • Chico: 13” MacBook Pro, about 2010. Stuck on High Sierra.
  • Groucho: 15” MacBook Pro, early 2013. Stuck on Catalina.
  • Moe: Mac Mini, late 2014. Upgraded to Big Sur.
  • Larry: MacBook Pro 16”, 2019. Upgraded to Big Sur.
  • Curly: iMac 27”, 2017. Upgraded to Big Sur.
  • Bob: Mac Mini, Apple silicon development (A12Z). On latest Big Sur beta.

Chico and Groucho are fine, obviously. They’re stuck on older operating systems for the rest of their lives. That was part of my reason for buying my newer laptop. Groucho is an amazing computer. He’s fast and powerful. He’s started feeling his age, of course, but he has plenty of life left, especially for a 7-year-old computer. Apple has made some exceptional computers over the years.

Bob is what he is. With Apple silicon, he can’t run anything but Big Sur. I got him to test my Morse Code iPhone app, which I’d like to have also running on Mac OS. If I had known I could have gotten a much faster Apple silicon Mini just a few months later, I would have waited. But here we are. It was kind of cool to get one of the early Apple development machines.

That leaves us with Larry, Moe, and Curly. Each one of them has problems.

Let’s start with Moe the Mac Mini. He’s my Plex server and has been running flawlessly for a very long time. Then he got Big Sur. Immediately, Plex started crashing at least once a day. The crashes may not have been Plex’s fault, but they were happening. After a lot of internet research and trying a bunch of things that didn’t work, I finally reverted Moe to Catalina. It’s been a week or two and he’s working perfectly. Strike one for Big Sur.

Then we have Curly the 27” iMac. Ever since I allowed him to upgrade himself to Big Sur a few weeks ago, he has stopped communicating via Ethernet and WiFi about once a day, requiring a reboot to get him working again. This never happened before. He’s going back to Catalina this afternoon.

And there’s poor old Larry, the 16” MacBook Pro. I thought he was working great with Big Sur. That made sense, since even though he’s an Intel Mac, he’s a model that’s still being produced and sold. But no. I tried to attach my portable external monitor to him on Christmas. He was unable to connect or even recognize the monitor. He connected to that monitor many times in the past. So it must be Big Sur. He’s going back to Catalina as we speak.

Frustrating times for Mac owners. This is the worst Mac OS update I have ever seen, and I’ve seen a lot of them. What’s up with that, Apple?

Alexa works on iOS! Mostly.

Posted in Amazon, Apple, Internet, Problems, Software on April 24th, 2017 by michael

I was delighted to learn today that Alexa is finally ready for iOS! And it seems to work great, except for one glaring problem – one of my very favorite Alexa apps: Jeopardy.

Like many people, I’m a big fan of the Jeopardy television show. I’ve loved it since the Art Fleming days, when little-boy me ran home from school for lunch and watching Jeopardy with my mother. They may not have any more-loyal fans than me.

So I was delighted to learn today that Alexa was now working on iOS, within the Amazon app. I tried it out first by asking for a joke. No problem! Immediately, I asked it for today’s Jeopardy clues, since I’m out of town and don’t have access to my beloved Echos.

That’s when I discovered the problem: Jeopardy hangs the app very frequently when it’s waiting for a user response. Maybe they forgot to test that functionality. The only recourse seems to be to close and reopen the app, at which time it allows you to either start over or resume from where you left off.

But there was a bug with that too. One of the several times it hung, I closed and reopened the app and asked it to play another joke, just to be sure it was still working. Jeopardy had apparently not really closed that time (although it seemed to do so every other time I went through the close/open cycle) and interpreted my joke request as an answer.

I lost credit for my correct answer! Noooooo!

Anyway, please fix the iOS app to allow Jeopardy to work properly, Amazon. In the meantime, it works fine on my Amazon Fire tablet. So that’s plan B until they fix the iOS implementation.

Another OS X calendar quirk

Posted in Apple, Problems, Software on December 16th, 2014 by michael

angry-computeruserOkay, it just keeps getting weirder for me with in OS X. I created a calendar event just now and wanted to include the restaurant’s name, address, and phone number in the “Location” tab. When I enter that information into the Location box, the app pops up a suggested address that’s identical to mine, but doesn’t include the restaurant’s name or phone number, which I want there. When I click outside of the box to dismiss it, the app deletes my entry and puts in its own “suggested” data.

The only way I can get it to keep what I want there is to tab out of the field. If I subsequently click in that field (ever!), it changes it again.

Now, I love Apple products, and they usually do things well. But dammit, if I want to put additional text into the Location box for an appointment I have, Apple has absolutely no business forcing a change there. None.

Unacceptable, Apple.

Flaky iOS camera behavior

Posted in Apple, Problems, Software on December 9th, 2014 by michael


I’ve been getting an unrepeatable error with both my iPhone and iPad under iOS 8. The Camera app’s shutter sound doesn’t work on the first photograph. It doesn’t happen all the time, but it’s frequent enough that it’s noticeable. When I take a second photo, the sound is there.

I just tried to duplicate the problem with the Camera app started cold and again with it brought up from the background, and the sound worked great. I have no idea how to get it to repeat, but I swear I’m not going crazy!

I did a quick web search and couldn’t find any reference to this issue. Has this happened to you?

OS X Calendar app quirk discovered!

Posted in Apple, Problems, Software on March 26th, 2014 by michael

I just added an appointment to OS X’s Calendar app. It’s supposed to run from 10:00 AM until noon. I go to the app and double-click on a date, fill in the event description and location, and then click on the date/time and get this:

Screen Shot 2014-03-26 at 5.09.06 PM

From the keyboard, I enter 10:00 AM as the starting time. Then I tab to the next line and try to enter 12:00 PM as the ending time. It won’t enter that time. It enters it as 10:00 PM, after which I have to go back and manually change it:

Screen Shot 2014-03-26 at 5.11.35 PM

In fact, it won’t let me type anything in the Hours space other than 11 until after I’ve changed the AM/PM indicator first. Now, I know I could do that and I know I could click on the time and select from Apple’s pre-ordained choices (from 30 minutes to 3 hours in half-hour increments). But what if I just want to type in an ending time? Don’t you think Apple’s programmers would automatically allow meetings to go past the noon/midnight barriers?

Am I the only one to discover this issue?

iTunes annoyance

Posted in Apple, Computer Science, Software on October 6th, 2013 by michael

05_Flatbed_2 - SEPTEMBER

Am I the only one who’s sick of the changes Apple keeps making to iTunes? It worked well before. Now it doesn’t.

The latest: they’ve eliminated the forward and back buttons from the Get Info window. Why did they do that? Those buttons weren’t hurting anybody.

I often want to edit multiple files’ information. I used to open the first one, edit it, and press the forward button to edit the next file. That worked okay, even after they changed it from a quick operation to a painfully slow one with iTunes 10 (or was it 9?). Now I have to open each file’s Get Info panel separately, taking about twice as long as the already painfully slow previous version.

Why did you do that, Apple?

Calculating hashes in iOS

Posted in Software on July 27th, 2013 by michael

simulat screenshot

I intended to follow up my last post (Implementing preferences in iOS – the wrong way) with a treatise on how to implement preferences the right way.  Even promised to do it.  But first a brief detour.

I wanted to write a quick demo app to show how to use NSUserDefaults to implement simple preferences.  For that demo, how about something that calculates the MD5 hash of an NSString?  We’ll call it Hasher.  Should be quick and easy, and I need the tech for the project I’m currently working on.  Did a little bit of searching and discovered that Apple provides a C library called Common Crypto.

But I’d rather code in pure Objective C.  A little more searching led me to Matt Gallagher’s excellent Cocoa with Love website and his HashValue wrapper class for Common Crypto.  Just the thing!  After a bit of confusion in using that class, which was written in 2009, I searched just a bit more and found Calvin Cestari’s slight updates that were last published in March 2013.  Download his code here.

Matt’s website does a fairly good job describing his code, but there’s nothing about using it.  So let’s put it together and make it run, shall we?

I started out by creating a new iPhone-only single-view application called Hasher.  For this demo, there’s no need to make an iPad version.

Create project

The storyboard is simple: two labels and two text fields.


In HasherViewController.h, I hooked the TextFields up:

@interface HasherViewController : UIViewController
@property (weak, nonatomic) IBOutlet UITextField *plaintext;
@property (weak, nonatomic) IBOutlet UITextField *md5Hash;

And also hooked the plaintext field up to HasherViewController.m:

- (IBAction)calculateHash:(UITextField *)sender

Next, I unzipped the file…


…and dragged the two files into my project.  The first time, I forgot to check the “Add to Targets” box.  Don’t follow my bad example there.


The API is pretty simple:

+ (HashValue*)MD5HashWithData:(NSData*)data;
+ (HashValue*)SHA256HashWithData:(NSData*)data;

- (id)initWithBuffer:(const void*)buffer hashValueType:(enum HashValueType)aType;
- (id)initMD5HashWithBytes:(const void*)bytes length:(NSUInteger)length;
- (id)initSHA256HashWithBytes:(const void*)bytes length:(NSUInteger)length;

In fact, we only need the two class methods:




For this example, we’ll only use the MD5 version.  If you’re planning on hashing passwords for real, though, please note that MD5 is considered to be broken.  Use SHA256.  I didn’t use it here because the 64-character hashes are too long to fit in my Text Field.

So we need just three lines of code.  First, we need to convert our NSString* to NSData*:

NSData* data = [self.plaintext.text dataUsingEncoding:NSUTF8StringEncoding];

Next, we simply make the call:

HashValue *hashValueMD5 = [HashValue MD5HashWithData:data];

And finally, we populate the Text Field:

self.md5Hash.text = hashValueMD5.description;

Before these lines, though, a tiny bit of housekeeping:

if ([self.plaintext.text isEqualToString:@""])
self.md5Hash.text = @"";

I discovered that, after generating a hash and deleting the plaintext, a hash is still created.  So the housekeeping lines above are just for appearance’s sake.

So here’s the entire HasherViewController.m file:

//  HasherViewController.m
//  Hasher
//  Created by Michael Morrow on 7/27/13.
//  Copyright (c) 2013 Business Casual Software LLC. All rights reserved.
//  Permission is given to use this source code file, free of charge, in any
//  project, commercial or otherwise, entirely at your risk, with the condition
//  that any redistribution (in part or whole) of source code must retain
//  this copyright and permission notice. Attribution in compiled projects is
//  appreciated but not required.

#import "HasherViewController.h"
#import "HashValue.h"

@interface HasherViewController ()


@implementation HasherViewController

- (IBAction)calculateHash:(UITextField *)sender
  // Blank out the results when the string goes away
  if ([self.plaintext.text isEqualToString:@""])
    self.md5Hash.text = @"";

  // Get and display an MD5 HashValue object
  NSData* data = [self.plaintext.text dataUsingEncoding:NSUTF8StringEncoding];
  HashValue *hashValueMD5 = [HashValue MD5HashWithData:data];
  self.md5Hash.text = hashValueMD5.description;


It’s that easy!  Oh, one more thing.  We need to be sure to import the Security framework and the libCommonCrypto library:

Screen Shot 2013-07-27 at 10.45.41 PM

At least I think I needed to import libCommonCrypto.  Maybe I’ll check that out later.

Next time, I’ll expand this project to include preferences.

Download the entire xcode project for this demo here.

New venture, new website

Posted in RoboWar, Software on April 15th, 2012 by michael

It may not look like it, but we’ve been working hard.  We’ve started a commercial venture called Business Casual Software.  We’re developing custom and semi-custom iOS and Android apps.  Our first app is already out – check out the Brewing Co. app!

We’ve developed a framework that we think will work nicely for musicians and event planners.  Have a look at our website and see for yourself.

In the meantime, spinfo dot info will continue to feature apps we develop just for fun.  In fact, we’re reconsidering (yet again) whether we want to tackle RoboWar.  Written as a Cocos2d game, it might just be doable.  Don’t bother us, we’re . . . thinking.


*** UPDATE *** As of February 2013, all our iOS and Android apps will be permanently featured here on spinfo dot info. will be used exclusively for software development topics and to support our terrain database support applications.  The business side of the business!  The fun all stays here.

We’ve (retroactively) added our third app to this site – The Brewing Co. app.  Check it out!