OneCardboardBox

joined 3 years ago

To be pedantic, the MW in OpenMW doesn't stand for anything. It's supposed to make players think of "Open MorroWind", but only Bethesda has the right to use the name Morrowind.

[–] OneCardboardBox@lemmy.sdf.org 30 points 4 days ago* (last edited 4 days ago) (1 children)

Skywind: Playing the plot of Morrowind in the Skyrim engine. Game mechanics, spells, skills, models, textures, and bugs are all going to be similar to what you have in Skyrim, give or take some modding.

OpenMW: Playing Morrowind in an open source, crossplatform game engine. You are playing the exact same game as TES III (gameplay mechanics, spells, models, textures, etc are 1:1 identical in a vanilla install) but the code behind it is less buggy, more moddable, and it provides many modern quality-of-life improvements that the original engine couldn't do.

[–] OneCardboardBox@lemmy.sdf.org 8 points 1 week ago* (last edited 1 week ago) (5 children)

Can I leave all my drives connected, plug in a seperate SSD through USB, boot into Nobara live and install on that drive without it affecting my mint install?

Yes. Just double-check every part of the install process so you don't write to the wrong device.

Also, if I do that will it put the EFI file on the seperate SSD?

Probably yes (depends on the options you pick during the install process). The external drive will get its own boot partition with appropriate EFI files. Then to boot from it, you would select the external drive in your UEFI.

I use rEFInd as my EFI bootloader: It lets me chain load other boot options (external drives) without touching my motherboard UEFI settings. I leave it installed to my main boot partition, but it scans for other bootable partitions at startup. Then it auto-populates a selector list of my main install, or whatever other external devices are plugged in. It can chain load GRUB, other EFI bootloaders, Windows, etc from these devices, so you don't have to worry about compatibility with whatever bootloader the OS expects to use.

[–] OneCardboardBox@lemmy.sdf.org 9 points 1 week ago (1 children)

Explain how the cartoonist could avoid drawing the crossbow?

/s

Me!!!!

But I'm actually safe: Last month I fried half of my BTRFS array, and decided that instead of recovering the system, I'd rather copy over the relevant data and reinstall Arch from scratch. In doing so, I've shed the majority of AUR packages that my old system had. Of the handful of AUR packages on my new system, none were attacked.

You said you don't want the page to load. Do you even care if the browser opens?

What about overriding the default browser application that the terminal tries to use? Maybe there's some env variable to override the xdg browser default, and you could point it to a script that exits instantly.

[–] OneCardboardBox@lemmy.sdf.org 17 points 2 weeks ago

I like that the response from Amazon was very obviously AI-written

[–] OneCardboardBox@lemmy.sdf.org 7 points 2 weeks ago* (last edited 2 weeks ago)

Not sure if it's a mistake by the comic artist, or a mistake by the instructor from the comic, but the shooter was destined for failure.

The butt should be pressing into the shooter's shoulder, such that their body absorbs recoil. In this picture, they have it squashed beneath their armpit where recoil could flip the gun out of their hands and maybe smack their face.

[–] OneCardboardBox@lemmy.sdf.org 2 points 2 weeks ago (1 children)

I agree with the person who suggested linking to Wikipedia articles.

For example, it's not much help to learn that PCIe stands for Peripheral Component Interconnect Express, because nobody calls it that. As an outsider, now I'm wondering what a component interconnect is. It's much more useful to link to a page that gives context about how PCIe is actually used.

Very true. I believe FPGAs are also popular for aerospace applications, since it's cheaper to design and patch programmable hardware than to design and physically install ASICs.

[–] OneCardboardBox@lemmy.sdf.org 79 points 3 weeks ago* (last edited 3 weeks ago) (19 children)

Vivado is software for designing hardware on an FPGA. AMD bought out Xilinx, one of the big FPGA manufacturers, a few years back. FPGAs are basically programmable digital circuits: you configure a series of internal logic gates to represent the function of a circuit with memory, data busses, registers, gates, etc. In this fashion, an FPGA could be programmed to function like a CPU, a radio, a video encoder, or nearly any other piece of digital hardware. Very useful for hobbyists and prototyping.

The thing with FPGA software is that there are no open source alternatives. FPGAs have so many complicated blobs and signing keys and proprietary IP blocks that your only choice is to use the manufacturer's offering.

 

I generally let my server do its thing, but I run into an issue consistently when I install system updates and then reboot: Some docker containers come online, while others need to be started manually. All containers were running before the system shut down.

  • My containers are managed with docker compose.
  • Their compose files have restart: always
  • It's not always the same containers that fail to come online
  • Some of them depend on an NFS mount point being ready on the host, but not all

Host is running Ubuntu Noble

Most of these containers were migrated from my previous server, and this issue never manifested.

I wonder if anyone has ideas for what to look for?

SOLVED

The issue was that docker was starting before my NFS mount point was ready, and the containers which depended on it were crashing.

Symptoms: journalctl -b0 -u docker showed the following log lines (-b0 means to limit logs to the most recent boot):

level=error msg="failed to start container" container=fe98f37d1bc3debb204a52eddd0c9448e8f0562aea533c5dc80d7abbbb969ea3 error="error while creating mount source path '/mnt/nas/REDACTED': mkdir /mnt/nas/REDACTED: operation not permitted"
...
level=warning msg="ShouldRestart failed, container will not be restarted" container=fe98f37d1bc3debb204a52eddd0c9448e8f0562aea533c5dc80d7abbbb969ea3 daemonShuttingDown=true error="restart canceled" execDuration=5m8.349967675s exitStatus="{0 2024-10-29 00:07:32.878574627 +0000 UTC}" hasBeenManuallyStopped=false restartCount=0

I had previously set my mount directory to be un-writable if the NFS were not ready, so this lined up with my expectations.

I couldn't remember how systemd names mount points, but the following command helped me find it: systemctl list-units -t mount | grep /mnt/nas

It gave me mnt-nas.mount as the name of the mount unit, so then I just added it to the After= and Requires= lines in my /etc/systemd/system/docker.service file:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com/
After=network-online.target docker.socket firewalld.service containerd.service time-set.target mnt-nas.mount
Wants=network-online.target containerd.service
Requires=docker.socket mnt-nas.mount
...
view more: next ›