Valve Will Not Be Officially Supporting Ubuntu 19.10+

[brad0]

Yeah, they should just forget about all the 32bit games and Proton *sarcasm

If the game isn't maintained then yes. I feel about as bad about that as I do Flash. So long goodbye. Go to the grave. *not sarcasm

Ya, we built these layers to run proprietary apps on top of other layers we knew would go away but we'll cry when the obvious happens. That's beyond stupid. But stupid is everywhere you look nowadays.

[brad0]

That is an order of magnitude harder than maintaining 32bit libs ...

Oh well. It's just never ending excuses why app providers can't do their job properly. The writing has been on the wall for 10+ years. Only 10 years to get their shit together. Gimme a break. No sympathy.

[M@GOid]

Looking in my steamapps folder, many of the Linux games have 32 AND 64 bit executables in the directory. The appid entry on the server side though, has to specify the file the launcher is supposed to run. They're all currently pointing to the 32 bit one, as that works on all installs. If it was set to the 64 bit one, it would fail to launch on any 32 bit system, with no error message.

There may have been some direction for devs to do this, otherwise I wouldn't expect to see so many with both versions installed. They may have planned that one day they would change the server side pointers and the clients would all start launching the 64 bit version instead.

Most third party developers do release 32 and 64 bit executables. But Valve games (Portal 2, Left4Dead 2, etc) only show 32 bit. I believe only CS:GO and maybe DOTA 2 must offer 64 bit.

[Raka555]

In other news today....

Buggy makers and buggy whip manufacturers protested at Ford headquarters over their concerns regarding Ford's plan to roll out the so called "auto-mobile". Joining in the protest were breeders of horses, livery owners, saddle and tack manufactures and the The International Union of Street Sweepers and Horse Poop Pickers.

It is more like Ford deciding to remove wipers from all their cars.
They are only needed when it rains and it put additional burden on the people that assemble the cars.

People wanting wipers an their cars, can keep using the old models...

Then a bunch of people starting arguing that wipers is something that Ford should have done away with 40 years ago, because it is old and useless technology...

But Ford now suggest using some new technology that involves swapping 2 wind shields in and out.
So you can clean the one while the other one is in use. There are 2 competing ways how the swapping can be done.
One is called snaps and the other one flatpak.
They still have some teething problems where people sometimes get wet while the swapping happens. And there are some edge cases where the swapping gets stuck. But the engineers working on these systems are assuring us that they will sort most of the niggles out.
They assure us it is something that should have happened a long time ago and soon we will be free of those unaesthetic wipers that was invented more than 100 years ago.

Many people rejoiced because the new technology is obviously better because its new and now they can finally get rid of those old fashioned wipers...

[Guest]

Are you on drugs?

Have you ever tried using it? By the time you're done with the (easy) install process, you'll know where everything is and where to look for solutions to problems that might arise. Much better than random tutorials with walls of terminal commands normies don't understand, because distro maintainers are trying to shield them from the "horror" of using a terminal to get things done.

[oiaohm]

It is more like Ford deciding to remove wipers from all their cars.
They are only needed when it rains and it put additional burden on the people that assemble the cars.

People wanting wipers an their cars, can keep using the old models...

Then a bunch of people starting arguing that wipers is something that Ford should have done away with 40 years ago, because it is old and useless technology...

But Ford now suggest using some new technology that can be used that involves swapping 2 wind shields in and out.
So you can clean the one while the other one is in use. There are 2 competing ways how the swapping can be done.
One is called snaps and the other one flatpak.
They still have some teething problems where people sometimes get wet while the swapping happens. And there are some edge cases where the swapping gets stuck. But the engineers working on these systems are assuring us that they will sort most of the niggles out.
They assure us it is something that should have happened a long time ago and soon we will be free of those unaesthetic wipers that was invented more than 100 years ago.

Many people rejoiced because the new technology is obviously better because its new and now they can finally get rid of those old fashioned wipers...

Wrong arguement the correct arguement from cars is seat belts.

32 bit programs like games are mostly old and not maintained. So it like driving without any safety using them.

Flatpak, snap, docker are all using cgroups/namespaces ie seat belts.

We have a stack of people seeing that Ubuntu 19.10 has added like a seat belt engine lock where the car will not start without you having the seat belts done up and are getting upset. That is if the Linux kernel in 19.10 still has 32 bit syscalls.

So basically what has been optional feature to use has been made mandatory.

This is the correct car issue. You have the 2038 problem effecting the Linux 32 bit syscalls that means 32 bit Linux programs will need at some point to use time domains to be able to run and time domains are to be set up on a per container base. The security issues of old non maintained 32 bit programs are no joke either so you may want to reduce amount of access to the system those applications get by default and this is again put them in containers.

[Raka555]

Wrong arguement the correct arguement from cars is seat belts.

32 bit programs like games are mostly old and not maintained. So it like driving without any safety using them.

Flatpak, snap, docker are all using cgroups/namespaces ie seat belts.

We have a stack of people seeing that Ubuntu 19.10 has added like a seat belt engine lock where the car will not start without you having the seat belts done up and are getting upset. That is if the Linux kernel in 19.10 still has 32 bit syscalls.

So basically what has been optional feature to use has been made mandatory.

This is the correct car issue. You have the 2038 problem effecting the Linux 32 bit syscalls that means 32 bit Linux programs will need at some point to use time domains to be able to run and time domains are to be set up on a per container base. The security issues of old non maintained 32 bit programs are no joke either so you may want to reduce amount of access to the system those applications get by default and this is again put them in containers.

Don't play games at work

[Danny3]

Thats becouse you in fact got both 64 bit and 32 bit windows dlls installed (it's very large).
They are in different folders on on you harddrive.
Same way that linux distros do it. But now Ubuntu maybe gonna cut away the 32 bit folder.

Thank you for the explanation!

I will need to have a look if Kubuntu developers can undo this imbecile bribery driven decision.
If they cannot put the 32 bit folder back, I'll have to look for another distro that has good KDE Plasma integration and has the 32 bit folder.
Anyway, I think soon Canonical will be the next Nokia

At this point I'm tired of their anti-user practices (Mir, Snap, Amazon leakage, spyware aka data collection, cutting away the 32 bit folder).
If they continue with this ass-kissing for Microsoft, Nividia, I'm done with it. Enough is enough.
Hopefully Solus will finish their KDE Plasma version soon.

[Raka555]

Wrong arguement the correct arguement from cars is seat belts.

32 bit programs like games are mostly old and not maintained. So it like driving without any safety using them.

Flatpak, snap, docker are all using cgroups/namespaces ie seat belts.

We have a stack of people seeing that Ubuntu 19.10 has added like a seat belt engine lock where the car will not start without you having the seat belts done up and are getting upset. That is if the Linux kernel in 19.10 still has 32 bit syscalls.

So basically what has been optional feature to use has been made mandatory.

This is the correct car issue. You have the 2038 problem effecting the Linux 32 bit syscalls that means 32 bit Linux programs will need at some point to use time domains to be able to run and time domains are to be set up on a per container base. The security issues of old non maintained 32 bit programs are no joke either so you may want to reduce amount of access to the system those applications get by default and this is again put them in containers.

I wont be surprised if containers turns out to be the biggest security mistake ever made in computing history.

At the moment the devs of the disto's maintain all the libs and patch them if and when necessary.

Now people are going to distribute all the libraries every app needs in a container with the app at development time.

If they discover a vulnerability in say glibc, the disto patch glibc, everyone updates and restart. End of story.

If you have a 100 containers, each having its own version of glibc, then you have to hope that who ever has built each container would build a new one with the glibc fixed.

I can assure you that is never going to happen. The broken libs will stay in those containers forever or until exploited...

[brad0]

This is the correct car issue. You have the 2038 problem effecting the Linux 32 bit syscalls that means 32 bit Linux programs will need at some point to use time domains to be able to run and time domains are to be set up on a per container base. The security issues of old non maintained 32 bit programs are no joke either so you may want to reduce amount of access to the system those applications get by default and this is again put them in containers.

This is an area I'm glad OpenBSD did the right thing with our 5.5 release (5 years ago). We moved our 32-bit archs over to 64-bit time_t. Non of the bullshit Linux is pulling now. It just reminds me of the garbage fire for large file support.