Coder Legion - Recent posts tagged ubuntu

Node 22.22 runs TypeScript. Ubuntu's Node 22.22 doesn't.

Tue, 27 Oct 2026 14:27:58 +0000

Four test files in my site's repo import TypeScript directly. faq.test.mjs pulls in src/lib/faq.ts, and three others do the same with their own modules. There is no build step and no loader in between: the script is node --test "test/*.test.mjs", and type stripping has been on by default since Node 22.18.0, so Node strips the types and runs what's left.

In CI those tests pass. The workflow asks actions/setup-node for node-version: "22", and the latest runs on main are green.

On my Ubuntu server, with Node 22.22.1, all four fail before a single assertion runs:

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for .../src/lib/faq.ts

22.22.1 is newer than 22.18.0, so on paper the feature is there. The version number was right. The binary behind it was a different build.

Same version, different binary

Node will tell you whether it strips types. The v22 docs describe process.features.typescript as "strip" by default, "transform" with --experimental-transform-types, and false if Node is started with --no-experimental-strip-types.

I did not pass that flag:

$ /usr/bin/node --version
v22.22.1
$ /usr/bin/node -p 'process.features.typescript'
false

That node comes from Ubuntu's nodejs package, version 22.22.1+dfsg+~cs22.19.15-1ubuntu1. Asking for the feature explicitly does not bring it back:

$ /usr/bin/node --experimental-strip-types t.ts
node:internal/util:226
    throw new ERR_NO_TYPESCRIPT();

To rule out the version itself, I downloaded the official 22.22.1 build from nodejs.org, checked it against SHASUMS256.txt, and asked the same question. It printed strip and ran the same .ts file without complaint.

Where TypeScript went

The package's own changelog explains most of it. The December 2024 entry, 22.12.0+dfsg-1, says:

dfsg-exclude amaro, build without it - it requires swc. This disables the ability to execute TypeScript files using the --experimental-strip-types flag.

The November 2025 entry, 22.21.1+dfsg+~cs22.19.0-1, says: "we build without-amaro for now, disable strip-types".

The March 2026 Debian entry, merged into the version I have, says: "Drop 'no amaro' patch, solved upstream". The build still answers false, and it reports how it was compiled:

$ /usr/bin/node -p 'process.config.variables.node_use_amaro'
false

The official 22.22.1 build prints true.

The changelog doesn't say what "solved upstream" changed. My tests only see what the build does.

Why CI never saw it

The setup-node README says the action first checks the runner's tool cache, then pulls LTS versions from the actions/node-versions releases and, on a miss, falls back to downloading from nodejs.org. None of those is Ubuntu's package. The four test files pass in CI, so the Node there strips types. The one on my server does not, and both report major version 22.

That is how one repository can be green in CI and red on my server without a line of code changing.

The fix

I extracted the official Node 22.23.2 tarball into /usr/local. /usr/local/bin comes before /usr/bin in PATH, so node now resolves to the official build, with npm 10.9.8 bundled.

I left the Ubuntu package installed. On this machine 15 installed packages depend on nodejs: handlebars and 14 node-* libraries. Removing it to get the right node would have meant fighting apt over things that have nothing to do with my site.

Same four files, official binary:

# tests 42
# pass 42
# fail 0

Ask Node what it can do

If a project relies on type stripping, node --version is not the check. This is:

node -p 'process.features.typescript'

On the two builds above it prints strip when the feature works and false when it doesn't, whatever the version string says. It belongs in a setup script next to the version check, because on my server the version check was the one that passed.

From Silence to Sound: Fixing Audio on Ubuntu Linux on my Samsung Galaxy Book

Mon, 26 Oct 2026 19:05:37 +0000

Over four days. That’s how long I spent trying to get the internal speakers on my Samsung Galaxy Book2 (NT950XDA) to produce a single sound after switching from Windows to Ubuntu.

And I wasn’t alone.

The Problem

Right out of the box, Ubuntu (even the latest 24.04) doesn’t play well with the Realtek ALC298 audio codec on many Samsung Galaxy Book devices. Headphones might work, but internal speakers remain silent due to uninitialized smart speaker amps.

I found myself crawling through obscure forum posts, GitHub issues, and deep dmesg logs. I came across broken workarounds, kernel parameters, even dead-end firmware downloads. Nothing stuck — until I discovered a promising thread from the Manjaro community and a early work of @joshuagrisham.

The Breakthrough

The answer turned out to be hda-verb, a tool for sending manual codec commands to initialize the amp. After copying dozens of lines of hda-verb commands into a script and running it manually, audio finally burst through my speakers.

It worked—but only until the next reboot.

The Automation

That’s when I decided to build a real solution:

Auto-run the fix at boot and after resume
Avoid breaking any existing audio setups
Use systemd services for reliability
Keep it simple, safe, and open source

The Tool: galaxybook-linux-setup

Now available on GitHub: https://github.com/topzyray/galaxybook-linux-setup

Features:

Initializes smart speaker amps via hda-verb
Runs fix on boot + resume using systemd
Disables PulseAudio's suspend-on-idle to prevent speaker freezing
Backs up existing config files to avoid damage
⚙️ Detects your current user and system safely
MIT-licensed, contributions welcome

Installation is as easy as:

git clone https://github.com/topzyray/galaxybook-linux-setup.git
cd galaxybook-linux-setup
chmod +x install.sh
./install.sh

Reboot when prompted, and you’re done. No more silent boots.

Who This Might Helps

Galaxy Book2 NT950XDA users or other device with similar issue or device/driver info
Anyone with Realtek ALC298 codec and no speaker output
Linux newcomers switching from Windows
Ubuntu/Mint/Pop_OS/Manjaro users on 5.8+ kernels though I tested on 6.14.

Credit Where Due

Joshua Grisham @joshuagrisham – GitHub
Community post from user @drlucas – Manjaro Forum
Access hda-ver used here

The Bigger Picture

This project reminded me why open source matters. Without the knowledge of those before me, I’d still be rebooting into silence.

Now, I’m extending this to include fingerprint readers, screen brightness fixes, and more for Galaxy Book users and I will also be testing on other devices. Please you can test too.

NOTE: The script does not delete any file rather it create a backup whenever updating an existing file.

Have a similar issue? Found this useful? Contribute, fork, share, or open an issue!

Repo: https://github.com/topzyray/galaxybook-linux-setup

If you have further question, suggestion or observations please leave them in the comment section. Thank you for reading.

Ubuntu Resolute: Evolution Instead of Revolution

Mon, 14 Sep 2026 04:35:11 +0000

With the 2026 Ubuntu LTS release, we’re seeing evolution instead of revolution across the board. Mostly small version updates, a recent kernel in version 7, and many updates under the hood.

An overview of available software versions for the most commonly used services can be found in our documentation.

What Does It Take to Implement a New Ubuntu Version?

Have you ever asked yourself what it takes us to implement a new Ubuntu LTS version in our ecosystem? It’s a little more complicated than imaging a USB stick. We’ll take you through our implementation journey.

An Early Look

On April 23, 2026, Ubuntu Resolute was publicly released, with a “Beta” preview a month prior.

Shortly after the Beta release, we had a first look at the new release. With clarity about the used Ruby version, we knew what it would take to update our self-service tools such as nine-manage-vhosts, nine-manage-databases, and FTPAdmin2. We also run some tools not directly used by customers but of importance to us and our automation landscape.

Following our first hands-on, we created the backlog items we considered mandatory for the implementation.

Step by Step

The first issue to solve was around the package manager and package sources. With some deprecations in apt 3.1, updates for our automation around our package mirrors (we mirror the Canonical repositories for all Ubuntu versions) as well as package sources became necessary.

After addressing these first issues, we needed to build a “packagebuilder” image for the new Ubuntu version. This container image is used in automated pipelines to build Debian packages like nine-manage-vhosts and nine-manage-databases, but also Prometheus exporters.

Prometheus is used for monitoring at Nine, and exporters are the metrics source our alerting is based on. We build more than 20 exporters that aren’t uniformly designed and need customisations in their build processes.

To test these packages in a “real” system environment (as opposed to a container, where things like systemd are missing), we built a VirtualBox VM image of Ubuntu Resolute, which we use to run tests of our self-built packages.

Once we had finished building our automation and monitoring tools, we could dive deeper into the automation of our Managed Services.

With Ubuntu Resolute, many services got updated systemd units and AppArmor profiles. This improves security but also required some changes and tests, for example to our Apache and MariaDB automation.

One of the changes to systemd resulted in /tmp partitions or folders that are no longer backed by system storage. Instead, /tmp uses a tmpfs partition type, which uses system memory to store data.

System memory is valuable, and many applications and services use /tmp for short-lived data that might require quite some storage. A tmpfs partition doesn’t meet our requirements for a server environment, so we reverted to a storage-based solution.

Most of these tasks are independent of the type of system, virtual or dedicated. But of course, we also needed to adapt our automated dedicated server provisioning for Ubuntu Resolute.

A Little Revolution

In the past years, the companies behind Elasticsearch and Redis have tried to further commercialise their open-source services and changed the licensing model of their software.

Although both companies have since returned to open-source licenses, rebuilding lost trust is difficult. In the meantime, the open-source ecosystem has continued to evolve.

In our offering, Elasticsearch has since been superseded by OpenSearch.

After Redis announced a license change in 2024, we thought we were prepared, as we had already implemented KeyDB as an alternative a year before. What looked promising at first (e.g. Redis compatibility, the possibility to run multi-primary replication) has turned out to be a dead end: the KeyDB project has since been abandoned.

In 2024, following the license change, another Redis fork named Valkey was released. Broad support from industry leaders such as AWS, Google Cloud, Percona, Oracle, and more has helped Valkey gain momentum quickly and establish itself as the de facto alternative to Redis.

With Ubuntu Resolute, Valkey 9 has found its way into the Ubuntu “main” repository. The main repository contains software that’s supported by Canonical during the entire lifecycle of the Ubuntu release.

As Valkey in version 9 is fully compatible with Redis 7.2.4, and Redis remains in the “universe” repository (a “community maintained” repository), the decision to use Valkey from Ubuntu Resolute onward was an easy one for us: fully compatible with the latest Redis version we offered (7.0 in Ubuntu Noble), but actively supported throughout all lifecycle phases of Ubuntu.

Engineering Summary

This implementation journey doesn’t just provide a broad overview of some technical challenges, it also gives an idea of how Nine engineers work and which tools and processes we use.

Many of the backlog items iteratively built on each other. Besides the engineering and quality control effort, we also need to ensure that changes don’t cause side effects on older Ubuntu versions, since all versions are automated through the same codebase.

After 76 merge requests linked to 20 backlog items, the first Ubuntu Resolute systems were delivered to our customers on June 29, 2026.

Ansible Installation and Configuration On Ubuntu

Wed, 08 Jul 2026 00:14:52 +0000

Introduction

What is Ansible?

Ansible is an automation language that can describe any IT environment, whether home-lab or large-scale infrastructure. It is easy to learn, beautiful code that reads like clear documentation.

There are many repetitive tasks that we may perform on a server, a VM, or a VPS. The tasks can range from setting up SSH keys to disabling the root user to firewall configs. If you manage multiple servers daily and you have to do the same configuration over and over, Ansible can automate the process, allowing you to increase your productivity.

It requires installing Ansible on the Control Node and just having Python 3 installed on the Managed Node.

What is the Control Node?

It's simply the system that Ansible is installed on that controls the remote machines.

What is the Managed Node?

A remote system, or host, that Ansible controls. Ansible is agent-less, so you don’t need to install Ansible on the managed node; you simply need Python 3 to be installed.

Install Ansible on Ubuntu (Control Node—local machine. Running ZorinOS).

your-command-prompt:~$ sudo apt update

your-command-prompt:~$ sudo apt install software-properties-common

your-command-prompt:~$ sudo add-apt-repository --yes --update ppa:ansible/ansible

your-command-prompt:~$ sudo apt install ansible

Note: Ensure that Python 3 is installed on your remote server. At this time of writing, Ubuntu 26.04 LTS has Python 3.14.4 installed by default. This is enough to get your remote server running with Ansible.

Create an inventory folder with a host file.

This file contains a list of the remote machines, VMs, or VPSs that you want to control using Ansible.

For this step you can use a code editor; I will be using Vs Code.

Create a folder called Ansible and open it in vs code
In that folder, create another folder and name it inventory
Inside the inventory folder, create a file named hosts with no extension

hosts file

Start with an attribute; give it whatever name you want.
[servers]

Then list the servers that you want to manage using their DNS names or their IP addresses.
[servers]
vpsServer ansible_host=10.10.100.45
work-ToRule
10.10.45.62

We can give our hosts an alias by passing in their IP address to any name we wish to give it. In the list above, I have given the VPS with IP address 10.10.100.45 an alias of vpsServer. (IP address, just an example)

Create a folder named Playbook

In this folder we will create the actual yml files that we will use to automate the different processes we want to run on our remote servers. It can be an update, firewall config or install a package.

Our first playbook will update the Ubuntu server and set the right timezone. I will name it apt-update.yml.

Examine the YML file.

- hosts: "*" — this means all remote hosts will be updated. A single host can be selected by either its alias, DNA name, or IP address.

become: true—gives Ansible the administrative authority to act as a sudo user.

serial: 1 —In Ansible, serial: 1 tells the automation engine to manage your servers one by one rather than updating all of them at the same time.

tasks —In Ansible, the tasks section is structured as a list of individual actions. Each task is a YAML block that breaks down into four main parts: the Identity, the Module, the Arguments, and Directives.

- name: This is a plain-text description of what the task does and always starts with a dash or hyphen.

The Collection (community.general): An Ansible Collection is a standardized packaging format used to bundle and distribute Ansible content, including playbooks, roles, modules, and plugins.

The Module (timezone): This is the specialized tool or command line plugin you want to use. It tells Ansible how to execute the action on the server. Instead of writing raw terminal commands, you use abstract modules like apt (for packages), copy (for files), user (for accounts), or service (for daemons).

The Parameters (name: America/Port_of_Spain): These are the specific settings, options, or instructions you pass into the module. It defines the exact parameters of your action. The name: parameter is a mandatory argument required by the community.general.timezone module. It specifies the exact geographical timezone identifier you want to apply to the target Linux operating system.

If you're new to Ansible, you can find a collection of the modules and arguments available @ https://docs.ansible.com/projects/ansible/latest/collections/index.html

Run Playbook

Connect to the remote host in your terminal.

your-command-prompt:~$ ANSIBLE_HOST_KEY_CHECKING=FALSE ansible -i ./inventory/hosts vpsServer -m ping --user root --ask-pass

ANSIBLE_HOST_KEY_CHECKING=FALSE
This is a temporary environment variable that changes how Ansible handles security signatures. It tells Ansible to skip looking inside your local ~/.ssh/known_hosts file. It allows you to connect to a fresh or reinstalled VPS instantly without throwing the strict “Host key verification failed” fingerprint error.

ansible
This invokes the ad-hoc command line engine (used for running single, quick tasks instead of running an entire playbook file)

-i ./inventory/hosts
The -i flag stands for Inventory. It tells Ansible exactly where your infrastructure map file is saved. In this case, you are instructing it to bypass any default system paths and read the specific file named hosts located inside your ./inventory/ folder

vpsServer
This is the specific destination target. Ansible looks into your inventory to find a server or group named exactly vpsServer to run the task against.

-m ping
The module flag. It tells Ansible to execute the built-in ping software module. This is a diagnostic module that logs into the server, checks if Python is available, and returns a successful green"pong"if the link is healthy.

Once you get a green ‘pong’ you can run the next command.

your-command-prompt:~$ ansible-playbook ./playbooks/apt-update.yml --user root -e “ansible_port=22" --ask-pass --ask-become-pass -i ./inventory/hosts

ansible-playbook
This invokes Ansible's playbook execution engine. Unlike the simple ansible command (which runs just one quick ad-hoc task), ansible-playbook is designed to open an automation script file and run a whole sequence of structured tasks in order.

./playbooks/apt-update.yml
This is the relative file path to the exact automation script you want to run. : You are telling Ansible to open the file named apt-update.yml inside your playbooks folder and execute whatever configuration steps (like package updates or installations) are written inside it.

--user root
This asks Ansible to establish the initial SSH network connection using the root account, completely ignoring any other default usernames written inside your configuration files.

-e “ansible_port=22”
The -e flag stands for Extra Variables. This dynamically injects a temporary variable into the execution. Here, you are explicitly forcing Ansible to connect over standard Port 22, overriding any custom ports (like 2222) saved in your host files.

--ask-pass
Tells Ansible that you are using password authentication instead of an SSH key token. It forces the terminal to prompt you for the root SSH login password when you launch the command.

--ask-become-pass
This tells Ansible to prompt you for the privilege escalation (sudo) password.

Note: Since you are logging in directly as the absolute system master (root),--ask-become-pass is actually redundant here because root already has absolute power and never needs to escalate further.

-i ./inventory/hosts
The -i flag maps your Inventory. It tells the playbook engine exactly where to look to find your list of servers. You are directing it to read the specific hosts file located inside your ./inventory/ folder.

Summary of the Execution Flow

When you execute this command from your Control Node terminal, Ansible handles it in this sequence:

It opens your./inventory/hostsfile to look up the IP address of the target server.
It stops and asks you to type the SSH password (due to –ask-pass).
It stops and asks you to type the Sudo password (due to –ask-become-pass).
It bypasses port variables, connects directly to Port 22 as root, opens up your apt-update.yml playbook, and begins executing its tasks.

Conclusion

I want to give a shout-out to Aldo @https://dev.to/aldo_cve. He recommended Ansible in a previous post I published, and I looked it up.

I found Ansible to be a great addition to my workflow in setting up my backend. I hope you guys enjoyed this walk through. You can look forward to more posts where I publish some of the playbooks that I find useful.

Surviving a Kernel Panic: My Ubuntu War Story

Wed, 22 Apr 2026 11:08:36 +0000

When your backlog is full of data science models and software engineering tasks, the last thing you need is your OS failing to boot because of a kernel panic, no?

Well, this happened to me. I was given the option to reboot, did it the first time, and I was back in after choosing an older kernel version from the menu. It happened a second time, a third time... and I was just okay with it, saying, "I'll fix it later."
This worked like a charm right up until Linux decided it had had enough. It finally threw an Input/output error, locked the root filesystem / into Read-only mode, and locked me out completely.

I couldn't even poweroff via the terminal.

The silver lining came when I realized I had a Kali Linux installer ISO sitting on a flash drive nearby. In case you find yourself in this,let's call it "very specific" situation, here is how to perform open-heart surgery on your system before you do anything rash like wiping your drive.

Step 1: The Hard Reset & The USB Boot

Since the terminal was completely frozen, a graceful shutdown was out of the question. Long-press the power button to force the PC to power off. Turn it back on and immediately open your startup menu (usually by spamming Esc, F12, or F9 depending on your laptop model). From there, boot directly into your rescue USB.

Step 2: Dropping into the Underworld (The BusyBox Shell)

Because I was using a Kali Linux installer ISO (not a Live Desktop), there was no beautiful graphical interface to save me. I had to navigate the installer menu and select "Execute a shell".

This drops you into a raw, stripped-down BusyBox ash shell. From here, we need to find exactly where the broken Ubuntu system lives on the hard drive.

Run this command to list your partitions:

fdisk -l

Scan the output for your main Linux filesystem. In my case, Ubuntu was sitting on /dev/sda2.

Step 3: Find and repair

Because I was forced to hard-reset the machine multiple times while the OS was locked up, the filesystem metadata was corrupted. Files were left hanging in memory, creating "orphaned inodes." If you try to boot with a corrupted filesystem, Linux will panic to protect your data.

NOTE: Make sure your broken partition is not mounted.
Quick check just to be safe:

umount /dev/sda2/

It's time to repair the drive. Run the ext4 filesystem check tool on your specific partition:

e2fsck -y /dev/sda2

(Tip: The -y flag is crucial here. It automatically answers "yes" to the hundreds of prompts asking if you want to fix individual corrupted sectors. Without it, you will be holding down the 'Y' key for an eternity).

Once the screen stops scrolling, you are looking for the holy grail: a message declaring your drive /dev/sda2: clean.

With the filesystem repaired, type reboot (or hard reset again if the shell is stubborn) and unplug the USB.

Do not let it boot normally. As soon as the PC turns on, spam esc to bring up the GRUB boot menu. Go to Advanced options for Ubuntu and manually select an older kernel version (e.g., 6.14.x instead of the newest one).

Once you are successfully booted into your desktop, open a terminal. It is time to find the killer. List all installed kernels:

dpkg --list | grep linux-image

If you read the output carefully, you'll likely spot the culprit. Look at the two letters on the far left of the list:

ii means Installed and Intact (This is your stable, older kernel).

it means Installed, Triggers pending (This is a half-baked, broken kernel).

In my case, the system had tried to automatically update to the 6.17 kernel in the background. But a third-party module, specifically VirtualBox DKMS, failed to compile for the new kernel architecture. VirtualBox crashed, which halted the entire kernel installation halfway through, leaving my machine with an unbootable OS.

Step 5: The Execution(Purging the Rot)

Now we just need to clean up the mess and permanently delete the broken kernel so the system stops trying to default to it.

First, get the blocking software out of the way (you can reinstall it later):

sudo apt remove --purge virtualbox-dkms

Next, tell the package manager to unjam itself and fix any half-installed dependencies:

sudo apt --fix-broken install

Now, drop the hammer on the broken kernel (replace the version numbers with the broken one from your dpkg list):

sudo apt purge linux-image-6.17.0-19-generic linux-headers-6.17.0-19-generic

Finally, sweep up the orphaned packages and update your boot menu to lock in your stable kernel as the new default:

sudo apt autoremove
sudo update-grub

All good ✨

A little note...

Isn't it funny how things completely falling apart is usually the best way to figure out how they actually work?

But hey, in case you found yourself in this situation, found your way here, and this still doesn't work... you should probably just delete that OS or contact your local AI agent.

I Ported ComfyUI Desktop to Ubuntu 26.04 1 a day till I run out!

Wed, 15 Apr 2026 03:17:57 +0000

And Another One!

Another Desktop App ported to Linux That was not available. I will Keep going until release day or I run out of apps to port. Let me Know what one you would like to see next!

The official ComfyUI Desktop app ships for Windows and macOS.

I wanted it on Ubuntu 26.04.

So I ported it.

Not a web wrapper. Not a fake launcher. Not a shell script around a browser tab.

The actual desktop app.

The Goal

I had two requirements:

build the real app on Linux
make it usable on a machine that already runs ComfyUI normally

That second one mattered more than people think.

If a Linux user already has:

a real ~/ComfyUI install
a running server on 127.0.0.1:8188

then the desktop app should not pretend the machine is blank and try to push a fresh install into ~/Documents/ComfyUI.

That is bad product behavior, even if the package technically launches.

The Starting Point

The upstream repo is here:

https://github.com/Comfy-Org/desktop

At first glance it looks cross-platform enough:

Electron app
bundled frontend assets
uv bootstrap
asset build pipeline
electron-builder config with Linux bits already half-present

But “half-present” is the dangerous state.

That usually means:

some paths exist
some assets exist
some packaging config exists
and the app still does not actually ship on Linux

Which is exactly what was going on here.

The Real Problems

There were a few distinct failures.

1. Linux was gated out of asset/bootstrap flow

The app would build fine for supported platforms, but Linux was not being carried all the way through asset setup and build verification.

That meant some Linux artifacts were never properly prepared even though the source tree looked close.

2. Packaged builds were missing `desktop-ui`

This was the first hard packaging bug.

The app launched, then died with a file-not-found error because the packaged build did not contain the desktop onboarding UI bundle.

That is the kind of bug that makes a port look dead before you even get to runtime behavior.

3. AppImage hit Electron sandbox issues

This is the standard Linux Electron tax.

The AppImage mounted fine, but Chromium tripped over the sandbox helper and aborted before the app could become useful.

I did not waste time pretending AppImage was the right hill to die on.

For Ubuntu, .deb was the better target.

4. Linux runtime assumptions were wrong

The app still had platform checks and install behavior that were effectively “Windows/macOS first, Linux later.”

A Linux port cannot just compile. It has to stop acting like Linux is unsupported at runtime.

5. Existing Comfy installs were ignored

This was the most important UX issue.

On my machine, ComfyUI was already installed and already running in the browser.

The desktop app still tried to start from scratch and push a managed install path into Documents.

That is technically launchable, but functionally wrong.

So I fixed it.

What I Changed

I split the work into build fixes, runtime fixes, and “make it behave like a sane Linux app” fixes.

Build and packaging fixes

enabled Linux asset bootstrap
enabled Linux build verification
packaged the missing desktop-ui bundle
switched the Linux target to .deb

Runtime fixes

added Linux config/reset path handling
made Linux hardware validation non-fatal
added fallback behavior for missing compiled requirements
added Linux-safe Electron startup defaults

Existing-install behavior

This was the good part.

I changed the app so it now:

prefers an existing ~/ComfyUI directory as the default base path
detects a live local Comfy server on 127.0.0.1:8188
persists external-server mode into desktop config
skips the desktop-managed venv validation path when attaching to that external server
opens the frontend against the already-running instance instead of forcing first-run install flow

That last bit is what makes the port feel real instead of merely “bootable.”

Why `.deb` Won

I know someone will ask why I did not just ship AppImage.

Because Ubuntu users need something that works, not something ideologically pure.

The .deb route gave me:

stable installation under /opt/ComfyUI
normal desktop integration
no AppImage sandbox headache
a clean launcher path

On Linux, packaging format is not theology. It is operational reality.

What the App Does Now

On an Ubuntu 26.04 machine with an existing Comfy setup:

launch the desktop app
it detects ~/ComfyUI
it sees the live server on 127.0.0.1:8188
it stores that as the desktop install state
it attaches instead of onboarding

That is the behavior I wanted from the start.

Commands I Actually Used

Install dependencies:

corepack enable
corepack yarn install

Bootstrap app assets:

corepack yarn make:assets

Verify:

corepack yarn typecheck
corepack yarn vitest run

Build the package:

corepack yarn make

Install the package:

sudo apt install ./dist/ComfyUI-0.8.30-amd64.deb

The Nice Surprise

The upstream repo was not hopeless.

This was not one of those situations where “Linux support” secretly meant rewriting the app from scratch.

Most of the work was:

finishing incomplete Linux paths
fixing packaging omissions
picking the right distribution target
making startup logic respect an existing local Comfy workflow

That is still real work, but it is not fantasy.

The Useful Lesson

A port is not finished when the window appears.

A port is finished when the app behaves correctly on the target machine.

For this one, the difference was:

not just “ComfyUI Desktop launches on Ubuntu”
but “ComfyUI Desktop understands an Ubuntu user who already runs ComfyUI”

That is the difference between a demo and a port.

Upstream and Source

Upstream desktop app: https://github.com/Comfy-Org/desktop
ComfyUI core: https://github.com/comfyanonymous/ComfyUI

My Repo

https://github.com/johnohhh1/comfyui-desktop-port-linux.git

git clone https://github.com/johnohhh1/comfyui-desktop-port-linux.git

Here is the Kimi Desktop on Ubuntu 26.04 noone asked for..... Because I am creating 1 desktop a day

Tue, 14 Apr 2026 03:17:32 +0000

I decided I am going to create 1 desktop app a day for the new Ubuntu release because noone ships linux. It's crazy they expect us to dev in linux but ship for windows and mac but you know what ? I am tired of bouncing back and forth! Linux for this windows for that ohhh check in on the kids switch to mac. It;s enough. So here is app 5 (if you dont count the Voicebox I made earlier today because their junk was busted and their instructions were just build it from source... Yeah thanks Chad...Here ya go. "Kimi Desktop on Ubuntu 26.04: Fixing the Broken .deb with Tauri v2"

"The official Kimi desktop app can't install on Ubuntu 24.04+ because it depends on a removed library. Here's how I rebuilt it with Tauri v2 and Pake v3 to fix it."

You install the official Kimi desktop .deb, fire sudo dpkg -i, and boom:

dpkg: dependency problems prevent configuration of kimi:
 kimi depends on libwebkit2gtk-4.0-37; however:
  Package libwebkit2gtk-4.0-37 is not installed.

That library doesn't exist on Ubuntu 24.04, let alone 26.04. It was removed from the repos over a year ago. The official Kimi desktop package is built on Tauri v1, which hard-depends on libwebkit2gtk-4.0.so.37 — a library that shipped with webkit2gtk 4.0, superseded by 4.1 and then dropped entirely.

So the app is just... broken on any modern Ubuntu. Here's how I fixed it.

The problem in one sentence

Tauri v1 → libwebkit2gtk-4.0 → removed from Ubuntu 24.04+ → dpkg fails.

The fix: rebuild with Tauri v2

Tauri v2 links against libwebkit2gtk-4.1, which is the version shipped in Ubuntu 24.04 and 26.04. So the fix is straightforward: rebuild the app with Tauri v2 instead of v1.

I used Pake v3, which wraps any web app into a native desktop app using Tauri under the hood. One build script, one config file, and you get a .deb that actually installs.

What you get

Tauri v2 runtime — Links against libwebkit2gtk-4.1, the one Ubuntu actually ships

OAuth / SSO — --new-window flag means Google sign-in works in-app instead of being blocked

System tray — Desktop integration that works

1200x780 window — Matches the original Kimi desktop dimensions

Rebuild it yourself

Prerequisites — Rust, Node, and the usual GTK/webkit dev packages:

# Rust >= 1.85
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Node.js >= 22 — use nvm, brew, whatever you prefer

# Build deps
sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev \
  libayatana-appindicator3-dev librsvg2-dev

# Pake CLI
npm install -g pake-cli

Then it's one command:

./build.sh

The .deb lands in dist/. Install it:

sudo dpkg -i dist/kimi_1.0.0_amd64.deb

Done. Kimi runs natively on Ubuntu 26.04 with no missing libraries.

The config that makes it work

Everything lives in config/pake.json. The important bits:

{
  "windows": [{
    "url": "https://kimi.moonshot.cn",
    "new_window": true,
    "width": 1200,
    "height": 780
  }],
  "user_agent": {
    "linux": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
  }
}

The two things that matter:

new_window: true — Without this, OAuth popups (Google sign-in, etc.) get blocked by the webview's navigation policy. This flag tells Pake/Tauri to open them in a new window instead.
user_agent.linux — Spoofing a Chrome UA because some OAuth providers reject webview user agents.

Why not just use the web app in a browser?

Fair question. A native desktop app gives you:

Alt-Tab separation — Kimi isn't buried among 40 browser tabs
System tray — Quick access, stays running in the background
Own window chrome — Feels like an app, not a tab
Smaller memory footprint — Tauri uses the system webview, not a bundled Electron instance

The repo

github.com/johnohhh1/kimi-app

Clone it, build it, install it. If you're on Ubuntu 24.04+ and want Kimi as a desktop app, this is currently the only way that works.

Uninstall

If you need to remove it:

sudo dpkg -r kimi

Kimi is a product of Moonshot AI. This project uses the open-source Pake tool (MIT license) to wrap the Kimi web interface as a native desktop application.

I Ported the Ollama Desktop App to Linux Just in Time for Ubuntu 26.04 LTS

Sat, 11 Apr 2026 22:50:53 +0000

Ubuntu 26.04 LTS drops this week. I've been running the RC for months. And I think it's going to be the release that finally pulls a meaningful chunk of people off Windows — especially AI-curious developers who are tired of the telemetry, the forced updates, and the general feeling that Microsoft is treating them like a product.

So I've been on a mission: take the cool AI tooling that still assumes Windows or macOS, and make it work natively on Linux.

This week's project: the official Ollama desktop app.

The Problem

Ollama is incredible. Local LLMs, dead simple, fast. But their desktop app — the polished GTK-style chat UI with model management, file attachments, settings, chat history — officially ships for Windows and macOS only.

Every single Go file in the app/ directory of ollama/ollama starts with:

//go:build windows || darwin

Linux users are left running ollama serve and pointing a browser at localhost:11434. It works, but it's not the experience.

The Discovery

Before writing a single line of code, I did what any good engineer does: I read the source.

The Ollama desktop app is built on webview — a lightweight C++ library that wraps the platform's native browser engine. On Windows it uses WebView2 (Edge). On macOS it uses WebKit. And on Linux?

// From webview.h, line ~400:
#if defined(WEBVIEW_GTK)
// Full GTK3 + WebKit2GTK implementation

The Linux support was already there. Fully implemented. Sitting in the header file, waiting. The Go build tags were the only thing blocking it.

The Port

Six new files. A patch. About 350 lines of Go.

1. Unlock the build tags

~40 files needed one line changed:

// before
//go:build windows || darwin

// after  
//go:build windows || darwin || linux

2. Wire up the CGo flags

app/webview/webview.go needed Linux-specific build flags to find GTK and WebKit:

#cgo linux CXXFLAGS: -DWEBVIEW_GTK -std=c++14
#cgo linux LDFLAGS: -ldl
#cgo linux pkg-config: gtk+-3.0 webkit2gtk-4.1

Note: Ubuntu 26.04 ships webkit2gtk-4.1 — not 4.0. If you're targeting older distros, check your version.

3. Platform files

The app architecture expects platform-specific implementations of a handful of interfaces. I wrote six _linux.go files:

app_linux.go — GTK window management via CGo, lockfile-based single-instance enforcement, signal cleanup:

func handleExistingInstance(startHidden bool) {
    f, err := os.OpenFile(lockPath, os.O_CREATE|os.O_EXCL|os.O_WRONLY, 0o644)
    if err != nil {
        slog.Info("another ollama-app instance detected, exiting")
        os.Exit(0)
    }
    f.Close()
    go func() {
        c := make(chan os.Signal, 1)
        signal.Notify(c, syscall.SIGINT, syscall.SIGTERM, syscall.SIGHUP)
        <-c
        removeLock()
    }()
}

server_linux.go — The app normally spawns the Ollama daemon itself. On Linux, systemd handles that. So this file is just a health-checker that pings localhost:11434 every 30 seconds and logs if it's unreachable. Never spawns a process.

updater_linux.go — All no-ops. systemd and apt manage updates on Linux.

filepicker_linux.go — File/folder dialogs via zenity:

func selectDirectory(title string) (string, error) {
    out, err := exec.Command("zenity", "--file-selection", "--directory", "--title="+title).Output()
    if err != nil {
        return "", err
    }
    return strings.TrimSpace(string(out)), nil
}

dialog/dlgs_linux.go — zenity implementations of the app's dialog interface (yes/no, info, error, file pickers).

webview_linux.go — The Webview struct without the Windows menu.h CGo baggage, plus all the JS bindings: ready, close, drag, doubleClick, zoomIn, zoomOut, selectFiles, selectWorkingDirectory.

4. The one frontend bug

The React sidebar had:

{isWindows && (
  <Link href="/settings">Settings</Link>
)}

On Linux, navigator.platform returns "Linux x86_64" — so isWindows is false and Settings just... doesn't appear. One-line fix:

const isMac = navigator.platform.toLowerCase().includes("mac");

{!isMac && (
  <Link href="/settings">Settings</Link>
)}

The Result

git clone https://github.com/johnohhh1/ollama-webchat-ubuntu.git
cd ollama-webchat-ubuntu
bash build.sh
sudo cp build/ollama-app /usr/local/bin/ollama-app
ollama-app

A native GTK3 window. WebKit2GTK rendering the full React SPA. Chat history in SQLite. File attachments. Model management. Settings. Dark mode. Wayland-native — no XWayland needed.

The NVIDIA gotcha

Running an RTX 5070 (Blackwell) with the proprietary driver? You'll see a wall of EGL warnings on startup:

libEGL warning: egl: failed to create dri2 screen
libEGL warning: pci id for fd 17: 10de:2f04, driver (null)

Ignore them. There's no open-source Mesa driver for Blackwell yet — WebKit probes Mesa EGL, fails, and falls back to Cairo software rendering for the compositor. For a chat UI it's completely imperceptible. Page layout and text were always CPU-rendered anyway.

Why Ubuntu 26.04 changes things

26.04 LTS is the first Ubuntu release with X11 removed entirely — Wayland only. GNOME 50. The desktop finally feels like a first-class target, not an afterthought.

At the same time, the local AI tooling ecosystem has exploded. Ollama, LM Studio, Open WebUI, llama.cpp — these tools are genuinely good, and they mostly work on Linux. The desktop app experience is just lagging behind.

That's the gap I'm trying to close. If you're a developer making the jump from Windows to Ubuntu 26.04 this week, you shouldn't have to give up your tools.

Repo

github.com/johnohhh1/ollama-webchat-ubuntu

PRs welcome — especially if you test on Fedora, Arch, or Ubuntu 24.04. And if you're building other AI tools that are stuck behind Windows/macOS build tags, the pattern here is reusable.

The C library usually already supports Linux. The build tags are almost always the only thing in the way.

Run the Real ChatGPT Desktop App on Ubuntu Linux (Not a Wrapper)

Thu, 09 Apr 2026 20:58:42 +0000

TL;DR: OpenAI ships a Windows MSIX binary. You can unpack it, patch three platform assumptions, and run the actual official app natively on Ubuntu — same binary Windows users get. No Electron wrapper, no web view in a box.

The Problem With Every Other Guide

Search "ChatGPT desktop Ubuntu" and you'll find two things:

Articles pointing you at lencx/ChatGPT — a third-party Electron wrapper that loads chatgpt.com in a window. It's not the real app.
Articles pointing you at other wrappers doing the same thing.

These work, but you're getting a community-built shell around a website — not the app itself. The real ChatGPT Desktop (the one in the Windows Store) has features, update hooks, and auth flows that wrapper apps can't replicate cleanly.

This guide unpacks the official binary and runs it on Ubuntu 26.04. Tested on kernel 7.0.0, RTX 5070, NVIDIA 580/CUDA 13.0, both X11 and Wayland via XWayland.

What the Script Actually Does

Extracts the x64 MSIX from the official .msixbundle
Pulls out the official app.asar (the real app logic)
Patches three platform assumptions so it boots on Linux:
- Routes the platform chooser through the macOS-style implementation (Linux is close enough)
- Disables macOS-only setVibrancy() calls
- Skips the macOS ioreg device ID path
Stages Linux Electron around the official app resources
Packages everything as a proper .deb — chatgpt-desktop-native

You end up with a system package you can install, update, and uninstall like anything else.

Prerequisites

System packages

sudo apt-get install -y dpkg-dev nodejs python3 file

Local Electron tooling

mkdir ~/chatgpt-windows-deb && cd ~/chatgpt-windows-deb
npm install electron @electron/asar --no-save

Get the Official MSIX Bundle

You need the official Windows package from OpenAI. Download OpenAI.ChatGPT-Desktop_<version>.Msixbundle from the Microsoft Store or OpenAI's distribution endpoint and drop it in your working directory.

The repo includes the version current at time of writing as an example payload.

Build

cd ~/chatgpt-windows-deb
git clone https://github.com/johnohhh1/chatgpt_desktop_ubuntu .
npm install electron @electron/asar --no-save
./build-chatgpt-native-deb.sh --exe ./OpenAI.ChatGPT-Desktop_2026.212.2039.0.Msixbundle

Output lands in dist/:

dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Install

sudo apt-get install ./dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Rebuilding without a version bump? Force refresh:

sudo apt-get install --reinstall ./dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Register Auth Callback Handlers

The package installs a helper that registers your desktop session as the handler for the chatgpt: and chatgpt-alt: URL schemes (used for the login flow):

chatgpt-desktop-native-register

Verify it took:

xdg-mime query default x-scheme-handler/chatgpt
xdg-mime query default x-scheme-handler/chatgpt-alt

Both should return chatgpt-desktop-native.desktop.

Launch

chatgpt-desktop-native

The desktop entry sets the WM class to electron so GNOME binds the running window to the ChatGPT icon instead of the generic gear icon.

Known Quirks

The terminal will print Electron/NVIDIA/VA-API noise. This is normal — ignore it.
The success signal is functional login and working chat, not a clean terminal.
If GNOME still shows the generic icon after first launch: close the app fully and relaunch once. Stubborn shell? Log out and back in.
If OpenAI updates the Windows app significantly, the patch targets in build-chatgpt-native-deb.sh may need updating. PR welcome.

Reproducing on Another Machine

Clone the repo to the target machine
Drop a real ChatGPT .msix, .msixbundle, .appx, or .appxbundle in the directory
npm install electron @electron/asar --no-save
./build-chatgpt-native-deb.sh --exe <your-payload>
Install the generated .deb
Run chatgpt-desktop-native-register
Launch chatgpt-desktop-native

Repo

github.com/johnohhh1/chatgpt_desktop_ubuntu

Issues and PRs open. If a new MSIX version breaks the patches, open an issue with the version string and I'll update the patch targets.

Tested on Ubuntu 26.04 "Noble" with kernel 7.0.0-10, RTX 5070, NVIDIA driver 580, CUDA 13.0.strong text

Fixing Google Antigravity Pro Authentication on Windows 10 + WSL2

Wed, 21 Jan 2026 17:57:05 +0000

Google Antigravity is Google's new agent-first IDE that promises powerful AI-assisted development. However, getting the Pro features to work on Windows 10 with WSL2 (Ubuntu 24.04.3 LTS) can be challenging due to authentication issues. This comprehensive guide will walk you through every step needed to get your Pro/Ultra subscription working seamlessly.

The Problem

When running Antigravity in WSL2, the authentication handshake between your Linux terminal and Windows browser often breaks or times out. This happens because WSL2 is a virtualized environment, and the redirect token struggles to find its way back to the WSL instance.

Common symptoms include:

Browser opens but IDE stays on loading screen
Browser Authentication is successful but the Agent Panel still says "Reqire Authentication" (or something similar), even though the Antigravity Settings > Account Screen shows Account as already signed in.
"Invalid Token" or "Login Expired" errors
"Not Eligible" or "Unauthorized" messages
Empty responses when running agy commands

Prerequisites

Before starting, ensure you have:

Windows 10 with WSL2 installed
Ubuntu 24.04.3 LTS (or similar)
Google Antigravity installed on Windows
A Google AI Pro or Ultra subscription using a personal Gmail account.

The first issue to address is WSL2's default NAT networking, which can hide the local ports Antigravity uses to listen for login signals.

Enable Mirrored Networking

On Windows, navigate to %USERPROFILE% (e.g., C:\Users\YourName)
Create or edit a file named .wslconfig
Add the following configuration:

[wsl2]
networkingMode=mirrored

Restart WSL by opening PowerShell as Administrator and running:

wsl --shutdown

Note: You may start getting this message on WSL Startup, especially on Windows 10 (shouldn't theoretically appear on Windows 11):

wsl: Mirrored networking mode is not supported: Windows version 19045.6466 does not have the required features.
Falling back to NAT networking.

In which case, you should remove the unsupported setting from your global config to get rid of the warning every time you boot/reboot and open Ubuntu, as WSL2 cannot enable this mode and defaults back to the standard NAT (Network Address Translation).

Instead, you can try the following config to ensure that Agents always reliably reach local addresses (Supported on Windows 10):

[wsl2]
localhostForwarding=true

Add or ensure these lines exist in %USERPROFILE%\.wslconfig. Save and run wsl --shutdown in your terminal.

Step 2: Synchronize Your System Clock

Google's OAuth 2.0 authentication is highly sensitive to time drift. WSL2 clocks often drift when a laptop sleeps (like in my case), causing tokens to be rejected as expired.

Run this in your Ubuntu terminal:

sudo ntpdate time.windows.com

# If you don't have ntpdate installed:
sudo apt install util-linux-extra && sudo hwclock -s

Step 3: Try Authentication again

If GUI login continues to fail, manually Sign out from your account in the Antigravity Settings > Account Screen.
Close and Restart the IDE.
Click on the Google Sign in button in the top right and Authorize your Google AI Pro account.
Close the Antigravity Sign-in confirmation page.
If the issue persists, repeat the first step and continue reading below.

Step 4: Verify Account Eligibility

Many authentication failures are actually due to account restrictions:

Account Type

Personal accounts (@gmail.com) have the highest success rate
Workspace accounts may require admin approval for "Experimental Google AI Services"

Regional Matching

Ensure your Windows Region, Google Account Region, and IP address (no VPN) all match. Mismatched regions can cause silent authentication failures.

Step 5: Fix Missing WSL Extension Scripts

A known bug in early Antigravity builds causes missing WSL helper scripts. Here's how to fix it:

Manual Script Extraction

Download the Remote - WSL extension from the VS Code Marketplace
Click "Download VSIX" (downloads a .vsix file) if in IDE extensions panel or use a tool like VSIX Downloader for web download.
Rename the file from .vsix to .zip
Open the zip and navigate to extension/scripts/
Copy all files (especially wslCode.sh and wslDownload.sh)
Paste into: %LOCALAPPDATA%\Programs\Antigravity\resources\app\extensions\antigravity-remote-wsl\scripts\

Fix the Launcher ID

Even with scripts present, you need to update the extension ID reference:

Navigate to %LOCALAPPDATA%\Programs\Antigravity\bin\
Open the antigravity file in Notepad
Find: WSL_EXT_ID="ms-vscode-remote.remote-wsl"
Change to: WSL_EXT_ID="google.antigravity-remote-wsl"
Save and restart your WSL terminal

Try Authentication in WSL:

Open Antigravity on Windows
Press Ctrl + Shift + P
Type "WSL" and select Remote-WSL: Connect to WSL
The bottom-left corner should show [WSL: Ubuntu]
Try signing in from this connected state

Step 6: Create the WSL-to-Windows Bridge

To use agy commands from your Ubuntu terminal, you need to create a proper bridge to the Windows binary.

Create the Wrapper Script

Create the local bin directory:

mkdir -p ~/.local/bin

Create the agy wrapper (replace [YOUR_WINDOWS_USERNAME] with your actual Windows username):

cat > ~/.local/bin/agy <<'EOF'
#!/usr/bin/env bash
# Robust wrapper to bridge WSL -> Windows CMD -> Antigravity
# REPLACE [YOUR_WINDOWS_USERNAME] with your actual folder name

WIN_USER="[YOUR_WINDOWS_USERNAME]"
WIN_PATH="C:\\Users\\${WIN_USER}\\AppData\\Local\\Programs\\Antigravity\\bin\\antigravity.cmd"

# Call via cmd.exe to ensure Windows environment is initialized
# cd to C: drive to avoid UNC path warnings
cd /mnt/c && cmd.exe /c "${WIN_PATH}" "$@"
EOF

Make it executable:

chmod +x ~/.local/bin/agy

Add to your PATH:

export PATH="$HOME/.local/bin:$PATH"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Verify Your Windows Username

Before running the wrapper, verify your path:

ls /mnt/c/Users/

Update the WIN_USER variable in the script to match exactly how your Windows username folder is spelled.

Enable WSL Interoperability

Ensure WSL can launch Windows processes by checking /etc/wsl.conf:

cat /etc/wsl.conf

If it doesn't exist or is empty, create it with these settings:

[interop]
enabled=true
appendWindowsPath=true

Then restart WSL with wsl --shutdown from PowerShell.

Step 7: Verify Pro Authentication

Once everything is set up, verify your CLI Setup:

# Check version
agy --version

# List available commands
agy --help

# Open IDE in current directory
agy .

Now try signing in again to your Google account. The Agent Panel should be available now, and the Antigravity Settings > Account Screen shows Account as already signed in. Expected output for Agent Panel:

Tier: Pro or Ultra
Model: Gemini 3 Pro or Gemini 3 Flash, etc.
Token Limit: 1M+ tokens

Use Pro Agents

Now you can invoke high-level agents directly on your WSL files:

agy chat "Analyze the structure of this repo and suggest refactoring opportunities"

Because you're authenticated as Pro, the agent will use the full index to understand your entire codebase structure.

Troubleshooting Quick Reference

Issue	Symptom	Fix
Network	Browser opens, IDE stays loading	Enable `networkingMode=mirrored` in `.wslconfig`
Clock Drift	"Invalid Token" or "Login Expired"	Run `sudo hwclock -s`
Account Type	"Not Eligible"	Use personal `@gmail.com` account
Missing Scripts	IDE won't connect to WSL	Download and extract scripts from VS Code Marketplace
Wrong Extension ID	Connection fails silently	Update `WSL_EXT_ID` in launcher script
UNC Path Warnings	Warnings in terminal output	Use `cd /mnt/c &&` in wrapper script

Common Commands

# Open current directory in Antigravity
agy .

# Check process usage and diagnostic information
agy --status

# Check version
agy --version

# Get help
agy --help

Pro Tips

Persistent Sessions: Enable "Persistent Agent" in Antigravity UI to keep agents running even if you close the terminal
Project Indexing: Let Antigravity fully index your project before asking complex questions for better results
Token Limits: Pro users get 1M+ token context windows, perfect for analyzing large codebases
Regional Consistency: Avoid using VPNs during authentication to prevent region mismatch issues

Conclusion

Getting Google Antigravity Pro working on WSL2 requires bridging the gap between the Windows and Linux environments. By following these steps—fixing networking, synchronizing clocks, creating proper symlinks, and enabling interoperability—you'll unlock the full power of Google's agentic IDE.

The effort is worth it: once configured, you'll have access to powerful AI agents that can understand and refactor your entire codebase, all while working seamlessly in your WSL2 development environment.

Additional Resources

Last updated: January 2026 | Tested on Windows 10 + WSL2 Ubuntu 24.04.3 LTS

Effortless Web App Deployments with GitHub Actions

Sat, 13 Dec 2025 16:33:23 +0000

Automating Production Deployments on DigitalOcean

Deploying web applications manually gets painful fast — especially once your project grows.

For azan.lk, a Laravel + React application running on a hardened DigitalOcean droplet, I moved from manual SSH-based deployments to a fully automated CI/CD pipeline using GitHub Actions.
Every push to main now builds, deploys, and optimizes the app automatically — safely and consistently.

This article gives you a practical, production-ready overview of how to automate deployments without overengineering.

⚙️ What This Covers

This guide focuses on real-world CI/CD for VPS-based deployments, not platform-locked solutions.

You’ll learn how to:

Automate deployments using GitHub Actions
Build Laravel & React outside the server
Deploy via SSH securely
Run database migrations and optimizations remotely
Keep your DigitalOcean droplet lean and stable
Eliminate repetitive SSH workflows

Perfect for portfolios, SaaS apps, client projects, or APIs running on a VPS.

Prerequisites (Important)

Before adding automation, your server must already be production-ready.

Make sure you’ve completed these first:

Server Hardening
- Non-root user
- SSH keys
- Firewall & Fail2Ban
  Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04
HTTPS & SSL
- Nginx
- Let’s Encrypt
- Auto-renewal
  Unlock Free HTTPS with Let’s Encrypt SSL
Manual Deployment Setup
- Laravel + PHP-FPM
- Nginx
- MySQL
- Node & Vite
  Streamlined App Deployment on Ubuntu 24.04

Once those are done, CI/CD becomes the final layer — not a replacement.

The Problem with Traditional Deployments

A typical manual deployment looks like this:

SSH into the server
Pull latest code
Run Composer
Run NPM builds
Fix permissions
Run migrations
Hope nothing breaks

On small VPS instances, Composer and NPM can consume memory, slow the server, or even crash builds.

And doing this repeatedly?
That’s technical debt waiting to happen.

What You’ll Accomplish with CI/CD

By the end of this setup, you’ll have:

Automatic deployments on every push to main
Builds handled by GitHub, not your VPS
Secure SSH-based file sync
Zero manual server logins for deploys
Reliable, repeatable production releases

Push code → GitHub Actions runs → App goes live

Why This Approach Works

This setup is optimized for developers who:

Use VPS hosting instead of managed platforms
Want full control over infrastructure
Care about performance and stability
Prefer simple, understandable pipelines

No Kubernetes.
No overcomplicated workflows.
Just clean automation that works.

Read the Full Step-by-Step Guide

The full article includes:

Complete deploy.yml workflow
GitHub Secrets setup
SSH key best practices
Common CI/CD pitfalls (and how to avoid them)
Production-safe Artisan commands

Effortless Web App Deployments: Mastering GitHub Actions with DigitalOcean

✨ Final Thoughts

CI/CD isn’t about complexity — it’s about removing friction.

Once this pipeline is in place:

Deployments become boring (that’s good)
Servers stay fast
Mistakes drop dramatically
Your workflow scales with your project

Pair this guide with Streamlined App Deployment on Ubuntu 24.04, and your readers get a complete journey:

Manual setup → hardened server → automated production deployments

Streamlined Production Deployment on Ubuntu 24.04

Wed, 03 Dec 2025 14:21:31 +0000

Deploying a full-stack application for production doesn’t have to be complicated — especially if you follow a structured setup. For azan.lk, a Laravel + React project backed by MySQL, I built a fully optimized, secure deploymenton Ubuntu 24.04, running on a DigitalOcean Droplet.

This post is a quick overview of what the major components you’ll handle.

⚙️ What This Covers

This deployment walkthrough is designed for modern full-stack apps and covers the full stack you’d expect in real production:

Laravel backend (PHP 8.4, FPM, Composer)
React frontend (bundled via Vite)
MySQL database (hardened & configured)
Nginx production server
Node.js + NPM via NVM
Git + SSH for secure deployments
Environment setup, permissions, and optimizations

If you’re deploying a portfolio, client project, SaaS, or API backend, this setup gives you a fast, stable, security-conscious structure.

Before Deployment: Essential Prerequisites

Make sure your droplet is secure and ready for production.
I recommend completing these two guides first:

1. Server Hardening (Must Do Before Anything)

Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04
A complete walkthrough covering non-root users, SSH keys, firewall, Fail2Ban, and more.

2. Enable HTTPS (Required for Live Apps)

Fortify Your Droplet: Unlock Free HTTPS with Let’s Encrypt SSL
Includes DNS setup, Nginx configs, SSL installation, and auto-renewal.

Once both are done, your droplet is safe to host real traffic — and ready for deployment.

✨ What You’ll Accomplish

Install PHP 8.4 with all required extensions for production
Set up Composer safely using the official installer
Configure MySQL with proper users, permissions, and best practices
Install Node.js via NVM for frontend builds
Set up Git SSH keys for secure repository access
Configure application permissions for Laravel
Build and optimize your frontend assets for production
Set up Nginx with proper routing, headers, and FPM integration
Run database migrations and seeders
Troubleshoot common deployment issues like PHP errors, permissions, or SSH problems

Every step — with commands, configs, and explanations — is included in the full guide on Hashnode.

Read the Full, Detailed Guide

The complete command-by-command walkthrough — including explanations, and best practices — is available on my blog.

Read the full article here:
Streamlined App Deployment: Launch Your First Web App on Ubuntu 24.04 with DigitalOcean

The post includes every command, config file, and optimization used in the real-world deployment of azan.lk.

Why This Guide Matters

Most deployment tutorials are outdated, incomplete, or skip critical production details.
This guide focuses on:

Security (SSL, firewall, SSH hardening)
Performance (PHP-FPM tuning, Vite builds)
Stability (MySQL, permissions, proper Nginx configs)
Developer workflow (Git SSH, easy updates, reliable builds)

Ideal for developers deploying real-world projects into production.

Final Thoughts

A reliable deployment is more than just “upload code and run”:
it’s a combination of security, performance, and correct configuration.

Secure Your DigitalOcean Droplet with Free HTTPS (Let’s Encrypt + Certbot)

Wed, 03 Dec 2025 07:59:56 +0000

Once your droplet is hardened with a non-root user, SSH hardening, and a firewall, the next upgrade you must add is HTTPS.

Without HTTPS, your login pages, API requests, and user data travel in plain text — easy for attackers to sniff or intercept. With HTTPS enabled, you get encrypted traffic, improved trust, and that familiar browser padlock that tells users their connection is safe.

This post is a quick overview of what the HTTPS setup includes.

Start Here: Droplet Hardening Guide (Before HTTPS)

Before diving into HTTPS, make sure you’ve completed the hardening steps covered in my first guide:
Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04

✨ What You’ll Accomplish

Connect your domain to the droplet
Configure Nginx properly for production
Install Certbot + Let’s Encrypt
Enable secure HTTPS with automatic renewal
Redirect all HTTP traffic to HTTPS
Validate the setup with a clean, secure padlock indicator

Every step — with the exact commands — is included in the full guide.

Why HTTPS Matters

Protects login and API endpoints
Encrypts form data, cookies, and tokens
Immediately boosts user trust
Required by OAuth providers, Stripe, Clerk, Firebase, and more
Works seamlessly with any backend (Laravel, Node.js, Go, Spring Boot, etc.)

Whether you're deploying a portfolio, SaaS app, REST API, or production service, HTTPS is non-negotiable.

Read the Full, Detailed Guide

The complete command-by-command walkthrough — including explanations, and best practices — is available on my blog.

Read the full article here:
Fortify Your Droplet: Unlock Free HTTPS with Let’s Encrypt SSL

(Every command and configuration is included — nothing hidden.)

After You Follow the Guide, Your Droplet Will Be:

✅ Fully encrypted with HTTPS
✅ Protected from MITM attacks
✅ Auto-renewing SSL forever
✅ Ready for real production workloads
✅ Safe for sessions, passwords, and API traffic

Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04

Tue, 02 Dec 2025 18:54:08 +0000

Launching a production app isn’t just about clean code or beautiful UI — it’s about making sure the server behind it is hardened, protected, and ready for real-world traffic. A poorly configured droplet can be compromised in minutes, and the cost of recovery is far greater than the cost of prevention.

To help fellow developers avoid those risks, I documented the exact hardening process I used for azan.lk, a Sri Lanka–focused Islamic portal. These steps apply to any project — personal, client-based, or fully commercial.

What You’ll Achieve

By the end of this guide, you’ll have a droplet that’s:

Hardened and production-ready
Protected with SSH key–only access
Locked down with root login disabled
Secured with a properly configured UFW firewall
Reinforced with optional tools like Fail2Ban and unattended security updates

These are foundational steps I recommend before deploying any backend, frontend, Docker service, or microservice.

What This Guide Covers

1. Organizing Your DigitalOcean Project

Set up a clean DO workspace so your droplets, DNS records, metrics, and backups stay organized.

2. Building a Secure Droplet

Recommended specs for most apps:

Ubuntu 24.04 LTS
2GB RAM / 2 CPU
60GB SSD
Singapore or Bangalore for low latency to Sri Lanka

3. SSH & User Configuration

Create a non-root sudo user
Add SSH key authentication
Disable password login
Disable root login for safety

4. Hardening Essentials

Strengthen your droplet with:

Strict SSH configuration
UFW firewall
Fail2Ban jail protection

5. Developer Quality-of-Life Enhancements

Set up a local SSH config so logging into your droplet becomes instant and password-free.

✨ Why I Wrote This

When I first started deploying production systems, server security felt like something for “later.”
Then I learned how vulnerable a fresh droplet is out of the box — and how quickly it can be scanned, probed, or exploited.

Now I document my setup processes so other developers can deploy with confidence and avoid the pitfalls I learned the hard way.

This article is perfect if you’re deploying:

Laravel, Node.js, or Go applications
React, Vue, or Next.js frontends
Docker containers / microservices
APIs or production websites

Read the Full, Detailed Guide

The complete command-by-command walkthrough — including explanations, and best practices — is available on my blog.

Read the full article here:
Fortify Your DigitalOcean Droplet: A Step-by-Step Security Guide for Ubuntu 24.04

(Every command and configuration is included — nothing hidden.)

Final Thoughts

Security isn’t a one-time task — it’s an ongoing practice.
But this guide gives you a solid, battle-tested foundation for any production environment, whether you’re hosting a small personal app or a full-scale platform.

Coder Legion - Recent posts tagged ubuntu

Node 22.22 runs TypeScript. Ubuntu's Node 22.22 doesn't.

Same version, different binary

Where TypeScript went

Why CI never saw it

The fix

Ask Node what it can do

From Silence to Sound: Fixing Audio on Ubuntu Linux on my Samsung Galaxy Book

The Problem

The Breakthrough

The Automation

The Tool: galaxybook-linux-setup

Who This Might Helps

Credit Where Due

The Bigger Picture

Ubuntu Resolute: Evolution Instead of Revolution

What Does It Take to Implement a New Ubuntu Version?

An Early Look

Step by Step

A Little Revolution

Engineering Summary

Ansible Installation and Configuration On Ubuntu

Introduction

What is Ansible?

What is the Control Node?

What is the Managed Node?

Install Ansible on Ubuntu (Control Node—local machine. Running ZorinOS).

Create an inventory folder with a host file.

Create a folder named Playbook

Examine the YML file.

Run Playbook

Summary of the Execution Flow

Conclusion

Surviving a Kernel Panic: My Ubuntu War Story

Step 1: The Hard Reset & The USB Boot

Step 2: Dropping into the Underworld (The BusyBox Shell)

Step 3: Find and repair

Step 4: The Boot Menu & The Investigation

Step 5: The Execution(Purging the Rot)

A little note...

I Ported ComfyUI Desktop to Ubuntu 26.04 1 a day till I run out!

And Another One!

Another Desktop App ported to Linux That was not available. I will Keep going until release day or I run out of apps to port. Let me Know what one you would like to see next!

The Goal

The Starting Point

The Real Problems

1. Linux was gated out of asset/bootstrap flow

2. Packaged builds were missing desktop-ui

3. AppImage hit Electron sandbox issues

4. Linux runtime assumptions were wrong

5. Existing Comfy installs were ignored

What I Changed

Build and packaging fixes

Runtime fixes

Existing-install behavior

Why .deb Won

What the App Does Now

Commands I Actually Used

The Nice Surprise

The Useful Lesson

Upstream and Source

My Repo

Here is the Kimi Desktop on Ubuntu 26.04 noone asked for..... Because I am creating 1 desktop a day

"The official Kimi desktop app can't install on Ubuntu 24.04+ because it depends on a removed library. Here's how I rebuilt it with Tauri v2 and Pake v3 to fix it."

The problem in one sentence

The fix: rebuild with Tauri v2

What you get

Rebuild it yourself

The config that makes it work

Why not just use the web app in a browser?

The repo

Uninstall

I Ported the Ollama Desktop App to Linux Just in Time for Ubuntu 26.04 LTS

The Problem

The Discovery

The Port

1. Unlock the build tags

2. Wire up the CGo flags

3. Platform files

4. The one frontend bug

2. Packaged builds were missing `desktop-ui`

Why `.deb` Won