I only use a few applications where middle click panning makes sense, and it works fine, middle click paste has no effect. If some applications don’t handle panning properly, that’s a bug in those applications. Why on earth should we disable a useful feature system-wide so a couple buggy applications can get away with shoddy code?
No, middle click paste has nothing to do with middle mouse scroll, or middle click open-in-new-window. They’re independent functions, and all 3 can work together just fine. Disabling middle click paste has absolutely no upside that I can think of. Unless they’re going to replace middle click paste with something more useful, I don’t understand this push.
Disagree. Their priorities are backwards.
Company A releases a product, it runs closed-source proprietary firmware on-board, and it can’t be updated by the user even if bugs or compatibility issues are found later on in the product’s life cycle.
Company B releases a product, it runs closed-source proprietary firmware on-board, but it can be updated by the user if bugs or compatibility issues are found later on in the product’s life cycle.
According to the FSF, product A gets the stamp of approval, product B doesn’t. That makes no sense.
I use node_exporter + VictoriaMetrics + Grafana for network-wide system monitoring. node_exporter also has provisions to include text files placed in a directory you specify, as long as they’re written out in the right format. I use that capability on my systems to include some custom metrics, including CPU and memory usage of the top 5 processes on the system, for exactly this reason.
The resulting file looks like:
# HELP cpu_usage CPU usage for top processes in %
# TYPE cpu_usage gauge
cpu_usage{process="/usr/bin/dockerd",pid="187613"} 1.8
cpu_usage{process="/usr/local/bin/python3",pid="190047"} 1.4
cpu_usage{process="/usr/bin/cadvisor",pid="188999"} 1.0
cpu_usage{process="/opt/mealie/bin/python3",pid="190114"} 0.9
cpu_usage{process="/opt/java/openjdk/bin/java",pid="190080"} 0.9
# HELP mem_usage Memory usage for top processes in %
# TYPE mem_usage gauge
mem_usage{process="/usr/local/bin/python3",pid="190047"} 3.0
mem_usage{process="/usr/bin/Xvfb",pid="196573"} 2.4
mem_usage{process="/usr/bin/Xvfb",pid="193606"} 2.4
mem_usage{process="next-server",pid="194634"} 1.2
mem_usage{process="/opt/mealie/bin/python3",pid="190114"} 1.2
And it gets scraped every 15 seconds for all of my systems. The result looks like this for CPU and memory. Pretty boring most of the time, but it can be very valuable to see what was going on with the active processes in the moments leading up to a problem.
*Raises hand*
I’ve experienced far fewer bugs on KDE 6 than Mint or Cinnamon, and I refuse to use GNOME. What else are you comparing against?
They continued harvesting data from users after the users explicitly disabled an option to shut that off. And for that, they owe $4 a person. When are we going to starting fining these companies properly? How about a thousand dollars a person for an infraction like this? Maybe a $98 billion fine might get them to start caring.
a transactional SMTP provider, which is almost certainly selling all outgoing email contents for AI training at least if not even more nefarious things.
That’s a big assumption, and that kind of behavior is specifically prohibited in the privacy policy of most, if not all SMTP relay providers, as well as GDPR regulations. If you think they’re violating their own privacy policy and government regulations and doing it anyway, there’s no reason to think Proton isn’t as well, or any other email provider, so that’s kind of a non-starter argument IMO. Plus this only applies to outgoing emails, not incoming. I don’t know about you, but I send about 5-10 outgoing emails a year, there’s not much to be gleaned there. Incoming is what you’d want to protect more than anything.
There’s really no viable way to run your own email server with actual delivery anymore
SMTP relays make IP reputation a complete non-issue. As long as you aren’t sending hundreds of emails a day, there are multiple free options (free tier, subsidized by paying corporate customers who send a lot of emails).
I’ll probably just install .1 and have a play then reinstall .2 from fresh and transfer my data.
There’s no need for that. X.1 -> X.2 is a minor upgrade, there’s no reason to wipe and reinstall for it.
All valid points. The compose setup is nasty, and OIDC definitely needs a major overhaul for sure. I’m hoping those are two issues they address in the near future. I can’t speak to the Android app as I use iOS, I don’t have any complains about that version of their app.
I use OpenCloud with Collabora
OliveTin, gives you a clean web UI for pre-defined shell scripts, with a dynamically reloadable YAML configuration.
There are a ton of things you could use it for, but I use it for container and system updates. A pre-processor runs on a schedule and collects a list of all containers and systems on my network that have available updates, and generates the OliveTin YAML config with a button for each. Loading up the OliveTin webUI in a browser and clicking the corresponding button installs the update and cycles the container or reboots the host as needed. It makes it trivially easy to see which systems need updating at a glance, and to apply those updates from any machine on my network with a web browser, including my phone or tablet.
Applications can override the behavior. I have several applications I use on a daily basis that use the middle mouse for panning and they work fine. If other applications don’t, that’s their own fault. Forcing users to disable a useful feature system-wide so a couple lazy applications can get away with buggy code is not a reasonable solution.