unhrpetby @ unhrpetby @sh.itjust.works

Posts

0

Comments

106

Joined

5 mo. ago

...saying what newsom or allred said.

I don't know about allred, but if this is the Gavin Newsom statement you're referring to:

I think it’s an issue of fairness, I completely agree with you on that. It is an issue of fairness — it’s deeply unfair...

Then I don't understand how it goes from that to:

...cheering on as trans people are murdered in camps...

5. Remote didn't work as well for the company.
6. Remote didn't work as well for any number of people at that company.

3. Tradition.
4. Belief that work-from-home is less efficient.

...that proved that the algorithms/protocols work.

You can use a perfect algorithm and still be insecure because the implementation was bad. You are trusting the SimpleX Chat devs to a degree.

I wouldn't trust encryption made by anti-vaxer more than...

Important to note: SimpleX Chat has gone through two security audits.

The SimpleX Chat is AGPL. If the founder is problematic, one can fork it and avoid reinventing what has already been made.

It is forkable if necessary. I do think SimpleX is a great piece of software that shouldn't be reinvented because of the founder.

There was this recent attack to XZ utils, which shows that more attention is needed on the code being merged and compiled.

XZ was made possible largely because there was unaudited binary data. One part as test data in the repo, and the other part within the pre-built releases. Bootstrapping everything from source would have required that these binaries had an auditable source, thus allowing public eyes to review the code and likely stopping the attack. Granted, reproducibility almost certainly would have too, unless the malware wasn't directly present in the code.

Pulled from here:

Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper Reflections on Trusting Trust and beautifully explained by Carl Dong in his Bitcoin Build System Security talk.

It is therefore equally important that we continue towards our final goal: A Full Source bootstrap; removing all unauditable binary seeds.

Sure you might have the code that was input into GCC to create the binary, and sure the code can be absolutely safe, and you can even compile it yourself to see that you arrive at the same bit-for-bit binary as the official release binary. But was GCC safe? Did some other compilation dependency infect the compiled binary? Bootstrapping from an auditable seed can answer this question.

There is a fairly all-or-nothing-security group of people within the GrapheneOS community. They will defend using a Google device on the claim of enhanced security.

Security is nice, but I'll take a hit to security if it means I get to support the growth of an ecosystem that respects the user.

The solution is to have stronger privacy laws.

Many people have the power to make certain privacy attacks impossible right now. I consider making that change better for those people than adding a law which can't stop the behavior, but just adds a negative incentive.

I wouldn't wait around for the law to prosecute MITM attacks, I would use end to end encryption.

Choosing an esoteric system for yourself is a good way for a free people to protect their privacy, but it won't scale.

If this is referencing using a barely-used system as a privacy or security protection, then I would regard that as bad protection.

Everyone using GrapheneOS would be a net security upgrade. All the protections in place wouldn't just fade away now that Facebook wants to spy on that OS. They're still in place; Facebook's job is still harder than it otherwise would be.

1. What graphics card are you using?
2. What is the output of lspci -nnk | grep "Kernel driver in use"
3. What desktop environment?
4. What filesystems for your root drive and mounted drive?
5. Is your mounted drive able to be read, written to, and have programs run on it by your regular user account?

Try setting PROTON_USE_WINED3D=1 %command% as the game launch options for a few different games and launch them.

Try different versions of proton. Also try changing the version of steam to the flatpak version, or to the native version if you are already using flatpak.

Take the whole log and put it a pastebin like pastebin.com. Then reply with the link.

You know exactly the problem I am describing that comes along with trying to game on a non systemd OS, because you have experienced it yourself.

Sorry, but that issue had nothing to do with systemd.

...you are arguing that solving the person's issue is irrelevant.

Irrelevant to proving. Context.

...then I'm sure you'll be able to prove that by solving...

Which is why I said: ... developed with systemd as the default, assumed, init system.

Next quote I'll explain more.

...they expect that it will more or less work out of the box at a fundamental level...

Which more has to do with just being setup incorrectly, than missing systemd.

You ever tried gaming on a non systemd OS?

I do. It works.

...I'm sure you'll be able to prove that by solving this person's problem for them within Devuan.

Solving a random non-systemd user's issue is irrelevant, even if we knew a lot more about their setup.

I would look at the proton log of a game that doesn't work.

How do I create logs of a game I run with Proton?

Proton will create a log file for a particular game, if you set the launch parameter to:

    
PROTON_LOG=1 %command%

  

The log file will be created in your home folder with the name scheme steam-$STEAMID.log. For example:

    
$HOME/steam-379720.log

  

...will encounter many absurd and esoteric problems, all of which ultimately stem from the fact that the vast majority of linux software is developed with systemd as the default, assumed, init system.

Unless the application in question is directly interacting with systemd, then I believe this is overblown.

Applications largely simply expect certain features to be supported. DNS, for example, could be provided by systemd-resolvd or by dnscrypt-proxy.

This isn't being built around systemd, this is being built around the expectation of a feature. This feature can be provided by different applications and still function.

In my experience, providing the features expected is far more important than providing specifically the systemd API.

Basically, any Linux OS that doesn't use systemd should be considered entirely experimental, beyond any software that the OS devs explicitly state they support.

Hard disagree.

I think the init system is more abstracted away from the developers of a game/typical user app than you are implying.