[{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/tags/arch-linux/","section":"Tags","summary":"","title":"Arch Linux","type":"tags"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/categories/discussion/","section":"Categories","summary":"","title":"Discussion","type":"categories"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/tags/foss/","section":"Tags","summary":"","title":"FOSS","type":"tags"},{"content":"I switched to Linux a year ago, searching for freedom from “Microslop’s” hypothetical chains. For much of that time, my Linux setup revolved around customisation, and simply looking cool. For the first 12 months, I used Arch Linux. I experimented with tiling window managers (settling on Hyprland), spent hours tweaking dotfiles, and constantly chased the perfect desktop experience. Like many Linux enthusiasts, I fell into the culture of ricing – endlessly modifying every visual detail of my system in pursuit of something uniquely mine. At first, it was exciting, Hyprland felt like a new philosophy of computing. I spent a lot of time building out a heavily customised setup with fancy dotfiles, animations, and carefully tuned workflows. My terminal (kitty) was customized, my status bar was handcrafted, I had a containerised windows installation for MS-Office, and my desktop screenshots looked impressive (Figure 1).\nFigure 1. My old, highly stylised, Arch Linux setup\nBut eventually, I started asking myself an uncomfortable question: Was any of this actually improving my computing experience?\nOver time, the answer became increasingly clear: not really.\nArch Linux is fantastic for people who enjoy building their system from the ground up, and I learnt many lessons on how UNIX-like operating systems function under the hood. The documentation is excellent, the community is passionate, and the level of control is unmatched. But that freedom comes with a hidden cost. The more customizable your environment becomes, the easier it is to spend more time maintaining your system than actually using it.\nI would regularly:\nRewrite configuration files for tiny visual improvements Replace working tools simply because something newer appeared on the Arch User Repositories Spend hours fixing issues caused by experimental software Constantly rebuild my desktop after reinstallations or major changes Obsess over aesthetics instead of productivity There is a strange culture in parts of the Linux community where complexity itself becomes a badge of honour. The more obscure your setup, the more impressive it appears, and while there is absolutely nothing wrong with customization as a hobby, I eventually realized I no longer enjoyed treating my operating system like a permanent side project – I have work that needs to be done and I merely want my computer to work. Thankfully, after months of gradual instability and bloat, a dependency error completely borked my Hyprland setup and gave me an excuse to start over. It is important to note that this was likely due to my extensive use of the AUR, and not a fault of the devs, who do a great job!\nI did not suddenly start disliking Arch Linux. In fact, I still think it is one of the best Linux distributions for learning how Linux works internally. Arch taught me more about Linux than any other operating system ever could (except perhaps Gentoo – I am, alas, not a masochist). But eventually I reached a point where I valued stability, convenience, and reliability more than endless customization. That is what led me to openSUSE Tumbleweed.\nAt first glance, Tumbleweed seemed unusual compared to other rolling-release distributions. It is still cutting-edge, but it approaches updates far more cautiously than Arch. One of the biggest differences is the testing process. Packages in Tumbleweed go through extensive automated testing before reaching users. This significantly reduces the chances of system-breaking updates while still keeping software relatively current. The result is a rolling-release distribution that feels surprisingly stable.\nSome features that immediately stood out to me were:\nReliable snapshot and rollback functionality through Snapper and Btrfs Sensible defaults that required minimal tweaking A polished KDE Plasma experience out of the box Strong integration tools like YaST that aid with backend sysadmin jobs which I admittedly still tinker with. Better system resilience during updates Exceptional dependency management through the Zypper package manager. The biggest surprise in this journey was not actually changing distributions. It was abandoning tiling window managers.\nFor a long time, I convinced myself that using a tiling WM made me more productive. Keyboard-driven workflows felt efficient, and highly minimal desktops looked elegant. And to be fair, tiling window managers can genuinely improve workflows for some people. But eventually I realized that I was forcing myself into a workflow that no longer matched how I actually used my computer. KDE Plasma in particular surprised me with how customizable, lightweight, and polished it has become. I could still use keyboard shortcuts, virtual desktops, and advanced workflows - but without spending hours configuring basic functionality.\nSimple things became easier:\nBluetooth worked reliably Audio devices switched properly Multi-monitor support required no manual configuration in a random dotfile that changes location every other update. Power management behaved correctly – including power profiles and wake on LAN. Applications integrated more naturally, with the QT framework being standard across all essential apps. Wayland support felt more mature as opposed to the still in development Hyprland. Most importantly, I stopped thinking about my desktop environment all the time. That might sound strange, but I think it is actually a sign of good software.\nOne thing I have noticed in Linux spaces is that there can sometimes be subtle pressure to pursue increasingly complex setups. Minimalism becomes performative, with people competing over terminal workflows, startup times, memory usage, or how little software they rely on (systemd haters will never stop getting on my nerves – just use it, it works). Again, there is nothing inherently wrong with any of this, experimentation is part of what makes Linux fun, but I think many users – especially newer users – can end up believing that they should constantly optimize and customize everything in order to be a “real” Linux user. You do not. Using a polished desktop environment does not make you less technical. Choosing convenience does not make you lazy. And preferring stability over endless tinkering does not mean you have somehow “lost” your enthusiasm for Linux.\nIn many ways, I think I appreciate Linux more now than I did before. I no longer feel the need to prove anything through my setup (Figure 2).\nFigure 2. My new, simple, openSUSE KDE desktop\nOne of the most important things I learned from this transition is that simplicity is not the same as limitation – and that it is often underrated. A simpler setup often means:\nLess maintenance Fewer distractions More reliability Better focus More time spent actually doing meaningful work I still enjoy Linux customization and I still appreciate tiling window managers for what they are and how they solve the problems that exist with classical floating WMs.\nI still think Arch Linux is excellent, but my priorities changed. Today, I value comfort and consistency more than endless tweaking. My desktop no longer exists to impress people online, it instead exists to help me work, study, write, browse, and enjoy using my computer. And honestly, that feels far more satisfying.\nSwitching from Arch Linux to openSUSE Tumbleweed was less about changing distributions and more about changing my relationship with technology. I stopped viewing my operating system as a project that always needed improvement. I stopped chasing the “perfect” setup. And somewhere along the way, I rediscovered something I had slowly lost, that being the simple enjoyment of using my computer without constantly needing to fix, tweak, or reinvent it.\nIronically, after years spent searching for the ultimate Linux setup, I ended up appreciating something much simpler.\nAnd, whether that is a sign of me getting old, or a sign of me maturing, I think that is perfectly okay.\nOpen Source Software referenced # Arch Linux Arch Wiki Hyprland Kitty terminal emulator KDE Plasma openSUSE openSUSE Tumbleweed Snapper Tutorial (Btrfs snapshots) Btrfs filesystem YaST Zypper package manager ","date":"25 May 2026","externalUrl":null,"permalink":"/posts/suse-migration/","section":"Posts","summary":"","title":"From Arch Linux to openSUSE Tumbleweed: A Journey from Tiling WMs to Productive Simplicity","type":"posts"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/","section":"Jack Magson","summary":"","title":"Jack Magson","type":"page"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/authors/jack-magson/","section":"Authors","summary":"","title":"Jack Magson","type":"authors"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/tags/opensuse/","section":"Tags","summary":"","title":"OpenSUSE","type":"tags"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"25 May 2026","externalUrl":null,"permalink":"/tags/tumbleweed/","section":"Tags","summary":"","title":"Tumbleweed","type":"tags"},{"content":"","date":"12 February 2026","externalUrl":null,"permalink":"/tags/alphafold/","section":"Tags","summary":"","title":"AlphaFold","type":"tags"},{"content":"","date":"12 February 2026","externalUrl":null,"permalink":"/tags/biochemistry/","section":"Tags","summary":"","title":"Biochemistry","type":"tags"},{"content":"Modern life science runs on software, yet much of it remains closed. From statistical packages such as SPSS to systems like AlphaFold 3 (Abramson et al., 2024) - whose outputs are shared under a Creative Commons licence while the underlying training infrastructure remains proprietary - the tools that underpin biological research are often controlled, restricted, or expensive.\nOpen source is not a foreign concept in academia. Programming languages such as Python and R are used extensively in research and are both free and open source. This removes financial barriers and allows libraries such as BioPython, Matplotlib, and ggplot2 to evolve alongside scientific needs. In contrast, platforms such as SPSS or GraphPad Prism operate under restrictive licensing models. While powerful, they limit modification, prevent inspection of underlying implementations, and often require costly institutional subscriptions. Users are consumers rather than contributors.\nThe open development model does more than reduce costs; it strengthens scientific integrity. When code is accessible, algorithms can be inspected, challenged, and improved. This aligns closely with the core principles of science itself: transparency, critique, and reproducibility. Projects that are deprecated can be forked to maintain compatibility with modern systems, and the availability of source code enables the creation of supplementary tools - from API extensions to something as simple as a graphical interface layered over a command-line program. A prime example of this model functioning effectively is the National Center for Biotechnology Information (NCBI). As a U.S. government institution, much of its software and data, including resources such as BLAST (Figure 1) and GenBank, are placed in the public domain. The code, databases, and interfaces are freely accessible, allowing researchers worldwide to build pipelines, mirror datasets, and integrate these tools into their own systems without restriction, including using their own datasets for specialised workflows. This openness makes NCBI resources foundational to modern biology, enabling accessibility, reproducibility, and most importantly, accountability in research. It is difficult to imagine modern molecular biology without tools such as BLAST or COBALT. Yet if such foundational tools were proprietary, access to sequence comparison - one of the most basic analytical methods in genomics - would be subject to commercial gatekeeping and profit margins.\nFigure 1 - NCBI Blast website running on GNU/Linux\nImagine if BLAST were not a public domain tool provided by the NCBI, but a proprietary product owned by a private corporation - let’s call it \u0026lsquo;GenBlast\u0026rsquo;. In this scenario, a basic sequence alignment might cost $10 per run, or require a $5,000 annual institutional seat. Graduate students working on novel organisms would be unable to \u0026lsquo;mirror datasets\u0026rsquo; locally to experiment freely; instead, they would be forced to upload their private, potentially sensitive data to a corporate cloud server to be processed. Worse, if \u0026lsquo;GenBlast\u0026rsquo; released an update that slightly altered how E-values were calculated to improve speed (convenience), researchers would have no way to verify the change. They could not inspect the code to see why their matches suddenly differed from previous years. The basic analytical method of genomics would become a trade secret, and the reproducibility of decades of genetic research would rely entirely on the solvency and goodwill of a single company.\nMy own bioinformatics project, PicoMol, serves as a case study in this regard. While it functions as a plasmid viewer and structural analysis toolkit, its real value lies in how it was built. Proprietary suites, like SnapGene, often create walled gardens, locking features behind tiered subscriptions. PicoMol, conversely, demonstrates the power of composability. By synthesizing the computational libraries of Biopython with the graphical capabilities of Qt6 (when i\u0026rsquo;ve finished the migration from the now deprecated Qt5), a single undergraduate can build a tool that rivals expensive commercial suites. This is not a claim that open-source developers are superior engineers. It is a recognition that open collaboration compounds progress. It is because the open model allows us to stand on the shoulders of developers who choose to share their work, rather than facing financial barriers to access. The corporate model monetises fragmentation. Open development enables integration. PicoMol\u0026rsquo;s combined suite proves that when the motive shifts from profit to discovery, scientific tools naturally tend towards connection, not fragmentation.\nIt would be naive, however, to ignore the advantages that proprietary software can offer. Analyzing raw biological data is a complex task, and for many wet-lab scientists, the steep learning curve of command-line tools is a significant barrier to entry. Commercial platforms such as GraphPad Prism, SPSS, or specialised software designed to operate a complex piece of equipment often provide polished interfaces, dedicated customer support, and tightly integrated workflows that hide away the underlying code, allowing researchers to generate publication-ready visualisations without needing to become programmers first. In fast-paced research environments, convenience matters. Industry investment can also accelerate development, particularly in areas requiring significant computational infrastructure, as seen with advanced AI-driven systems in structural biology, such as the invaluable contributions towards AlphaFold from Google’s DeepMind. However, these benefits come at a cost beyond licensing fees. With proprietary software operating as a black box, algorithms cannot be meaningfully inspected, modified, or independently validated. Researchers must trust that implementations are correct and that updates will not silently alter analytical behaviour. Consider the implications for a PhD student. If a proprietary model is updated halfway through a thesis, and results suddenly shift, the student has no way to prove whether the change is a scientific discovery or a software patch, potentially invalidating years of work. When licences expire or companies pivot, access can disappear entirely, stranding the researchers, both academic and industrial, who rely on such workflows. In such cases, methodology depends on corporate continuity rather than reproducibility. Science, by contrast, is meant to outlive the products that support it.\nWhile commercial tools may offer convenience, convenience for convenience\u0026rsquo;s sake is not a scientific virtue. Transparency is.\nThe dependence on proprietary systems in academia extends beyond specialised scientific software. Much of modern research infrastructure runs atop closed operating systems and productivity suites such as Microsoft Windows and Microsoft Office. These platforms are often treated as default infrastructure. They are the systems researchers actually rely on to run experiments, store data, and write papers. When the infrastructure itself is proprietary, researchers are subject to licensing terms, update cycles, file format constraints, and long-term corporate strategy decisions that lie entirely outside the academic sphere, serving only executives and shareholders whose priority is market dominance over scientific longevity.\nScientific inquiry demands scepticism and verification. It is inconsistent, then, for research institutions to depend on digital infrastructure that they cannot inspect, modify, or control.\nThe risk of proprietary infrastructure becomes particularly visible in systems such as Microsoft Windows and Microsoft Office. Windows update cycles are controlled entirely by Microsoft, and major updates have, at times, introduced instability, deprecated features, or removed support for older hardware. High-value instruments - such as electron microscopes and plate readers - often possess a mechanical lifespan that far exceeds the support window of their proprietary drivers. It is a common reality in academia to find six-figure instruments tethered to isolated computers running Windows XP or Windows 7, simply because the vendor has ceased software support and the hardware is incompatible with modern operating systems. This forces a wasteful choice: maintain insecure, air-gapped machines that hinder data transfer, or decommission perfectly functional scientific equipment due to software obsolescence. In an open ecosystem, such as the Linux kernel, community-maintained drivers could extend the life of these instruments indefinitely, ensuring that grant funding is spent on new discoveries rather than replacing tools that already work.\nIf a vendor deprecates the software for a £500,000 electron microscope, a university running Linux is not forced to scrap the machine. They, or a hired developer, can update the kernel driver to keep it running on modern infrastructure. This restores control to the laboratory, and ensures the task of coding the software is not placed on the researcher as writing or maintaining drivers in low-level languages such as C or Rust is not a skill expected of biologists. The focus is instead on Right-to-Repair. While navigating university procurement and grant funding to contract a specialist is rarely simple, the math remains undeniable, paying for a few weeks of custom development is infinitely cheaper than purchasing six new microscopes every Windows update cycle.\nThis brings me to my critical point about education. To reclaim control over our infrastructure, we must integrate computational literacy, not just coding, into the undergraduate curriculum. This does not mean every biologist must learn to write kernel drivers. Rather, the goal is to shift students from being passive \u0026lsquo;consumers\u0026rsquo; of software to active architects of their digital environments. Just as a researcher understands the optical principles of a microscope without needing to know how to grind the lenses, they should understand the functional nature of their operating systems (such as filesystems, command-line integration, or even learning how to install tools such as BLAST locally). By teaching the fundamentals of how open systems function, we empower the next generation to manage their infrastructure rather than be held hostage by it. A biologist with this systems thinking knows enough to deploy a community patch, migrate data from a legacy format, or collaborate with a developer to keep a six-figure instrument running, ensuring that research is limited only by physics, not by a licensing agreement.\nThis struggle for sovereignty extends beyond the laboratory bench and into the cloud. In the last decade, Microsoft Office has evolved from a standalone tool into a subscription-based ecosystem increasingly integrated with AI-driven features such as Copilot. This creates a new crisis of data sovereignty. Cloud-based tools often require researchers to upload sensitive, unpublished data to infrastructure they do not own, governed by agreements few read. This raises a critical question: does the data remain the exclusive property of the scientist, or does it become training data for the corporation? In a closed system, there is no technical guarantee that a novel protein sequence, confidential patient dataset, or new drug discovery will not be used to train commercial models.\nClosed infrastructure requires trust in authority. Open systems distribute that trust across a community.\nThis is not to imply that open systems are effortless. They are constantly maintained, tested, and iterated upon by the communities and organisations that develop them. Their stability does not emerge from corporate control, but from continuous collaborative refinement. The sense of community that arises within open-source spaces fosters shared responsibility; bugs are reported publicly, improvements are discussed transparently, and progress is visible to all.\nUltimately, the reliance on proprietary software introduces a systemic fragility into the heart of bioscience. When methodology is embedded in closed systems, reproducibility depends on corporate stability rather than scientific principle. We risk a future where critical instruments are rendered obsolete by arbitrary driver updates, where novel datasets become training fodder for corporate AI, and where reproducibility is limited by the lifespan of a subscription. To reclaim our independence, we must stop treating software as a mere utility and start treating it as a foundational scientific discipline. This shift begins in the classroom. By integrating open systems and computational literacy into the undergraduate curriculum, we empower the next generation of biologists to be architects of their own workflows rather than consumers of restricted products. In the computational era, if we cannot inspect the code, we cannot fully verify the science. One silent update is enough to introduce a bug that can spiral into career‑ending errors. Open source is not just a software model, it is the infrastructure most compatible with the scientific method.\nScience requires us to show our work. In the computational era, that includes the code.\nThe choice is not simply one of convenience or cost, but of who controls the means of knowledge production. If we want science to remain reproducible and independent, FOSS must become the standard, not the exception, in bioscience research, education, and industry.\nFurther Reading # Open Source in the Life Sciences (Nature) – Discusses the impact and challenges of open-source software in biology. AlphaFold 2: Open-sourcing deep learning for protein structure prediction – DeepMind’s AlphaFold project and its licensing. Open Source Projects # Biopython – A library for bioinformatics in Python. PicoMol – Your bioinformatics toolkit. NCBI Tools – Publicly available bioinformatics resources. The Linux Kernel – Open-source operating system kernel. LibreOffice – Open-source office suite. GitHub Resources # Matplotlib – Python plotting library. Qt6 – Open-source GUI framework (up-to-date version). Open-Source Molecular Biology Projects – Community-maintained bioinformatics projects. Useful Citations \u0026amp; Further Sources # On AlphaFold and Open Source Licensing # AlphaFold 3 licensing terms and restrictions – The official GitHub repository showing AlphaFold 3’s Creative Commons Attribution‑NonCommercial ShareAlike licence and terms of use for model weights, which restrict commercial use. Accurate structure prediction of biomolecular interactions with AlphaFold 3 (Nature) – The peer‑reviewed paper describing AlphaFold 3’s architecture and its ability to predict structures of proteins, nucleic acids, and other biomolecular complexes. On Open Source, Reproducibility, and Scientific Software # Publishing computational research and open infrastructure – Review showing how open access to code and data supports reproducible computational science. Importance of open source and open standards in scientific publishing – Article discussing why reliance on proprietary software and formats can negatively affect scientific communication. ReScience C journal - reproducibility with FOSS – A journal dedicated to replications done with free and open‑source software, highlighting the role of FOSS in scientific verification. ","date":"12 February 2026","externalUrl":null,"permalink":"/posts/foss-biosci/","section":"Posts","summary":"","title":"The Importance of Free and Open Source Software (FOSS) in the Biosciences.","type":"posts"},{"content":"","date":"10 February 2026","externalUrl":null,"permalink":"/categories/general/","section":"Categories","summary":"","title":"General","type":"categories"},{"content":"","date":"10 February 2026","externalUrl":null,"permalink":"/tags/welcome/","section":"Tags","summary":"","title":"Welcome","type":"tags"},{"content":"Welcome! I\u0026rsquo;m Jack, and this is my corner of the internet where I share my thoughts on three things I\u0026rsquo;m passionate about: biochemistry, music, and open source.\nWho Am I? # I\u0026rsquo;m a 21-year-old undergraduate biochemist at the University of Bristol, exploring the molecular intricacies of life in the lab. Beyond the textbooks, I\u0026rsquo;m an avid musician and proud president of the University of Bristol Big Band Society—where I get to indulge my love for jazz and big band music. When I\u0026rsquo;m not studying or making music, you\u0026rsquo;ll find me contributing to my own open source projects and exploring the world of software development.\nWhat You\u0026rsquo;ll Find Here # This blog is a space for me to document my learning, share experiences, and connect with others who share similar interests. Whether you\u0026rsquo;re here for the science, the music, or the code, I hope you find something valuable.\nThanks for visiting, and stay tuned for more posts!\n","date":"10 February 2026","externalUrl":null,"permalink":"/posts/welcome/","section":"Posts","summary":"","title":"Welcome!","type":"posts"},{"content":" Hi, I\u0026rsquo;m Jack. I\u0026rsquo;m a 21-year-old undergraduate biochemist at the University of Bristol with a passion for understanding the molecular intricacies of life. Beyond the lab, I\u0026rsquo;m an avid musician and proud president of the University of Bristol Big Band Society, where I get to indulge my love for jazz and big band music. When I\u0026rsquo;m not studying or making music, you\u0026rsquo;ll find me exploring open source projects and contributing to the developer community.\n","externalUrl":null,"permalink":"/about/","section":"About","summary":"","title":"About","type":"about"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"}]