These people don't just need a fine. They need their entire corporation to be shut down with all the assets confiscated and all the responsible individuals sentenced to years in prison.
Friday, March 19, 2021
Friday, March 12, 2021
One application where I spoke too soon was Snapz Pro X. Despite MacWorld's lackluster review of version 2.5.1, it is still a very good screen capture utility that I consider superior in many ways to the one built-in to macOS.
When I wrote my review in December, I didn't really test Snapz Pro X. I launched it, saw that the menu appeared, then I quit it and assumed that it worked. I was wrong.
Wednesday, March 03, 2021
This morning, I found that my Mac’s screen wouldn’t wake up. The computer runs 24x7, with the screen blanking after a few hours of idle time. Nearly all of the time, I just tap a key on the keyboard to wake the screen when I want to use it.
This morning, that didn’t work. The screen remained asleep. I tried obvious things like hot-plugging the display and hot-plugging the keyboard, but no luck.
Wednesday, February 17, 2021
Love him or hate him, all can agree that Rush almost single-handedly defined modern conservative talk radio. My lunch-time radio listening will forever be less interesting without his voice giving me his opinions and analysis of current events.
Thursday, February 11, 2021
A remarkably simple attack revealing serious problems in corporations' open source package distribution systems.
Like most companies using open source software, they develop applications containing both public packages (which come from well-known and trusted Internet repositories) and private packages (developed in-house). In order to maximize reuse of private packages, they are deployed using an internal repository system, which automatically installs and an application's dependent packages, regardless of where they come from.
The problem happens because the internal repository system doesn't seem to distinguish between private and public packages. So if your application is using a private package, and later one a public repository adds a new package with the same name, the system may end up replacing your internal package with the one from the public server. And because automatic updates are common (in order to quickly incorporate bug fixes and security patches), these replacement packages may automatically get installed into publicly accessible applications.
Well that's not right.
Fortunately, this test was from a security researcher, who promptly reported the bugs, but this could just as easily been malware.
I don't think this should be hard to fix. Internal package management systems need to distinguish between public and private packages. When a given package name exists as both a public and a private package, the system *must* always give priority to the private package. It must also alert administrators and owners of affected applications to alert them to the conflics, so appropriate action may be taken. This action may be one or more of:
- Block the public package
- Rename the private package and update all applications using it so they use the renamed package
- Allow application developers to explicitly state in their package manifests if they want to use the public or the private version
Thursday, January 28, 2021
In part 3 of this article series, I described my application migration story. In this part, I'm (finally) finishing up the tale by talking about my various pieces of hardware that either worked or needed to be replaced. All of the work I'm describing here was actually done in October and November, but I'm just getting around to writing about it now.
Ideally, I would like to just swap the computer and leave everything else unchanged. But life is not ideal. Over the years, Apple has changed the port configuration of the Mac mini, so not everything can just plug in. At least not without some adapters. And some devices that were perfectly great 9 years ago are old and slow by today's standards. So it's time to change up several peripherals.
Friday, December 18, 2020
Thursday, December 10, 2020
In part 2 of this article series, I described the migration process to move all my stuff to the new computer. In this article, I want to share my experiences with application support. What just worked, what didn't work and what was easy and hard to make work.
As you probably know, the latest versions of macOS, starting from version 10.15 (Catalina), do not support 32-bit applications. No 32-bit application will work unless you run it on an older version of macOS (e.g. via a virtual machine). Apple has supported 64-bit applications for a very long time, and they have always been supported on Intel processors. Nevertheless, quite a lot of Mac apps in my possession were 32-bit. I'm not sure why, since 64-bit compilers were available on the Intel Mac platform since day-one.
Tuesday, November 10, 2020
Just when you thought Facebook had hit rock bottom. Now their adware network is being used for criminal extortion. And they're not even refunding the money to the victims who had their accounts hijacked in the process.
So glad I drop-kicked them to the curb many years ago.
Monday, November 02, 2020
In part 1 of this article series, I explained why I needed to upgrade my old Mac, what I bought, and the shipping process.
Now that the computer had arrived, the next step was to move all of my data from the old computer to the new one. In the past, I did this the hard way - I manually created user accounts (an administrator, my personal account, and accounts for my wife and daughter). I then copied all of our documents over the LAN, manually installed all the software I require, ending up with a working system. The whole process usually takes a week or two, plus all the time needed to configure my preferences in everything.
This time, I decided to use Apple's Migration Assistant utility to speed up the process. This, as it turns out, was a mixed bag. Some parts of the migration worked flawlessly, and other parts made a mess I had to clean up after.