i’m lizard
The email ecosystem is changing in recent years but yeah, it’s best to expect that there is at least one opportunity for any given email to be sent over the internet unencrypted. MTA-STS has been slowly changing the landscape but adoption isn’t going all that great.
Powered through Beastieball over the past week, a creature collector/“sports” game from the devs of Chicory and Wandersong. I had fairly high expectations because I enjoyed the devs previous work, but it turned out even better than expected. Lots of cool creature designs, music is Lena Raine’s usual standout stuff, story kept my attention.
The sportsball system is surprisingly complex, if a little hard to learn. I went through multiple types of team setup and felt like a lot of different setups were viable in the end. Every match is a 2v2, every offensive turn is 3 actions worth, and you get a defensive turn too. You really have to build a team with good synergy between them and be smart about swapping in and out.
Only real downside is it’s still early access and a decent chunk of creatures have placeholder art or don’t have the full set of animation frames yet. Most are reasonably finished but there’s a couple that are a little jarring.
You go to the settings and verify it. You don’t have to host anything, just verify that you own the domain via text file or DNS record and choose to set it as your handle. Bluesky’s ATProto has a couple extra layers of indirection and it’s very easy to get a custom handle as a result.
The downside of this setup is that running your own complete network is completely impossible. If you want to follow theonion.com, anyone can find did:plc:a4pqq234yw7fqbddawjo7y35 in the DNS without too much work. That’s the identifier for The Onion’s Bluesky account, and even if they swapped back to .bsky.social, that ID number would stay. But that DID tells you absolutely nothing about where the data is currently hosted.
So how do you figure that out? Well, you register it with https://plc.directory/ which is ran by Bluesky and cannot currently be replaced. There’s fancy cryptography involved that makes it hard for them to spoof data, but they are perfectly capable of simply not giving any data out for any given DID.
I don’t have Obsidian around, but this has been happening elsewhere lately too, almost certainly because of this underlying Electron issue: https://github.com/electron/electron/issues/43819
Unfortunately there’s not much you can do about it. Electron decided to depend on functionality not yet in a released version, and that very interesting choice flows down to everything that updates their Electron on the regular.
Sorry, I’ve had a (self-imposed) busy week, but I have to admit, that also has me rather stumped. As far as I can tell, your second entry should work. If the device is visible in /dev/mapper under a name, it should be able to mount under that name.
The only thing I can think of is that some important module like the ext4 module might be missing somehow? You can get pretty confusing errors when that happens. Dracut is supposed to parse /etc/fstab for everything needed to boot, and maybe that’s not recognizing your root for some reason. dmesg might have some useful info at the end after you try to mount it. If that’s what’s happening, you could try to add add_drivers+=" ext4 " in your dracut.conf and regenerate it (the spaces are important!). But if that’s not it, then I’m probably out of ideas now.
I think you should check your root= line and add a rd.luks.uuid= to make it open it. Dracut will by default open the root FS as /dev/mapper/luks-abcdef... based on the LUKS container UUID. You can get that with cryptsetup luksUUID. /dev/mapper/root is just never going to show up unless you’ve assigned a custom name to that with the barely documented rd.luks.name, and I don’t see that in your setup. The cryptroot and cryptdm parameters aren’t used by Dracut either.
With all of that missing it’s just gonna wait for that /dev/mapper/root to magically show up out of nowhere, without ever trying to open it.
A correct cmdline will probably look something along the lines of root=/dev/mapper/luks-<uuid> modules=sd-mod,usb-storage,ext4 rootfstype=ext4 rootflags=rw,relatime rd.luks.uuid=<uuid> and once opening with passphrase works, you can start to mess with rd.luks.key=/awesome.key (and readd quiet when done debugging, if you want it that way).
ldconfig errors and the missing modules should be fine. musl’s ldconfig is just a bit different but also isn’t required in quite the same way. I don’t think you should need to mess with modules manually. I don’t think you’re using LVM’s userland for your setup, just all the device-mapper kernel modules. Dracut will pull all the necessary bits in for you if you’re setting it up for LUKS.
For current exports, it’s some custom .csm/.csd file combo. Not sure if there’s any tools for working with it, seems like it’d be more annoying than just using a normal archive format either way.
It technically still exists in the game properties -> installed files tab, but it doesn’t really work. The backup files you get require you to be online to meaningfully restore and will trigger a patch to the latest game version.
Practically speaking it’s better to just make a copy of the game install directory manually, gives you a better chance of things working (even though most games require some kind of external tooling for that).
Dracut may have this functionality already built in via rd.luks.key, so a custom module would really only make sense if you’re trying to do more than that. You can probably get away with just using that if you just want it to work, but if you want to customize stuff:
I suspect your module is running well after the device is already supposed to be cryptsetup opened. The way the default crypt module handles it is by setting up udev configuration in a very early phase, and then having udev request the password a little bit later when it finds the device it’s trying to open, until all devices are ready. It’s a complex mechanism compared to Alpine’s straightforward script, but it’s much more flexible when it comes to ordering of things like RAID/network devices/LUKS/etc.
The result of that is that your code would have to run much earlier. There’s some documentation on how hooks work, and the builtin rd.luks.key / keydev handler runs at cmdline 10. That’s well before your pre-mount, and probably where you’d want to run your code. Based on a cursory inspection of the other code, you could either cryptsetup open it yourself if you use the name it expects (rd.luks.name= cmdline parameter or luks-$luks_container_uuid), or you could use that /tmp/luks.keys mechanism (it’s a dracut-internal thing so you won’t find much documentation, but it lives in crypt-lib.sh, cryptroot-ask.sh and probe-keydev.sh).
As for debugging, the cmdline manpage has a few decent enough options. rd.break=cmdline or similar can force a shell before Dracut goes through a specific phase of hooks. You should be able to manually test doing things similar to your script at that point.
You’d be looking for /usr/share/mkinitfs/initramfs-init . I’ve never customized that myself, but it looks like there’s already some support for a keyfile if you look for KOPT_cryptroot and check that block of code. That looks like it’s mostly set up for a keyfile embedded into the initramfs, but I guess it should be possible to replace that code with something that grabs the keyfile off an USB drive.
I suppose you’d make a copy of it, put it somewhere in /etc or whatever and change the mkinitfs.conf to point to it. init="/etc/whatever/myinitramfs-init" should do the trick since the config file just gets sourced in. That said you’re definitively heading into unknown territory here. It might be easier to just use Dracut or the like instead.
mkinitfs doesn’t support running custom shell hooks. mkinitfs is very, very, very bare-bones custom code and the whole features concept exists only to pull extra files and kernel modules into the initramfs, not for extra logic.
You’d either have to customize the init script itself (not impossible, it’s 1000 lines) and pass -i/set init= in the .conf, or install Dracut/Booster instead (which should “just work” if you apk add them, but I’ve had no need to do so).
All of the cool development-related Nix things like pinning a project to known-good library versions (for regression tests or otherwise) don’t really need you to run NixOS. If you like NixOS then it’s a perfectly usable distro for development work, but all of the powers come from Nix itself, and that can be installed anywhere you feel comfortable with.
The only real pro of running full NixOS is that everything you work on will test a relatively uncommon *nix setup by its nature. Things like developer-only scripts with hardcoded shebangs are more likely to break on NixOS than they would on a conventional Linux distro with Nix installed. That’s something potentially worth fixing as it might also hurt the developer experience on *BSD/Mac systems.
That already happens constantly and I’d consider this the consequence of it, rather than the cause. You can only issue so many vetoes before people no longer want to deal with you and would rather move on.
The recent week of Wayland news (including the proposal from a few hours ago to restate NACK policies) is starting to feel like the final attempt to right things before a hard fork of Wayland. I’ve been following wayland-protocols/devel/etc from the outside for a year or two and the vibes have been trending that way for a while.
I’ll freely admit I don’t use that thing and was under the assumption it was feature complete. Regardless, the Android and iOS clients are also open, and I’ve found absolutely no indications that there’s any blobs in the repo or the like.
It’s not and I’m not sure how that article arrived at that conclusion. Their E2EE crypto is problematic homebrew crypto, but that’s very, very different from being closed. The whole desktop client including the implementation of that crypto is fully open source and lives right on GitHub. Plenty of people have independently reviewed it and came back with a very iffy impression of the whole thing.
Really the only difference is that Telegram doesn’t publish their backend, but the one Signal publishes is missing a couple of bits related to their “spam filter”, which happens to take in the source & destination of messages and do anything it wants with them. That doesn’t matter for either platform’s E2EE properties in any case, since distrusting the server is the whole point of E2EE.
Digging into the GitLab & related discussions, the main takeaway I got is that FFmpeg’s API supposedly meshes better with what Wine needs to provide to Windows code, simplifying things overall. GST is pretty heavy on asynchronous/background processing, which is normally something I’d consider good for media, but if the API you’re expected to implement is synchronous then I guess it only adds complexity.
Moderation is handled by each instance’s version of that community separately.
Reddit/Lemmy/etc communities differ from something like Tumblr/Cohost by also having per-community rules, and nobody has the time to moderate hundreds of communities according to their per-community rules.
It’s relatively easy to keep an instance free of spam/overly blatant hate/etc, since that is a fairly common set of rules. But it’s much harder to keep a “world news” style community being overran with US-centric posts, or a discussion community on a specific subject from being filled to the brim with memes, or posts that are only very vaguely adjacent. Without centralized per-community moderators, it would fall on general instance moderation to make decisions about whether a post about an Undertale hack fits in the Undertale community. That’s probably going to go wrong more often than not.
You can have a website that is only moderated according to global rules with tags being a free-for-all, but you fundamentally end up building something along the lines of Tumblr or Cohost, which attracts a different audience, including those that know how to rules lawyer their way in such an environment; tagging 20 mediocre photos a day with #photography instead of just a good one, for example. With the end of Cohost approaching, I wouldn’t be surprised if some tried to build that kinda thing, but it’d likely end up having a very different vibe.
I don’t know if the Atari Lynx counts as non-major. Anything from Atari should probably count as major, the thing supposedly sold 2 million units, but I can’t remember the last time I’ve seen anyone mention it and that’s still less than 2% of the Game Boy’s 110m+.
I got the original model as a hand-me-down towards the end of the 90s and I wasn’t super fond of it. The thing looks and feels like a brick and ate batteries for breakfast, the internet says 5 hour battery life but I remember getting like 2. The “left-hand mode” is a cool concept but putting two pairs of A/B buttons on the device feels like something they could’ve done better. It had color, a couple of arcade ports were really great games and there was Chip’s Challenge, but younger me got exhausted just using the damn thing.
Basically yes. Rancher Desktop sets up K3s in a VM and gives you a kubectl, docker and a few other binaries preconfigured to talk to that VM. K3s is just a lightweight all-in-one Kubernetes distro that’s relatively easy to set up (of course, you still have to learn Kubernetes so it’s not really easy, just skips the cluster setup).
Acts as access point, if you connect to it from another device you get access to stuff on the SD card (via app or built-in webserver)… at least in theory. Quality varies.