Valve Reaffirms Commitment To Linux While Also Releasing Updated Proton

[ZeroPointEnergy]

Those multilib problems have been solved over a decade ago. I don't think some fragile container shit is better than an actual support of 32bit binaries in the main OS. It does it now and there is no reason it can't do it in the future. If Ubuntu gets rid of multilib they will have fewer users in the end because they literally break the userland.

Also before you somehow told us that the 32bit versions of the libs will stop working for whatever reason, but apparently in a container they are magically fine.

[oiaohm]

Those multilib problems have been solved over a decade ago.

Multilib triggered failures in build have been turning up all the time. There are a lot of automated testing finding the faults.

Also before you somehow told us that the 32bit versions of the libs will stop working for whatever reason, but apparently in a container they are magically fine.

Big thing there is in container you can go out of version alignment that multilib designs forbid.

I did not say being in a container is magically fine. Container allows more more resilient 32 bit library support by in fact supporting going out of version alignment.

I don't think some fragile container shit is better than an actual support of 32bit binaries in the main OS..

Really both can be fragile.

Multilib/multiarch is forcing releasing 32bit and 64bit libraries on exactly the same version. This is not helpful when you have a patch that fixes the 64 bit version but breaks the 32 bit version and vice vs verse. Multilib solution is highly fragile and requires lot of work to keep it in fact working. Multiarch gets even worse.

http://www.improbability.net/loki/ You cannot expect old loki games to work on a modern distribution without bundling up old libraries.

There will be some libraries were version matched will be forced like Nvidia closed drivers due to this being a kernel driver requirement. But over 99 percent of the runtime libraries programs use don't need to be matched between 32 bit and 64bit runtimes if you remove the multiarch/multilib out.

[ZeroPointEnergy]

http://www.improbability.net/loki/ You cannot expect old loki games to work on a modern distribution without bundling up old libraries.

This has absolutely nothing to do with multilib but with people not caring about the userland and breaking ABI compatibility all the time. You know, people like you who think it is a good idea to completely break 32bit applications in the name of "progress". And then you come with silly band aid like containers because of a self created problem.

There are actually use cases for containers where they add value. But if you think bundling of depencencies and old libs is one of them you have some serious other issues.

[oiaohm]

This has absolutely nothing to do with multilib but with people not caring about the userland and breaking ABI compatibility all the time. You know, people like you who think it is a good idea to completely break 32bit applications in the name of "progress". And then you come with silly band aid like containers because of a self created problem.

It been that way for over 2 decades at some point you have to just accept the problem and build systems to cope. The self created problem is unlikely to go away anytime soon.

Remember what I wrote that multilib/multiarch by design is mandating matched versions due to shared data.

There are actually use cases for containers where they add value. But if you think bundling of depencencies and old libs is one of them you have some serious other issues.

No I don't have a serious issue thinking that. This is you not thinking about the problem.
1) 32 bit mode x86 is being tested less.
2) Users of multilib/multiarch installs are the rarity not the normal and getting more rare because the people using any 32 bit program is coming rarer.
3) We have had on going compatible problems from ABI breakages this is a given.
4) 2038 problem and 32 bit time_t.

Getting containers properly worked out for 32 bit this will allow 64 bit containers as well to work well. So the people not caring about the userland breakages will not be effect those needing applications to work as much.

It absolutely makes sense at this point in time to stop 32bit x86 being multilib/multiarch and move across to containers. The really old legacy 32 bit applications are going to come like loki games like it or not because ABI breakage is going to keep happening into the near future so those applications will have to be bundled with runtime.

We are going to have more cases of 32 bit libraries not working because the developer who patched the library only tested on 64 bit systems.

We have the 2038 problem to consider that means we need 32 bit applications in containers by that time and you have to remember redhat and other enterprise distributions make there choices for 10 years into the future. 2038 is 2027-2028 when redhat and other enterprise solutions have to make up their mind on it.. https://lwn.net/Articles/766089/ Yes this stuff and if Redhat and Ubuntu want to try a few different things to hand 2038 they have to start attempting now so they can have them tested for the 2027/2038 when they have make their choice. Redhat backing flatpak and Ubuntu backing Snap now makes a lot of sense now right.

At some point you just have to accept the writing on the wall.

As a commercial distribution this way they see it.
1) There are less people paying them to fix 32 bit things.
2) There are less people running 32 bit things.
3) We have to fix 2038 issue somehow for 32 bit.
4) We have to cost reduce our work 32 bit.

Cost reduce work on 32 bit include possible completely dropping it.

Of course community distributions like debian will face this problem later as the resources the commerical distributions provide disappear from supporting 32 bit will lead to applications and libraries no longer building on particular architectures because they were never tested.

[ZeroPointEnergy]

It been that way for over 2 decades at some point you have to just accept the problem and build systems to cope. The self created problem is unlikely to go away anytime soon.

There are other solutions than a crappy container. Bundling old versions of libs is not a solution. Building s shim or something so the old binary works with the new broken userland may be one. And not breaking more stuff in the name of "progress" would be the most important one going forward!

1) 32 bit mode x86 is being tested less.

The libraries needed by 32bit software are as much used and tested as the libraries used by 64bit software is. There is a ton of 32bit software around, mainly games that are played every day.

2) Users of multilib/multiarch installs are the rarity not the normal and getting more rare because the people using any 32 bit program is coming rarer.

The majority of games is 32bit so this is simply not true. A lot of people play games on Linux and every major Linux distribution has multilib support.

3) We have had on going compatible problems from ABI breakages this is a given.

Then this has to be fixed. Bundling older versions is not a solution. It is a dead end.

4) 2038 problem and 32 bit time_t.

This can only be fixed by providing a compatiple ABI that takes care of the problem and again not by bundling old libs in a container.

Getting containers properly worked out for 32 bit this will allow 64 bit containers as well to work well. So the people not caring about the userland breakages will not be effect those needing applications to work as much.

This is just a stupid workaround and not addressing the real problem, the one not yet existing but you want to create by breaking userland again.

It absolutely makes sense at this point in time to stop 32bit x86 being multilib/multiarch and move across to containers. The really old legacy 32 bit applications are going to come like loki games like it or not because ABI breakage is going to keep happening into the near future so those applications will have to be bundled with runtime.

No, we can just stop fucking up the userland.

We are going to have more cases of 32 bit libraries not working because the developer who patched the library only tested on 64 bit systems.

They are used on multiple other architectures that are 32bit. This is not an issue, you try to invent one again to strengthen your case for containers.

We have the 2038 problem to consider that means we need 32 bit applications in containers by that time and you have to remember redhat and other enterprise distributions make there choices for 10 years into the future. 2038 is 2027-2028 when redhat and other enterprise solutions have to make up their mind on it.. https://lwn.net/Articles/766089/ Yes this stuff and if Redhat and Ubuntu want to try a few different things to hand 2038 they have to start attempting now so they can have them tested for the 2027/2038 when they have make their choice. Redhat backing flatpak and Ubuntu backing Snap now makes a lot of sense now right.

If it can be fixed in a container it can be fixed in a regular userland. Containers are not special.

At some point you just have to accept the writing on the wall.

What are you, a crazy prophet?

As a commercial distribution this way they see it.
1) There are less people paying them to fix 32 bit things.
2) There are less people running 32 bit things.
3) We have to fix 2038 issue somehow for 32 bit.
4) We have to cost reduce our work 32 bit.

There are not only commercial distributions. There are people paying developers for fixing the stuff for games. This is not an issue.

Cost reduce work on 32 bit include possible completely dropping it.

Source?

Of course community distributions like debian will face this problem later as the resources the commerical distributions provide disappear from supporting 32 bit will lead to applications and libraries no longer building on particular architectures because they were never tested.

Again there are companies like Valve paying for that development...

Wow, you really try hard to create a problem that doesn't exist

[Weasel]

LOL moron wine it self contains containerisation in what is called WINEPREFIX. Yes even today you still get cases where 2 new windows games from different makers cannot be installed on windows at the same time and run due to conflicting dependency.

That has absolutely nothing to do with the ABI, even more so considering that the .dll files are just fake (until wine 4.10) and the actual .so files that implement the ABI are in one spot only modifiable by root. You're fucking retarded.

Of course, an app can even delete kernel32.dll or mess with another app (imagine a server/client app combination), and so two wine prefixes can prevent this fiasco here. Which has nothing to do with ABI, that's just app isolation. You can get the same shit in Linux by running an app as different users.

[Weasel]

No, we can just stop fucking up the userland.

Short and to the point. Amen. Don't mind oiaohm, he's "special" like that.

[oiaohm]

That has absolutely nothing to do with the ABI, even more so considering that the .dll files are just fake (until wine 4.10) and the actual .so files that implement the ABI are in one spot only modifiable by root. You're fucking retarded.

NO this post of weasels should have not got a vote. Since first version of wine the following from the man page of wine has existed:

WINEDLLOVERRIDES
Defines the override type and load order of dlls used in the loading process for any dll. There are currently two types of libraries that can be loaded into a process address space: native windows dlls (native) and Wine internal dlls (builtin). The type may be abbreviated with the first letter of the type (n or b). The library may also be disabled (''). Each sequence of orders must be separated by commas.

That right wine include the means to not use it provided libraries instead use native built libraries. This is required to get particular programs to run due to ABI different in windows.

So the .dll you are using to run windows programs in wine are not always fake with different copy protections there are lot of modified core .dll in the mix.

Wine design as the ABI alterable per WINEPREFIX using Dll Overrides to choose between wine provided version and other sources.

Winetricks have been loading in Microsoft parts over wine provided libraries for a long time to get programs to work. .

Weasel is the moron who keeps on pushing the idea that the WIndows ABI is stable.

https://test.winehq.org/data/

Wine project testsuite is run against windows we know that windows versions ABI don't match. Heck we know that you can have 5+ different installs of the same version of windows and have ABI differences this does make getting programs to work kind of tricky. Wine ABI is in fact basically a average of the different Windows ABIs so we are more than aware that we at times have to override this so applications work.

[oiaohm]

NO this post of weasels should have not got a vote. Since first version of wine the following from the man page of wine has existed:
WINEDLLOVERRIDES
Defines the override type and load order of dlls used in the loading process for any dll. There are currently two types of libraries that can be loaded into a process address space: native windows dlls (native) and Wine internal dlls (builtin). The type may be abbreviated with the first letter of the type (n or b). The library may also be disabled (''). Each sequence of orders must be separated by commas.


That right wine include the means to not use it provided libraries instead use native dll in the wineprefix instead. This is required to get particular programs to run due to ABI different in windows.

So the .dll you are using to run windows programs in wine are not always fake with different copy protections there are lot of modified core .dll in the mix.

Wine design as the ABI alterable per WINEPREFIX using Dll Overrides to choose between wine provided version and other sources.

Winetricks have been loading in Microsoft parts over wine provided libraries for a long time to get programs to work. .

Weasel who keeps on pushing the idea that the WIndows ABI is stable.

https://test.winehq.org/data/

Wine project testsuite is run against windows we know that windows versions ABI don't match. Heck we know that you can have 5+ different installs of the same version of windows and have ABI differences this does make getting programs to work kind of tricky at times. Wine ABI is in fact basically a average of the different Windows ABIs so we are more than aware that we at times have to override this so applications work.

[oiaohm]

The libraries needed by 32bit software are as much used and tested as the libraries used by 64bit software is. There is a ton of 32bit software around, mainly games that are played every day

This not true by the numbers.

https://popcon.debian.org/

Before 2011 32 bit was more tested that 64 bit after 2011 64 bit came more tested than 32 bit. 32 bit usage has been in decline. Systems that can run 32 bit applications are in decline.

The majority of games is 32bit so this is simply not true. A lot of people play games on Linux and every major Linux distribution has multilib support.

Just because I am playing game does not mean I am using 32 bit. Like playing Oad, Wesnoth, Quake3 these are all 64 bit games.

Yes all major distributions have multilib support. Most when you do a 64 bit install don't enabled it. So when you go into package manager and search for games you are shown 64 bit games.

Majority of games installed by debian popcon numbers are pure 64 bit versions. Linux users are installing more 64 bit games than 32 bit games by the stats data you can collect.

Yes the majority of games available might be 32 bit. Linux world stats have the majority of games installed by Linux users as 64 bit games. With the majority of those with 64bit Linux installed don't have multilib installed.

Basically ZeroPointEnergy try again but this time try some say something that matches the statistics of the Linux world.