home.social

#libreops — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #libreops, aggregated by home.social.

fetched live
  1. CW: gig offer, sysadmin (and adjacent)

    Got some budget for loosely scoped infra work.

    This gig is remote and primarily asynchronous with a group of 3-5 other engineers.

    Must be comfortable with #Linux command line, able to configure applications like webserver & databases on the #Debian / #Ubuntu stack, and willing to learn whatever open source stuffs we're tinkering with this week.

    Networking experience is a plus, especially if you're familiar with #OpenVPN and/or #wireguard.

    #boostOK #libreOps

  2. CW: Tales From LibreOps (at this point I don't think it's microfic anymore, gonna drop that tag)

    Over the course of several hours, they familiarize me with the hardware basics, the workstation's build system, and the audit they'd begun performing before I arrived. The network is reachable. Attempting to write an email crashes the email client. All other functions seem to work. The messenger issue seems to just be from a stalled update.

    Stepping outside while waiting for the next step of the debugging process to complete, there's a weird ennui to stepping back into a world of trees and traffic and sidewalks.

    Belatedly remembering my original plan to resolve this ticket, I retrieve my logo-plastered tote bag and fish out the aluminum slab of my corporate notebook, still silently judging me for my every datapoint.

    Ignoring the itch of pervasive monitoring at each keystroke and pointer movement, I update the ticket with "work pending", and erase the part about an OS reload. No way am I going to attempt to modify this stack without a lot more time to study it, and that's going to have to happen in my off hours.

    Clocking out, I swipe the notebook against the sensor of the local secure locker pod, and drop my branded tote bag into the padded recesses of my newly assigned local locker.

    Tugging on the shoulder strap of my backpack to reassure myself it's still with me, I retrace my steps towards the building with the workstation.

    #microFic #LibreOps

  3. homelabs
    are both

    an exercise
    in digital archeology

    and

    writing prophetic
    self-fulfilling
    science fiction

    #libreOps

  4. Accidentally double queuing and attempting to use 150% of available CPUs, crashing the build system?

    It's more likely than you think!

    Thankfully, with this one simple config option, you can ensure your heavy jobs wait their turn!

    laminar.ohwg.net/docs.html#Con

    #LibreOps

  5. Build failed after 2 hours, 43 minutes...but manually re-running make in the same context (after installing a missing package) finished the build in about a minute.

    Re-running in a fresh workspace just to validate that it works...

    ...but also, was able to manually determine that it's an issue with lacking a module, rather than the off-by-one guile version that I thought in the first place...

    ...so, useful foundations, but not...the solution for my "no code for module" exception.

    #LibreOps

  6. Context, this is the single-board computer that acts as the development build orchestrator. It's got a couple gigs of RAM and a 4-core with aarch64 with one core pretty much pegged.

    Using #Laminar for these #LibreOps, it's my go-to for an open source build system.

  7. Yo #guix knowers, any idea why `guix describe` shows different results for the root and other accounts?

    Asking because "git.savannah.gnu.org..." is deprecated/depricating, and after setting the new URL in the system-level channel file, it's fixed for root but not for the other accounts.

    #libreOps

  8. Content type issue has been resolved, and we have signs of life from the API...this is excellent, it means I can start releasing code.

    Well, sort of. I need to finish the auth part first, but that's relatively simple compared to what we just did.

    Here's to #lisp and #guix for making this possible! #libreOps

  9. This is how Linux CIFS driver'sidsfromsid works, "discovered" from the source code: when a Samba server finds a file owned by a Unix user or group that it doesn't know about, Samba (and Windows) server uses two special SIDs to represent unmapped Unix accounts: S-1-22-1-uid (S-1-5-88-1-uid) and S-1-22-2-gid (S-1-5-88-2-gid). When Linux's cifs.ko sees them, it automatically maps them back to Unix accounts (same UID/GID as server) on the local client machine. But it only works if the fileshare is owned by someone on Unix that Samba doesn't know - if Samba already knows it, Samba maps them to a real SID in the ACL, so idsfromsid won't work. How is it supposed to be properly used remains a mystery... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=975221eca5fbfdb4b6b1d17c9e540d4d7627ce18 #libreops

  10. The Unix permission mapping features (cifsacl, idsfromsid, modefromsid) provided by Linux's CIFS driver for SMB v2+ are completely undocumented! In other words, nobody on the Internet (other than a few Samba and Microsoft Azure developers) knows how to mount a modern (non SMBv1) file share on Linux with proper Unix permissions. Wonderful! /s #libreops

  11. "Who needs a space heater when you can run FP32 FMA stress test on CPU 0, CPU 1, GPU 0 and GPU 1..." Repost with obligatory wattmeter reading added - great for the winter! #libreops

  12. New test bench is up and running. No need to worry about massive AWS server bills again. #libreops

  13. Super janky watercooling installed. "Who needs a space heater when you can run FP32 FMA stress test on CPU 0, CPU 1, GPU 0 and GPU 1... #libreops