441–450 of 459 posts
Earlier quoted context omitted.
How many do you know running Linux? Most of them are either specialized bare-metal OS and the rest is VxWorks.
https://search.brave.com/search?q=missiles+running+Linux
That is pretty much what I'm doing with Steam, Proton and my Game Library. 99% the time it works just great.
If you mostly do singleplayer, sure. Anything online with anti-cheat is usually broken.
The working number is usually around 40-50% see areweanticheatyet.com
What?? I've used Linux for quite a while, and I've had a very good experience with software. I struggle to follow what they're talking about, Linux works just fine. Using Windows software is also pretty easy and like many people have already mentioned wine-binfmt is basically what this article is describing.
Earlier quoted context omitted.
AppImages have a few problems. Ever seen how much dependencies you need installed to execute an AppImage? You also need to be in an environment where you can create FUSE filesystems. And iirc the reference implementation requires the deprecates fuse2 library to work. Snaps, Flatpaks, AppImages and static linking are all solutions to a real problem. But I don't think AppImages are an especially good solution. I talked…
Snaps and Flatpaks have many more dependencies than AppImage, they are just not deprecated YET.
Earlier quoted context omitted.
I am sure this is true. But I seem to have had good results building static executables and libraries for C/C++ with cmake (which presumably passes -static to clang/gcc). golang also seems to be able to create static executables for my use cases. Unless static linking/relinking is extremely costly, it seems unnecessary to use shared libraries in a top-level docker image (for example), since you have to rebuild the im…
> I am sure this is true. But I seem to have had good results building static executables and libraries for C/C++ with cmake (which presumably passes -static to clang/gcc). golang also seems to be able to create static executables for my use cases. Depends on what you link with and what those applications do, I would also check the end result. Golang on top of a Docker container is the best case, as far as compatibil…
And yet the original Macintosh toolbox was 64 kilobytes. Black and white though, and no themes out of the box.
Even a 1MB GUI library (enough for a full Smalltalk-80, or perhaps a compact modern GUI) would be in the noise for most apps.
> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. How this can be considered a good thing?
Backwards compatibility is generally a good thing. It certainly has its downsides (like security) which can be more or less of a concern depending on backwards compatibility techniques.
Earlier quoted context omitted.
> and each app is isolated in a different user id I always liked this idea; but wouldn't you run into issues with file permissions? And if not, wouldn't that mean that the program in question would have access to all your files anyhow, removing the benefit of isolation?
When I'm using Office, the files come from a shared directory accessible as Z: I use scripts to automate everything - including allowing wine to use Xwayland (because until I start the application I want, its userid is not allowed to show content on my display) If you want to try using wine with different user ids, try to start with a directory in /tmp like /tmp/wine which is group writable, with your windows app and…
Earlier quoted context omitted.
> It's not just to prevent applications to read other applications files, but also to firewall each application individually Why would one want to prevent applications from reading other applications' files? We're talking about running desktop applications designed for an OS that isn't built around any concept of application isolation, and for which using a common filesystem is a primary mechanism of interoperability…
> Why would one want to prevent applications from reading other applications' files? Because I can, and because I don't trust Windows application to be secure. Thanks to that, I have no problem running 15 year old office software: even if I knew it was malicious, I also know there's nothing it can do without network access, without file access, and with resources constrains (so it can't even cause a denial of service…
Great. Except... WTF can you do with an office application that can't read or write files?