frankie-tales

Is the future federated? Or, why the hyperscaler are here to stay

2026-08-07T19:00:00Z

Sovereignty in the EU is now the trend, at least as a conceptual idea. Someone finally discovered that most of the Western world is dependent on a few US big companies, and the current status of Geopolitics is quite confusing, causing stomachaches and concerns among multiple governments.

Under these conditions, it is a good idea to understand the status of the mainstream internet services, including the so-called cloud and social networks. As explained in a past post, for some of these services, the EU situation is not so bad. We have many good companies that offer hosting and cloud services at a good level, and we have all the skills in-house. Therefore, at least for basic services, including distributed storage, email systems, and computing resources, we are in a position to be independent within a reasonable time frame. Of course, the number and extent of our data centers are not comparable, but if we do not have ambitions of offering such services worldwide, they can be enough for European use.

About social networks and instant messaging systems, among others, the situation is more concerning. While some alternatives exist, in many cases the network effect and first-mover advantage are strong and heavily weigh against building any real alternative. The tragic reality is that a pure distributed network of peers, which has been the core of the Internet since its birth, has been disrupted by the imposition of concentrated, single-company, non-standardized services. Think of WhatsApp, Facebook, LinkedIn, X/Twitter, Instagram, YouTube, or even the so-called alternative like Telegram or Bluesky. Most of the concrete alternatives are simply regional or restricted, simply a different incarnation of the walled garden concept. Think of TikTok, WeChat, Sina Weibo, and other regional services; they are simply different, isolated networks that do not communicate with others.

Like it or not, the only true alternatives for such systems are the fully federated services, such as Mastodon, Matrix, DeltaChat, or Peertube. There are literally dozens of such independent services based on open protocols, and they fully reflect the original idea of the Internet networking. Problem solved? Unfortunately, no, because the scale of such implementations is far from being comparable. We talk about thousands (about 1,5 million monthly active users in the luckiest case) of users against billions: a full order-of-magnitude difference, which causes evident network-effect problems. Common users are simply not incentivized to participate in such alternative services unless strongly motivated.

But imagine for a moment that all Internet users would like to enter the federated worlds.

In most cases, the typical federated server hosts a few hundred to a few thousand users. For such numbers, very small management teams and even small budgets could be viable and easily covered through crowdfunding. The most populated Mastodon instance (Mastodon.social) counts less than 1 million accounts with less than 300,000 daily active users currently. In a different service context, Codeberg supports less than 400,000 users and 700,000 projects, through 1,700 active members for its association (numbers of 2026). This is perfectly viable for a small-scale service and also the ideal situation with a good tradeoff between quality of service and efforts/size.

In our hypothesis, such servers would probably be subject to an average load multiplied by 1000 times, even in the case of fully working federated mutual help by smaller instances. In order to avoid service collapse, such instances would require an intensive architecture improvement and a significant increase in human effort for management. In other words, big money and the spreading of efforts among many individuals and organizations. Finding a tradeoff to avoid a new concentration and consolidation of services in the hands of very few actors would be the next challenge.

Again and again, my consideration is always the same: it is not only a matter of open protocols, mutual peers, and technicalities; it is a matter of governance and sustainability. The crude reality is that concentration among a very few active parties (just another oligarchy of service providers) could be unavoidable as the number of participants scales up. Of course, the only possibility of avoiding such evil concentrations is to ensure sufficient fragmentation by conception, for example, by imposing a maximum number of users per instance, or by maintaining small worlds of strictly thematic/regional instances.

So, federated services could be the answer for the future, but only by ensuring enough diversification of equal-weight instances, which could not scale at the same rate as the number of active users. Small is nice and safe, and this is the natural scale of federated servers to retain. In the opposite case, that would only become the next large walled garden, with serious sustainability problems and the constant temptation of having a new king of the realm. The obvious implication is that the mainstream bigco services will not be threatened by such alternatives, even considering that a lot of people are simply not aware/interested enough in privacy and digital rights. I think the only true limitation to well-known hypertrophic services can and should be found in international and national regulations, implemented with a grain of salt to avoid excessive problems and management load for federated services. Such a grain of salt and reasonability could be the key for the future, or, in the opposite case, establish the end of the Internet dream, which is already threatened by hyperscalers.

To understand the matter, think of Gmail, which is probably the most common email service worldwide. The most credible estimate is that almost 40% of email traffic is managed there, making the whole email thing a fully federated service with a few dominant providers. Most users do not search for alternatives, and many may have multiple alternatives and Gmail in use for different purposes. Even in these conditions, email is an example of a successful federated service. I would be happy if social networks moved in such a direction, frankly.

A completely different matter is the AI drama, where I see most of the risk for the future, for both Europe and most of the free world. Incredibly enough, the only current concrete alternative to the hypertrophy of less than a handful of US giants is represented by the open-weights, Chinese models. They could also be used at a reasonable scale locally, even if not for personal use. Unfortunately, the finest models are also extremely demanding for computing resources (both in terms of memory, storage, and GPUs) and out of reach for individual use. They can be considered for business investments, but it is already evident that a lot of effort is required to create an effective harness, where most of the value is currently present. The whole framework of agentic software and the capability of aligning models to goals will be the challenge of the future, but that will be out of reach for most users (including most companies), who the limits of general providers (OpenAI, Anthropic, Google, or anyone else) will constrain.

More and more, I see personal computing in the AI context will consist of running software on someone else's cluster, with all obvious implications for privacy and security for the average user. We will live sad times about that, with personal computing becoming managed computing, and users reduced to customers. Of course, the biggest problem is the awareness of users in such conditions, which appears more and more complicated due to the absence of a fully independent alphabetization policy in this new(?) digital world.

But maybe this is matter for another post...

The problem is not only if, but how.

2026-06-01T13:30:00Z

Ok, such dramas and the whole topic are starting to be annoying. The last episode was the rsync project with the well-respected Andrew Tridgell as maintainer, who initiated a Claude-based development effort for the 3.4 series a few months ago. The rsync tool is a well-known, widely used tool for copying files between hosts in a smart way, includes a daemon to optimize file transfers, and serves as an entry point for synchronization.

Only at the end of May, when some regressions began to appear, this step by the tool's main developer triggered the opening of a rather harsh issue regarding the use of AI agents in development. One of the most consistent changes in the source tree has been the introduction of Python helpers to replace the tool's test coverage. This is not a new type of controversy; it appears as a quite common pattern. AI tooling for programming (or automatic programming, as Antirez calls it) based on specifications and natural language appears to be quite widespread nowadays.

It is no novelty that such applications provoke a divisive reaction, with fans and detractors of a tool that, at first glance, appears almost magical for creating new programs from scratch in any language, or for reviewing existing code, or for evolving any existing project through extended, progressive pull requests. This is particularly annoying for many contributors when the AI agent is blindly used as a committer or to create PRs or issues. The whole controversy comes into dramatic focus when the project is a prime-time one, as in the case of rsync.

Note that rsync has been with evidence in quite low-intensity maintenance in recent years, with several hundred issues open and almost 50 PRs proposed but still pending. This is quite normal for seasoned FOSS projects, like it or not, and specifically for low-voltage tools that have most of their life-cycle in the past. Rsync is a tiny utility based on less than 150,000 lines of C code, started about 30 years ago by Tridge. In 2024, he stepped up again as a maintainer, likely due to the project's overall status (merely not abandonware, but almost such). This is, unfortunately, the known problem of too many FOSS projects to count: they are old, seasoned programs developed years ago and substantially frozen, but for minimal maintenance. They are often written in legacy languages, such as pure C, which are quite far from the interests of average Gen Z developers. Development teams are minimally set up, even under a foundation umbrella, and interest in advancing them concretely is equally minimal. They are what I call ‘good enough’ projects, often of widespread use. They could be so legacy that they are considered carved in stone.

Of course, in 2026, the temptation to revitalize such legacy programs with AI tooling is extremely high. It is higher when developers are overwhelmed with many other tasks, and you know, maintaining such a project can be extremely boring. But when the tool in question is considered a brick of the whole FOSS basement and used as such by tons of reverse-dependent projects, the whole operation can be extremely prone to controversy and intolerance. There are not only problems of quality assurance for the final result, but also ethical and philosophical questions about the use of AI tooling. All such aspects cannot be ignored, and some kind of caution is required.

To introduce AI tooling into such a project, the first step is to reach an agreement among all parties involved. That would lead to an accepted, explicitly stated AI policy (which apparently lacked in the case of rsync). The most accepted approach currently is a rigorous human-in-the-loop development policy (as accepted in the Linux kernel, for instance). Without them, any forced use of AI tooling for community-based FOSS projects is doomed to failure and controversy, which could ultimately lead to a fork and the dispersion of effort and energy. This consideration implies that the project has already adopted some form of governance. Once the IF phase is passed, the HOW step must be consequent. It is totally unacceptable that a human-in-the-loop becomes a purely formal step before committing. In other words, the project committers need to strictly review and commit to avoid regressions and subtle bugs, which could easily be present with or without the AI contribution, but for sure are a risk when one touches legacy code. The human committer is responsible. Being proactive is a duty and cannot be neglected. Better to do nothing than mess up working code. I don’t know if this has been the Tridge’s case, but regressions have happened, which isn’t a good signal, and the whole thing could lead to unexpected upset.

But, but, but... Wasn't the AI tool the magic silver bullet to solve all software issues and productivity? Well, dudes, I’m afraid that you need to change your mind. There’s no silver bullet, even 30 years later. There’s no magic recipe to solve all problems with undersized projects, and someone has to pay the debt.

We still need engineers who do their job, damn it.

The Web is dying, long live the World Wide Web.

2026-05-27T13:30:00Z

I already dealt with the status of the WWW in the recent past. See, specifically, the authoritative opinion of Sir Tim Berners-Lee on that. Multiple dynamics have upset the initial idea of a distributed, democratic, and influential worldwide system, as conceived in the 90s, including the roles of BigCorps, socials, and geopolitics. What appears to be the last brick in the grave of the WWW is the current AI wave, which introduces two distinct elements of breaking an already compromised equilibrium.

It is now evident that a large part of the WWW content is AI-generated [3,4], often with very low quality and care. Let me point out, for instance, articles in the well-known Medium.com magazine (but that’s not specifically a problem of it, it is a general one): it is not a novelty that quite a lot of authors there are intensively writing most of their content via AI, with just minor human contributions. This is not new: in the past, the figure of the ghostwriter (who wrote slop contents by weight) was quite widespread and even present in prime-time magazines, but now AI tooling has exacerbated this approach. This is what is generally considered the enshittification of the web, and it started even before the AI hype, with content generated by extensive copy-and-paste and the addition of announcements, clickbait titles, sponsored articles, etc.

At the same time, the web search systems are also undergoing significant changes. Google introduced AI overviews, but people also changed their approach to searching for information, and that was not dependent on Google's or any other search engine's suggested overview. The possibility of having a structured summary of any argument, instead of a long list of well (or not so well) centered references, changed many people's views of the whole information search topic. Unfortunately, this also deeply impacts the overall sense of sponsoring a search engine or maintaining a site of content about any topic. For instance, why maintain a whole site about tourism in Berlin if the same information can be obtained in a short form via AI independently, and no one will visit such a site? And above all, how will content creators continue to monetize effectively in such conditions [1]?

If, as seems likely after Google I/O 2026, the next search engines will be simply AI overviews, mainly with sponsored results (typically by secretely steering AI summaries), what about independent and non-profit content? To be clear, already most traffic (I mean >90%) on small websites is bot-generated. Of course, that includes AI bots and general crawlers. The duration of such visits is typically under a few seconds. Of course, such a status is not a big problem for non-profit sites, but it can cause some frustration. That was true also before the autumn of 2022, indeed. What will be the final result of such a process is quite evident to me: the enshittificated, mechanical production of web content will go away because it will become only noise on the net, without any real revenues (or value); as it has started, it will surely go mostly to a dead end. Of course, until it can still capture a fraction of users' attention, it will stay here, but in my opinion, it will only be a matter of time before such low-profile content ends. What will remain is probably paywalled or institutional pages (only those with a decent value per se), non-profit/community websites, and AI-protected sites (with a continuous risk of abuse by new generations of autobots). Free access with announcements will become a thing of the past, as the number of active human readers declines. Mass production and poetry, to summarize.

Surely, easy monetization and SEO will soon be a keepsake. It has also been visible for ages in alternative media (such as video-based content), which is currently much less accessible to AI generation solutions. Even in such a domain, content creation has become more selective, and valuable assets are quite distinct from a more general, low-quality production. My idea is that, in the long run, most content creation (in any format, text, audio, or video) will follow a bimodal distribution (with low and high quality peaks) around its general quality, and the best quality will generally require some form of subscription, because of the involved efforts for production. Indeed, I would expect some concentration among a relatively few actors for any topics. Quality is neither spread nor democratic. One will need to exit the mass of low-quality profiles, which are and will be the majority of what is available out there on the web.

That’s already visible in the traditional mainstream media: most of their web-based content is pure garbage, and that was true even a few years ago; now it's paroxysmal. I found years ago that most of the so-called news on mobile devices was largely disseminated through announcements, dialogs, and sponsored content, making it completely unusable and unfocused, for me. Nevertheless, the mobile-first approach has already been the dominant UX for the average user for ages. Even the AI-generated content could largely become targeted to AI bots instead of humans, with unclear implications about readability and form. But the average user gets used to the most incomprehensible things, so who knows?

Therefore, the concrete perspective (or the crude reality) is a web full of AI-generated content or walled gardens, with few non-profit corners that publish mainly for fun, along with a few authoritative sources (such as Wikipedia [2], a knowledge source that will need to be defended and encouraged as well), which are becoming increasingly difficult to discover in the old way by humans.

We all become like modern Diogenes walking with a lantern on the net, during the daylight, looking for the true web value with mixed luck...

A giant step backward at a time when there were manually maintained indexes of interesting sites organized by topics. Damn it, sounds familiar. Not so bad, wasn’t it? That’s the core of the Fediverse, basically: some micro-universes oriented to small communities of focused users, all navigating in a global ocean of mere s*t.

References

The only good AI is a dead one: myth and reality of AI tooling for code

2026-05-05T13:00:00Z

Some months ago, I participated in this Mastodon poll. My thesis was that, in general, there is no presumptive quality flag that can be added to a product, whether it was created with AI-aided tools or not. My opinion sparked a small, heated controversy among some readers.

Labeling a product as AI-generated and expecting low-quality results is simplistic and prejudiced. One expects that the resulting product is accepted without review or handcrafted changes, after multiple adjustments to the LLM prompt through an iterative process. This is clearly false in general for coding (vibe coding, per se, is not a black-and-white picture; it is full of shades of grey), but it can also be applied to other creations.

Even the use of AI tooling has hundreds of nuances, especially in many articulated processes of creative production across multiple fields. AI tools or not, the human contribution is still central in the process. One can abdicate to such a role, or be fully responsible for the final result, with accurate changes and handcrafted work based on a rough draft generated by AI. The presumption of labeling AI helper use as a signal of low-quality production negates the importance of the human-in-the-loop. The point is that quality should be considered an objective aspect of any product, with or without human authoring: having a handcrafted product is not necessarily a symptom of quality per se, and the same goes for the opposite if the product used AI tooling at any phase of its creation. At least for programming, we had spaghetti code for ages, well before AI agents.

If you take a walk around GitHub and look at too many projects to enumerate, even without any AI intervention, you will find a lot of half-finished, incomplete, alpha-quality, obsolete, or partially working code that would need a good number of deep refactorings to be considered for production use. That’s not a problem with AI use; it’s simply due to the not-too-recent shift in FOSS coding as the mainstream approach to writing programs. Opening a GitHub portfolio assumed almost the same importance as opening a LinkedIn profile for techies. In many cases, such proof-of-concept products have been sitting on a developer’s shelf for years. Today, they populate their GitHub (or any other hub) repos, instead.

On the opposite side, one could read a recent Antirez’s post, which shows how much a meticulous human-in-the-loop approach for automatic programming can be productive and reasonable. Not secondary; such an approach should be currently considered essential to fully admit a copyrightable contribution to existing or new code, as explained in Simone Aliprandi’s recent book.

In conclusion, pretending that AI tooling produces only slop is clearly prejudicial, not different from past anti-FOSS prejudice that unpaid work done in free time cannot be of good quality. Does it sound familiar? Sure, there are a lot of low-quality projects out there, but again, that’s not necessarily the case, and there are also many very good FOSS projects, created and maintained with great care. Again, a license type and development workflow are not enough metrics to judge software quality, nor is the use of AI sufficient for the same purpose. And that’s true for coding as for other creative works. That’s not that simplistic, dudes.

Guess what? 97% of 3,456 respondents in the Mastodon poll answered that an AI mark on a product is a good idea for a presumptively low-quality design. I’m quite sure most of them are also AI users in some form, of course, and that says a lot about the future of this AI era and human ingenuity.

Is AI driven coding the start of the end of mainstream FOSS?

2026-02-04T20:00:00Z

Someone on Mastodon (I’m sorry, but I don’t remember who exactly) published a short post that pointed to a rather technical economic study of the impact of AI on FOSS software development [1]. It is no secret that the AI debate is highly polarized, and the enthusiasts for the current trend in AI applications in the IT domain are at least as numerous as those who are concerned/skeptical. What is certain is that no one can, in the long term, prospectively evaluate the impact of AI on society, particularly in the IT world.

The main thesis of the paper is that AI-based code production will end the mainstreaming of FOSS software, as we have learnt over the last 15-20 years. The paper begins with well-known episodes from recent history (specifically, the Tailwind saga [2] and Stack Overflow's near-death experience [3]).

Of course, the paper presents a theoretical economic model to evaluate a possible impact scenario for the FOSS production model, which could or could not come to fruition, depending on the assumptions made.

My honest opinion is that a conscious and accurate use of AI can accelerate development. That is, in a bad and good sense, I mean directly on the basis of the experience and skills of people who use such models. Therefore, we are both seeing slop and high-profile creations with the aid of AI. Maybe slop contributions are more prevalent simply because mediocre developers are the majority, and mediocrity is the backbone of enterprise production (because it is the most replicable and independent of contributors and their capacities).

Like it or not, modern software industries do not need, and fight against, too much creative approaches. Enterprises need aurea mediocritas, not isolated geniuses. Also, depending on third-party creations, it apparently reduces the enterprise's technical debt because it is typically shifted onto someone else's shoulders. Of course, this is an approach that works until it fails miserably when such a third party disappears, changes its license model, changes its mind about the product, changes its APIs, and so on.

That said, one clear consequence of using AI helpers in coding appears to be the progressive disappearance of many packages, modules, and libraries, which can be easily replaced by AI-generated creations tailored to the task. Just to cite one practical example, Tailwind nowadays could be easily replaced by CSS and simple JavaScript components, with the obvious advantage of not depending on yet another third-party-controlled piece of code that could be subject to abrupt changes from one version to another without notice and break existing codebases. At the same time, Tailwind themes can be generated by AI without even consulting its documentation (which apparently had an immediate impact on the company's revenues).

Another advantage is that AI-based, tailored solutions would reduce the amount of code from external dependencies that solve problems for others, instead of focusing on the minimal set of features for your own needs (with all the implications of possible breakages arising from such an anti-minimalistic pattern).

Of course, using AI helpers in this way does not reduce the effort required to understand and create new software, but it probably raises the required competence to a higher level, which could be better in the long term, while encouraging quick-and-dirty approaches in the near term. The so-called vibe coding is not a black-and-white concept; it has a lot of grey tones directly depending on the awareness, responsibility, and skills of the developer: as said, it can accelerate in many senses - even to crash against a wall - increasing in an uncontrolled manner the technical debt when in the hands of the wrong individual. Even about that, Anthropic recognizes that AI abuse can negatively impact coding skills and debugging capabilities [6].

Add to this the current very high infrastructure load many networks are reporting, for which the AI bots currently seem to be the culprit [4]. This seems like very strange behavior for such botnets, given that web crawlers have been around since the 90s and should be able to handle infrastructure load fairly well by now. It seems that AI companies simply aren't fair enough on their own, or that the training phases of neural nets are definitely more demanding. Maybe both?

So, what do I see as the future for FOSS development as a whole? I am not a pessimist as in the cited article. For sure, I see fewer small contributions in the long term. Today, there is a massive production of AI-slop-based contributions to many prime-time projects, but I see this as incidental. In recent years, GitHub-based path of honors has been a major self-promotion channel for junior developers, which explains the drift toward low-quality contributions: devs are (were?) strongly motivated to contribute and find in AI slop an easy path to that, by creating personal portfolios. That’s also true for fake security-related reports (see the well-known Curl project case [5] and others). This is, of course, annoying, but in my view, that’s the result of current AI hype and should normalize in the mid-term.

Also, in the near future, I see less and less relevance in FOSS projects that are not sustained by a strong architectural idea, innovation-grade, a large community, and a consistent development effort (much bigger than a few weeks or months of work). That kind of project will become mainly background noise, let me say. Maybe that could impact whole categories of FOSS software: it is not a secret that many language hubs are full of packages/modules of dubious quality, often used because they are available just a use/import directive away. In many cases, such products will simply be replaced by an AI-based reimplementation. If the final result will be better or worse in average quality, only the future will show. For sure, the AIAD will cause a progressive democratization/popularization of the development process, giving average users access to possibilities once unavailable to them: we will probably see the production of a plethora of small tools and workflows built on agents rather than finished, refined products, like it or not.

The result could be an increase in FOSS products at the cost of lower average generality and code quality, with a few high-end, tailored products for mainstream applications instead. But was this really so different in the past? I don’t think so. The true difference is probably the increase in quantity in both sets of products, as potentiated by AI tools: if one does not do her/his homework, the result is clearly garbage, but that was true before AI, too.

“AI gives us the worst and the best - simultaneously.”

(Daniel Stenberg, the Curl Mantainer)

References

How to trust FOSS players and the security implications

2026-01-27T17:30:00Z

More and more, recent (and not too recent) episodes [1-5] nowadays show a hard truth we already discovered in the Debian project since the end of the 90s. A key security principle in FOSS code development is ensuring the trustworthiness of all parties involved, and that’s unfortunately also the weakest part of the whole chain.

Debian adopted a long time ago a tentative GnuPG-based screening of people involved in the project through the so-called Web of Trust. All developers need to participate in eyeball meetings to sign each other's public keys after verifying personal IDs. The more signatures, the more trustworthy. That is generally mandatory before being granted the privilege of uploading to the main archive without review. Of course, trust is not automatic, and each volunteer must demonstrate they have the required skills and good intentions, and embrace the Debian social contract. This is the annoying, often multi-year process to be accepted as a contributor.

This process is far from perfect and may also be subject to abuse, as Martin Krafft demonstrated at a past DebConf, a long time ago. One of the main issues is that maintainers work on upstream software that generally does not undergo such a process to accept contributors. As the well-known sad case of the xz utils demonstrated [6] a couple of years ago, an initial review of pull requests is not generally enough to ensure that the developer or group does not have evil intentions in the mid- to long-term. Also, with the best intentions of sane upstream developers, evil parties can make very creative efforts to hide their malware code. This is magistrally demonstrated in that episode, which did not cause major security issues, only by casualties.

The sad reality is that none of the main programming language hubs is really trustworthy, because literally anyone can register anonymously to upload code and participate in development teams. Core teams at least review pull requests before accepting them to avoid major abuses. To address this, enforcing a worldwide web of trust for all core projects and possibly all software hubs should be considered a mandatory step to improve security and accountability.

It does not resolve all problems, but it helps. A central authority is not the answer, as it could create more problems than it solves. Instead, enhance trustworthiness by encouraging ongoing cross-review by multiple parties. Establish processes that build developers' trust over time through active participation and transparent peer review. While key hijacking remains a risk, this is a separate issue requiring distinct protective measures.

I've written about this related issue before. The shift from distributions to language and upstream hubs shifts software management onto developers and users, increasing the risk of security incidents from malicious contributions.

That said, like it or not, most FOSS products out there are created/maintained by single individuals and micro-development teams with no warranties and questionable durability. I wonder how billion-dollar companies can seriously consider basing their core business in such conditions, a problem directly connected to the broader sustainability challenges for FOSS projects. The progressive spread of the AGPL license and other similar licenses is a symptom of this type of malaise and should be taken into consideration, as they are different aspects of the same problem. Security concerns are another key point that we, as a community, should try to manage better, but my honest thought is that nowadays, predatory big (and not so big, even) companies (as well as public bodies too) that use community-driven FOSS code in an unfair manner, without returning a cent for development and maintenance, are not more acceptable.

Therefore, FOSS communities are not perfect, but many of the culprits are nowadays on the shoulders of companies and public bodies that are still looking out their windows instead of being active stewards and promoting reciprocal collaboration among all involved parties.

Come on, put the money and effort into the sources of your digital profits.

References

The perfect desktop is a matter of points of view, or not?

2026-01-22T19:40:00Z

I recently learned about an opinionated flavor of the Arch distribution called Omarchy, which is basically a collection of desktop packages built on top of a rolling Arch distribution. Nothing special, but for the vocal original author of the scripting job at the base of such flavor, who is, as it happens, for many old-school self-centered geeks out there, the quite discussed DHH. I will not enter into the merits of the reasons for the dubious fame of David "DHH" Heinemeier Hansson, which basically stem from some of his past posts on X/Twitter and some of his questionable ideas.

I’m not interested in that here. I’m more interested in some spontaneous thoughts about the hype (well, at least among the very restricted niche group of Linux desktop fans) around this desktop flavor. It is not something new; the Hyprland UX is basically an i3-like tiling window manager with steroids, based on the current non-Xorg incarnation of Wayland, with a few whistles and bells.

I have been a long-time Linux desktop user since the 90s, and a tiling window manager (specifically one of the suckless incarnations, Awesome WM) has been my main desktop for quite a few years. Some years ago, I abandoned such a paradigm when I finally realized that a pure tiling window manager is a great idea until it isn't. Basically, most of its pros (one application per virtual desktop, easy tiling on big displays, keyboard-driven navigation) can be easily replicated in a capable desktop environment like any current Gnome version. This has the big advantage of being ready for use right after installation and of being easily and fully customizable via plugins. The cons of a tiling WM are always present, based on workflows, and there are generally no easy workarounds. The biggest is the need to find tricks and third-party tools to solve use cases that are not always trivial (or worse, that are trivial on a DE instead).

A DE has the indisputable advantage of including all batteries for widgets and customization tools, whereas most (all) WMs require third-party tooling to manage many disparate configuration snippets, such as Bluetooth, Wi-Fi, hot-plug devices, auto-sensing of beamers, dynamic multi-display, fast binding of container apps, accessibility featues, and many others. Too often, also, such WMs require using a command-line tool or a workaround to perform tasks that are simply part of the common DE experience.

I also remember the pain of using the multiwindow GUI of GrassGis under Awesome, which was at the time just another type of application under a floating window manager, instead. When an application opens a new window for every new module used, well, the UX could become a nightmare under a tiling WM, if you are not using a 43-inch display. The same goes for virtualized desktops, too: when the guest and host collide for keyboard use, continuous control switching can rapidly lead to madness. That’s just a pair of examples to conclude that the coolness of a desktop implementation is often a matter of perspective and personal workflows, and I constantly found that a mandatory tiling WM paradigm is simply less flexible in some practical cases.

To be honest, I find the Omarchy UX to be the typical incarnation of a canonical WM-based interface for fresh Linux desktop users. Such users are divided into two classes:

The class of people who are searching for an exact replica of Windows/macOS GUI. A no-hope group of people: if something has to look like Windows, have exactly the same policies and the same applications and icons, even, well, probably they should stay with Windows: simple and clean. They are the most critical and vocal complaining users for whom the Linux-on-the-desktop era will never come.
The class of people who look for something radically different and discover the keyboard-driven interfaces as something almost magical (without fully realizing that such an experience can be replicated easily and mostly by using environment shortcuts and some simple plugins). A trivial secret, I would say. They are the most enthusiastic about this kind of desktop, but also regular distro-hoppers (yes, it is an offense for me: distro-hopping is for gamers, not for workers who need to complete primary tasks daily) from time to time; more often, they will never admit they are simply playing around, and solving auto-inflicted problems is part of their game.

Of course, the WM-based desktop paradigm still has its own use cases, which I group under a very few limited cases:

You are using a strictly roll-on distribution, such as Debian sid/unstable, Arch, Guix, Gentoo, and many other in-development flavors of other mainstream distributions, including Fedora and OpenSUSE. On such distributions, avoiding desktop environments reduces the likelihood of encountering temporary problems after daily upgrades, as some transient (in the order of days/weeks) breakages can occur. But who is the user of such platforms today? Seriously, I think only someone actively involved in development and testing should be interested in such distributions. Today, most desktop apps are distributed as containerized packages via one of the multiple available hubs for Flatpak, AppImage, Snap, Docker/Podman. I can’t see the practical advantage of using an unstable distribution on a daily basis. If you think differently, dude, you have a problem, and it is not the distribution you are using, but it is what you see in the mirror. If you are not a YouTuber who needs to produce videos to monetize, well, you are probably simply using the wrong distribution pointlessly (and creating your own problems from time to time, which are perfectly part of the roll-on experience, by manual).
You are using an old, low-resource box with limited RAM and cores. A platform that cannot simply be used with the current desktop environments. I seriously doubt it could also be used for general computing, indeed. Nowadays, even a web browser is simply a hungry hog on such platforms. I mean, a dual-core box with 4 GB of RAM that could be more than 15 years old. If this is your platform, well, a window manager is perfectly legitimate, but it probably couldn't be used with Hyprland either. But to do what? I mean, but for installing it and telling it to friends...
You are an old-style lazy geek, anchored to your own configurations, refined over dozens of years, with very few reasons to change. That’s perfectly legitimate, but most of those configurations could probably be out of date. I know, you are still adjusting your Modelines in your Xorg configuration. Well, dude, probably it’s time to come down the tree in the forest.

Of course, I also tried to install Omarchy on an old box of mine (an 11-year-old Lenovo ThinkPad L540 with a dual-core i5 and 8GB RAM) that runs perfectly with the current Debian 13 and Gnome 48. Sadly, it was not even booted to install: just a dark screen. Good, but not too good, dudes.

And this leads me to the elephant-in-the-room argument for this post. Most users need stability and, occasionally, up-to-date applications. The average users need certainty that they can easily install an OS on most platforms and have a stable UX for a decently long period (let’s say 2-5 years without any reinstallation in between). The more users, the more stability. The simpler, the more effective, too. And that’s the real point most devs (or wannabe experts) have probably missed in the meantime. The desktop is a mere tool; it should not require an expertise addiction.

It is not a matter of DE vs WM, but of homogeneity and generality versus good, but not enough for all. If one has to rediscover the warm water to manage a configurable tool that, in a DE, is a click-n-point away, it is a failure in general UX. Of course, even DEs are far from perfect, but too often, WM UX is far from even being basically complete.

For instance, I can easily manage my full clipboard history with inter-session persistence thanks to a simple Gnome plugin (i.e., Clipboard Indicator). There is no equivalent widget in most WMs, but they need to use a third-party tool to provide something that is almost equivalent, but often incomplete. Well, Houston, we have a problem! That’s just an example, but the general approach is clear: if one has to constantly sacrifice immediate, good-enough implementations to adopt half-finished tools or workarounds to solve basic GUI workflows, WMs become not accelerators of productivity but defective implementations, and that has been my constant experience in that regard with WMs. At some point, one has to set priorities, and after years, my priority has become not to waste time reinventing the wheel for desktop GUIs. Sorry, guys. There is more than one way to implement a desktop interface, but many of them can simply become a pain because they are not flexible enough or incomplete, resulting in continuous adjustings and workarounds to have something decently working.

And yes, this is another damn opinionated post about the current Year of Linux on Desktop. Don't take it too seriously...

A Terramaster NAS with Debian, take two.

2026-01-19T13:00:00Z

After experimenting at home, the very first professional-grade NAS from Terramaster arrived at work, too, with 12 HDD bays and possibly a pair of M2s. NVME cards. In this case, I again installed a plain Debian distribution, but HDD monitoring required some configuration adjustments to run smartd properly.

A decent approach to data safety is to run regularly scheduled short and long SMART tests on all disks to detect potential damage. Running such tests on all disks at once isn't ideal, so I set up a script to create a staggered configuration and test multiple groups of disks at different times. Note that it is mandatory to read the devices at each reboot because their names and order can change.

Of course, the same principle (short/long test at regular intervals along the week) should be applied for a simpler configuration, as in the case of my home NAS with a pair of RAID1 devices.

What follows is a simple script to create a staggered smartd.conf at boot time:

#!/bin/bash
#
# Save this as /usr/local/bin/create-smartd-conf.sh
#
# Dynamically generate smartd.conf with staggered SMART test scheduling
# at boot time based on discovered ATA devices

# HERE IS A LIST OF DIRECTIVES FOR THIS CONFIGURATION FILE.
# PLEASE SEE THE smartd.conf MAN PAGE FOR DETAILS
#
#   -d TYPE Set the device type: ata, scsi[+TYPE], nvme[,NSID],
#           sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N],
#           usbprolific, usbsunplus, sntasmedia, sntjmicron[,NSID], sntrealtek,
#           ... (platform specific)
#   -T TYPE Set the tolerance to one of: normal, permissive
#   -o VAL  Enable/disable automatic offline tests (on/off)
#   -S VAL  Enable/disable attribute autosave (on/off)
#   -n MODE No check if: never, sleep[,N][,q], standby[,N][,q], idle[,N][,q]
#   -H      Monitor SMART Health Status, report if failed
#   -s REG  Do Self-Test at time(s) given by regular expression REG
#   -l TYPE Monitor SMART log or self-test status:
#           error, selftest, xerror, offlinests[,ns], selfteststs[,ns]
#   -l scterc,R,W  Set SCT Error Recovery Control
#   -e      Change device setting: aam,[N|off], apm,[N|off], dsn,[on|off],
#           lookahead,[on|off], security-freeze, standby,[N|off], wcache,[on|off]
#   -f      Monitor 'Usage' Attributes, report failures
#   -m ADD  Send email warning to address ADD
#   -M TYPE Modify email warning behavior (see man page)
#   -p      Report changes in 'Prefailure' Attributes
#   -u      Report changes in 'Usage' Attributes
#   -t      Equivalent to -p and -u Directives
#   -r ID   Also report Raw values of Attribute ID with -p, -u or -t
#   -R ID   Track changes in Attribute ID Raw value with -p, -u or -t
#   -i ID   Ignore Attribute ID for -f Directive
#   -I ID   Ignore Attribute ID for -p, -u or -t Directive
#   -C ID[+] Monitor [increases of] Current Pending Sectors in Attribute ID
#   -U ID[+] Monitor [increases of] Offline Uncorrectable Sectors in Attribute ID
#   -W D,I,C Monitor Temperature D)ifference, I)nformal limit, C)ritical limit
#   -v N,ST Modifies labeling of Attribute N (see man page)
#   -P TYPE Drive-specific presets: use, ignore, show, showall
#   -a      Default: -H -f -t -l error -l selftest -l selfteststs -C 197 -U 198
#   -F TYPE Use firmware bug workaround:
#           none, nologdir, samsung, samsung2, samsung3, xerrorlba
#   -c i=N  Set interval between disk checks to N seconds
#    #      Comment: text after a hash sign is ignored
#    \      Line continuation character
# Attribute ID is a decimal integer 1 <= ID <= 255
# except for -C and -U, where ID = 0 turns them off.

set -euo pipefail

# Test schedule configuration
BASE_SCHEDULE="L/../../6"  # Long test on Saturdays
TEST_HOURS=(01 03 05 07)   # 4 time slots: 1am, 3am, 5am, 7am

DEVICES_PER_GROUP=3

main() {
    # Get array of device names (e.g., sda, sdb, sdc)
    mapfile -t devices < <(ls -l /dev/disk/by-id/ | grep ata | awk '{print $11}' | grep sd | cut -d/ -f3 | sort -u)

    if [[ ${#devices[@]} -eq 0 ]]; then
        exit 1
    fi

    # Start building config file
    cat << EOF
# smartd.conf - Auto-generated at boot
# Generated: $(date '+%Y-%m-%d %H:%M:%S')
#
# Staggered SMART test scheduling to avoid concurrent disk load
# Long tests run on Saturdays at different times per group
#
EOF

    # Process devices into groups
    local group=0
    local count_in_group=0

    for i in "${!devices[@]}"; do
        local dev="${devices[$i]}"
        local hour="${TEST_HOURS[$group]}"

        # Add group header at start of each group
        if [[ $count_in_group -eq 0 ]]; then
            echo ""
            echo "# Group $((group + 1)) - Tests at ${hour}:00 on Saturdays"
        fi

        # Add device entry
        #echo "/dev/${dev} -a -o on -S on -s (${BASE_SCHEDULE}/${hour}) -m root"
        echo "/dev/${dev} -a -o on -S on -s (L/../../6/${hour}) -s (S/../.././$(((hour + 12) % 24))) -m root"

        # Move to next group when current group is full
        count_in_group=$((count_in_group + 1))
        if [[ $count_in_group -ge $DEVICES_PER_GROUP ]]; then
            count_in_group=0
            group=$(((group + 1) % ${#TEST_HOURS[@]}))
        fi
    done
}

main "$@"

To run such a script at boot, add a unit file to the systemd configuration.

sudo systemctl  edit --full /etc/systemd/system/regenerate-smartd-conf.service
sudo systemctl enable regenerate-smartd-conf.service

Where the unit service is the following:

[Unit]
Description=Generate smartd.conf with staggered SMART test scheduling
# Wait for all local filesystems and udev device detection
After=local-fs.target systemd-udev-settle.service
Before=smartd.service
Wants=systemd-udev-settle.service
DefaultDependencies=no

[Service]
Type=oneshot
# Only generate the config file, don't touch smartd here
ExecStart=/bin/bash -c '/usr/local/bin/create-smartd-config.sh > /etc/smartd.conf'
StandardOutput=journal
StandardError=journal
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

AI training, copyright and the future of contents creation

2026-01-11T21:00:00Z

I have already addressed the implications of modern LLMs, specifically their training, in the context of copyright and licenses for both code and original content. A 'IANAL' disclaimer applies to this post, but my honest opinion is that such training is a legitimate type of reading and learning after study, unless explicitly excluded in licenses among the licensee's rights.

Following the exploitation of LLMs and the AI boom that began in 2022, several lawsuits and litigations emerged among multiple parties, with a few reaching a significant milestone through the first court rulings. Note that every country has a bit different regulations about copyright and fair use, so the current lawsuites could be only the starting point of a long list of legal actions.

While most of the current lawsuits seem to demonstrate that Anthropic or Meta had the right to use books bought (in paper or digital form) for LLMs training (on the basis of the fair use principle), the most problematic aspect instead is the apparent use of pirated books taken from LibGen and other known piracy websites, which - if confirmed - can result in potentially destructive damange for the companies, to compensante authors and pay fees in the order of hundreds of billions.

The same problems are present in the coding parts: again, using FOSS-licensed code for training could fall under fair use, but training using private codebases, as well as proprietary ones, could be equally destructive for the same companies, as well as for GitHub and Microsoft. The key point would be demonstrating, without any doubt, the unfair use of private or pirated content, of course.

Of course, I'm quite sure future licenses for FOSS codebases and documentation could include an explicit exclusion clause for AI training, which could jeopardize the legitimation of use even for future FOSS code. I would expect such a license change, as some projects already explicitly exclude AI-based contributions. My opinion about such a question is that it could represent shooting oneself in the foot, due to the pervasivity of AI tools among developers currently. Adoption of AIAD could represent a boost in development time if adopted with a healthy dose of skepticism (i.e., a human-in-the-loop approach). About that, I'm quite convinced of Linus Torvald's point of view: the point is not who writes the code, but who is technically responsible for it and ensures the required quality review and supervision.

Moreover, an implication of the current polarization in the AI hype is the future (present?) crisis of traditional web content providers. A symptomatic case is the StackOverflow crisis, which will, with high probability, lead to the end of the service as we know it in the near future.

That will have an impact on future AI training, too, for sure, because SO has been for years a huge source of knowledge about multiple fields in IT. What if fewer and fewer people will contribute to Wikipedia and general web content? What if more and more sources of information were to reserve the right to use their information for pure human-driven study? Knowledge has not been static in human history; AI models will need to continuously enrich their training sets and stay up to date.

It would be grotesque if the whole AI hype were brought to a halt by such copyright-based legal questions (even if I'm pretty sure a fully fair training would be possible now for such companies, who knows the impact of a more limited approach on the final result?). Surely, this seems the most serious threat to the future of such companies and the whole AI-based solutions.

The only true solution to such a threat is finally having a true open training model, which details sources and the whole process of training with full transparency, something that even the so-called open AI models are still far to be ready to provide.

References

This was for every one: about the crisis of the web

2025-12-25T15:30:00Z

I just finished reading the delightful book by Sir Tim Berners-Lee, titled This is for Everyone, published this year. It is a trip, long, almost 400 pages, about the origin and evolution of the World Wide Web, seen by those who conceived and pushed it from the start. The entire first part of the book is dedicated to the history of the web, the W3C, and the Web Foundation's operations as we have known them in the first 30 years of its development, from 1989 onwards.

I was there at the very beginning of the 90s: I was connected to the Internet since 1991, and reading such a book for a good part has been an emotional trip in my memory of those events and people. He is a visionary and an idealist who fought for an extended period to prevent his WWW creature from being intercepted and disrupted by for-profit interests.

It happened almost from the start, when first NCSA, then Netscape, and Microsoft tried one after the other to change the whole idea of openness into something proprietary, driven through the same scheme of embracing, extending, and extinguishing. In practice, the complete negation of standard and openness, with a clear goal in mind: obtaining users' lock-in into proprietary products, clearly for profit.

Tim provides evidence on multiple critical aspects of the current incarnation of the net as we know it today and over the last 20 years or more. They are both technical and social defects or drifts. The web is no longer what we learnt to know in its first years of existence. The start of the end of the original web concept was the mobile-first approach, which relegated the use of a regular computer to a second-class experience for most users. Most of the digital-native people never used a computer to access the network, and that user experience deeply affects the current vision of the web.

For years, nowadays, a browser has not been the main program for accessing content and services. Social networks are mostly not interoperable because companies have little interest in having their users leave the walled gardens of their apps. Using a browser and potentially exiting the company's services to access other servers and spaces is tolerated, but is perceived as damaging profits. That's simply because users are not users, but customers. The result is the shattered Internet about which I already wrote: the W3C standards are still relevant, but embedded in applications and frameworks that enrich and upset the user experience with proprietary workflows and extensions.

An emblematic case is Apple, which has, in practice, abandoned its WebKit engine and Safari browser in favor of apps and proprietary services to monetize customers and companies.

The concrete risk is that the whole web and its standards would become a marginalized component of the net, while most users are confined to walled-off realms of proprietary services and social networks. The recent AI innovation can mark the definitive end chapter of web content creation and search as we have used them over the last 30 years. More and more users will limit themselves to AI-provided overviews instead of collecting and consulting multiple sources of information and independent services. That will also have a concrete impact on revenues and interest in content creation and provision at large.

The second part of the book is fully dedicated to all such problems: the impact of social networks, the last few years of generative AI, the BigCo dominance, and includes all Tim's worries for the foreseeable future. He's an idealistic, optimistic, and positive guy due to his past experiences. However, he also has a good dose of sane realism. He understands that the path is nebulous and full of dangers (specifically, the AI path is highly polarizing and can hide multiple issues at many levels).

He sees in the indie web, and specifically in open and well-structured distributed standards (such as the ActivityPub protocol), a possible way to change the present and future by favoring interoperability and independence. A concrete proposal is the Solid standard for personal data wallets (or pods in Solid terminology) under complete user control for accessibility by third-party services. Such a standard is still in its infancy, but the true problem I see is the trustworthiness of involved parties, both companies and governments. Trusting is the key, and maybe we all individually lost such a superpower a long time ago.

Creating a corpus of rules to manage all such technologies and ensure ethical behavior can be a desperate illusion; the only concrete alternative would be to opt out, at the cost of exclusion from the social context (not only the digital one). But I agree there is no other way to recover the original idea of the web. The AI technologies are even more polarizing, among doomers and boomers, with a bumpy road ahead. For sure, open protocols and distributed multi-peer services are the inevitable starting point, but they won't be enough.

"It was not enough simply to release new technology and hope for the world to improve. You had to develop technology and society together. You really had to fight, in a principled and continuous way, for human rights. The web offered people a platform for their voices to be heard, reducing the cost of publishing and distributing information to effectively nothing. But, used improperly, it could also be turned into a tool of surveillance and control." (timbl)

References

Installing Debian on a USB stick for a Terramaster NAS

2025-10-15T18:00:00Z

I recently bought a basic NAS for home use. The NAS is a nice Terramaster F2-425, which is a very basic RAID1-only NAS with a decent CPU and 2.5Gb network. Terramaster allows users to either use its custom Linux-based TOS or install any other operating system supported by the x86_64-based platform. Note that this model does not mount any NVME unit for the OS, as for the F2-424.

Common choices include TrueNas, Proxmox, or any other Linux-based distribution. My choice has been a plain Debian stable distribution because I do not have special requirements and prefer a lightweight CLI-only solution over a dashboard. The F2-425 does not have NVME cards, only regular HDDs/SSDs. However, when installing an independent OS, as in my case, you can immediately use an external USB stick for the system, and dedicate HDDs to data. The unit even has a tiny (264MB) internal USB stick for installing TOS, but I simply used a decent 16GB SanDisk thumb drive. The clear advantage is the possibility of having the base system and data perfectly separated, and multiple copies of the stick for safety.

Of course, the installation of such a system can be done without using the Debian installer at all, so I'm describing here how to perform such an installation for my future reference and for other geeks. Of course, you need a running Linux system with debootstrap installed. The process involves partitioning the stick in GPT mode, installing the base system and EFI, and configuring the system to finalize a bootable system with the necessary software to connect the NAS to the network, including OpenSSH.

Note that the 2.5 Gb Ethernet is a RealTek, so a firmware blob (firmware-realtek package on Trixie) is required to properly work with that. Alternatively, another of the USB ports could also be used to add a wireless connection. The OS stick could be simply mounted on the internal port, but it requires opening the chassis for that and using a tiny stick.

At power-on, the internal TOS dongle automagically boots up, so connecting an HDMI display and a keyboard is required to change the setup to boot the Debian EFI image on the stick. On F2-425, press the <F12> key to access the AMI setup and change boot priorities. There are always slight differences among AMI BIOS setups, so it is required to find the right key to access settings and change boot options.

Let's consider /dev/sde as the name of the USB stick device on the host where it will be prepared. A GPT partition can be created via GNU parted, as follows:

parted /dev/sde 	# to create EFI and root primary partition
partprobe --summary /dev/sde
sfdisk -l /dev/sde
mkfs.vfat -F 32 /dev/sde1
mkswap /dev/sde2
mkfs.ext4 /dev/sde3

Once done, installing the base system is immediate.

mount /dev/sde3 /mnt
mount /dev/sde1 /mnt/boot/efi
debootstrap trixie /mnt

mount -o bind /dev /mnt/dev
mount -t devpts devpts /mnt/dev/pts
mount -t proc proc /mnt/proc
mount -t sysfs sysfs /sys /mnt/sys
mount -t tmpfs run /mnt/run

cp /etc/apt/sources.d/debian.sources /mnt/etc/apt/sources.d/.
cp /etc/resolv.conf /mnt/etc/.

echo "nas" > /mnt/etc/hostname
sed -i -e 's/localhost$/localhost\n127.0.0.1\tnas/' /mnt/etc/hosts

rootfs=$(blkid /dev/sde | grep TYPE=\"ext4\"|awk '{print $2}'|cut -d\" -f2)
vfat=$(blkid /dev/sde|grep TYPE=\"vfat\"|awk '{print $2}'|cut -d\" -f2)
swap=$(blkid /dev/sde|grep TYPE=\"swap\"|awk '{print $2}'|cut -d\" -f2)

cat >/mnt/etc/fstab <<EOF
UUID=$rootfs / ext4 noatime,errors=remount-ro 0 1
UUID=$vfat /boot/efi vfat noatime,umask=0077 0 1
UUID=$swap none swap sw 0 0
EOF

chroot /mnt
apt update
apt upgrade -y
apt install grub-efi-amd64 linux-image-amd64 ssh \
        firmware-misc-nonfree \
        firmware-realtek xfsprogs rsync pmount \
        gddrescue screen util-linux-extra bash-completion \
 	mdadm  parted smartmontools htop ntp unattended-upgrades sudo
useradd -m -G sudo -s /bin/bash -C 'Your Name' your_username 
passwd your_username
adduser your_username plugdev
apt install tzdata locales
dpkg-reconfigure locales
grub-install --target=x86_64-efi --force-extra-removable /dev/sde
update-initramfs -u
apt clean
exit # leave the chroot
umount /mnt/run
umount /mnt/sys/firmware/efi/efivars
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev/pts
umount /mnt/dev

Note that required HDDs can be easily installed later. I manually configured the two disks with GNU parted for a GPT Linux RAID partition. After booting with the stick, a simple install of the md array support suffices. Typically, the USB stick runs as /dev/sdd

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
mkfs.xfs /dev/md0
mkdir /data
data=$(blkid /dev/md0|grep TYPE=\"xfs\"|awk '{print $2}'|cut -d\" -f2)
echo "UUID=$data /data xfs defaults 1 1" >>/etc/fstab

In order to allow shutting down by pressing the power button, it is required to configure systemd-logind as follows.

sed -i -e 's/^#HandlePowerKey=poweroff'/HandlePowerKey=poweroff/ \
       -e 's/^#HandlePowerKeyLongPress=ignore/HandlePowerKeyLongPress=ignore/ \
    /etc/systemd/logind.conf

systemctl restart systemd-logind.service

It could also be a good idea to stop the periodic auto-scan on the RAID volume for big disks, which can take ages to run.

sed -i -e 's/^AUTOCHECK=true/AUTOCHECK=false/' /etc/default/mdadm
systemctl restart mdmonitor.service

The network configuration depends definitively on the type of connection used and the home network setup. In my case, the NAS uses a static IPv4 address, so it can be configured through ifupdown, and it is only necessary to correctly write the /etc/network/interfaces for the enp1s0 Realtek 2.5Gb Ethernet interface. Not that it requires a non-free firmware blob to run.

After the initial syncing, a series of software to better manage the NAS can be installed, but that is optional and can be the subject of a different post. For sure, for better convenience, a copy of the USB stick with the complete configuration is a good idea, to allow a fast recovery in case of failures.

A call to minimalistic programming

2025-09-10T17:00:00Z

Minimalism in development is a forgotten virtue of our time that should gain more attention. A straightforward summary of some minimalism principles is available here. Briefly, the principles of minimalism in Software Engineering can be summarized as follows, based on the manifesto for minimalism.

Fight for Pareto's law: look for the 20% of effort that will yield 80% of the results.
Prioritize: minimalism isn't about not doing things but about focusing first on the important.
The perfect is the enemy of the good: first do it, then do it right, then do it better.
Kill the baby: don't be afraid of starting all over again. Fail soon, learn fast.
Add value: continuously consider how you can support your team and enhance your position in that field or skill.
Basics, first: always follow top-down thinking, starting with the best practices of computer science.
Think differently: simple is more complicated than complex, which means you'll need to use your creativity.
Synthesis is the key to communication: we have to write code for humans, not machines.
Keep it plain: try to keep your designs with a few layers of indirection.
Clean kipple and redundancy: minimalism is all about removing distractions.

Most of those principles are coherent with each other and relate heavily to the well-known Unix KISS principle.

An extended and fascinating book about the practical application of such principles is Eric S. Raymond's "The Art of Unix Programming", which I strongly recommend reading. I can also recommend a now-classic volume on the same topic by John Ousterhout, "A Philosophy of Software Design". Both outline practical examples of how minimalism in design can be effectively embraced, with a focus on doing the right thing sooner rather than later.

The same principles could (or maybe should) be applied even to programming languages, but this is often a neglected aspect of such a minimalistic approach. Note that one of the most successful languages of all time is the C language, which indeed has a straightforward syntax and, as such, cannot be easy to use correctly (the principle is that what is simple is not necessarily easy, too). That's because the programmer needs to create her/his own abstractions and layers to build her/his vision of a software design. It seems that this is precisely the opposite of the C++ or Java approach, where the entire specification spans thousands of pages, and many high-level abstractions are integral parts of the language. The same can be applied to Python nowadays, which started as a simple language, more readable and clean than Perl, but now has a wide and articulated specification. Again, hundreds of pages are now needed to describe a once-simple language, where tons of new features and abstractions have been added to enrich its expressiveness. If one considers its standard libraries and modules, the actual situation appears even worse. Can such an approach be considered easier? I don't think so. Let me say: how can a program be considered simple if it relies on hundreds (or even thousands, including dependencies recursively) of external modules, as well as hundreds of syntactical constructs and glues? Some languages also manage multi-versioned dependencies, allowing a program to cross-depend on multiple editions of the same module (yes, JavaScript, I'm talking about you), with the concrete possibility of introducing obscure bugs as a result. At the opposite extreme, there is the consideration that we only know and deeply understand what we make.

Minimalism also means actively seeking a balance between these two opposing approaches, because reusing third-party modules and packages can be an immediate solution to deadline urgencies, but can also potentially introduce instability and dependencies on unmaintained software in the long run. Long dependency chains where changes happen independently of the main program focus and are introduced by third-party motivations and reasons - often with wrong timing for depending projects - can cause breakages at multiple levels.

Of course, to reach the right tradeoff, a few things need to be considered: every single programmer could not be smarter than a lot of libraries and modules out there, where multiple developers could have spent hours/weeks/months, or even years refining them. That's true, but it is also true that not all libraries or modules are written with the same level of quality and effort. For instance, we all know cases of elementary modules available for Node that could be easily avoided, and instead are imported for some form of laziness in development. Even, sometimes features that need to be used could be only a small portion of the whole library/module, which could be reimplemented with a very reasonable effort and time. This approach could be amplified in modern times when AI tools could significantly increase productivity in such cases. I would simplify these concepts with some additional mottos:

Limit your external dependencies: avoid depending on modules or libraries that are not strictly required to significantly reduce the total development time, are not rock stable for their interfaces and features, and do not have a clear and stabilized roadmap.
Reproducibility of the software stack is a must: these days, a SBOM has become recommended/mandatory, but it should not only consist in a documentation of external dependencies and their versions, but also the full process of building a runtime environment should be fully defined and consistent for the long term.
Do not follow the last oh!-so-cool technology: while that could be done for an amateur project to develop during spare time, it is not a good idea depending on a technology whose future is not clearly stated, with a well-established development team and proven sustainability in the long term. I consider a risk even depending on a single company project, and even more if it is considered a startup. Synthetically, this can be generically considered as minimalism in coding style.

Moreover, if you are going to use a well-established framework, such as Django, for developing your mid-to-long-term web project, it is probably better than using the latest Nodejs-based framework created six months ago that seems the latest 'big thing'. But that's probably only common sense. Instead, ask yourself if your project should be created from scratch using a simple jamstack system and some microservices for well-defined and minimal parts. In many cases, that is more than enough for too many CMS-based sites out there: indeed, I continuously ask myself why a lot of websites are still based on WordPress, when most of them could be easily converted into a handful of static pages and simple JavaScript snippets that they will use in any case. This can be declined in terms of minimalism in defining computing architectures, which can also allow scaling up applications more easily.

So minimalism principles can be considered at multiple levels: for programming languages, libraries, architectures, and design. However, they require skills, in-depth research, and a significant amount of time to dedicate to continuous refactoring and meditation about viable alternatives. And that's probably the key point: developers with deadlines and urgency imposed by PMs are too often tempted to follow the easiest and richest paths and provide a solution of any kind without too much meditation on the final balance among efforts, quality, efficiency, and durability of results.

Of course, about minimalism, an extraordinary citation is due for the whole suckless effort on the uncompromising minimalism side. And why not?.

Ok, ok, I'm joking. But you got the point.

About languages and tools: the walking dead and other legends

2025-05-08T13:00:00Z

I'm writing this post to react to one of the many articles and threads about the presumed death of this or that programming language, library, framework, or tool. What that article was about and who wrote it is secondary. I could synthesize my idea by citing a well-known joke by Mark Twain: "The rumors about my death are greatly exaggerated."

Let me use a synecdoche rhetorical expedient and limit what follows to programming languages. Of course, this post is not absolutely limited to them; it could be applied with little effort to libraries, tools, frameworks, content management systems, and many other tools of common use among developers.

Any developer who has been around enough knows that the death hoaxes about the end of a programming language are a common refrain that returns almost every year for most of them. The nude truth about programming languages is that developers follow trends and fashions. Job recruitments influence such trends, as well as some application categories and technologies that appear from time to time. Without any specific preference, there are currently tons of languages that still have significant (or even not so large, but still sustainable) communities that passed in the rearguard because their trendy momentum has been in the past. A lot of people mistake the end of convulse development periods (or, even worse, the absence of headlines on major tech news sites) for death. I could cite many such products that were considered dead a long time ago and still see one or more releases per year. From stability to death, it is often a matter of points of view.

I would not refer to Fortran, Cobol, Ada, Prolog, Lisp, etc., which have been around for 60-70 years. For me, all those are clearly niche languages that still have their own use in specific domains, and that has been true at least in the last 40 or 50 years. In most cases, they are not simply updated for features or even able to manage common applications or programming patterns of the modern era.

Who would try to write a web framework in Fortran or Cobol? Oh well, you probably don't know Fortran.io, an MVC web framework written in Fortran90. Or even any of the full-stack web frameworks written in Cobol. So, it is better to say that for such languages, some applications are purely intellectual challenges, drafts, and sketches that no one would seriously(?) consider in production environments. That does not imply that such products are at a dead end, but only that they are not considered for those applications (but could be for other ones).

But for them, there are even more recent languages that gained the stage about 20-30 years ago or less, such as Java, Perl, Ruby, or PHP, which are still in use in production environments but in declining popularity. A special case is C/C++ and its variants, which most consider low-level languages at a dead-end but are actively used in many application domains. Today, Rust is considered by general rumors to be their natural replacement, but again, there is no evidence that it will truly be so in the future. Often, in the past, what appeared to be an ineluctable success in a certain period revealed a pure illusion to be replaced by the next language of dreams.

So what? A dose of sane realism is genuinely required. Developers are voluble and suffer from early love like teenagers. What today seems like the way to go could only reveal a dazzle a few years (or even months) later. Being a bit conservative could help, but the whole silver bullet idea for tooling is auto-lesionism. There is not one ring to rule them all. Simply, there is not a single language to win in all fields, and the skill of being able to switch comfortably among multiple ones (possibly finding the most helpful for a specific goal or application domain) is the true superpower of a developer. That's specifically true if such languages expose different programming patterns and abstractions. All the rest is for gossip and opinions. Sometimes, a specific package or framework declares the convenience of using the language (do you remember the whole Ruby-on-Rails momentum?), as well as the existence of a very specific language feature (e.g., Erlang efficiency in concurrency). That is the true basis of a reasoned choice for an implementation.

That said, the only concrete problem nowadays is the job market. A learning plan that includes only good-but-old, as well as for the opposite, only too recent tools, could be equally wrong. The job opportunities could be equally few for both. It seems that the most convenient language is one with a vast community, but unfortunately, that could be a transient status: at the very beginning of the third millennium, it seemed that Perl was the language of choice for web applications, which became clearly not the case just a few years later. So what? Well, a grain of salt is due in any case, but what seems like the current primary choice could become a language of the past in just a few years.

A complete developer should at least know at a non-trivial level a system programming language (e.g., C/C++, or Rust), as well as Python, JavaScript, and possibly also a pure functional one (e.g, Scheme, Clojure, or Haskell). Of course, moving from a non-trivial level to the guru level is a matter of time and experience, and it could also never happen in practice for each of them. The more languages and programming paradigms you dominate, the better for you.

What will be the next dead language in the near future that still seems to be the current Big Thing? I have some suspicions, but I keep them to myself.

Refurbish to fight against planned obsolescence

2024-09-25T18:30:00Z

The planned obsolescence of computers and other IT electronic equipment is a well-known plague of our age. For years, I stopped buying new computers and prefer refurbished ones whenever possible. That includes all my personal ICT boxes, and even at work, I try to spin out the life cycle of the equipment in use under my direct management. Proprietary OSes often limit the lifespan of IT equipment, but in some cases, vendor-independent FOSS software can replace the original one at End of Life (EOL). This is beneficial because FOSS software is often more lightweight, customizable, and has a longer support life, thereby extending the usability of your equipment.

For instance, I'm writing these notes on a dual-processor Lenovo Thinkstation C30 refurbished workstation that left the factory 10 years ago with plenty of RAM I bought 4 years ago. Thanks to the use of SSD storage instead of the old HDDs, I hope to use it for at least another 4-5 years. My living room Thinkpad L540 refurbished laptop is the same age, again with a replaced SSD, and I bought it in the same period. My main office personal HPZ320 workstation has been around for almost the same number of years, while my office laptop is a damn new Thinkpad X1 Carbon 5th-Gen of 2017. Both of them were new at buying time.

Of course, all of them run Debian GNU/Linux and have been upgraded regularly during the years. This is essential. Otherwise, the well-known proprietary OSes will obsolete your boxes, and you will be screwed. Generally, this is an easy task because reasonably aged computers are better supported by FOSS kernels. It would be better to avoid well-known vendors with problematic or unsupported devices.

I have even run a couple of aged Seagate Personal NASes in EOL for years, thanks to installing a plain Debian for ARMv7 processors distribution instead of the original Seagate one. I think they have been around for almost ten years, and one is a used unit. Of course, HDDs changed in the meantime.

Some servers still in use are the rock-solid IBM xSeries.They were born with a Suse Linux ES 11 and are still around and doing their jobs under Debian. Of course, the trade-off between power consumption, budget, and goals must be rigorously considered.

Plan for the future in advance

In order to run computers for a long time, I found it essential to buy with more RAM than needed at the moment of buying (even in the case of new boxes). You will need more, and assume you still don't know. Possibly, the same is true for the number of cores. If you buy a refurbished computer, it is inevitably a professional/business unit you would never find in a shop for home users. That's better because they generally have superior quality and decent support in the Linux kernel. In the business market, note that many companies retain computers for an extended guaranteed time only (by internal policy), so you will always find 3-5 years-old equipment recycled by medium/big companies. For personal use, they are more than enough and exceptionally usable with a FOSS OS.

Even note that current computers (but for GPUs) are comparable to reasonably old computers (let's say the last 10-12 years) in terms of the number of cores, speed of RAM, and bus throughput. They are faster, but not so much. Their average power consumption should be lower, but Moore's law is dead, sorry. So, buying new computers is quite pointless in most cases, and even worse if you purchase a consumer low-end computer for a limited budget. A refurbished box is generally the best option because it is cleaned, incorporates ad hoc changes (e.g., a new SSD for old units), is tested, and includes a one-year warranty by its vendor (generally, but just check before buying). Even the refurbished computer was at least an SOHO one, not a home product, so it is a much better option.

Be redundant, be safe

I never base my daily activities on a single box. At home and at work, I always have forklifts and replacements for emergencies. You cannot trust old (or even new) units, and not for sure in the long term. The same goes for parts such as HDDs or SSDs. Ça va sans dire that you need to take care of your data and backup with required redundancy, too.

Missions impossible

As said, the refurbishing possibility is minimal for GPUs and in some application domains. I'm not a gamer, but there are rumors about forced obsolescence every few years for commercial reasons triggered by games and vendors. Even for high-performance computing, any GPU before late 2014 is not more truly supported or usable. Again, it is partially a matter of hardware, but proprietary software, including SDKs, renders old GPUs obsolete.

Nowadays, the 2016 generations of GPUs with 8GB of VRAM are basically to be retired for many applications: that was the standard size at the time, but now vendors have decided that 8GBs or less is too few for any practical use. Too bad.

Smartphones are another area where planned obsolescence is the rule. The most expensive ones have 7 years of software support, but most can only be upgraded to a pair of major versions. Basically, you should change your phone every 3-5 years because security support is limited in time. But the average replacement cycle seems less than 3 years, anyway. Often, an older phone can still be used, but it is at risk for security support. Too bad, again.

The same happens for many so-called smart electronic equipment: having a box permanently connected to the network and missing any security support is generally a bad idea, and only a small minority of them can be upgraded to FOSS firmware. Cameras, TVs, routers, access points, and many other objects in our homes have a sort of implicit counter for end-of-life that often stops before the end of the hardware parts. You need to be very selective in equipment vendors.

In many cases - guess what? - such devices now run an embedded version of GNU/Linux that could be community-supported after the end of vendor support if the vendor provided enough information appropriately, which is rarely a possibility. In most cases, the vendor only has a public archive of third-party FOSS source packages, not the entire build system, so community support is not practically viable. Even any development documentation is usually totally missing, just to discourage people from following that path. In many cases, the devices include totally proprietary chipsets and drivers, so there is no way. That's even the reason why Android is an almost-open mobile operating system. Too bad, take three.

Will it change in the future?

In general, this battle was lost years ago. Expanding or repairing a laptop could now be challenging due to the accurate practices of many vendors to discourage self-intervention. That's true for a lot of other equipment, too. They are always ready to obsolete your products more often than you are prepared. I'm a pessimist about the future of this war.

They're coming outta the goddamn walls