frankie-tales

SM-Tools, Copernicus, FOSS and the reasons of inevitable choices and drifts

2026-02-25T15:00:00Z

Here at work, we develop a series of tools for geospatial processing with multiple goals, expected maintenance durations, different scopes, generalization needs, and motivations. Note that about 10 years ago, here in Europe, a completely new approach to upstream and downstream services for Earth Observation began: ESA changed its data licenses, and distribution and access modalities entered the Big Data era.

That even changed the data approach for academic institutions and triggered a major shift in the daily work of researchers, with access to a tremendous volume of weekly data available almost just in time and worldwide. Of course, such a change also impacted us, and we had to adapt our processing and storage capabilities to the new era.

One of my side projects in that regard is SM-Tools, which consists primarily of a collection of support tools for running our internally developed soil moisture algorithm using SAR satellite data (SMOSAR). One such tool (now named smt_copernicus) began (and evolved with multiple restarts-from-scratch) more than 10 years ago, when the Sentinel constellation started operations. Its purpose is to search for and download satellite products from Copernicus archives using multiple criteria, and to maintain an internal geospatial database of these products, along with all derived maps and ancillary data. This is only one component of a system that should be able to process large quantities of multi-source data on selected areas of interest, create downstream products, and calibrate and analyze results by comparing them with field data. The clear final goal is to achieve new findings in satellite data analysis, supported by extended processing worldwide, and to introduce new algorithms.

This is a long-term goal that unfortunately runs up against short- to mid-term difficulties of accessing archives that are not under our direct control. The sad reality is that in the last 4 years, the Copernicus archive access modality changed 3 times, and in the previous period, Copernicus also changed policies and modalities in progress (e.g., by introducing online and offline products, changing formats, etc.). Geospatial communities are small enough to encounter more practical difficulties than expected in such operational conditions, and this is now an almost weekly experience. We now have to chase other parties’ changes more often than we did in the past, rather than working on our own goals instead.

For instance, until 2023, the main package used for accessing the Copernicus archive was the Sentinelsat Python package (developed by an handfull of willing scholars starting in the summer of 2015). It became abandonware that year when people discovered that the protocol changes required rewriting most of the package from scratch, including all test code and mockings. That happened again at the end of last year. Incredibly enough, all access protocols have been an ongoing affair since 2023, even for non-secondary details, and required frequent adjustments to avoid unexpected breakage in download and processing pipelines. That for sure does not encourage community-supported FOSS solutions. Exactly in 2023, when I discovered our Sentinel-related tool had to be deeply changed because of the lack of the obsoleted Sentinelsat package, I decided that enough was enough and managed to migrate from Python to a fully self-supported Perl reimplementation: one of the things I always hated in the Python ecosystem is the excessive (for me and our purposes at least) speed in deprecation of consolidated packages and features, and the prospective of having to chase after unexpected changes in both Copernicus AND Python sides was out of question. My experiences with Perl have been much less annoying in this regard, with scripts running perfectly even after 20 years since they were written. Let’s consider this the old-school approach: if something is working, don't touch it without a more than valid reason, and even then, think twice before you touch.

In the meantime, around 2019, another independent effort started to support Copernicus access, along with a few other data providers. That’s about 4 years after the original Sentinelsat project. Timing in this case is essential to be considered. EODag is a single-company FOSS product that has been actively developed since then, but may have been considered stable 1-2 years later. Of course, it only provides the usual access layer, and using that package implied, at the time, replacing Sentinelsat with EODag as a base layer for searching and downloading only, while performing other tasks afterward with other self-made code. Before 2023, using Sentinelsat or EOdag was equivalent in order to perform the same task, with very little advantages.

Note that both tools were, in any case, pretty adequate but not enough for our goals, and also had a few defects (or a lack of flexibility, to say better) to manage in some creative way. That has been one of the reasons for not replacing Sentinelsat with EOdag in 2023. The other major one was that the idea of replacing a small package with another (as for Sentinelsat, there are just a couple of main contributors to the codebase, along with a good number of pending issues and PRs for such a kind of product) is probably not the safest one to avoid problems in the near future, when Copernicus will change things (again, see the next Earth Observation Processing Framework EOPF data format — Zarr). And of course, EODag is written in Python, and I already expressed my concerns about that.

Even if you like it or not, nowadays, the concrete alternative to adopting small FOSS projects to perform basic tasks is to use AI tooling to create a perfectly (or almost so) tailored implementation for the target task. While in 2023 I had to rewrite from scratch (in maybe a month of work with some fixes to Geo::GDAL::FFI package for a multi-threading issue) an implementation of a multi-threaded tool for accessing the Copernicus archive and maintaining an internal geospatial database of products consistently among multiple generations of the archive, I implemented the STAC protocol variant in a few hours instead, thanks to Claude Code-based patching and my reviewing and tests for the resulting codebase. As said in this post, currently, the cons of adopting a small third-party FOSS solution outweigh the pros, particularly regarding the resulting technical debt, compared with a well-conducted self-consistent AI-based development process.

I’m seeing in my own side projects exactly the mirror of what will probably be the reality of FOSS projects in the near future, in practice, as I mentioned in the previous post. Relatively few major/interesting projects will be adopted by others and attract contributions, while most codebases will become pure one-man shows, with AI tooling.

A significant part of geospatial processing involves data procurement and processing, i.e., refining and preparing data and images in order to collect, filter, and process large volumes of data for subsequent analysis. This is the most annoying and repetitive part of the process, and also often the most time-consuming. In my experience, working on those tasks is probably the most effective way to use LLMs through a spec-and-test-driven design. Whether you like it or not, it is the most immediate way to produce working code by iterating with a chain of thoughts and accurate reviewing of results, including a decent test coverage. As observed in Antirez's experience, the AI agent also had the nice ability to retain my Perl style (which is not secondary, given that Perl has many programming flavors and variants).

Maybe the final results will be an increase in quick-and-dirty codebases, but for many scholars, it will be a major simplification of their lives. In most domains of science, coding activities have been seen as an inevitable evil: they are a tool, not the primary goal, and even before the advent of LLMs, most scientific codebases were far from something to be proud of. The Copernicus attitude to FAFO will also encourage such approaches. Simply because scholars don't have time to waste chasing changes introduced by this or that data provider or company when contracts change.

AI sloping attitude? No, simple survival instinct.

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

About computing environments for reproducible science

2025-12-09T13:00:00Z

A few weeks ago I gave a lecture for the Spatial Ecology course to introduce a handful of junior and not-so-junior researchers from various domains to the not-so-nice world of scientific computing environments.

For people interested, here are my slides about this topic. They are somehow specialized for the Python ecosystem (which has become nowadays the programming language adopted for scientific computing in multiple contexts), where, in the last few years, a lot of evolutions have taken place for the management of dependencies and the management of the computing environment. This problem is amplified in the HPC context (I already wrote a semi-serious post about such an argument).

I also cited guix without more details (it was impossible to deal with all sub-topics in the lecture, and I know that multiple listeners already had problems fully understanding the matter).

Reasoning about that, it is not a silly idea to write some blog notes about the whole topic. First of all, what is the context? Reproducible science is not a novel matter. Any scientific experiment should be reproducible, starting from the same data and giving comparable results: this is the basis of the scientific method (Galileo docet). In the context of scientific computing, that implies that the whole execution environment should be fully reproducible in order to ensure the possibility of replication of the executions, with the same outputs starting from the same inputs. Possibly later on, running on the same platform, or after deployment on a new, completely different system.

The key point is that the long-term reproducibility of such results on current platforms and with current languages is minimal, to be generous. Having the full source code of a Python notebook, a git source repository, or anything comparable is simply only the starting point. The sad reality is that in practice, the source code has, in too many cases, a lifetime of a few months because of the understimation of such a problem by the average scholar. When following a few good practices, such a lifetime can be extended to a few years, maybe.

When I wrote my thesis, too many years ago, I developed the whole C source for execution on a parallel computer of the time. It was a Meiko Computing Surface, a SIMD platform based on INMOS Transputers. The C code used a proprietary message-passing library, CSTools, to enable communication among T-800 processors (unfortunately, there is no relation with the Terminator series, sorry). Now, it is somewhat expected that a code based on a dead proprietary library running on a dead hardware platform could have reproducibility issues today, after more than 30 years.

What is unexpected is that one could have the same reproducibility problems after 30 months, or in some limited cases, after 30 days. I mean both at the binary and source levels, often. Now, part of the problem is due to the FAFO attitude of some development communities. Not all teams are like the GDAL one, which is capable of maintaining the same well-refined APIs for dozens of years. More usually, from time to time, new versions of libraries and tools introduce expected or unexpected breakages against past versions and APIs, which backfire on programs that use them. In other cases, new versions can fix and/or introduce bugs of primary interest for dependent software. Those are the main reasons to meticulously annotate and document every single version of direct and indirect dependencies. This is somewhat solved by dependency resolvers, as explained in my lecture. But that's only part of the whole chain.

Unfortunately, nowadays this chain of dependencies traverses a single language and crashes against system-level dependencies, including the whole operating system, with its system compilers, interpreters, and libraries. This problem is amplified in a fully containerized world, which is nowadays used intensively. Depending on a third-party-provided binary image taken from any hub out there is not a safer approach. Such images can disappear from night to day or have a limited lifetime, so the conscious scholar should also develop his/her own from scratch, which often is particularly out of the skill perimeter of the average scholar.

This is exactly where Guix tries to give an answer. Guix is a source-level package manager with a set of full descriptions written in Guile Scheme for the whole chain of dependencies up to the kernel level. Combining such an analytical description of the system for any built artifact in the timeline from the starting point (derivations), along with the possibility to use build systems to cache binary artifacts (substitutes), and install any software at the user level, does allow the creation of a source-level definition of a full execution environment.

Such an ambitious goal is not without problems, as magistrally summarized by Ludovic Courtès here, but anyway it is at light-years of distance from the possibility of the average deployment system that needs instead continuous babysitting in order to ensure a working environment.

What is probably of interest for general consumption would also be a consistent additional security tagging for derivations in order to fast identify sources with known CVE-tagged versions in the chain of dependencies. That would increase the level of self-awareness when the Guix time machine is used to go back in the past and pick some sources from Pandora's box. It would also be of considerable interest in the SBOM context outside the perimeter of science computing.

So, guix is not perfect, but again a sure advancement towards reproducible computing environments, which currently lack in a way or another in the science domain (and not only that).

References

[1] A guide to reproducible research papers

[2] Guix as a tool for reproducible science

[3] Using Guix for managing reproducible, flexible, and collaborative environments in a PhD thesis

[4] Reproducible genomics analysis pipelines with GNU Guix

[5] Replication crisis

Too many eyes or too few efforts?

2025-12-07T16:00:00Z

I recently read a post by Jack Poller about the end of FOSS optimism in creating software in recent years. His thesis is that the myth that the more eyes that look at a piece of software, the higher its quality, is indeed a myth, and that nowadays it is also a dangerous illusion when we concentrate the analysis on security. Commercial software, on the other hand, has processes and resources dedicated to managing security, which in these times of active AI use could make the difference.

I agree with such a thesis at large, but with some differences in declination and sense. It is absolutely true that security requires special skills that most developers do not have and (above all) are absolutely not interested in having. This is amplified in the FOSS communities, where many programs and libraries are not specifically written with security in mind. On the other hand, currently most AI-generated security reports are fake and pure hallucinations (e.g., ask the Curl maintainer, about the overwhelming number of reports in the last few years that are clearly generated with help of AI and are pure garbage). Therefore, having new AI-based tools for screening does not simplify the problem neither for software creators nor for infosec experts. Basically, they still need to do their time-consuming jobs with resources and efforts: there is not an easy escape for that.

Even, if you like it or not, nowadays FOSS software production is organic to the commercially supported one, and they are strictly connected. If the security (and, more generally, the sustainability) of so many FOSS projects today is a problem, it is also a problem for their commercial counterparts. In other words, FOSS development has been mainstream for at least the last 20 years: that implies that the sustainability (and security) problem extends to the entire supply chain for both FOSS and commercial software.

I already dealt with some of those topics in past posts (e.g., have a look here, or here), not referring to security, but to the sustainability of the FOSS ecosystem of independent-but-interdependent projects. This is a matter of responsability for both FOSS mantainers and companies, and not something that could be avoided as a problem for others.

As already written in the past, I can't see a recipe for success, but I'm quite sure that overcomplication of information systems does not help, but is part of the problem. Too many dependencies, complex frameworks, and architectures are sure highways for disasters. And that's true for both FOSS and commercial software. The shattering of code hubs among multiple sources of binaries, packages, images, and distributions is another sure quarry of problems, because they imply a multiplication of possible origins of issues, as well as the need of sustaining multiple teams and replicating efforts instead of concentrating them.

There is great chaos under heaven; the situation is excellent! (Mao Zedong) .

DebianGis anniversary and the power of being a community

2025-10-16T18:15:00Z

A few days before today, 21 years ago, I sent this message to the debian-devel-announce mailing list to solicit helpers in packaging and to oversee the geospatial software stack included in the main Debian archive. After so many years, still there.

At that time, the Debian project had already been around for more than 10 years and even had a few releases behind, but the typical maintenance of software was still a one-person show, except for a few large and complex pieces of software. Even the kernel was managed by a single developer, Herbert Xu. Each developer was responsible for implementing updates, fixing bugs, and releasing updates. Often jealous of such prerogatives and their stated possession of the package or task. While there was already a quality assurance team and an orphaning process for abandoned packages (or inactive developers), these processes were not very common and were even relatively slow and imperfect.

Since that time, team-based maintenance has become the standard approach in the Debian community for properly managing the most complicated software collections. That's at least to ensure proper long-term maintenance, because the average developer can provide only a limited continuity to their efforts, and real life is generally more complicated than the digital one. It is not secondary that packaging tasks can be tedious in the long term, and it is easy to lose motivation. The presence of a working team can reduce the risk of burnout and allow each developer to step down when needed. The most effective team should be small enough to coordinate more easily and avoid lagging in changes and migrations, but not too small: presenting a one-person show as a team work is not a great idea. But too many people in the same team is equally not a great idea for the opposite reason.

In the specific case of Debian, the system is so modular and lacks many interdependencies that it favors the creation of fully independent management groups for hundreds of components and ecosystems of packages. It is not casual that most of the bugs and inconsistencies are concentrated where too many parts need to interact appropriately with perfectly aligned programming interfaces.

Talking about DebianGis and the geospatial software, the key motivation at the time was the lack of a coordinated effort to build and collect together, with consistency, a lot of different libraries and programs that were (and still are) specialized enough and based on hundreds of dependencies, often not within the perimeter of competence of the geodata user. At that time, piling up the software stack of a typical geospatial application was not an easy task for the faint of heart, and most (all?) of the Linux distributions lacked in one way or another.

Anecdotally, I can remember about 15 years ago, the company that sold us a Suse Enterprise-based solution for a geospatial information system that had so many problems in completing the required setup that I finally created a chroot-based environment with a Debian stable plain install to run a working PostGIS DBMS. That was the time when containerized solutions were still far from being supported, so the chroot environment was the most immediate solution to such a problem. A little win for a community-based distribution and its tiny geospatial team, which provides a measure of the problems at the time. A giant step for the whole FOSS concept.

I'm currently much less active in packaging tasks, but still seeing the current team alive and capable of releasing well-supported products more than twenty years later gives me reason to be proud of such a community.

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.

Does HPC mean High-Pain Computing?

2025-09-06T19:40:00Z

Please, forgive the silly joke in the title of this semi-serious post, but lately I have been thinking about the strange fate of an area of general computing that I have spent more and more time in recently, as in the near and far past. For my job, I have utilized a series of scientific HPC clusters worldwide to solve multiple computing problems most efficiently by distributing computation across numerous nodes. Over the last thirty years, all such platforms have consistently shared the same common characteristics, which invariably pose a problem in their use for the average scientist (often a young/junior dedicated to a short-term project) in any application domain.

To use Fred Brooks' definition, HPC technologies have both intrinsic and incidental fallacies for such users category. The intrinsic one is due to the inner complexity of creating a parallel and distributed solution to any problem, possibly in a way that does not harm the final implementation due to the increase in communication time among computational agents. This is already a relevant problem per se, which can often be out of the abilities, knowledge, and interests of the average researcher in bioinformatics, physics, mathematics, remote sensing, or whatever other research domain.

The incidental fallacy is instead always due to the accessibility of platforms and the technologies used for their implementation. At large, all such HPC clusters are a large pool of multi-core hosts with plenty of memory and connected with multiple high-speed networks for implementing some sort of multi-tier distributed POSIX file system and/or object storage. Users can log in on a limited number of such hosts that are connected to all others and run some type of scheduling system (e.g., Slurm or HTcondor) where multiple computational nodes can be reserved for a limited period of time to execute batch jobs or even an interactive one (mainly for debugging). In most cases, such clusters can also be used with some MPI/OpenMP implementations for proper parallel computational modeling based on message passing among computing agents that run on multiple cores and hosts, with or without multi-threading. Alternatively, GPUs can also be reserved and exploited via Cuda/OpenCL. In many cases, such implementations are vendor-oriented and trigger the need to adopt specific libraries and compilers that add another layer of complexity to implementations.

The incidental problems start when the casual users discover that all such computing nodes invariably run some legacy enterprise Linux distribution that is maintained for a period of ten years or even more, until a full reinstallation of the whole cluster. On top of such legacy systems (that are for any practical use simply unusable as such) these scientific clusters give essentially a few different mechanisms for creating a general computational environment:

Environment Modules
Containers (Singularity or Apptainer)
Anaconda/Miniconda-like environment (or free forks like Miniforge)
Some specific software/application to run

But for containers, the other solutions are all binary-based hubs, which could expose them to possible breakages when the application developed needs to access exotic language bindings for extensions, and the poor users enter the mysterious and dangerous world of ABI violations and a chain of broken dependencies. Even, often, such hubs are not always consistent, and any upgrade by the admin team exposes them to sudden breakages from night to day.

The final solution (or apparently so) nowadays is using containerization and a target environment where the user code can find all and only the correct dependencies and versions for the whole software stack of the application. This, at least, until the third-party hubs of base distributions and languages ensure complete consistency and retain past binaries and versions for any medium/long-term need. Of course, a full source-based stack with proper version tracking a la Guix would help to avoid dependencies on external binary hubs and seems the way to go. Indeed, a small group of interest in such a solution has existed for a few years, but I am unaware of so many HPC clusters that consistently propose this kind of implementation for users. That said, writing Guile Scheme descriptors for preparing an execution environment may not be within the reach of the average researcher in biochemistry or astrophysics.

Unfortunately, as I wrote in a past post on this digital site, this moves the whole responsibility of a software stack maintenance onto the shoulders of the final users, who are often the infamous junior profiles I mentioned before. These are non-IT specialists who should adopt such HPC platform to implement solutions as part of their daily job in their special scientific domain.

The result, to be honest, is that the average researcher simply tries to avoid the whole thing as soon as possible because of the significant complexity that the entire thing involves, while the private sector introduced specialistic roles of data and software engineers to manage such problems properly (which is the only reasonable approach, indeed). Adding insult to injury, in some academic areas, such interests in HPC are also viewed with contempt or as a waste of time, if not openly discouraged.

All this explains why a roundabout in any of the significant HPC clusters worldwide often guarantees hilarious experiences in terms of who is doing what and how.

Sometimes, I almost feel like I can hear them swearing...

Guix for geeks

2025-09-03T19:40:00Z

In the last few months, I have installed and upgraded my second preferred GNU/Linux system, GNU Guix, on multiple boxes. Regarding that system, I have already written a few introductory posts in the recent past. This is an update about my experiences as a user and developer. I still think Guix is a giant step forward in packaging and management, in comparison with Debian and other distributions, for elegance and inner coherence.

On the negative side, I can confirm that the most important aspects to consider in order to adopt Guix for daily use are as follows.

Guix is essentially a roll-on type of distribution with a limited user base, so a grain of salt is required at upgrade time because instabilities are somehow expected. The integrated time machine can be used to step back in case of problems, anyway.
The development team and other support teams are tiny enough that I would avoid using Guix for publicly exposed services. Also, it can lag on specific applications and issues. Tasks and goals do not specifically structure teams, so there is no proper security team, but I guess all maintainers can participate to cover all required tasks.
Packages are not always up-to-date with the latest upstream versions. Some packages are even older than in Debian stable, so if you are looking for the latest and coolest products, that's not the place.
Some choices for the core distribution are not mainstream, such as using shepherd as its init system instead of systemd. This implies some delays because patches are sometimes due for complex software, such as Gnome, which introduced strict dependencies on systemd in recent years. This is the reason why, as of the current date, Gnome is still at version 46, while Debian stable is at version 48.
The geospatial tools and libraries available are still quite limited, which may require a more in-depth analysis to estimate the level of lag. See the section below.
The readiness for immediate use is not comparable to the main distributions. For instance, if one absolutely needs a non-free Linux kernel due to firmware constraints, the nonguix add-on repository is available; however, one must build and install an ad hoc ISO installer by hand. Nothing transcendental, but complicated enough to discourage most users. Here is my fork of the System Crafters repository to prepare such an ISO image, updated for use of the current main Guix (now hosted on Codeberg) and NonGuix channels. That could be easily prepared on any foreign distribution that includes the guix package management software, such as Debian.

As of the current date, I have installed at least a few laptops and VMs, including a Dell Inspiron 15, an Asus EEE 1215P, and an old Acer Travelmate. I strongly suggest using at least a box with 8GB of RAM and a 512GB SSD, because building from sources can be overwhelming. My dual-core Atom EEE Pc has only 2 GB of RAM, and it is slow enough, but it has the big advantage of being fully supported by the official GNU Linux libre kernel.

Additionally, I believe that having a local build host for substitutions within the home/work LAN is the most efficient solution. That is because the officially provided worldwide substitution hosts could be generally heavily loaded and occasionally fail (when that happens, the time of recovery is on a best effort basis).

Of course, it is also entirely possible to use Guix only as a package management system on a foreign distribution, having most of the advantages of a reproducible environment, as well as within a container or a virtual machine. In that case, one has to consider that the host system is typically based on the systemd init system, which can cause a few headaches when porting existing package descriptions for services taken from the Guix repository. Probably the best compromise is still using a foreign distribution on the physical box and a Guix-based container to prepare an execution environment, something I already experimented as explained in previous posts.

Guix and geospatial software

In 2004, Paolo Cavallini and I started a subproject within the Debian community of developers and users to improve the status of geospatial software in Debian. That was the birth of what is today the DebianGIS pure blend, with a mildly coordinated team of developers and maintainers that work together in Debian (and derivative distributions) on a set of essential libraries and tools for the geospatial community. For people interested in the history of FOSS, I wrote a contribution to the ASITA conference in 2009 about that. That was and still is grunt work, often neglected and at the time perceived as a secondary effort by upstream developers. Indeed, that is an essential task instead, because collecting together properly and ensuring that you have a complete and well-built stack of software for a geospatial application is not trivial at all.

One of such base libraries is GDAL, which can be built with multiple optional dependencies and plugins. Like other platforms, some of those optional dependencies are missing in the Guix package, and that should be taken into consideration. Some tools are instead totally missing, such as MapServer and others. Of course, some packages could be patched here and there in Debian, or can require a Guix-specific patching (because of the peculiarities of such a system, which does not respect the Linux FHS), and that definitely could be a reason to have a package in good shape or not. That's to say that the Guix ecosystem would need a serious help for packaging such niche packages, but where most people can see a lack, I see an opportunity in that regard. After all, when I started my life in the Debian project, it was because I did not trust an operating environment that I could not develop and adjust personally for whatever reason. That's the way and Guix seems a brilliant example of a vibrant community for that.

Still, no silver bullet

2025-08-24T18:30:00Z

I recently re-read the seminal book by Fred Brooks about software engineering, entitled "The Mythical Man-Month" or MM-M for brevity. Specifically, I read the paper version of the 20th anniversary, which was revised and reprinted in 1995, after the first edition of 1975. I did that on purpose, firstly because it is always a fantastic read, and secondly to understand how much of its contents is still valid today, exactly thirty years later since its last revision.

Fred missed in 2022; otherwise, it would still be interesting to know his thinking nowadays after the LLMs boom and the birth of the AIAD (AI Aided Development) as a new revolutionary (or often seen as such) tool. Hi, Fred, wherever you are. It is worth mentioning that AI was already taken into consideration by Brooks at the time, even if limited to expert systems and other rule-based variants, which seemed promising and often sold as revolutionary before the mid-90s. A lot of the book's contents remained in the history of software engineering, including the famous Brooks' Law, and the whole book is still an excellent source of inspiration for any management and organization of complex intellectual projects (not necessarily limited to software systems), that heavily includes large teams of individuals.

One of the main theses of the latest book edition is that in the short term of 10 years from its proposition (the original essay was dated 10 years after the first edition of the book), he did not expect a silver bullet. That means no significant technological or managerial development was expected to be able to improve our productivity in programming by one order of magnitude. Ten years later, he confirmed the same idea, even considering exceptional tools like old-generation AI, visual programming, CASE tools, and so on. Is this thesis contradicted in 2025 by the existence of current AIAD tools, including chatbots, agents, and AI-empowered IDEs? My honest idea is no. I mean not now and not for the foreseeable future. The reason is exactly the same as Fred posed at the time. Reducing accidental problems in software creation (what AI is able to do) cannot be confused with the essential problems in software creation: the complexity of defining an articulated task, its analytical specifications, and an algorithmic solution to solve it. First of all, ignore the simplistic case of asking an AI engine to implement a very simple program. Here, the word simple means truly that. If you can specify a request by a whatever large manageable token context and formulate your request in terms of a brief question (let me suppose a question of some dozens of rows), well, that's probably an example of a simple (or dumb) problem. Too few, too easy. We are talking about a whole system that is generally difficult to describe, even in thousands of pages of specifications and documentation, written collectively by large teams of developers, architects, and domain experts.

The hard truth is that most of the real-world information systems out there cannot simply be specified in such a way. We are not able to define an unambiguous and complete enough specification to describe such systems, not to mention being truly able to write a complete and neat documentation of it, including its inner workings and use. We live in a deep illusion about that. The context size to get the required level of details to avoid bugs and ambiguities in specification would be impractical for current and even future tools, as well as for any humans. We would get in any case buggy (i.e., incomplete or misunderstood) results even if the AI engine were able to avoid hallucinations (which is not the case) and had no limitations for context size. The presence of AI hallucinations is only accidental in this regard.

In the current AI tooling, we are simply moving the complexity from the writing of a formal language step by step to using a natural language with a higher level of abstraction to express the problem. The complexity is still there, and it is inherent to the problem. Again, we resolved an accidental difficulty in a creative manner, not different from moving from assembly to using a modern programming language. Now the difficulty has moved elsewhere, but it is still there, and natural language is even more complicated to use compared to formal language. These difficulties translate into multiple refinements and trials to try to be more precise and get sensible answers and code in a continuous iteration. Isn't that so similar to the whole ordinary process of developing a program? In the most simplistic approach, such a process becomes vibe coding, and iteration could tend to infinity, with a forever loop. The smarter programmer for an easy task will do that in a reasonable (limited, hopefully) number of iterations, instead. Is that a significant improvement of one order of magnitude? I think not, as in most cases for the past. As in the case of high-level languages instead of assembly, they improved efficiency in coding as asserted in MM-M, but not by a whole order of magnitude. The AIAD is again another helper to solve accidental difficulties. The problem and all its complexity are still there. Thinking that we found the silver bullet is again (and again) an illusion or pure marketing.

So why do many CEOs insist on predicting a bright yet unlikely future of AI agents instead of having developers create applications? Brooks already wrote about that: there is a profound confusion in exchanging months and men, and an excess in optimism when approaching software development, even among techies, but that becomes paroxysmal among managers. None can seriously provide even a decent and reasonable evaluation of development time starting from incomplete, ambiguous, or vague specifications: the same simply happens systematically in overestimating the capabilities of current AI tools.

So what? AIAD is simply yet another tool among those available to developers, but the management problem of dominating complex projects is still there, with all its inherent difficulties. And the possibility to use natural language instead of a high-level formal one is only an apparent simplification of the process. It looks more familiar and easier, but it is also much more ambiguous, and the so-called prompt engineering is again a pure optimistic illusion, an euristhic approach to try to overcome our totally insufficient capabilities of dominating nuances and semantics.

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.

Again about AI, copyright, uses and abuses

2025-04-29T20:00:00Z

My last post dealt with some ideas about copyright that need more in-depth analysis. First, as it was common in the old good days, IANAL applies to this post and the whole topic. The final results of current litigations in courts that touch on some of the primary companies involved in the whole AI thing could ultimately differ from what is now the common sense point of view (mine). This post could become rapidly obsolete, so another disclaimer is due for this aspect, too.

A nice summary of the matter in the summer of 2024 can be read in [1].

I have to partially fix the assertion I made about copyright by Anthropic/Google and whatever company in a certain sense. At least for US copyright law, anything directly produced by non-humans is (or seems currently) not admissible for copyright coverage [2]. As you know, there are a few differences between different jurisdictions, specifically the US and the rest of the world. That's the reason why, indeed, Joseph Borg and Galyna Podoprikhina by WH Partners [3] say:

Despite the "common" belief that a work can be only be
protected by copyright if it is created by a human, one must
bear in mind that copyright laws are not uniform around the
world, especially when it comes to AI-generated work, or a
work created with the assistance of AI. Currently, apart
from the UK as described above, AI artwork is also subject
to copyright in Ireland, India, and New Zealand.

If a photo taken with a camera is admissible for copyright, the same could be claimed for any other tool, one could say. In the past centuries, even photography would have been indubitably not initially admitted to copyright and the artistic scene: indeed, a painting is a lot different from a photo. A modern photographer would not agree with such mortification of her/his work. Today, the reality is quite different, and photography is fully accepted among modern arts, with all implications about intellectual property and copyright.

Most authors agree with the significance of the human contribution to the work to define a copyrightable work, but how this contribution could be quantified is obscure. The number of prompts and replies, as well as the size of context contributions, are significant and sufficient efforts, or should they be quantified in LOCs and the size of direct patches to the AI artifacts? And in that case, what is the percentage of human-driven contribution that represents the threshold for deciding if the work is copyrightable or not? I'm afraid that the final verdict is something to decide in a court, as in cases of plagiarism.

But for AI, for ages, we also had RAD and no-code/low-code utilities that seemed the future of development for specific applications, with all their limitations (not too different from AI ones, to be fair). Even in those cases, copyright claims could be problematic.

That said, there is also the problem of training possibly performed without authorization. While most of the FOSS software is covered by one of the OSI licenses, not all licenses are compatible with each other, so the resulting LLM model is questionable and possibly unfair. I will ignore, for decency, the eventual use of proprietary content for the purpose of training, which already seems to be the subject of lawsuits by multiple parties in some contexts: see for instance [4] and [5].

As written in [2], the final destination of the whole topic is still foggy and unclear. Multiple parties are involved, and a series of lawsuits and claims are pending. This seems to be the reason why some companies explicitly deny the possibility of using AI tools in their developers' daily work. Due to their pervasive diffusion at multiple levels, this becomes increasingly difficult to avoid. As often in the past, tools are still forward than rules and sh*t could happen in a not so far future.

References

AI artifacts, copyright and electric sheep dreaming

2025-04-22T12:30:00Z

My last post captured the attention of my old fellow Sandro 'strk' Santilli on Mastodon, who sent a provocation about the whole AIAD thing. So, the challenge is accepted.

First and foremost, the whole AIAD issue is a complex and hotly debated topic. The question of whether the training practices of the past and present should be considered fair use is a matter of contention. This is particularly true for existing code bases on well-known repositories and other types of content, a complexity that keeps us all intellectually engaged.

In the specific case of code, the basis for deciding about such a question was formerly stated in the accompanying licenses. Honestly, there is nothing in the current formulation of OSI licenses (BSD and GPL, among others) that precludes such a very special activity. The non-discriminating conditions apply to any human activity, and the neural net training - undoubtedly a human-driven task - is not excluded. The training is a learning type of activity or a sort of.

That said, the NN training is, of course, a massive and intensive kind of learning. But let me consider any artifact created by an AI model as a direct derivative product (this is a forcing of the concept for me, but let me axiomatically accept it). That could be an 'original' product created from scratch (i.e., by direct prompting or by limited documental context) or a direct derivate one (because it is based on previous code proposed as part of the AI context). Suppose you ask any of the big models for a direct clarification of the terms of use. In that case, you will discover that any of their artifacts retain the copyright ownership of the product, but there is a very permissive use that perfectly adheres to the four fundamental freedoms of FOSS licenses. Of course, the results could be based on a previous code base. In that case, its license still applies for such a derivative work, even with the additional copyright of Anthropic, Google, or OpenAI.

This could pose a significant problem if the final software product needs to retain one specific copyright holder, as is the case with most proprietary software or some FOSS ones. Understanding the potential impact of copyright transfer is a key consideration in this context, and it's crucial for us to be fully informed and aware.

Is the process of an AI participating in development really that different from what any average hacker does when participating in FOSS projects? I don't think so. You add your copyright to the existing ones for the parts that are under your direct control and accept conditions of use already defined in a license. The true challenge, in my humble opinion, lies in the changing of licenses. Any ex-post change should start with a note of acceptance by all copyright holders, including Anthropic, Google, etc.

I consider this difficulty a feature, not a bug. I advise against participating in projects with copyright transferring because of the potential for changing the license later when your contributions move out of your control. It happened in the past, and it will happen again.

One should also consider the licenses of many other sources of knowledge and inspiration for developers. How many people know that the default license for StackOverflow code snippets is CC BY-SA? Indeed, how many developers actually add an acknowledgment in their software for such snippets? Or even for snippets taken from sites, blogs, books, or manuals without considering that such sources are even more restrictive for use and creating derivative work? Isn't our full daily work the result of a long learning phase, based on our education and training by books, experiences of others, as well as trial-and-error processes?

That said, let me spend some words about the elephant in the room. In the context of AI and copyright law, the 'elephant' represents the complex nature of AI models and their potential to create original works. Do AI models dream of electric sheep? Well, I don't think current models are pure stochastic parrots, to be honest. I think there are probably dozens or hundreds of cognitive forms that govern what we call generically intelligence, including some emotive and empathic forms that one can also find in a dog, a cat, or a dolphin. One of those forms is probably captured from the neural network model of functional representation, which is also perhaps in common with part of our mind. We are at an average level, much more effective and efficient in those regards, and to be fair, I would also say that hallucinating is a common experience even on the human side. We are much more complete and retain contexts that are wide, like a lifetime. A few people are terrified by this observation and seek refuge in negation or faithful certainties.

We are complex organisms with probably still partially known processes that govern our so-called intelligence, which is physically based on cells and energy in our brains, whether we like it or not. We found a way to mimic part of this complex process, with all limitations of the case. Is this intelligence? I don't know, but at the end of the day, what is intelligence? When none asks me about that, I know perfectly what is, but if you ask me about that, I don't know anymore.

Coding with AI, the good and the bad

2025-04-20T17:40:00Z

Like many other developers, I recently started using some LLM-based AI systems as helpers for coding in a few languages. I'm not a fan of VSCode, and I prefer a more traditional approach to coding: I hate to cope with code completion servers and use one of my preferred editors, Vim or Emacs. Navigating by tags is more than enough for me. That said, this is the summary of my current experience in the new world of AI-aided approach to coding (i.e., AI-aided development or AIAD for brevity).

There's a clear divide among developers when it comes to AI tools: some love them, while others are more skeptical. If you're keen to delve deeper into this topic, Salvatore Sanfilippo, also known as Antirez, shares some insightful perspectives on his YouTube channel. He provides comprehensive evaluations of the leading AI models and systems, offering a balanced view of their strengths and limitations.

Based on my experience, while both Anthropic and Google top models are equally good enough for use, a big difference is due to their relative UX, which is incomparable among various systems. Luckily, things are continuously changing in those areas. Copying and pasting without a clean and accessible per chat/project assets catalog is definitively a pain. The most effective approach is sharing pieces of a git-based code base, which is not always possible with all AI chatbots. Even Salvatore shared a few impressive results about his experiences, and I can definitively assert that, at least currently, some of those systems can be quite helpful for some tasks if (and only if) used with a grain of salt.

First and foremost, the most effective use of AI tools starts from very circumscribed tasks to perform in a step-by-step approach after a well-stated creation of the context to make choices. In other words, any model must be conducted by hand in the right direction. It is crucial to use what Claude AI defines as projects to create a clear context with a general detailed architecture description and key assets for orienteering the linguistic model. It is also essential to maintain order meticulously. Being verbose enough and precise is the key point, and that's typically what a senior profile should be able to do. Each resulting asset needs accurate reviewing and testing; it is simply impossible to assume that a simple change in human terms corresponds to perfectly valid changes in AI assets. What is easy for us could not be for the AI model and viceversa.

The review should be both stylistic and functional because complicated programming patterns could be completely unmatched by the AI model. That is specifically true when documentation about APIs is unprecise or missing the point. The models even tend to generate redundant code or hallucinated code snippets that cannot be compiled or interpreted. Sometimes, the AI model generates incredibly good code at large but presents silly or subtle oversights. At the end of the day, there is not always a gain in development time; it is only something different: you spend more time reviewing and fixing bugs than writing code from scratch. It is essential to cope with the limits of current AI systems to develop a handy way to compose multiple parts together and keep track of improvements and fixes in multiple iterations of the process. During iterations, it could reach the limits of the AI context and get incomplete or truncated files, and it is fundamental to have a way to regain the path with minimal effort. In other words, one has to design a well-formed idea of the resulting products and all intermediate artifacts. That's the reason why seniority and experience are fundamental to using such tools effectively: sorry, Mr. CEO, engineers are still here to stay and being paid for good work.

Tasks that can be easily covered by current AI models are:

Creation of general documentation and/or comments in existing code.
Creation of simple tests from a structured codebase.
Translation of code from one programming language to another, including documental formats, such as XML, JSON, and YAML.
Creation or improvement of auxiliary tools and boilerplates.
Reviewing and improving existing code by steps.
Help in identifying common issues and possibly interesting features.

The average results are good enough for an initial base of successive analysis and development, and I found the AIAD especially helpful with activities that I judge seriously dull and time-consuming. It's a relief to have AI tools that can handle the whole web front-end-related activities, which I personally find less interesting.

Using multiple AI models to cross-review a code base and possibly prepare multiple improvement alternatives while purging the obvious misunderstandings is also an interesting opportunity. At the end of the day, I judge AIAD as effective enough, but for the most significant limitation of having a not-too-extended context size (at least with basic pro/premium profiles). This intrinsic limit is the source of major problems in the UX, along with still rough or incomplete interfaces: if you need to review and modify a large code base, you can easily crash against such limitations and have to apply intensively a divide-and-conquer strategy to govern hundreds of thousands of LOCs (but diving into any unknown big code base is anyway so different?).

Of course, the correct approach is understanding that its use changes programmers from pure creators to reviewers. In those regards, I generally consider AIAD a Stackoverflow with steroids: anyone who used SO in the past found valid and interesting answers to questions along with perfectly misleading suggestions, and that's not different, and mostly better.

Disclaimer: I mostly used Claude and Gemini Pro, much less ChatGPT and Deepseek due to their intrinsic limits for UX.

FOSS toxicity, burnout and governance (again)

2025-03-23T15:40:00Z

I recently read with interest the post where Hector Martin resigned as Asahi Linux leader. As possibly well-known, Asahi Linux is the very first Fedora-based distribution where all the hard work to support the Apple ARM M* chip series in the Linux world found its way.

Dismissing the whole thing as another episode of burning out for a FOSS developer would be ungenerous. Some elements are typical in such cases, such as the excessive users pressure on the project. That caused a lot of pain and over-reactions in other contexts, but a big part of the Hector experience is related to issues with the upstream Linux kernel within the more general Rust-in-Linux saga.

Of course, harsh behaviours and bad relations with other people are common patterns in all human activities and often require a very thick skin and big diplomatic capabilities to get positive results. This is not specifically true for FOSS developers only (even if I say that a lot of developers are quite peculiar on the side of human relations, often in a semi-pathological way).

In my life, I have had the opportunity to deal with another very peculiar human category, such as cavers. Even when no money is involved, human beings can create bad relations, internal wars, and unhealthy atmospheres for their fellows. So, I guess it is a standard part of all human-to-human interactions, not a FOSS ecosystem peculiarity. A lot of people are strongly opinionated, and when also passionate, they tend to become intractable.

That said, I will concentrate on a specific part of Hector's post.

[...]
Back in 2011, Con Kolivas left the Linux kernel community. An anaesthetist by
day, he was arguably the last great Linux kernel hobbyist hacker. In the years
since it seems things have, if anything, only gotten worse. Today, it is
practically impossible to survive being a significant Linux maintainer or
cross-subsystem contributor if you’re not employed to do it by a corporation.
Linux started out as a hobbyist project, but it has well and truly lost its
hobbyist roots.
[...]

This is indisputable, IMHO, and it is likely the root of many problems that afflict the Linux kernel community and others. When people start working side-by-side with others who are motivated and sustained by different goals, it could be the seed of big social issues. Linux is not more just for fun for years, and that can create friction among developers. That includes perception about what should be considered acceptable for project sustainability and what should not.

These days, all that includes the use of profiling features for projects that are directly exposed to end-users and definitively the acquisition of personal habits and/or information about the users. This is not the case of Linux kernel, but it is a concrete issue for organizations such as the Mozilla Foundation and its products, and could become a divisive issue for OS distribution projects, as already happened in the immediate past.

Another problem is the wrong perception that a FOSS project should always accept contributions and enhancement proposals, while often it is not due or obvious. Like it or not, no acceptance of contribution is due, and I would add that FOSS projects could (or should) be very conservative in those regards, i.e. answering thanks-but-no-thanks more often than I have seen in recent years. IMHO, this gives evidence to what, for me, is an urgency for too many projects to list here, including, in practice, all programming languages out there.

Adding features over features on a piece of software is almost never a good policy because it increases the entropy of any software product and decreases its usability. The original spirit and goals of the software that possibly decreed its success should always be preserved, and that has been the basis of the original success of the Unix operating system approach, as an ensemble of compact and independent tools that solve single problems in the most general, simple and elegant ways, tools which are able to glue together to solve complex tasks. Now, this simple vision is already a source of friction among developers because maintainers are so often obliged to answer negatively to pull requests and patches for either respecting quality levels or opportunity.

This is a delicate trade-off that should be translated for every minimally articulated project in a written Social Contract to state and explain the goals and rules to respect for both users and developers. In a word, the governance principia of the project need to be defined ex-ante and not ex-post, to avoid misunderstandings and inner fights, as well as avoidable pressures during time. Unfortunately, many FOSS projects tend to delay ad libitum the definition of an explicit Social Contract or introduce that - more often, only a Code of Conduct for contributors is contemplated - when it is too late. Many big projects do not even have such explicit statements, and it is a pity. Users and developers should always be aware of such rules and goals in the life of any FOSS project.

One of the biggest problem nowadays is having such governance clearly established for life, but another is also ensuring that users and developers know its existnce and respect it, the two side of the same problem.

Enterprise software systems, or how diamonds never came from s*it

2025-02-23T15:00:00Z

Some time ago, I eventually listened on YouTube to a year-old interview by Guido Penta with Salvatore Sanfilippo (aka Antirez) about the art of development in the current age. I agree with some points, specifically that in many cases, multiple developers work for their whole work life on boring/marginal activities. One of them, IMHO, is the entire front-end effort in developing web-based applications, a development task that nowadays could be broadly and proficiently managed mainly via AI to reduce human intervention to minimal parts and architectures.

Many mid-to-large-size companies aim to produce and maintain software systems thanks to interchangeable average-level personnel who work on well-known and established tools. Too many creative and original approaches are banned from the start. The average developer must represent a little gear in the whole system, nothing too essential for creating and maintaining the products and services. Let me call it the standardization of the development process, which is conceptually an entirely creative process and, therefore, original. Indeed, the core goal is moving from crafting to industrial design, which does not necessarily imply achieving better quality but other objectives, such as the right timing to market, cost optimizations, etc.

The result can be a mass of frustrated professionals who have very few alternatives but to escape and continuously try to find better companies. Passionate people find a compensation valve in FOSS projects for being paid to work on lousy legacy code bases for their entire professional lives, company after company.

In some regards, it is not that different if you work in IT for the academic domain, where often the only code you write is a proof-of-concept, just to perform some quick-and-dirty experiments before relegating it to the trash and moving on to the next project. Thesauring the code developed in years, making it better, clean, and helpful for a reference community, and building on it a whole ecosystem is not so common in many academic areas. Often, the code per se is pure garbage for intrinsic quality, often produced by students who are only around to learn and escape with a degree and minimal effort. Sometimes, this is done by scholars whose main interests and backgrounds are not in coding. The big difference is that in the enterprise world, there is no trash, only do-not-touch repositories with (almost or pretending so) working code to preserve.

Very few are interested in perfect coding, solving stimulating problems or providing new conputng approaches.

Unfortunately, the average code quality is not the only problem based on my experience. As a typical user and citizen, I often have to use digital systems of public administrations that seem created by a group of drunk monkeys, with a terrible UX and that often, instead of genuinely simplifying the tasks, overcomplicate them and require more time and manual work that any respectable user could solve alone with a piece of paper and a pen. Sometimes, the digital system solves the wrong problem (sort of finger-and-moon syndrome), the documentation and the systems are completely disconnected, or things change for the worse over time, and so on.

During my professional life, I had some enterprise consulting periods, and I experienced precisely the main reason for that, IMHO. Inevitably, developers and end-users are totally and definitively disconnected during the development and the lifetime of software systems. Even if, in theory, the enterprise assigns internal human resources for analysis and design, those people have literally no idea of what they are dealing with because they are not the true average end-users. The results are systems and subsystems developed based on partially incomplete and often missing or misleading specifications. Developers with deadlines have to invent all the missing parts and work with their own capacity (if any) to understand the application domain and cross their fingers. Literally, the whole agile design, in many cases, is based on a trial-and-error basis, but with no one who is genuinely able to say if the result makes sense for the end-users and the processes already adopted in the target customer enterprise or user community — a sort of dialogue between blind and deaf-mutes. Try to imagine the results when developers are temporary workers whose only main goal in life is escaping from that bad-ass consulting company.

In the case of public administration digital services, the final result is a big f*k! exclamation when the end-user (you!) discovers the final UX of the new system during every new release. Just after learning the intricacies and idiosyncrasies of the system in version N, you find out that version N+1 is even worse, only with a different set of idiosyncratic features to learn to dive again and again.

About the enterprise, the bigger the company is, the bigger the disconnection between developers and the end-users, with a unique taste for autoreferral management of new features and bugs. If you connect this problem with strictly deadline-based development, reduced attention to code quality, and demotivation of the developer teams, you get a lethal combination for the final results.

FOSS development was born to re-connect developers and users in a single well-linked community, where the developers can have a direct idea of what features make sense, what changes are due, what the main bugs are, and so on. FOSS developers are often passionate people who pay great attention to details and code quality, with no deadlines but those dictated by the general quality of the result.

Enterprises nowadays have often adopted FOSS as a mainstream license but never truly gained the unified-community-driven spirit. The result is, again and still, the usual sh*t. No diamonds around, damn it.

Are distributions still relevant?

2024-07-29T20:00:00Z

In principle and the traditional vision, the roles were clear enough. Upstream developers had to create and support their own projects, including multiple libraries, tools and modules, possibly for multiple operating systems. Distribution maintainers had the responsibility of collecting a significant software set, porting on various architectures, choosing versions that work well together for each piece of software, patching for coherence and well-established policies, eventually providing a build and installation system for the end users. At the end of the day, a quite complicated and articulated work that many people out there do for fun, others as a full-time job.

Some distributions have been around since the beginning of the 90s and still release new versions regularly, including Debian GNU/Linux, an ecosystem where I have lived and collaborated for almost 25 years. That was an ideal workflow, managed differently and with diverse goals by multiple non-profit associations and companies, including the Debian project. Distribution aimed to have the most stable and affordable daily-use system, especially for servers and enterprise ecosystems.

That was until 15 years ago or less, when virtual machines and later containers changed the games and the whole cloud computing revolution started. In prospective, that has not been the only driver for the change. Another important aspect has been the great relevance that dynamic languages and their ecosystems assumed during the same period.

The new world of hubs

Hubs, hubs everywhere and for anyone. For programming languages, as well as for containers and virtual machines. Starting from Perl and its CPAN archive, all currently used languages have their own ecosystems of packages/modules hosted on some third-party delivery networks. Most modern applications are based on the distributed efforts of thousands of developers who create and maintain thousands of tiny or large modules to solve some very specific goals, which inevitably live in their respective language hubs.

Your latest applications, almost for sure, could only exist thanks to dozens - or hundreds - of include/require/use clauses written in some of the prime-time dynamic languages that currently ride the wave of popularity. Sub-modules that are often developed by small independent teams or even single developers, packages that are mostly open source and come with no warranties for their use and destination.

Hubs for developers

In recent years, developers learned to distribute their own laptops with their applications: let me simplify. Instead of creating minimal, well-engineered traditional packages for some target platforms and eventually installers, we are now distributing container images on some cloud computing resources with all required software piled up within them. If those images are based on Docker, Podman, Lilipod or Apptainer it is absolutely secondary. Often, most applications are written in a dynamic language and install gigs of dependency modules and libraries (often in multiple versions) altogether. Giant software blobs stacked on top of some very tiny operating system layer. All that started from continuous integration platforms for testing and development and exploded in a plethora of subsystems and tools used for deployment to the end users.

Hubs for end-users

Talking about common users, thanks to new container-based systems thought for that - such as flatpak, snap, or appimage - even ordinary users can now use programs that are not more strictly dependent on distribution package managers. Those are the equivalent of Windows installers in the Linux environments for end-users. Installing new programs or sub-systems is now simplified: no building from sources, backporting and other more technical workflows. Just install and update the latest product, kindly made available by multiple upstream teams, in terms of some containerized image with only a minor runtime overhead.

It seems like a new ideal development and user world for Linux ecosystems, at least apparently. Probably it is so for advanced and self-aware users, but ...

I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened (Obi-Wan Kenobi).

The splintering of the Linux ecosystems

The Linux ecosystem has always been extremely fragmented from the point of view of a Windows (or Macos) user. There are too many distros, too many desktop environments, and too many programs that often do almost the same things, but differently in some regards, always in the name of freedom of choice. However, all this is nothing in respect with the future. Distributions are going to be always less and less relevant for running applications in the cloud and even on the user's desktop. For instance, in the case of Ubuntu and many derivatives distributions, even a big part of the desktop system is now based on snap, and its Ubuntu-specific containerized hub. Soon, all distributions could become very compact core systems with most of the system applications moved onto multiple external hubs with different frequencies of update.

Who is responsible of the whole supply chain?

At the moment, one of the main challenges for the security of applications - that have become more and more complicated and dependent on a plethora of different third-party software - is certifying the whole supply chain. A software bill of materials is nowadays required in multiple contexts, but guess what? A splintering of the whole software stack management responsibility among multiple third-party hubs, development teams, and end-users is a game changer. As a user or developer, you will be directly responsible for updating all your applications and keeping them stable. Not more your distribution, but you. Most hubs do not have clear, well-established, and just-in-time policies for security updates. In most cases, it is a task to be managed by every development team in order to re-collecting all required pieces - in a consistent way - and rebuilding containerized images when needed.

Sure, there are continuous integration workflows available in some cases. Still, I don't know so many application teams that are seriously interested in timely reacting on security reports, starting from some obscure CVEs, patching, updating multiple source trees and even ensuring to not break anything by accurate testing platforms. A grunt work done by distribution secteams until now.

Even if basic container images were bricks accurately managed and updated, the final build and deployment of application images is a different matter, and while the current approach could be helpful to have the most recent software installed for the end-users desktops, I'm pretty sure that most of the thousands of embedded devices that now populate our homes are in pathetic conditions for security. Many of them have opaque and short-term supports, and the use of multi-hub sources can only render the whole thing worse: we all are potentially living with multiple little time bombs permanently connected to the net.

This has been so since the very beginnig in the embedded environments, now we are changing the things in the same way for desktops and cloud applications.

Once you start down the dark path, forever will it dominate your destiny (Yoda)

We live in interesting times...