It's really not and the culture is not that big.
In Windows, ALL software is installed through suspicious means. In Linux world, MOST software is not. That's the difference.
If some dumbass wants to curl a random URL into a shell that's their problem. That's a very rare occurrence.
> You can do the same thing but with a Linux binary of "photoshop."
Yes, but it seems to me you are choosing to be dense on purpose and it's irritating me.
Please read what I am actually saying. I'm not saying it's impossible to make malware for Linux systems. I'm saying the CULTURE of Linux users is not to download random executables. So if I do that, it wouldn't be very effective. If I upload a random ELF executable to download.com, close to nobody is going to download it. On Windows, this is not the case.
> This is due to more consumers using Windows than Linux.
Again, I've already addressed this. It seems you cut off the quote too early.
This is PART of the reason, but we have to acknowledge how much easier it is to actually distribute malware on Windows.
The "popularity" argument is also just a bad argument. Linux is absolutely not unpopular - almost all the servers worldwide run some Linux distro. Those servers, lots of them, contain valuable data. They are absolutely a target for malware authors. There's probably more servers running Debian alone than Windows Server and it's not even close. Even still, there's a lot more malware that runs on Windows Server than Debian.
> Linux Distros...
There seems to be a fundamental misunderstanding here.
What you are proposing is a change to the Linux kernel which allows it to not be modified in some way. That's not something that is a distribution concern - that's a kernel API concern. Which will never be implemented in the kernel for the reasons already specified.
>What you are proposing is a change to the Linux kernel which allows it to not be modified in some way.
Linux already supports attestation and it doesn't prevent the kernel from being modified.
>That's not something that is a distribution concern
It is because distros like Android already support such an API to apps.
>Which will never be implemented in the kernel for the reasons already specified.
Again it already exists in the kernel.
I was talking more about the supply chain of the operating system itself, but lets not forget Linux has a culture of people running random commands off the internet which is also an easy vector to get people to install malware. Also I think you are overconfident in how much vetting repositories like npm do. I'm sure Linux people download random stuff off of github too like appimages.
>it's 10x easier for me to add a virus to photoshop and upload that exe to download.com
You can do the same thing but with a Linux binary of "photoshop."
>That's why Windows has a lot of malware and Linux doesn't.
This is due to more consumers using Windows than Linux.
>You're constructing a strawman.
I'm trying to assume what you mean due to this being asynchronous communication since the claim of attestation being related to freedom 0 and 1 is not true. One is about proving information to another party and the other is about having freedom of what you are running on your computer.
>What we're saying is that building kernel-level APIs to hook in anti-cheat or other anti-user software is antithetical to freedoms 0 and 1.
In this case being able to prove with relatively high confidence that no one in a game is cheating is a pro-user feature.
Being able to attest to the system state does not limit freedom 0. Anyone is still free to run any system they want, they just can't attest to their system being trusted if they are not running something trusted. Attestation doesn't make software any harder to modify than before, freedom 1, it only prevents you from attesting that you are using unmodified software when you aren't. Linux distros are not arms of the free software foundation so I don't think trying to argue about what they think is free or not is necessarily relevant to something like this being created.