Indeed, good observation. Another observation is that 82% of that is debug info.

-OReleaseSmall -fno-strip produces a 580K executable, while -ODebug -fstrip produces a 1.4M executable.

zig's x86 backend makes for a significantly better debugging experience with this zig-aware lldb fork: https://github.com/ziglang/zig/wiki/LLDB-for-Zig

I don't recall whether it supports stepping through comptime logic at the moment; that was something we discussed recently.

The biggest impact suckless had on me was via. Their Stali Linux FAQ: https://sta.li/faq/ .

They've built an entirely statically linked user space for Linux . Until then i never questioned the default Linux "shared libraries for everything" approach and assumed that was the best way to deliver software.

Every little cli tool i wrote at work - i used to create distro packages for them or a tarball with a shell script that set LD_LIBRARY_PATH to find the correct version of the xml libraries etc i used.

It didn't have to be this way. Dealing with distro versioning headaches or the finnicky custom packaging of the libraries into that tar ball just to let the users run by 150 kb binary.

Since then I've mostly used static linking where i can. AppImages otherwise. I'm not developing core distro libraries. I'm just developing a tiny "app" my users need to use. I'm glad with newer languages like Go etc... static linking is the default.

Don't get me wrong. Dynamic linking definitely has it's place. But by default our software deployment doesn't need to be this complicated.

As someone who used Qute for a long time:

* Python is much slower than SBCL (yes, even if rendering is done by Blink); including the lack of threading

* Bookmarks are pure crap, they don't have tags nor directories to sort them better

* Less hackable (e.g. something that should be possible in Nyxt: https://github.com/qutebrowser/qutebrowser/issues/3933)

* Massive gaps: https://github.com/qutebrowser/qutebrowser/issues/2328 https://github.com/qutebrowser/qutebrowser/issues/2492 https://github.com/qutebrowser/qutebrowser/issues/5731 (!!!)

* Per domain/URL settings never progressed further than the initial batch of properties: https://github.com/qutebrowser/qutebrowser/issues/3636

* Adblocking is better than hostfile but still missing a lot compared to uBlock (https://github.com/qutebrowser/qutebrowser/issues/6480). No script blocking matrix like uBlock "advanced mode" at all.

My impression is that it has been stuck in bug fixing/dependency churn for a long time now. Switched to Firefox while waiting for Nyxt to be usable (apparently, Nyxt 4 will be it).

    def redirect(info: interceptor.Request):
        if info.request_url.host() == "en.m.wikipedia.org":
            new_url = QUrl(info.request_url)
            new_url.setHost("en.wikipedia.org")
            try:
                info.redirect(new_url)
            except interceptors.RedirectFailedException:
                pass

I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security.

The big concern I have however is hardware support, specifically networking hardware.

I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of hardware as well as network support, and use a sort of Rust OS/abstraction layer for the rest, bypassing or simply not using the originally booted kernel for all user land specific stuff.

My own summary and collection of information about the problems with the Unlicense: https://chrismorgan.info/blog/unlicense/

(I collected that mostly because I didn’t find all the relevant information in one place, or explanation of the reasonable alternatives.)

I read this a long time back somewhere -

A person dies twice. The first time is when they die. The second time is when the last person who remembers them dies.