Context
We maintain guria/misexeuntu, a downstream fork of exeuntu that drops the baked coding agents in favor of mise-managed dotfiles materialized at boot. While auditing its footprint against stock exeuntu we measured several things that look like dead weight or rough edges. Some of these may be deliberate choices or already-known tradeoffs on your side — flagging them with data rather than assuming. Happy to send PRs for whichever parts you want.
All numbers are dpkg-query Installed-Size or du on running VMs (ubuntu 24.04, amd64).
1. Packages with no reverse dependencies (~500 MB)
apt-get why (after apt-get update) finds nothing depending on:
| package |
size |
locales-all |
232 MB (replaced by locales + locale-gen en_US.UTF-8 ru_RU.UTF-8 ≈ 4 MB) |
snapd |
130 MB — units are already masked/disabled in the Dockerfile, and snap cannot function in the container anyway |
python3-botocore + python3-boto3 + python3-s3transfer + deps |
~120 MB — no aws binary in the image |
pocketsphinx-en-us |
74 MB speech models |
debian-keyring |
32 MB |
These purged cleanly in our build (autoremove swept the orphaned deps) with no functional change we could detect.
2. Mesa/LLVM GPU stack appears unused by headless-shell (321 MB)
libllvm20 (140 MB) + mesa-vulkan-drivers (96 MB) + mesa-libgallium (42 MB) + the small dri/vdpau/va drivers. SwiftShader ships inside the /headless-shell/ bundle itself (libvk_swiftshader.so), and an A/B test supports that it does all the rendering:
- rendered https://example.com via chromedp (CDP) on two otherwise-identical VMs, one with the stack and one without
- screenshots were byte-identical (
compare -metric AE = 0 differing pixels out of 480000)
We kept the glvnd loader libraries and libgbm1.
3. Question: who uses the baked Go toolchain? (282 MB)
/usr/local/go is the single largest non-docker item in /usr/local. In our usage nothing on the machine needed system Go (per-project runtimes come through mise), so the fork dropped it — but this one is plausibly intentional for exeuntu users, so asking rather than proposing.
4. Cost note on unminimize
The unminimize + apt-get install --reinstall $(dpkg-query -W) + mandb -c sequence restores base-package docs at ~91 MB plus several minutes of build time on every rebuild. We dropped it in the fork (newly installed packages still ship their own man pages since the dpkg excludes files are removed). No action requested — mainly documenting where a chunk of build time goes.
5. One-shot headless_shell --screenshot hangs in VMs (independent of #2)
On exeuntu VMs, the one-shot mode crashes/hangs even on a local page:
/headless-shell/headless-shell --no-sandbox --disable-gpu \
--screenshot=/tmp/x.png --window-size=1280,900 https://example.com
never writes the file and logs repeated Failed to send GetTerminationStatus message to zygote / Socket closed prematurely; --single-process, --disable-dev-shm-usage don't help; it reproduces identically with and without the mesa stack, and even for data:text/html URLs, while plain CDP (chromedp) renders fine. Possibly inherent to the nested-container environment — mentioning it here since headless chrome is a headline use case of the image and others may hit the same wall with CLI flags.
6. Stale image content shortly after pushing a new build
Timeline from today: new image pushed to ghcr.io/guria/misexeuntu at 18:59 UTC; a VM created from :latest at 19:16 booted the previous build's filesystem; recreating pinned by digest also served the old content once. Creating by explicit commit-sha tag worked every time. Looks like a cache somewhere between GHCR and VM provisioning. Not blocking us (sha tags are a fine workaround), just FYI in case it surprises others too.
Net effect in the fork
Rootfs 8.0 GB → ~6.4 GB (of a 25 GB disk), package count 1177 → 1164, and builds got noticeably faster mostly from dropping the reinstall-everything step.
Context
We maintain guria/misexeuntu, a downstream fork of exeuntu that drops the baked coding agents in favor of mise-managed dotfiles materialized at boot. While auditing its footprint against stock exeuntu we measured several things that look like dead weight or rough edges. Some of these may be deliberate choices or already-known tradeoffs on your side — flagging them with data rather than assuming. Happy to send PRs for whichever parts you want.
All numbers are
dpkg-queryInstalled-Size orduon running VMs (ubuntu 24.04, amd64).1. Packages with no reverse dependencies (~500 MB)
apt-get why(afterapt-get update) finds nothing depending on:locales-alllocales+locale-gen en_US.UTF-8 ru_RU.UTF-8≈ 4 MB)snapdpython3-botocore+python3-boto3+python3-s3transfer+ depsawsbinary in the imagepocketsphinx-en-usdebian-keyringThese purged cleanly in our build (
autoremoveswept the orphaned deps) with no functional change we could detect.2. Mesa/LLVM GPU stack appears unused by headless-shell (321 MB)
libllvm20(140 MB) +mesa-vulkan-drivers(96 MB) +mesa-libgallium(42 MB) + the small dri/vdpau/va drivers. SwiftShader ships inside the/headless-shell/bundle itself (libvk_swiftshader.so), and an A/B test supports that it does all the rendering:compare -metric AE= 0 differing pixels out of 480000)We kept the glvnd loader libraries and
libgbm1.3. Question: who uses the baked Go toolchain? (282 MB)
/usr/local/gois the single largest non-docker item in/usr/local. In our usage nothing on the machine needed system Go (per-project runtimes come through mise), so the fork dropped it — but this one is plausibly intentional for exeuntu users, so asking rather than proposing.4. Cost note on unminimize
The
unminimize+apt-get install --reinstall $(dpkg-query -W)+mandb -csequence restores base-package docs at ~91 MB plus several minutes of build time on every rebuild. We dropped it in the fork (newly installed packages still ship their own man pages since the dpkg excludes files are removed). No action requested — mainly documenting where a chunk of build time goes.5. One-shot
headless_shell --screenshothangs in VMs (independent of #2)On exeuntu VMs, the one-shot mode crashes/hangs even on a local page:
never writes the file and logs repeated
Failed to send GetTerminationStatus message to zygote/Socket closed prematurely;--single-process,--disable-dev-shm-usagedon't help; it reproduces identically with and without the mesa stack, and even fordata:text/htmlURLs, while plain CDP (chromedp) renders fine. Possibly inherent to the nested-container environment — mentioning it here since headless chrome is a headline use case of the image and others may hit the same wall with CLI flags.6. Stale image content shortly after pushing a new build
Timeline from today: new image pushed to ghcr.io/guria/misexeuntu at 18:59 UTC; a VM created from
:latestat 19:16 booted the previous build's filesystem; recreating pinned by digest also served the old content once. Creating by explicit commit-sha tag worked every time. Looks like a cache somewhere between GHCR and VM provisioning. Not blocking us (sha tags are a fine workaround), just FYI in case it surprises others too.Net effect in the fork
Rootfs 8.0 GB → ~6.4 GB (of a 25 GB disk), package count 1177 → 1164, and builds got noticeably faster mostly from dropping the reinstall-everything step.