Quoting: F.UltraWouldn't the much greater marker on Android make it that much more susceptible to cheaters and thus much more profitable for a cheat-dev to write an exploit for?

A quick google shows that cheats for Fortnite on Android is just a simple APK that you can sideload, what those do is apparently to replace the Fortnite launcher with one patched to load the cheats.

It might be, if there is demand for exploits and cheats. Hell, maybe there even is a Fortnite cheating problem on Android. But clearly Epic's calculus says that it's worth the money to compromise. Otherwise they'd pull the plug on Android, right?

My whole argument hinges on the simple fact that Epic does not want to compromise with the Linux/Deck market. If Epic was willing to compromise we could hand-wave literally all the technical hurdles, because if Epic really really wanted the game to be available on the Deck then they could obviously make that happen. They aren't interested in compromising and at least claim to want to run their full-blown EAC on Linux and my argument is that it's never going to be a viable approach.

Getting Fortnite to run on Linux is not what I am claiming to be impossible here. It's the set of demands Epic is putting on Fortnite running on Linux that I am claiming as at least highly impractical.

View this comment - View article - View full comments

Quoting: pete910Oh come on, just about everyone knows it takes seconds to look for an apk and install it for andriod. And lets be honest, a cheater is going to know how to do basic things on any platform and there is no need for custom roms to be used. On IOS I would agree with your point.

Android is so sandboxed that you aren't going to be installing Fortnite cheats with an APK off the Internet, except if you somehow found a hacked Fortnite client that is still somehow respected by the Fortnite servers. Otherwise you'd at the very least need root in order to poke at the running processes from outside the official binary and although it can be done, it is not common knowledge. You are also still not acknowledging the other side of the issue, which is that the Android market is so unbelievably big that it's a great deal even if you have some cheaters. You just cannot equate the Android and Linux/Deck markets and assume the same risk calculus applies everywhere.

View this comment - View article - View full comments

Quoting: pete910Think you've just shot your own argument in the foot there.

It's a given than 99% of cheaters have no clue on how to write a cheat let alone a kernel driver on windows, Which also would be true for Linux side or the deck.

So the entire premise fails as a result of that theory.

Different argument, production and consumption operate under different rules entirely. For a cheat to be popular, all you need is that 1% to make a few and a distribution method to get them in the hands of would-be cheaters. My argument on Android side is that there isn't an easy distribution method, because replacing a phone ROM is a more complex procedure than installing essentially an application or even booting up a VM image or flashing a USB stick.

And even in the case of some people booting a cheater ROM on their phone, Epic would be willing to make that deal simply due to the size of the market.

View this comment - View article - View full comments

Quoting: Lancabanwith everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.

Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?

Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.

Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.

View this comment - View article - View full comments

Quoting: marcusI still think that if Valve provided a measured boot facility where a user-program could verify that it is running on an un-modified kernel then EAC could assume that there are also no kernel-level cheats present and that all kernel-level introspection APIs present correct and unmodified results.

All fun and games until someone comes up with a way to spoof the measured boot report. If you add more layers, someone will eventually figure out how to hack the layer above.

View this comment - View article - View full comments

Seems entirely fair. He doesn't want to write rootkits for my system and I don't want to run his rootkits on my system. We've got good mutual agreement there.

View this comment - View article - View full comments

Quoting: iiigg4giyMore Wayland is always good to hear but I get confused how these things all fit together. What's the difference between SDL and vulkan for example?

SDL is a platform abstraction library, Vulkan is a graphics (and GPGPU?) API. So the overall way these would fit together is someone starts a game that uses SDL on a Wayland based desktop, SDL realizes it is running on Wayland and makes appropriate calls to create a Wayland window and then sets up a Vulkan context for that window. Then the game can start talking Vulkan and game graphics get drawn where they should be.

View this comment - View article - View full comments

Quoting: STiATIsn't that a risk and circumvents the whole idea? I mean.. you have profile.d which gets executed and could do all kind of stuff there. Even modifying the ostree...

Who's going to modify it though? You'd still need root and none of the recommended ways to install software grant root access to any installation procedure. You would have to pipe some script off the net into sudo bash and at that point the script could just dd your drive full of garbage anyway. The immutability is not primarily a security feature but a stability feature: it ensures atomic and transactional system updates so that the software is always in a consistent state.

View this comment - View article - View full comments

Quoting: STiATSince you are using Silverblue and I have yet to find sb else who does ... how does Silverblue do with additional disks? I mean immutable system means no writing to /etc, means not being able to add additional disks on boot time.

/etc and a few other directories (such as /home, naturally) are mounted writable. So, to mount disks you just edit /etc/fstab as you would ordinarily. Basically, Silverblue feels like just an ordinary distro up until you go to install software or run system updates. All of the regular system configuration, service management and all of that is basically the same as anywhere else.

View this comment - View article - View full comments

Quoting: sudoerNo, the secret is in the libraries, check the 2 points here.

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

Except that Arch also breaks the first point by also providing multiple versions of certain libraries for compatibility reasons. And I highly doubt Debian providing libfoo1 and libfoo2 significantly increases dependency resolution time, since those are treated as two separate packages. So, I think the speed different between Pacman and APT can be explained with something else.

Quoting: sudoerIMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

I have a feeling that regular computer users aren't going to read the manual from cover to cover to learn how to maintain their system. No matter how much fun Arch/Gentoo users seem to have doing it, I don't think it's the way forward for general adoption.

View this comment - View article - View full comments