Dwight Dickinson

Author: Dwight Dickinson

  • Migrating to Backblaze B2

    Earlier this year, my attention was drawn to alternative options to Amazon S3 for both user content storage (and delivery) and server backups. I’ve been using AWS (and S3 in particular since 2015) with great success and have continued to adopt it as my go-to object storage provider. Overall, I can count the number of issues I experienced with AWS on one hand.

    Alternatives!?

    I’ve been pointed to AWS alternatives plenty of times, but nothing ever seemed enticing enough to actually make the effort to switch (given my success and overall happiness with AWS). The desire to switch was lessened even more by the lack of compatibility in API calls. I noticed a lot of S3 competitors (such as Bunny) were focussing more on egress costs as well, which is important in a couple of my use-cases. These changes in the market are what finally convinced me to seriously begin researching alternatives and begin the initial decisions of whether switching is a task worth undertaking, or just moving to alternative services with new projects of mine.

    This decision to seriously look into the options was solidified when I realized that most of the major object storage options out there from all the major providers offered an S3 compatible API, significantly reducing the transition time for my projects (and even requiring no end-user update to make the switch). I decided that an S3-compatible API is absolutely mandatory for me to consider the object storage offering. This would give me the opportunity to make the transition quickly and with little change to my code, which provides an easier pathway back to S3 if I deem it necessary.

    Why Backblaze B2?

    I reviewed offerings from across numerous providers that offered an S3-compatible API (either partial support for most functionality, or full– with an obvious preference for full). As far as cost-effectiveness goes, which was important to me, Backblaze was the clear leader in my research. Backblaze also offered relatively cost-effective egress, and great partnerships with CDN companies for those projects that do have heavy outgoing usage. As dependability goes, B2 is a relatively new product; however, Backblaze appears to have been in the backup business for quite some time with an impeccable track record and a great relationship with customers. Additionally, B2 offers redundancy solutions that would check all the boxes I need checked.

    Other offerings couldn’t compete with Backblaze’s straight-forward pricing model, which is very clearly explained and doesn’t seem designed to confused, which is a nice change from the usual confusing class pricing model. Egress partnerships make this a very attractive offering for high-egress projects.

    Finally, the last requirement for my decision was S3 API compatibility. Backblaze B2 seemed reluctant to offer one at first due to additional costs; however, they appear to now not just offer, but encourage the use of their S3 API over their B2 API. Backblaze’s S3 API seems to be much more complete than a lot of competing offerings. Backblaze also offers some great versioning options with great control, very similar to S3’s feature-set.

    Overall, Backblaze B2 checked all the right boxes. Particularly when it came to user engagement and feedback acceptance. Backblaze seems to have a very public presence online and provides updates on upcoming roadmap items, as well as answering questions and concerns publicly and honestly. I have a high affinity for companies that take pride in their offering and actually act like customers exist and deserve to be heard. It was nice to see real responses rather than canned “create a ticket” answers.

    How’d it go?

    At the time of writing, I have now almost fully divested from S3 and am utilizing Backblaze B2 for most of my object storage needs. In retrospect, it was a very wise move and I was able to switch to a company that seems to care about their users (good for me and my users as well), and I was able to cut down my costs significantly while maintaining high availability and performance. While I’m still making modifications to my CDN providers for the best egress: Backblaze has proven to be a rock solid drop-in replacement for S3. Migration was also simple and quick with a relatively low startup cost for the migration (yes, my first months bill was higher than subsequent months due to transaction costs associated with the initial transfer).

    Overall, I’m thrilled that companies are deciding to offer cloud services and venture into providing these on a more cost effective, customer-focussed, and innovation-driven basis. I’m happy with this switch and I cannot wait to see further innovations in this space.

    It’s important to note that my decision to switch object storage providers was not motivated by issues with AWS S3 (as mentioned earlier, I’ve had almost no issues with AWS services). I’m grateful for the innovation and solutions that AWS has brought to the IT industry, and I was a very happy customer for years (even using them for HIPAA/PIPEDA compliant medical record backups).

  • Speech Jammer 5.1.4 Released

    Speech Jammer 5.1.4 has been reviewed and approved by Apple and is now available on the iOS App Store.

    This is a maintenance update that has performance improvements and framework updates to ensure that the app continues to run smoothly. Additionally, Speech Jammer 5.1.4 adds support for Macs using Apple Silicon (M1 Base/Pro/Max/Ultra and M2 Base/Pro/Max, as of writing). Find it in the Mac App Store.

    As the migration to Swift nears completion, I will begin to assess the possibility of writing a macOS version of the app to be deployed as a native app compatible with both Intel and Apple Silicon.

    This update adds new enhancements and features:

    • Bug fixes and performance improvements
    • Improvements for the latest versions of iOS and iPadOS.
    • Support for macOS 11 or newer (Apple Silicon required)

  • Starlink for RV: Our experience

    Entertainment while camping has always been at the front of our mind when considering upgrades to our motorhome. We’ve been using a few different options for RV internet, but none of them really offered a seamless experience.

    I’ve been following Starlink since their announcement, since I always believed that it had the real potential to be a game changer in the RV world. Our order was finally fulfilled in February 2022 and we began using it at home prior to the camping season. Shortly before our camping season began: Starlink offered the ability to convert residential services to RV, which would allow us to pause and resume service as desired. This was a perfect fit for us!

    Starlink Terminal

    I was very happy to receive the rectangular Dishy (Starlink Terminal), since it meant that it was easier to store. We got our RV dealer to install an access port to a bay that would house all our networking equipment. We actually prefer the mobility of the current user terminal rather than one that is permanently mounted on the roof. A roof-mounted terminal, while convenient, will start to dictate where and how we park our RV.

    We use the Starlink router in bypass mode and connected it to some Ubiquiti equipment using the ethernet adapter (yay dongles). Since our inverter powers all onboard outlets when shore power is gone, it means that we have Wi-Fi even during power outages.

    We also grabbed Starlink’s official storage case and it’s been perfect for storing Dishy.

    Performance

    We camp relatively close to major cities in most cases, so we are typically using cells that are occupied by rural users living slightly outside urban centres. We’ve also camped in very urban environments. According to the capacity map from Starlink: we are almost always in “Low Capacity” areas, meaning that our expected speeds could be as low as 5Mbps download. We were okay with this, since 5Mbps should still stream HD.

    We were also a little worried about tree cover, but we’ve only found one site that gave us even a slight amount of trouble with trees. Typical campsite tree obstructions don’t appear to be impactful to normal streaming. I suspect that connections that are more sensitive to hiccups or complete drops might have a bit of trouble if tree cover is extreme. In our case though, trees don’t seem to be giving us any trouble.

    Full speed ahead

    Starlink has outperformed our expectations during the entire camping season. It absolutely feels like our terrestrial home internet connection. Nothing about Starlink feels like a typical satellite internet experience (reminds me of when Royal Caribbean first launched Voom and it felt closer to a land-based connection). Websites load fast, videos stream immediately, and all of our Apple TV’s respond insanely fast when streaming.

    Our average speed over the camping season has probably been about 125Mbps down / 8Mbps upload. We frequently see over 150Mbps download in several areas. Latency is usually ~40ms-~80ms depending on the destination. US destinations typically have much lower latency than Canadian destinations.

    On several occasions, we can usually get over 200Mbps download, but our sustained download is usually around 150Mbps. I’ve downloaded (and uploaded) massive server backups, performed typical cloud operations, and did basically everything I’d do at home.

    Streaming Gaming (GeForce NOW)

    After streaming HD movies on our Apple TV’s in the RV and noticing the relatively low latency to US destinations: I decided that the numbers I was seeing in Speedtests were actually meeting (or exceeding) the requirements for a stable GeForce NOW session. I decided to put that 3080 tier membership to use and give it a shot.

    I was pleasantly surprised to find out that GeForce NOW was able to carry a 4K gaming session at 120FPS pretty much flawlessly. No disconnections and smooth gameplay. There was the occasional hiccup during my gaming session, which I attributed to slight satellite gaps or the switching between satellites (although it could just have easily been anything else like general networking hiccups).

    It certainly didn’t grant me the same flawless experience that my home connection gave me; however, it was a relatively smooth experience. It’s also nice to know that I have the option to fire up a game using GeForce NOW while camping.

    Final Thoughts

    Starlink for RV was probably one of the best investments we’ve made for our RV. We (like most people) are heavily using internet connected services that are thirsty for a lot of data. We also like having the conveniences of home in the RV, so being able to add the Apple TV’s to each TV in the RV to just grab a remote and browse/stream is a huge benefit.

    Ultimately Starlink for RV has done exactly as it has promised. Every time we setup Starlink at a new site, it performs flawlessly without any effort. We haven’t had so much as a hiccup while camping with Starlink. Our speeds constantly rise above 200Mbps and always support smooth HD streaming without buffering, despite us being inside “low capacity” areas on the map.

    I’d recommend Starlink for RV any day to anyone looking for mobile internet service while camping. I’ll continue to update this blog with new posts about how the service is performing for us.

    Thank you to Elon Musk and the entire SpaceX/Starlink team for creating and maintaining this service. It really is out of this world (pun-intended) and we hope to be a customer for a long time. It’s also rare that something gets announced and actually makes its way to market as fast Starlink has.

  • Ubiquiti AMPLIFI Alien: HomeKit bliss?

    HomeKit Home with 120+ accessories
    Our HomeKit home has grown to over 120 accessories and we needed a Wi-Fi router that could keep up

    I’ve been a pretty big fan of Apple’s AirPort lineup since around 2008. I’ve used the 802.11n Extreme’s and I’ve had two Time Capsule’s (the 802.11n and the last model in production: the 802.11ac tower). They’ve performed flawlessly at home and even in some small business environments. I’ve always been happy with them and they were one of the first consumer routers I’ve encountered that worked reliably without the need for any reboots or weird configuration changes.

    As I added HomeKit devices to the network, the 802.11ac Time Capsule handled everything like a champ. All devices stayed connected and were rock solid (and fast)… However, I had noticed that one of my IoT devices was showing a Wi-Fi issue. It only connects periodically, so I figured it was some interference at the moment it tried to connect. It wasn’t able to connect when I tried to manually connect it. I tried to reset it and input the Wi-Fi information again (thinking it was some sort of bug on the IoT device) to no avail. Then I realized that the number of devices on the 2.4GHz band was likely approaching some limit. I opened AirPort Utility and counted the 2.4GHz devices and sure enough: 32 devices on the 2.4GHz band. The 2013 AirPort Time Capsule must have a 32 device limit per band. This is when I made the decision to finally retire the AirPort in favour of a more modern router.

    Hunting for a replacement

    The criteria for my replacement would be pretty simple:

    • Consumer router with high performance. If I could not find a decent consumer router, then I was not against using an enterprise setup or prosumer setup. I really wanted a set and forget sort of system for my smart home.
    • Most Important: High 2.4GHz simultaneous client count.
    • Reputable company
    • Newer standards (Wi-Fi 5 at minimum to match the AirPort it was replacing or Wi-Fi 6).

    The Options
    Netgear
    – This one was ruled out almost immediately as their only official documentation on the website stated a 32 client limit per band across their entire lineup. I believe that this has changed recently, but it was still concerning to see it in the knowledgebase.

    Synology
    The RT2600AC and MR2200AC seemed like good candidates. Their website explicitly stated that they tested simultaneous client counts in the 100’s on each access point. I emailed them and received a response that there is no per-band limitation (I’m guessing 128 would likely be the line). Very impressed with their response time and that they explicitly stated their simultaneous client count tests (as a high number of simultaneous clients on the 2.4GHz band was the most important factor for me)

    AMPLIFI
    I am a huge fan of Ubiquiti and their consumer lineup interested me. I didn’t want to maintain controller software, AP software, and gateway software. This meant the AMPLIFI line was my best bet. They don’t list simultaneous client specs anywhere and seem hesitant to give any concrete numbers; however, anecdotal evidence on the internet had many users with 70+ Wi-Fi clients on the AMPLIFI Alien.

    The First Choice

    I originally chose the Synology RT2600ac. It was shipped by Amazon from their US warehouse (since I don’t believe the RT2600ac has Industry Canada certification, which I discovered a little later). It wasn’t the prettiest router, but it ran a familiar Linux OS with their SRM software on top of it. Upon initial setup, it worked well and I was very happy. Most importantly: connected over 32 clients to the 2.4GHz band. Success!

    Over the course of a couple of weeks, I was having some issues with some VOCOlinc light bulbs and devices. I couldn’t get them to remain connected and had trouble identifying the cause. Wi-Fi standards implementations are never 100%, especially in IoT devices and this was likely the cause of what I was seeing.

    I could get a ton of clients connected to the 2.4GHz, but some devices had some weird connectivity problems with no discernible pattern. Ultimately after a lot of troubleshooting and configuration changes, I ended up returning the router to Amazon in favour of an AMPLIFI Alien.

    AMPLIFI Alien

    I had the AMPLIFI Alien set up in no time (what a great little app) and was able to get all my devices connected to it over Wi-Fi (well over 32 clients on the 2.4GHz). As of writing, I have about 70+ clients connected to the AMPLIFI Alien and the connections are rock solid. My smart home network has continued to grow with the AMPLIFI Alien as the sole router solution and has handled the growth flawlessly. The ability to block IoT devices from the internet with a simple interface is an added bonus (since I exclusively use HomeKit cameras and products and don’t want the devices to be able to directly access the internet).

    Very rarely do I find a product that really gives me the confidence to recommend it without hesitation, but the AMPLIFI Alien really is one. It has turned my HomeKit home into a rock solid smart automation paradise. The router has great aesthetics and just looks cool. It’s managed by an app that exposes most settings you’d ever want to mess with in a consumer router. It plays really well with Apple devices and scales well with a large number of clients. It can also be meshed with additional AMPLIFI Alien units.

    If you’re looking for a reliable, simple, and powerful router for your HomeKit home: the AMPLIFI Alien may be a great fit. I’ve been using it for a little over a year now and it’s been rock solid while I continue to throw more devices at its 2.4GHz band.

  • Stanley/Whistler UT351 Limit Switch Replacement

    We currently have a Whistler (Stanley/Genie series) UT351 screw drive garage door opener and it has been in need of some repairs. Since the garage door opener has been rock solid reliable, and it’s connected exclusively to a HomeKit Garage Door Controller Accessory that I developed (so all garage door commands are sent encrypted through HomeKit), we decided that it’s best to repair the opener that’s worked for so long rather than gamble on a new brand.

    We repaired the motor coupler… However, there was another issue: all of the limit switches broke so they were being held to the track with a sophisticated mechanism of duct tape and carpet tape. This worked pretty well, but was becoming slightly problematic occasionally and required readjustment. Pretty problematic since if the limit switch slips, then the door will slam into the opener or into the ground with pretty decent force. We decided it’s time to replace these limits witches.

    The issue: discontinued

    Garage Door Opener Replacement Limit Switch
    Part 36850

    When we spoke to some garage door part distributers and discussed the parts we required, we were informed that limit switches are no longer produced for our garage door. We were able to find someone who sold, what was supposed to be, drop in replacement limit switches for our model. These are the Stanley-compatible Limit Switches (Part #36850). We ordered two of these and thought we were golden

    Surprise 2: our limit switches are wired together

    Original limit switch - one wire into opener and other wire proceeds to next limit switch

    This one surprised us during the switch. Our limit switches are wired together in sequence and not independently wired back to the opener (i.e. one wire proceeds down connecting both limit switches, with only one wire returning to the opener from the closing limit switch). We thought maybe this was expected, so we installed both switches in place of the existing wires.

    Plugged the opener back in and: surprise surprise… the opener started throwing an error indicating the limit switches were not connected. This made sense since the circuit would have to be completed for the opener to function properly, and this method of installing did not make that happen. The circuit could never complete since the reed switches would never be pulled closed at the same time.

    The fix: resistors to the rescue!

    To get these limit switches working, we’d need to complete the circuit by adding resistors to both limit switches between the wire coming into the limit switch and heading onto the next switch (or the opener in the case of the down switch).

    We used 5% resistors: 1.3k Ohms (first/up limit switch) and 2.2k Ohms (last/down limit switch). Rewiring is pretty simple:

    • Connect the wire from the garage door opener into the first/up limit switch lead wire. Also connect the 1.3k Ohms resistor to this wire connection that’s just been made.
    • Connect the last wire of the first/up limit switch to the existing wire heading to the second/down limit switch. Also connect the 1.3k Ohms resistor to this wire connection.
    • Connect the wire from the first limit switch into the second/down limit switch lead wire. Also connect the 2.2k Ohms resistor to this wire connection.
    • Connect the last wire of the second/down limit switch to the existing wire heading back to the garage door opener. Also connect the 2.2k Ohms resistor to this wire connection.
    New limit switch installation
    Excuse the mess here. This was simply a test to see if the theory works. The final connection will be much cleaner (and should be in your case as well)

    Hopefully this assists in wiring new limit switches to the the older screw-drive Whistler/Stanley/whatever other brand they sold this UT351 opener under. Remember: you’ll be using the existing wire coming from the garage door opener to the first limit switch, and the existing wire going from the final limit switch back to the garage door opener. Keep that in mind when cutting the old cable and using the crimp connectors. Make sure both wires in the new limit switches have a resistor that ensures the circuit can always complete.

  • Speech Jammer 5.1.2 Released

    Speech Jammer 5.1.2 has been reviewed and approved by Apple and is now available on the iOS App Store.

    This update adds the ability to export individual recordings off-line for sharing without uploading to the Speech Jammer Sharing Service. This was a big step for added privacy for users. Details are available below. This update also includes enhancements for the latest versions of iOS.

    This update adds new enhancements and features:

    • Ability to export single recordings without uploading to the Speech Jammer Sharing Service
      • Speech Jammer has long offered the ability to share recordings by uploading your recording (encrypted during transit) to the Speech Jammer Sharing Service, which would store your recording and make it available via a generated link. This gave enhanced compatibility by making sure the recording is shared as a standards-based MP3 file and always accessible through a highly-available service.

        With this addition, users can now choose to share an individual recording without uploading it to the Speech Jammer Sharing Service. This adds an additional element of privacy for users and allows them to instantly share an Apple-codec based recording file through iMessage or any other sharing service of their choice. This will not upload any file to our servers, and will not generate any link. You can share the actual recording file.

        The Speech Jammer Sharing Service remains available as an option and the choice to share offline or through the server is up to the user.
    • Enhancements for the latest versions of iOS
    • Performance enhancements

  • Start Usage Meter upcoming changes

    I wanted to write a quick blog post to comment on some upcoming updates to Start Usage Meter. Before I get into these changes, I wanted to circle back to my reasoning for splitting Start Usage Meter into two branches (perpetual 2.5.8.x, and 2.6 and beyond).

    Why the change?

    When I first started writing Start Usage Meter: I wrote it as a native Mac app and it was built from the ground up using Apple technologies. It was built to support as many older releases of OS X as possible from its birth. This meant that the app launched with OS X Lion support, even though it was released a couple of years prior to the apps development. I chose this for two reasons: (1) I felt it was important to support users on older operating systems, especially for a utility app where some users may not be able to progress past a certain OS and (2) I wanted to challenge myself to support OS X 10.7 Lion as long as possible, while still supporting the newest releases of the Mac operating system.

    This was relatively easy to do for a long time. If an API didn’t exist in an older version of macOS, then I created workarounds to create the same outcome wherever possible. The only downsides were that it took some extra work and maintenance with potentially a little less polish (e.g. base localization couldn’t be supported since I cannot target OS X 10.7 and build with base localization, which meant that I needed to create separate XIB’s for each language and maintain them all separately. This meant that each language may not be pixel perfect). Where critical API’s didn’t exist, I just didn’t display it to the user (e.g. Notification Center wasn’t available in OS X 10.7 Lion, so I don’t support it and didn’t display any options relating to it).

    I continuously announced my commitment to support OS X 10.7 for as long as possible and was able to keep it up for a while. I was able to work around the lack of new API’s in some cases. As long as my tools allowed me to continue, then I would.

    Then Xcode 12 was released. This new version of Xcode included the new macOS Big Sur SDK’s and offered some pretty cool enhancements. The downside? You could only target OS X 10.9 or later. I had to make a decision. Do I keep the app on an old toolset, convert to a different environment, or drop OS X 10.7 and 10.8? I ultimately settled on dropping OS X 10.7 and OS X 10.8 so I can continue to build for macOS using native tools and SDK’s; however, I decided to create a second branch of Start Usage Meter: Start Usage Meter 2.5.8, which I plan to back port critical fixes and improvements from the later versions. I will always distribute 2.5.8.x as a signed and notarized app and will do this for as long as possible. This lets me finally modernize the app.

    So what’s coming?

    I plan to release Start Usage Meter updates shortly for the Mac App Store version. 2.6 already has some improvements that were held back due to old OS support, such as base localization and new UI improvements.

    The upcoming releases will take this much further. I plan to transition Start Usage Meter entirely to Swift and modernize the codebase. There will be big UI improvements to help it feel even more like a new modern native Mac app (it is and always has been a native app, but older OS support meant holding back on some UI improvements).

    The immediate upcoming changes will have some pretty impactful UI interaction improvements, which should greatly improve the user experience.

    I just wanted to provide a bit of a heads up about what to expect from updates, and provide some additional clarity as to why the OS changes were made in the first place. I can’t wait to share the updates with you, and I hope it improves the experience as intended.

  • Modernizing servers and planning for the future

    I’ve been making several changes to my servers in an effort to modernize them while maintaining stability and reliability. There’s been a lot of volatility in the server OS market: from macOS discontinuing several server packages and options to CentOS moving to become an upstream distribution. This has resulted in more-than-expected adaptations in order to future-proof the servers and custom scripts/procedures. Since Apple still offers the ability to replace binaries for Server.app-managed services, I’ll likely be leaving macOS deployments on the latest OS with security update commitments. The plans are slightly muddied for my Linux servers, though.

    Latest Improvements

    I am was a pretty avid CentOS user and have been running RHEL-derived distributions on all of my servers (with the exception of office installations where macOS Server.app may be used for remote access and configuration). I have been making several configuration changes in an effort to modernize my CentOS server performance (congestion algorithm changes and more modern protocols), which required quite a few changes to packages since CentOS is a downstream operating system without inherit support for modern feature sets and I usually run a LTS release for at least a few years.

    CentOS becoming upstream

    The announcement from CentOS threw a wrench into a lot of my upgrade path plans and has forced me to re-evaluate my distribution choice. Although it may be easier to remain with a RHEL fork (like AlmaLinux) for binary compatibility: this sudden change is a little disappointing and is driving me to a different distribution with a long history. It has ultimately been a blessing in disguise and has lead me to move to a new distribution with a better commitment to open and free software with a focus on stability. I have experience with Debian and distributions based on Debian (like Raspberry Pi OS). I’m also a fan of FreeBSD, although I’d like to stay in the Linux world for portability of scripts. Debian’s staying power and consistency is really what I’m looking for and is my current planned route (Debian Stable with packages built from source).

    Migration Plan

    I’m excited to make these changes and have started migrating my servers to Debian. I’m taking this move relatively slowly with a lot of preparation. Thankfully, I’m granted this extra time thanks to back ported kernels and CentOS 7 offering LTS until 2024. This gives me the opportunity to focus on getting this migration right and with very minimal downtime. This allots me plenty of time to re-write scripts, if necessary, prepare new configuration files, and test.

    Current Status

    Although my primary servers are still running CentOS or some other RHEL fork and I am preparing for the migration to Debian or FreeBSD; I have already migrated some services to different distributions. For example, my secondary/tertiary nameservers are now running Debian or some distribution other than CentOS and have new custom scripts for maintaining them. So far, I’m very impressed with the maintenance of these distributions and am excited for moving all of my servers off of RHEL once I’m confident that I can maintain the current stability I have. For the time being, I’ve been able to improve performance and reliability with CentOS 7, but I am ready to move forward to have a better future-proof plan. I’m hoping to have an upgrade plan ready to be implemented around Bullseye Hard Freeze.

    Thank you to the CentOS community and RHEL for all the years of support and distributing stable operating systems! It has served me well and I was happy to be a user! I will still be dipping my feet in the RHEL world through future CentOS Stream versions for other use cases!

  • Start Usage Meter 2.6 Released

    New modern app build

    Note: Users running OS X 10.7 to OS X 10.8 or earlier must use Start Usage Meter 2.5.8.1, which is available from my website as an app verified by Apple and notarized. If you are running OS X 10.9 or later, then you should use the Mac App Store version as usual.

    Start Usage Meter 2.6 has been approved by Apple and is now available on the Mac App Store. As previously mentioned, this version only supports macOS 10.9 and later.

    This app has native support for Apple Silicon (looking at you M1 chip!). This marks the first version of Start Usage Meter that includes a universal binary. This update also contains a few fixes to polish the app. It also includes some minor UI tweaks for macOS Big Sur.

    • Modernized many parts of the application to use newer macOS technologies!
    • Native support for Apple Silicon. The app is now a universal binary
    • Fixes an issue where the daily usage window would not highlight the row representing today
    • Icon improvements for Big Sur
    • UI enhancements

  • Start Usage Meter 2.5.8.1 Released for OS X 10.8 and earlier (including FAQ)

    Note: Users running OS X 10.9 or later (including the latest versions of macOS) should use Start Usage Meter 2.6, which is available in the Mac App Store, built for the latest versions of macOS, and contains support for the newest Mac hardware

    Start Usage Meter 2.5.8.1 has been released as a notarized app and is now available. It is an Intel app.

    This update contains a few fixes for Start Usage Meter that have been backported from Start Usage Meter 2.6 (available on the Mac App Store for OS X 10.9 and later). This release has been checked and notarized by Apple.

    Start Usage Meter 2.5.8.1Download App

    SHA256 SUM (although unnecessary due to the fact that the binary is signed and notarized by Apple)
    Start-Usage-Meter-2.5.8.1.zip – a1129fe051bcc2c5e9dc9b5fe08ae585d2938b7e216301bfdf2de267a6b3fb60
    Start Usage Meter.app/Contents/MacOS/Start Usage Meter – 1b4abd4bbde01bb9e11beaeefd04a692371ef8bd4c2b893e1cd755ac3b8f36e1

    Start Usage Meter 2.5.8.1 has been released as a notarized app for OS X 10.7 or later, available exclusively through my official website. As previously mentioned and planned, this marks the first version that will not be available through the Mac App Store since version 1.5. It contains back ported improvements relevant to its current feature set. Notably, this update:

    • Fixes an issue where the daily usage window would not highlight the row representing today

    FAQ

    What’s notarization?
    Notarization is a feature from Apple that allows me to send my app to Apple for confirmation that it does not contain malicious content or anything that will harm your computer. It essentially offers the security advantages of a Mac App Store app, outside of the Mac App Store.

    Is the app still sandboxed?
    Yes. Start Usage Meter 2.5.8.x is essentially the same version you’d find on the Mac App Store if I were able to continue to offer it with support for the older versions of macOS. As the app and tools evolve, I’ll need to split the app into two versions; however, the security aspects of the app remain the same (i.e. the app is sandboxed and verified by Apple). Any release outside of the Mac App Store moving forward will always be sandboxed and notarized by Apple for your security. Always make sure you download from either the Mac App Store or https://dwightd.com.

    Why not just cut support?
    I’m really happy about my ability to continue to offer the app for all users on all operating systems. I’d like to continue that for as long as possible, and Start Usage Meter 2.5.8.1 represents my attempts to make this a reality. It contains a bug fix that is available in Start Usage Meter 2.6 on the Mac App Store. Although I may not be able to port all new features back to 2.5.8 for older operating systems, I’d really like to keep it running smoothly and issue free.

    Is it still a native app?
    Yep! Everything about Start Usage Meter remains the same as the Mac App Store build. It is still a 100% native app written using native Apple tools and languages. It does not contain any Swift code to maintain compatibility with OS X 10.7.

    Old Icon (Click to Download)

    Old icon?
    Start Usage Meter 2.5.7 changed the icon to follow the macOS Big Sur design language. Since 2.5.8 was the last version to support OS X 10.7 and it contained the Big Sur icon, I’ve left it the same way in 2.5.8.1. That said, I have attached the 2.5.6 icon and you can copy it and paste it in the icon field by clicking the icon in the apps “Get Info” window.



    Side note: the icon was slightly reduced in size in Start Usage Meter 2.6 to better match the rest of Big Sur. 2.5.8.1 contains the original, slightly larger, Big Sur icon introduced in 2.5.7.