Macos on Melabit

macOS Tahoe: let's free the icons!

Mon, 24 Nov 2025 18:00:00 +0000

It is not just a matter of disk icons. As soon as I saw what Tahoe had done to the icons of many applications installed on my Mac, I decided I had to do something to restore the original look of the icons.

I tried several times, using Apple’s home‑automation tools, Automator and Shortcuts, but nothing worked and there was always some function missing. Or maybe I’m just not very good at using them.

Then I discovered fileicon, a library available on Homebrew that lets you programmatically modify file and folder icons. With that, the problem was practically solved.

– Source: Hennie Stander on Unsplash.

The squircle jail

With Tahoe Apple introduced a new icon format that now has to conform to the default shape of a squircle, a cross between a square and a circle (or a superellipse, for those who enjoy mathematics).

Apple redesigned its application icons to fit the new format and the aesthetic standards of Liquid Glass, although the final effect is often quite debatable. Even John Gruber doesn’t spare criticism of this aspect, going so far as to call the designer of the Automator icon a hack who never should have even gotten a job working at Apple (and how can one say he’s wrong?).

The problem, however, isn’t just that many Apple application icons lost meaning or are outright ugly, but also that many third‑party application icons don’t fit properly into the jail represented by the squircle.

It happens with all those applications that have beatifully-crafted icons, such as Audio Hijack, BBEdit, Alfred, Amphetamine, VLC, NValt, Gemini 2, HandBrake, Keyboard Maestro and so on.

These are all well-known applications built by medium-to-large teams. Yet overe these months they haven’t deemed it necessary (or useful) to adapt their gorgeous icons to the new standard imposed by Tahoe.

And imagine if the smaller developers, or those building cross‑platform applications where a unique, recognizable look is essential, have done it either.

What happens in those cases? Tahoe automatically shrinks the icons of these applications and encloses them within the squircle. Moreover, almost as if to remind developers to hurry up and comply with Cupertino’s dictates, it places these icons on a gray background which calling ugly would be an understatement.

In the first beta of Tahoe the final result was simply hawful, as you can see in the images from my first article on Tahoe. Moreover, this brutal treatment made some icons almost invisible (Tunnelblick, QGIS, OpenMV IDE, Thonny).

In the public version of Tahoe, released in September, and in the subsequent updates, Apple toned down some of the transparency excesses of Liquid Glass and also lightened the gray background of the icons that refused to fit within the squircle.

The final effect is undoubtedly better.¹ However, the gray‑bordered icons are still ugly and much smaller than they could (and should) be.

Can we do something to bring back the look they had before the Tahoe treatment?

Let’s Free the Icons

Obviously the answer is yes, otherwise I wouldn’t have written this post.

The manual method is described very well here and requires right‑clicking the application icon, selecting Get Info and replacing the icon thumbnail with the one that lives inside the application bundle itself.

To find it, right‑click the application icon again, choose Show Package Contents, click on the Contents folder, then on Resources and look for the file with the .icns extension (keeping in mind that some applications may contain more than one such file) and drag it onto the thumbnail in the Get Info window.

It sounds complicated but, with a bit of practice, it becomes fairly quick. This manual method works fine if you only have a few applications to fix. But if, as in my case, there are more than 20 applications, it quickly becomes tedious and error-prone. And, as if that weren’t enough, you’ll probably have to repeat the process every time the application is updated.

Better to let your Mac do everything automatically. And that’s where IconLib comes in.

IconLib

IconLib is a simple Bash script that automates the whole process, relying on the fileicon library to actually perform the icon modification. All you have to do is provide it with a file containing the list of applications to update – and sometimes the name of the .icns file too, because, darn it!, many developers use icon filenames that have nothing to do with the application name and often bundle multiple .icns files inside the application bundle – and it does the rest.

If you’re not happy with the result, you can run the script again with the -u switch (for undo), restoring the Tahoe icons.

You can also run IconLib on a list of applications, and then later edit the list to restore the icons for only the selected applications, leaving the others in their pre-Tahoe state.

All the details are in the README file of the GitHub repository and I won’t repeat them here. Instead I’ll just show how the icons look after fixing them with IconLib.

Even though the old icons don’t follow the stylistic dictates of the squircle, the richer, less constrained look and the absence of the gray background make me prefer them, at least until developers roll out new icons better suited for Tahoe.

Bare Bones Software just did it for BBEdit. The fact that such a major software house took so long indicates it’s no easy task, or that developers hoped (in vain) for months that Apple would backtrack. And if BBEdit took that long, it’s hard to imagine other cross‑platform or niche applications adapting quickly.

Conclusions

IconLib is not a must‑have program at all and it serves an admittedly narrow audience.

First of all, it is useful for people like me, who have many programs installed on their Macs, often produced by indie developers or by specialist teams that lack the time, desire, or expertise to deal with subtle graphics issues (think, for example, of Tunnelblick, for managing VPNs, Thonny, a must‑have for those who program microcontrollers in Python, or JASP, one of the best statistical programs for those who know little about statistics).

It also helps anyone who is dissatisfied with the jail that Tahoe enforces around the formerly magnificent icons of many applications.

Finally, it assists those who think Apple is overdoing this trend in macOS, which increasingly feels like an offshoot of iOS rather than a standalone system deserving its own life.

And lastly, it serves those who think Apple is going too far with this drift in macOS, which increasingly seems more like a by-product of iOS than an operating system worth its own independent existence.

While they were at it, couldn’t they have used a white background? ↩︎

macOS Tahoe, again

Mon, 10 Nov 2025 18:00:00 +0000

After less than two months since the official release, Tahoe seems poised to become another one of those macOS versions to be forgotten, like Lion, Mavericks, Sierra, Catalina, or Ventura.

Aside from Liquid Glass, which I’ll discuss in a moment, what does Tahoe have that’s memorable? There’s the telephone‑call filter, which actually belongs more to iOS than macOS and still has many limitations, and there are also improvements to Spotlight search. But is it really worth upgrading an operating system just for that?¹

Liquid Glass should be the real novelty of macOS 26 Tahoe, but Macworld first compared it to Vista and then declared it dead in the cradle. If Macworld says so – not PCWorld, not Linux Pro -— there’s definitely something to be concerned about!

Moreover, Liquid Glass went wrong from the very beginning, when some joker thought of inverting the colors of the Finder icon. Without any particular reason, just for sake of change.

The criticism was so destructive that Apple had to backtrack quickly, restoring the historic design of the Finder icon, the one we’ve known for thirty years and that is one of macOS’s distinctive marks.

Haowever, when it came to disk icons Apple managed to do even worse. In the very early betas of Tahoe the disk icons were identical to the ones we’ve been used to for years: the image of a mechanical hard‑disk for internal drives and a rounded orange rectangular prism for external drives. Very skeuomorphic, but also very clear and even pleasant to look at, with all those little screws, colored LEDs, and even a label warning us not to open the disk.

With the fifth beta of Tahoe, Apple throws the old hard‑disk icon into the trash and replaces it with a more stylized image that should represent the SSD installed in all Macs for years.² While it’s at it, it also freshens up the other disk icons (external, network, and removable) and the result is shown below, where the top row displays the disk icons up to Sequoia and the earliest Tahoe betas, while the bottom row shows the updated icons.

– Source: Ars Technica.

Soon after, the internal‑disk icon loses all front elements, that perhaps were meant to represent ventilation slots or activity LEDs, and becomes as minimal as the others.

Admittedly, the new icons are bland, having lost all detail in favour of greater simplicity, just as has happened to the rest of the graphical interface built around Liquid Glass. But so far that’s fine.

What’s incomprehensible is why the icons were redesigned to appear narrower in the front and wider in the back, defying the laws of perspective and how we’ve been accustomed to seeing them up to Sequoia. It’s merely an optical illusion; in reality (I checked) the icons have perfectly parallel sides, but the play of light and shadow makes them look odd and out of place.

The effect worsens when the icons are placed side-by-side, because the differing reflections make the gray internal‑disk icon look more natural and less distorted compared to the external units.

Now, I can understand the need to adopt a homogeneous and well-defined graphic language, but wasn’t it possible to design icons that looked more natural? Susan Kare managed it with just 32×32 pixels, how can we think that today’s Apple designers, who today have immense fields of pixels at their disposal, can’t do the same?

If Cupertino can’t even produce a convincing disk icon, how can we trust that Tahoe and Liquid Glass are serious projects?

The annual macOS update cycle is good for marketing, but from a technical point of view it makes very little sense. Not only because it’s hard to invent truly novel features for each annual release of macOS, but also because this relentless quest for novelty distracts from equally important activities such as fixing bugs in the current version and optimizing system performance. ↩︎
Actually, the new internal‑disk icon has nothing to do with an actual internal SSD image, but we won’t be too pedantic about it. ↩︎

Goodbye dc, welcome luka: a new RPN calculator for the Terminal

Sat, 09 Aug 2025 06:00:00 +0000

The Reverse Polish Notation (RPN) is a method for performing calculations without the need for parentheses. RPN was popularized in the ’70s and ’80s by Hewlett-Packard (HP), that used it in all its scientific and financial calculators.

When using calculators from rival Texas-Instruments, which all relied on parentheses, it was easy to lose track of how many parentheses had been opened or closed, often forcing users to re-enter the entire expression from scratch. Those who used an RPN calculator didn’t have these problems, although they had to overcome a small initial learning curve to get used to the new notation.

Today, physical calculators are rarely used, and almost everyone prefers to use an app on their phone or computer. However, there are still some die-hard nerds who refuse to give in to the graphical interface and insist on using the Terminal. Why? For example, because it’s much easier to enter numbers and complex operations with a keyboard than to press the glass keys of a virtual calculator.

– Image generated by Google Gemini.

A bit of history

Poland gave us Nicolaus Copernicus, Fryderyk Chopin, Joseph Conrad, Marie Curie, Arthur Rubinstein, and Stanislaw Lem. But it also gave us Jan Lukasiewicz, a mathematical logician (and philosopher) who, about a hundred years ago, invented a mathematical notation that did not use parentheses.

In this Polish notation, all operation symbols ( $ + $, $ - $, $ \times $, $ / $ ) precede the numbers they apply to. The same applies more generally to mathematical functions, such as $ \sqrt{} $, $ \sin $, $ \cos $, $ \exp $ (operators) and the numbers or variables (operands) they act on.

For example, $ 3 + 4 $ is written in Polish notation as $ + \ 3 \ 4 $, while $ (5 + 2) \times (5 - 2) $ becomes $ \times + 5 \ 2 - 5 \ 2 $.

For many years, this remained just an odd idea, because the benefit of not using parentheses didn’t seem to outweigh the unusual and more difficult-to-read notation.

Then, in the late ’50s, John McCarthy brought back Polish (or prefix) notation for LISP, one of the most influential programming languages of all time,¹ developed with the goal of being applied to the development of programs in the field of nascent artificial intelligence.

In fact, prefix notation not only greatly simplified the implementation of the LISP interpreter, but also made it possible to represent both code and data in the same form, an invaluable feature for a language designed to make computers intelligent. But better not to digress.

Reverse Polish Notation

But the real breakthrough came by inverting the order between operands and operators, that is, by writing the numbers first and then the operations to be performed on them, so $ 3 + 4 $ becomes $ 3 \ 4 \ + $ and $ (5 + 2) \times (5 - 2) $ becomes $ \ 5 \ 2 + 5 \ 2 - \times $.

This Reverse Polish Notation (RPN) was discovered and rediscovered at least three times in twenty years, but it only became popular in the early ’60s when Friedrich Bauer, the inventor of the concept of stack and one of the developers of the ALGOL computer language, and Edsger Dijkstra, famous for solving the “shortest path problem” and for a thousand other things, took up the concept again, because it reduced access to memory, which at the time was scarce and slow, and ensured that all operations were performed within a well-defined memory area (the stack), that was therefore easier to manipulate.

The advantages of RPN for performing mathematical calculations were so evident that HP used it in practically all its scientific and financial calculators, at least until the early ’90s. The development of larger memories and much bigger displays made it possible to easily view and modify the entire entered operation – not just the last number entered – thus reducing the necessity of using RPN.

A calculator in the Terminal

Those who wish to use a traditional calculator in the macOS or Linux Terminal have an almost mandatory choice: bc, the basic calculator, that has been a part of UNIX since 1975, a full 50 years. The current version, available on Linux and macOS, has been completely rewritten, but the original was just an interface for dc (desk calculator), one of the oldest utilities present in UNIX and even older than the C language.

And dc was… an RPN calculator. A choice that confirmed HP’s intuition: RPN notation was more efficient and easier to implement, and therefore also ideal for the limited-resource computers of the ’70s.²

Today, RPN is no longer a choice forced by hardware limitations, but rather a choice driven largely by convenience. Once you’ve spent half an hour learning to use it, you discover that it’s really much more convenient to perform calculations with this notation than with the traditional algebraic notation.

And then, maybe, there’s also a certain pleasure in going against the flow: in a world where everyone conforms to the dictates of (real or presumed) social media influencers, using an RPN calculator becomes a way to stand out, to feel different, almost a declaration of intellectual independence.

dc is still available on Linux and macOS and can be used in the Terminal, but it’s quite a hassle, its fifty years clearly show. The results of the operations are not visible unless you explicitly print them on the screen with p. The stack isn’t visible either, unless you explicitly request it with f. Negative numbers are indicated with an underscore _ and not with the usual - sign, so that $ - 4 $ must be written as $ _4 $. And so on.

But starting (almost) today, there’s dc2, or rather, luka.

The 21st-century RPN calculator

Since a few weeks we have a new RPN calculator for the macOS and Linux Terminal, initially called dc2, in homage to the venerable, now over-50-year-old calculator.

However, dc2 sounded too much like a rewrite of the original, while this is a completely new project, written from scratch in C. It therefore deserved its own name, luka, in honor of Jan Lukasiewicz, the inventor of the Polish notation (see the box above).

Compared to dc, luka is truly from another century, and it shows as soon as you start trying it out. It’s interactive, it shows the content of the stack at all times, it has a history of the operations, variables, a concise but complete inline help, a crystal-clear manual page (if only there were many more like this!)

And luka is also made in Italy. At a time when national identity is exalted for mostly trivial reasons, it’s nice to see something that really deserves to be valued.

The program currently has a small bug related to the display of the history, but the author crunches code much faster than I write words, so it’s very likely the bug will be fixed ASAP (vacations permitting).

Evolution of the code

The development of dc2/luka has been incredibly fast. Behind the project is Davide Mastromatteo, known among his pen pals as @mastro35 and author of the excellent blog The Python Corner.

In just a few days, Davide went from version 0.1.0, which was perfectly functional but had a still-raw user interface,

to version 0.2.0, with a much clearer view of the stack, the ability to use degrees and radians, and to change the number representation format, as well as a more compact help.

Version 0.3.0 introduced the history of operations and a further revised help,

while version 0.4.0, which coincided with the program’s name change, brought us variables and several new keyboard commands, as can be seen in the first two images of this post.

Using luka

Installing luka on a Mac or Linux is a breeze, at least for those who use homebrew (and those who don’t should start doing so immediately)

brew install mastro35/homebrew-mastro35/luka

Otherwise, just download the latest release of the source code, unzip it, and run

make clean && make

from the Terminal, obviously after navigating to the directory that contains the source code.³

Needless to say, anyone who has make and a C compiler installed on Windows can also compile luka on that operating system.

I almost forgot: soon there will be packages for Linux, in both deb and rpm formats, and who knows, maybe also aur. Perhaps even an installer for Windows.

There’s little to add about using the calculator itself. Those familiar with RPN will feel right at home and quickly use luka’ to its full potential. Those who don’t know RPN might be tempted to try it, if only to try firsthand how much more convenient it can be to perform calculations with an RPN calculator compared to a traditional algebraic one.

There are countless guides to RPN, but unfortunately, they are all oriented toward explaining its use with a physical calculator, such as the now legendary vintage HPs, or with graphical emulators for Android or iOS.⁴

Compared to these guides, there are some differences to consider. The main one is that, lacking physical keys, luka (but also dc) requires you to press ENTER each time to insert a number or function. Some function names are also different, as are the commands for managing the stack or for saving and retrieving variables. For example, luka uses store and load for variables, while physical or emulated calculators generally use keys named STO and RCL (but if the author reads this post, maybe he will change them 😂). However, apart from these tiny details, the underlying logic doesn’t change.

For my part, I tried in every way to make luka crash, and never succeeded. I tested it with factorials of absurdly large or small numbers, divided by zero, performed the infamous$ 0 / 0 $ and then asked to calculate the reciprocal of the result. But no matter what, luka always returned the correct result. In short, the quality is definitely there.

Conclusions

Trying luka costs nothing. It installs (and uninstalls) in a few seconds, works on macOS, Linux, and, for those who want, even on Windows. The results it produces are exact (and this is the most important thing). The developer is skilled and open to suggestions. In short, it’s an ideal tool for anyone who wants to perform calculations from the Terminal.

Sure, it’s a niche tool, aimed at a select group of sophisticated users who appreciate RPN notation and are not afraid of the Terminal. But that’s also what what gives it its unique charm.

And then, what about the beauty of seeing a program evolve before our very eyes, maybe even participating in its development with suggestions or criticisms?

And beyond that, there’s something special about watching a program evolve right before our eyes, especially when you can join the development with your own suggestions or feedback.

And one of the few languages, along with FORTRAN and COBOL, to still be alive and well. ↩︎
Not by chance, one of the most efficient programming languages ever is FORTH, which is based on a stack and uses RPN. ↩︎
What, you don’t even have make? Then hurry up and install homebrew! ↩︎
For iOS, I recommend without hesitation PCalc Lite or, even better, the full version Pcalc, which costsbout as much as a sandwich and a small bottle of water at a café. Alternatively, WP 34s, which manages to compact everything onto a single screen, or i41CX, perfect for those who once dreamed of having one. ↩︎

macOS Tahoe: Developer Beta 3

Tue, 22 Jul 2025 06:00:00 +0000

A few days ago, right on schedule, Apple released to developers the third update of the macOS 26 Developer Beta, better known as Tahoe.

Once the update is complete, it doesn’t take long to realize that Apple is (slowly) modifying something in the Liquid Glass graphical interface of the latest version of its operating system.¹

Perhaps this is also to address the many criticisms it has received over the last month from big names like Riccardo Mori – whatever you think, his first article on MacOS Tahoe and Liquid Glass is a must-read (but his first and second follow-ups are also worth reading) – as well as from John Gruber, Craig Hockenberry, Francisco Tolmasky, Louie Mantia, Marco Arment and many others, as can be read in one of Michael Tsai’s masterful collections.² As well as, in my own humble and far less masterful writings (here and here).

It’s a beta

Let’s clear up a misunderstanding: constructively criticizing the beta version of an operating system, such as macOS, is a good and right thing to do.

When Apple releases a beta, they’re not doing us a favor by letting us preview an unreleased product. Rather, we’re doing Apple a favor by analyzing and dissecting their software in ways that might never have occurred to their official developers and testers.

To argue, as many do, that “you have to be patient, it’s just a beta” or that “betas always have bugs,” is utter nonsense, because it is precisely at this stage, when the product is tested in the field, that flaws emerge which official developers, accustomed to working on it every day for months, no longer notice.³

After all, if Apple has extended access to its Developer Betas to a much wider audience in recent years, it means that what is done in this phase is indeed useful to them!

The Wallpaper

The first thing you notice when you access your Mac after the update is the new default wallpaper, which now shows the rocky shore of Lake Tahoe, surrounded by a long chain of snow-capped mountains (in Nevada?).

I don’t particularly like these natural wallpapers; there are too many details that distract and prevent a clear view of what’s on the Desktop. However, compared to the anonymous wallpaper we had before (and which is still among the available wallpapers), this one is much better, so it’s all right. And the subtle ripple effect of the waves, which unfortunately isn’t visible in the screenshot, is truly delightful!

However, changing the active default wallpaper on the fly seems to hint some issues in the development direction of Tahoe/Liquid Glass, as will become even more apparent in the next section.

This, to be fair, is a change introduced in the previous beta, which I didn’t get a chance to write about here, yet. Apple has added an option to restore the menu bar background (System Settings > Menu Bar > Show menu bar background), just like in Sequoia and previous versions of macOS.

In my opinion, this is an excellent decision because, after using macOS Tahoe for a few weeks, I realized that having a transparent menu bar available is useless. For at least two reasons.

The first is that with a transparent bar, menu items and icons tend to blend into the background image, becoming much less legible. This effect is particularly severe when the wallpaper is full of details and gradients, as in the example below.

The difference in clarity when the menu bar has a background is evident.

The second reason is that, even if the menu bar is transparent, it cannot (rightly) be occupied by application windows, so you don’t gain useful space for applications.

What is the real purpose of a transparent menu bar if it is less legible and doesn’t provide more useful space for applications? It is just to achieve a (questionable) more homogeneous visual effect without any functional advantage?

Most people use their computers to work. They don’t spend all day admiring the desktop. Why should they struggle to read the menu items or the battery level, the Wi-Fi strength, and all the other icons that are there for a specific purpose, just because some dime-a-dozen designer decided that the menu bar should blend in with the desktop?

It is striking, though, that after no less than two Developer Beta releases, this setting has still not been translated into Italian and, I imagine, other languages. It is a small detail, but that gives the impression of a half-baked, thrown-together thing, something that the team working on this part of Tahoe is still not quite clear on.

This reinforces doubts about how Tahoe’s development is progressing, as expressed very well by Craig Grannelli.

[this change] also makes me question Apple�s confidence in its design work. When Apple starts hedging its bets, it signals that it knows something is wrong, but lacks the conviction to course-correct. Or perhaps such settings are a means to temporarily shut people up, while default choices reveal the true intent and direction of travel.

System Settings

In my first article on Tahoe, I reported that the new Appearance item in System Settings behaved strangely: setting the Auto mode in the section related to Dark, Clear, and Tinted icon (and widget) styles apparently had no effect.

In the article, I supposed that this mode would allow the operating system to automatically adapt the display details of the chosen icon and widget style to the active Light or Dark mode. However, I also noted that the implementation seemed rather confusing.

Actually, it wasn’t a poorly implemented feature; it was a true bug, as reported in the Release Notes for this beta.

Finder
Resolved Issues

Fixed: Finder does not display Dark Mode app icons or tinted folder colors when the Folder Color setting in System Settings > Appearance is set to Automatic. (152193702)

Unfortunately, even though Apple claims to have fixed the problem, I don’t see any improvement. However, I clearly see that certain combinations of settings still result in such low icon contrast that it becomes difficult to tell them apart.

The Finder

As soon as I opened the Finder, I had the impression that Apple had reduced the shadow intensity of the separate groups of icons that now make up the Toolbar.

Unfortunately, this is not the case; the shadow intensity, as well as the icon transparency, is identical to before, producing the same color mess described in the previous article whenever the more colorful icons in the main Finder window end up beneath those in the Toolbar.

To avoid this, it would be enough for the Finder’s Toolbar to retain the white background present since Big Sur (that replaced the previous metallic one). This way, the icons shown in the main Finder window would be visible only in that window, without spilling over into the area reserved for the Toolbar.⁴

The more I use Tahoe’s new-Finder, the more I wonder what’s the point of this confusion, where the Toolbar – which isn’t there for beauty but to manage files and navigate the file system – has to blend and overlap with the files themselves, in an indistinct mix that isn’t even aesthetically pleasing?

Even Apple’s developers seem to have doubts about their choices, as switching from Icon to List view shows the usual clear separation between the main window and the Toolbar (apart from the three-dimensional effect added to the latter by Liquid Glass).

If we switch to Column view, we find a third, intermediate mode between the previous two. In this mode, the Toolbar has a white background, but where the icons of applications and files are blurred well before they reach the Toolbar, as happens in the normal Icon view.

This confusion in the display mode of the Toolbar is not only present in the Finder but also in applications like Notes where, depending on the chosen display mode, you can find yourself with a transparent Toolbar that blurs everything that ends up underneath it,

or with a normal Toolbar with a white background, as we are used to seeing since Big Sur.

Something similar also happens with Font Book, albeit with slightly different modes, while it doesn’t happen with Freeform or Preview, which always have a transparent Toolbar. Reminders is another special case, but I’ll leave you the pleasure to figure out why.

In short, there seems to be a great deal of confusion in Cupertino, and even the developers cannot decide what to do with the new Liquid Glass-style Toolbar.

Application Icons

I want to give the new application icons in the Finder their own section because, in this case, it’s no longer a simple matter of taste, but of the relationship between Apple and developers. After all, developers are fundamental to the success of a platform.

But first, let’s briefly recap the issue.

In macOS Tahoe, Apple has introduced a new icon format for applications, borrowed from iOS. The new icons have the shape of a squircle, a geometric shape intermediate between a circle and a square, and can be created with the new Icon Composer. This new format allows, among other things, to dynamically adapt the icons to the chosen style, or rather Appearance (see the System Settings section).

So far, so good.

The problem arises from the fact that there is no choice: the icons of all applications installed on the Mac can no longer have a customized shape, such as that of BBEdit which I am using to write this post, but must obligatorily adopt the squircle shape.

All application icons that have not yet adapted to the new style imposed by Liquid Glass are automatically enclosed in a squircle with an horrible dark gray background behind them, which seems to be placed there specifically to flag those bad products that have not yet conformed to Apple’s new guidelines.⁵

But redesigning icons is no piece of cake. For example, Bare Bones Software, which is certainly not an indie software house, has not complied yet. Its flagship product, BBEdit, was given a major update just a few days ago, but retained its traditional icon.

Independent developers are even less enthusiastic about having to redo all their application icons following the new format imposed by Apple.

One of them is Howard Oakley, who ironically calls macOS Tahoe the iconoclast, and equates the squircle with the gray background to a sin bin, as the area of the field where a player who has committed a foul is temporarily confined.⁶ Someone else goes even harder and calls the squircle a true prison.

Even those who decide to comply have problems because, as Howard Oakley tells us, updated icons for Tahoe may not work correctly in previous versions of macOS.

Half of the applications installed on the Mac that I updated to macOS Tahoe have grey icons. In the month and a half between the release of the first Developer Beta and today, I believe none of them have adopted the new icon format. This includes Google Chrome, which certainly has the resources to adapt quickly. Some Apple applications, such as GarageBand and Xcode, don’t even follow their own guidelines. The latter is particularly significant given that Xcode is the main tool for developing Mac applications.

My impression is that Tahoe’s graphical interface is not carved in stone -� oops, in glass – and that developers prefer to wait for the final version before conforming to Apple’s dictates.

After all, between Developer Beta 1 and Beta 2, Apple has already changed the Finder icon due to popular outcry, and has added the option to restore the menu bar background. So it’s clear that Apple is not insensitive to the criticisms expressed by those who are previewing Tahoe.⁷

I almost forgot: you can even restore the usual oddly-shaped icons in Tahoe. However, it’s a manual and rather tedious process, that must be repeated for each affected application and for each Mac. I’ll pass.

Performance

The third Developer Beta of macOS Tahoe seems much slower than the two previous versions. For example, Firefox takes forever to launch and restore previous tabs, but almost all applications seem more sluggish, especially at startup, than is reasonable to expect on Apple Silicon. Some ‘System Settings’ panels appear completely empty at first and take several seconds to display the available options.

As annoying as it is, this is normal behavior in a beta, which by its nature is filled with debug code and immature or poorly tested functions that may generate memory leaks, erroneous cache usage, and the like. I only mention it here because the first two Developer Betas appeared much more responsive than this one.

In any case, restarting the system solves the problem, at least temporarily, while we await the release of the final version.

Conclusions

In a few days, perhaps even tomorrow, Apple will make the Tahoe beta available to everyone, so that it can be tested by a much wider and more diverse audience.

As I said earlier, the fact that the Finder icon was changed mid-development demonstrates that Apple is listening to criticism about the new macOS interface. So there is hope that other issues will be resolved in the two months remaining until the official release of the new macOS version.

If someone thinks that critical posts like those cited above, and maybe even the little notes you’ve just read, are written solely for the purpose of getting easy clicks… well, never mind, the authors will come to terms with it.

If someone thinks that critical posts like the ones mentioned above, or maybe even the humble piece you’ve just read, are written purely to get easy clicks, well, never mind… the authors will come to terms with it.

Apple is doing the same with the corresponding version of iPadOS (which I’m testing on my iPad Pro) and iOS (which I’m leaving alone for now). ↩︎
Riccardo Mori describes himself as a translator and writer, but in reality he also has extensive expertise in the field of design and typography. John Gruber has been writing one of the most important blogs dedicated to the Apple universe for more years than I can remember and is the inventor of Markdown. Craig Hockenberry is a developer who has produced, among other things, Tot, which I adore, and is one of the souls of Iconfactory. Francisco Tolmasky was a member of the original iPhone team, where he helped develop Safari for iOS, and is the creator of Objective-J, a superset of JavaScript, and Cappuccino, an “open source framework that simplifies the creation of desktop-class applications running in a web browser”. Louie Mantia is an artist and graphic designer specializing in icon design. Marco Arment is an iOS and web application developer, as well as a “writer, podcast producer, geek, and coffee lover.” ↩︎
More or less the same thing happens when writing: if you have a text read by a third person, they will much more easily notice errors that the author, who now knows the text by heart, no longer pays attention to. ↩︎
As has always been the case, not just in macOS (or Mac OS X, or whatever you prefer to call it), from Sequoia all the way back to Cheetah, but also in the versions of Mac OS released throughout the ’80s and ’90s. ↩︎
To make a sporting comparison, Apple seems more or less like that soccer referee who pulls out a yellow card while warning the striker that “one more silly mistake and I’ll send you off.” ↩︎
I swear that when I wrote the soccer comparison in the previous note, I had not yet read this comment by Howard Oakley. ↩︎
I can’t help but think that if Steve Jobs had seen what some of his Finder icons have become, he would have kicked those responsible right out the window. ↩︎

macOS Tahoe: where is my Terminal?

Tue, 08 Jul 2025 06:00:00 +0000

– Image generated by Google Gemini.

Take macOS Tahoe, updated to version 26.0 Developer Beta 2, and open the Terminal. Actually, don’t just open one Terminal; open two, three, four different Terminals, each in its own tab. More or less like this:

Now tell me: which is the active Terminal?

In order to answer you need to look closely. Only then you will notice that the title bar of the active Terminal has a slightly darker background and that the title itself is in bold.

Do the same with Sequoia, or any other previous version of macOS, and the Terminal in use will be apparent at first glance.

Actually, there is also a way to tell which Terminal is active in Tahoe, but it is counterintuitive and requires the use of the mouse. If you hover the mouse over the active tab, nothing changes visually,

while, when you move the mouse over an inactive tab, its background gets darker.

To many, it may seem like a minor detail, but the Terminal is an essential tool for interacting with the operating system at a low level. Those who use it can’t afford to waste time figuring out which panel is the right one, nor can they risk running a dangerous command in the wrong Terminal.

To give a practical example: for managing this blog, I use three different Terminal panels, each of which is dedicated to a specific task. In one panel, I work via ssh on a test site, which I use to check that everything works properly before uploading the blog to the live server. Since this is only a test environment, I’m accustomed to wiping everything out with the command rm -r *. I can do that without worry because I can tell at a glance that I’m in the right Terminal, without even reading. However, with Tahoe, I’ll have to change my habits because running that same command in the wrong Terminal could have catastrophic consequences.

Among all the inconsistencies in macOS Tahoe, this is perhaps the most baffling. And potentially the most dangerous.

At this point, one can’t help but wonder: do Apple’s developers actually use the products they create?

macOS Tahoe: see you in September

Sat, 28 Jun 2025 06:00:00 +0000

It’s becoming a habit. Earlier this year, instead of waiting, like I usually do, for the next version of macOS to be ready (or nearly ready) before installing the current one, I installed Sequoia on all my Macs. A few days ago, I decided to take the plunge and install the very first developer beta of Tahoe on a Mac that I don’t use much, mainly to try out the new Liquid Glass interface on macOS.¹

Since this is my first time trying a macOS beta, I cannot say whether previous versions were more or less mature than Tahoe at this stage of development, which admittedly is still far from the official release.

Therefore, I will share my first impressions of the new interface here, focusing in particular on the Finder, which is one of the most frequently used applications, and on System Settings, which is essential when getting familiar with a new operating system. After the official release in September, there will be time for a more in-depth evaluation.

Update

The update from Sequoia 15.5 to Tahoe 26 Beta weighs just over 7 GB, which seems in line with previous updates, and perhaps even slightly below average.

The installation of the new operating system is fast. I dont’t know exactly how long it took, but I was surprised when I found out that it was already finished.

After the update, the first thing you see is this screen, which gives a preview of Liquid Glass, with the buttons raised above the rest of the window. Here, there is no visible transparency effect yet, but there will be time for that, too.

Desktop and widgets

Once you click Continue, the Tahoe Welcome Screen appears, which, poor boy! looks like toothpaste writing overlaid on my Mac’s default background. Sadly, the days of the magnificent Welcome Videos of the early macOS versions with the big cat names are long gone.

From here, you go straight to the Mac Desktop, which now displays a few widgets on the left-hand side of the screen (some of the widgets do not show any information just because the screenshots were taken late at night, with an inactive internet connection).

I’ve never really liked widgets. On Tiger and later versions, I used a few, but only because they were neatly tucked away on a separate screen, the now forgotten Dashboard. Having them on the Desktop, which I use all day, just annoys me. I already know that, as soon as I finish this post, I’ll remove them without hesitation.

But there’s time for that. For now, I’m just going to change the wallpaper to Tahoe’s default.²

I’m not thrilled with the new wallpaper: there are too many details and gradients for my taste, and the contrast with light icons, such as the disk icon, is too low. But no one is forcing me to use this exact wallpaper, so this is a non-issue.

Finder

A true problem, however, are the application icons with the dark gray background, which literally make me jump out of my seat when I first opened the Finder.³

The original icons had a transparent background, which can be noticed simply by changing the background of the Applications folder in Sequoia or earlier macOS versions. For reasons beyond understanding, in Tahoe this invisible background is replaced by a dark gray tone, that is an understatement to define as ugly.

Clearly, Apple applications do not have this issue. However, as shown in the previous image, some of the most popular ones are affected by it, with Google Chrome being one of the main examples.

However, when I scroll down towards the less popular apps, I find lots of ugly icons bordered in gray! In some cases, the icons have even been shrunk, presumably due to the new dynamic scaling rules of Liquid Glass, making the gray area around them even larger. Who on earth came up with something like this?

This is not the only questionable aspect of the new Finder. Here, the familiar Toolbar has been replaced by separate groups of translucent icons that seem to float above the main window.

The change feels somewhat rushed, especially since they forgot to raise also the folder name. That said, the new toolbar can be considered acceptable, even if inconsistent, when there is a light background behind the icons (as shown in some of the images above).

But when the translucent icons of the Toolbar overlap the most colorful icons of the main Finder window (as shown in the image below), the result is a chaotic, unpleasant mix of colors, that makes it hard to tell one Toolbar icon from another.

Maybe using a stronger blur effect or reducing the transparency might help to avoid the issue. However, wouldn’t it be better to just stick with the old white toolbar, with the new floating icons on top?

And yes, I understand that everything must speak the liquid concept now, but was it really necessary to turn the cursor in the Finder’s status bar (the one in the bottom right corner that lets you resize the icons) into such a huge yet barely visible capsule?

On the other hand, the new Trashcan isn’t bad at all; it looks more modern than the classic cylindrical one we have always had. I do wonder how it would stand upright, but it is clear that skeuomorphism has been dead for a while now.

Still on the topic of the Finder: could someone explain why the Settings window in the Finder still has the slightly rounded corners from Sequoia, and why its icons look thinner than those in the sidebar of the main window?

The new Apps

The new Apps application, on the other hand, isn’t bad at all: it groups installed apps in a logical way, more or less as iOS already does. It definitely looks better than Launchpad, which I tried to use but quickly gave up on,⁴ though I don’t like the fact that it takes two clicks to access the apps in a given group.

Mission Control hasn’t changed, and I’m totally fine with that. I use it a lot, and I wouldn’t like to break my habits. The same goes for Chess, which I never play because I always lose, but that has been a part of macOS since… forever (and was present in its forefather, NeXTSTEP, too).

The other default applications don’t seem to have changed much either, but I’ll save a more detailed analysis for later.

System Settings

Lastly, a look at System Settings. I won’t to comment on how confusing it has become. Up to Monterey, a quick glance was enough to find what you needed. But ever since macOS started mimicking iOS, you basically have to rely on the search function every time you need to find some setting.⁵

What I will comment on is the new feature that globally changes the color of macOS Tahoe icons and widgets. Here you can see the Default icon (and widget) style which, aside from the grayish border I mentioned earlier, is what we have always been used to seeing.

This image shows what happens when the Dark style is enabled. While all the Apple icons visible in the Dock do change, the application icons shown in the Finder do not —- probably because they need to be updated to support this new style. However, the Light theme doesn’t really do this new style justice,

whereas with the Dark theme, it’s a whole different story.

However, if I enable the Dark style and select the Auto mode, the entire interface reverts to looking exactly like the Default style. You can see it in the two images below: the first shows the Mac screen with the Dark style and Auto mode enabled, while the second shows the Default style.

I assume that the Auto mode is supposed to allow the operating system to automatically select the styling that best fits the current Light or Dark mode. While this makes sense, it might need a different implementation; as it stands, it just ends up being confusing.

The other two styles, Clear and Tinted, are nice enough, but personally I don’t like the idea of having all the icons in the same colour. I’m sure plenty of people will appreciate these new uniform styles, but I doubt I’ll ever use them myself.

Even with these styles, the Auto mode automatically adjusts the appearance to match the active theme. Here too, I think that both the placement and the labeling of the automatic mode needs some improvement.

Not bad at all, the option to change the accent color of the user interface.

I’m not really into these things, but a lot of people like them, and since they don’t overhaul the interface, why not?

The final gem is the huge switch that toggles Bluetooth (as well as Wi-Fi and VPN). True, even in Sequoia these switches were larger than the others, but don’t you think Apple has gone a bit too far this time?

Conclusions (for now)

This ends up my quick overview of macOS Tahoe and its Liquid Glass interface. If I gave the impression that I’m not thrilled about it, well, that’s exactly how I feel.

I really appreciate that Apple had the courage to change, aiming to develop a consistent interface across all its devices. Liquid Glass definitely has a lot of potential, but it’s still quite immature on macOS, perhaps even more so than on the iPad. It reminds me of the metallic transition of Leopard, which needed several subsequent macOS releases to refine.

In any case, Liquid Glass is the future, and we’ll have to live with it for quite a few years. So it’s best to start appreciating its positive aspects now, and be patient with the negatives.

In the meantime, Apple’s developers have fixed the flipped Finder icon, which caused quite a stir. Hopefully, before the official September release, they’ll do the same for the many other oddities and inconsistencies.

On the iPad, Liquid Glass is very interesting, though still quite immature. ↩︎
Unless they’re really ugly, like some Linux wallpapers, I always stick with the default backgrounds. I’m not a fan of extreme system customization, and using the default wallpaper helps me to instantly recognize which OS version I’m running. Besides, macOS default wallpapers are almost always really beautiful. ↩︎
Actually, these grayish icons were already showing up in the Dock. But due to the late hour or the low contrast, I hadn’t really paid attention to them. ↩︎
For example, because it used to lose the carefully set layout and didn’t allow syncing it across multiple Macs. ↩︎
Some might suggest that having a similar layout between macOS and iOS is a good thing. Indeed it is, but unfortunately iOS settings have always been one of the most confusing things I’ve ever seen. Therefore, it would have made more sense to adapt the macOS settings model to iOS, instead. ↩︎

WWDC 25

Thu, 12 Jun 2025 06:00:00 +0000

When was the latest truly memorable WWDC? I’d say in 2020, a year that was already memorable in itself, when Apple unveiled the new Macs with Apple Silicon processors, capable of outperforming their equivalent Intel-based models.

I don’t know if what was presented at this year’s WWDC will be just as memorable, but there’s no doubt that Apple has came up with some interesting innovations.

First and foremost, there is an update to iPadOS that finally introduces (why did it take so long?) overlapping windows and a more decent file system management, virtually retiring Stage Manager.

I never liked Stage Manager. I’ve always found it annoying and too limited, with its four-and-no-more-than-four side mini-windows that come and go, with no way to pin one in place once and for all. I think few people will miss it.

The new overlapping windows in iPadOS 26 may have an “old-school” vibe, but they’ve been around for 40 years and are definitely more intuitive and easier to manage. If I have to adapt to something new, Apple should to offer me something better, not worse.

Getting Preview and Calculator on the iPad is no small bonus. As a more-than-satisfied Preview user, I’m really curious to try it on the iPad.

The other major new feature is the new “Liquid Glass” user interface, which will be rolled out across all Apple platforms, from Macs to iPhones and even Vision Pros. Beyond its look, glassy today, who knows tomorrow, what really matters is that from now on, all Apple platforms will speak the same visual language, with clear benefits in terms of ease of use and, I believe, also app development.

That Liquid Glass is the modern version of Aqua seems obvious at first glance. In the early 2000s, I switched back to the Mac from Linux not only because it had UNIX under the hood, but also because I absolutely loved Aqua.

The later shift to a metallic theme and to today’s muted gray tones, elegant as they may be, never really excited me, so I’m very curious to see Aqua 2.0 in action.

As for the rest of the keynote, I’ll admit that I don’t remember much. The fact that the Apple Watch now tries to convince me that I run better than Jacobs matters to me about as much as nothing. The same goes for the time that stretches or shrinks depending on the iPhone wallpaper. Or the ever-present Memojis. But if they get so much stage time, it must mean people like them, so maybe I’m the one who is out of sync with the times.

Apple improving the built-in apps in its operating systems should be standard practice. But this obsession with hiding features is getting a bit pathological (thinking of you, Camera).

Call Screening, on the other hand, could be a real game changer, assuming it actually works in my country.

And the fact that Federighi didn’t burst out laughing while claiming that over the past year Apple Intelligence has been relevant says a lot about how many times that scene was rehearsed.

Almost forgot: the new version numbering for the operating systems. Having a unified scheme for all platforms might be a good thing, but was it really necessary to use the year (and get it wrong, too)? Microsoft already tried that with Windows 95, Windows 98, and Windows 2000. Was it really impossible to come up with something more original?

Anyway, this unification will force Apple to release a new version of half a dozen different operating systems every year, even when they will not have a single noteworthy new feature. Personally, I think an annual release cycle is excessive and unsustainable in the long run. But apparently, Apple’s marketing always needs something new, whether it’s useful or even works is another story.

A last, fairly sad note. How could Tim Cook and his team not find a minute during their hour-and-a-half-long keynote to remember Bill Atkinson? And at a developer conference, no less!

Apple wouldn’t be what it is today without his contributions. RIP.

From melabit to melabit: hosting Jekyll

Tue, 18 Mar 2025 06:00:00 +0000

– Source: Scott Rodgerson on Unsplash.

As promised (or threatened?) in the last post, this post is dedicated to exploring the available options for hosting a Jekyll-based website (or any other static site generator), whether for a personal blog like the one you’re reading, a professional studio, or a small business website.

I could summarize this in two lines and only refer you to what I wrote 6–7 years ago (here and here), but so much time has passed that a proper update is needed.

For those interested in reading the other installments of my transition from WordPress to Jekyll, below is the full list of posts that have been published:

Introduction

I’m not a professional developer, I don’t know much about web development, and I consider myself just a hobbyist when it comes to server and network management.

The thoughts shared below are purely personal reflections, shaped by years of experience and experimentation in managing computing systems – some more complex than others – and web services, both still active and long gone (sadly, more than one). I hope these insights will be useful to anyone considering similar solutions, but those looking for professional answers should turn to someone with deeper expertise.

Why using a Mac isn’t a good idea

As I mentioned last time, I find it impractical to use a Mac as a web server for a Jekyll-based site (or, more generally, for any website, whether static or dynamic).

The reason is simple: for a site with moderate traffic, a Mac is overkill – an unnecessary waste of resources.¹

Development is a different story (I used a Mac for that myself). Having a UNIX-based system with a polished graphical interface, powerful yet user-friendly editors, and tools that streamline coding and debugging is invaluable.

What about an old Mac lying around, why not repurpose it to serve my site?

An old Mac is still great for writing, managing emails, browsing the web, video conferencing, making music, learning to code, and much more. Even better if you install a recent version of macOS using Open Core Legacy Patcher.

But using an old computer as a server, keeping it on 24/7? Personally, I wouldn’t do it, it just doesn’t seem reliable enough. And even if you wanted to try, you’d run into the same broader issues I’ll discuss in the next section.

Why doing it yourself isn’t worth it

Instead of a Mac, we might consider using a PC, perhaps one of those slightly older but still capable mini-PCs, available for just over 100 euros, like the Lenovo M95q or the HP 800 G3. Another option could be a Raspberry Pi 5, though unfortunately, it’s no longer as budget-friendly as it used to be, at least if we plan to use it as a regular desktop computer.

As I mentioned years ago, once you install Linux on these mini-PCs, they become perfect “for learning how to manage a web server and the associated Linux system, or for experimenting with different CMSs or static site generators before deciding which one to use for your website.”

You don’t even need to connect a keyboard and monitor, as everything can be done from the Terminal via ssh. For those who prefer a graphical interface, remote access is easy with Chrome Remote Desktop or with one of the many remote access services we’re all familiar with these days.

But can we use these mini-PCs to run a “real” website, one that needs to be online 24/7?

In my opinion, no.

A website needs a fixed public IP address, and in Italy only Fastweb offers this for free, but under certain conditions. Other providers either don’t know what it is or require special contracts, which are of course more expensive than regular “home” or “business” plans.

I know, there are dynamic DNS services. But the ’90s are long gone, and today I would never trust my web services to a volatile service with unpredictable IP update times. Besides, if you want any level of reliability, you’re going to have to pay for it. At this point, is it worth it?

Another issue is sudden internet or power outages, perhaps due to street work or because your colleague or partner decided to turn on all the air conditioners at once or run the washing machine, oven, and hair dryer at the same time.

Sure, there are UPS devices, but if we’re away from the office or home, even the UPS will eventually run out of power, and our server will shut down.

And let’s not forget the security issue, the inevitable and constant attacks from countless idle youngsters with nothing better to do with their time. If we’re not already security experts, are we really willing to delve into matters far beyond our skill set?

What is worth doing yourself

If you want to do it yourself, the best option is undoubtedly to use a virtual machine on one of the countless cloud services, from UpCloud to Digital Ocean, or Heroku and Linode (now Akamai Cloud), not forgetting the big players like Amazon AWS and Google Cloud (and yes, there’s also Microsoft Azure). If you’re hesitant to buy American right now, here’s a list of European cloud providers.

A virtual machine on the cloud is inexpensive and doesn’t have any of the drawbacks listed so far, except for the security issue, which, however, is at least partially managed by the service provider itself.

Even more secure, and completely free, is to use services like GitHub Pages, which automatically regenerates and publishes the site on github.io every time a linked Jekyll-based repository is updated. The related documentation is very detailed, so there’s no need for me to add anything further.

What I have done

I am a user like many others, and the solution I have adopted can be a good example of how to manage web hosting efficiently and relatively cheaply (which is always a plus), without compromising on service quality.

This site is hosted by Shock Hosting, a hosting service I have been using for years, with a great support service. Actually, I’ve had very few problems over the years, and they’ve always been minor, like paying a bill twice by mistake, but every time the support response couldn’t have been faster.

The basic “Low Shock” plan at $2.99 per month offers unlimited disk space and data transfer, with no artificial speed limits (which few competitors offer). This plan is more than sufficient for a static site, but also for a site based on WordPress or other CMSs (based on my direct experience). The higher plans are identical to the basic one but allow hosting more domains, and switching between plans only requires opening a ticket and a short wait.

The domain name is also managed by Shock Hosting and costs 12 dollars per year (one dollar per month), which is the standard cost for a .com domain.

Of course, Shock Hosting is just one of countless hosting services available, although I find it hard to beat in terms of price/quality ratio. In any case, before making a choice, I recommend paying close attention to the terms of service, as most providers impose more or less strict limits on disk space or data transfer. Others may offer very attractive prices for the first year or the first few months, only to raise them significantly later. If you can test how their support works before committing, that’s a big plus.

Otherwise, choose a service that allows you to pay monthly or quarterly so you can carefully evaluate whether it meets your needs. You can always choose to pay at longer intervals later on.

Avoid like the plague those services that offer massive discounts if you commit for two, three, or more years, or even for… eternity. Nothing on the internet lasts forever; in fact, the so-called eternal services are often the first to disappear. And if that happens, you’ll ve lost everything you paid for in advance, so much for saving money!

The hosting service alone is not enough for melabit.com/posts/en because it doesn’t support running comma to manage comments. The simplest solution would have been to switch to a virtual server, still on Shock Hosting, but I don’t like simple solutions. Besides, the hosting service offers several advantages that I didn’t want to give up: it handles web server management and site security, performs backups, renews the SSL certificate, provides analytics, and much more. All of this is worth far more than the few euros per month it costs.

Just as I was thinking about what to do, I came across this post, and I decided to give the German kitchen a try by purchasing a virtual server from Hetzner. To run comma, the base CX22 plan is more than enough. For less than 5 euros per month, it offers a machine equivalent to the base plan from Shock Hosting, which costs twice as much. The virtual machine is powerful enough that I can also generate the site on it and then transfer the result to Shock Hosting using rsync.

When I chose Hetzner, the ongoing trade war between the U.S. and Europe was only in the minds of the gods, but in hindsight, it turned out to be a wise decision. If I ever lost access to my US-based hosting service or if the cost became prohibitive for a European, it would take very little effort to move everything to a safer location. Bye bye, USA.

Let’s do the math

In this post, I’ve written about why I don’t think it’s worth it to run a website on either a Mac or a PC. But is it at least economically viable to do so?

Let’s start by calculating how much I spend per month for melabit.com/posts/en. Hosting costs me 3 euros, and the virtual server costs 5 euros. That’s a total of 8 euros per month, which adds up to 96 euros per year. I should also add the cost of the domain, but that has to be paid anyway, so I’ll leave it out.

Now, let’s assume I’m stubborn and insist on using a mini PC or a Raspberry Pi to manage my site. Say the barebones computer costs around 100-120 euros. Then, I need to add a decent SSD and a sufficient amount of RAM, which adds at least another 60-100 euros (for the Raspberry Pi, the RAM is fixed and can’t be upgraded, but instead, I’d need to buy a case, a power supply, a practically mandatory heatsink, and an NVMe SSD adapter, again totaling about 100 euros).² Then, I’d also need a UPS, which will add another 100 euros.

The total comes to about 300 euros (give or take 30-40 euros), roughly the same as what I spend in three years. But there’s no guarantee that a mini PC, or even worse, a Raspberry Pi, will last three years of uninterrupted use. Maybe today the fan breaks, tomorrow the power supply, the SSD starts acting up, or the UPS batteries die. In short, even financially, it’s not really worth it.

Trust me, the cloud is much, much better.

In theory, you could dedicate an entire Mac to a website that gets a lot of traffic. But in this case, you need a truly professional solution; doing it yourself is not an option. ↩︎
Staying close to the lower limit of 160 euros seems really difficult to me. ↩︎

From melabit to melabit: managing comments with Jekyll

Wed, 05 Mar 2025 06:00:00 +0000

As noted in the last post, Jekyll does not have a built-in commenting system, but its themes often allow comments to be managed by connecting to third-party services such as Disqus and similar platforms.

The problem with these services is that they can stop working overnight (as happened last year with Muut, which no longer even has a website), or they have opaque usage policies and user data collection practices.

Another issue, which is far from negligible, is that most of these services require users to register before they can comment. Registration is useful for filtering inappropriate comments or spam, but it also acts as a barrier for casual readers who just want to share their thoughts.

Then there is the problem of cost. Some comment management services are paid and not exactly cheap, take Hyvor Talk as an example, which costs 12 euros per month. A price that is more than reasonable for a professional site or a small business that wants to interact with its users – especially since these services often also handle newsletters and other promotional materials – but that is completely out of scale for a toy handmade blog like this one.

Looking for the ideal commenting system

My interest in comment-related issues began a year ago when, after the sudden shutdown of Muut, I observed the enormous work being done behind the scenes by Mimmo, MacMomo, and Paoloo to recover from Muut all the comments from Quickloox – one of the must-read blogs for anyone interested in Apple, Macs, and related topics – convert them to the format of the new commenting engine, and reinsert them neatly into the blog.¹

A few months later, I began working on my own transition from WordPress to a Jekyll, and the commenting system was one of the main problems to solve. With WordPress, this isn’t an issue, because comments are integrated and stored in the site’s database along with the text of the post. But with a static site, like the one generated by Jekyll, it is necessary to implement some mechanism to add comments, which by their very nature are dynamic objects.

In hindsight, I could have followed Mimmo’s advice and chosen Comma from the beginning. But coming from WordPress, using a database seemed like the most natural approach.

So I tried Cusdis, Commento, Commento++, Remark42, and Zooment, all database-based commenting systems.¹ I carefully followed the instructions step by step, I used Docker, I ran Linux virtual machines on the cloud, I tested services that are supposed to handle everything automatically, like Railway and Vercel. Nothing worked. There wasn’t a single commenting system that worked like it should!!²

I also ruled out all systems that rely on GitHub, such as Giscus, Staticman, or utterances. These are perfect for developers who already have a GitHub account, but impractical for casual readers who would be forced to create yet another unnecessary account. That left only one option. Comma, of course.

Working on Comma

And Comma it was. Comma is written in Go and is distributed only as source code. To compile it, we need a compiler for the Go language. On a Mac, the compiler can be installed by downloading the prepackaged package and following the instructions, or via the usual Homebrew with

$ brew install golang

Similarly, on Linux, Go can be installed by downloading a compressed file and extracting it into the usr/local directory, or using the package manager commands of our distribution,

$ sudo apt install golang
$ sudo dnf install golang
$ sudo pacman -S go

depending on whether we are using Debian/Ubuntu, Fedora/CentOS, Arch, or one of their countless derivatives.

Once Go is installed, compiling Comma is a matter of seconds,

$ git clone https://github.com/Dieterbe/comma.git
$ cd comma/src
$ go build

where the last command checks that the program compiles correctly. If everything is fine, we can run

$ go install .

which compiles the source code and installs the comma executable in ~/go/bin/ (as usual, the ~ represents the Home directory of the account we are using).

Before cloning the Comma repository, I made a fork in my personal account, but only because I wanted to tweak a bit the code a bit.

The first thing I did was to change the filename extension of the comments from .cmt to .xml (lines 67 and 105 of my comment.go file). Comma comments are stored as XML files, and there was no reason to use a non-standard extension. Also, this change makes it easier to open them with a text editor, which will automatically format them for better readability. A small convenience, but very useful during development. To further improve readability, I also added four spaces before each XML tag (lines 71-73 of comment.go).

Lastly, I removed the requirement to enter an email address when submitting a comment (lines 94-96 of main.go). My goal was to have a site free of any form of user tracking, thus avoiding many headaches related to GDPR compliance.³ In theory, this could pose some security risks, but do we really think that someone with malicious intent would enter their real email address?

For the frontend – i.e., how the user sees his new comment as well as the list of previous comments – I used most of the original code from the author of Comma, adapting it to work with Jekyll. To that I added Markdown support and filtering of potentially malicious code from comments. For these two features, I took a lot of inspiration from the code that by Mimmo, MacMomo, and Paoloo wrote for Quickloox.

As for the icons associated with each commenter, I chose to generate them with Jdenticon, probably because its symmetrical geometric patterns fit my personality better.

The final appearance of the comments seems quite pleasant and well integrated with the rest of the site, and the localization works well, even in small details like the more prominent thin line under “Add a comment,” that changes depending on whether the text is in Italian or in English.

All the frontend code is in _includes/custom/comma-comments.html. While I was at it, I also added a small JavaScript function to the post page (_layouts/post.html) that allows users to jump back to the top of the post with a single click. I originally needed it during development, but I believe it could be useful for readers as well, so I left it in the final code.

Putting all together

Once the comment system and the code to display them on the site are ready, we need to make everything work together. First, we need to create a folder to store all the comments,

$ cd
$ mkdir ~/comments

and start Comma manually,

$ ~/go/bin/comma ~/comments localhost:5888
$

telling it it to listen for new comments on port 5888 of the local computer localhost and save them in the ~/comments folder. The last step is to add a line to _config.yml to connect Jekyll to the comment server

#--- Comma comments ---
commentserver: http://localhost:5888

and everything should work on the first try.

If instead of a physical computer we are using a cloud virtual machine, we will need to replace localhost with the machine’s reverse DNS name (see the previous post). However, the exact steps depend on the service we are using, so I can’t be more specific.

On a real site, things get a bit more complex, for example, because one needs to use the secure https: protocol instead of simple http:, which requires proper web server configuration. But again, the details depend on the web server, the configuration of installed services, and so on, making it impossible to explain everything without writing a whole manual.

However, I can say for sure that a real website requires Comma to be started automatically, just like the web server that manages the site.

Assuming that the site is running on a Linux server (in the next post, I will explain why using a Mac as a web server doesn’t make much sense) and that Comma was installed by the user webuser, in order to start Comma automatically on every system reboot (as well as when the program stops unexpectedly), we need to run

$ cd /etc/systemd/system
$ sudo touch comma.service

which creates an empty configuration file called comma.service. We need to add the following lines to this file,

[Unit]
Description=comma backend server
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/home/webuser/go/bin/comma /home/webuser/comments :5888
Restart=always
RestartSec=1
User=webuser
Group=webuser

[Install]
WantedBy=graphical.target

making sure to replace webuser with the actual username of the user who installed Comma. Running,

$ sudo systemctl enable comma

activates the automatic startup mechanism, allowing us to almost forget about Comma’s existence. To manually interact with the service, we can use the following commands,

$ sudo systemctl status comma
$ sudo systemctl stop comma
$ sudo systemctl start comma

which are useful for checking the status of the service or manually stopping and restarting it. These commands are particularly useful during debugging, but can also be helpful in production, so it’s good to know they exist.

Conclusions

I had originally planned to end this long journey through the technical description of the new site here. However, while writing this post, I realized that a few words about hosting might be useful. And that will be the subject of the next post.

And not even a small database like SQLite! All these comment systems use heavyweights like MariaDB or PosgreSQL. ↩︎ ↩︎
If I were mean, I might think the instructions were wrong on purpose to push me to use their paid cloud solutions. But I am a good guy. ↩︎
I have nothing against GDPR. In fact, I think it is a very useful regulation, at least in theory. In practice, however, it does little to truly protect user privacy and ultimately becomes a not-so-useful bureaucratic burden. ↩︎

From melabit to melabit: developing a web site in Jekyll

Sat, 01 Mar 2025 06:00:00 +0000

After the first part dedicated to installing and configuring Jekyll, this second part of these annotated notes dives into developing a Jekyll site using a pre-existing theme. On the other hand, developing a theme for Jekyll from scratch is far beyond my expertise, but those who can do it don’t need to read these notes.

What do we want?

First, we need to have a clear idea of what the site should look like graphically and what features it should support. Do we want a personal blog with a simple list of posts? Do we want a more elaborate magazine-style site? Do we need a showcase site to present our business or a specific project? Do we want a photography or documentation site?

Once we’ve clarified the site’s “specifications,” we can look for the Jekyll themes in this site for Jekyll, or here, here and here (I can’t tell them apart by name because they are all called Jekyll Themes). The most patient among us can go through the themes one by one, while others may prefer to filter by the type of site they’re interested in and only look at those themes. In any case, it’s good to take note of the themes we like the most and try out the demo sites, when available. It’s useful to keep an open mind – we could find an interesting theme that doesn’t fit our original specifications, and it’s worth noting that down, too.¹

How a theme is structured

Now, it’s time to try some theme out. To avoid being too generic, I’ll describe the installation of the Mundana theme which, coincidentally, is the one I used for melabit.com/posts/en.

Like Mundana, most Jekyll themes that are not gem-based are installed by cloning their GitHub repository or downloading a compressed file (in which case, all the following parts related to git can be skipped). In both cases, what we install is both the theme and the actual site because, in Jekyll, there is no strict separation between design and content.

The first thing to do is install git on the computer. On macOS, it comes preinstalled, but it’s usually an outdated version, and as I mentioned last time, it’s always better to keep system tools separate from development tools. With Homebrew, installing the latest (or nearly latest) version of git on the Mac is a matter of seconds,

$ brew install git

On Linux, the process is similar, but this time we must use the package manager of our distribution. This means we need to execute one of the following commands,

$ sudo apt install git
$ sudo dnf install git
$ sudo pacman -S git

depending on whether we use Debian/Ubuntu, Fedora/CentOS, Arch, or one of their many derivatives.

As already mentioned, installing Mundana is done by cloning its repository,

$ git clone https://github.com/wowthemesnet/mundana-theme-jekyll.git
Cloning into 'mundana-theme-jekyll'...
remote: Enumerating objects: 324, done.
remote: Total 324 (delta 0), reused 0 (delta 0), pack-reused 324 (from 1)
Receiving objects: 100% (324/324), 4.12 MiB | 24.52 MiB/s, done.
Resolving deltas: 100% (116/116), done.

or by downloading and extracting the project’s zip file.

The developers suggest making first a fork on our GitHub account and then cloning from there. This makes sense if we plan to contribute to the code; otherwise, it seems like an unnecessary step. Anyway, those who know what a fork is don’t need further instructions.

Once the installation is complete, we can navigate to the Mundana directory and explore a bit (for clarity, all directory names end with a /).

$ cd  mundana-theme-jekyll
% ls -nhp
total 72
-rw-r--r--   1 501  20   398B Feb 12T19:58:00 404.html
-rw-r--r--   1 501  20   510B Feb 12T19:58:00 Gemfile
-rw-r--r--   1 501  20   1.7K Feb 12T19:58:00 Gemfile.lock
-rw-r--r--   1 501  20   2.0K Feb 12T19:58:00 README.md
-rw-r--r--   1 501  20   1.7K Feb 12T19:58:00 _config.yml
drwxr-xr-x  11 501  20   352B Feb 12T19:58:00 _includes/
drwxr-xr-x   6 501  20   192B Feb 12T19:58:00 _layouts/
drwxr-xr-x  11 501  20   352B Feb 12T19:58:00 _pages/
drwxr-xr-x  20 501  20   640B Feb 12T19:58:00 _posts/
drwxr-xr-x   5 501  20   160B Feb 12T19:58:00 assets/
-rw-r--r--   1 501  20   149B Feb 12T19:58:00 docker-compose.yml
-rw-r--r--   1 501  20   9.2K Feb 12T19:58:00 index.html

The Mundana directory contains two service files for RubyGems, Gemfile and Gemfile.lock, as well as the docker-compose.yml file, which is only needed if we run Jekyll inside a Docker container (which is not relevant here). Everything else is related to Jekyll.

Static pages go into the _pages folder, while all the more dynamic content, such as the blog posts that are updated more frequently, goes into the _posts folder. The content of static pages and posts can be written in either HTML or Markdown.

The _layouts folder contains files that generate the main parts of the site, such as static pages, blog post templates, or sidebars, while the _includes folder contains snippets of code that can be included in other pages, more or less like library functions.

These four folders, all prefixed with an underscore _, are processed by the Jekyll engine, which uses them to generate the actual HTML pages for the static site.

The assets folder, on the other hand, holds site content that Jekyll does not process, such as the CSS files that define the site’s design, the JavaScript files for interactive features,² and all site images. When Jekyll generates a site, this folder is copied as is, and the system automatically creates links to the various files.

Finally, the _config.yml file contains all the site configuration parameters, such as the site name and description, the links to the site’s logo and favicon, the required plugins, the pagination settings, and a list of files and service folders that Jekyll should ignore. The _config.yml file can become quite long and complex, so for simplicity, here’s just a small portion of the default _config.yml file for Mundana.

# Site
name: 'Mundana'
description: 'Mundana is a free Jekyll theme for awesome people like you, Medium like.'
logo: 'assets/images/logo.png'
favicon: 'assets/images/favicon.ico'
baseurl: '/mundana-theme-jekyll'

[...]

# Plugins
plugins: 
  - jekyll-feed
  - jekyll-sitemap
  - jekyll-paginate
  - jekyll-seo-tag
  
[...]

# Paginate
paginate: 10

# Exclude metadata and development time dependencies (like Grunt plugins)
exclude: [README.markdown, package.json, grunt.js, Gruntfile.js, Gruntfile.coffee, node_modules]

Since we’re at it, let’s make our future work easier with a small modification to the _config.yml file, replacing the line baseurl: '/mundana-theme-jekyll' with baseurl: ''.

Almost forgot: plugins (and their dependencies) are also Ruby gems and are not installed by default, so we need to install them. First run

$ rm Gemfile.lock

to prevent conflicts between plugin versions listed in the Gemfile.lock file and newer versions that Ruby suggests to install. After that, run

$ bundle install
[...]
Fetching gem metadata from https://rubygems.org/............
Resolving dependencies...
Fetching jekyll-paginate 1.1.0
Installing jekyll-paginate 1.1.0
Fetching jekyll-sitemap 1.4.0
Installing jekyll-sitemap 1.4.0
Bundle complete! 4 Gemfile dependencies, 39 gems now installed.
Bundled gems are installed into `[...]/.gems`

that installs the actual plugins (and automatically regenerates the Gemfile.lock file with the newly installed versions of the plugins).

Testing Jekyll again

All that is left now is to test Jekyll again, this time with the theme we just installed.

$ bundle exec jekyll serve --host=0.0.0.0

The site will be quickly regenerated and will be available on our real machine at the URL http://localhost:4000. If we are using a virtual machine or a cloud server the port will still be :4000, but the URL will depend on the configuration of the machine (for cloud servers, the URL usually has a label like reverse DNS name or something similar).

Compared to the simple gem-based themes covered in the previous post, Mundana is clearly on a different level. At the top of the page are the four most recent posts, along with their images. In the center, a featured post is prominently highlighted against a contrasting background (for example, it could be the most recently published post). Below that, all other posts are arranged in reverse chronological order. On the side, a sidebar contains posts that we want to highlight.

If we replace Mundana’s default posts with our own, add the images, make two or three modifications to the _config.yml file, and within minutes we could have a site ready to go online, with all the posts neatly organized into well-structured pages (as you can see here).

When the default theme is not enough

A well-designed theme is very convenient and, as we’ve just seen, allows you to get online quickly with minimal effort. However, it may not fully meet everyone’s needs as it is.

For example, I wanted to create a multilingual site in both Italian and English – something that Mundana does not support by default.

Additionally, I wanted the site’s Home page to display a summary of the latest posts with thumbnail previews of the featured images, but didn’t want the thumbnails to appear in the individual post pages. Mundana handles the first requirement correctly, but not the second.

Another issue concerns pagination: the default pagination looks nice, but it displays a single horizontal row of links to all the generated pages. When there are too many pages, this row expands excessively, overlapping other graphical elements on the page or extending beyond the browser margins.

Lastly, Mundana natively supports the Disqus commenting system, but I preferred a self-hosted solution, to avoid reliance on third-party services that could change their terms of use or, worse, shut down unexpectedly.

Let’s get to work!

All the modified theme code is available on GitHub, at https://github.com/sabinomaggi/mundana-theme-jekyll-multilang.

Pagination

Let’s start with pagination. Since Jekyll version 3 (we are now at 4.4.1), pagination has been managed by the jekyll-paginate-v2 plugin. In Mundana, the pagination code is integrated into the index.html file and is quite simple, which can cause issues when the number of pages grows.

I moved the pagination logic to _includes/custom/paginator.html,³ making sure that the links only point to a subset of the available pages: those adjacent to the current page, the first and last pages, and an intermediate page calculated based on the distance of the current page from the first (or last) page. This approach allows pagination to work correctly even on very narrow windows or mobile devices.

There isn’t much to say about the code: starting from the current page, all other pagination elements are determined, dynamically generating the HTML code for each link. All the logic is written in Liquid, the templating language used by Jekyll. Liquid’s syntax is a bit peculiar and requires some workarounds with variables, but the important thing is that it works.

Actually, the most interesting part of the code is the first line, which dynamically changes the text strings based on the active language. But that brings us to the next section.

Multilingual support

Jekyll can handle multilingual sites using the jekyll-polyglot plugin, but it does not interact well with the jekyll-paginate-v2 plugin,⁴ so I needed a different solution.

Polyglot is very easy to use: you just need to add the plugin under the relevant section in the _config.yml configuration file and define two new variables for all the languages you want to support.

[...]

# Plugins
plugins: 
  [...]
  - jekyll-polyglot

[...]

# Polyglot
languages: [en, it, de, fr]
default_lang: en

To set the language of a post, simply add the lang: variable (e.g., lang: en or lang: it) to its front matter, and you’re done.

The front matter in Jekyll is a block of metadata in YAML format placed at the beginning of a Markdown (.md) or HTML (.html) file.

The front matter is enclosed by three dashes (---) and provides information about the page or post, such as the title, language, layout, and settings for customizing the page behavior. For example:

---
title: "Welcome"
layout: default
permalink: /it/
lang: it
---

When Jekyll processes the site, it uses the front matter to:

Define the template to use for rendering the page (layout: default).
Customize the URL associated with the page (permalink: /it/).
Set specific variables for that file, which can be used in layouts and themes (lang: it).

If a page or post includes the lang: it variable in the front matter, Polyglot can use it to apply content or styles specific to the Italian version of the site.

My idea was to manually emulate the behavior of polyglot. The first step was to define two new variables in _config.yml, that are similar to those used by Polyglot:

#--- Custom localization variables ---
# Polyglot does not work well with Paginate-v2
# define these two variables instead
locales: [en, it]
default_locale: en

I also added a new variable to the front matter of each page or post, which, following the same pattern as _config.yml, could be either locale: en or locale: it.

To simplify language management, I created two subfolders, en and it, inside the main _posts directory to store posts in their respective languages. This way, it is very easy to add the correct locale variable to each group of posts with sed.

Lastly, I leveraged a Jekyll feature: when Jekyll finds a file with a language indicator in its name, it treats it as another version of the original file (without the indicator), inheriting all its content but using the specific variables defined in its front matter.

In other words, if I have an index.html file that contains all the code for the Home page of the site, and I create a new empty index_it.html file, adding the locale: it variable to its front matter, the index_it.html file will inherit all the content from index.html, but will use the locale variable to localize the page for Italian. This mechanism is well documented in some pages I consulted, but unfortunately I can’t find the links anymore.

One last detail: when using pagination, the locale: it variable must be defined inside the pagination: variable in the front matter:

pagination:
    enabled: true
    locale: it

Therefore, all code that dynamically determines the language of a page must always check both the page.locale and the page.pagination.locale variables.

Of course, all text strings on the site must also be adapted to the selected language. To achieve this, there is a _data/translations.yml file containing English and Italian translations for all the strings used.

Needless to say, setting up the localization mechanism correctly took the most time during the development of melabit.com/posts/en. However, the way it’s done allows to add a new language in just a few steps: add the new language code to the locales variable in _config.yml, add another folder inside _posts, and include the language flag image in assets/images. Almost makes me want to try it… 😂

Thumbnails and comments

After dealing with localization, removing the thumbnail from post pages was easy. I just had to find the relevant lines of code and comment them out. Problem solved.

Comments, on the other hand, were a completely different story, even more complicated than localization. But that will be the topic of the next post.

For example, while writing this post, I came across this theme, which doesn’t match my original idea for a site but might have worked just as well (but I’m not changing now). ↩︎
Jekyll is a static site generator, but even static sites today require a certain level of dynamism to handle things like search functionality, comments, and more. ↩︎
I placed all the new code inside the custom folder to physically separate it from the original theme files. ↩︎
Since several posts from 4-5 years ago report successfully using both jekyll-polyglot and jekyll-paginate-v2, this may be a Mundana-specific issue. Alternatively, it could be an incompatibility that has emerged in the latest versions of Jekyll or of the two plugins. ↩︎

From melabit to melabit: Jekyll, installation and basic configuration

Tue, 11 Feb 2025 06:00:00 +0000

This post is not meant to be a detailed guide on installing and configuring Jekyll; for that, there are excellent guides listed below.¹

Instead, this post is a commented collection of notes I took while developing melabit.com/posts/en. They are the result of days and days of trial and error, changes in direction, and research to find the right command. These notes were useful for me to remember what I had done and how I had solved the issues that arose from time to time. They might be useful for you to get everything done more quickly and smoothly.

Installing Jekyll

To experiment with Jekyll, there is nothing better than using a virtual machine, preferably with a lightweight Linux server version. A good alternative is a virtual cloud server, even a cheap one, like UpCloud, Google Compute Engine, Amazon EC2, or similar. However, for serious work, it is much more convenient and faster to use a real machine, especially since following these instructions makes the risk of damage almost nil. Luckily, I had an old Mac available, which allowed me to try and retry, knowing that if any issues arose, I could easily reset it.

The best guide for installing Jekyll is undoubtedly the official one, with specific instructions for the most common operating systems.

The guide for macOS is well-done, but the installation requires Homebrew and a number of steps to be followed carefully. On Linux, the installation is much easier, while on Windows, the best approach is to install the Windows Subsystem for Linux (WSL) and then work essentially in a Linux environment.²

An important detail missing from the macOS instructions—but present in those for Ubuntu, FreeBSD, and other Linux distributions—is that before executing the final command gem install jekyll (or even before starting the Jekyll installation), it is advisable to add these lines to the ~/.bashrc or ~/.zshrc file (depending on the shell used):

#--- Install Ruby gems in the user account, e.g., in ~/.gems ---
export GEM_HOME="$HOME/.gems"
export PATH="$HOME/.gems/bin:$PATH"
#--- end ---

Then, execute source ~/.bashrc or source ~/.zshrc to activate the new environment variables (I usually just close and reopen the Terminal).

What are these lines for? They instruct RubyGems, Ruby’s package manager, to install all its gems,³ including Jekyll, in the user account instead of system-wide. This is a good practice as it separates the native Ruby installation within the operating system from everything we install ourselves, allowing us to fix inevitable errors without risking system integrity.

At this point, you can proceed with the actual Jekyll installation,

$ gem install jekyll

Immediately after, install another very useful gem, Bundler,

$ gem install bundler

which, inexplicably, is completely omitted from the macOS instructions.

To instruct bundler to install everything within the user account, execute

$ bundle config set --local path $GEM_HOME

Finally, if you are using a virtual machine or cloud server and your main operating system is macOS, install this gem,

$ gem install rmate

which will allow you to use TextMate, which I consider the best overall editor for macOS, to edit files remotely instead of using nano, vim, or emacs directly on the virtual/cloud machine (being a Linux server version, it lacks a graphical interface).⁴

Your first Jekyll site

After installing Jekyll, all guides suggest creating a new site with

$ jekyll new my-new-blog

which creates a new my-new-blog folder in the current directory. Moving into the new folder and starting Jekyll’s built-in web server,

$ cd my-new-blog
$ bundle exec jekyll serve --host=0.0.0.0

will allow you to view the new site at http://localhost:4000 if using a real machine. With a virtual/cloud machine, you should point the browser to the public URL provided by the server, always using port 4000.

This procedure is useful for verifying that everything works, and Minima, the default theme, is very clean and elegant. If Minima is enough for you, you can stop here, simply add a site title and content, and you’re ready to go.

However, this process gives only a vague idea of what Jekyll can really do since its features are tightly integrated with its themes.

Jekyll and its themes

Minima is an example of a gem-based theme, installed outside the site’s folder and theoretically easily replaceable with another gem theme, like the one shown below.

However, such themes are rare, generally minimalistic, and harder to modify or extend. Worse yet, they are often designed for outdated Jekyll versions and may not work with the latest ones.⁵

Most Jekyll themes instead come in a format that combines content and design within a single folder. This is very convenient when you find the right theme but makes changing themes later much more complicated.

Installing most Jekyll themes essentially means installing an entire pre-built site, then replacing the default posts and images with your own. Therefore, it is best to first choose a theme that suits your needs and then start customizing it.

But this will be the topic of the next post.

If you no longer like Jekyll

Then you need to uninstall everything. The modern way to do this is with

$ gem uninstall --all --ignore-dependencies --executables --verbose

or, for those who love compact commands

$ gem uninstall -aIxV

If you followed the initial advice of installing everything in the user account, no admin privileges are needed. Otherwise, you’ll have to prepend sudo as a penalty for your mistake.

After uninstalling all gems, you could also remove ruby and related packages using Homebrew on macOS or the package manager for your Linux distribution. But with today’s large disks, is it really worth the effort just to save a few MB?

Until next time

This post is already too long, so let’s end it here. The next post will dive into the actual development of a Jekyll site. See you soon!

With Jekyll’s extensive documentation, the real challenge is distinguishing useful guides from time-wasters. ↩︎
From now on, I won’t mention Windows, as the necessary instructions are identical to those for Linux. ↩︎
A gem is a program or a library written in Ruby that contains everything needed to run it or to develop new programs that utilize its functions. Gems are installed using the standard package manager, RubyGems, whose gem command allows performing all installation, update, and uninstallation processes for various gems. ↩︎
Of course, this is irrelevant for vim or emacs masters. ↩︎
When I say “often,” I am not exaggerating at all. ↩︎

Apple, we fixed some issues: from Sonoma to Sequoia

Tue, 04 Feb 2025 06:00:00 +0000

– Image generated by Microsoft Designer AI.

In the past few months, I have written four posts about macOS Sonoma bugs (a complete list is at the end of this post) because I found it unbelievable that this macOS version was released with such glaring issues in the Finder and in disk management.

In the latest Sonoma versions, some reported bugs – such as the erratic emptying of the Trash, the default file name when virtually printing a web page to PDF, or the failure to display a new file or folder in Snap to Grid mode — have been fixed, but the most annoying ones remained untouched.

A couple of days ago, after testing macOS Sequoia on a spare machine, I decided to upgrade my home Mac Mini M1 to Sequoia 15.3. To my great satisfaction, I can say that all, or almost all, of the major bugs reported in my previous posts have disappeared.¹

Bug #1: If we have a folder full of files and drag icons below the bottom of the window while holding down the CMD (⌘) key, the bottom of the window now correctly expands to show the lower icons without making them look like they have disappeared. The only exception is when the folder does not have an active scrollbar because it contains too few files. In this case, the icons still disappear, just like in Sonoma, but now you can simply click the < icon in the upper left corner of the toolbar and return to the original folder to restore full file visibility.

Bug #2: If we have two overlapping Finder windows in a Space and use the CTRL(⌃)-1, CTRL–2 (and so on) shortcuts to move the top window from one Space to another, upon returning to the original Space the traveling window now appears on top of the one that stayed put, as it should. The same applies when more than two overlapping windows are present.

Bug #3: The flickering issue that was highly visible in Sonoma when dragging a Finder window from one Space to another has now disappeared. Seeing such a thing was simply outrageous, not only because it was happening on machines powered by the powerful Apple Silicon processors, but also because before Sonoma such flickering had never been seen on much, much less powerful machines, like the Intel-based MacBook Air.

Bug #4: Sequoia has also fixed the bug related to the popup window that disappeared faster than a Formula 1 car when connecting a USB stick to a laptop, but I had already written about that.

Bug #5: Finder has finally returned to normal when displaying folders on an external USB drive containing hundreds of files. The sluggishness (to put it mildly) experienced in Sonoma was truly frustrating, and I was fed up with having to wait dozens of seconds every time I accessed a somewhat full external folder.

Bug #6: But the real highlight of Sequoia, the one that earns it a solid B at the end of the first term, is that, for the first time in years, the macOS update did not mess up the arrangement of icons in the Applications folder. There will be very few people, like me, who prefer to keep installed applications organized visually rather than alphabetically. But I still want to represent these few users and sincerely thank Apple developers for a fix we had been waiting for through countless macOS versions.²

What else can I say? I am really pleased that Apple has managed to fix so many embarrassing Sonoma bugs with Sequoia. Especially because the ones I reported were not related to exotic features of the operating system or of the file system, but rather easily visible issues for anyone using the graphical user interface of macOS.

I doubt that someone in Cupertino is avidly reading Melabit. But this also means that the issues reported in my previous posts were real and evident to other users and Apple developers alike, not just the imaginary concerns of an overly meticulous user.

The core problem remains: it makes no sense to continue with this policy of annual macOS (and iOS, iPadOS, watchOS, etc.) releases, each packed with shiny, but mostly useless new features that are inevitably under-tested and may introduce new bugs into the core of the system, without allowing enough time to fix existing bugs.

An annual release cycle may be great for marketing, but is it really what users really need?

For those interested in my saga about macOS Sonoma’s bugs (and more), here are links to previous installments:

So much so that soon afterwards, I also updated the Mac Studio I use for work. ↩︎
It seems clear to me that there was no technical reason behind this issue (such as the strict separation between the default macOS applications and those installed by the user), but simply a lack of attention to a detail that may be minor, yet is quite annoying for those who rely on it. ↩︎

Frozen Mac? How to recover it using DFU mode

Tue, 19 Nov 2024 06:00:00 +0000

– Source: Apple Support.

Experimenting can sometimes lead to issues. That’s exactly what happened to me after a failed macOS installation, which resulted in a big question mark with a prompt to visit the Mac restore page.

For some years now, when a Mac is unable to boot macOS and cannot even run macOS Recovery to repair or reinstall the OS, the only way to bring it back to life is to enable DFU Mode (Device Firmware Upgrade). This mode is stored in ROM and cannot be erased under any circumstances.¹

DFU Mode has been used for years (forever?) to revive an iPhone or iPad (as well as iPod, Apple TV, and Apple Watch). To use this mode, you connect the device to a Mac, press a specific key combination, and proceed with the restore directly from the computer.

With Intel Macs, recovery used to be different. By pressing specific key combinations, such as CMD (⌘) and R, ALT (⌥), CMD (⌘) and R, or SHIFT (⇧), ALT (⌥), CMD (⌘) and R, you could boot into macOS Recovery from Apple servers to download and reinstall macOS.

In 2018, with the introduction of the T2 Security Chip, internet-based recovery was phased out, and DFU Mode became the only way to restore an unbootable Mac. The downside? You need a second working Mac, which fortunately can be either Apple Silicon or Intel.

But that’s not all. Besides a second Mac, you’ll need three other items and a bit of coordination.

First, you need a USB-C cable to connect the sick Mac to the functioning one, which acts as the doctor. In theory, third-party cables don’t work, but one from my collection activates DFU Mode without issues. If you want to play it safe, I recommend Apple’s 1-meter cable, which is reasonably priced and long enough. Alternatively, there’s the 2-meter cable, though it’s more expensive. Either way, buying a cable costs much less than a trip to the nearest Apple Store.

If the doctor Mac lacks a USB-C port, you can use a USB-A port with an adapter, such as this one or this one, which I’ve personally tested.

The cable connects to the DFU port of the Mac being restored (any USB port works for the doctor Mac). Which port is the DFU port? It varies, and you can find the details here. On the MacBook I restored, it was the port closest to the screen. Wouldn’t it be easier to just mark the correct port?

Lastly, download Apple Configurator 2 from the App Store onto the doctor Mac. Though recent macOS versions allow using Finder, I find Apple Configurator more convenient.

Once everything is ready, open Apple Configurator 2 on the doctor Mac and keep it in the foreground.

If restoring a desktop Mac, unplug the power cable, press the power button while reconnecting it, and wait 10 seconds. A large DFU square will appear on Apple Configurator, signaling success.

For a MacBook, patience is key, as activating DFU Mode may take several tries. Following Apple’s official instructions, which suggest holding four keys for around 10 seconds, didn’t work for me. Pressing for longer didn’t help either.

Fortunately, I found this video by Mr. Macintosh, followed his steps, and finally succeeded in enabling DFU Mode.²

Once DFU Mode is enabled, you have two options. The first is to try reviving the Mac by restoring macOS Recovery without erasing the system disk. Right-click on the DFU square in Apple Configurator, select Advanced, then Revive, and wait while the Mac downloads the macOS Recovery image and transfers it to the sick Mac. If successful, your Mac will be fully operational with all files and applications intact.

If Revive fails, you’ll need to perform a more drastic Restore, which will reset the Mac to factory settings and install the latest macOS version.

To Restore, right-click on the DFU square and select Restore. Apple Configurator will confirm if you’re sure about resetting the Mac to factory settings. The process, which can take an hour or more depending on your network speed, will download and reinstall macOS.

When the reinstallation of macOS is complete, your Mac will be fully functional but all files and applications will be lost. Not a big deal if you can restore everything from Time Machine (because you always use Time Machine, right?).

Unless there’s hardware failure, in which case service is required. ↩︎
There’s also a newer video with two additional methods to enable DFU Mode on a MacBook, though the original method should usually suffice. ↩︎

Apple, we have a problem: a new macOS Sonoma bug

Thu, 14 Nov 2024 06:00:00 +0000

– Image generated by Microsoft Designer AI.

Sonoma’s bugs never fail to surprise, and here I describe a fresh one, which luckily has been fixed in Sequoia.

Take a new MacBook Air or Pro, where you’ve just installed Sonoma, or a MacBook where you erased the startup disk before installing Sonoma (what happens when simply updating from a previous version might be different).

Try inserting a USB stick or external USB drive (or even an SD card, when available). What you’ll see is this:

That is, you’ll see practically nothing, even in slow motion.

In theory, macOS should display a pop-up window asking the user whether they want to allow the connection of the USB accessory (as Apple calls it) to the Mac. The problem is, as shown in the video, the pop-up disappears faster than a Formula 1 car.

I must say that the first few times this happened, I didn’t even see it. Only after several unsuccessful and increasingly frustrating attempts, a very quick shadow on the screen made me suspect an overly zealous disappearing window.

This bug occurs with macOS Sonoma 14.6; I have no idea if previous versions are affected. To work around the issue, you need to go to System Settings under Privacy & Security and change the Allow accessory connections option from Ask Every Time, or Ask for New Accessories, to Always.

Once the USB drive is connected, for added security, you can return to selecting the Ask for New Accessories option—just remember to repeat the procedure every time you insert a new USB stick (or external drive).

At first glance, it seems strange that the consent request for connecting new accessories only appears on MacBooks and not on desktop Macs.

But thinking about it, it makes sense. I don’t believe macOS developers want to prevent us from connecting our own USB drives or those of people we know. Instead, I think they want to prevent someone from surreptitiously inserting a malicious USB stick (also known as a Rubber Ducky), which can now even be made at home with a low-cost Raspberry Pi Pico.

These sticks are programmable and can cause serious damage to a computer, from automatically transferring sensitive files onto the stick,¹ to erasing—if the programmer has the admin account password—the entire system disk.

It goes without saying that such an attack is more likely to happen on a MacBook, often left unattended, rather than on a desktop computer, which remains in more controlled environments like home or the office.

Including this type of security check in the operating system is therefore a great idea; what’s terrible is how it’s implemented in macOS Sonoma.

The good news is that in macOS Sequoia, the bug has been fixed, and the pop-up remains clearly visible on the screen until the user makes a choice.

For those interested in my saga on macOS Sonoma bugs (and more), here are links to previous posts:

It’s not just stealth aircraft designers at risk of this happening, as it could just as easily involve documents from a divorce case or a financial dispute. ↩︎

Apple, we have a problem: a look at macOS Sonoma bugs (update)

Fri, 31 May 2024 06:00:00 +0000

– Image generated by Microsoft Designer AI.

A couple of months ago, I listed some more or less serious bugs in Sonoma that I noticed while getting familiar with the latest version of macOS, first on the new Mac Studio M2 Ultra and then on the household Mac Mini M1.

At that time, I was using macOS Sonoma 14.3, which I soon updated on the Mini to version 14.3.1. With this minor release, Apple fixed a couple of the bugs I described, specifically the one about emptying the Trash into a random Space and the issue that prevented giving decent names to PDF files generated by the Print function.

Since I primarily use the Print (virtual) function for PDFs in Firefox, I suspected this bug might be tied to the browser rather than the operating system. But that’s not the case. On the updated Mini, the issue disappeared, but the Mac Studio, which stayed on version 14.3 longer, continued to bother me despite having the exact same browser as the Mini.

Now both machines have macOS 14.5 installed, and the PDF naming issue has disappeared on the Mac Studio as well. However, all the other bugs I reported still happily persist. In fact, with this post, I’m adding two new bugs, one of which immediately climbed to the top of my list of annoyances.

The first bug was pointed out to me by Mimmo (thanks!) back in the days of Sonoma 14.3. It involved Safari occasionally hiding the text within a selection, as shown in the image below.

It’s not a major issue, I admit, but it’s surprising in a product from a company as detail-oriented as Apple. Apparently, Cupertino thought so too, as it seems to have been fixed in the transition from version 14.3 to 14.5. That’s better.

The other bug is so obvious that I can’t understand how I missed it before: every time I open a folder with a large number of files, Sonoma’s Finder takes an eternity to display them.

For years, I’ve used an external USB drive to store everything I want to keep but don’t need daily. Some folders contain thousands and thousands of files, but until now, viewing their contents was always instantaneous, or nearly so. And this was even with a mechanical drive—high quality but still mechanical.

With Sonoma, everything suddenly changed: every time I open a very full folder, I have to wait several dozen seconds before seeing its contents. And when I say dozens of seconds, I mean 40, 50, even 60 seconds for a folder with 1,000–2,000 items. That’s a lot, sure, but it’s not the end of the world.

What’s strange is that until Monterey, with the same external drive, viewing was practically instantaneous, so I don’t think it’s a disk or connection speed issue.

To rule out doubts, I even purchased a 2 TB NVMe SSD, which I installed in an external hub connected to the Mini via USB-C. Now folder contents load faster (as expected!) but still much slower than what would normally be expected. Roughly speaking, it takes half the time it did before, which for an NVMe SSD—even an external one—still seems unacceptable to me.

I hope Apple has noticed the problem and will fix it with macOS 15. Otherwise, I might actually have to file a bug report, and I really don’t feel like doing that.

From Intel to Apple Silicon

Mon, 11 Mar 2024 06:00:00 +0000

– Source: Viktor Forgacs on Unsplash.

The transition is complete: since a few days, all the computers I use for work are running on Apple Silicon ARM processors. This includes a Mac Studio M2 Ultra, which I’ve already talked about extensively and which sits on my office desk; a Mac Mini M1 with 16 GB RAM and 1 TB SSD – previously neglected on a shelf for reasons I won’t go into here – now in my home office; and a very basic MacBook Air M1 (just 8 GB RAM and 256 GB SSD, half the specs of my wife’s) for light use and when I’m on the go.

Oh, and let’s not forget: since last summer, I’ve also been using an 11" iPad Pro M1, which is an absolute gem and deserves a post of its own.

The Mac Studio and Mini are running Sonoma, which I’m not thrilled about, but it’s here to stay. Meanwhile, the Air is still on Monterey. I’ll update it to Sonoma soon to ensure consistency across all my machines.

Needless to say, compared to the Intel models I’ve used up until now, the performance is on another level. The benchmarks already say a lot, but the daily experience speaks volumes more: programs that open instantly, the fluidity of even the most resource-hungry applications, Python or R scripts that used to take minutes now finishing almost before I can blink.

Another clear indication of the speed of these machines is the time it takes to install (as usual) the operating system and all the applications I need from scratch (and there are quite a few).

With the Mini, I completed everything in a single day (around 100 applications to download, register, and configure one by one). I spent a second day on finer details, such as transferring files between Macs, tweaking system settings (a rather complicated process that, thankfully, most users can skip), and installing essential command-line tools like homebrew and conda for my work.

Rosetta installed itself automatically the first time I opened an Intel-only application, and so far, all the apps I’ve installed run without issue – even the more niche ones that require specialized libraries. After all, it’s been over three years since the introduction of the first M1 Macs, and the early challenges should have been resolved long ago.

In short, the transition from Intel to Apple Silicon has been smooth – easier than I initially expected and perhaps even simpler than the previous switch from PowerPC to Intel. And in any case, much easier than crossing a busy street in Rome in the 1960s.

P.S. What about my old Macs? As I’ve mentioned elsewhere, I have a new project in mind to repurpose them effectively. The initial tests look very promising, but I’d rather be sure about certain details before writing about it. Stay tuned!

Sonoma: there is some good around

Mon, 26 Feb 2024 06:00:00 +0000

– Image generated by Microsoft Designer AI.

Sonoma is still raw and comes with a fair number of bugs, but fortunately, there is something good here too.

As far as I’m concerned, I like that Screen Sharing has finally gained its rightful place on the Mac, taking its spot in the Utilities folder within Applications, instead of being relegated to /System/Library/CoreServices/Applications, as it had been until now.

I could be wrong, but I remember a similar application, Apple Remote Desktop, was present in Utilities several years ago (around the time of Tiger or Leopard, maybe among the optional tools you could choose during installation). However, Apple quickly reversed course, hiding the remote access application within macOS system services and accessing it through the Finder menu Go > Connect to Server or via the Locations section of the sidebar.¹

But back to today and Sonoma: the most interesting thing about the new Screen Sharing is that the application now shows a history of all past connections, making it easy to reconnect to frequently used computers and to create consistent groups of connections for the various machines we use.

Having a dedicated application also means being able to configure it according to personal preferences. This was technically possible even with the pre-Sonoma application, but I only realized it while writing these lines.

Why am I so enthusiastic about Screen Sharing? Because I often work over the network, and I find it very interesting to have a native tool that offers more advanced functions than those previously available. It’s just a pity that Apple uses the vnc protocol to connect to remote Macs—a protocol with numerous security issues, often blocked by firewalls, which effectively limits the use of Screen Sharing to local networks only.

A real shame, because after years of partial remote work, I can say that Screen Sharing is much more efficient than Teamviewer (which I stopped using a long time ago) or Chrome Remote Desktop, which I currently use even though it doesn’t completely satisfy me.

These last four years have taught us that remote work is possible, but it requires the right tools. So, after many criticisms, Apple deserves a well-done here.

An advanced version of Apple Remote Desktop is also available on the App Store for €89.99. A price not exactly popular for those who only need it occasionally, but absolutely fair for professionals who rely on it. ↩︎

Apple, we have other problems: a look at macOS vintage bugs

Thu, 22 Feb 2024 06:00:00 +0000

– Image generated by Microsoft Designer AI.

In the last post, I described some very recent bugs present in Sonoma, the latest version of macOS.

The bugs reported here, however, have persisted across several versions of macOS, and it seems that Apple has no intention of fixing them or doesn’t even consider them to be bugs. These issues, unlike other reports, don’t occur under extreme conditions or after opening a zillion files but during completely normal use, which makes it even stranger that they’ve never been resolved.

The first two are more user interface inconsistencies, which are surprising given the almost obsessive attention Apple dedicates to the design details of its products.

The scrollbar for the list of purchased apps in the App Store is partially hidden by the window title and only appears after scrolling through a certain number of apps (the exact number depends on the total apps in the list—if there are many, you’ll have to scroll quite a bit to see the scrollbar).
The same thing happens on the App Store home page when you move the mouse to the top of the window, causing the title to appear. However, since this page contains fewer elements, part of the scrollbar remains visible.

This one, however, is an old bug related to Terminal.

I’ve configured System Settings > Desktop & Dock so that the Prefer tabs when opening documents option is always active. This way, every time I open a new window in applications that support this feature (including Terminal), macOS creates a new tab instead of a new window.

But if I’m using Terminal with a custom configuration (e.g., mine is set to 120 columns x 40 rows) and I select the menu option New Window with a profile of a different size (e.g., the default of 80 columns x 24 rows), a new tab is indeed created, but the entire Terminal changes size to match the profile just chosen.

This might even be a deliberate design choice. However, it contrasts with what happens when the Prefer tabs when opening documents option is only active in full-screen mode, where the new tab adopts the size of the existing one.

To be fair, it was worse in High Sierra: every time a new tab was opened, Terminal would lose a row. Fortunately, this bug was fixed in the next version of macOS.

For me, who always uses the Align to Grid option in Finder windows, organizes file icons visually in a logical order (at least for me), and often leaves empty spaces, this next bug is a major nuisance.

Until El Capitan, if I moved icons in a folder below the bottom edge of the window, Finder kept their order intact, leaving a blank space where the icons were originally located. Starting with Sierra, however, the bottom edge of the Finder window became a sort of impenetrable barrier, causing icons dragged below it to “bounce” back to the top of the window, leaving the bottom empty.

To avoid this, you have to drag the icons while holding the CMD (⌘) key, which in theory bypasses the grid alignment, but then you’ll need to manually restore their order afterward.

This final gem, undoubtedly my favorite macOS bug, isn’t just an annoyance, it’s a royal pain in the neck.

Just like with documents, I organize applications visually, grouping them by type and usage frequency, aligning the icons to Finder’s virtual grid.

As a result, I place all pre-installed Apple apps (Pages, Numbers, Keynote, Xcode, iMovie, GarageBand, etc.) at the top of the Applications folder, followed by office tools (Office 365, LibreOffice, PDF managers), communication apps (Teams, Webex, Skype), browsers, and remote access apps. Further down are apps specific to my work—note-taking, code editing, image editing—and at the bottom, utilities for monitoring Mac temperature, managing the clipboard, unzipping files, recording the screen, and occasionally running an antivirus scan (MalwareBytes).¹

This organization allows me to quickly locate the app I need, as I know exactly where it should be even if I don’t remember its name.²

Unfortunately, for several macOS versions now, every time I update the OS, app icons are always reordered alphabetically. Since alphabetical order is the default for the Applications folder, most users don’t notice this. But for those like me, who prefer custom order, it means having to reorganize everything after every update.

Why do I consider this a bug and not a feature? The reason is simple: Finder allows different sorting options for any folder—alphabetically, by date, by size, by type—and also lets you align items to a grid or leave them unordered. So why should the Applications folder behave differently?

Are there technical reasons for this decision? Under normal use, the Applications folder can be customized like any other Finder folder, so why should Finder reset customizations after every OS update, even minor ones?

In my humble opinion, this issue, along with the one mentioned above, is tied to a problem with the pesky .DS_Store files that manage each Finder folder’s configuration. The file format is more secretive than Area 51.

If anyone from Apple’s development team is reading this, could you spare an hour to fix these bugs? It shouldn’t be too difficult—please take a look, a loyal user would be grateful.

The ability to organize apps and documents visually is one of macOS’s features that makes me prefer it over Linux or—horror!—Windows, where this workflow simply doesn’t exist. ↩︎
On the Mac I’m using to write this, I have 148 installed apps, which, for my habits, isn’t even that many. Remembering all their names isn’t for me, so I’ve never used alphabetical sorting or apps like Alfred and the like. ↩︎

Apple, we have a problem: a look at macOS Sonoma bugs

Mon, 12 Feb 2024 06:00:00 +0000

– Image generated by Microsoft Designer AI.

I use my Mac for work, so I’m always reluctant to update macOS too quickly. I usually prefer to wait until the current version matures, and sometimes I skip it entirely, maybe because I’ve read particularly negative reports or because I wasn’t convinced after using it on a friend’s or colleague’s computer (as I did with Sierra, Catalina, and Ventura).¹

Until now, all the Macs under my control—both the ones I personally use and those in my family—were running Monterey. I like it because it’s stable, fast, and compatible with all the applications I use daily (and there are quite a few).

However, with my new Mac Studio, I had to make an exception because it came with Sonoma pre-installed and is likely not compatible with Monterey. It might work with Ventura, but Ventura is one of the versions on my blacklist, so what’s the point in using it?

Introduction

Sonoma irked me from the day I read that it would no longer natively allow conversion of PostScript or EPS (Encapsulated PostScript) files to PDF. I know that few people use PostScript today, and I can still use Ghostscript or an emulator to convert my old EPS files instead of relying on Preview. But it’s almost a philosophical matter: macOS is a very complex operating system made up of thousands upon thousands of interconnected components. Was there really no more room to maintain support for PostScript/EPS files? ²

As soon as I started using Sonoma on the Mac Studio, I realized my initial skepticism was well-founded. Sonoma is plagued by quite a few baffling bugs that fail to do justice to the potential of the Mac Studio.

Sonoma Bugs

Most of the Sonoma bugs I’ve noticed occur in the Finder and Spaces. The Finder is widely used by all macOS users, while Spaces is less popular among everyday users but presumably favored by the operating system’s developers. Some of these bugs are so obvious that I find it strange they weren’t fixed during the beta testing phase or in the updates released over the past months. In any case, all these bugs are present in Sonoma 14.3, the version currently installed on my Mac Studio.

The following list is roughly ordered by (personal) importance, starting with the more minor bugs—small annoyances that don’t greatly impact the macOS Sonoma experience—and ending with the truly critical and unjustifiable ones.

Right after installing Sonoma, when browsing the network from another Mac, the Mac Studio icon appears as a question mark, while icons for other pre-Sonoma Macs appear normal. After a few hours, the Mac Studio icon returns to normal.
Occasionally, the confirmation message for emptying the Trash appears in a Space different from the one where the command was executed. This also happens in Monterey, but in that version, the Finder automatically switches to the Space with the message, allowing the user to click the confirmation button. In Sonoma, this doesn’t happen, and since the message isn’t visible, users keep trying to empty the Trash unsuccessfully.
When using the Print function to generate a PDF of a document or a webpage, the PDF file no longer automatically inherits the name of the source document and is instead named Untitled. This never happened before and is incredibly annoying. Is it possible that macOS developers never generate PDF files?

I suspect the bug is related to the removal of PostScript support, but I’m not entirely sure.
In a Finder window set to Align to Grid mode, if we drag a group of files below the window’s bottom edge while holding the CMD (⌘) key and then release the mouse, the lower icons disappear from view, giving the impression that the files are lost.³

To make them reappear, you must switch the view mode (e.g., use CMD (⌘)-2 to switch to list view and then return to icon view with CMD (⌘)-1). Alternatively, you can navigate up one folder level and then back, or simply close the current window and reopen it, selecting the same folder again.

The images below illustrate what happens. The first image shows a Finder folder containing a collection of documents and other folders.

Here, I selected some files and dragged them downward while holding the CMD (⌘) key (if I didn’t, the lower files would move to the top of the window once they passed the bottom edge). This action should expand the Finder’s virtual window, causing a scroll bar to appear. However, in Sonoma, this doesn’t happen, and it seems as if the files have disappeared.⁴

Switching to list view and back to icon view finally displays the scroll bar, revealing the files below the bottom edge.
Closely related to the previous bug: if I open a Finder folder in Align to Grid mode and add a new file, it sometimes isn’t visible until I perform one of the actions mentioned above. The same issue occurs when creating or copying a new folder. To make matters worse, this bug happens randomly—sometimes everything works fine, sometimes it doesn’t—causing even more confusion for users dealing with Sonoma’s Finder.
Suppose you have two overlapping windows in a Space, let’s say Space 1. If you click on the top window’s title bar, hold down the mouse button, and use the CTRL (⌃) + 2 and CTRL + 1 shortcuts to move to Space 2 and back, the traveling window always ends up below the stationary one when you return to the original Space.

If there are three or more partially overlapping windows, the window that moves between Spaces always ends up below the window that had focus before the traveling window but above all other Finder windows.

This behavior only affects Finder windows: if you overlap a Finder window with, say, a Safari window, the Finder window that moves between Spaces will reappear in the original Space always on top of Safari, as it should.
Those who watched the videos above may have noticed another very serious problem: every time any window is dragged between Spaces, there is a noticeable flickering of the window’s background. This may be related to the code responsible for redrawing the window.

This happens on the powerful Mac Studio as well as on less capable Macs (thanks, Mimmo!). It has never, ever happened in any previous macOS version.⁵

The strange thing is that this is a very common operation for regular Spaces users. It’s baffling that the developers didn’t notice it or, if they did, didn’t address it before releasing the operating system. Seriously, with today’s ultra-powerful computers, must we really wait half a second to redraw a window?

Conclusions

These are the Sonoma bugs I’ve personally noticed so far. The list is certainly not exhaustive but reflects my particular way of using macOS, including constant use of Spaces (which I find much more convenient than a multi-monitor setup), frequent drag-and-drop operations in the Finder, and reliance on keyboard shortcuts.

As we’ve just seen, Sonoma introduced several bugs of varying severity. However, macOS also suffers from many vintage bugs—issues that have existed for years and that Apple either refuses to fix or doesn’t consider problematic. But you’ll read about those in the next post.

I’m not as critical as Riccardo Mori regarding the more recent macOS versions, but I admit that what he writes strikes a nerve. ↩︎
At this point, I could launch into a long rant about how our digital documents risk becoming unreadable in just a few years unless we’ve printed hard copies, but I’ll spare you that since it’s not the main topic of this post. ↩︎
What’s the purpose of such an operation? For example, to make space for new files that, for some reason, you want to place before the existing ones while maintaining the order of the already-present icons, or to manually rearrange files. ↩︎
Needless to say, in System Settings, I’ve chosen to keep the scroll bars always visible. ↩︎
I can’t speak for Ventura, which I’ve never tested thoroughly, but this certainly never happened in Monterey and earlier versions of macOS. ↩︎

Mac Studio!

Sun, 04 Feb 2024 06:00:00 +0000

And here it is, the Mac Studio. I had to go through a long bureaucratic process to get it, but I finally managed, and now it’s right here in front of me.

The first thing you notice is that the box is heavy, very heavy. The specs state that the Mac Studio is large and weighs about as much as three Mac Minis stacked on top of each other (19.7 x 19.7 x 9.5 cm^3 and 3.6 kg for the Mac Studio versus 19.7 x 19.7 x 3.6 cm^3 and 1.2 kg for the Mac Mini). I’ve never held three Mac Minis together, but the box gives a strong impression of solidity, which is definitely a positive for such an expensive device.

The Mac Studio is indeed not cheap. The configuration I chose is almost top-of-the-line — M2 Ultra processor with a 24-core CPU, 60-core GPU, and 32-core Neural Engine, 128 GB of RAM, and a 1 TB SSD. The total cost was just under €7,000 — the price of two Vision Pros.

But quality comes at a price, and for an equivalent workstation from HP, Dell, or Lenovo, you’d have to shell out €1,000 to €4,000 more.¹ In this case, Apple is even competitive.

Unboxing

I’m not a fan of unboxing rituals, but the Mac Studio deserves this initiation ceremony. The box is a tall, sturdy cardboard parallelepiped, more developed in height than width.

Opening the box is incredibly easy: just pull the tab and fold one side of the box open, reminiscent of the opening mechanism of the Mac Pro G4.

Seeing the Mac Studio lying on its side is a bit unsettling — it looks like it could fall at any moment. But the side flaps are much sturdier than they appear, and the Mac Studio is far too large to slip out of their grip.

At this point, you need to lay the box on its side, spread the flaps in the direction of the arrows, remove the protective paper wrapping, and finally hold the Mac Studio in your hands.²

It really does look like a Mac Mini stretched in height, and now it seems appropriately weighted for its size. The additional weight is entirely due to the box, which is clearly designed to provide the best protection for the valuable item inside.

Even the power cable is a piece of engineering — thick yet flexible, with a fabric sheath that reminds me of those on old irons. This one, however, has a much tighter weave and is unquestionably more elegant. Too bad about the plug — I would have preferred a Schuko, but so be it.

Connecting the power cable and the USB-C cable for the monitor is a breeze. Even pairing my wireless keyboard and mouse (Logitech, both excellent) was simple: I just removed the USB dongle from my usual Mac and plugged it into one of the Mac Studio’s ports — no need to configure anything or fuss with Bluetooth.

Finding the power button was a bit trickier. It’s on the bottom-left corner, perfectly flush with the body of the device, and practically imperceptible to touch. But once pressed, badaboom! In a few seconds, the macOS welcome screen appears. A quick system configuration (since I’ll be reinstalling anyway), and the Sonoma desktop appears.

Reinstalling macOS

Call me obsessive, but I always reinstall macOS from scratch on any new Mac I get my hands on. Maybe it’s a habit from the past, a fixation, or just a desire for control, but I’ve never used a Mac without personally installing macOS.

On Apple Silicon Macs, you need to hold down the power button until the Options icon (a gear symbol) appears, usually alongside one or more icons representing the Mac’s disks. Clicking on Options and confirming loads the macOS Recovery utility.

Once Recovery loads, I first initialize the system disk with Disk Utility, giving it a more meaningful name than the default Macintosh HD (usually the same name I use on the network for easy identification). Then, I reinstall macOS using the straightforward guided procedure.

As always, the estimated installation time is wildly inaccurate: the three-plus hours initially shown turn out to be just about 40 minutes — not short, but not excessive for installing a complex OS like macOS.

It’s also curious that after the mandatory reboot, the screen resolution drops significantly, only to return to normal once the macOS welcome screen appears. I’ve never seen this happen with other macOS versions, but it’s worth noting that most of my (re)installations are done on MacBooks, which have more consistent hardware than desktop systems.

After carefully completing the initial macOS setup, I was back on the Sonoma desktop within minutes. Now, I could finally start experiencing how the Mac Studio performs.

How Does the Mac Studio Perform?

The Mac Studio runs beautifully (but was there any doubt?). Everything is smooth, without the slightest hiccup. While this is true for all Apple Silicon Macs, it’s immediately clear that the Studio is a cut above — perhaps even two.

Application installation is instantaneous: double-click the .dmg, drag the icon to the Applications folder, and… done. Even with larger apps like GNU Emacs, GIMP, or Miniconda, the wait is just two or three seconds.

The only app that put up some resistance was QGIS, whose installation took two and a half minutes on the Mac Studio. But that’s understandable for a 3 GB behemoth containing thousands of small files that need to be copied one by one.

I didn’t bother with Geekbench or similar benchmarks to measure the Mac Studio’s performance. The web is already flooded with such data, and my results would only be redundant. Instead, I’m more interested in how the Mac Studio handles demanding applications — I have some early impressions but will wait to share more.

Sonoma, however, is a drag. It’s clear from the start that this operating system is still full of bugs and inconsistencies (which I’ll showcase in the next post), and it doesn’t do justice to what the Mac Studio can really achieve.

Apple has accustomed us to a tick-tock approach for its operating systems (similar to the one Intel followed for years with its processors): one year, they release an innovative but buggy and slow OS, followed by a version focusing almost exclusively on bug fixes and optimizations. This happened with Leopard and Snow Leopard, then with Lion and Mountain Lion. Later, the pattern continued with El Capitan, practically perfect after the horrendous Mavericks and Yosemite, and Mojave, following two mediocre releases like Sierra and High Sierra. Most recently, Monterey was excellent after the disaster of Catalina. Sonoma, theoretically the bug-fix version of Ventura, is a disappointment. Hopefully, Apple will fix things at the next WWDC in June — and big time.

Conclusion

I did all the unboxing and setup of the Mac Studio at home, so I could work in peace away from the usual chaos at the institute. But after a week, the Mac Studio moved to my office, taking pride of place on my desk amid monitors, keyboards, mice, cables, and various gadgets.

And my old High Sierra computer? That’s destined for a new project, and I’m really curious to see what comes of it. Stay tuned!

It’s worth noting that the aforementioned workstations are, at least theoretically, more expandable than the Mac Studio. However, expandability isn’t a critical factor for my specific needs. ↩︎
There’s not a single piece of plastic in the box. It may not be much from an environmental perspective, but it shows that it can be done. ↩︎

Macos on Melabit

macOS Tahoe: let's free the icons!

The squircle jail

Let’s Free the Icons

IconLib

Conclusions

macOS Tahoe, again

Goodbye dc, welcome luka: a new RPN calculator for the Terminal

A bit of history

Reverse Polish Notation

A calculator in the Terminal

The 21st-century RPN calculator

Evolution of the code

Using luka

Conclusions

macOS Tahoe: Developer Beta 3

It’s a beta

The Wallpaper

The Menu Bar

System Settings

The Finder

Application Icons

Performance

Conclusions

macOS Tahoe: where is my Terminal?

macOS Tahoe: see you in September

Update

Desktop and widgets

Finder

The new Apps

System Settings

Conclusions (for now)

WWDC 25

From melabit to melabit: hosting Jekyll

Introduction

Why using a Mac isn’t a good idea

Why doing it yourself isn’t worth it

What is worth doing yourself

What I have done

Let’s do the math

From melabit to melabit: managing comments with Jekyll

Looking for the ideal commenting system

Working on Comma

Putting all together

Conclusions

From melabit to melabit: developing a web site in Jekyll

What do we want?

How a theme is structured

Testing Jekyll again

When the default theme is not enough

Let’s get to work!

Pagination

Multilingual support

Thumbnails and comments

From melabit to melabit: Jekyll, installation and basic configuration

Installing Jekyll

Your first Jekyll site

Jekyll and its themes

If you no longer like Jekyll

Until next time

Apple, we fixed some issues: from Sonoma to Sequoia

Frozen Mac? How to recover it using DFU mode

Apple, we have a problem: a new macOS Sonoma bug

Apple, we have a problem: a look at macOS Sonoma bugs (update)

From Intel to Apple Silicon

Sonoma: there is some good around

Apple, we have other problems: a look at macOS vintage bugs

Apple, we have a problem: a look at macOS Sonoma bugs

Introduction

Sonoma Bugs

Conclusions

Mac Studio!

Unboxing

Reinstalling macOS

How Does the Mac Studio Perform?

Conclusion