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

I like Flatpaks. They provide a reasonable compromise between compatibility guarantees and disk space usage thanks to runtimes, integrate fairly well while also providing decent sandboxing features and are easy to manage and typically get updated fairly regularly. I think they definitely should be embraced more, especially for the newbies, since you won't break your DE and display manager by installing them.

Flatpak is obviously not ready (at least yet) to be the sole software source. A fair amount of things like terminal utilities and developer tools either aren't installable through Flatpak or otherwise have some quirks and integration issues. At least for me on Fedora Silverblue, the best approach to software development right now is to run my IDE, linters, compilers and library dependencies off of a Toolbx container. So, I don't think Flatpak will be replacing distribution-specific package managers in the short-term for this sort of system-level software.

But when it comes to day-to-day graphical application programs, the stuff majority of people would actually use, Flatpaks work just fine and provide a less fragile environment with a slight bit more safety guarantees and with a better way to target more distributions with a single package. AppImages might have their place for repository-less software distribution of, say, proprietary software that you just download off some website somewhere, but I've found AppImages to be often of poor quality and not actually meeting the cross-distro compatibility they often claim, plus they necessarily suffer from more library duplication than Flatpaks. Snaps on the other hand seem to win Flatpak in terms of being able to install terminal utilities and daemons, but beyond that they seem worse than Flatpaks in most ways, so it would probably be better if Flatpak just gained the ability to better install and use utilities.

Not that long ago I was still fully on-board with the distro-specific packaging approach, where software developers develop and package maintainers package, but I think this approach ultimately has too many drawbacks. It creates a potential for manpower issues, since either the developer needs to do much packaging work to target a multitude of distributions, or they need to rely on package maintainers to have the time and energy to do the packaging for them, which either way results in much duplicate work. It also reduces initial visibility, as software needs to filter through more layers before being generally available to users and increases the time between a new version being released and it being available to users, because some distros will freeze or hold back packages for varying amounts of time for varying reasons. If we want more developers to make application software for Linux, we need to make the process as smooth as possible and reduce the amount of work needed to get your software in front of as many users as possible.

View this comment - View article - View full comments

Quoting: BielFPs

Total War: WARHAMMER III gets a short hype-trailer for The Daemon Prince

You can easily defeating him by using kill -9

Bold of you to assume it doesn't have Restart=always enabled.

View this comment - View article - View full comments