The Blog of Thomas Depierre, Elixir and DevOps consultant.
I am a skeptic of the utility of LLM in software development. It is not because of IP laws problems (even if they are highly problematic), nor is it for ecological and ressource comsumptions reasons. It is not even for “they are all crap” reasons. My problem with LLM Coding Assistants is that I cannot see, in the face of the scientific evidence, how they can help someone write code better or…
In the OpenSource Supply Chain discourse in the past few years, we got many versions of the same article. The title is usually something like “unpaid maintainer of library X demand Big Company to shut up or pay them money”. There are variations on that theme, like Github Sponsors launching, pieces that explains how the CRA will magically make companies pay maintainers, etc. It is usually cheered…
I regularly comment on the Internet on my views on most schemes proposed to fix FOSS problems. They are mostly negative. I think that most of these schemes cannot achieve any meaningful impact. It seems that most of these disagreements come from the fact that I seem to work on different models of how FOSS work. Over the years, I have tried to share parts of my model. This is part of this endeavor.
For quite some time, I have felt some unease at the public discourse around OpenSource. In the past few years, we have seen a growing discourse around the sustainability and security of the large body of OpenSource software.
There is a term that is on a lot of lips lately. “Memory Safety”. The theme of the early 10s for software security is “Move to memory-safe languages”. You hear and see it everywhere
When you hear that one of the vendors responsible for keeping government organizations safe had a security breach, you can easily decide that this is unacceptable. When you hear that it is hard to know who is affected and how much, you may start to feel a bit panicked. This is bad; it would be far better if it never happened.
We look at the world and make decisions for our actions through models. Depending on the context, some models will be more fruitful to apply than others. There is a model that I have found tremendously helpful, in particular, when discussing “open source supply chain” but also more regularly as an SRE. I dub this model Goals/Capability/Constraints. It evaluates action far differently than most…
Recently, PyPI announced that they would force everyone that maintains a project or an organization on the platform will have to enable 2FA. This is one more step in the direction of strongly protecting the package providers and their users. I am not opposed to it. But it made me think of the discussions we have around FOSS about reciprocity and unfair burden1. And about double standards. And how…
It would be a major boon to software velocity, maintenance burden and safety to bring more attention to developer tooling, in particular bringing to everyone’s toolkit the techniques and technologies developed since the 80s but that was never mainstreamed. It is at least what I advocated for in We Need More Process Engineering in Software. Over the past few years, I have explained to a lot of…
When you peruse the depth of software engineering as a discipline, you find a lot of techniques and tools laying around in corners. Pattern matching, tighter type-checking compilers, property-based testing, snappy IDE, debuggers, dynamic tracing, Result types, effect handlers, capabilities, model checkers, fuzzers, etc. And yet, they are not in use in the industry. I posit that this is because…