• 0 Posts
  • 6 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle
  • My Linux laptop is set to check for updates daily, which I then apply manually when I notice the tray icon. I sometimes procrastinate when it comes to reboots though.

    My Android phone is on auto-update, which seems to mean whenever it’s being charging for a few hours (so typically when charging overnight). Because the battery is still pretty good and I don’t need to charge daily, that comes down to once every 2-3 nights or so.

    My personal Linux servers (which run my self-hosted apps) are configured to automatically apply all updates (and reboot if necessary afterwards) at the time of day I’m most likely to be awake and available to manually fix stuff if anything goes wrong. The Docker-containers that run on them mostly get auto-updated to the latest version every 6 hours by Watchtower. A few containers have more cautious policies though, ranging from pinning a major version (but auto-upgrading to new minor versions within that) to pinning a specific version and at most sending a notification if there’s an update. The latter is limited to stuff that has broken before and/or where newer releases are known to be buggy or incompatible.

    When it comes to major updates (i.e. new distro releases) of my Linux machines, I typically wait about a month before upgrading because I’ve been bitten by release-day bugs before.


  • I’ve never used Rust or Zig, but for Go: (disclaimer: this is all from memory, so there may be inaccuracies or out-of-date information here)

    Go does not allow circular references between modules. That restriction allows the compiler, when compiling a module, to not only put the compiled machine code in the resulting object file for that module but also the information that in C would be required to be in a header file (i.e. type definitions, function signatures, and even complete functions if they’re considered candidates for inlining, etc.). When compiling a module that imports others, the compiler reads that stuff back out of those files. Essentially a compiled Go library has it’s auto-generated “header file” baked-in.

    In older versions this was actually human-readable: an early part of the object file would essentially look like trimmed-down Go when opened in a text editor. IIRC they’ve switched to a binary serialization format for this some years back, but AFAIK it still essentially works the same.

    I guess when comparing to C or C++, you could compare this to automatically generating pre-compiled headers for every module, except the headers themselves are also auto-generated (as you alluded to in your post).

    If by “shared library” you mean a dynamically linked one: IIRC Go does allow shared libraries to be used, but by default all Go code is linked statically (though libraries written in other languages may be dynamically linked by default, if you import a module that requires it).