Because humans don't also take inspiration from other's work they've heard and unconsciously repeat part of other songs they've heard before, possibly decades ago. Never happens. Never. Humans don't profit from books they've read and apply to their career. Humans don't profit from watching other humans do the thing and then learn to do it themselves.

All AI does is do the same thing but at ridiculous scale and ridiculous speeds. We shouldn't hold progress because capitalism dictates that we shouldn't put people out of jobs. We need to prepare for the future where there is no jobs and AI replaced all of them.

Ask your admin to turn it off, or if you're the admin, turn it off.

They really went with the worst possible way to implement this in that it mangles the post to rewrite all images to the image proxy, so it's not giving you a choice. So if you want the original link you have to reprocess it to strip the proxy. It's like when they thought it was a good idea to store the data as HTML encoded, so not-web clients had to try to undo all of it and it's lossy. It should be up to the clients to add the proxy as needed and if desired. Never mangle user data for storage, always reprocess it as needed and cache it if the processing is expensive.

Now you edit a post and your links are rewritten to the proxy, and if you save it again, now you proxy to the proxy. Just like when they applied the HTML processing on save, if you edited a post and saved it again it would become double encoded.

Personally I leave it off, and let Tesseract do it instead when it renders the images. It's the right way to do it. If the user wants a fresh copy because it's a dynamic image, they can do so on demand instead of being forced into it. And it actually works retroactively compared to the Lemmy server only doing it for new posts.

And also with the atomic/immutable distros, the switch is practically instant, so it's not even like it forces you to watch a spinning circle for 20 minutes when you turn off your computer. You reboot and the apps all start clean with the right library versions.

It's rare but I've seen software trash itself because the newly spawned process talks a different protocol and it can lead to either crashes or off behavior that leads to a crash eventually. Or it tries to read a file mid update. Kernel updates can make it so when you plug in a USB stick, nothing happens because the driver's gone. Firefox as you mentionned. Chromium will tolerate it mostly but it can get very weird over time.

The risk is non-zero, so when you target end users that don't want to have to troubleshoot, it's safer to just do offline updates. Especially with Flatpaks now, you get those updated online and really it's only system components you don't care to delay updates taking effect

If you're new to Linux and everyone told you you can just update and no reboot, and you run into weird Firefox glitches, it just looks bad.

This tool is great to see when remote instances will attempt to send activity to you and how far behind you are: https://phiresky.github.io/lemmy-federation-state

There's an exponential backoff, so sometimes it can take hours before you start receiving activity again, so it's nice to know when to expect it.

The stability of a distro usually has more to do with API and ABI stability than stability in terms of reliability. And a "stable" system can be unreliable.

That's why RHEL forks are said to be compatible bug for bug. Because you don't know if fixing the bug could have a cascading side effect for somebody's very critical system.

Arch has been nothing but reliable for me. Does it doesn't need fixing sometimes because the config format of some daemon changed, or Python or nodejs got updated and now my project doesn't build? Absolutely not. But for me usually newer versions are better even if it needs some fixing, and I like doing it piecemeal rather than all at once every couple years.

Stable distributions are well loved for servers because you don't want to update 2000 servers and now you're losing millions because your app isn't compatible with the latest Ruby version. You need to be able to reliably install and reinstall the same distro version and the same packages at the same versions over and over. I can't deal with needing a new server up urgently and then get stuck having to fix a bunch of stuff because I got a newer version of something.

I use multiple distros regularly, for different purposes. Although lately Docker has significantly reduced my need for stable distros and lean more on rolling distros as the host.

Make Docker depend on the mount. You can simply use systemctl edit docker.service and then

[Unit]
Requires=path-to-your-smb.mount
After=path-to-your-smb.mount

Then it will guarantee it's mounted by the time Docker starts.

Ah it's a laptop, I thought it was a desktop motherboard. That is strange, on a laptop I wouldn't expect people to have to mess with the BIOS at all to make VR work, that's usually a desktop thing to make sure rebar is enabled and stuff.

They most likely sent you a new board which happens to have an older BIOS on it. I don't think they try to upgrade them at all, they pick a boxed new board from the warehouse and ship it to you. You can probably just upgrade it again, there's no way this one's newer. Also I guess double-check you got the same model of board back, that could also explain the old BIOS.

RMA'd an MSI board for which they released a BIOS update specifically for the bug I encountered which can get the system completely unbootable even with a CMOS reset, and it didn't even come with the updated BIOS either. I imagine they expect it'll eventually get updated through Windows.

Basically, the SUID bit makes a program get the permissions of the owner when executed. If you set /bin/bash as SUID, suddenly every bash shell would be a root shell, kind of. Processes on Linux have a real user ID, an effective user ID, and also a saved user ID that can be used to temporarily drop privileges and gain them back again later.

So tools like sudo and doas use this mechanism to temporarily become root, then run checks to make sure you're allowed to use sudo, then run your command. But that process is still in your user's session and process group, and you're still its real user ID. If anything goes wrong between sudo being root and checking permissions, that can lead to a root shell when you weren't supposed to, and you have a root exploit. Sudo is entirely responsible for cleaning the environment before launching the child process so that it's safe.

Run0/systemd-run acts more like an API client. The client, running as your user, asks systemd to create a process and give you its inputs and outputs, which then creates it on your behalf on a clean process tree completely separate from your user session's process tree and group. The client never ever gets permissions, never has to check for the permissions, it's systemd that does over D-Bus through PolKit which are both isolated and unprivileged services. So there's no dangerous code running anywhere to exploit to gain privileges. And it makes run0 very non-special and boring in the process, it really does practically nothing. Want to make your own in Python? You can, safely and quite easily. Any app can easily integrate sudo functionnality fairly safely, and it'll even trigger the DE's elevated permission prompt, which is a separate process so you can grant sudo access to an app without it being able to know about your password.

Run0 takes care of interpreting what you want to do, D-Bus passes the message around, PolKit adds its stamp of approval to it, systemd takes care of spawning of the process and only the spawning of the process. Every bit does its job in isolation from the others so it's hard to exploit.

Seen similar stuff on TikTok.

That's the big problem with ad marketplaces and automation, the ads are rarely vetted by a human, you can just give them money, upload your ad and they'll happily display it. They rely entirely on users to report them which most people don't do because they're ads and they wont take it down unless it's really bad.

Throwing that kind of stuff at an LLM just doesn't make sense.

People need to understand that LLMs are not smart, they're just really fancy autocompletion. I hate that we call those "AI", there's no intelligence whatsoever in those still. It's machine learning. All it knows is what humans said in its training dataset which is a lot of news, wikipedia and social media. And most of what's available is world war and cold war data.

It's not producing millitary strategies, it's predicting what our world leaders are likely to say and do and what your newspapers would be saying in the provided scenario, most likely heavily based on world war and cold war rethoric. And that, it's quite unfortunately pretty good at it since we seem hell bent on repeating history lately. But the model, it's got zero clues what a military strategy is. All it knows is that a lot of people think nuking the enemy is an easy way towards peace.

Stop using LLMs wrong. They're amazing but they're not fucking magic

This is why I have respect for Valve. They're willing to invest into changing the status quo instead of seeing it as not profitable immediately. They're playing the long game, and they've put their version of Linux into millions of hands. They've built hardware for it, they've invested a ton into Wine/Proton, they've invested in open-source graphics drivers. They're actively fixing up third party games to the point some of them run better on a their handheld than decent Windows PCs. And a good chunk of it is open-source and given away for free to everyone to use.

Meanwhile Sweeney is just there whining that Linux is too hard. They can't even be bothered to try.

I would give money to Valve just so they keep going. I have no desire to buy an Epic game they're not even willing to try to at least make it easier to run in Wine.