In the fall of 2025, the end of Windows 10 support put me in front of a fairly concrete decision.
My main workstation, TALYN, wasn't eligible for Windows 11. Yet with its Core i7, 32 GB of memory, SSDs, and GTX 1660 SUPER, it still comfortably met my professional needs.
Replacing the machine solely because it didn't meet the new OS's requirements was hard to justify.
So I chose a different path: keep the hardware and replace Windows.
In November 2025, I switched over to Linux Mint.
What had started as a pragmatic response to Windows 10's end of life would end up reshaping, more deeply than expected, the way I use and troubleshoot my workstation.
A transition less brutal than it looked
Moving from Windows to Linux Mint could have seemed like a major break. In my case, it was much less of one than I expected.
On Windows, I was already regularly using Cygwin to get back the Unix environment and tools I missed natively. The command line, and a good part of the habits tied to that ecosystem, were already part of my working environment.
Linux Mint didn't introduce those habits. It simply made them native.
So, for my development and command-line usage, I wasn't starting from scratch.
The biggest differences showed up elsewhere: how the graphical environment behaves, peripherals, drivers, and more generally, diagnosing the system when something didn't behave as expected.
When the first freeze changes how you reason
One of the first serious difficulties came a few weeks after the migration.
The graphical interface froze. At first the mouse pointer still responded, before the machine eventually seemed completely locked up.
That's when I started discovering a distinction that has since become central to how I diagnose my machine: a frozen graphical interface doesn't necessarily mean the whole system is frozen.
Getting to a TTY (a text console reachable outside the graphical interface), inspecting processes, restarting Cinnamon, recovering the graphical session, Magic SysRq (a low-level key combination that talks directly to the kernel): I gradually built a hierarchy of things to try to recover the machine before resorting to a hard reboot.
Some work depending on the nature of the freeze. Others don't.
What mattered was that a full reboot was no longer necessarily my first response to an unresponsive graphical environment.
When the problem turned out to be storage
The slowdowns and freezes also repeatedly led me to suspect memory.
Yet TALYN has 32 GB of RAM. Measuring memory used, memory available, and swap (the backup memory on disk) activity, nothing pointed to memory exhaustion. There were reasonably active processes, notably the browser and Cinnamon, but those measurements didn't account for the symptoms.
That reminded me of a simple rule that's easy to forget when an incident blocks your work tool:
a symptom isn't a cause.
That same logic — measure before concluding — led me to widen the investigation beyond RAM. That's where the real problem showed up: available disk space. Docker, with images and data piling up over the months, played its part.
What these investigations left me with, more than a one-off answer, was a set of commands and a method for examining memory, swap, disk space, processes, and logs before reaching a diagnosis.
A USB scanner recognized… but not really usable
The peripheral hardware confronted me with a different kind of difficulty.
My Fujitsu ScanSnap S1300i was clearly visible on the USB bus. That didn't mean it was immediately usable on Linux Mint.
I had to work my way progressively down the chain: USB, SANE (Linux's standard scanner management system), firmware, permissions, then the scanning application.
The required firmware wasn't immediately available in my installation. Once retrieved and correctly registered with SANE, scanimage was finally able to drive the scanner.
The scanner was now usable via SANE, from the command line. What remained was a real gap with the everyday use I actually wanted.
When the workaround becomes a small Rust project
The support was there: SANE could drive the scanner, scanimage could scan.
But what I actually needed was much more mundane: load documents into the feeder, pick a profile, run a duplex scan, and get a usable PDF directly. That gap between what the support made possible and what my everyday use required, I could obviously have closed with shell commands. I preferred turning the need into a small project and building scan_cli in Rust — the logical next step of that appropriation, not a separate product.
The tool doesn't replace SANE or the scanner's firmware. It orchestrates the existing pieces to provide the usage layer I was missing:
- automatic scanner detection;
- document, grayscale, and color profiles;
- duplex scanning;
- PDF generation;
- persistent configuration;
- handling of the main error cases;
- environment diagnostics.
This case is fairly representative of what I've come to appreciate about Linux over time.
The system never stopped me from doing what I wanted. The building blocks existed and were accessible. What was missing was the layer matching my exact usage.
I was able to build it.
The command line is no longer a fallback tool
Cygwin had already gotten me used to Unix tools on Windows, so it would be wrong to present my move to Linux Mint as a sudden discovery of the terminal.
What changed is its place.
On Linux, the command line isn't a layer I add on top of my environment: it's naturally part of the system I administer.
A command first used to diagnose an incident can become a reflex. A sequence that works several times becomes a procedure. A procedure stable enough eventually ends up in my notes or in a playbook.
Over the months, I ended up building a small toolbox suited not to "Linux" in general, but to my own machine and my own usage.
Learning heavily assisted by AI
This lessons-learned piece is still missing something important: I probably wouldn't have pushed these investigations as far without the help of an LLM (Large Language Model), the type of AI model behind assistants like ChatGPT or Claude.
Faced with a problem, that assistance let me move forward iteratively: describe a symptom, formulate hypotheses, run checks, analyze the results, then rule out certain leads until reaching a solution.
The LLM didn't necessarily know the cause from the start. The value was precisely in that progression. Each result gathered on the machine fed the next step of the diagnosis.
This approach helped me just as much to understand a Linux Mint freeze as to diagnose a storage saturation issue or make my scanner genuinely usable. In that last case, the process even went beyond troubleshooting, since it led to building scan_cli.
The combination of Linux, the command line, and AI assistance turned out to be particularly effective: the system provides plenty of observable information and tools to act on it, while the LLM helps progressively turn that information into a diagnosis, then a solution.
Looking back, that's an important dimension of this migration: I didn't just learn to use Linux Mint better. I also learned to lean on AI to go further in understanding and solving problems I probably wouldn't have tackled the same way on my own.
What I ultimately take away from this migration
I didn't leave Windows 10 because TALYN had become unusable. It still worked well enough that replacing it, solely because it didn't meet Windows 11's requirements, felt hard to justify. Linux Mint started out as a pragmatic response to that situation — Cygwin had already prepared part of the ground, the following months did the rest.
The incidents themselves didn't disappear: freezes, disk space saturation, an uncooperative peripheral. Some fixes worked immediately, others turned out to be dead ends. But they gradually produced something I hadn't anticipated when I migrated: a much more precise understanding of how my own machine actually works, and a more solid method for diagnosing it before rebooting.
That reflection is what now serves as my starting point for documenting these experiences separately — some of the incidents mentioned here will become content of their own: technical lessons learned, diagnosis and recovery playbooks, operational notes. They don't exist yet; this piece is only the starting point.
After several months on Linux Mint, the most lasting change is probably not the operating system itself.
It's the way I've started paying attention again to what's happening underneath.