YouTube Video

The original EverQuest theme song was mine. Captured the epic wide-eyed wonder of going on an adventure perfectly.

Hey there! And thank you for reading.

Let's take your example, as a Nomad cluster operator. The Acme Corporation may have a team for provisioning and maintaining this Nomad cluster. The organization wants to give customers the option for self-service. As a Nomad cluster operator on the Nomad team, because you are empowered with agency and visibility, you get to think of creative solutions to the problem of self-service. The billing team? They're doing that too. And your two teams may collaborate. But the onus is on you to be creative and work within your skillset to best deliver.

Maybe you decide to go sit with the billing team for a week to understand the provisioning flow from the moment a customer presses pay to the automatic creation of a new Nomad cluster. Because you are empowered, you act. You're happier because you don't have to go through seven layers of command to be effective.

Does that help?

I run Guix System on my personal laptop and Project Bluefin on my work machine.

Guix is even easier to get started with now thanks to the Guix Packager , a web UI for writing Guix package definitions.

Project Bluefin auto-updates thanks to its use of container images deliver system updates. It's also just a great platform to get started writing containerized apps, since it ships with rootless Podman by default and you can easily add new developer tools using just commands.

I deeply love the story of Grendel. He's left an invisible imprint on me since I was a young boy fishing issues from my father's oversized trunk that squatted tempestuously in our living room. Thank you for this summary! I learned a few things I hadn't known.

For those who grew up with Grendel and now work in tech, like me, I did a talk on mindfulness and conflict in the workplace using the leitmotif of Grendel. Matt Wagner was kind enough to allow me to use his art for the talk.

Hey there, for a very simple start there's the compose.yaml file at the bottom of my comment here.

The Intel discrete cards are fantastic value for money. There's plenty of folks on the internet who can attest to this. Intel's support story in general (so not just graphics cards) on Linux has been nothing less than sterling. If you're using any Linux kernel you can expect Intel stuff to just work. It's been this way for at least a decade.

WebOS powers TVs now and, from the article, Amazon intends this replacement to cover their Fire tablet line. WebOS ticks all their boxes, especially since apps in Amazon's new flavor are intended to be delivered as React Native web apps.

I'm devastated they didn't choose to pick up webOS for this.

If you're looking for the GitLab version of Codeberg's hosted Forgejo Git forge, there's Framagit hosted by Framasoft.

This sounds like something on your end as I get cached builds every time, rootlessly even. Podman also supports cache mounts.

Check my comment history for an example of a simple bind mount compose.yaml I use for developing a small Python project. It's exactly the same as Docker Compose (since Podman Compose follows the Compose spec) but if you're just getting started, it might be a good skeleton to build on.

There's real usability benefits too. I've collected some anecdotes from Reddit:

Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related stuff like volumes, configs, the control socket, etc. in my home directory and standard user paths vs. scattered all over the system. Permission issues with bind mounts just totally disappear when you go rootless. It's so much easier and better than the root privileged daemon.

and,

If you are on Linux, there is the fantastic podman option "--userns keep-id" which will make sure the uid inside+the container is the same as your current user uid.+

and,

Yeah in my experience with rootless you don't need to worry about UID shenanigans anymore. Containers can do stuff as root (from their perspective at least) all they want but any files you bind mount into the container are still just owned/modified by your user account on the host system (not a root user bleeding through from the container).

finally,

The permissions (rwx) don't change, but the uid/gid is mapped. E.g. uid 0 is the running user outside the container, by uid 1 will be mapped to 100000 (configurable), and say 5000 inside the container is mapped to 105000. I don't remember the exact mapping but it works roughly like that.

I try to write about it as much as I can here! There's also !guix@lemmy.ml

For something simple that just needs a bind mount like

services:
  app:
    build:
      context: .
      target: base
    volumes:
      - ./debaser_studio:/opt/app-root/src/debaser_studio/debaser_studio
    ports:
      - "3000:3000"
      - "8000:8000"
    user: default

I haven't found any issues. Do you have more complex needs?

I use Logseq for everything. I've found the more you throw into it the more useful it becomes since your touch points are so frequent and that gets you thinking through and exploring your graph more. I've yet to use any of the data query features but I've heard they're incredibly powerful.

Whiteboards are just a fantastic way for modeling a topic or themes you know you want to turn into a deliverable when the how is uncertain.

Now that I've finished the first draft of an article on setting up rootless Podman on Guix System, I'm using and building out a set of tools to support a new article covering an all Red Hat stack from inner loop to CI.

So far, it's

• OpenShift for the platform services run on
• Podman for my local container engine
• Podman Compose for inner loop development
• OpenShift Pipelines for CI
• Shipwright for building container images locally with Buildah
• Quay for image scanning and storage
• OpenShift Serverless for scale-to-zero deployments

I did a little research and found a Redditor who was able to answer better than me:

Logseq makes it easier to work with blocks, transclusions can be edited in place, and you can automatically be building another page consisting of blocks you’re writing in your daily journal or another page.

EDIT: I was really curious about the major differences and what is enabled by Logseq's block-based architecture so I asked my network on Mastodon and got some great answers!

Some folks may not know this but Logseq has a built-in whiteboard feature too that's also FOSS. I use it all the time to mind-map new blogposts and newsletters.

In Logseq the starting page is always the journal page for the day. This allows you to build up content without worrying about where it should go. Once you have something you feel you can run with, then you can move it to its own page.

EDIT: more features enabled by Logseq's block-based (bullets) architecture over on Mastodon.

Logseq is block-based. Each bullet is a block. This is very powerful because it allows you to interlink concepts, ideas, at the level of the block vs page.

You can use Git, Syncthing or any other FOSS sync tool of your choice.