IRCv3 has extended IRC quite a bit over the past decade, fixing a lot of minor pain points if clients support the fixed versions of the protocol.

Given that the UUID changed, you almost certainly made a new LUKS container, overwriting the old one. That’s bad, because the LUKS header is the only source of the actual encryption key that was used, and making a new one will overwrite both the main header as well as its backup copy immediately. Your password/keyfile/whatever is merely used to decrypt the part of the header that has the actual encryption key, and that’s gone in that case.

Unless you have access to a header backup from before that, there’s a fairly strong chance it’s irrecoverable. I’d suggest going through any archives you might have to see if you have such a backup - most of the instructions on the Gentoo wiki encourage making one, so you might have made one through the power of copying & pasting instructions. Should be a file of around 16MB.

The KeePassXC people are also volunteers and dealing with the fallout of this decision.

Some people are opposed to sudo being a fairly complex program with an awkward to understand configuration language and a couple of methods that can fetch config from elsewhere. Fixing upstream sudo can’t happen because those features exist and are presumably used by some subset of people, so straight up removing them is not good, but luckily doas and sudo-rs exist as alternatives with a somewhat stripped featureset and less footguns.

Others are opposed to the concept of SUID. Underneath all the SUID stuff lies far more complexity than is obvious at first sight. There’s a pretty decent chunk of code in glibc’s libdl that will treat all kinds of environment variables differently based on whether an executable is SUID, and when that goes wrong, it’s reported as a glibc bug (last year’s glibc CVE-2023-4911 was this). And that gets all the more weird when fancy Linux features like namespaces get involved.

Removing SUID requires an entirely different implementation and the service manager is the logical place for that. That’s not just Lennart’s idea; s6, as minimal and straight to the point as it tends to be, also implements s6-sudo{,d,c}. It’s a bit more awkward to use but is a perfectly “Unix philosophy” style implementation of this very same idea.

SO already was. Not even harvested as much as handed to them. Periodic data dumps and a general forced commitment to open information were a big part of the reason they won out over other sites that used to compete with them. SO most likely wouldn’t have existed if Experts Exchange didn’t paywall their entire site.

As with everything else, AI companies believe their training data operates under fair use, so they will discard the CC-SA-4.0 license requirements regardless of whether this deal exists. (And if a court ever finds it’s not fair use, they are so many layers of fucked that this situation won’t even register.)

View -> User Interface, change to Tabbed or Tabbed Compact (or Notebookbar in old versions).

This is a fork of the evaluator/language implementation/daemon/builder/whatever you want to call it. The other one (Auxolotl) is a fork of Nixpkgs, the repository of build scripts and all the NixOS misc pieces.

Or put into other terms, this is a fork of APT/RPM as well as their associated builder tools, while Aux is a fork of Debian/Fedora/whatever. The Nix evaluator is a much more complex piece of software than most other package managers so it does benefit from having a dedicated team working on it.

Lemmy (and Kbin for that matter) very much do the same thing for posts. I don’t think they fetch URL previews for links in comments, but that doesn’t matter: posts and comments are both fairly likely to end up spreading to Mastodon/etc anyway, so even comments will trigger this cascade.

Direct example: If you go to mastodon.social, stick @fediverse@lemmy.world in the search box at the topleft and click for the profile, you can end up browsing a large Mastodon server’s view of this community, and your very link has a preview. (Unfortunately, links to federated communities just result in a redirect, so you have to navigate through Mastodon’s UI.)

Looking at the implementation, it doesn’t really implement sudoers or tools like sudoedit in any way. systemd-run has already been an existing tool for quite some time and this is really just a different CLI for it. That tool asks systemd to make a temporary new service and immediately run it. That, in turn, requires blanket yes/no approval for org.freedesktop.systemd1.manage-units via polkit.

So with run0, you can either do everything or you can do nothing. In-betweens are just not a thing at the moment. There’s very little new backend code running as root.

run0 bash should behave very similar to something like systemd-run --uid=0 --gid=0 --wait --same-dir --send-sighup --pty --pipe --collect bash and the majority of those options have been available for quite a while.

The point of this is to implement some form of privilege escalation without the SUID mechanism. sudo, pkexec and doas are all SUID.

It’s not what the buttons look like, it’s what they do. In Krita, making an ellipse involves clicking the ellipse button and dragging it somewhere. You now have an ellipse, and you hold shift if you want to make it a circle instead.

In GIMP there is no direct ellipse tool, there’s only an ellipse select tool, likewise you hold shift to make it a circle. Then you use a menu item to select the border of your selection, getting a popup to let you determine how much pixels you want. And then, you use the fill tool or fill menu item to fill it. That’s a surprising amount of clicks to accomplish what’s most likely the single most common task for anyone opening a screenshot in an image editor. I’m not aware of any easier/faster method to do it. Feels like it should exist, but this is also what you get if you search for how to draw a circle in GIMP, so if it exists everyone’s missing it.

GIMP’s method gives you more power, but you rarely ever need that power. But when you do, Krita also has ellipse select, border select and various fill tools that can be strung together in the same way.

I think they’ll give it a genuine shot. These stalking services pop up like weeds and every time it gets some media attention they end up with significant problems not much later. dis.cool was the last well-known entry but there’s been more.

My casual-browsing-only netbook is currently running on a RAID0 setup between the internal eMMC and the microSD card because I think it’s funnier that way. Nothing useful’s stored on there and it’s one nixos-rebuild away from being reinstalled so I don’t mind the inevitable breakage.

sudo mv /etc/default/grub /root/old_etcdefaultgrub to get it out of the way, then sudo dnf reinstall /etc/default/grub to reinstall the package that provides it, giving you a fresh unmodified copy. Should work for practically any config file on Fedora.

Storj is blockchain stuff with the storage and bandwidth provided by individual node operators. They’ve kinda tried to bury the whole blockchain stuff and generally keep it removed from their main signup/pricing/usage flow; customers pay in USD and never have to see any of it. But it’s still there in the background and it’s still the main reward system for node operators.

There’s some clickwrapped T&Cs for operators that set some minimum requirements, they’ve made sure one node leaving doesn’t cause data loss, but I’d still be very wary of using them for anything irreplaceable. It only takes one crypto crash or the like for the whole thing to die out, and while they might end up suing some guys running an old NAS out of their garage, that’s not gonna get your data back.

This is a shot in the dark, but since the permissions look fine to me, the only other thing that comes to mind is that the SELinux contexts might not have been copied. Fedora is one of the few distros that enables SELinux in enforcing mode right out of the box. That can be very complex to understand if it breaks.

There is a Fedora documentation page about SELinux. The /var/log/audit/audit.log log file should be full of errors relating to your /home if it broke. I believe that stat /home and stat /new_home should display the SELinux context if SELinux is active, and they should be identical.

Also possible I’m totally off the mark, though, it’s just a possibility.

For the port thing, you can set the net.ipv4.ip_unprivileged_port_start sysctl to a lower value like 80 (may need to go lower if you also do email). It also applies to IPv6.

The default of 1024 is for security, but the actual security granted by it is not really that relevant nowadays. It stems from a time where ports < 1024 were used by machines to trust other machines using stuff like rsh & telnet, and before we considered man-in-the-middle attacks to be practical and relevant. Around the start of this millennium, we learned better. Nowadays we use SSH and everything is encrypted & authenticated.

The only particularly relevant risk is that if you lower it enough to also include SSH’s default port 22, some rogue process at startup might make a fake SSH server. That would come along with the scary version of the “host key changed” banner so the risk is not that high. Not very relevant if you’re following proper SSH security practices.

Note: The HTTP/3 QUIC module is not enabled by default and is considered experimental

Do note that despite not being enabled by default, it is enabled in the official binary packages.

There’s a funny amount of layers to this thing but as far as I’m concerned, if it’s a feature you ship in the default binary packages on your site, that is definitively enough for a CVE even if it’s disabled by default.

This is also going to affect Linux distros, many are moving to x86-64-v2 or even v3. That comes with the same requirements this Win11 build is going to enforce.

There’s plenty of life left in some of the later hardware not on the official Win11 support list, but hardware old enough to be excluded by this build is really overdue for retirement and/or being considered retrocomputing.

Technically always has, ROCm comes with a “backported” amdgpu module and that’s the one they supposedly test/officially validate with. It mostly exists for the ancient kernels shipped with old long-time support distros.

Of course, ROCM being ROCM, nobody is running an officially supported configuration anyway and the thing is never going to work to an suitably acceptable level. This won’t change that, since it’s still built on top of it.