she got the idea for the brand while watching the Republican debates, where she noticed audience members drinking water that had “no connection to the people drinking it.”

They could have been drinking the same water as the blue team. Disgusting.

Does it actually tell you the results? I’m curious how they score your driving, and how effective it is. The scariest things I see on the road are things like:

• distracted driving
• tailgating
• lack of awareness

I don’t see how they’d measure how safe a driver you are.

Perhaps it’s just that people are more careful when they know they’re being monitored, and safe drivers are more likely to opt in?

I think most orgs would want to own the server and for messages to not be end-to-end encrypted. All connections to the server would still be encrypted.

That would be more in-line with slack or something.

If you’re referring to federation specifically then that’s going to get pretty complicated with security policies.

It’s a trap.

Sounds like it’s not really a downgrade, but just an unreleased beta or test build? That seems a little less sketchy, and maybe it’ll be generally released at some point.

Something which notifies you whenever a new comment or reply is made to a selected post/comment, so that you can keep track of any new conversation.

Something like this would be awesome as a core Lemmy feature IMO. It would essentially turn a post (or maybe any comment tree?) into a matrix style room. Lemmy is actually decent for long term discussion (e.g. helping someone with a problem), but not if there are more than two people involved.

I’d probably:

1. make sure it can be reliably reproduced using something like systemctl suspend
2. try swapping the cables and see if it still happens on the same screen, or the same port
3. look at journald/dmesg output for the period from suspend to resume

When the screen fails to wake, are you able to get it back by powering it off, or by unplugging it? Is it X or wayland?

These drugs aren’t giving people the calories they need to live, so it sounds like your business depends on making people unhealthy.

I’ve been using orgzly for years and this is the first I’ve heard of revived. Looks promising.

Oh yeah, that was pretty much the point I was trying to make too.

Of course not, but you have to either trust your users to some extent or give them a system that’s locked down to the point of hindering them.

There’s actually not that much autotools jank, really. There’s configure.ac and a few Makefile.am. The CMakeLists.txt in the root is bigger than any of those files.

There’s also some stuff from autotools archive in m4/. IMO that’s a bad practice and we should instead be referencing them as a build dependencies.

I’m not convinced this backdoor would have been significantly more difficult to hide in the cmake code.

What is ‘unallowed software’? A shell script the user wrote? Something they downloaded and compiled?

Limiting that seems fundamentally at odds with FOSS.

Emacs I assume.

cmake compiles to makefiles as well (it just also supports some other backends). I’m not sure why that matters though. In both cases the makefile is generated.

If you stop shipping autotools generated artefacts in your tarballs, things will be a lot simpler.

Weirdly enough the malicious code does look eerily similar to the benign code, because both are unnecessarily obfuscated.

This is not a human written or readable file you’re talking about. It’s a generated script.

As the other user suggested, you probably just need to mount the root subvolume somewhere and run it on that.

Try using btdu. I’m not sure how it works with compression, but it at least understands snapshots, as long as they are named in a sane way.

Yeah, that’s fair. If you want to test that you can still decompress something compressed with some random old version, you either need to keep the old algorithm around, or the data.

Many of the files have been created by hand with a hex editor, thus there is no better “source code” than the files themselves.

I don’t buy that. There would have been some rationale behind the contents that could be automated, like “compressed file with bytes 3-7 in the header zeroed”.

You also probably don’t need these test files to be available in the environment where the library itself is built. There are various ways you could avoid that.

I do agree about the autotools stuff though.

Minor differences in those files are perfectly normal as the contents of them are copied in from the shared autoconf-archive project, but every distro ships a different version of that, so what any given thing looks like will depend on the maintainer’s computer.

This seems avoidable. We shouldn’t be copying code around like that.