But at one point in the email, a question appeared - one that has become a recurring theme in the modern software world: "I notice there haven't been any new releases for about ten months. Should I consider the project abandoned?"

I decided to reply immediately: "No, it’s not abandoned. But it satisfies all my requirements, so unless there are bugs or new needs, I consider it 'complete'."

The person’s response was telling: "What do you mean by complete? Software is either in active development or it's abandoned. I’ve never heard of 'complete' software."

I started reflecting on how the very ideal of "completeness" has totally vanished from our lives. And on second thought, I wasn't surprised.

This doesn't just apply to software; it permeates every corner of our modern existence. There was a time when you bought a car, you owned it. Today, almost everyone leases or uses financing with a final "balloon" payment - often so inconvenient that people find themselves taking out a new loan after just a few years. The result is that we never truly own our cars, and they are constantly plagued by automatic software updates that, in some cases, break things that previously worked just fine.

When we bought an appliance, we installed it. Barring a breakdown, it stayed exactly as it was for the rest of its (often long) life. Today, an immediate software update is mandatory the moment you plug it in. Fail to do so, and essential features won't work. A modern washing machine often comes with only two or three built-in programs; the others must be downloaded from the "cloud" - sometimes for a fee. If you don't, you can't fully use what you already paid for. I don't wash my clothes the way I want anymore; I wash them the way the manufacturer’s questionable cloud dictates. And this continues only as long as the manufacturer decides I am allowed to wash my clothes at all.

Before everything was "always online", the concept of complete software was common. Yes, new releases happened from time to time, but they weren't taken for granted, and sometimes years would pass between them. The premise was clear: software was released to solve a specific problem. Distributing updates wasn't easy, so it had to be reliable from the very first release. It couldn't come out riddled with bugs - that would have meant a loss of face (or even bankruptcy) for the producer.

When a new release or a new product did come out (be it software, an appliance, or a car), the manufacturer had to entice the user by focusing on what was actually new - on what new problem it would solve. Consumable goods eventually need replacing, but for durable goods, the battle for the customer's attention was more complex. I remember buying many books, VHS tapes, CDs, and DVDs during sales, and then spending the following months reading, listening, or watching them. The beauty of today's streaming is choice. The tragedy is that the moment we stop paying, we are left with nothing.

The "disposable" has become the norm for everything. Quality has plummeted - even in our relationships - because we are always searching for something "new". And yes, I say "we" because I include myself in this chase for dopamine - that intense, albeit brief, pleasure of something new. Even when there is almost nothing new about it. Even when I didn't need it.

Just as with my relationships, I like to take care of my things. Making my wife laugh, sending a message to a friend, painting the house. Sometimes I rescue old objects and give them a new life. Behind me sits a cabinet - I bought it for next to nothing, and it's incredibly useful. Ten years ago, with some hours of work, I completely restored it. It’s beautiful, sturdy, and perfect. It had been thrown away by someone who considered it old and outdated, only to replace it with a fragile piece of furniture from a well-known chain. To each their own, sure. But taking care of what you own is an act of respect.

I replied to that email. Yes, the software is currently complete. I will take care of it. I will ensure that bugs are fixed. And if I ever have new requirements, I will resume development. But as of today, it has solved my problem and it works excellently. Why should I add useless "stuff" just for the sake of expanding it? For whom? For what? I gain nothing from it. I don't have to sell it. And even if I did, I would rather sell an effective, working product than a constant, never-ending process of fixing something that is perpetually buggy and incomplete.

Not "continuous integration", but "boring software" that does its job.

And this is perfectly aligned with my business ethos: I would rather stop growing indefinitely and take care of my current clients than start hiring incompetent people just to make numbers and provide a service that doesn't meet my expectations.

Just like in the IT world, I am convinced that you can usually solve much more with a direct conversation than with a thousand intermediate steps. Too many layers, even if theoretically sound, just complicate things.

And this is one of the reasons I've always tried, as much as possible, to avoid overcomplicating the relationship with my clients. It's why I have always sought, as much as possible, to engage with businesses where I can speak with people, not "offices" or "departments".

Take the example of the roof repairs on my house: I spoke with the people who did the work. They did an excellent job and even fixed things I hadn't mentioned because, in their words, "a satisfied customer is a customer who will call back". A few days earlier, "large, structured" companies had sent completely different quotes without even looking at our roof. "The people we send will assess it then, but we'll instruct them to do what's in the quote". It was schematic, inflexible. Probably efficient from their point of view, but not from mine. Replaceable by AI? Of course: X square meters of roof, Y job, Z per square meter -> cost is €W. Without anyone truly caring about what my roof might actually need.

For this very reason, I dislike talking to salespeople. It's one thing when I'm buying a product (with verifiable features, etc.), but it's different when I'm buying a service or a consultation. Salespeople do their job, which is to sell. And they try to sell what they don't have, what they don't know, and what I don't need. The better they are, the more they sell me things I don't need. And, frankly, I don't like that very much.

This is why I prefer to talk to the person who actually provides the service. The one who gets their hands "dirty". But many people love to create a structure, an abstraction. Even when it's not necessary.

A few days ago, I identified an open-source software solution with two versions, a "community" and an "enterprise" one, but it still seemed approachable. I quietly started running some tests and realized that this solution might be suitable for offering some new services to both current and new clients. Something new and innovative, yet consistent with my philosophy. As I often do, I did some research on the company behind it. I discovered it was a tiny company with extremely low revenue - so low that my contribution could, at least in part, help it grow. Not because my business would be huge, but because it could provide visibility in a market where they currently have no presence. Noticing how few people were in the company, I decided to contact the dev/founder/CEO directly.

A human connection, to understand the project's direction, to see if it was the right fit for my needs, and to potentially fund the development of features I was interested in. I would also explain that, given the cost and my trust in the product, I would use the "enterprise" licenses for my clients, bringing further revenue to their business.

As I often do in these cases, I proceeded on two fronts: I opened a support ticket asking about the status of support for a specific operating system, and I sent a private message to the dev/founder/CEO on one of the platforms where the company is active, briefly explaining my idea.

After a few minutes, the private message was declined (I'm not even sure if it was read), and the ticket received a terse reply, something like "that OS is not officially supported". Period. They didn't even get to the next part, the one where I would have funded development and provided my clients with the enterprise version.

This kind of shutdown is disheartening. Of course, not every startup thinks this way, and the search for a scalable business model is perfectly legitimate. But when exponential growth becomes the only metric for success, the value of the customer and the product gets lost in the process.

It's not the first time, and in different forms, I notice a fairly common pattern nowadays: a certain market just isn't of interest. They want massive clients - or they'd rather shut down the project. It's not a mindset of "hey, I have an idea and I want to build it", but rather "how can I make mountains of money in a short time? Let me find an idea that might work". Why does everyone dream of being the multi-million-dollar startup with a product that "disrupts the market", while giving up on a healthy, organic, clean path of gradual growth?

It’s as if success has been reduced to a single metric: financial gain, where the ultimate satisfaction is purely economic. Betraying your own principles - or the trust of the customers who got you there - doesn't matter. Building a business has become a kind of checklist. The original idea, the founder's spirit, the unique tenacity - none of it matters as much as just following the steps: chase the current hype, promise the world, and do whatever it takes to get to the next stage.

All or nothing. Either you're Elon, or you're a nobody. I recently witnessed a similar situation with one of my clients. Their business was doing well, growing linearly and steadily. They were well-regarded in their market, competent, and valuable. But at a certain point, I saw their best developers leaving due to "disagreements over company policy". I've stayed in touch with many of them, and they explained that they were becoming mere cogs in a machine. In my next meeting with the owners, they told me that their business would be winding down, potentially even closing. "Why? It seems like things are going well!" Their response: "Yes, but we didn't dominate the market. The profits and growth are good, but not exponential. We need to find a new idea, hoping this time it's the game-changer".

Going back to the software, I simply wrote it off. I realized I can't trust the product or the company. They lost a good opportunity, but maybe they don't care. Their primary goal isn't to sustain their product and their idea. They are just developing something to make a lot of money. If they succeed, they'll sell it to the highest bidder (who will then likely perform an enshittification on it just to monetize as much as possible). If they fail, they'll abandon it and move on to something else.

I'll move on to something else - perhaps less suitable, but something that gives me more guarantees of continuity. Because in my mind, there are still figures like Federico Faggin - who left Intel to found his own company, Zilog, because he wanted to continue working on processors when, for Intel, they were just a tool to sell more memory. And there are countless examples like that, of people who had an idea and wanted to extend it, expand it, and then, why not, make money from it. When I witness the opposite - the idea that the goal is a huge, quick profit and the idea itself is secondary... well, I move on.

Not my cup of tea.

Gradually, things changed. Over time, minimalism took hold. "Less is more" became the mantra in many sectors. We saw it in electronics (a philosophy Apple rode to great success), in interior design, in construction, and in architecture. We got low-impact homes and devices that were ever more powerful yet consumed less and less energy. And yet, in the one field that should embody efficiency and logic more than any other - computing - the exact opposite seems to have happened. We've progressively made things more complicated. Simple tasks, like hosting a website, have become, in the eyes of many, jobs that require complex and heavy stacks - stacks that consume resources and electricity just to get the base system running.

Operating systems are becoming increasingly complex, bloated, and packed with features that are useless to most people. Even the Linux world, which was often born under the banner of modularity and lightness, has in many cases followed the same trend. Just think of modern web stacks that, even on Linux, require containers, orchestrators, and complex build systems merely to serve a static page.

And that's why I've decided that my blogs, at least for now, will be hosted entirely on a VM that costs 1 Euro per month. By using efficient operating systems (like NetBSD, in this case), it's possible to run the whole setup with excellent performance on very few resources.

This isn't a matter of necessity - I have powerful, underutilized servers at my disposal - but a matter of choice. It's a small act of computational minimalism. I want to demonstrate, just as I have done and am still doing with FediMeteo, that you don't need to invest in extreme resources, powerful (and expensive) hardware, and complicated stacks to perform simple tasks. Tasks that today, for whatever reason (that's a rhetorical question, and the answers range from commercial interests pushing new solutions for already-solved problems to curriculum-driven development), are instead handled on oversized infrastructures.

As I like to say, it's like needing to buy some salad from the shop down the street, but instead of walking, cycling, or, at most, taking your car, you take a semi-truck.

Sure, it works.

But it makes no sense.

Like OpenBSD from NetBSD, DragonflyBSD from FreeBSD, or Nextcloud from Owncloud - the examples are endless. It was about freedom, the chance to be part of something or, in some cases, at the very center of something: its development.

To me, Open Source meant having the chance to develop an idea and find other people who shared it, turning what was just a project in my mind into a reality. All without needing big funding, a business plan, or having to risk anything. Just the pleasure of doing it and the joy of seeing it come to life. A waking dream.

Over time, I witnessed many exchanges of opinion - some of them quite heated - that led to hard forks or uncomfortable situations within development teams. People leaving, others taking over - you name it. But, in the end, the software was always at the center. It was an ideological battle over how to implement something (or how NOT to implement it).

This led to some fantastic pairings: Linux, a kernel without an operating system, and GNU, an operating system without a stable and complete kernel. Together, they revolutionized the world, changed the concept of computing, and proved that yes, Open Source works and produces quality software - often of a far greater quality than many of its closed-source, commercial counterparts.

And yet, there were the "distro wars" - and I didn't understand them. And if I didn't understand the distro wars back then, the situation today seems even more extreme. I appreciated the variety, the different ideas, and the different approaches, but never the fanaticism. I was a strong supporter of Debian, but I couldn't understand those who openly attacked alternatives (like Red Hat, at the time, or Suse). I thought: use what you like, contribute if you want but... hey, it's Open Source, you don't pay for it, you're not forced, just choose what you like best! If you're happy, tell the world. If you're dissatisfied, switch (to different software) or change THE software (meaning, implement what you think is necessary). But why wage war on others, on those with different ideas who made different choices? Is it the general polarization fueled by social media? Is it because Open Source has become more mainstream, bringing with it users who have a "consumer" mindset rather than a "collaborator" one?

And yet, there are still positive examples out there — quiet, solid, and often overlooked. The BSD projects, for instance, show us that it's still possible to diverge in philosophy and approach without descending into hostility. FreeBSD, OpenBSD, and NetBSD took different paths. And yet, there are no "wars" between them. Their communities may disagree on technical choices, but they coexist with mutual respect. You rarely see a FreeBSD user shouting "OpenBSD must die!" or a NetBSD developer trolling others on social media. The tone is sober, the work is steady, and the focus remains on the code and its quality - not on brand wars or personal egos.

This is the spirit I fell in love with: different ideas, mutual respect, and the shared goal of building something useful and free. We may not all agree on everything, but we can still build in parallel, learn from each other, and avoid turning diversity into division.

Lately, all of this is becoming truly extreme. I read, for example, sharp and violent opinions from Wayland users against X11 (Xorg, etc.) - "it must die!" But, I wonder, why this violence?

I use Wayland on Linux and X11 on FreeBSD - both on the same computer, both with satisfaction. Why should I hate one of them? If I don't like it... I simply don't use it.

The world is becoming increasingly polarized and bitter, making people less and less inclined towards dialogue or tolerance for those with different ideas or positions. But, I ask myself, why should this be happening in the world of Open Source?

We are all in the same boat. We have the tools, the freedom of choice, and it costs us nothing. If we don't like a solution, we can say so and choose something else. Why this violence? Cui prodest? Who benefits?

When we fight violently over Open Source software, when we lash out with intolerance against a solution we dislike, the entire Open Source world loses an opportunity. The opportunity to reduce the chances of ending up in a computing monoculture, the opportunity to have a choice, the opportunity for someone to listen to our well-reasoned observations and learn from them.

It's up to us, every day, with every comment and contribution, to decide whether we want to build bridges or raise walls.

Classical Style

Typical Reaction:

"Too ornate! So outdated! Nobody wants this old-fashioned stuff full of frills anymore!"

"Look at all these useless objects! It's so... maximalist!"

"Impossible to keep clean! Who has time to dust all those details?"

Minimalist Style

Typical Reaction:

"So elegant! Modern and functional!"

"True beauty lies in simplicity!"

"Finally a space where the mind can breathe!"

WEB ARCHITECTURE

Simple Traditional Stack

┌───────────────┐
│    Browser    │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│    Firewall   │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│   Web server  │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│   HTML/CSS    │
│     Files     │
└───────────────┘

Typical Reaction:

"Too simple! That's so 2010!"

"Not scalable! How do you handle thousands of users?"

"Where's the DevOps? And CI/CD? What about serverless?"

"It's not resilient/reliable/cloud-native enough!"

Complex Modern Stack

┌─────────────────┐    ┌─────────────┐    ┌──────────────────┐
│    CDN Edge     │◄───┤ DNS Manager ├────┤ DDOS Protection  │
└────────┬────────┘    └─────────────┘    └──────────────────┘
         │
         ▼
┌────────────────┐    ┌──────────────┐
│  Load Balancer ├────┤ Auto-scaling │
└────────┬───────┘    └──────────────┘
         │
         ▼
┌────────────────┐
│     Proxy      │
└────────┬───────┘
         │
         ▼
┌────────────────┐    ┌──────────────┐    ┌──────────────────┐
│   Kubernetes   ├────┤ Service Mesh ├────┤ Circuit Breaker  │
└────────┬───────┘    └──────────────┘    └──────────────────┘
         │
         ▼
┌────────────────┐    ┌──────────────┐    ┌──────────────────┐
│  Microservices ├────┤Message Queue ├────┤   Redis Cache    │
└────────┬───────┘    └──────────────┘    └──────────────────┘
         │
         ▼
┌────────────────┐    ┌──────────────┐    ┌──────────────────┐
│      API       ├────┤ Auth Service ├────┤  User Service    │
└────────┬───────┘    └──────────────┘    └──────────────────┘
         │
         ▼
┌────────────────┐    ┌──────────────┐    ┌──────────────────┐
│    Database    ├────┤   Sharding   ├────┤  Backup System   │
└────────┬───────┘    └──────────────┘    └──────────────────┘
         │
         ▼
┌────────────────┐    ┌──────────────┐    ┌──────────────────┐
│   Monitoring   ├────┤   Logging    ├────┤    Alerting      │
└────────────────┘    └──────────────┘    └──────────────────┘

                * To serve a text page with 5 users per day *

Typical Reaction:

"Such an elegant architecture! So professional!"

"Finally a modern, well-designed approach!"

"This is the right way to do things today!"

"Excellent cloud-native implementation! Beautiful diagram!"

The Contradiction

• In interior design: "Less is more! Simplify!"

• In web development: "More is better! Complicate!"

Does a simple landing page really need Kubernetes?

Conclusion

Perhaps it's time to reassess what "modernity" truly means and consider the real purpose of what we're creating.

I stumbled upon an email from an old friend I had lost touch with around that time. That email is the last trace I have of him - in which we promised to catch up soon - so I decided to reach out. Instinctively, I searched on Google, social media, etc., but found nothing. He wasn't tech-savvy, so I wasn't surprised. The only lead I had was this email address, which I had set up for him on a free mail server he used for school.

I decided to give it a shot. I replied with a simple line: "We promised to catch up soon. Is 25 years long enough? :-)" - fully expecting the email to bounce back as "unknown recipient" or "mailbox full" (of spam).

No errors. To my immense surprise, two hours later, I received his reply: "After 25 years, one email isn't enough; we need to meet for at least two days. We have 25 years of life to catch up on."

Here's the reflection that struck me: after 25 years, I could read and reply to an email without a hitch. The open and decentralized standard of emails ensured its longevity and compatibility.

What would've happened if all I had of my old friend was a "PIN" from BlackBerry Messenger? Or any other proprietary and closed communication tool, perhaps now defunct or bankrupt? Take, for instance, Adobe Flash. Once the backbone of interactive web content, it's now almost unsupported. Countless creative works, animations, and interactive experiences crafted in Flash face the risk of vanishing, becoming mere digital memories.

In light of this, it's essential to understand the value of open standards. Throughout history, open standards have proven to benefit users by ensuring accessibility, longevity, and compatibility. Whether it's the HTML that powers the web or the SMTP protocol for emails, they stand the test of time and evolve with our needs, ensuring that our digital footprints aren't lost to proprietary systems.

Are we truly certain that, in 25 years, WhatsApp, iMessage, Telegram, Discord, Slack, etc. will still be active and accessible?

In an era where control over information and data has become central, it's even more crucial to rely on open, decentralized, interoperable standards.

More Matrix and less Discord, more Fediverse and fewer closed social networks, more Mastodon and less Twitter (or rather, X).

News from the past months: "Libero and Alice's emails are not working. They have not been working for days and will resume as soon as possible." Everyone is outraged - I understand - but in fact, seeing the level of advertising, spam, and the like, I would say it was clear that the two services were no longer being managed "impeccably".

News appeared in the same period, Microsoft had problems, so Outlook, Teams, etc. had serious disservices for hours.

Even Facebook, Whatsapp, and Instagram had serious problems in the past. And these are all services that lose millions of euros for each minute of downtime.

Yet today, in the interconnected world, a disruption in connectivity or service is seen as a tragedy.

I've been managing servers for so long that a child born when I put my first services online could have graduated and had children of their own. My first server was archived by the Wayback Machine in 2002, but it's at least a year older. Some colleagues I work with daily were born after my first server.

Yet today, like never before, a stop of a service (even outside of business hours, even if planned, even if the service is not needed at that moment) has become unacceptable.

Every morning a system administrator wakes up and knows that they have to race against time to patch, check, and reboot services before a vulnerability can hit their system. Every morning a user wakes up and will have to use the service just in the few seconds in which the system administrator is rebooting it. Even if the system administrator had warned that they would reboot the service at that time, causing a "few minutes" of interruption. Even if the system administrator got up at 4 in the morning to do it. Even if the user, at 4 in the morning on Sunday, usually sleeps.

The Network is made of interconnected components and only parts of it are controllable. It can happen that something jumps: a service provider, a backbone, an external dns. We have to learn to accept that something, sometimes, may not be fully efficient.

When you have a physical store, there can be a power outage, water, gas, a flood, road work... why can't what's online be idle for a minute every 6 months, if announced? Or an hour every year, if there is an unforeseen problem?

The promises of the "cloud" have led everyone to believe that 24/7 always and anyway exists. But no, it actually doesn't exist and the more complex the infrastructure, the more parts can break. And the promises of "always online" are often drowned in terms and conditions with very limited liability in case of breach.

Better five minutes offline today than an attack tomorrow, with the relative risk of leakage of personal data.

The operating systems are different, the question is the same, and the outcome is identical. To better understand why these operating systems haven't dominated the desktop market, it's helpful to examine the evolution of the tech industry over the past few decades. While the desktop market has always been dominated by giants like Microsoft and Apple, Linux and FreeBSD have found their success in other devices and platforms.

Anyone with an Android phone effectively has Linux in their hands. Android is based on the Linux kernel, and thanks to its immense popularity, has brought Linux into the pockets of billions of people worldwide. Likewise, anyone with an Apple device, such as an iPhone or a Mac, has a BSD "heart" inside, since macOS and iOS are based on the XNU kernel, which in turn is derived from BSD. Sony's Playstation also has a FreeBSD base, and even Windows itself, with the Windows Subsystem for Linux (WSL), has (partially, in a way) embraced the Linux-related world, enabling easy use on all PCs.

The market pushes what is demanded, and there has never been a real demand from any "big player" for "pure" Linux/FreeBSD/etc. on desktops. The desktop market, like the mobile one, is dominated by a few big players (such as Microsoft and Apple), and the average user is not knowledgeable enough (and, in the future, will be even less so) to fully understand the advantage of using a free, expandable, non-obsolete system without planned obsolescence.

Furthermore, the adoption of Linux/FreeBSD on desktops is hindered by the lack of support from hardware and software manufacturers. Many popular applications and games are developed exclusively for Windows and macOS, making it harder for users to switch to Linux or FreeBSD. However, in recent years, the situation has improved thanks to the introduction of portable tools, which allow running Windows games on Linux, and the increasing support for open-source applications.

Even if the desktop market may never be dominated by Linux or FreeBSD, their presence in other sectors provides users with the freedom and flexibility that these operating systems promise.

In conclusion, the year of Linux/FreeBSD on desktops may never come, but their widespread presence and impact on the technological landscape are undeniable. These operating systems will continue to play a crucial role in the evolution of technology, providing innovative and flexible solutions that adapt to the ever-changing needs of users and businesses.

IPv6 (Internet Protocol version 6) is the latest version of the communication protocol that manages Internet traffic. Its main difference from the previous version, IPv4, is the use of a 128-bit IP address, compared to the 32-bit IP address used by IPv4. This means that IPv6 can support a much larger number of IP addresses than IPv4, which proved inadequate to meet the growing demand for Internet connectivity. However, the transition from IPv4 to IPv6 has been slow and gradual due to compatibility with the old protocol and the need to update existing network infrastructure.

For over 20 years, the adoption of IPv6 has been a hot topic in the world of networks. Despite a steady growth, we are still far from full support for this new generation of IP addresses. IPv6 promises greater efficiency and scalability, but its adoption is hampered by a series of challenges and resistances.

One of the main difficulties in adopting IPv6 is the change, at least in part, of the network concept. This requires a deeper understanding of how it works, but once the mechanism is understood, it is more logical and practical than IPv4.

In addition, IPv6 challenges the beliefs of many "technicians" who for years have considered NAT as protection for the local network (it is not). LAN security is not guaranteed by simply "being behind NAT." Many "technicians" disable IPv6 as their first operation because they believe it can only cause problems, while in reality, what is lacking is proper knowledge of IPv6 management.

Meanwhile, IPv4 addresses have run out, and the few available on the market are sold at high prices. Providers like Hetzner and OVH have also increased their prices for IP addresses, affecting management dynamics. IPv6, on the other hand, is more efficient and suitable for the modern interconnected world, offering a virtually unlimited number of addresses.

However, IPv6 introduces new issues, such as the direct reachability of all devices through direct routing (without NAT), making the firewall even more critical in managing network security. It is necessary to better understand the dynamics of networks and subnets, and given the number of digits in IPv6 addresses, it is almost impossible to remember them by heart.

Today, all my devices are connected via IPv6. When I do not have direct support (such as in mobile connections), I use a Hurricane Electric tunnel or, if impossible (due to the lack of a public IPv4), a WireGuard connection to an external VPS capable of performing Nat66. I have created a ULA to still allow direct connection to public IPv6 addresses.

Unfortunately, many operators still do not fully understand the functioning of IPv6 and the number of addresses available. By assigning "only" a /64, they limit the possibilities of use, while a /48 or a /56 would allow the creation of numerous /64s, facilitating the use of SLAAC for connected devices. Operators likely fear repeating the mistakes made with IPv4 when large amounts of addresses were assigned, leading to the current scarcity. Fortunately, IPv6 has such a vast number of addresses that we should not worry about similar problems, even in the case of massive waste.

To accelerate the adoption of IPv6 and take advantage of its benefits, we must push for it to be implemented extensively and as quickly as possible. It is crucial to learn how to use it correctly and abandon the old (often wrong) criteria related to the technical limitations of IPv4. In this way, network quality will improve, optimization will be more effective, and everyone will benefit.

It is essential to overcome the resistances and fears associated with IPv6, adequately train technicians, and continually update ourselves on new developments. Only in this way can we ensure a more efficient, secure, and sustainable future for our networks and connected devices.

The Server is Full, Add more Space!

Even if there are tens of gigabytes of useless logs. Even if there are tens of gigabytes of useless stuff, left on the server just due to inertia.

Recent innovations in the field of hardware resources have generated devices with increasingly high performance, higher memory capacity, and reduced energy consumption. This trend has enabled the development of applications and services that were unthinkable until recently. However, a dark side of this progress concerns the decline of software optimization.

Optimization is no longer a priority

Technological progress has led to a context where powerful and accessible hardware has become the norm. As a result, developers no longer feel the urgency to optimize their software. In the past, when resources were limited, optimization was a necessity to ensure the proper functioning of applications and to avoid wasting resources. Today, developers tend to focus on other priorities, such as implementing new features or improving the user experience. Optimization doesn't matter anymore. The solution, for them, is always to resort to more powerful hardware.

The decline of software optimization has several negative consequences:

• Energy consumption: Unoptimized applications consume more energy than optimized ones, contributing to a greater environmental impact. The growing concern for climate change makes this issue particularly relevant.

• Resource waste: When developers neglect optimization, applications use hardware resources inefficiently, wasting disk space, memory, and computing power. This waste translates into higher costs for users, who may be forced to upgrade their hardware more often than necessary.

• Reduced performance: Unoptimized applications can cause slowness, lag, and crashes, compromising the user experience and productivity. Moreover, less recent hardware may not be able to properly run these programs, limiting access to a portion of users.

• Security and stability: Unoptimized software may have security vulnerabilities or bugs, exposing users to potential risks. In addition, unstable applications can cause data loss or compromise system integrity.

• Maintenance and updates: The lack of optimization makes it more difficult and expensive to maintain and update software, as developers must deal with more complex and disorganized code. This can lead to delays in releasing patches and new features.

To reverse this trend and ensure a more sustainable and efficient future for the software industry, it is crucial that developers recognize the importance of optimization. Below are some steps that can be taken to promote positive change:

• Training and education: Teach programmers the importance of optimization and provide them with tools and techniques to implement it from the beginning of the development process. It often becomes difficult, especially for us "adult" system administrators, to explain to those who are not used to the physical limits of hardware but believe that the cloud has "infinite resources, just pay more." However, we must do it, otherwise, we will be the ones to answer when the server is slow or, worse, full.

• Standardization and best practices: Promote the adoption of standards and best practices that guide developers towards a more efficient approach to software creation.

• Benchmarking and metrics: Use tools and metrics to evaluate software efficiency and compare it with competing solutions, thus encouraging continuous performance improvement.

• Incentives and recognition: Create awards or incentives for companies and developers who commit to producing optimized software, publicly recognizing their efforts.

The abundance of low-cost hardware resources (at least in appearance) has led to a decline in software optimization, as developers no longer consider it a priority. However, it is possible to reverse this trend through training, the adoption of best practices, and the promotion of a more sustainable and efficient approach to software development. Only in this way can we fully exploit the potential offered by technological innovation while ensuring a positive impact on the environment and the user experience.

Experience teaches, experience shapes. If you're young, you're probably thinking "ok, boomer" and ready to close this article and move on. If you're less young, on the other hand, you might think it's the usual "revolutionary" article, against the system and against big corporations.

It's not.

About 20 years ago, all users of alternative operating systems (i.e. not Windows) were seen as aliens because "the whole world uses Windows." We dreamed of the "year of the Linux (or FreeBSD) desktop revolution," a topic that is still joked about today. In fact, these operating systems have really arrived everywhere (in the form of Android, Smart Home, Playstation, partly MacOS, etc.), obviously in a different way than we would have dreamed of.

Even then, I would get angry and answer "why should I use Windows? Just because everyone else does?" The answer, usually, was this: "In the real world and in the workplace, everyone uses Windows."

While they may have had a point in some sense, it didn't seem like a valid reason to force me to use an unsuitable or at least less effective operating system for my work.

Time has proved me right. The internet has seen Unix or Unix-like-based servers prevail, data centers have become mainly based on Linux (thanks, Amazon, for pushing this trend even further!), the concept of "cloud" has been born and everything that comes with it. Routers and firewalls have started to be based on Linux or *BSD systems and development has gone beyond just keeping a packet filter running to the additional features that we have available today.

The big players have entered the game, Microsoft itself has started to love Linux, FreeBSD and, with WSL, has definitively shown that "the other" cannot be ignored.

Today, saying that you're a Linux system administrator generates admiration and respect, while less than twenty years ago, I would be told "Linux is a toy used in universities, the world uses Windows." Being an expert in *BSD systems administration, on the other hand, still generates strange thoughts in the interlocutor.

Experience has taught me that there is no (and should not be!) only one way to do things. In the world of Open Source, the plurality of solutions facilitates a diversified development that could, over time, hold surprises.

A few days ago, I published an article on how I migrated from a Proxmox server to FreeBSD without any particular problems and improving system efficiency. The article had an unexpected success, receiving a huge number of visits in just a few days, and the comments were enthusiastic. Some critical comments, of course, came in. I love critical comments because sometimes it is essential to see things from another point of view. When I am truly convinced, I still stick to my idea, but if the critical comment were to arouse doubt, I would have the inspiration to investigate further. To do research. To experiment, which is the foundation of our profession.

That's why I have never sympathized with those who, with arrogance (and arrogance often synonymous with ignorance), close off any solution that is not their favorite.

We should have learned by now that the technological world is a virtually infinite world, made up of tools (i.e. bricks) with which to build a solution to our problem. Seeing adult or elderly people entrenched in rigid positions is sad, and even sadder is seeing young people (perhaps also competent) who close the door to anything that is not the "hype" solution of the moment, perhaps driven by the marketing of those who have invested a lot of money in those solutions. Saying "it's 2023 and everyone uses Kubernetes on the cloud, on managed clusters," for example, means ignoring that not all tools are suitable for solving all problems. I don't use an industrial scale to weigh myself because it would be too big, too expensive, or otherwise unsuitable for the purpose. Therefore, not everyone should use industrial scales to weigh themselves. Studying the problem should always be the first step towards finding the most suitable tools to solve it. Fortunately, there is no "one size fits all" in computer science. Just as not always the most "modern and trendy" tool is the most suitable and long-lasting over the long term.