Personally, I do think it’s a useful exercise to decide what your red-lines are when it comes to OS level age verification.

For me: Having a field in a database that could contain my DoB is acceptable. Having a prompt to populate it during first time set up is very concerning. Requiring that data to be validated by a third party is the red line.

If you don’t want to be boiled like a frog, bring a thermometer.

The change would be using Gitmail as the plumbing, and normalising the creation of user-friendly porcelain on top.

E.g. suppose there is a repo foo/bar hosted by a forgejo instance at myinstance.org/foo/bar. Sending an email to foo.bar@myinstance.org (or similar) could automatically create a PR and, conversely, opening a PR could send a patch series to the foo/bar mailing list.

To be honest, I’m starting to drink the Sourcehut coolaid here. We have a distributed method of interacting with repositories: Email.

Don’t get me wrong, the current user experience of email-based patches and discussion isn’t great because it’s too easy to send a badly formatted patch. But if we invested time in making email patches easier to use (e.g. sending them through a web ui for people who prefer github style PRs) then we could skip all the architectural pains of solutions like forgefed.

Not sure I like their definition of declarative. I’d instead say that a config is “declarative” if the result of applying that configuration is independent of the current state of the system.

MacOS

I had a go at using guix as a package manager on top of an existing distro (first an immutable fedora, which went terribly, then OpenSUSE). Gave up for a few reasons:

• As mentioned in the article, guix pull is sloow.
• Packages were very out of date, even Emacs. If I understand correctly, 30.1 was only added last month, despite having been available since February. I get that this isn’t the longest wait, but for the piece of software you can expect most guix users to be running, it doesn’t bode well.
• The project I was interested in trying out (Gypsum) had a completely broken manifest. Seems like it worked on the dev’s machine though, which made me concerned about how well guix profiles actually isolate Dev environments. This was probably an error on the dev’s part, but I’d argue such errors should be hard to make by design.

All in all I love the idea of guix, but I think it needs a bigger community behind it. Of course I’m part of the problem by walking away, but 🤷

Keep the files in a dedicated torrents folder then make symlinks to where you actually want them?

Are there any new features in particular you’re hoping for?

For me, those two are the only things I can remember thinking it would be nice to have. Q

The Koru is a 416-foot masterpiece with three towering masts, each standing 230 feet tall, that harness kinetic energy to propel the vessel. The yacht is so massive that, for it to leave the shipyard after completion, a historic bridge in Rotterdam had to be dismantled. Bezos even offered to fund the dismantling and reconstruction of the 95-year-old De Hef bridge but later abandoned the plan amid public outcry. Eventually, Koru was towed away without her masts, which were later assembled.

The tone of this article is astonishing. “He even offered to pay to vandalise a historic building”, how selfless…

I can’t imagine that’s any more free than bitwarden?

Please somebody correct me if I’m wrong, but I really don’t find the “chip makers don’t have to pay licence fees” a compelling argument that RISC-V is good for the consumer. Theres only a few foundries capable of making CPUs, and the desktop market seems incredibly hard to break into.

I imagine it’s likely that the cost of ISA licencing isn’t what’s holding back competition in the CPU space, but rather its a good old fashioned duopoly combined with a generally high cost of entry.

Of course, more options is better IMO, and the Linux community’s focus on FOSS should make hopping architectures much easier than on Windows or MacOS. But I’d be surprised if we see a laptop/desktop CPU based on RISC-V competing with current options anytime soon.

In my experience it Just Works ™️. I spin up a distro/toolbox, compile some software (e.g. Emacs) then run the executable inside the container, and up pops the GUI window.

If you use distrobox, you can even distrobox-export desktop files, at which point a containerised gui application is practically indistinguishable from one installed on the host system

By default, XWayland apps are now allowed to listen for non-alphanumeric keypresses, and shortcuts using modifier keys. This lets any global shortcut features they may have work with no user intervention required, while still not allowing arbitrary listening for alphanumeric keypresses which could potentially be used maliciously

This is… very smart actually. Any reason this is limited to Xwayland? (Is that XDG portal a thing yet?)