goombacloud

They won't build software, they'll let some AI-based software do the execution of their instructions (which is inefficient, opaque, vendor-locked, not reproducible etc.)

If you mean using Incus on Flatcar, there is a PR for adding Incus as systemd-sysext extension.

Flatcar inside Incus is a bit more difficult: for Flatcar being a container one can import https://stable.release.flatcar-linux.net/amd64-usr/current/f... and for it being a VM I don't know if the regular image works. A major hurdle is that one has to tweak the way VMs/containers are configured because normally Ubuntu's cloud-init is used but in Flatcar only coreos-cloudinit or Ignition is supported and there are differences in the way the user-data has to be set up and the contents as well. But in the end Incus would be one more "cloud" platform to support and one could make the Incus integration as nice as with other platforms where Flatcar runs on (OpenStack, VMware, etc.).

With static binaries that is not needed (and you can use OS=_any in the extension release file to mark them compatible).

If you want to repackage distro binaries without recompilation, you can have a look here: https://github.com/flatcar/sysext-bakery/pull/74 There are two tools, one can bundle the needed libs in a separate folder, and the other one works more like Flatpak and uses a full chroot. Since you already know what files are needed at runtime I think you could try the first approach, otherwise the second might be easier.

In https://archive.softwareheritage.org/browse/revision/e446ab7... one can open the patches and then click the "Changes" sub-tab. Stuff like this looks like a perf improvement but who knows if a tricky bug is introduced that was aimed to be exploited https://archive.softwareheritage.org/browse/revision/e446ab7... There are more patches to be vetted unless one would give up and say that 5.2 should be used as last "known-good".

This might not be complete because this statement "More patches that seem (even in retrospect) to be fine follow." lacks some more backing facts. There were more patches before the SSH backdoor, e.g.: "Lasse Collin has already landed four of Jia Tan’s patches, marked by “Thanks to Jia Tan”" and the other stuff before and after the 5.4 release. So far I didn't see someone make a list of all patches and gather various opinions on whether the changes could be maliciously leveraged.

When socat is around a simple server can also be constructed with it:

        tee /tmp/server > /dev/null <<'EOF'
        #!/bin/bash
        set -euo pipefail
        SERVE="$1"
        TYPE="$2"
        read -a WORDS
        if [ "${#WORDS[@]}" != 3 ] || [ "${WORDS[0]}" != "GET" ]; then
          echo -ne "HTTP/1.1 400 Bad request\r\n\r\n"; exit 0
        fi
        # Subfolders are not supported for security reasons as this avoids having to deal with ../../ attacks
        FILE="${SERVE}/$(basename -- "${WORDS[1]}")"
        if [ -d "${FILE}" ] || [ ! -e "${FILE}" ]; then
          echo -ne "HTTP/1.1 404 Not found\r\n\r\n" ; exit 0
        fi
        echo -ne "HTTP/1.1 200 OK\r\n"
        echo -ne "Content-Type: ${TYPE};\r\n"
        LEN=$(stat -L --printf='%s\n' "${FILE}")
        echo -ne "Content-Length: ${LEN}\r\n"
        echo -ne "\r\n"
        cat "${FILE}"
        EOF
        chmod +x /tmp/server
        # switch from "text/plain" to "application/octet-stream" for file downloads
        socat TCP-LISTEN:8000,reuseaddr,fork SYSTEM:'/tmp/server /tmp/ text-plain'

I really think we should have means of spawning wasm components from wasm components. How the runtime runs them should be up to the runtime - it could be directly backed by kernel primitives but it could also be in a browser. Leaking posix things into wasm… is something I'd rather never want to see. Let's come up with something better as wasm did aim for from the start.

To spot more common problems I recommend:

  alias shellcheck='shellcheck -o all -e SC2292 -e SC2250'

For regular Linux users you can do:

  sudo touch /etc/udisks2/tcrypt.conf
  sudo systemctl restart udisks2

Does this finally have UEFI by default?

The next logical step would be to only support wasm programs ;)

gzip uses LZ and Huffman coding and not arithmetic coding with a predictor, so yes, these are not similar.

Specially compression algos that use arithmetic coding with interval weights adjusted based on the prediction of what is likely coming next are very similar. They adjust the arithmetic coding (https://en.wikipedia.org/wiki/Arithmetic_coding) based on the context of the byte/bit to predict, so the more accurate the predicted continuation is, the more efficient is the encoding. The task is very similar to that of the transformers like GPT. A perfect prediction will almost have no additional storage cost because the arithmetic interval doesn't get smaller, and thus no bit gets stored - but anyway, you have to count the size of the decompressor to get a fair benchmark.

Audio is covered as well, as written in the article, I recommend reading it.

https://www.mojeek.com/ even has its own crawler

There are multiple ways to start containers, one of them is to define systemd units in Ignition. If that part needs to change, reprovisioning is needed but a new "flatcar-reset" tool (in Alpha) should make the barrier for reprovisioning lower by only requiring a reboot and being able to keep wanted local data. In the past Ansible was a common choice if neither Kubernetes, Nomad or even docker compose are used.

There is a changed version that includes drop-in config files, masking, and loading defaults from /usr/ instead of requiring full config files to live under /etc: https://uapi-group.org/specifications/specs/base_directory_s...

For most use cases you can configure autosuspend and always wrap your commands with systemd-inhibit or gnome-session-inhibit. E.g., for an SSH session when starting tmux, or when you start the music player (for GNOME I guess that many players already do register inhibitors only when they play). One could also write a server that registers inhibitors as long as it serves connections (one could also use systemd socket activation and wrap the server in systemd-inhibit and terminate the server when done).

You can spawn a (priv) container with the host PID namespace and then trace from there.

Not really, you can start it from the host and trace any container process you like. On Linux the processes are in one large tree and the host has IDs for all container processes. Inside the container you may have different IDs if a pid namespace is used but from the outside these processes are in the host's process tree and have regular IDs.

You don't need to be in the container and trace from there, you can run strace outside of the container (you just have to make sure that the process ID you use is the one as seen from the host).

I find myself using cat or less even thought I have bat around because copying from cat or less works best and you don't get line breaks inserted.

It's sad to see that Apple Silicon gets extra treatment and arm64 work suddenly gets done while for Linux it's still amd64-only. With Signal it's the same and they also don't offer arm64 builds.

Nowadays it's very easy to build for arm64 - you either go the way with cross compilation or you go the way with full qemu binary emulation which is as simple as it gets because you would build within an arm64 docker image, e.g., docker.io/arm64v8/alpine or docker.io/arm64v8/ubuntu and qemu-static handles the emulation (it will be slower than cross compilation but as long as speed is acceptable you can go this easy way).

I think the hard part is to know when caching is not allowed, and for that the compiler is a good point to manage such a cache because it could add metadata such as compiler version (maybe even patches?), compiler flags etc which a wrapper may miss. This disintegration of ccache and the compiler makes me not really trust it because these two could easily get out of sync and you would not easily notice when/why the result is wrong.

Building into the kernel instead of using modules is not perfect because it increases RAM usage when you don't use certain modules compared to having them loaded on demand.

Love this modularity of swapping the compute modules!

By the way, the leading nncp in the LTCB (text.html) "is a free, experimental file compressor by Fabrice Bellard, released May 8, 2019" :)

The comparison doesn't make much sense because for fair comparisons you have to measure decompressor size plus encoded image size. The decompressor here is super huge because it includes the whole AI model. Also, everyone needs to have the exact same copy of the model in the decompressor for it to work reliably.

Is the "USB-PC" port to forward the server's serial console or doesn't it have a port for that? PiKVM seems to support IPMI SoL.

That's the time passing in the vessel, not bad but still it means that such a mission would have to be completely self-sufficient and not rely on anything on/from Earth…