LightNews LightNews
banner
usrbinkat.io
@usrbinkat.io
4.1K followers 5.2K following 4.2K posts
🧙‍♀️ Open Sourceress
🚀 Ms. (f)Rizzle @Cisco
🏳️‍⚧️ Blame for Oops & Ops my own
🤗 Seize the means of computing
👩‍💻 K8s/AWS/Azure Platform Engineer
📖 https://blog.usrbinkat.io/en/page/about
🍿Watching Dystopia IRL
🧠 Neuro Spicy Autist
📍 Sacramento ☀
Posts Replies Media Videos
usrbinkat.io
kubectl apply > vm boot > cloud-init > clone kalilix > build flake

She's alive!!!!! 🐉🍦
Screenshot of Ghostly terminal emulator, displaying the K9s Kubernetes utility. K9s shows the console log view of a KubeVirt virtual machine. The terminal shows real-time logs from a cloud-init bootstrap process, with timestamps in brackets on the left and cloud-init detailed installation messages. "Kalilix Bootstrap - Nix-First Multi-Platform" is visible in a decorative ASCII border box. The console logs capture the automated installation sequence beginning with mise package manager installation via curl, followed by successful mise installation to /home/kali/.local/bin/mise. The logs continue with cloning of the Kalilix repository from https://github.com/usrbinkat/kalilix into /home/kali/.kalilix. Multiple green checkmarks indicate successful completion of bootstrap steps including "Installing Nix package manager," "Linux installation complete," "Lix installed successfully," and "Flakes enabled." The installation reports Lix version 2.93.0 on x86_64-linux with experimental features enabled. The final section shows Nix flake evaluation and validation, with the system fetching dependencies from cache.nixos.org and nix-community.cachix.org, evaluating multiple development shell derivations for default, node, python, go, rust, devops, and full environments, each generating unique store paths in /nix/store. This visualization captures the successful orchestration of modern cloud-native development infrastructure where KubeVirt manages a Ubuntu 24.04 VM that automatically bootstraps a reproducible Nix-based development environment through cloud-init userdata. The deployment demonstrates the convergence of Kubernetes virtualization, declarative configuration management, and immutable infrastructure principles, showing how the Kalilix flake provides language-specific development shells while mise coordinates the toolchain installation, creating a fully automated, reproducible development workstation within a Kubernetes cluster.
November 9, 2025 at 11:45 PM
usrbinkat.io
Okay, back to Kalilix but I've moved her from the laptop to the local cloud. Back to porting Kali linux to a Nix ecosystem flake approach.
A screenshot displays a Linux terminal window with a deep purple background and light gray text output. The terminal window shows system information for an Ubuntu 24.04.3 LTS workstation, with the hostname "ghostty" visible at the top in white text centered between the window control buttons. The terminal displays various system statistics, network information, security notices, and command outputs from a user session. The terminal content begins with a welcome message and system identification, followed by three documentation links for Ubuntu help, Landscape management, and Ubuntu Pro support. System information dated Saturday November 8 at 19:58:06 UTC 2025 shows minimal resource usage with 0.0 system load, 31.6 percent of 55.31GB memory usage, zero percent swap usage, and 347 processes running with one user logged in. Two IP addresses are displayed for network interfaces br0 and br1. A prominently featured message about Kubernetes security appears with an associated Ubuntu link. Below this, security maintenance notifications indicate one immediate update available and two additional ESM Apps updates. A bordered rectangular section near the bottom contains Ubuntu workstation details including XRDP port 3389, SSH port 22, and services for RDP, Docker, and Libvirt. The final lines show command outputs for a git repository clone operation of a project called "kalilix" with progress indicators showing successful object enumeration, counting, compression, and delta resolution at 100 percent completion. The terminal session represents a freshly configured Ubuntu development workstation with remote access capabilities and containerization tools ready for use. The presence of Kubernetes messaging, Docker services, and active git operations suggests this is a DevOps or cloud development environment. The successful repository cloning operation shows the user actively setting up their Kalilix development project to port Kali linux to the Nix ecosystem as a Nix Flake.
November 8, 2025 at 11:01 PM
usrbinkat.io
I hear you speaking the language of my people, I run this desk on one of two devices, a dual USBC dock on my M4 work MBP, or my 16C 128GB Ram Nvidia Quadro Xeon Dell Precision laptop.

And clamshell machines can only just barely do this.
November 1, 2025 at 5:33 PM
usrbinkat.io
best github readme image ever

github.com/Jeija/bluefl...
image of a hacked furbie
November 1, 2025 at 1:14 AM
usrbinkat.io
All tests are passing as a service I guess?

If at first you don't succeed, the tests were probably wrong?

Forget TDD, it's passing driven test development.
October 26, 2025 at 2:18 PM
usrbinkat.io
It works! `kubectl apply -f kali-kubevirt-vm.yaml` works!

I took the upstream official kali linux qcow2 image, updated & added cloud-init packages to image and redistribute via dockerhub, then the kubevirt yaml automates the rest!

I estimated 2 hours originally but this journey was so much more.
An xfce desktop for Kali Linux is open inside a KubeVirt VM accessed via Microsoft Remote Desktop, displaying a full-featured penetration testing environment. The Kali application launcher is open, showing the full tree of categorized offensive security tools from reconnaissance to exfiltration. Visible windows include a terminal running `fastfetch` that confirms the system is Kali Linux Rolling 2025.3 with XFCE and the Kali-dark theme, plus Firefox with tabs open to Exploit-DB and Kali-related resources, and a system monitor revealing active services and CPU load. The host machine runs macOS with Microsoft’s RDP app, while the VM is running remotely on a Kubernetes cluster labeled `usrbinkat-optiplexprime`. This image confirms the success of a multi-step iterative process: after debugging boot issues and refining the image pipeline, the Kali Linux VM is now fully provisioned with a graphical desktop, xrdp access, and post-boot cloud-init configuration via a simple `kubectl apply`. The `kubevirt` panel on the left shows three additional VMs also running: Fedora, Ubuntu, and this instance of Kali. The upper terminal window (`ghostty`) displays the virtual machine list in the Kubernetes cluster, showing the Kali VM as `Running` on node `op3` with a provisioned IP address and correct phase status. This milestone marks the completion of a working Kali Linux 2025.3 VDI image deployed entirely from a declarative KubeVirt manifest and cloud-init userdata file. The provisioning script installs XRDP, Docker, Wireshark, configures user accounts and SSH keys, and applies polkit rules for GUI tools—all automated via cloud-init and reproducible through the KMI project. The result is a turn-key, Kali workstation accessible over RDP in Kubernetes, blending offensive security workflows with cloud-native operations.
October 26, 2025 at 5:50 AM
usrbinkat.io
The first boot of the kali vm in kubevirt did not work and i had limited troubleshooting options available without working cloud-init or ssh-server being enabled.

So i deployed a kubevirt fedora 42 vm with rdp and virt-manager to test the qcow2 disk in docker.io/containercraft/kali:latest-dev
A Fedora 42 Workstation desktop is open through the Windows Remote Desktop app on macOS, showing a GNOME overview with multiple running windows. The main view highlights a terminal window where the user `kc2user` is verifying Fedora’s OS release information, confirming it’s Fedora 42 (Cloud Edition). Below it, a Virtual Machine Manager window displays an active VM titled “kali,” running inside the Fedora guest. The Kali desktop is visible within the VM console window, showing a 3D blue grid wallpaper with cables and connectors, indicating a nested virtualization environment where Kali is running under Fedora, which itself is running on bare metal through KubeVirt and accessed remotely via RDP. This setup represents a live debugging and recovery workflow. After the initial Kubernetes deployment of the Kali VM failed to boot properly, the developer pivoted to manual validation by pulling the built `containercraft/kali` image as a `.qcow2` disk, copying it into `/var/lib/libvirt/images/` on the Fedora guest, and spinning up a traditional libvirt VM using Virt-Manager to inspect the image’s boot behavior. The visible Fedora desktop shows both system tools and the nested Kali instance side by side, confirming that nested KVM and libvirt integration are functioning inside the XRDP session. Altogether, the scene captures a layered virtualization testbed: macOS running Microsoft Remote Desktop, connected to a Fedora VM via XRDP, which in turn is hosting a Kali VM through libvirt and QEMU. This configuration demonstrates the robustness of nested virtualization workflows for debugging image pipelines, enabling deep introspection and rebuilds of KubeVirt-ready base images from within their own managed virtualized environments—an elegant example of using the infrastructure itself to diagnose and perfect the infrastructure.
October 25, 2025 at 8:43 PM
usrbinkat.io
First build of the image is published...

...going to touch grass, will try deploying to OptiplexPrime KubeVirt cluster when I get back. 🌱
A Docker Hub page is open to the `containercraft/kali` repository under the "Tags" tab, confirming the successful publication of two new image tags: `latest-dev` and `2025-3-dev`. Both were pushed just 3 minutes ago by the user `katamo`, and both share the same digest `6bb06c7900e0c` for the `linux/amd64` architecture. The image size is listed as 5.42 GB, suggesting it contains a full-featured Kali Linux environment ready for use. The command to pull the latest image is shown as `docker pull containercraft/kali:latest-dev`, verifying the image is now live on Docker Hub and ready for downstream use in virtual machines or containers. This image is the containerDisk backing the KubeVirt virtual machine being built in the previous screenshot. Now that it’s published, it enables automated VM creation via Kubernetes manifests using `kubevirt.io` and Multus network attachments. With this update, users can run a GUI-enabled, XRDP-accessible Kali Linux environment in-cluster for remote access, testing, or full-stack red/blue team exercises—all with the same infrastructure-as-code pipeline used to publish Fedora, Debian, and other base images in the ContainerCraft image library. Together with CircleCI automation, this image pushes KMI’s capabilities into the realm of security-focused development and education. By publishing Kali to Docker Hub, the ContainerCraft team is making it trivial to spawn a fully provisioned Kali VM in Kubernetes for platform security engineering, vulnerability research, or offensive security training—with no local installs required and support for declarative version pinning (`2025-3-dev`) or rolling tags (`latest-dev`).
October 25, 2025 at 5:33 PM
usrbinkat.io
Happy Saturday!

What's cookin? 🍳👩‍🍳
CircleCI dashboard shows an in-progress job titled “customize-kali-linux-amd64”, part of the `build-and-publish-dev` workflow for the `kmi` project under the GitHub organization ContainerCraft. The executor is a Linux machine of the `Large` class, and the job has been running for over 6 minutes. The job is currently executing the “Customize image” step, which includes a bash script building a customized Kali Linux image using the `guestfs` tool. The output reveals provisioning actions like creating user accounts, inspecting machine IDs, and preparing the image for deployment. This confirms the pipeline is constructing a new headless Kali Linux VM image for inclusion in the KubeVirt Machine Image library github.com/ContainerCraft/kmi. Previous steps in the pipeline “Spin up environment,” “Preparing environment variables,” “Checkout code via HTTPS,” “Restore cache”—have completed successfully, showing green checkmarks. The log output for image customization includes low-level commands like `udevadm`, `guestfsd`, and filesystem operations to finalize OS configurations within the disk image. These automated scripts enable reproducible image creation with pre-installed tooling, setting the stage for a full-featured Kali Linux environment. This approach aligns with GitOps and Infrastructure-as-Code principles, allowing developers and security teams to deploy immutable VMs consistently across environments. This screenshot is a teaser for an upcoming feature in the ContainerCraft image library: a Kali Linux VM with full xRDP support, designed for red, blue, and purple team use cases. Built to run inside Kubernetes via KubeVirt, the image provides white-hat hackers and enterprise security engineers with a reproducible, RDP-accessible Kali workstation tailored for penetration testing, reverse engineering, and defensive operations.
October 25, 2025 at 4:59 PM
usrbinkat.io
Ugh, I need the enshitification to end.
Screenshot of a smartphone screen displaying the app info page for TikTok. The TikTok logo and name appear at the top, with three action buttons below labeled "Archive," "Uninstall," and "Force stop." A confirmation dialog overlays the screen, asking: “TikTok — Do you want to uninstall this app?” with two options at the bottom: "Cancel" and "OK." The interface has a dark theme with pink-tinted highlights.
October 25, 2025 at 1:39 AM
usrbinkat.io
I still love how responsive the Fedora + Gnome + xRDP session is, even over wifi there's nearly no discernable lag for general tasks.

gist.github.com/usrbinkat/e8...
A macOS desktop displays the Microsoft Remote Desktop (RDP) app actively connected to a Fedora 42 Workstation virtual machine running on a bare metal Kubernetes cluster via KubeVirt. The Fedora VM, deployed using `containercraft/fedora:42`, shows the GNOME welcome tour's “Let’s Begin” screen. In the bottom-right corner, the RDP app’s connection panel confirms the session is connected to a host named “fedora” under the kubevirt section. The RDP window includes Fedora’s graphical environment, launched via XRDP with cloud-init customization, signifying successful remote GUI access to a virtualized Linux desktop over the network. Behind the RDP window, a terminal session shows live logs from the provisioning process. The terminal displays cloud-init output confirming successful configuration steps: SSH keys injected, XRDP and GNOME desktop environment installed, Docker and libvirt enabled, and custom GNOME settings applied. The provisioning is fully automated using YAML-based Infrastructure-as-Code, specifically via two files—`fedora-42-userdata.yaml` and `fedora-42-vdi-xrdp-gnome-br0-containerdisk.yaml`. These files define user accounts, desktop packages, service configurations, and system settings, along with a multus-bridged network interface for VM-to-LAN connectivity. The image illustrates a modern homelab dev workflow where a developer uses Pulumi and KubeVirt to deploy a fully functional Linux desktop VM on bare metal, accessible via RDP from macOS. Thanks to the combination of `cloud-init`, multus CNI networking, containerDisk images, and virtual machine manifests, the user provisions the entire Fedora 42 workstation stack with XRDP, Docker, GNOME, and user-specific SSH keys. This setup demonstrates how Kubernetes-native virtualization (via KubeVirt) and declarative cloud-init customization can deliver fast, reproducible developer workstations inside a homelab Kubernetes cluster, without sacrificing graphical performance or system integrations.
October 24, 2025 at 7:22 PM
usrbinkat.io
KubeVirt Virtual Machine disk images from DockerHub 👩‍💻☁️

ContainerCraft is heating up 🔥

Many images are already passing the qemu-guest-agent and ssh credential cloud-init testing and promotion pipeline already! ⚙️⚙️⚙️
A dark-themed webpage screenshot from the ContainerCraft GitHub README shows a table titled “Available Images.” The table lists Linux and BSD distributions that are available as virtual machine disk images packaged as OCI containers for KubeVirt use on Kubernetes. The table has six columns: Distribution, Version, Status, amd64, arm64, and Image. Each row corresponds to a different operating system. All entries are marked “Preview” under Status. Most show ✅ for both amd64 and arm64, indicating multi-architecture support. Arch Linux, openSUSE Tumbleweed, and VyOS have ❌ under arm64, signaling no current support for that architecture. Example image tags include containercraft/debian:13, containercraft/ubuntu:24-04, and containercraft/fedora:42. A browser bar at the bottom shows github.com, confirming this is from a GitHub-hosted README. This table is part of the ContainerCraft project for distributing production-ready KubeVirt VM images as OCI container disks. The user is highlighting the progress of automated pipelines that test for cloud-init compatibility, qemu-guest-agent functionality, and SSH connectivity. The images listed are built from upstream sources and designed for seamless integration in cloud-native environments running Kubernetes with KubeVirt. The table showcases architecture support status as the project advances toward stable releases for cloud and homelab use cases.
October 24, 2025 at 4:12 AM
usrbinkat.io
For the low low price of...
Cartoon of a suited salesman slapping the side of a large cargo ship labeled "SS EDMUND FITZGERALD" with a Kubernetes logo on the hull. Text above reads “Used Kubernetes Salesman slaps hull of ship” and below says “This Kubernetes can fit ALL your containers!”—a play on the “slaps roof of car” meme adapted for DevOps humor.
October 20, 2025 at 8:04 PM
usrbinkat.io
So pretty 😍
October 20, 2025 at 1:47 AM
usrbinkat.io
Y'all, and we're back!

It's been almost a year but we have liftoff 🚀

I think I can GA the github.com/ContainerCraft.io/Kargo IaC this winter.

Here is a teaser of what I have on KubeVirt.

Debian 13 Trixie w/ KDE Plasma 6 over RDP deployed from a few lines of yaml to bare metal Talos Kubernetes.
A KDE Plasma desktop is shown in a remote session. The left pane of the Konsole terminal runs `htop`, showing two `usrbinkat`-owned processes for plasmashell and Xorg, with minimal resource usage. The right pane runs `fastfetch`, displaying system info: Debian Trixie 13, Plasma 6.3.6, kernel 6.1.0, Intel i7-6700 CPU, 16GB RAM, 5.8GB used of 57GB disk, and RDP over X11. The taskbar below includes the KDE menu with app launchers like Discover and Dolphin. System uptime is 25 minutes, and the local IP is 192.168.1.158. This desktop is a live result of a Pulumi Kubernetes deployment defining a KubeVirt virtual machine (`usrbinkat-kde`) in YAML, running on bare metal. The VM is provisioned via cloud-init with full KDE Plasma 6, X11, XRDP, and developer tools, built from a `containercraft/debian:trixie-dev` image and deployed with secure UEFI firmware and bridged networking. XRDP is configured to launch sessions using Unix domain sockets with `port=-1`, `sesman.socket`, and `new_cursors=false` to fix KDE rendering issues. Full desktop experience is achieved headlessly over RDP without GPU passthrough, confirming graphical functionality via `fastfetch` and terminal apps. This setup demonstrates declarative infrastructure as code delivering not just a server but a usable GUI dev workstation. Every component—from XRDP socket directories and PolicyKit auth to TLS cert generation and systemd overrides—is provisioned via Pulumi’s Kubernetes provider. It’s not “remote dev” in theory—it’s a live KDE session rendered from YAML.
October 20, 2025 at 1:43 AM
usrbinkat.io
How about 4 big monitors?

🎶🎵.. Na na na smooth criminal da da da🎶🎵
October 16, 2025 at 11:43 PM
usrbinkat.io
In this house, real time:
October 14, 2025 at 5:54 AM
usrbinkat.io
I couldn't count the miles @radicalkjax.com and I have walked this year. Of all the amazing things she does, the walks are probably the most wonderful thing for my heart.

We call them TedWalks✨ cause we're just nerdy chatterboxes and our scope always creeps as we dream and imagine.

scopecreep.zip
A browser window shows the homepage of ScopeCreep.zip, a pastel-toned website with a playful yet polished aesthetic. The header features a pink logo of a sparkling pixel-art .zip file next to the site name in a bubbly gradient font, with the subtitle “Concepts of HealthTech Integration.” Below that, a rounded menu bar links to pages like Our Expertise, Podcast, Speaking, Technical Blogs, and Repos. The main tagline reads, “Professional Tech Discussions with a dash of Glimmer,” followed by a welcoming intro that presents hosts Kali and Kat as trans engineers who fuse technical excellence with joyful, magical creativity. This isn’t a corporate tech site—ScopeCreep.zip is a vibrant portal into the minds of two deeply technical professionals who blend serious cybersecurity, AI, and platform engineering with kawaii style, inclusive energy, and tongue-in-cheek chaos. As the site’s About section elaborates, it’s part zine, part playground, and part mutual encouragement circle for hacking with heart.
October 13, 2025 at 1:21 AM
usrbinkat.io
Why yq is 🔥

Case in point, I pull physical hardware config from talos nodes via Omni api in json, and compare my yaml pulumi stack config in json. Low effort high confidence understanding of the world is priceless in developing workload IaC for this metal.

props @siderolabs.com for a killer OS
Terminal window showing two compact JSON outputs using jq. The top command parses real-time hardware details from a Talos Kubernetes bare-metal node managed by Sidero Omni, including disk models, CPU info, PCI addresses, and network interfaces. The bottom command converts a Pulumi infrastructure-as-code YAML file into JSON using yq, showing Kubernetes configuration for a cluster node pool with tolerations, selectors, resource limits, and metadata labels. This comparison visualizes a developer checking whether the live state of physical infrastructure matches the intended deployment state declared in code. The jq CLI filters and displays both sources in a normalized structure, while yq enables seamless translation of YAML to JSON so that both machine state and desired config can be inspected side by side. What emerges is a streamlined, reproducible feedback loop between actual and declarative environments. It’s a hands-on, DevOps-native audit: YAML turned into actionable truth, shell-native tools bridging abstraction layers, and a reminder that reliable infrastructure lives in the union of what’s deployed and what’s defined.
October 11, 2025 at 4:30 AM
usrbinkat.io
TIL SwiftOnSecurity's greatest obsession is Taylor, greatest nemesis is horses/horse girls, and now you poor unfortunate soul, you must bare the burden of both things being all wrapped up into one.

Where should I send the get well soon care package?

Will you be okay?

(my horses from years ago)
October 10, 2025 at 5:05 AM
usrbinkat.io
🪄💻🔮✨

Hubble so sassy, responded with like "not serving"..

Hubble dramatic.
October 5, 2025 at 8:51 PM
usrbinkat.io
TIL yaml taming!

`~$ yq -c . foo.yaml`
Terminal screenshot shows the command `yq -c . ./workspace/infrastructure/pulumi/helm-chart-kube-prometheus-stack.77.12.0.yaml` being run, which outputs the entire YAML file as a single compact JSON line. The file path and name appear twice—first in a `wc -l` command showing 5434 lines, then with `yq -c`, collapsing those lines into a densely packed, color-coded output. The shell prompt shows the workspace on the `main` branch, using Node v24.9.0 and Python v3.13.7, inside a Docker context. This demonstrates a common developer technique for visually taming massive YAML files by using `yq -c`, which transforms verbose configuration into minified JSON for quick scanning, jq parsing, grepping, or debugging.
October 3, 2025 at 5:30 PM
usrbinkat.io
What's in your Docker Desktop?
Full-screen screenshot of VS Code in a dev container titled “Cisco Security @ desktop-linux,” showing a deeply integrated infrastructure-as-code (IaC) Kubernetes environment in active development. Top left is the Pulumi stack YAML config defining a Talos-based local Kubernetes cluster, launched with Docker Compose. Top center is k9s terminal UI displaying pod health for all namespaces in the Talos cluster, including cert-manager, kube-system, and kubevirt workloads. Bottom left shows Python source code for a custom Pulumi component, `HostPathProvisionerComponent`, declaring Kubernetes resources via Pulumi’s Python SDK. Bottom right terminal displays the output of a Pulumi preview, showing resource updates for RBAC roles, CRDs, and secrets being deployed. The workspace is running on branch `main`, Python v3.12.7, Node v24.4.1, and the prompt reflects a Dockerized environment orchestrated with `mise`. This stack uses Pulumi to declaratively deploy infrastructure into a locally composed Talos cluster, with YAML and Python working in tandem to build modular Kubernetes components. The user is clearly working in an advanced iterative loop: stack configuration is open for editing, IaC logic is visible and modularized, resources are actively being deployed, and k9s gives immediate visual feedback from the live cluster—all within a single devcontainer setup. This is a tightly bound feedback loop between definition, execution, and state verification. Together, it reflects a highly optimized development flow where modern IaC principles meet security-conscious Kubernetes experimentation. This isn’t just code—it’s a reproducible cloud lab running in Docker Desktop. When someone asks, “What’s in your Docker Desktop?”—this is the answer: a real-time, local-first control plane that can bootstrap, mutate, and tear down complex Kubernetes systems on command, with total infrastructure transparency at every layer.
October 2, 2025 at 12:27 AM
usrbinkat.io
When you want to develop a nix flake but you want development to be easy in codespaces.

Say hello to Systemd in Debian 13 Trixie Docker Compose based Devcontainer on GitHub Codespaces remote development environment. Connected via VSCode Remote Containers extension.

Philosophically impure 💀
A Visual Studio Code window with dark theme is open on macOS, connected to a GitHub Codespace for the repo “kalilix.” The left tree shows files like flake.nix, devcontainer.json, docker-compose, setup.toml, and .config/mise for task automation. The center terminal shows logs from a devcontainer running docker.io/library/debian:trixie (Debian 13) with nix installed. Output includes systemd startup, a process tree with /lib/systemd/systemd, nix develop, dbus-daemon, nix-daemon, and vscode-remote processes, ending with “Outcome: success” and “Finished configuring codespace.” The right terminal runs nix flake show inside the shell “kalilix-base-env,” listing devshells for aarch64-darwin, aarch64-linux, x86_64-darwin, and x86_64-linux, with omitted entries for python and rust, plus overlays including Nixpkgs. Git remote -v confirms origin at github.com/usrbinkat/kalilix. Technically, this shows a flake-managed devcontainer built with Docker Compose. Nix flakes handle dependency management, mise replaces Make for workflow automation, and the flake defines multi-arch devshells with overlays for polyglot development. Systemd runs in the container, enabling nix-daemon, dbus, and vscode integration. Logs confirm deterministic startup through flake shell availability. Overall, the screenshot illustrates how kalilix provides a reproducible Kali Linux–style dev environment on nix. All dependencies and overlays are versioned in the flake, ensuring consistent builds across Darwin and Linux. By pairing nix for package management with mise for tasks like linting, testing, and lifecycle updates, the project treats environments as code, giving teams a single repeatable foundation for development and CI.
September 28, 2025 at 6:37 PM
usrbinkat.io
Webex Millennial discrimination conspiracy!!!
A Webex pop-up error message on a dark purple background with the Webex logo at the top reads, “Too many reactions for this message. We can’t add any new reactions to this message because the limit is already hit.” At the bottom is a bright pink button labeled “Dismiss.”
September 17, 2025 at 4:43 PM