starshipeleven
I'm not reading all of that. Especially since you started it out with a gif.
Other people seem to understand my point, so, the fact you can't isn't worth my time. You rarely are.
Announcement
Collapse
No announcement yet.
Steam For Linux Beta Adds Experimental Namespaces/Containers Support
Collapse
X
-
Originally posted by arQon View PostThe Steam client is doubtless much closer to a "simple" app than a game, and yeah, it's hard to excuse Valve for not having ported it yet given how important a part of their business it is. But it's also VERY old, and pretty much held together with scotch tape and baling wire at this point, and like any project with a mountain of technical debt to it there will be a genuine fear of touching it at all, especially since it IS almost their entire business.
"Just recompile it" shows a level of ignorance so complete that it blows my mind you even felt qualified to post it. And what's the real benefit to Valve for doing that? Having to maintain two clients, as you say, when there's zero user benefit to a 64-bit app in the first place and that platform is less than 1% of your market. Remember that until, what, ?about two years ago, if that? Ubuntu et al were still pushing their 32-bit builds as the "default" install.
Steam's stats aren't perfect, but Valve also has a lot more information about who's running Steam than you or I do. And if I was them, I wouldn't bother with a 64-bit Linux client at all either, until I could see that well over 95% of Linux users were on 64-bit systems, AND that there were a lot more of them than there are.
- Likes 1
Leave a comment:
-
Originally posted by carewolf View PostFor any well-written program it is a simple recompile.
But *in practice* it absolutely is not the case with any "legacy" code I've ever seen, and it wasn't when we moved from 16 to 32 either.
> If you are doing something overly clever with pointers and packing, and you are an amateur and did it wrong, it might need some rework
Yeah, no. If you are doing something overly clever with pointers and packing, because that's what you needed to do to get something to work performantly, then you are a professional and did exactly what you should have. It's great to be able to sit on the sidelines with toy apps that are simple on a technical level (regardless of complex they are in a business sense) and sneer about how all *your* code poops rainbows, but when significant chunks of your codebase are hooked into asm and were written over a decade ago, it's a LOT of work.
The goal isn't "get it to compile on 64-bit", it's "get it to run properly on 64-bit". That's not the same thing, and I know you understand that. But if you think "just recompile it" is all that you need, then trust me: you have led a charmed life and have never had to inherit a complex system.
> And for the love of God.. The steam client and all the steam games are entirely separate things. The games are already in 64-bit. We are talking about the launcher and nothing else.
Yes, I'm aware. My point was that the steam client is *an ancient pile of garbage code*, and while it's not going to be anything like as hard to port as a game, I used the games themselves as an example of how much work that porting can be in an extreme case, because your ridiculous "just recompile it" comment trivialised what the other end of that spectrum can be, especially when you have 32-bit libs as dependencies because your code is a trainwreck (to be clear, "you" here is Valve of course, not carewolf :P) that has half a web browser and a dozen other random messes duct-taped inside it.
But I think we're getting too much into the technical weeds here, and losing the "real" point: which is that a 64-bit steam client adds absolutely no value at all, while increasing the maintenance burden for Valve since they can't just kill off the 32-bit version. It's a clear net negative, and as a result it's not something they should be doing NOW. In the future, sure, and if I was working on it I'd have been preparing for that migration for years already (and they probably have been to at least SOME extent ever since the W7 install base passed 50% of users on x64).
But, I repeat, until the number of 32-bit Linux USERS drops to well under say 10% and the number of Linux users gets well over the current "barely worth bothering with AT ALL" 1%, why would you burn ANY manpower at all on a project that has literally no actual benefit to anyone?
Leave a comment:
-
Originally posted by schmidtbag View PostThe need for 32-bit libs doesn't change that, and, there arguably isn't even a need for them at all.
Why I need to spell everything out in large letters. I'm sure you will still not understand, but explaining once or twice so that others reading this will at least have a chance of understanding is still my duty. SO here we go
The client does not care for shit about the system bit size. You could make the client run on ARM too in a week at best if you have the source because 99% of the architecture-specific code is the webkit rendering engine that comes from upstream and has an ARM veresion already.
For the steam client 32bit, 64bit, ARM, Power is irrelevant as it is a web application itself.
I'm seeing several games in my library getting ported to 64-bit because they no longer work in MacOS.
But I guess this is OK for Apple users. And you will probably tell me that you agree with arbitrarily dropping support, because that's what good Apple users do.
I assume that means it doesn't have 32-bit libs.
Had the client itself been 64-bit, there wouldn't have been any incentive for games to be ported with 32-bit binaries.
let me repeat
Steam shipped game runtime libraries for both 32bit and 64bit games. The "game runtime libraries" are for games.
Steam specifically wanted to let developers port their games to Linux at the lowest cost possible regardless of your own uninformed opinion of what is "easy to port" or not.
It was not a choice dictated by the Steam client own bitness.
Therefore, there wouldn't have been a need for 32-bit libs,
And this is A LOT of titles and probably the only way to play these games in the future when will stop working on Windows 12 because something has changed.
and, Besset could've been working on something more practical than the namespace containers.
Namespace containers are still required for the same reason flatpak 64bit applications exist. Closed source stuff will never get updated past a certain point and therefore you need to use a static environment and libraries for them or they will break when the world around them changes.
Currently Steam is shipping an ancient Ubuntu 16.04 "runtime" in its folders, but eventually they want to actually have more modern libraries than that for games.
32bit or 64bit is irrelevant. You need containers anyway because you are shipping closed source applications that will not be updated anymore after a few years. With proper containers you only need kernel support for 32bit applications, not the whole "multilib" 32bit system libraries.
So, had the Linux Steam client been 64-bit from the very beginning, there wouldn't have been any incentive to make 32-bit ports, and this whole mess could've been avoided.Last edited by starshipeleven; 12 November 2019, 10:01 PM.
- Likes 2
Leave a comment:
-
Originally posted by starshipeleven View PostTell what? MacOS itself can't run 32bit applications anymore from Catalina onwards.
Remember, when Steam for Linux was released, there were only a handful of available titles, most of which either already had 64-bit binaries or could have effortlessly made them before the debut. Had the client itself been 64-bit, there wouldn't have been any incentive for games to be ported with 32-bit binaries. Therefore, there wouldn't have been a need for 32-bit libs, and, Besset could've been working on something more practical than the namespace containers.
So, had the Linux Steam client been 64-bit from the very beginning, there wouldn't have been any incentive to make 32-bit ports, and this whole mess could've been avoided.
Leave a comment:
-
Originally posted by schmidtbag View PostTell that to MacOS.
That's exactly when Steam client will become 64bit on other platforms too, when running 32bit games will not be possible anymore.
- Likes 1
Leave a comment:
-
Originally posted by starshipeleven View PostHaving 64bit steam client is pointless, you still need 32bit libs.
Leave a comment:
-
Originally posted by xeekei View PostHow will containerised games affect streaming/recording with other software, such as OBS?
Wayland probably has specific Wayland protocols to allow desktop-sharing and screen-recording software to grab all the rendered (AKA composited) frames that are ultimately displayed on the monitor.
Leave a comment:
-
Originally posted by starshipeleven View PostContainers are using namespaces (a Linux kernel feature), not hardware virtualization (a hardware feature).
It's not "bare metal virtualization" as there is no VM, no additional kernel, and no hardware virtualization layer to fool such kernel. The proper term is OS-level virtualization https://en.wikipedia.org/wiki/OS-level_virtualization
It's literally just telling the current system's kernel "load libraries for this application from path X instead than from default system path" and "for this application please block system calls in this blacklist" but the application is talking directly to the same OS kernel as if it was any other application running in the system.
Docker (Flatpak/Snap/LXC/whatever) does not need VT-x/AMD-Vi on Linux
It needs VT-x on Windows (and Mac I guess) because there Docker is run through a Linux VM and to run the Linux VM you need virtualization because it's a VM.
And why you need a VM? Because the docker image is not a VM but just a pack of Linux application and libraries, it needs a host Linux kernel to run.
https://www.unixtutorial.org/does-do...virtualization
Leave a comment:
-
Originally posted by zxy_thf View PostI'm Okay with a containerized steam with nested containerized games.
The native steam causes lots of troubles on my system and the flatpak one works flawlessly, and to containerize individual games also makes sense to me because there are likely fewer compatibility issues (just think of how much effort MS put in order to maintain backward compatibility).
My real concern is it seems Value created yet another containerization solution, and we already have (at least) three.
They are adapting the technologies to suit their needs, but they are not pushing for a new container format...
Leave a comment:
Leave a comment: