They probably fixed all the bugs they considered essential, and the rest is just nice to have fixes that can be moved to the next cycle if necessary (and they still have a week to work on them before release, although they might be careful not to introduce severe bugs now).

The general idea with this approach is that it doesn’t make sense to block a release on a few bugs worked on by only a subset of available developers and having the rest idle - the project can be finished faster by moving the remaining tasks over to the next release and accepting the bugs in the meantime.

Not familiar with the API, and I’m not entirely sure if it’s not just a bug in Eternity (fork of Infinity), but lemmy.one doesn’t have downvotes and I don’t get the option to downvote anywhere.

If you don’t sign into a Google account, you will never arm this mechanism at all.

The comment you replied to is a direct reply to the comment you linked - I don’t think it was intentional, but if it was, then I’d like to say it’s not a very helpful reply as OP already read it.

someone just plain lying about what OS they’re using in order to break fingerprinting.

The idea with avoiding fingerprinting is to look like whatever the biggest group of users looks like, because that’s who you share the fingerprint with. If you use an uncommon value for something, you make fingerprinting easier.

That’s one of the reasons why for example Vivaldi on Linux sets its user agent to match the latest version Chrome on Windows.

That really depends on the technology used. For example, all modern Ethernet standards (which includes both copper and fiber optic) are full duplex, meaning they can provide the full bandwidth in both directions at once. So a gigabit Ethernet link can do a gigabit in one direction AND a gigabit in the other direction at the same time (but not two gigabits in one direction).

In my very limited experience with my 5400rpm SMR WD disk, it’s perfectly capable of writing at over 100 MB/s until its cache runs out, then it pretty much dies until it has time to properly write the data, rinse and repeat.

40 MB/s sustained is weird (but maybe it’s just a different firmware? I think my disk was able to actually sustain 60 MB/s for a few hours when I limited the write speed, 40 could be a conservative setting that doesn’t even slowly fill the cache)

Fair enough. I misunderstood, my bad.

Then what’s the meaning of this whole part?

On non-corpo linux syslog can be disabled if you want, though I’d prefer to just symlink/mount /var/log to a memory filesystem instead.

Is it just a random tidbit that could be replaced with a blueberry muffin recipe without any change of meaning of the whole comment? Because it sure won’t help OP at all with their Arch-specific question, so it’s either that, or it provides contrast to the “corpo Linux”, which is how I interpreted it.

And here’s the remaining part of your comment I left out, just to make sure people won’t lose the context between two three sentence long comments (for those without any attention span, it comes before the previous quoted part):

If you’re on arch you use redhat’s garbage.

On non-corpo linux syslog can be disabled

systemctl disable --now systemd-journald

I’d prefer to just symlink/mount /var/log to a memory filesystem instead

Set Storage=volatile in /etc/systemd/journald.conf

Your mileage may vary - your experience might be different for one reason or another

How is it open source?

How is it not? Open source doesn’t mean you have to accept other people’s code. And it is perfectly valid to only dump code for every release, even some GNU projects (like GCC) used to work that way. Hell, there’s even a book about the two different approaches in open source.

So whatever benefit you were hoping to get from Nvidia’s kernel modules being open source probably is not there.

It allowed the actual in-tree nouveau kernel module to take the code for interacting with the GSP firmware to allow changing GPU clock speed - in other words no more being stuck on the lowest possible frequency like with the GTX 10 series cards. Seems like a pretty decent benefit to me.

What’s Steve?

Probably a bit of a TL:DR of the other answer, but the short answer is: the execute bit has a different meaning for directories - it allows you to keep going down the filesystem tree (open a file or another directory in the directory). The read bit only allows you to see the names of the files in the directory (and maybe some other metadata), but you cannot open them without x bit.

Fun fact, it makes sense to have a directory with --x or -wx permissions - you can access the files inside if you already know their names.

Edit: not a short answer, apparently

xrandr is Xorg only, it doesn’t work with Wayland. You should be able to make SDDM use your Plasma display configuration - https://wiki.archlinux.org/title/SDDM#Match_Plasma_display_configuration

No clue if that’s going to fix your issues, but at least it’s supposed to work with Wayland.

Right, now get a borderline computer-illiterate person to connect to your network, ensure their firewall isn’t misconfigured to block all incoming traffic (with TeamViewer, this configuration would still work because the device just connects to the TV server) and open and set up a completely separate screen sharing program.

I know none of these steps are difficult if you have any idea what you’re doing, but I’ve met plenty of people who would most likely need assistance going through the motions. Funnily enough, the best way to do it remotely would probably be to get them to install TeamViewer to then set this up for them remotely.

By the way, as far as networking goes, Tailscale does the same thing TeamViewer does, just for a VPN instead of a screen sharing application - it will try to do all the NAT punchthrough techniques and IPv6 connection and fall back on tunneling through relay servers if all else fails. It’s not any more of a direct connection than TV.

So I did look more into it, and apparently the open firmware is technically compatible with PCIe cards using this chip, but doesn’t provide any advantages over just wiping the firmware and letting the chip default to its built-in fallback firmware, and so the maintainer doesn’t see any value in explicitly supporting it.

Now the question is whether you consider the proprietary fallback firmware to be acceptable to run - this might sound weird, but for example FSF has explicitly made exceptions for devices with built-in firmware to be able to qualify for the Respects Your Freedom certification, so if your view aligns with theirs, you might consider this to be completely OK. If not, the free firmware appears to have a similar feature set, you’ll just have to jump through more hoops.

Also do note that both the fallback firmware and the free firmware are missing many features of the proprietary firmware, so make sure to check it’s not missing anything you need (wake on LAN, Jumbo frames and PXE boot seem like the most notable missing features to me).

More info on support for various PCIe cards

Convenience (after you install it, all you have to do is enter the code and you’re connected, no other setup required), familiarity (it’s the default name people will think of or find if they want remote access - that alone means they can get away with pushing their users slightly more) and - IMHO most importantly - connectivity: if two computers can connect to the TeamViewer servers, they will be able to connect to each other.

That’s huge in the world of broken Internet where peer to peer networking feels like rocket science - pretty much every consumer device will be sitting behind a NAT, which means “just connecting” is not possible. You can set up port forwarding (either manually or automatically using UPnP, which is its own bag of problems), or you can use IPv6 (which appears to be currently available to roughly 40% users globally; to use it, both sides need to have functional IPv6), or you can try various NAT traversal techniques (which only work with certain kinds of NAT and always require a coordinating server to pull off - this is one of the functions provided by TeamViewer servers). Oh, and if you’re behind CGNAT (a kind of NAT used by internet providers; apparently it’s moderately common), then neither port forwarding or NAT traversal are possible. So if both sides are behind CGNAT and at least one doesn’t have IPv6, establishing a direct link is impossible.

With a relay server (like TeamViewer provides), you don’t have to worry about being unable to connect - it will try to get you a direct link, but if that fails, it will just act as a tunnel and pass the data between both devices.

Sure, you can self host all this, but that takes time and effort to do right. And if your ISP happens to use CGNAT, that means renting a VPS because you can’t host it at home. With TeamViewer, you’re paying for someone else to worry about all that (and pay for the servers that coordinate NAT traversal and relay data, and their internet bandwidth, neither of which is free).

It’s less about the computer and more about the card itself - Talos II and Blackbird both use the BCM5719 chip for their integrated NICs. Basically, you’re flashing part of the motherboard with this firmware. A PCIe card built around the same chip might connect the interfaces in a different way, and firmware doesn’t generally have a way of poking around to find out how everything’s set up from the hardware side of things - it needs to just know this, and that’s why there are separate firmware builds for different hardware.

If you flash one of these files to that card, it might just so happen to work perfectly, but it most likely won’t. You would need to figure out how it’s wired up and modify the firmware with that knowledge. And then you could use the modified open firmware with that specific card model on any computer that supports the proprietary firmware, because IIUC this is meant to be functionally identical.

So in short, no, you cannot currently use this open firmware on any computer other than Talos II and Blackbird, but for slightly different reason than you might think.

Also, the Arch repos are pretty much just an “AUR with binaries” - they contain the same PKGBUILD files used by AUR packages, because that’s how Arch packages are built. So you can just download an Arch package PKGBUILD, modify it however you wish, and then build and install it.