Someone mentions encryption, someone else says “AES‑256,” and for a brief second the room relaxes. The magic number has been spoken. The vault door has appeared. The dragon is asleep.

Then the same team commits a decrypted .env file to Git. Or stores an age private key in a shared password note. Or lets CI print a production secret into a build log. Or keeps the only decryption key on one developer laptop, guarded by vibes, hope, and an unpaid backup plan.

The uncomfortable truth is this: AES‑256 is usually not the weak point. Your workflow is.

The SOPS and age use case

This becomes very real in modern DevOps and GitOps setups.

Tools like SOPS and age exist because teams want to keep configuration close to code without spraying plaintext secrets all over Git. SOPS is an editor for encrypted files and supports formats such as YAML, JSON, ENV, INI, and binary files. It can use backends such as age, PGP, AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault, and OpenBao. SOPS keeps the structure of configuration files visible while encrypting values, and its own documentation says values are encrypted using AES‑256 in GCM mode. (getsops.io)

age is a modern file encryption tool and format with small explicit keys, UNIX-style composability, and support for recipient-based encryption. In other words: encrypt to one or more public recipients, decrypt with the corresponding private identity. (github.com/FiloSottile/age)

That is a very practical setup:

Git stores encrypted secrets.
Developers can review structure without seeing plaintext.
CI/CD decrypts only where needed.
Access is managed through explicit identities or KMS permissions.

That sounds sane. And it can be sane. But only if the surrounding workflow is sane too.

AES‑256 itself is not the problem

AES, the Advanced Encryption Standard, is a symmetric block cipher standardized by NIST. AES supports 128, 192, and 256-bit keys and encrypts data in 128-bit blocks. AES‑256 simply means AES with a 256-bit key. (NIST FIPS 197)

A 256-bit key space contains:

2^256

possible keys. That is about:

116 quattuorvigintillion possible keys

A billion has 9 zeros. A trillion has 12 zeros. This number has 78 digits.

Written out, it is:

115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936

At this scale, the exact name of the number almost stops helping. The point is simpler: there are so many possible AES‑256 keys that brute force is not an engineering plan. It is bedtime theatre for impatient supercomputers.

A classical brute-force attack is absurd

Let’s pretend an attacker has a machine that can try:

10^18 keys per second

That is one quintillion key attempts per second. At that speed, searching the full AES‑256 key space would take roughly:

3.67 × 10^51 years

The universe is about:

1.38 × 10^10 years old

So this is not “a long time.” This is “the heat death of your roadmap happened before the progress bar moved.”

But what about quantum computers?

Quantum computers do change the discussion, but not in the way many headlines suggest.

For symmetric key search, Grover’s algorithm can theoretically provide a quadratic speedup. Instead of searching through N possibilities, an idealized quantum search needs roughly:

√N

For a 256-bit key space:

√(2^256) = 2^128

That is where the common statement comes from:

AES‑256 has roughly 128-bit security against idealized quantum brute force.

That sounds scary until you look at what 2^128 means:

340,282,366,920,938,463,463,374,607,431,768,211,456

Still enormous.

NIST’s post-quantum FAQ is much calmer than the mythology. NIST says Grover’s algorithm gives a quadratic speedup in theory, but also notes that quantum hardware is likely to be expensive, that Grover is hard to parallelize efficiently, and that AES‑192 and AES‑256 are expected to remain safe for a very long time. (NIST Post-Quantum Cryptography FAQ)

So no: a future quantum computer does not magically turn AES‑256 into wet cardboard.

How long would 2^128 attempts take?

Assume an attacker somehow needs to perform 2^128 useful attempts.

The last line looks scary.

But 10^30 useful cryptographic search steps per second is not “a large GPU cluster.”

It is not a few racks in a data center. It is not even “someone at AWS got a very spicy invoice.” It is fantasy-scale computing.

Compare that to the fastest supercomputer

As a reality anchor, take El Capitan.

In the November 2025 TOP500 list, El Capitan was listed as the world’s fastest supercomputer, with an HPL benchmark result of 1.809 exaflop/s, 11.34 million cores, and a power draw of 29,685 kW, roughly 29.7 MW. (TOP500 November 2025)

Now let’s be outrageously generous. Let’s pretend that:

1 floating-point operation = 1 useful AES key attempt

That is not how real AES brute force works, and it is especially not how quantum search works. But as a rough scale comparison, it is generous enough to help the intuition.

At El Capitan’s 1.809 × 10^18 operations per second, even the reduced quantum-style 2^128 search space would take roughly:

5.96 × 10^12 years

That is about:

5.96 trillion years

So even after giving the attacker the quantum “128-bit effective” framing, and even after pretending the world’s fastest supercomputer is a perfect AES guessing machine, the answer is still trillions of years.

The machine is fast. The number is ridiculous.

What would 10^30 attempts per second mean?

Now take the scary table entry:

10^30 attempts per second

Compared to El Capitan:

10^30 / 1.809 × 10^18 ≈ 552,800,000,000

So you would need roughly:

553 billion El Capitan-class systems

Again, this is a crude comparison. FLOPS are not AES attempts. Classical supercomputers are not quantum computers. But that actually makes the point stronger: even with a fantasy-friendly comparison, the scale is deranged.

Power consumption would be equally absurd.

One El Capitan-class system draws about:

29.7 MW

Scale that to 553 billion systems:

≈ 16,400,000 TW

That is:

16.4 million terawatts

And if electricity cost only:

$0.10 per kWh

then running that fantasy machine would cost roughly:

$1.64 quadrillion per hour

At:

$0.30 per kWh

it would be roughly:

$4.92 quadrillion per hour

That is not a data center. That is not even an energy policy. That is a planet trying to become a space heater.

Quantum does not mean free

And the quantum version is not easier in practice.

You do not just replace 553 billion supercomputers with one glowing quantum cube and call it done.

A serious Grover-style attack against AES would require fault-tolerant quantum computing, logical qubits, quantum error correction, enormous gate depth, control hardware, cooling infrastructure, and a level of reliability that does not resemble today’s noisy quantum machines. Research on applying Grover’s algorithm to AES focuses exactly on these resource questions: qubits, circuit depth, gate counts, and the cost of implementing AES inside a quantum circuit. (arXiv:1512.04965)

That is the gap between theory and practice. Theory says:

Grover reduces exhaustive search from 2^256 to roughly 2^128.

Practice says:

Good luck building the machine, powering it, cooling it, error-correcting it, and running the full attack before civilization changes ticketing systems again.

The boring attacks are the real attacks

If you use SOPS and age, the real risks are much less cinematic. They look like this:

A decrypted secrets file committed by accident.
An age private identity copied into Slack.
A CI job decrypting secrets for untrusted pull requests.
A debug command printing environment variables.
A KMS policy granting access too broadly.
A backup system storing plaintext copies.
An engineer leaving the company while still listed as a recipient.
A production secret living forever because nobody owns rotation.

None of these attacks break AES‑256. They walk around it. They steal the plaintext before encryption or after decryption. That is the little goblin door in the castle wall.

What a sane SOPS + age workflow should care about

The important questions are operational:

Who can decrypt production secrets?
Where are private identities stored?
Are they backed up?
Are they encrypted at rest?
Can CI decrypt only on protected branches?
Can forked pull requests ever access plaintext secrets?
Are old recipients removed when people leave?
Are secrets rotated after exposure?
Do logs ever contain decrypted values?
Can you rebuild the system if one laptop dies?
Can you prove which key material protects which environment?

This is where the real engineering lives.

AES‑256 gives you a very strong locked box.

But someone still has to decide where the key goes, who can touch it, how it is rotated, how it is backed up, and how it is prevented from ending up in the worst possible chat thread at 17:48 on a Friday.

The quantum panic is mostly misplaced

Quantum computing is a serious field.

Post-quantum migration is serious too, especially for public-key cryptography such as RSA and elliptic-curve systems. But symmetric encryption is not in the same panic category.

For AES, the practical message is much calmer:

AES‑256 is not the part you should be losing sleep over.

If your attacker can read your decrypted Kubernetes Secret from a build artifact, they do not need a quantum computer.

If your production .env file is sitting in someone’s Downloads folder, they do not need Grover’s algorithm.

If your age identity is copied into a wiki page, they do not need cryptanalysis.

They need search.

The real takeaway

AES‑256 is enough.

The hard part is not making ciphertext strong. The hard part is making plaintext rare.

A good secrets workflow should make decrypted secrets temporary, intentional, auditable, minimal, and boring.

SOPS and age can help with that. They are not magic. They are sharp tools. Used well, they let teams store encrypted secrets in Git without pretending Git is a vault. Used badly, they become one more ritual around a private key that everyone is too afraid to touch and nobody knows how to recover.

So yes:

AES‑256 is enough.

But that sentence is incomplete.

The better version is:

AES‑256 is enough.
Your secrets workflow has to be good enough too.

While you can download and use the Tor Browser for enhanced anonymity, I find that simply routing traffic through Tor’s network suffices for my needs while maintaining a civilized workflow.

Installation

First, install Tor using Homebrew and start the Tor service:

brew install tor
brew services start tor

Configure Network Settings

Next, configure your network settings to use Tor as a SOCKS proxy:

1. Open System Preferences.
2. Navigate to Network.
3. Select your active network connection and click Advanced.
4. Go to the Proxies tab.
5. Check SOCKS Proxy and enter localhost as the server and 9050 as the port.

Verify Tor Connection

To ensure that your traffic is being routed through the Tor network, visit Check Tor Project. You are able to use Onion-Links like: https://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion/

Managing the Tor Service

To restart Tor, use the following command:

brew services restart tor

To stop Tor, use:

brew services stop tor

Note: After stopping Tor, remember to disable the SOCKS Proxy in your Network Settings to resume browsing without Tor.

A cornerstone of Linux’s versatility lies in its sophisticated resource and security controls, which facilitate the implementation of containers. Containers have become indispensable in large-scale production networks, enabling efficient deployment and management of applications. In contrast, macOS lacks native container support. While solutions like Docker Desktop attempt to bridge this gap, they inherently rely on running a Linux virtual machine to emulate the necessary controls. This dependency underscores a fundamental divergence: Apple’s strategic focus does not prioritize macOS as a server platform, a domain increasingly embraced by competitors such as Windows, which now robustly supports containerization. Consequently, macOS remains the predominant mainstream operating system devoid of native container capabilities.

From a workstation perspective, macOS excels in delivering a polished and user-friendly environment, catering effectively to a broad spectrum of professional and creative tasks. However, the functionalities that Linux affords beyond the capabilities of macOS typically pertain to systems of considerable scale or minimalism - domains where flexibility and customization are paramount.

Personal usability further delineates these platforms. My experience with the macOS desktop environment often involved navigating a cluttered interface with multiple overlapping windows, making the retrieval of specific applications or settings cumbersome. In contrast, major Linux desktop environments such as GNOME, KDE, and XFCE, though perhaps less refined in aesthetics, offer a more streamlined and unobtrusive user experience. Their design philosophy prioritizes functionality and user autonomy, allowing for greater customization and efficiency, albeit occasionally at the expense of visual smoothness.

Philosophical Underpinnings: Open Source vs. Proprietary Paradigms

The philosophical divergence between Linux and macOS extends beyond mere functionality to the very principles underpinning their development and distribution. Linux, as an open-source operating system, embodies the ideals of transparency, collaboration, and communal ownership. Its development model encourages a decentralized approach where contributions from a global community of developers drive continuous innovation and improvement. This openness fosters an environment where users are not merely consumers but active participants in the evolution of the software they utilize.

In stark contrast, macOS operates within a proprietary framework, controlled and curated by Apple Inc. This model emphasizes a tightly integrated ecosystem where hardware and software are meticulously designed to work in harmony, ensuring a consistent and optimized user experience. While this approach guarantees reliability and polish, it inherently limits user autonomy and restricts the ability to modify or extend the system beyond the parameters set by Apple.

This dichotomy raises profound questions about control, freedom, and the nature of technological progress. Linux’s open-source nature advocates for a democratized approach to computing, where knowledge and tools are freely accessible, promoting innovation through collective effort. Conversely, macOS’s proprietary stance underscores a vision of seamless integration and user-centric design, prioritizing quality and ease of use over customization and flexibility.

The Role of Community and Ecosystem

The communities surrounding Linux and macOS further illustrate their philosophical differences. The Linux ecosystem thrives on a diverse array of distributions, each tailored to specific needs and preferences, from the user-friendly Ubuntu and Fedora to the highly customizable Arch Linux and Gentoo. This plurality fosters a rich environment of experimentation and specialization, enabling users to select or even create a system that aligns precisely with their requirements.

macOS, while benefiting from a robust and dedicated user base, offers a more homogenized ecosystem. Apple’s stringent control over its software and hardware ensures a uniform experience but limits the breadth of customization and the proliferation of alternative configurations. This controlled environment can be advantageous for users who prioritize stability and support, yet it may be restrictive for those seeking to push the boundaries of their system’s capabilities.

Ethical Considerations and Digital Sovereignty

Ethical considerations also play a role in the philosophical debate between macOS and Linux. The open-source movement, represented by Linux, champions digital sovereignty—the idea that individuals and communities should have control over their digital environments without reliance on proprietary entities. This perspective aligns with broader ethical principles of autonomy, privacy, and resistance to monopolistic practices.

On the other hand, macOS’s proprietary model places trust in a single entity to safeguard user data and system integrity. While Apple has built a reputation for strong security and privacy measures, this centralization also means that users must depend on Apple for updates, support, and the longevity of their systems. This reliance can be seen as a trade-off between the assurance of professional stewardship and the empowerment of individual or communal control.

The Aesthetic and Experiential Dimension

Beyond the technical and philosophical aspects, the aesthetic and experiential dimensions of macOS and Linux contribute to their distinct identities. macOS is renowned for its sleek design, intuitive interfaces, and cohesive visual language. This emphasis on aesthetics is not merely superficial; it reflects a deeper philosophical commitment to creating environments that inspire and facilitate creativity and productivity through beauty and simplicity.

Linux, while sometimes perceived as utilitarian in comparison, offers a canvas of customization that appeals to users who derive satisfaction from tailoring their environments to their exact specifications. The ability to modify everything from the window manager to the underlying system processes aligns with a philosophy that values individual expression and technical mastery.

Navigating the Philosophical Landscape

Ultimately, the choice between macOS and Linux is not merely a technical decision but a philosophical alignment with different visions of computing. macOS represents a philosophy of curated excellence, where user experience and seamless integration are paramount. It appeals to those who seek a reliable, aesthetically pleasing, and user-friendly environment with minimal need for customization.

Linux, conversely, embodies a philosophy of openness, flexibility, and communal collaboration. It attracts users who value control, customization, and the ability to engage deeply with their operating system’s inner workings. For academics, researchers, and technologists who thrive on tinkering and optimizing their computational environments, Linux offers unparalleled advantages.

In the context of informatics and philosophy, this dichotomy also reflects broader themes of individualism versus collectivism, control versus freedom, and the balance between structure and flexibility. As technology continues to evolve, the philosophical discourse surrounding operating systems like macOS and Linux will remain a vital area of exploration, shedding light on how our digital tools shape and are shaped by our values and aspirations.

If the decision between these systems prompts contemplation, it is likely that Linux may not align with your current workflow demands. However, for those inclined towards tinkering and optimizing their computational environment, Linux remains a powerful and adaptable platform. Conversely, if macOS meets your needs without eliciting a desire for deeper system engagement, it stands as a testament to the success of proprietary, user-centric design. Embracing either system involves aligning with its underlying philosophy, thereby influencing not only how you interact with technology but also how you conceptualize and engage with the broader digital landscape.

We conducted a benchmark comparison using hey to demonstrate Go’s superiority in high-performance backend operations. By deploying identical machine learning models using both Python and Go, we measured their response times and throughput.

Why Python for AI Development?

Python is the dominant language for AI development due to its rich libraries, like TensorFlow and scikit-learn, which simplify model training and experimentation. Its extensive ecosystem and simple syntax make rapid development easy, especially for data scientists who need flexibility and easy-to-read code.

However, Python’s interpreted nature results in slower execution and higher memory consumption compared to Go. This becomes especially noticeable when scaling an application to handle many requests, such as in a model-serving scenario.

Why Go for Model Serving?

Go’s strengths lie in its speed, concurrency, and memory efficiency. It’s compiled and optimized for handling many requests at once, making it a powerful choice for production-level model serving. For applications that need to serve ML predictions to thousands of users, Go is an excellent fit due to its lower latency and better scalability.

Simple Example: Serving AI Models

Let’s take a simple machine learning example where we train a model using Python and serve it using both Python and Go. We’ll then compare their performance.

Python API (Flask)

from flask import Flask
app = Flask(__name__)

@app.route('/predict')
def predict():
    # Simple prediction simulation
    return "Prediction: Iris-Setosa"

if __name__ == '__main__':
    app.run(port=5000)

Go API

package main

import (
    "fmt"
    "log"
    "net/http"
)

func predictHandler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Prediction: Iris-Setosa")
}

func main() {
    http.HandleFunc("/predict", predictHandler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Benchmarking with Hey

To compare both APIs, use hey for benchmarking. Here’s how you can run the tests:

# For Python API
hey -n 1000 -c 10 http://localhost:5000/predict
# For Go API
hey -n 1000 -c 10 http://localhost:8080/predict

Benchmarking: Go vs. Python for Model Serving

In our tests, Go handled more requests per second (34,172 vs. Python’s 24,795) and had lower average response times. These results clearly show Go’s efficiency in handling concurrent requests, making it ideal for production model serving in AI applications.

• Python

  • Requests per second: 24,795
  • Average response time: 0.0004 secs
  • Slowest response: 0.0107 secs

• Go

  • Requests per second: 34,172
  • Average response time: 0.0003 secs
  • Slowest response: 0.0075 secs

As these numbers show, Go outperforms Python in terms of both requests per second and response times. In high-concurrency environments, the ability to handle thousands of requests with minimal latency is critical, and Go’s concurrent processing model makes it a clear winner for the backend. The improvement in throughput (over 30% more requests per second) highlights Go’s advantage when scaling applications.

Conclusion

While Python remains the best language for AI development due to its powerful libraries, Go outperforms it in production environments for serving machine learning models. Using Go for model serving can lead to faster response times and higher scalability, making it a compelling choice for backend operations in AI-powered applications.

Currently, I’m working at an AI startup, where we’re building our core infrastructure around Kubernetes. For local development, I’ve chosen k3d due to its lightweight setup, ease of use, and speed, making it ideal for rapid experimentation and testing.

Step 1: Reset k3d

Before we start, let’s ensure that there are no existing k3d clusters running. This will help us start with a clean slate.

To reset k3d and remove all clusters, run the following command:

k3d cluster delete -a

This command deletes all active k3d clusters so you can proceed without any conflicts.

Step 2: Start the Cluster with Port Mappings

Now, let’s create a k3d cluster with one control plane and three worker nodes. We’ll map port 8080 on the host to port 80 inside the cluster. This allows us to expose our services externally:

k3d cluster create mycluster -s 1 -a 3 --port "8080:80@loadbalancer"

This command creates a cluster with load balancing enabled, mapping traffic from port 8080 on your local machine to port 80 within the cluster.

Step 3: Deployment and Service

Next, we’ll deploy a simple Nginx service. First, create a deployment of three Nginx containers:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Then, define a service to expose the deployment within the cluster:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer

Apply these resources to the cluster:

kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-service.yaml

Step 4: Verifying the Deployment

Once the deployment is created, you can use k9s to monitor the status of your pods and services.

Navigate to :deployments to see the live logs from the nginx-deployment. You can also switch to :pods to observe the individual Nginx pods. If you terminate one of the pods, Kubernetes will automatically respawn it, ensuring no downtime, thanks to the ReplicaSet.

you can also curl the service from your local machine:

curl localhost:8080

‘cd’ is a command you probably use every day hundreds of times. Maybe you also have some sort of autocompletion for your shell because it’s faster and more convenient.

Well, I installed zoxide, along with a plugin for the fish shell, and after setting the alias “alias cd=z”, I basically replaced every “cd” with “z”.

This enables me, for example, to type “cd -” and navigate to the previous directory every time. Also, after a while, zoxide will learn your frequently used paths, so you don’t have to type “cd ~/.config/nvim” anymore — a simple “cd nvim” is enough, and the same goes for your project folders.

So just check out zoxide on GitHub to learn how to install and configure your shell with this great tool, improving your speed and convenience even further.

This narrative reflects the state of CentOS prior to the aforementioned transformation:

Previously, CentOS operated as a community-driven initiative that involved retrieving all the source RPMs from Red Hat Enterprise Linux (RHEL) and crafting a functional distribution from them. The sole alterations were the removal of Red Hat’s branding, adhering to legal stipulations. Essentially, CentOS Linux closely mirrored RHEL, differing only in the absence of proprietary branding, and it did not incorporate its own fixes, modifications, or patches.

What has transformed, aside from the nomenclature shift to “Stream,” is this:

CentOS Stream now occupies the position formerly held by RHEL. Therefore, unless one perceived RHEL as unstable, there is no basis to assume that CentOS Stream will exhibit instability.

The designation of CentOS Stream as a rolling release prompted some discontent among users. It is important to note that a traditional rolling release does not inherently imply instability; rather, it involves meticulous testing of packages by maintainers. The distinguishing feature is the potential for significant version jumps in installed packages, leading to notable changes in program behavior.

In the case of CentOS Stream, the alteration primarily involves the elimination of point releases. Instead of transitioning from, for instance, CentOS 7 to 7.1, users receive regular updates. As these updates remain within the same major release, they do not introduce disruptive changes. This framework contrasts with classic rolling releases such as Arch or Gentoo, which lack version numbers.

For those familiar with Debian Stable and the -updates repository, the concept is analogous.

Conclusion

RHEL, characterized as a stable LTS distribution, follows a release schedule spanning 3 years, complemented by a support period lasting a decade. Beyond this, minor releases concurrent with a major RHEL release persist for up to 2 years, providing a consistent ABI guarantee that outlines supported interfaces. This assurance equips developers with precise knowledge about interface stability throughout the 10-year duration.

In comparison, CentOS Stream maintains its status as a stable LTS distribution, featuring a release cadence occurring every 3 years and a support lifespan of 5 years. Aligning with RHEL, CentOS Stream offers an equivalent ABI guarantee.

Traditionally, CentOS adhered to the same cadence and lifespan as the corresponding RHEL release, excluding the extended minor release duration. This distinction is crucial, as CentOS’s stability lagged behind RHEL due to users lacking the option to remain on a minor release for 2 years while still receiving security updates.

This nuance might not be fully grasped by individuals unfamiliar with RHEL, including many Reddit users, encompassing a significant portion of the CentOS community on the platform.

CentOS Stream, while sharing a stability level with CentOS, does not fall short of CentOS’s stability; it is equally robust. Both CentOS and CentOS Stream provide the same ABI guarantee and function as a unified major release channel.

For example CentOS Stream 9 was released September 15, 2021 and will have active Support until May 31 2027.

Gentoo is often referred to as the non-binary distribution, where everything must be compiled from source code. For me, this aspect has always been Gentoo’s greatest strength and, simultaneously, its most significant weakness. Despite being a fervent Gentoo fan, I find myself resorting to Arch in certain environments because, I must admit, compile times on Gentoo, especially on older hardware, can be quite painful.

This is precisely why Gentoo is now expanding its offering of binary packages on their (mirror) servers. While, for most architectures, this is limited to the core system and weekly updates, it’s a different story for amd64 and arm64. There, they boast an impressive >20 GByte of packages on their mirrors, ranging from LibreOffice to KDE Plasma and from Gnome to Docker. Gentoo stable is updated daily!

Despite the newfound convenience, you still retain the flexibility of Gentoo’s USE flags. However, if you find yourself running Gentoo on older hardware or simply wish to avoid lengthy builds, such as with qtwebengine, you have the option to expedite the installation process using binaries on a base system. Later, you can switch back to a non-binary installation, although the installation process with binaries is considerably faster, as illustrated in the screenshot I captured during a fresh installation using emerge, which predominantly utilized binary packages:

I’m using a modded version of dwm as my windowmanager and st as my terminal emulator.

The only modifications I made in this fresh installation were to edit the contents of this new file here:

/etc/portage/binrepos.conf/gentoobinhost.conf

So that the priority is 9999 and to ensure I’m utilizing the nearest mirror:

[gentoobinhost]
priority = 9999
sync-uri = https://mirror.netcologne.de/gentoo/releases/amd64/binpackages/17.1/x86-64/

Also, make.conf should have the following entry to enforce verification of GPG signatures:

FEATURES="${FEATURES} binpkg-request-signature"

emerge -avuDUg @world will now handle the rest.

If you wish to install a package like neovim using emerge, you can do so by employing the “-g” parameter alongside the emerge command to install neovim from the binaries:

emerge -g --ask neovim

If you desire to set the “-g” parameter as the default for your system, modify your make.conf file to ensure that EMERGE_DEFAULT_OPTS reflects your preferred default settings:

EMERGE_DEFAULT_OPTS="-g"

Installation in an virtual environment

If I have to set up a virtual machine, I typically do so using qemu. For me, this is the most versatile and lightweight way to spin up virtual machines.

First, I created a qemu image of 15GB:

qemu-img create -f qcow2 gentoo.qcow2 15g

For this machine, I created this simple shell startup file:

    qemu-system-x86_64 \
      -m 2G \
      -vga virtio \
      -display default,show-cursor=on \
      -usb \
      -device usb-tablet \
      -smp 2 \
      -cdrom install.iso -boot menu=on \
      -drive file=gentoo.qcow2,if=virtio \
      -device e1000,netdev=net0 \
      -netdev user,id=net0,hostfwd=tcp::2222-:22  \
      -cpu Nehalem

and made it executable via chmod +x start.sh.

Now, I downloaded the latest minimal install image from Gentoo and started the VM via ./start.sh.

After the machine was booted up, I started the SSH daemon, assigned a password to root, and was able to SSH into it from a proper terminal emulator.

/etc/init.d/sshd start
passwd root

ssh -p 2222 root@localhost

Gentoo

I did the usual steps for installing Gentoo without any frills. If you don’t have any idea of what you are doing, please read the Gentoo Handbook. It’s awesome.

livecd /etc/portage/binrepos.conf # lsblk
NAME  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
fd0     2:0    1     4K  0 disk
loop0   7:0    0 424.5M  1 loop /mnt/livecd
sr0    11:0    1 466.7M  0 rom  /mnt/cdrom
vda   252:0    0    15G  0 disk
zram0 253:0    0     0B  0 disk

livecd /etc/portage/binrepos.conf # parted /dev/vda
GNU Parted 3.6
Using /dev/vda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted) mkpart primary ext4 1MiB 100%
(parted) set 1 boot on
(parted) quit
Information: You may need to update /etc/fstab.

livecd /etc/portage/binrepos.conf # blkid /dev/vda1
/dev/vda1: UUID="2e7bc77b-40ff-46c2-8d13-3f34cf03742a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="primary" PARTUUID="e28d6e8d-bb87-427e-818b-198d60e23ddb"

livecd /etc/portage/binrepos.conf # mount /dev/vda1 /mnt/gentoo/
livecd /etc/portage/binrepos.conf # cd /mnt/gentoo/
livecd /mnt/gentoo # ls
lost+found
livecd /mnt/gentoo # wget https://distfiles.gentoo.org/releases/amd64/autobuilds/20240114T164819Z/stage3-amd64-systemd-mergedusr-20240114T164819Z.tar.xz
--2024-01-18 13:45:33--  https://distfiles.gentoo.org/releases/amd64/autobuilds/20240114T164819Z/stage3-amd64-systemd-mergedusr-20240114T164819Z.tar.xz
Resolving distfiles.gentoo.org... 195.181.170.18, 212.102.56.182, 195.181.175.15, ...
Connecting to distfiles.gentoo.org|195.181.170.18|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 309232792 (295M) [application/x-xz]
Saving to: ‘stage3-amd64-systemd-mergedusr-20240114T164819Z.tar.xz’

stage3-amd64-systemd-mergedusr-20240114T164819Z 100%[======================================================================================================>] 294.91M  11.1MB/s    in 29s

2024-01-18 13:46:03 (10.3 MB/s) - ‘stage3-amd64-systemd-mergedusr-20240114T164819Z.tar.xz’ saved [309232792/309232792]

livecd /mnt/gentoo # tar xpvf stage3-*.tar.xz --xattrs-include='*.*' --numeric-owner

In recent years, GitLab, for example, made numerous promises about features but struggled to deliver on many occasions. Notably, they still lack support for ARM64 (See Epic).

Moreover, in most cases, I’ve observed that companies don’t necessarily need an exhaustive feature set like GitLab’s. What they often require is CI/CD, Issues, package management, Renovate or Webhooks, in addition to User Management.

With Gitea, I get all of this - and more. I can also run it on a Raspberry Pi or configure it for replication on larger machines.

In this article, I’ll show you how I installed a simple Gitea test instance on a small server (1 CPU, 1GB RAM) and hosted a runner for CI/CD actions. All of this was set up in ~1h. For demonstration purposes, I did not dive into TLS or backup topics, and OAuth2 is not included.

Installation

I followed the official documentation from Gitea and was able to access it on port 3000 within a few minutes. (You can also choose to run it in Kubernetes, install it via Docker, etc.)

For simplicity and a lightweight installation, I chose an SQLite3 Database.

The first user will be granted admin rights. The installation only took a few seconds, and the dashboard was displayed:

I added my public SSH key to my user profile and made sure my ~/.ssh/config was configured to represent the new server, like:

Host IP/HOST
    User git
    Hostname IP/HOST
    PreferredAuthentications publickey
IdentityFile ~/.ssh/me.daniel.meier

I then added a new organization, and within it, a new repository. As you can see, there are numerous options available, including the ability to use a template for our repository, for example:

With the repository in place, my public key added, and my ~/.ssh/config configured, I was now able to follow the steps to make the first commit:

And in the dashboard, everything was displayed as well—perfect!

Runner (CI/CD)

Starting a runner for CI/CD processes is extremely simple. For demonstration purposes, just follow the steps outlined in the documentation. After enabling the actions in the repo settings, I registered my demo runner as a global runner:

Inside my repository, I created the following file:

.gitea/workflows/demo.yaml

name: Gitea Actions Demo
run-name: $ is testing out Gitea Actions 🚀
on: [push]

jobs:
  Explore-Gitea-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a $ event."
      - run: echo "🐧 This job is now running on a $ server hosted by Gitea!"
      - run: echo "🔎 The name of your branch is $ and your repository is $."
      - name: Check out repository code
        uses: actions/checkout@v3
      - run: echo "💡 The $ repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls $
      - run: echo "🍏 This job's status is $."

As my code was pushed to the repository, I checked the runner’s output in my terminal:

And the process was visible from the repository as well:

Enterprise

To run such a setup in an enterprise scenario, I would recommend ensuring a robust backup strategy (testing regularly is crucial) and staying vigilant about version updates. Additionally, always implement TLS, for instance, with an Nginx reverse proxy, and maintain control over user management through OAuth2. Keep a close eye on right-sizing your server to optimize costs.

Conclusion

I’ve only scratched the surface here, but it should give you a glimpse of what is possible with Gitea. It offers many more features needed on a daily basis, such as linking references or closing an issue via commit or PR. Please refer to their documentation for more information.

IT is changing permanently, but one thing has stayed the same over all the years working in this field, and that is the emphasis on reducing costs. If you have commitments to licenses, such as with GitLab or Slack, it can be challenging to reduce them, and often, you end up paying (a lot!) for features you don’t need.

For me, Gitea is a simple yet powerful and highly scalable solution. Easy to maintain and with no licensing costs, it provides a cost-efficient way to grow with it.

The speed and efficiency derived from not relying on your mouse for interactions with k9s is remarkable. By solely utilizing your keyboard, you develop muscle memory, resulting in a faster workflow compared to other programs.

I have been using k9s for several years, and I firmly believe it is the most efficient solution for managing and maintaining Kubernetes clusters. I trust it so much that I regularly use it for version upgrades, and it has never let me down.

Upon opening k9s for the first time, you should expect to receive an overview like this:

As you might be familiar with from vim commands, navigation in k9s allows you to move up and down using j and k. Press Enter to select your kubernetes context.

Upon doing so, it will display a comprehensive list of all your pods:

In the top right corner, you’ll consistently find a list of available commands, extending beyond the fundamental ones. In the pod-view, for instance, you can open a shell with s, view the pod logs using l, or edit the YAML file associated with the pod through e.

Here’s a glimpse into the log-view of my demo-pod:

You might have observed that the menu in the top right has been altered; it now provides options for toggling features such as Autoscroll, FullScreen, etc. while inside the log-view:

No matter where you are in the menu, you can always return to the previous screen by pressing ESC.

I recommend getting acquainted with the search command, which follows the same pattern as vim: /. Pressing / will bring up a search box, facilitating quick searches for namespaces, pods, and more.

Switching between Kubernetes services is straightforward. First, obtain an overview by pressing Ctrl+a:

As demonstrated, I entered / in the aliases overview and typed con, displaying all search results for con in all aliases.

After a few hours, you’ll likely identify the most essential services, enabling you to switch between them rapidly. Simply press the vim-command : and enter the name or shortcut you wish to switch to, like pod (shortcut po) or namespace (shortcut ns).

Remember, you can always look up all aliases via Ctrl+a, and if ever in doubt, press ? to access the general help page.

With this knowledge, while entering command mode and typing a resource name or alias, navigating through frequently used resources could become cumbersome. Allow me to introduce: HotKeys!

You can customize your own HotKeys on a global scale:

$XDG_CONFIG_HOME/k9s/hotkeys.yaml

You have the flexibility to define HotKeys on both a global and context-specific or cluster-specific level:

$XDG_DATA_HOME/k9s/clusters/clusterX/contextY/hotkeys.yaml

Your HotKeys will also be visible on the help page ?.

Example hotkeys.yaml:

hotKeys:
  # Hitting Shift-0 navigates to your pod view
  shift-0:
    shortCut:    Shift-0
    description: Viewing pods
    command:     pods
  # Hitting Shift-1 navigates to your deployments
  shift-1:
    shortCut:    Shift-1
    description: View deployments
    command:     dp
  # Hitting Shift-2 navigates to your xray deployments
  shift-2:
    shortCut:    Shift-2
    description: Xray Deployments
    command:     xray deploy
  # Hitting Ctrl-U view the resources in the namespace of your current selection
  ctrl-u:
    shortCut:    Ctrl-U
    description: Namespaced resources
    command:     "$RESOURCE_NAME $NAMESPACE"
    keepHistory: true # whether you can return to the previous view