miggol

A slight limitation of worktrees is that you can only have a branch checked out once in all of your worktrees. I guess that's just how git works.

But when I want to checkout a branch that's already checked out in another worktree, Magit just plain refuses. I wish it would offer me to either:

1. Switch to that worktree instead

2. Detach head in the other worktree and checkout here

Would be such an improvement! No excuses though, I love magit and might as well hack this myself. I'm just bad at elisp.

> And wondered if tailscale was doing a bit more magic than tinc is here?

Yes, tailscale, rayfish, zerotier and all use an existing network of relays to do nat traversal. Tinc doesn't provide that, but allows you to be completely independent if you get (or already have) a $5 VPS.

Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.

It's the combination of geographical data (maps) linked to its visual representation in the world (footage of structures, roads, landscape features) that is useful.

The geographical data already exists in digital maps. And I would expect competent militaries already have maps of enemy territory. It's the second part that was so far missing.

This combined set allows the training of AI models that can say, "When my surroundings look like x, that looks like y on a map".

So when your drone's GPS gets jammed, it can look at its surroundings, reference its (internal and offline) maps, figure out where it is, and navigate.

From the FAQ: "What is SDF"

> While we did initially start out on a single computer in 1987, the

> SDF is now a network of 8 64bit enterprise class servers running

> NetBSD realising a combined processing power of over 21.1 GFLOPS!

Which piqued my interest about how that compares to today's computers. nVidia's venerable 1080Ti from 2017 measures about 11300 GFLOPS, or 11.3 teraFLOPS. About a fifty times increase.

Yeah I read further down in the comments that Aeon and Kalpa have actually diverged quite a bit, the installer might be one of those divergences. How are you liking Kalpa?

The main benefit of sleeping to RAM is of course the resume speed, which makes it more suitable for when you just left your computer inactive for 15 minutes. That goes double if you use encryption without TPM unlocking.

For leaving your computer overnight, hibernate wins on all fronts. I'm enthusiastic about sleep-then-hibernate schemes, but haven't gotten them to work on my devices yet.

Been running Aeon, the Gnome version of Kalpa, on my personal laptop for about six months now. I came from Tumbleweed so the learning curve wasn't steep. Overall the experience has been good!

The one major issue I had from the start was non-free Bluetooth codecs like AptX. That required me to taint the base image and add a non-official repo. It was messy but that was mostly down to it being a learning process, if I had to do it again I could probably do it with a single run of `transactional-update shell`.

The installer is super minimal and surprisingly user-friendly. One thing I remember is that there was zero partitioning choice: just use the full disk for encrypted btrfs and you get no swap (but zram swap is on by default). If you use OpenSUSE with secure boot enabled (as intended) then hibernate is prevented by `kernel_lockdown` anyway.

Snapper by default is nice, but you also get that with Tumbleweed. I ran into no applications that I couldn't get from Flatpaks or export from a distrobox, the latter being mostly for obscure stuff I need to compile myself. And my main toolbox hosts my Emacs environment that I spend most of my time in besides Firefox.

It's hard to recommend a MicroOS desktop over Tumbleweed, the latter being a great all-purpose distro as it is. But I'm hoping the benefits of forcing this "rootless" paradigm on myself will appear when it's time to move to a new machine. Just copy over my home directory and distroboxes and I'm golden, I could even switch to ARM without hesitation.

The distroboxes help with migrating because if I want to compile a newer version of that obscure program from earlier, I don't have to hunt down all the arcane requirements again. They're all still there waiting for me, in a Fedora/Ubuntu/Arch/whatever distrobox, depending on what works best for that program. At least that's the theory.

Happy to answer questions.

Wow, it feels like this argument rewired my brain.

When I first read about the chardet situation, I was conflicted but largely sided on the legal permissibility side of things. Uncomfortably I couldn't really fault the vibers; I guess I'm just liberal at heart.

The argument from the commons has really invoked my belief in the inherent morality of a public good. Something being "impermissible" sounds bad until you realize that otherwise the arrow of public knowledge suddenly points backwards.

Seeing this example play out in real life has had retroactive effects on my previously BSD-aligned brain. Even though the argument itself may have been presented before, I now understand the morals that a GPL license text underpins better.

Yes, the entire point is that requiring Google's permission to sideload anything is very bad.

The linked post by F-droid additionally points out that even that very bad case is not certain. We shouldn't trust that Google will even allow sideloading at all based on their words on their own blog.

Media has a responsibility to report that there is no evidence that Google will even allow anyone to sideload at this point.

Just wanting to say thanks to the whole team for creating such an inspiring and useful creative tool!

I'm most excited to try the perceptual analizer, which was something I found always had disappointing performance in plugins.

Which of the new features would you say posed the most interesting engineering challenge?

No need to be rude. The person above is adding a new insight to the conversation.

Vertical integration makes it possible but motivation makes it happen. Where is Samsung's ultra LTS Exynos device?

Good point, considering the nature of floppies I suppose it technically mustn't have been immutable. But I feel like it would have been wise to mount your OS root read-only to prevent yourself from accidentally ruining your (possibly only) copy of your OS. At least before you had a reasonably sized hard drive.

> I'm surprised that, having something immutable, you'd choose to go the other direction.

I can somewhat imagine that having been limited by space and having to swap out disks all the time one would jump on the train of mutability without fully appreciating the benefits of immutability.

I've only used modern immutable Linux (Alpine, MicroOS) and wondered why of all places `/var/` was chosen as the location for rw stuff. It's fun to be reminded that there was of course a time when an immutable OS was the default, and you ran it off of floppies. So there's a lot of history to using `/var/` for that. Guess we've come full circle!

> But what actually being banned is accounts, not access.

Is this implied, or is this detailed in the law? I can see why this would make sense. So many businesses just have a link to their facebook page as their business website, which you should still be able to view. And presuming platforms like YouTube fit the definition, banning kids from watching anything on there would be pretty rough.

> One might argue that this removes the algorithmic feeds. But I would wager that social media companies will just use browser fingerprinting to continue to serve algorithmic content to logged out users, if they aren't doing this already.

On the subject of YouTube, I wonder if they would allow for the creation of teen accounts, which restrict all social media functions but allow subscriptions. But would that then also remove algorithmic recommendations? What about data harvesting off those accounts? If so, I might have to look up how to get a teenage fake ID.