When I’m driving, it’s actually unsafe for my car to be operated in that way. It’s hard to generalize and say, buttons are always easy and good, and touchscreens are difficult and bad, or vice versa. Buttons tend to offer you a really limited range of possibilities in terms of what you can do. Maybe that simplicity of limiting our field of choices offers more safety in certain situations.

Or maybe being able to consistently and reliably operate the thing without taking your eyes off the road has something to do with it? Hmm… Yes, this is really hard to generalize.

AFAIK, RetroArch is just a front-end for the emulators that actually use the controller, so getting this to work depends on the emulator you’ll be using.

I would expect any decent emulator on Linux to work with the standard Linux joystick and/or evdev APIs, which are supported by the Linux DualShock 4 driver. This driver is built in to the Linux kernel; nothing more should require installation. However:

It’s possible that your distro might not load that driver automatically. To check, connect the DS4, power it up with the Playstation button (if its light isn’t already on), and run lsmod |grep -E 'hid_sony|hid_playstation' in a terminal. If it responds with some lines containing hid_sony or hid_playstation, then the driver is loaded.

It’s possible that your distro might not have labeled the DS4 as a joystick device in udev, which isn’t strictly required, but some software expects to see. On the distros I’ve used, the easiest way to get this done is to install the steam-devices package. I think most desktop distros do it automatically these days, though.

You don’t want DS4Windows. That’s Windows software. There is a program (not a driver) called ds4linux, which creates a virtual Xbox controller alongside the real DS4, similar to what Steam Input does when you use it. You shouldn’t need this for games/emulators that were written properly for Linux, but it’s there for cases when a developer took a shortcut and assumed Microsoft game hardware is standard on our non-Microsoft OS. Alternatively, I think you can use Steam Input when launching non-Steam games in Steam.

There are various joystick test programs for linux, to give you an idea of whether the OS sees the controller. (This can be helpful when a game doesn’t appear to see it, to determine if it’s the game’s problem or a connection/driver problem.) KDE Plasma has one built in to the System Settings. There’s a also generic one called jstest-gtk, available with most desktop distros. There are probably more out there.

Keep in mind that test programs like that don’t necessarily know which inputs map to which buttons/sticks on the controller. Don’t panic if they look mixed up in a test program; try it in a game first. If they’re still mixed up, look for a way to remap the inputs.

Cloudflare has a long track record of not abusing that position, though.

Well, Cloudflare is not all that old, and we can’t see what they do with our data, so I would say it has a medium-length record of not getting caught abusing that position. But that’s not the point.

The point is that most Lemmy users’ actual browsing is in fact not private between them and their server. Many instances have a big network service corporation like Cloudflare watching everything read or written by every user, so that info is available to anyone with sufficient access or influence there, like employees and governments.

That applies to most of the internet,

Not exactly, but it does apply to a great many of the biggest web sites, so we could say it applies to much of the internet’s traffic.

And that’s part of the problem. Cloudflare is in a position to watch much of what people do on the web, across many unrelated sites and services (often including domain name lookups), and trivially identify them. This includes whatever political, religious, or NSFW posts they’re reading on Lemmy, and who they are when they log in to their bank accounts.

In any case, I replied not to be pedantic, but just to let our community know that they shouldn’t assume their reading habits on Lemmy are safely anonymized behind a made-up username, or confidential between them and their instance admins. If your instance uses a provider of DDOS protection or HTTPS acceleration, as many big instances do, then the walls have ears.

Your actual browsing of lemmy is moderately private, provided you trust your server.

Not exactly. Many of the big instances have Cloudflare (or similar) sitting between you and the server, providing the HTTPS layer while watching everything you read and write on Lemmy. In cryptography circles, we call this a man-in-the-middle.

Your instance (sh.itjust.works) is one such instance, by the way, as is lemmy.world.

A quick search for the mentioned product names found their safety data sheets:

https://www.crcindustries.com/media/msdsen/msds_en-1003333.pdf

https://www.tmkpackers.co.nz/wp-content/uploads/FUELITE-TMK-SDS-ISSUE-6.pdf

This comment from PaulG.x caught my eye:

Electronics technician with 48 years in the industry here.

The common cause of the buttons losing sensitivity is that the silicone absorbs skin oils and these oils act as insulation on the pads and tracks.

If you look at the tracks under the pads that are least sensitive , you will see the oily residue. You can clean the tracks and pads with alcohol for a short term fix but the pads will exude more of the oil that is within the silicone.

A longer term fix is to soak the whole key pad sheet in Fuelite (Petroleum Spirit) Fuelite is the main ingredient in CRC Contact Cleaner (in fact it is the only ingredient). Use liquid Fuelite to do this , not Contact Cleaner because you have to immerse the silicone sheet.

Soak the sheet for 5 minutes , it will swell a little , let it dry thoroughly and it will return to normal dimension.

While the silicone has still some absorbed Fuelite in it , it will be easily torn so treat it carefully.

Then reassemble the device.

This fix should last several months depending on the state of the silicone sheet

It’s important to post these things every so often. There will never be a day when everyone already knows. :)

https://xkcd.com/1053/

Good luck. :)

The existing distro Neon has issues generally because of their choice to use Ubuntu LTS as a base. This is because KDE Plasma needs newer libraries usually than Ubuntu LTS can provide

In other words, they don’t have enough resources dedicated to doing it well. This is part of the problem I described.

Basing it on Arch means they’ll almost always have the latest libraries ready to go.

That could reduce the work required in one area, but would increase it in another. Arch fails the “doesn’t break” goal on its own, which means someone would have to do more work if they want to achieve it.

Beware online “filter bubbles” (2011) - Eli Pariser

https://www.ted.com/talks/eli_pariser_beware_online_filter_bubbles

Don’t assume too much from the headline, folks. They’re not saying everything has to be rewritten by 2026. They’re saying new product lines serving critical infrastructure should be written in memory-safe languages, and existing ones should have a memory safety roadmap.

If you’re about to post about how you think that’s unreasonable, I think you should explain why.

I think dropping loadable module support would severely limit what users can do when a driver misbehaves or doesn’t handle a particular device as well as an (in-tree) alternative.

Also, I wonder how they expect to achieve being “The KDE operating system” or “doesn’t break” when their existing distro has been more than a little rocky so far. Who do they think will do the long-term work of raising and maintaining the quality bar?

It would be kool to have a solid reference distro where Plasma could shine, especially for organisations and newer users who don’t know how to replace GNOME on existing distros. But this proposal gives me the impression that they underestimate the effort required, so I am skeptical.

You could always test the waters by writing up a few of your workarounds in Lemmy posts, and seeing how much interaction they draw. If they’re well-received, the effort of building and maintaining a blog might be worthwhile.

You are correct. Traditional X middle-button behavior is to insert the primary selection, from any application. It is distinct from the cilpboard(s), has no “copy” step, and doesn’t behave the same as “paste” (it can’t paste over another primary selection).

Many people don’t notice the difference, though, especially if they’re used to an environment that lacks that functionality, like Windows. Some might even get confused or frustrated when the middle click doesn’t work quite as they expect (which, of course, is because it’s actually doing something different).

https://www.jwz.org/doc/x-cut-and-paste.html

It’s also possible that OP remapped their middle button to paste from the clipboard, although their phrasing makes it seem unlikely.

You can’t know with certainty on Signal that the client and the server are actually keeping your messages encrypted at rest, you have to trust them.

This is untrue. By design, messages are never decrypted on servers when end-to-end encryption is in use. They would have to break the encryption first, because they don’t have the keys.

Some advantages are listed in this /c/Technology comment:

https://lemmy.sdf.org/comment/15398090

Debian is also chill. There’s always unstable (can’t remember the current name. Debian Trixie?) For something that’s more up to date

Debian Unstable’s code name is always Sid. Debian Testing’s code name is always the one that will become the next Debian Stable release, currently Trixie.

Room membership and various other room state events are not currently end-to-end encrypted, which means a nosy admin on a participating homeserver could peek at them. (They’re still not visible on the wire, though, nor on homeservers whose users haven’t been invited.)

I don’t know if Signal is actually much better here, since I haven’t looked at their protocol. They hyped their Sealed Sender feature as a solution to some of this, but it can’t really protect from nosy server admins who are able to alter the code, and they fundamentally cannot hide network-level meta-data like who is talking with whom. There’s a brief and pretty accessible description of why in the video accompanying this paper.

I don’t have a list of Matrix events that remain unencrypted in encrypted rooms. You could read the spec to find them if you’re motivated enough to slog through it, but be warned that network protocol specs tend to be long and boring. :) Unfortunately, the few easy-to-digest blog posts about it that I’ve encountered have been both alarmist and inaccurate on important points (one widely circulated one was so bad that the author even retracted it), so not very useful for getting an objective view of the issue.

However, the maintainers have publicly acknowledged the issue as something they want to fix, both in online forums and in bug reports like this one:

https://github.com/element-hq/element-meta/issues/1214

It looks a lot like the “3rd-party EULA” label that appears in the sidebar for some games, below connectivity and controller support. Nice. This ought to make it easier to see if a game meets my basic requirements, and respond quickly when a friend suggests one.

Could someone smarter than me explain Matrix to me?

I wouldn’t assume that I’m smarter, but I do have more than a little experience here, so I’ll try to answer your questions. :)

It’s a real-time messaging platform. The most common use for it is text chat, both in groups (like Discord or IRC) and person-to-person (like mobile phone text/SMS). It supports other uses as well, like voice chat, video conference, and screen sharing, although much of that is newer and gradually showing up in clients.

What would be the utility for someone, who cares about privacy and currently uses Signal and email for communication?

Compared to Signal:

• Matrix doesn’t require a phone number, or even an email address (although some public homeservers want an email address these days, as a recovery method in case you forget your password).
• Matrix has a variety of clients, so it’s more likely that an app fitting your needs exists.
• Matrix clients typically don’t require Google services at all; neither to get the software nor to receive notifications.
• Matrix cannot be monitored at any single location, so it’s more resistant to meta-data tracking at the network level.
• Matrix cannot be shut down by any single organization, so it’s more resistant to censorship and denial-of-service attacks. If a homeserver is ever forced offline, only the accounts on that homeserver go away; all your other contacts remain intact. Same thing if a service operator changes its policies or goes out of business.
• Matrix (last time I checked) had better support for using multiple devices on the same account. Phone, laptop, and office computer, for example.
• Matrix homeservers can be self-hosted by anyone, and still participate in the global network.
• Signal’s encryption covers more meta-data at the application level than Matrix currently does. This might be important if you’re a whistleblower or journalist whose safety depends on hiding your contacts from well-positioned adversaries.

Compared to email:

• Matrix has end-to-end encryption, with forward secrecy, built in. It’s generally better for privacy than bolting PGP onto email, and it’s far easier.
• Matrix is well suited to instant messaging.
• Matrix supports features that people have come to expect from modern chat platforms, like reaction emoji and editing after sending.
• Email has a greater variety of servers and clients.
• Email apps often have more composition features to support long-form writing.

What advantage would it give me over other services?

We already covered Signal, and there are too many other services to compare every difference in all of them, but here are some more common advantages:

• Matrix is a completely open protocol, developed through a public and open process, with open-source servers and client apps. This is important to people who care about privacy because it can be scrutinized by anyone to verify that it operates as it claims to, and can be improved by anyone with a good idea and motivation to participate. It’s important to people who care about longevity because nobody can take it away.
• Matrix has multiple clients for every major platform: desktop, mobile, and web.
• Matrix handles groups of practically any size (including just one or two people).
• Matrix messages are delivered even when you’re offline.

Is Matrix anything good already, or is it something with potential that’s still fully in development?

Until recently: Ever since cross-signing and encryption-by-default arrived a couple years ago, it has been somewhere between “still rough” and “pretty good”, depending on one’s needs and habits. I have been using it with friends and small groups for about five years, and although encrypted chats have sometimes been temperamental, they have worked pretty well most of the time. When frustrating glitches have turned up, we sorted them out and continued to use it. This has been worthwhile because Matrix offers a combination of features that is important to us and doesn’t exist anywhere else. I haven’t recommended it to extended family members yet, because not everyone cares as much about privacy or has the patience for troubleshooting in order to get it. However…

Recently: The frequency of glitches has dropped dramatically. Most of the encryption errors have disappeared, and the remaining ones look likely to be solved by the “Invisible Encryption” measures in Matrix 2.0. Likewise with things like sign-in lag and client set-up.

If you’re considering whether it’s time to try it, I suggest waiting until Matrix 2.0 features are formally released in the clients and servers you want to use, which should be very soon for the official ones. I wouldn’t be surprised if I could confidently recommend it to family members in the coming year.

How tech savvy does one need to be to use Matrix?

If you just want to chat, not very. Even one or two of my friends who can barely use email got up and running pretty quickly with a little guidance. Someone who can get started using Lemmy by themselves can probably handle it on their own.

If you want to host your own server, moderately tech savvy.