[ajross]

I know it feels like being pedantic and missing the joke, but "just give me the EXE" is a terrible bug, not a feature request. Distributing unauthenticated, untraced OS-level binaries is just dangerous in the modern world. Safe app distribution requires either elaborate sandboxed runtimes (browsers) or carefully curated and maintained lists of known-safe binaries (app stores, distro package repositories).

We can't be doing this "GIVE ME THE .EXE" anymore. Those days are gone.

Even building from source is questionable, but at least there it requires that the installer be part of (or at least adjacent to) a community of developers who can be expected to have the expertise to notice and recognize bad actors pushing code.

[bigstrat2003]

> We can't be doing this "GIVE ME THE .EXE" anymore. Those days are gone.

We can and should still do that for people who want it (i.e. most people). The security conscious can decline to use them, but that doesn't mean the rest of us should have a worse experience.

[riquito]

If you're considering "just give me the exe" as multiple sharing between people, I wholeheartedly agree that it's a mistake, but the context here is of a person wanting to download the binary from the author themselves.

[ajross]

How does an average user authenticate "the author themselves"? Again, you or I understand how github projects work and can figure out within a minute or two whether or not this is the right group or a legitimate project.

But if you're just a "GIVE ME THE .EXE" person, how do you know the binary you're looking at is a legitimate network scanner or keyboard mapper or game cheat or whatever? You don't. You can't. You just followed a link from someone else who thought it was.

The basic point is that software in the modern world is too complicated to require regular users to validate. They can't do it. And so we need to have trusted authorities like distros and app stores to do it for them, even (especially) when they demand we JUST GIVE ME THE .EXE.

[cdrini]

I wish we could have something like exes with permissions. Similar to browsers. So I could run an arbitrary executable, but the OS level APIs would be blocked unless the user allowed the given permission.

[ajross]

That would mostly be a browser, though. Changing the language used for the API to C (or whatever) from Javascript is mostly cosmetic, existing interpreter/JIT engines are extremely optimized, you can target basically anything to wasm, etc...

The problem isn't the technical hurdle, it's that sandboxed apps really aren't what we want in a lot of cases. There remain a lot of use cases for native apps the interact directly with the hardware in ways that are hard to abstract safely. Games need the whole GPU, backend middleware needs the raw network stack, you want to set up routing tables or a custom NAS, etc...

Those requirements don't go away even when "most" stuff can be done in a browser-equivalent sandbox. And... you need to rely on your Linux distro for those things still, or at least compile from an active github project. You can't just get raw binaries from whoever and expect to be safe.

[chaxor]

What's wrong with flatpak for that? Honest question as I don't know that space really

[enriquto]

it should not be the flatpack who decides its own appropriate permissions, but the owner of the OS where the flatpack runs. Even when--especially when--, the permissions profile disagrees with that requested by the developers. Whatever permissions the flatpack "requires" should be irrelevant. Only those granted by the user will be given.

Flatpack and snap and other systems that conflate packaging and permission management get it totally wrong. Permission management is an OS-issue, not a packaging issue. Thus, distributing a plain static executable or a python script should be just as safe as a "safely packaged" app.

[psnehanshu]

apks are like that