> Things get exponentially cheaper as you make more of them.
not all things.
Things that can scale are things that have a non-linear scaling production output vs input. For the LCDs (and semi-conductors), the area of the output is squared, if you increased the size of the production by a linear amount (let's say, the glass width). But the work required is not quadrupled!
Things that are linear in scaling - e.g., a burger cooked, does not scale the same way (at least, not for a McDonalds burger) - it's a one to-one, even if you tried to make it scale up by having more cooks/more machines etc. Cars, to a similar degree, but the fixed cost of a car factory/assembly line vastly out weight the lack of scaling i suppose, and so cars did get cheaper but not from the scaling manufacturing, but from cheaper components, and more automated steps etc.
or figure out how to build it yourself from source. But you can count on the lazy tax - esp. for windows (as building from source on linux is likely to be much more convenient).
If a student is willing and desire to learn, an LLM is better than a bad teacher.
If a student doesn't want to learn, and is instead being forced to (either as a minor, or via certification required to obtain work & money), then they have every incentive to cheat. An LLM is insufficient in this case - a teacher is both the enforcer and the tutor in this case.
There's also nothing wrong with a teacher using an LLM to help with the grading imho.
i do feel the ecosystem isn't broad enough for linux to become consumer facing. E.g., if you buy a random chinese made writing tablet and tried using it on linux, it has less than even chance of working straight out the box.
Similarly with bluetooth, wifi (for laptops), etc.
The problem is that OEM are locked into windows, so you have the chicken/egg problem where OEM won't want to spend effort on linux compatibility without a large customer base, and customer base won't grow unless they know for sure it is always going to work for _any_ piece of hardware they might purchase.
May be steam machine and valve could be the push it needs to establish a large customer base.
> I don't consider it "malware" anymore than I consider a driver for my graphics card to be "malware" even if they do operate in kernel mode.
the bloggers/journalists calling it malware is doing the conversation a disservice. The problem is only really the risk of bugs or problems with kernel level anti-cheat, which _could_ be exploited in the worst case, and in the best case, cause outages.
The classic example recently is the crowdstrike triggered outtage of computers worldwide due to kernel level antivirus/malware scanning. Anti-cheat could potentially have the exact same outcome (but perhaps smaller in scale as only gamers would have it).
If windows created a better framework, it is feasible that such errors are recoverable from and fixable without outages.
I'm not giving a small time software vendor proprietary access to my machine at that level. I honestly think that anyone who accepts it must be woefully uninformed about the risks involved.
I'm already salty about the binary blobs required by various pieces of firmware.
People just don't care. Even Stallman is okay with a microwave with closed-source firmware as long as it doesn't try to update its firmware.
For most people, a computer is just another appliance. They don't consider the security implications that this appliance can leak credit cards and such.
But I think they ought to. I also suspect that the current state of affairs is largely due to lack of understanding.
> as long as it doesn't try to update its firmware
I agree. But that isn't what we're talking about here. Things that can't update their firmware generally don't need you to upload a binary blob to them on startup.
but how does the anti-cheat know that the kernel is not modified such that it disables certain eBPF programs (or misreports cheats/spoofs data etc)?
This is the problem with anti-cheat in general (and the same exists with DRM) - the machine is (supposedly) under the user's total control and therefore, unless your anti-cheat is running at the lowest level, outside of the control of the user's tampering, it is not trustworthy. This leads to TPM requirements and other anti-user measures that are dressed as pro-user in windows.
There's no such thing in linux, which makes it inoperable as one of these anti-cheat platforms imho.
Great point. As I mentioned there are other attack vectors and you can mitigate them. For mitigating what you are mentioning for instance you don't just run one eBPF program, but you run a cluster of them that watch each other:
(The following was refined by an LLM because I didn't remember the details of when I was pondering this a while back)
All your anti cheats are eBPF programs hooked to the bpf() syscall itself.
Whenever any process tries to call BPF_PROG_DETACH or BPF_LINK_DETACH, your monitors check if the target is one of the anti cheats in your cluster of anti-cheats.
If an unauthorized process (even Root) tries to detach any of your anti-cheat processes, the eBPF program uses bpf_override_return to send an EPERM (Permission Denied) error back to the cheat.
(End LLM part)
Of course, you can always circumvent this by modifying and compiling the kernel so that those syscalls when targeting a specific PID/process name/UID aren't triggered. But this raises the difficulty of cheating a lot as you can't simply download a script, but you need to install and boot a custom kernel.
So this would solve the random user cheating on an online match. Pro users that have enough motivation can and will cheat anyway, but that is true also on windows. Finally at top gaming events there is so much scrutiny as you need to play on stage on vetted PCs that this is a non-issue
It's open source. Somebody will simply publish an AUR package with a custom kernel that is one command away. You're underestimating the capability of motivated nerds to make a good UX when needed :p. This is how we ended up with SteamOS in the first place
But given Linux kernel is monolithic and you can enforce signing of kernel modules too, using TPM to make sure the Kernel isn't tampered with is honestly the way to go.
You can't, but circumventing anti cheats already happens on windows with all their fancy kernel level anti cheats.
I believe the goal is to make it so uncomfortable and painful that 99.999% of the users will say fuck it and they won't do it. In this case users need to boot a custom kernel that they download from the internet which might contain key-loggers and other nasty things. It is not just download a script and execute it.
For cheat developers, instead, this implies doing the modifications to allow those sys-calls to fly under the radar while keeping the system bootable and usable. This might not be trivial.
the OP isn't wrong about insider trading - it's just that it lacked the crucial bit about being _transparent_ about insider trading.
Current insider trading laws are about _preventing_ it (but it still happens). This makes it so that insiders who do trade and get away with it make bank, but this does little to benefit the over all market information equilibrium.
What needs to make insider trading "good" (instead of bad), is to make the insider's trades 100% transparent and instant (instead of the months of SEC filing currently needed before it becomes public info). Doing this will ensure that insider's trades immediately gets reflected and copied/arbitraged against, and will allow the price of a stock to reflect information not yet released but is acted upon by insiders.
not all things.
Things that can scale are things that have a non-linear scaling production output vs input. For the LCDs (and semi-conductors), the area of the output is squared, if you increased the size of the production by a linear amount (let's say, the glass width). But the work required is not quadrupled!
Things that are linear in scaling - e.g., a burger cooked, does not scale the same way (at least, not for a McDonalds burger) - it's a one to-one, even if you tried to make it scale up by having more cooks/more machines etc. Cars, to a similar degree, but the fixed cost of a car factory/assembly line vastly out weight the lack of scaling i suppose, and so cars did get cheaper but not from the scaling manufacturing, but from cheaper components, and more automated steps etc.
reply