• 1 Post
  • 26 Comments
Joined 1 year ago
cake
Cake day: July 16th, 2023

help-circle

  • The third option is to use the native secret vault. MacOS has its Keychain, Windows has DPAPI, Linux has has non-standardized options available depending on your distro and setup.

    Full disk encryption does not help you against data exfil, it only helps if an attacker gains physical access to your drive without your decryption key (e.g. stolen device or attempt to access it without your presence).

    Even assuming that your device is compromised by an attacker, using safer storage mechanisms at least gives you time to react to the attack.



  • How in the fuck are people actually defending signal for this, and with stupid arguments such as windows is compromised out of the box?

    You. Don’t. Store. Secrets. In. Plaintext.

    There is no circumstance where an app should store its secrets in plaintext, and there is no secret which should be stored in plaintext. Especially since this is not some random dudes random project, but a messenger claiming to be secure.

    Edit: “If you got malware then this is a problem anyway and not only for signal” - no, because if secure means to store secrets are used, than they are encrypted or not easily accessible to the malware, and require way more resources to obtain. In this case, someone would only need to start a process on your machine. No further exploits, no malicious signatures, no privilege escalations.

    “you need device access to exploit this” - There is no exploiting, just reading a file.




  • "We listened to our accounting, and the massive wave of refunds and unbought mtx is hurting our numbers. PR isn’t happy about the reviews either. We’ll keep you updated on future plans for fucking you over!

    Do you really think that Sony will actually back down? They are calming down the shitstorm that is going over all media, socials and steam. They’ll reorganize and will move on with their plans. Arrowhead and Helldivers is just one of many assets.


  • If you use a dockerized environment, that will only work better on Linux. .NET8 is AFAIK natively supported on Linux, so there shouldn’t be too much of an issue apart from the usual clunkyness. Visual Studio will probably be more of a problem. The “easiest” way would probably be to switch to jet brains or vscode. If you are hardstuck on VS for whatever reasons, you probably should be able to do some voodoo with running it in docker and using the container as a remote desktop, but this will be PITA to setup and maintain.



  • The Hamas-led murderous rampage into southern Israel was the deadliest terror attack in Israel’s history, killing at least 1,200 people and abducting more than 250 others. Israeli attacks on Gaza have since killed at least 33,634 Palestinians and injured another 76,214 people, according to the Ministry of Health there.

    Jesus fuck, Germany is paying symbolic money to roughly as many genocide survivors in Israel as people have been murdered and injured by Israel committing genocide.

    The current German government is an absolute fucking joke, and they are doing everything to actually show it.


  • Again, you may quote the FSF, but there are too many users of open source, as well as developers, who got into it for the reasons I stated. I can assure you that they are not doing it so that corporations can profit off their software without giving back.

    If you are developing open source, you are not necessarily developing FOSS. If you are developing FOSS, you are also developing open source.

    FOSS is well defined by the FSF, and it has been for ages, and to be frank, therefore no one cares for anyone’s personal definition of it.

    What I am against is having the cake and eating it, as it’s being proposed with this licensing. Either you do FOSS, or you don’t. Either you do open source, or you don’t. Either you do proprietary software, or you don’t. It’s really that simple, because depending on your project, you take the terms that you see fitting and live with the consequences. The whole goal of this proposal was to be taken more serious as open source developers and projects, and to ensure funding for further development. Cherry picking the best parts of every model, and making irrational demands does not achieve that.

    As I said, I’m absolutely on board that open source licensing and open source development being taken for profit by corpos absolutely sucks, and the usual licensing models have not aged well with the much wider adoption and usage of open source, and there is a need for change - as it’s being done e.g. by elastic, redis and others with their dual licensing.


  • It doesn’t matter how hard you want to call it FOSS, but with this licensing terms you describe it is not FOSS, period. And to be honest, you calling out various people for not getting what FOSS is, while you fully ignore the agreed on definition by people who are actually doing FOSS is you discrediting yourself.

    You haven’t found a license like this, because your model is flawed: A licensing like this will disqualify you from any kind of usage in an actual FOSS licensed environment. Personal users, which will not be providing revenue, will not be really affected by this, and are irrelevant for your point. Corporate users, which you will mostly target by this new license probably won’t be able to use your funky new license because they will need to check with legal, and your software will need to have a lot of USPs for someone to bother with that. A 1% corpo-richness-tax will not be approved by any kind of bigger company, because it’s a ridiculous amount from the perspective of your potential customers.

    You’re taking yourself way to important. Open source software is not replaceable as a whole, but individual projects are. If you want to earn money with your project, that’s good on you, license it accordingly, but do not try to upsell it as FOSS.

    And I fully get your point, and I’m currently working on the same problem in my in-development project, and I’m not sure yet whether to dual-license it, for similar reasons you stated, and live with the consequences of providing OSS, but non-FOSS software, or do FOSS and provide it for actually free.

    Edit: Also, the xz backdoor has nothing to do with funding. Any long time maintainer (as in not just a random person contributing pull requests) going rogue can happen in funded scenarios as well.





  • I don’t think that the current tools will be using it internally, since this would require the tools actually supporting the CLI launcher, and in the best case we would have something like the proton config in steam in every tool separately again.

    I think that you will need to have your launcher installed, but you will have this new launcher as your entry point, from which you will start your games using proton from the linked project.

    But - it’s a PoC right now, maybe both ways will be possible.

    From a wishful perspective, it would be super neat if this new launcher would hook into the installed regular tools, and automagically make those use the preconfigured proton runtime it brings. Shouldn’t this be possible using LD_PRELOAD?


  • Right now it’s a PoC (proof of concept, a rough implementation of an idea), to emulate launching games from other stores as if they were launched from steam using proton.

    What this could be used for is to create a new Linux launcher, where you setup proton once, and launch all games using this launcher.

    This simplifies usage for you as the end user, since you would only need to install the launcher, and it sets up ProtonGE, and you’re done. It also enables simple Proton usage for other games (Epic, Lutris, whatever).

    Additionally it helps unifying development. Windows games under Linux have a lot of moving parts: there’s Proton as a compatibility layer. There’s integration between steam, proton and your system (sniper/vessel). There’s protonfixes which is game specific changes in proton. Each of which itself consists of components and stuff I’ve missed. In short, it’s complicated. Unifying all this components with one tool, with one battle tested installation and compatibility and with a single source of truth in development could be another big step in Linux gaming.

    TLDR - potentially a new launcher for games under the Linux, enabling any game to be played using proton, when supported, not only steam games.




  • Before you talked about the Fediverse as a whole, now from a single user perspective.

    IMO it affects the Fediverse as a whole by abusing it. The whole idea is an open network, where instances can federate with each other to bilaterally share information and create a seemingly single platform. This is not the case with the planned Threads integration, because they explicitly plan to feed on the content, but hiding sharing their own content behind an (for most of their userbase) obscure opt-in.

    From a single user perspective it doesn’t affect you directly. But it affects the platform you are part of with malicious intent.

    I am not against Threads joining the Fediverse, and I do actually think it would be great for the growth of the Fediverse if actual big players join, and if it brings content that I personally do not like to see, I can use the tools available (e.g. blocking user/communities/instances) to hide it. But only if they plan on joining as a “regular instance” like any other - but Meta does not intent doing so, since they have chosen the opt-in with obvious intent of simply gaining additional content on their walled platform for their own gain.


  • The problem is not them reading data, but that Threads will take Fediverse content, and display it on Threads. In the opposite direction, Fediverse will only see the select few user content that do actually opt-in, and let’s be honest here, most users won’t know what the Fediverse is, except for again the few people that are on both platforms. This is absolutely not “playing nice” as you’ve put it before, and purely parasitic and, again, purely a greed decision by Meta. I don’t really know why you are shilling so hard trying to excuse absolutely unexcusable behavior.