Hi, I'm Abdelmonem. I build self-hosted software for hardware that is supposed to look after itself — and, lately, drivers for hardware that refuses to be driven at all. Alongside that: a control suite for Klipper 3D printers, plugins for OPNsense firewalls, local LLM serving on Synology hardware, Odoo modules, and iOS and Android apps.

Most of it is Python, TypeScript and C. Almost all of it ships in Arabic as well as English, because the people running this hardware do not all read English.

Install OPNsense on a Sophos XGS and it boots to a working firewall with no network interfaces at all. The appliance is two computers, and the second — a coprocessor behind PCIe, with drivers for Linux and the vendor's own OS only — owns every front port, so when support lapses the usual verdict is e-waste. os-xgs-npu is the FreeBSD kernel modules that hand those ports back, written against registers no vendor documents, across a family of six coprocessor generations.

I gave it a home of its own, npuforge.org: the guide, every measurement with its method, a compatibility list that owners add to, news of each release and the story, in English and in Arabic.

The repository is much younger than the work in it. It went public on 25 September 2026; the work behind it took close to two years — eight months of surveying other vendors' appliances, adapters that failed, a firmware of my own that ran into a board of many chips, and then the turn every driver here stands on: the host learning to speak the coprocessor's own language. The whole story is on the site.

• Two unrelated coprocessors, one contract. Marvell and Cavium silicon answer the same kernel offload interface, behind the same OPNsense pages, and both drivers take the same orders: hand one connection back to the host, never offload these addresses or ports.
• The tunnel costs nothing. With hardware at both ends, IPsec runs at the rate of clear text — 1.85 Gbit/s on one stream at the standard MTU, 7.41 Gbit/s with jumbo frames. The XGS 136's engine keeps its gigabit's rate with IPv6 outside the tunnel and inside it, and with extended sequence numbers, both ways. On both appliances a connection's outgoing side can be encrypted and forwarded by the coprocessor alone, without one of its frames passing through the host.
• Forwarded at the link's rate. IPv6 connections handed to the coprocessor carry 9.27 Gbit/s through an XGS 3300 on eight streams, every one of them in hardware — the 10G link is the limit, not the chip. A thousand connections at once fill it too: 9,837 Mbit/s with the host's processors 7.8 % busy. The XGS 136 does the same at its gigabit, for IPv6 and for IPv4 translated from LAN to WAN in the coprocessor: 941 Mbit/s with its processors 0.4 % busy, against 19.6 % through the host.
• What the offload buys is the processor. Most of a core at a gigabit, against a few hundredths of one, with 99.6 per cent of a connection's frames in hardware.
• Fast, and still a firewall. A connection the coprocessor forwards can still be cut: when a block list gains its address, or when OPNsense's intrusion detection sees its TLS fingerprint (JA4) on a list. When an IPsec policy comes to cover it, it leaves the hardware for the tunnel, so nothing meant for the tunnel goes out in the clear. It is still counted: the coprocessor's own figures reach pf's states and rules and the interfaces' traffic graphs, which would otherwise never see it. And a port scan, a sweep, or a host far beyond its own normal is reported, never blocked. Each of these is measured on both appliances. What the Traffic Shaper or the Captive Portal names stays with the host too, so a shaper's pipe still holds — measured on the XGS 3300.
• Two roads onto an appliance. Most people start from a bootable image: xgs-image-builder builds one from a page in the browser, in English or Arabic, with the newest release, the plugins, Arabic and right-to-left already inside, and one built that way has been installed on an XGS 3300 and booted. Experts can load the drivers by hand; for everyone else I wrote a guide from nothing to the first sign-in, a picture for each step, in English and Arabic. Either way it lives in OPNsense as if it belonged there — a menu section of its own, from the overview and the ports to updates and problem reports, in Arabic and English; ports assigned by the names on the chassis at the first boot; and updates from tagged releases since 0.1.0-alpha.1, installed from its own page: the three appliances here took 0.1.0-alpha.2 that way.
• It keeps its own score. The main part is done and the rest arrives as updates, but it is an alpha and says so: every figure with its method in the measurements, the dead ends on the road, and plain advice to try a release first on an appliance you can reach.

How each family is driven

FilaMind is an open-source, self-hosted suite for makers running Klipper and Moonraker. Most of my commits over the past year went here.

• filamind-core — the TypeScript foundation the rest is built on: a Moonraker client, a session orchestrator, a fail-closed write arbiter so two front ends can never fight over the same printer, and i18n for 19 locales.
• filamind-flow — the control panel: firmware flashing, input shaping, TMC motor-driver tooling. Python and FastAPI behind Vue 3, built one widget at a time so each piece can be adopted on its own.
• filamind-screen — the on-printer touch interface, same core, wrapped as a desktop app with Tauri 2.
• filamind-3d — the web control UI on top of the core. Vue 3, Vite and Tailwind over a lean FastAPI host.
• filamind-ai — private AI for a Synology NAS: local LLM chat with optional cloud fallback, multi-user, an OpenAI-compatible API, and a full interface in both Arabic and English. Runs on a DVA 3221 with its CUDA GPU, or a DS1821+ on CPU.
• filamind-setup — one installer engine behind two front ends, a CLI and a widget inside flow.

Five plugins, BSD-2 licensed like the platform itself and packaged as FreeBSD ports.

• os-linkhealth — watches every physical port and names the cable or transceiver that is going bad, by the label printed on the chassis rather than the interface name. It reads the DOM registers on the transceivers, so the warning arrives before the link actually drops.
• os-netreport — scheduled network reports by email, and an alert the first time an unknown device shows up. Each report is written in whichever language the GUI is set to.
• os-frontpanel — drives the LCD and buttons built into an appliance's front panel through LCDproc, with the screens and their timing set from the GUI instead of a config file on disk.
• os-fanctl — fan control and every readable temperature sensor, for repurposed appliances whose fan curve left with the vendor firmware. Talks to the Super I/O chip directly.
• os-theme-xgs — XGS Silicon, a light, a dark and an automatic theme for the OPNsense GUI on the XGS appliances: carbon and copper like the hardware, IBM Plex with its own Arabic, and not one page's layout changed. An image built for the XGS starts with it.

Three of them now know the Sophos XGS appliances above — port labels for every XGS board and FleXi module, generated from the vendor's own board files, port identification through the coprocessor, temperature and fan readings from the board and from the coprocessor, the 3300's front panel with its buttons and a menu — so a reclaimed box gets more back than its ports. Six packages — the first four here, and the Arabic and right-to-left ones — update only when their owner says so: on an XGS from one Plugins tab in XGS: Updates, anywhere else by hand. All six survive an OPNsense update that replaces their strings or templates.

They share one shape:

Volt templates and PHP for the interface, the model in XML, configd actions in the middle, and Python doing the real work against FreeBSD. Following that layout instead of inventing my own is what lets the plugins get backed up, upgraded and translated like every other part of the system.

Most of my Odoo work is client projects in private repositories: custom modules and business integrations. The public part is the device side, where Odoo has to talk to real hardware.

• filamind-iot — a self-hosted IoT gateway addon for Odoo 19, paired with the IoT-box image below.
• filamind-iotbox — a patched Odoo IoT Box image that takes a server URL directly on its settings page, instead of going through the hosted pairing service.
• filamind-iot-proxy — the replacement for that hosted service: pairing rendezvous, ACME certificate issuer and reverse-tunnel relay, LGPL and running on your own machine.

• opnsense-arabic — the Arabic translation of the OPNsense 26.7 web interface, tracked against upstream so the strings don't drift between releases.
• opnsense-rtl — right-to-left layout for Arabic and Persian. Flipping the text direction is the easy half; tables, form flow, icon direction, menu alignment and a long tail of Bootstrap overrides are what decide whether an RTL interface is genuinely usable or merely mirrored.

The same concern runs through everything else: 19 locales in filamind-core, Arabic and English throughout filamind-ai, every OPNsense report rendered in the language of whoever has to read it, and every page the XGS driver and the plugins add to OPNsense translated into Arabic with the rest — each one photographed in both languages. And I built the XGS project's site an Arabic edition of its own, right to left, with Arabic menus and search.

cadenza curates music libraries on a Synology NAS: acoustic fingerprinting to find real duplicates, metadata pulled from several sources, format conversion. It never deletes anything. Suspect files go to quarantine, because a false positive should cost you a folder, not a recording. DSM 7, x86_64.

A fair amount of my work stays in private repositories: the Odoo projects built on top of the modules above, and iOS and Android applications. Ask if that is the part you need.

Python for backends, plugins and media pipelines. C for the kernel side — the XGS drivers above all, then the Super I/O access in the fan controller and the local inference build in filamind-ai. TypeScript and Vue 3 for every FilaMind front end, React on cadenza. PHP and Volt because that is what an OPNsense interface is written in, and SCSS for its theme. Rust where a Tauri shell needs it.

Underneath: FreeBSD and its ports tree, Synology DSM 7, Docker, FastAPI, Vite, Tailwind, gettext, and GitHub Actions for CI and releases. At the hardware end: PCIe network coprocessors, SFP/SFF DOM registers, HD44780 panels through LCDproc, TMC stepper drivers, and CUDA when there is a GPU worth using.

Happy to talk about Klipper tooling, OPNsense plugins, FreeBSD, local LLM serving, or Arabic localization of infrastructure software. Questions about the XGS drivers are best asked in the project's Discussions, where the answer stays for the next person.

• xgs: what the Traffic Shaper and the Captive Portal name is kept with the host — os-xgs-npu, 20 Oct
• xgs: the coprocessor's own uptime, load and memory on the Overview — os-xgs-npu, 20 Oct
• npuep: what tunnel flows encrypt is handed to the kernel's association — os-xgs-npu, 20 Oct
• No daily self-update: a release is installed from XGS: Updates or by hand — os-netreport and 5 more, 20 Oct
• xgs: XGS: About - the project, its author, its links and addresses, the disclaimer — os-xgs-npu, 20 Oct
• xgs: a Plugins tab on XGS: Updates - each appliance plugin's release, installed by hand — os-xgs-npu, 20 Oct