Nothing hotter than a giant electric fleshlight whirring away as you get off.

I saw one in a sex shop, it looks like such a chore to get going and clean up afterwards. It's fucking huge too. Hands are so much easier to clean, and readily available anywhere anytime.

I route through my server or my home router when using public WiFi and stuff. I don't care too much about the privacy aspect, my real identity is attached to my server and domain anyway. I even have rDNS configured, there's no hiding who the IP belongs to.

That said, server providers are much less likely to analyze your traffic because that'd be a big no-no for a lot of companies using those servers. And of course any given request may actually be from any of Lemmy, Mastodon, IRC bots or Matrix, so pings to weird sites can result entirely from someone posting that link somewhere.

And it does have the advantage that if you try to DDoS that IP you'll be very unsuccessful.

I can definitely see the improvement, even just between my desktop monitor (27in 1440p) and the same resolution at 16 inch on my laptop. Text is very nice and sharp. I'm definitely looking at 4K or even 5K next monitor upgrade cycke.

But the improvement is far from how much of an upgrade 480p to 1080p and moving away from CRTs to flat screens. 1080p was a huge thing when I was in highschool as CRT TVs were being phased out in favor of those new TVs.

For media I think 1080p is good enough. I've never gone "shit, I only downloaded the 1080p version". I like 4K when I can have it like on YouTube and Netflix, but 1080p is still a quite respectable resolution otherwise. The main reason to go higher resolutions for me is text. I'm happy with FSR to upscale the games from 1080p to 1440p for slightly better FPS.

HDR is interesting and might be what convinces people to upgrade from 1080p. On a good TV it feels like more of an upgrade than 4K does.

Crashes on LineageOS 21 as well.

If you dig deeper into systemd, it's not all that far off the Unix philosophy either. Some people seem to think the entirety of systemd runs as PID1, but it really only spawns and tracks processes. Most systemd components are separate processes that focus on their own thing, like journald and log management. It's kinda nice that they all work very similarly, it makes for a nice clean integrated experience.

Because it all lives in one repo doesn't mean it makes one big fat binary that runs as PID1 and does everything.

Some executables are special. When you run them, they automagically run as root instead! But if sudo isn't very, very careful, you can trick it into letting you run things as root that you shouldn't be able to.

Run0 DM's systemd asking it to go fork a process as root for you, and serves as the middleman between you and the other process.

I haven't had D-Bus problems in quite a while but actually run0 should help with some of those issues. Like, systemctl --user will actually work when used with run0, or at least systemd-run can.

Haven't used it yet so it's all theoretical, but it makes sense to me especially at work. I've used systemd-run to run processes in very precise contexts, it's worth using even if just to smush together schedtool, numactl, nice, taskset and sudo in one command and one syntax. Anything a systemd unit can do, systemd-run and run0 can do as well.

I'm definitely going to keep su around just in case because I will break it the same I've broken sudo a few times, but I might give it a shot and see if it's any good just for funsies.

Just trying to explain what it does and what it can do as accurately as possible, because out of context "systemd adds sudo clone" people immediately jump to conclusions. It might not be the best idea in the end but it's also worth exploring.

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.

I've actually ran into some of those problems. If you run sudo su --login someuser, it's still part of your user's process group and session. With run0 that would actually give you a shell equivalent to as if you logged in locally, and manage user units, all the PAM modules.

systemd-run can do a lot of stuff, basically anything you can possibly do in a systemd unit, which is basically every property you can set on a process. Processor affinity, memory limits, cgroups, capabilities, NUMA node binding, namespaces, everything.

I'm not sure I would adopt run0 as my goto since if D-Bus is hosed you're really locked out and stuck. But it's got its uses, and it's just a symlink, it's basically free so its existence is kBs of bloat at most. There's always good ol su when you're really stuck.

The same is on the way in the US with how hard conservatives are fighting to keep graduates dumb and educated. Educated people don't lean towards wars.

Yeah, even Asahi has better OpenGL support than real macOS. They make damn sure you have to use Metal to get the most out of it, just like eventually you get caught up in DirectX on Windows whether you want it or not. You can use Vulkan and OpenGL, but the OS really wants to work with Metal/DirectX buffers in the end.

I appreciate that the devs care enough to make it really good from the start, because that sets the benchmark. Now the Linux version has to have a similar enough polish to it.

In comparison, Atom and VSCode both worked fine on Linux just about day one thanks to Electron, but it was also widely disliked for the poor performance. It's a part of what Zed competes on, performance compared to VSCode.

Yeah if it was brand new, it might also have been defective, I've seen that happen. It's just between jailbreak and manufacturing defect, which do we default to? Depends on the whole timeline really.

It's not impossible it broke it, but anyway the Pixel is made for that so it's a lot less sketchy to begin with. It's the same risk as installing an OS on a PC really.

Google releases betas and developer previews for the Pixel, it's made to survive buggy code.

I just replied to that in a dedicated comment. But for your Pixel it's even better because it's something that Google even officially endorses, it doesn't even void your warranty.

I've been modding phones since the Android 2.2 days, and I've never had any major issues or anything that would make me want to go back to stock, and never had issues going back to stock. Even my S7 with a modded bootloader splash screen, it was gone when I flashed stock back on it.

As for the iPhone 3G, I think it was just software and an aging device. My iPod definitely got pretty laggy with multiple apps open on a device with 128MB of RAM in an OS that doesn't even support running apps in the background. The more mods and plugins loaded the laggier naturally.

But even with a jailbreak, they didn't mod drivers or anything that would make it different from a hardware perspective. They just sideload a store that can then install any apps. You can install bad apps but nothing that would survive a restore in iTunes.

What could have happened is she got an iOS update after the restore that also was a bit laggier and energy intensive. Or maybe the faster discharge and higher energy consumption is what finished an already aging battery. It's very unlikely the jailbreak caused it, more likely triggered it or expedited an existing problem. Like formatting your mom's PC whose hard drive is on death's bed and the IO of reinstalling an OS makes it kick the bucket. Is it the OS's fault? No. But did installing the OS cause the fault? Yes. People will still blame the OS, especially if it's a different OS in case of a jailbreak or putting Linux on your mom's laptop that's still on XP or 7. The new thing, it broke the thing!

Pixel phones are basically the gold standard of Android phones for flashing custom ROMs. Google doesn't lock anything down and provide everything necessary to not only build your own, but it even fully supports relocking the bootloader with your own keys and all the secure boot security features.

In most cases I think Google has an online tool you can run right from the browser to fully reflash the stock OS on it.

The only thing that won't work is apps using Play Integrity which some bank apps and streaming apps use for DRM, including Google Pay/Wallet. There's not much you can do about it especially in the longer term, as this is hardware-backed so unless some major exploit gets dropped, you can't really fake the phone being stock to apps. Reverting to stock should bring back full functionality.

You really have to go out of your way to brick a Pixel and mess with overclocking to do permanent hardware damage.

Have fun!

Matrix is for chatting, not posts.

When it goes well you get live, interactive support and get your question answered fairly quickly. Nice and convenient. But as you've said already, it has drawbacks and it's where forums and things like Lemmy come in, where sometimes you can get replies days later.

They're different systems that reach different audiences. You use whichever based on the needs and complexity. What sucks is when the chat rooms develop some knowledge that doesn't get known outside and it's also not indexed anywhere on the web. Some things are better discussed in forum format (or mailing lists if you're very oldschool), while others are just better interactively and the back and forth on a public forum would just be painful.

Usually there's a bit of an overlap at least, where users are usually in Discord/Matrix/IRC and some forum or reddit or fediverse community at the same time.

Adding routes for other thing on the network the clients can reach directly and remove some load from the router. For example, reaching another office location through a tunnel, you can add a route to 10.2.0.0/16 via 10.1.0.4 and the clients will direct the traffic directly at the appropriate gateway.

Arguably one should design the network such that this is not necessary but it's useful.

The attack vector here seems to be public WiFi like coffee shops, airports, hotels and whatnot. The places you kinda do want to use a VPN.

On those, if they're not configured well such as coffee shops using consumer grade WiFi routers, an attacker on the same WiFi can respond to the DHCP request faster than the router or do an ARP spoof attack. The attacker can proxy the DHCP request to make sure you get a valid IP but add extra routes on top.

Most VPN providers don't use DHCP. OpenVPN emulates and hooks DHCP requests client-side to hand the OS the IP it got over the OpenVPN protocol in a more standard way (unless you use Layer 2 tunnels which VPN providers don't because it's useless for that use case). WireGuard doesn't support DHCP at all and it always comes from configuration.

Some providers have managed to make split tunnelling work fine so those I suspect are not affected because they override the routing at the driver level. It's really only the kinda lame OpenVPN wrappers that would be affected. When you have the custom driver, you can affect the routing. It's been a while since I've tested this stuff on Windows since obviously I haven't been paid to do that for 6 years, but yeah I don't even buy that all providers are affected and that it's unfixable. We had workarounds for that when I joined PIA already so it's probably been a known thing for at least a decade.

The issues we had is sometimes you could get the client to forget to remove the firewall rules or to add back the routes and it would break people's internet entirely. Not great but a good problem to have in context.