Full Width [alt+shift+f] Shortcuts [alt+shift+k]
Sign Up [alt+shift+s] Log In [alt+shift+l]
35

Using WordPress is risky

from anderegg.ca [alt+shift+b] in technology

It’s been a couple of weeks since I last wrote about WordPress. Stuff’s been happening in the background, but I’ve been trying to ignore it. This morning I read a story that bothered me enough to require another round of therapy-by-blog-post. First up, a couple of things that have happened recently. One is that Matt Mullenweg wrote a post about how his freedom of speech was being curtailed by WP Engine. My reading of the post is that blocking WP Engine from WordPress.org is “speech”, and WP Engine shouldn’t be allowed to file an injunction to prevent this. Several people in the community pushed back. I’m not a US citizen, or an expert on the First Amendment, but I find the “free speech” argument a bit weird. Mullenweg has been blocking people on X and disabling people’s WordPress.org accounts if they disagree with him. He also threatened the person running bullenweg.com with legal action. The site, which had been chronicling the drama, has since been taken down. These don’t seem like the actions of someone who values free speech. Anyway, if you’re looking for a place that follows the drama, there’s now Matt is not WordPress. It has more examples of people being blocked from official WordPress resources. This all felt aggravating and stupid, but it wasn’t anything new. I continue to believe that Mullenweg only wants yes-people around him, so these actions fit. This morning, though, I read an article from The Verge covering the latest legal filing from Automattic/Mullenweg. It’s a light piece, but it highlights some passages from the filing. One of them made me feel like I was going mad. Here it is from a PDF of the filing uploaded by The Verge. You’ll find this on page numbered 6 of the PDF, starting on line 5: The mere fact that WP Engine made the risky decision to base its growing business on a site to which it has no rights or guarantee of access, without making backup plans, is not enough for it to conjure a claim out of legal thin air. Similarly, WP Engine’s...
1st Nov 2024

Stay updated

Get a weekly newsletter with the top 5 articles worth reading every week.

More from anderegg.ca

Two more 27.0 design grumbles

After living with Apple’s 27.0 OSs since launch, I have some more annoyances to get off my chest. This time, it’s all about how tabs and menus have gotten worse. I’ve already ranted about the Liquid Glass material in general, but these two design changes in particular have really been grinding my gears. I’ll reiterate that Apple’s latest OSs look substantially nicer to me than the previous set… but that only makes these setbacks more glaring. Also, many of these issues aren’t nearly as bad in light mode — but I use dark mode exclusively on all platforms. Apple offers this appearance setting, so I think it’s fair to criticize them when it’s not holding up. First up, let’s talk tab bars. I think these looked awful in the original Liquid Glass redesign, and in 27.0 they look even worse. Below is an example of three tab bars from Safari in macOS. All of them are in dark mode. The top example is from macOS 26 with the “clear” Liquid Glass setting, the middle is macOS 27 with the default (mid-slider) version of Liquid Glass, and the bottom is macOS 27 with Liquid Glass at its most tinted. In each, the middle tab is selected (though I think the word “tab” is being quite generous to these globs). In macOS 26, there was practically no difference between the clear and tinted versions of tabs. Similarly, the clearest and default/middle tabs in macOS 27 are effectively the same. Because of this, I’m leaving out the redundant examples. Even though I still think it’s ugly, I vastly prefer the macOS 26 version of these three options. It offers the most contrast, and it makes more sense in dark mode: the background is darker and the foreground of the active tab is lighter. The middle example is what tabs look like in the default (mid-slider) version of Liquid Glass in macOS 27. There’s now only a very faint outline around the active tab, and practically no difference in background colours. To me, this is unreasonably subtle. The effect is even worse when there are a lot of tabs open. Lastly, there’s macOS 27 with the fully tinted Liquid Glass setting. It’s better, but it still looks less correct to me than the tab design from macOS 26. It’s difficult to put into words how much I loathe the look of this new tab bar design. I don’t mind the more “bubbly” look of Liquid Glass throughout the 27 OSs for the most part. It gives UI elements more dimension than in the 26 OSs. But it doesn’t work for tabs. Because the bubbly look is inside a trough, the active tab’s glass effect ends up looking like a blur on the top and bottom. This reduces contrast further and makes the active tab harder for me to pick out. Even in dark mode with full tint, I find the active tab less visually clear than in 26’s clear mode. Now, I’m sure there are at least a few people reading who don’t see what the fuss is about. If that’s you, I assure you that the difference is more stark when you’re not comparing things side by side. It’s not impossible for me to pick out the active tab, but I think it’s trickier than it needs to be! But, if you still don’t believe me, here’s a little experiment. Which of these do you think is most legible? The text/background colours in the above image are based on the foreground/background colours used in the tab bar instances above. First is clear in macOS 26, then the default from macOS 27, then fully tinted in macOS 27. I think they’re all pretty awful, but I prefer the macOS 26 clear version. Again, this is because I’m using dark mode. In dark mode, light text appears on a darker background. Similarly, active UI elements have a lighter background than their surrounding elements. I’m sure there are counter-examples, but this is how just about everything else works in Apple’s own apps! It should be noted that Safari uses the system default tab bar design. I also see this design in Apple’s Terminal app, in Pixelmator Pro, and elsewhere. I don’t use Xcode daily anymore, but you’ll also find them there — though in true Xcode fashion, they’re ever so slightly nonstandard and also don’t respect your tint setting. Below is a screenshot of Xcode using my current settings of dark mode with fully tinted Liquid Glass. Up next: menus. Below is an image showing four versions of the same menu in macOS. Top left is macOS 26 clear, top right is macOS 26 tinted, bottom left is macOS 27 default (mid-slider), and bottom right is macOS 27 fully tinted. It’s a similar story here. In macOS 26’s dark mode, I had no problem with system menus even when Liquid Glass was set to clear. In macOS 27, even in the fully tinted mode, the menus have much lower contrast. They also now lose all of Liquid Glass’s refractive effects when at their most tinted. I think this is less of an issue than the tab design changes, but it’s still a downgrade. Again, I’m certain many people don’t care about this. Some might wonder why I’m not turning on accessibility settings to help with these things, if they bother me so much. I’ve flirted with this (especially the “Increase Contrast” setting), but those settings have many knock-on effects. 1 But honestly, I don’t think accessibility settings should be required to have a reasonable amount of contrast in a design system. Maybe Apple disagrees, but I really hope more dark mode tweaks are coming. The “Increase Contrast” setting is under System Settings -> Accessibility -> Display -> Increase Contrast. Interestingly, you can use this setting along with the clearest version of Liquid Glass to almost get back to how things looked in macOS 26’s version of tinted. However, it adds contrast-y lines around many UI elements that I find extremely distracting. It also alters colours on some elements to, strangely, make them less contrast-y. It feels unevenly applied and poorly implemented in several apps. ↩

2nd Oct 2026 • 1 votes
The Talk Show Timeline

I really enjoy John Gruber’s podcast The Talk Show. However, I’ve noticed that it’s been a while since it was in my feed. I decided to chart previous episode dates to check some of my assumptions about release frequency. Cutting to the chase, here’s a link to The Talk Show Timeline. You can click/tap on days to get a pinned tooltip, which lets you link out to a particular day’s episode. I’ve tried to make this work well on mobile devices, but you’ll likely find it works best on desktop. A note about this: Gruber has mentioned in the past that there has been a personal situation that he’s been working through. He’s also mentioned something to this effect on the podcast at points, but hasn’t gone into detail. I don’t need to know more than has been said, and I just hope things are alright. I’ve read Gruber’s site since 2002 1 and listened to his podcasts since 2007. In that time, I’ve learned that he operates on his own timeline… and has a penchant for procrastination. No shade here! He’s set himself up with a work situation that I envy. I also don’t want to seem grumpy about the lack of podcast episodes; I’m just trying to understand how this current break compares to those in the past. Because it was easiest, and because it would answer my immediate questions, I only looked at the current iteration of The Talk Show. Happily, there’s a single page which lists all the episodes. It had a tiny bit of data weirdness, 2 but I was able to turn this into a JSON file with the details I cared about. With that, I used the calendar heatmap chart in Apache ECharts to display the episodes over time. Some things I noticed: While it’s been a while (29 days) since the last episode (on August 10), this isn’t unheard of. The average is about 12 days between episodes, but there have been 6 other times when the episode gap has been at least this long. The longest gap was 62 days between December 24, 2024 and February 24, 2025. There’s exactly one day with two episodes: July 19, 2014. It was “Cat Pictures” with Marco Arment, which got split into two “sides”. Here’s a link to side 1, and here’s side 2. I mentioned procrastination: 73% of episodes take place on the 16th of a month or later. 28% of episodes take place on either the last or second-last day of the month. Again, no shade! It’s something I chuckle about whenever I notice it. At the current rate, this year is about in line with output going back to 2023. While it has been a while since a new episode dropped, it’s not out of whack statistically. Anyway, this was a Labour Day project that was mostly for my own amusement. I expect there will likely be a new episode of The Talk Show some time fairly soon after tomorrow’s Apple event. I also don’t know if I’ll keep this chart up to date… though it’s not terribly onerous to do now, so who knows. I found Daring Fireball because I was researching the purchase of my first Mac around this time. It wasn’t until October of 2002, but I ended up buying one of the machines he wrote about in his first post that August. ↩ The following dates don’t match the main format: Sunday 30 November, 2025 Mon, 24 Feb 2020 16:05:34 EDT Tuesday 31 December 2019 Tuesday, June 25 2019 Sat, 16 Mar 2019 19:43:49 EDT Wednesday 31 December 2014 Monday, 30 Jun 2014 ↩

8th Sep 2026 • 1 votes
Bubbles.town

I mostly use my web stats service because I get a lizard-brain kick from watching numbers go up, but it also provides some fun insights. For example, it’s how I found out about bubbles.town. At first I thought this might be a Mastodon instance. I get a lot of referral traffic from Mastodon, but each instance has its own URL. You can guess at mas.to, but dice.camp doesn’t provide many clues. Bubbles, as it’s known, is a very nice service. It aggregates a curated list of indie blogs. People can sign up and vote for posts they enjoy, but they can’t submit new articles. Authentication and comments are both handled using Fediverse technologies. In my case, I was able to log in via my Mastodon instance. The idea is to highlight cool indie writers around the web. I love this sort of thing so very much. Anyway, this is all to say that you should check out Bubbles. Seeing a blog-based reaction to one of my posts on the service filled my heart with immense joy.

9th Aug 2026 • 1 votes
An infuriating goodbye to Photoshop

I’ve been using Photoshop since the mid-90s. First at school, with Photoshop 3, then through work. I bought my first boxed copy of CS2 in 2005, then upgraded to CS5 in 2010. I subscribed to Photoshop Creative Cloud on day one. Today, I uninstalled it. I hope I never have to use Adobe software ever again. Photoshop used to be a joy to use. Whenever I got access to an upgraded version, I’d always have fun exploring the new features. I got really good at using it. When Adobe launched the Creative Cloud version of Photoshop in 2013, I signed up immediately. The subscription meant I would always have an up-to-date Photoshop, and I loved the idea that new features would be rolled out more frequently. But over time things started getting worse. Slowly at first, but then much more quickly. Originally, the Creative Cloud app was native and relatively useful. I wasn’t ever excited to open it, but I certainly didn’t mind having it installed. At some point, it became a terrible web-based app. Over time it felt slower and more broken. One thing I loved as part of the Creative Cloud subscription was the Creative Cloud Synced Files service. Basically, it was Adobe’s version of DropBox. I used it all the time to share screenshots and samples of in-progress work. Then, in 2023, Adobe announced they’d be discontinuing the service. There was so much pushback that they delayed the service’s retirement for a year. It makes sense, it was a nice feature of the subscription plan and businesses had come to rely on it. This was the first time I started questioning my Creative Cloud subscription. Out of curiosity, I looked around at the available options. I played with Pixelmator Pro, Acorn, and Affinity Photo. They were all fine, but I couldn’t let Photoshop go. I just knew it too well. But I also started realizing how little I was using it. I used to do a lot of traditional web development. In days of yore, this involved getting Photoshop mockups from designers. Those images needed slicing into pieces that you’d use to build a site or an app. But I hadn’t gotten a Photoshop document from a client in years. The PSD had been replaced with Sketch files, then with links to Figma documents. I still used Photoshop to touch up images, but that really didn’t use much of its power. The only thing holding me to the product was familiarity. Then I started to notice some real quality issues. For some reason that I still don’t understand, my copy of Photoshop stopped updating. I didn’t notice for a while, but eventually I stumbled upon the release notes and saw that I was something like nine months behind. I was able to fix this by forcing the Creative Cloud app to reload its settings using Command + Option + R, at which point I could update. Then, a few months later, Photoshop updates started getting stuck. I’d start an update, but it would spin for hours but never complete. I was able to fix this by uninstalling Photoshop using the Creative Cloud app, then re-installing it… but I had to do this more than once. Soon after that, every new Photoshop update would reset my preferences to the defaults. I’d need to take 5 or so minutes to re-apply my settings every time. A little while later, Adobe started silently updating my /etc/hosts file for license verification purposes. As posited in that link above, the Creative Cloud app now felt like malware to me. But that wasn’t all, Photoshop itself had started feeling terrible. There was now an annoying welcome screen that would re-appear for me whenever I didn’t have an image open. There was an option to disable it, but the option was reset every time I relaunched Photoshop for a couple of releases. Then Adobe decided to replace almost all of Photoshop’s native UI controls with web-based ones. This was the final straw. I’m sure some of these issues were special cases for me. Something that got stuck somewhere, maybe. I’m a developer, so maybe my tooling was interfering with something? Only: every time I ran into an issue, I’d see dozens of people complaining about the same thing on the Adobe support forums. It really felt like Photoshop and the Creative Cloud app had grown into blobs of pain that Adobe no longer knew how to properly maintain. As this was happening, Apple had released their Creator Studio service. For the same price as my Creative Cloud Photography plan, I could get an updated version of Pixelmator Pro, plus a bunch of other great apps. I’ve since signed up and haven’t looked back. But Adobe wasn’t done with me yet. It turned out that my subscription, which had been going since 2013, was on an “Annual Paid Monthly” plan. Even though I was getting billed monthly, I couldn’t actually cancel any time I wanted. I had sort of remembered this being a thing when I signed up, but had long since forgotten about it. Anyway, the one-month window to cancel without a termination fee recently arrived, and I got around to cancelling today. Cancelling required me to log into my Adobe account on the web. No problem, I thought. I had set up Adobe Authenticator, and had used it dozens of times to log in before. This time, however, the authenticator app needed me to log in. To log into the authenticator app, the app asked me to use the app to authenticate the app. Sorry? This was, of course, impossible. Eventually I figured out that I could use an alternative method to log into the app, so I could then use the app to authenticate my web session. This felt bone-headed, but whatever. I then received the following email. There’s nothing hidden here, this is the full contents of the message. At this point, though, I was actually able to start the cancellation process. The first screen of the cancellation flow looked like this: Here’s what it looked like after selecting things: I guess no one at Adobe uses dark mode? Anyway, the next 3 steps included Adobe begging me not to cancel, and even offering me three free months. This process had not convinced me I’d be happier staying. But even after completing the cancellation, I wasn’t done. I now wanted to uninstall everything. The Photoshop part of this was easy enough using the uninstaller app in the /Applications/Adobe Photoshop/ folder. The Creative Cloud app was more stubborn. There was also a link to an uninstaller for it in the /Applications/Adobe Creative Cloud/ folder… but running it failed with the error: Couldn’t uninstall Creative Cloud for desktop. You still have Creative Cloud applications installed on your computer that require it. Weird. The only other “app” I had installed was Camera Raw, which was just a plugin. There was also no way to uninstall it inside of the Creative Cloud app. I was able to find the plugin in /Library/Application Support/Adobe/Plug-Ins/CC/File Formats/. Deleting it and relaunching the Creative Cloud app showed that it was now no longer installed. I tried running the Creative Cloud uninstaller again, but I got the same error. This time I tried the “Repair” option, offered as part of the uninstaller, but that also failed. So I then tried the Creative Cloud Cleaner Tool… but this failed, too. At this point I was really annoyed, so I decided to manually remove things. I do not recommend doing this yourself, but here’s a general list of the stuff I got rid of: Under /Applications/: all the Adobe folders Under /Applications/Utilities/: all the Adobe folders The /Library/Application Support/Adobe and ~/Library/Application Support/Adobe directories, as well as any com.adobe.* files Under /Library/Preferences/ and ~/Library/Preferences/ all the Adobe* and com.adobe.* files Under /Library/Caches/ and ~/Library/Caches/ any Adobe* directories Under /Library/LaunchAgents/, /Library/LaunchDaemons/, and ~/Library/LaunchAgents/ directories: all the com.adobe.* files Under /Library/PrivilegedHelperTools: all com.adobe.* files Under /Users/Shared: all Adobe* directories Let me reiterate: you should not follow my lead here. I likely missed some things, and it’s very easy to mess things up by deleting system files. I offer no support if you decide to follow these steps. Again, it’s quite possible that there’s something weird going on with my machine or my installation… but I swear I never did anything but use the Creative Cloud app to manage things. I expect Adobe to be able to clean up their mess if they’re going to install files all over the friggin’ place. Anyway, all this said, I’m still slightly sad to be rid of Photoshop. Pixelmator Pro suits my current needs, but there are definitely things I will miss from Photoshop. Pixelmator Pro’s UI is a bit of a Liquid Glass nightmare, but it’s a massive improvement in terms of software quality. I’m extremely happy that it doesn’t strew zillions of files across my computer. I’m also pretty certain it will be much easier to unsubscribe from if I decide to do so in the future. So long, Photoshop. I’ll remember the old days fondly, but you are well past your prime.

12th Jul 2026 • 2 votes
Thoughts ahead of WWDC 2026

I’ve been following Apple news and rumours since the year 2000, and I don’t think I’ve ever been less excited for WWDC. Apple’s software story is in rough shape, and I worry that this year’s event won’t do much to help. Perhaps it’ll be the beginning of an upswing, but we’ve got quite a way to go. Before looking forward, let’s look back. WWDC 2024 focused on a number of “Apple Intelligence” features that never materialized. Which is probably for the best because the features that did ship that year were annoying at best and awful at worst. WWDC 2025 introduced a new redesign that I was initially looking forward to… until I saw it in practice. This year, the scuttlebutt is that WWDC will once again be about LLM-based features. Many of those features sound like re-announcements of the ones from 2024. I wasn’t excited about them then, and I’m still not now. If there are Apple Intelligence features announced on Monday, I hope they’re actually useful and not just shoehorned in. It’s reasonable for Apple to do something to improve Siri, but it’s been terrible for so long that I’ve found much better alternatives. I also worry that Apple risks overloading people with “AI” features. Microsoft only recently started learning their lesson about this, and it would be a real shame if Apple wasn’t taking notice. Given Apple’s recent track record, I’m not optimistic. I wish Apple would be content with its excellent place as a platform for machine learning and LLM-based work. I truly believe that local LLM use is the future, and it’s a future with far fewer downsides. I would love for Apple to focus on this, as it’s something they’re already doing well. None of the rumours have hinted at local LLM improvements, but it’s more developer- than user-focused. Maybe there will be more news at the State of the Union event after the keynote. My guess is that most AI features announced will still be sent to a server farm, and will likely involve subscription fees. There’s also been talk about tweaks to the Liquid Glass design language. I’m somewhat more hopeful about this, but still concerned. Apple’s head of design changed late last year, but that’s not much lead time. If there are changes, they won’t be drastic. Apple spent a lot of time re-architecting parts of the system to support Liquid Glass, and then asked developers to update their apps to support those changes. There’s no easy way to revert things, and we’d be in for another rough year of software quality if they tried. Instead, we’ll get minor tweaks. Here’s hoping for more design concerns to be addressed. The other thing I’ve heard is that this could be another “Snow Leopard” year. That is, Apple may have spent the last year fixing bugs and optimizing things. I’d be very happy if this was the case, but it is a bit at odds with all the AI rumours. Even if Apple has been doing a lot of polishing, it’s a difficult thing to market. Maybe Apple could brag about the number of bugs they’ve squashed? That would make me very happy, which tells you the sort of person I am. It’s definitely not exciting, but it’s the thing I’m most looking forward to. I’ve been worried about the direction of Apple’s software quality for a while. Their hardware game has never been more on-point, so it’s potentially hopeful that the head of hardware will soon be the new CEO. But this change, like the change of design lead, isn’t happening in time to affect this year’s WWDC. Maybe I’m wrong to worry. Maybe Apple will surprise me tomorrow. Sitting here today, I’m much more interested in what WWDC 2027 might look like.

7th Jun 2026 • 2 votes

More in technology

Anecdata: running shucked WD My Book/Easystore 8TB hard drives for over 5 years

Sharing a few data points because some people did not expect these drives to last that long.

8 hours ago • 1 votes
Prove you are not a child

I'm 100% for banning social media for children. I would even extend it to banning it all together in its current form. But I am also against the methods for enforcement. The problem with banning social media for one group and not another is that you have to differentiate the different groups somehow. And right now, in an age where information and personal data means everything, there are several entities that are salivating to get this data. I've written before about all the problems that come from uploading sensitive data online. It doesn't even matter if they delete the data afterward, as long as the data goes through the wire in the first place, there is a chance for a leak. What appears to be the same simple request "please verify your identity", becomes fundamentally different when mediated by technology. The question isn't whether these digital systems will be compromised, but when. And unlike that movie theater clerk who can't perfectly recall my birthdate minutes after seeing it, computers have perfect memory. They store, copy, backup, and transmit our most sensitive information through networks we don't control, to companies we've never heard of, under policies we'll never read. When kids are not allowed to use social media, it's the adult who pays the price. It's the adult who has to prove that they are not children. They have to risk uploading their government ID to a third party, or biometric data that may be saved and backed up forever. I reject this method. I also reject the method where I have to provide my age to the operating system. No system should compel me to provide personal data in order to use it. Especially if this feature is intended to provide the information to a third party. And what happens if I don't provide this information to my freebsd machine? Or worse, what if I provide false information? Am I going to get punished? How does that protect children in any way? Breaking news: Grown up arrested when OS reported forged identity in his laptop. One question I asked myself was what happens when a minor circumvents the ban. What are the consequences? At least in Australia, a country that has implemented a social media ban for those under 16, there are no consequences. The law places legal responsibility on platforms, not children or parents, and it currently applies to Facebook, Instagram, Kick, Reddit, Snapchat, Threads, TikTok, Twitch, X and YouTube. This almost sounds reasonable. Why should you care, if it becomes facebook responsibility when you don't even own a facebook account? But there is always a caveat. When facebook becomes a tool your school uses to communicate with parents. When Google classroom is the service students use to do their homework. When you are required to login on a system to receive government service. You may not care about a particular social media, but they raise the bar for every other entrant in the game. Every website frequented by a large number of people inherently become social media, and demand data you didn't need to provide before. Technology is not a magical thing that can just solve every problem. It is especially weak when it comes to social problems. However, society can use technology to solve their problems. The responsibility of children falls onto their parents. And there are great tools for parents that their kids access on their devices.

12 hours ago • 1 votes
Intuitive Estimation of the Number of Error Correction Bits

Introduction Hamming Distance Intuitive Estimation of Error Correction Bits Digging Deeper Comparing against BCH Codes What about Reed-Solomon Codes? BCH vs Reed-Solomon Codes References Footnotes Introduction I’ve been interested in error correcting codes (ECC) for a while now, and though I haven’t gotten very far, I keep on reading and, occasionally, writing about it. Except for really simple schemes, ECC theory gets complicated quickly. The two codes that I’ve looked at most are Reed-Solomon (RS) and binary Bose–Chaudhuri–Hocquenghem (BCH) codes. They are closely related: both use polynomial math that is normally performed over a Galois Field, though, as shown in my earlier Reed-Solomon blog post, that’s not strictly required. The encoding algorithms are relatively straightforward but the decoding algorithms are significantly more complicated. RS and binary BCH codes differ in the size of their symbols, their alphabet: a symbol of the former consists of multiple bits, often 8 bits, while a symbol of the latter is a bit. Errors are corrected with a granularity of a symbol. One key ECC question is “How many additional bits do I need to correct a given number of errors?” In this blog post, I check if an intuitive approach that I’ve been using matches reality. I’m trying hard to stay away from theory here, which makes the subject hopefully more accessible, but has the flip side that it’s far from being rigorous and exact. Hamming Distance When you look at the theory of error detecting and correcting codes, the discussion immediately turns to Hamming distance: the number of bit flips required to convert one vector of bits to another. The goal of an error correcting code is to transform the input vector, the message, to an output vector, the codeword, so that the minimum Hamming distance between valid codewords is guaranteed to be at least a certain number. The higher the Hamming distance, the higher number of bits that can be flipped in a codeword without destroying the ability to recover the original message. If \(t\)1 is the number of errors that we want to correct, error coding theory gives us the following formula: In words: to correct a codeword with a maximum number of \(t\) bit errors, the Hamming distance between any 2 codewords must be larger than two times \(t\). The theory also tells us the minimum Hamming distance to detect an error without correcting it: In the rest of this blog post, though, we’ll only care about correction, not detection. Here are 2 quick examples where the message is one bit. Adding 1 bit to the message For a one bit message, there are only 2 possible messages, 0 and 1. Let’s use a code that repeats this bit once: 0 becomes 00 and 1 becomes 11. The Hamming distance between these 2 valid codewords is 2 because you need to flip 2 bits to convert 00 into 11. The equation above tells us that a distance of 2 is not sufficient to fix a one-bit error. Indeed, when we receive 01 as a codeword, it’s impossible to tell if the transmitted codeword was 00 or 11: both have a Hamming distance of 1 to the received word of 01. Adding 2 bits to the message When we expand the 1 bit message to 3 bits and repeat the message bit twice, things are different: 0 transforms into 000 and 1 into 111. The Hamming distance between all possible codewords is 3. The theory says that we should be able to correct a codeword for which only 1 bit was flipped. And indeed, if we receive 001 and there is only 1 bit corrupted, we know for sure that the original message was 0. Intuitive Estimation of Error Correction Bits The concept of a minimum required Hamming distance to correct a number of errors is not particularly complicated, but it’s a different matter to use it to determine the number of additional ECC bits for, say, a BCH code. In fact, I still don’t know how to do it. As an alternative, I found myself using a simple model that works like this: Participant A transmits 1000 bits to participant B over a noisy channel B transmits the same 1000 bits back to A over a perfect channel A transmits a 10 bit error index to signal to B which bit it received wrong Or more general: If a message of \(k\) bits has 1 incorrect bit, you need a number of \(r = \lceil \log_2(k) \rceil\) 2 bits to point out the incorrect bit. Let’s call that number the error index3. To correct \(t\) bits, you need up to \(r = t \cdot \lceil \log_2(k) \rceil\) additional bits. That’s it! The model is simple, it’s not exactly practical, and the number of parity bits has to be only a first order estimation, but I felt like it had to be pretty close to reality. But is it? Digging Deeper Let’s consider some of the aspects of this model: There is no way to signal that there was no corruption That can be solved by allocating one error index value extra to signal a perfect transmission and calculate the number of bits as \(r = \lceil \log_2(k+1) \rceil\) instead of \(r = \lceil \log_2(k) \rceil\). E.g. for a 1000-bit message, an error index from 0 to 999 indicates an error location, and 1000 signals perfect transmission. For messages that are not a power of 2, the number of error indicator bits remains the same. The transmitted error indicator bits can be corrupt as well One way to solve this is by going through the same procedure to verify the error index. For a first iteration, it would cost an additional \(\lceil \log_2(\lceil \log_2(k+1) \rceil ) \rceil\) bits, 4 bits for a 10 bit error index. Of course, those 4 bits might be corrupt too! A better approach is to work backwards: start out with the length of the codeword and the number of errors you want to correct and determine the number of input message bits from there. The number of error indicator bits is then calculated over the length of the codeword and you get \(r = \lceil \log_2(n+1) \rceil\). The length of the message is \(k = n - r\). This breaks the simple model where you transmit message and error indicator separately, but that was not a realistic scenario anyway. It doesn’t consider that the same error index can appear only once If the code can correct 2 errors, you’d need \(\lceil \log_2(k+1) \rceil\) bits for the first error index to indicate zero errors or the location of the first error. For the second error, you need one less value because one location has already been corrected, so the number of bits needed is \(\lceil \log_2(k) \rceil\). This suggests that the number of error indicator bits might be an upper bound. It only applies to error correction the way BCH does it Any random bit can be corrected, but it doesn’t work for RS coding because there a whole symbol can be incorrect. That’s fixable though, I get to that later. You don’t need to signal the correct value Since the symbol is 1 bit in size, the location of the error is sufficient. To fix it, the receiver just needs to invert the bit. This also doesn’t work for RS. Comparing against BCH Codes Forget about using the Wikipedia article to compare the intuition against theory: you won’t find anything explicit. I found this presentation from the National Taipei University useful. The key formulas are on the first slide: Block length: \(n = 2^m -1\) Number of parity-check bits: \(n - k \le m t\) Minimum distance: \(d_{min} \ge 2t + 1\)4 In the equations above, \(k\) is still the length of the original message, \(t\) is the number of bits that can be corrected, \(n\) is the length of the codeword. If we rearrange the first equation, we get: Substitute \(m\) in the second equation: \(r\) is the number of error correction bits, so \(r = n - k\) and: Compare this with the intuitive formula that I started with: The only differences are: I used \(k\) instead of \(n+1\). That accounts for the fact that parity bits themselves need error correction too and that a perfect transmission must be signaled. the BCH equation assumes that the total codeword length is always one less than a power of two. instead of an approximation, it defines an upper bound. Theoretically, all BCH and RS codewords have a length \(n = 2^m -1\) symbols. In practice, the transmitted codewords are often shortened by setting a bunch of the symbols in the input message to zero and not transmitting them.5 When using shortened codes, you still have to use the \(m\) value of the parent code for which \(n = 2^m -1\). The intuitive formula works for long codewords and a limited number of errors to correct: \(n \approx k\). What about Reed-Solomon Codes? RS codes correct symbols not bits but you can still use the intuitive formula to identify the corrupted symbol: in a message with, say, 223 bytes you’d need 8 bits to pinpoint an incorrect byte. However, you also need an additional byte to fix the corruption and that is the case for every error byte that needs to be corrected. To repair \(t\) symbols that are \(s\) bits in size in a message of \(k\) symbols, you’d need this number of bits for the error location: And a bunch of bits with the correct values: Note that \(r_{location}\) points to a symbol, not a bit. Just like BCH codes, \(n = 2^s - 1\) for RS codes. Change \(r_{location}\) to use \(n\) instead of \(k\) and you get: The final result is: It turns out, that is exactly what you’ll find in all texts about RS coding: the number of parity symbols must be at least 2 times the number of corrupt symbols you want to correct. BCH vs Reed-Solomon Codes I’m getting a bit off-topic here but with the intuitive formula validated, it’s interesting to see when RS codes are better than BCH and vice versa. Let’s create an example where codewords are 255 bytes or 2040 bits and where we reserve 32 bytes or 256 bits for error correction. For RS, this allows us to correct 16 corrupt bytes that can contain up to 128 corrupt bits, as long as they’re contained within those 16 bytes. For BCH, we need 11 bits per error or \(11 \cdot 23 = 253\) parity bits to correct 23 corrupt bits which fits within the 256 bits that were allocated for RS. RS is the winner if errors happen in bursts: it doesn’t matter if a burst is 1 or 8 bits long, it counts as a single corruption when they fall within the same byte. BCH wins when errors are spread randomly: instead of fixing 16 bit flips, it can fix 23. In practice, communication protocols often used 2 codes in the following scheme: Transmitter: RS Encoder -> Interleaving -> Convolutional Encoder Receiver: Viterbi Decoder -> De-interleaving -> RS Decoder In this setup, RS is called an outer code and convolutional coding the inner code, because they wrap around the transmission in that order. In many transmission mediums, bit error are uncorrelated and burst errors unlikely. One would think that RS coding is the wrong choice then. However, the Viterbi decoder can introduce bursts of errors when it makes a mistake. The RS decoder is used to clean those up. The burst error length can be so long that a single RS codeword can’t deal with them. That’s why there’s an interleaver to increase the length of burst errors that can be corrected, at the expense of latency and memory storage, but that’s a topic for a different blog post. Modern communication protocols, such as DVB-S2 that’s used by satellite TV, use a low density parity check (LDPC) code instead of a convoluational code as inner code. A LDPC decoder has a lower tendency to introduce long error bursts in case of a mistake and instead introduces single bit errors that are spread randomly within a large codeword. This is where BCH codes shine which is why it’s used instead of RS. All words in this blog posts were written by a human. References Reed-Solomon Error Correcting Codes from the Bottom Up National Taipei University - BCH code CMU Introduction to Coding Theory - Notes 4: Elementary bounds on codes NASA - Bandwidth efficient CCSDS coding standard proposals Discusses outer coding/interleaving/inner coding for space communication. There’s an abundance of information in there, which is what you’d expect from a 70 page document! Footnotes In literature, you’ll often see \(k\) being used for this formula, but further down, \(k\) is used as the length of the original message, which is also a literature convention. So I decided to be consistent within this blog post. ↩ \(\lceil x \rceil\) means: round up to nearest integer. ↩ I came up with “error index” myself, but it turns out to be a term that is commonly used in error coding theory and its meaning is exactly what I had in mind! ↩ This is the minimum Hamming distance equation for error correction. ↩ This assumes that a systematic coding scheme is used, where the original message appears unmodified in the codeword. This is the case for most BCH and RS coding schemes that are used in the real world. ↩

yesterday • 1 votes
Is Clean Power 2030 dead?

Plus Thomas Ableman on what we can learn about AI from the Victorian railway rollout

yesterday • 1 votes
MIT engineers design a safer, more efficient vaccination system for farmed fish

Water-resistant microneedles made from food-grade silk could deliver vaccines to help prevent the spread of disease in aquaculture.

yesterday • 1 votes
📚 BoredReading

You seem to be enjoying this.

Join free to unlock everything.

Create free account

Already have an account? Sign in