Valve going to end official support for Ubuntu starting from 19.10

[Chunchunmaru_]

2 hours ago, Sauron said:

Arch hasn't supported 32bit libraries out of the box for years.

 

It's almost as though this doesn't actually mean you can't run 32 bit software if you really need to.

 

But... there already was no reason to use Ubuntu over Windows if all you care about are the games.

 

You can still play half life because it's statically linked.

 

32bit binaries will still be compatible with Ubuntu as long as they aren't dynamically linked to libraries that will no longer be available.

 

I don't think we should chase popularity in exchange for progress. Windows is a trash heap in large part due to its retrocompatibility constraints.

Arch is not an user friendly distro at all, you need to configure it

 

They have not deprecated mutliarch, you can just enable it manually

 

Manjaro does btw

 

Half life cannot be static linked with graphics and audio drivers

 

But windows still works, isn that better?

I notice that by myself, windows is a pile of crap anyway but... If I can't get my work easily done on my operating system I'm not fixing their mess

 

[Sauron]

18 minutes ago, Chunchunmaru_ said:

Arch is not an user friendly distro at all, you need to configure it

That's not the point. The point is that Steam and Wine are both available and work just fine on Arch - why would it be any different for Ubuntu?

18 minutes ago, Chunchunmaru_ said:

They have not deprecated mutliarch, you can just enable it manually

A distinction without a difference. If you need it you can add it, just as you'll no doubt be able to do with a third party PPA on Ubuntu.

20 minutes ago, Chunchunmaru_ said:

Manjaro does btw

As will some Ubuntu derivative. All it takes is to ship it with the multilib PPA enabled.

21 minutes ago, Chunchunmaru_ said:

Half life cannot be static linked with graphics and audio drivers

That's not a problem as long as gpu and audio drivers don't rely on 32bit libraries, which they don't. You don't need multilib to install amdgpu or the nvidia driver on Arch, I'm pretty sure the same goes for every other distro. Plus I believe the interface the drivers offer is architecture agnostic, though I could be wrong.

27 minutes ago, Chunchunmaru_ said:

But windows still works, isn that better?

I notice that by myself, windows is a pile of crap anyway but... If I can't get my work easily done on my operating system I'm not fixing their mess

It's up to you to decide if you think Windows is worth tolerating over adding a PPA with one command. Or just using another distro.

[Chunchunmaru_]

43 minutes ago, Sauron said:

That's not a problem as long as gpu and audio drivers don't rely on 32bit libraries, which they don't. 

Kernel drivers are a different thing compared to userspace drivers...

 

32bit binaries need to interface with 32bit userspace drivers before getting into the kernel 

 

Btw I don't think a simple ppa is able to satisfy such need because it has some limitations 

[Sauron]

2 minutes ago, Chunchunmaru_ said:

Kernel drivers are a different thing compared to userspace drivers...

 

32bit binaries need to interface with 32bit userspace drivers before getting into the kernel 

I think those can be statically linked though

[dalekphalm]

2 hours ago, Chunchunmaru_ said:

They just said they won't

 

canonical won't either as they are not even thinking of building for i386 anymore

 

is good for people to going back to windows tbh 

Wine said that they won’t - but that’s not Canonicals fault - that’s the Wine dev teams fault. 

 

Canonical made the right call, and once they get past the transition period, they will be ahead of most of the other distros. 

 

[Guest]

6 hours ago, TetraSky said:

It's 2019... What reason is there to still run a 32bit only OS in this day and age? Other than reviving old hardware? It's about time for softwares and games to be made with only 64bit in mind instead of cutting corners with 32bit dependencies just because a small minority of users are still on 32bit hardware/OSes only.

 

There's isn't even 2% of users still on 32bit windows on Steam. And none at all on 32bit Linux, or at least, according to the numbers shown by steam hardware survey. It'd be about time they upgrade. I get that some older games might not play nice with newer hardware/64bit OSes, but there's usually some workaround for those. Like emulators or virtual machines. 

 

Couldn't Ubuntu just put the 32bit dependencies in a separate optional package, to give users the option to have a lightweight 64bit only OS without those?

The trouble with WINE is that for some reason 32-bit runs much more smoother and playable than 64-bit.

[Chunchunmaru_]

3 minutes ago, floofer said:

The trouble with WINE is that for some reason 32-bit runs much more smoother and playable than 64-bit.

Wine officially supports 32bit, even for MacOS

 

But the fact MacOS is not fragmented like Linux distributions, they probably ship libraries with no issues whatsoever

[Guest]

3 minutes ago, Chunchunmaru_ said:

Wine officially supports 32bit, even for MacOS

 

But the fact MacOS is not fragmented like Linux distributions, they probably ship libraries with no issues whatsoever

There’s not 32-but support in MacOS either, but 32-bit programs tend to be much more stable in WINE than 64-bit (Using the same program and 32-bit and 64-bit versions of WINE)

[colonel_mortis]

4 hours ago, Captain Chaos said:

Here's the thing though: AFAIK Debian still has 32bit support, even in their 64bit installs.  Seeing as Ubuntu is based on Debian, this move means that Cannonical actually has to spend time and resources to remove the 32bit support from the OS they start with.   

I understand if they feel that their OS is bloated, because it clearly is.  Anyone who has recently used Ubuntu will have to admit that Ubuntu 14 was the last good version.  I can only applaud them for actually trying to slim it down again.  However removing 32bit support isn't going to solve the problem because the problem is caused by all the other crap they added over the years.

AFAIK the change is that Canonical will no longer build 32 bit libraries or distribute them through official channels. They aren't actually making changes to the OS itself - if you have the dependencies then you will be able to run 32 bit programs on a 64 bit OS install without problems, they just won't be providing the dependencies to do so. That means that all Steam (and the games) just need to bundle or otherwise provide the 32 bit libraries, and it will work correctly.

 

I don't understand why Valve don't just build a 64 bit version of steam though, like pretty much every other program on my linux install. Although it might be slightly more complicated for them than just a compiler flag, it can't be much more complicated. The only reason that I could think of was that perhaps games don't have 64 bit support, but all the games that I tested from the ones I currently have installed are 64 bit, and they bundle the required libraries anyway so they will work fine on Ubuntu after this change anyway. Proton is 64 bit too.

 

I'm sure they have a reason, but I'm really struggling to see what it is.

[PocketNerd]

Hold on, I thought 64-bit was capable of running 32-bit applications through natural backwards-compatibility?

[Jito463]

1 minute ago, PocketNerd said:

Hold on, I thought 64-bit was capable of running 32-bit applications through natural backwards-compatibility?

The hardware is, but the software/OS still has to support it.  It's theoretically possible for 64-bit Windows to support 16-bit applications (since 16-bit is backwards compatible from 32-bit), but the OS support just isn't there.  That's the same thing that will happen to 32-bit once Canonical drops those libraries from their Ubuntu distribution.

[leadeater]

6 hours ago, Chunchunmaru_ said:

LTS ship with LTS kernels, and support from new hardware comes only with backported which takes time, and they don't refresh the ISO anyway that frequent 

There is no delay, all repos get updates at the same time, Nvidia doesn't release drivers piecemeal and an older Kernel won't not boot with an unknown graphics device, fallback layers.

 

Ubuntu doesn't just put on any old graphics driver, you do actually have to install them and when is the last time a current branch repo and LTS repo not been updated at the same time with the current Nvidia driver release?

[Nowak]

1 hour ago, colonel_mortis said:

I don't understand why Valve don't just build a 64 bit version of steam though, like pretty much every other program on my linux install.

Probably the same reason that Steam (specifically the client bootstrapper and service) is still 32-bit on Windows.

[Sauron]

26 minutes ago, PocketNerd said:

Hold on, I thought 64-bit was capable of running 32-bit applications through natural backwards-compatibility?

Yes, however to avoid huge binaries people use dynamically linked libraries in their programs; these are basically libraries that aren't compiled into the executable and are expected to be present on the operating system. If you use 32 bit libraries for this, those libraries will expect 32 bit address spaces while 64 bit libraries use 64bit address space. This means that calls meant for 32 bit libraries are incompatible with the 64 bit counterparts. This isn't a problem with statically linked binaries where everything needed is bundled in the executable.

[Chunchunmaru_]

27 minutes ago, leadeater said:

There is no delay, all repos get updates at the same time, Nvidia doesn't release drivers piecemeal and an older Kernel won't not boot with an unknown graphics device, fallback layers.

 

Ubuntu doesn't just put on any old graphics driver, you do actually have to install them and when is the last time a current branch repo and LTS repo not been updated at the same time with the current Nvidia driver release?

I am not talking about the repo, when you download the actual image installer, it's a lot of months older and is not refreshed with every update, so it does come with unupdated graphics drivers as they come with the kernel version

 

And Nvidia driver release it's not related at all, by default Ubuntu uses nouveau anyway which isn't directly supported or maintained by Nvidia and it's all reverse engineered

 

On AMD gpus is a different story, they update the initial graphics support a whole year before into the kernel so it will surely be supported by the LTS at least for basic boot

 

Manjaro so far is the only distro who comes with proprietary drivers in the installer, so the issue here is less noticeable even on old releases 

[Sauron]

1 minute ago, Chunchunmaru_ said:

I am not talking about the repo, when you download the actual image installer, it's a lot of months older and is not refreshed with every update, so it does come with unupdated graphics drivers as they come with the kernel version

 

And Nvidia driver release it's not related at all, by default Ubuntu uses nouveau anyway which isn't directly supported or maintained by Nvidia and it's all reverse engineered

At worst it should revert to the mesa driver, it shouldn't ever get to the point where the installer can't boot.

[Dabombinable]

What about Debian itself? Won't that still support 32bit apps?

Edit: Start using Ubuntu's base (Debian) instead. Works with the same apps, and at the very least there'll be support for 32bit until 2022 - if not well past that:
https://wiki.debian.org/LTS

[colonel_mortis]

31 minutes ago, Nowak said:

Probably the same reason that Steam (specifically the client bootstrapper and service) is still 32-bit on Windows.

It does simplify the packaging process (no need to produce multiple binaries), which I guess is quite a significant reason. However, I imagine that the intersection between people running Steam and people running a 32 bit OS in 2019 is extremely small, so it seems to me like it would be easier for them to switch to compiling for 64 bit, at least on Linux, than to switch target distro (32 bit Linux Steam users << Ubuntu Steam users).

 

There will probably be unofficial third party packages for Steam on Ubuntu, as there are for other platforms (eg I use Steam on Fedora, which is maintained by a third party and requires extra RPM repositories), but unless it's on the Ubuntu store/in the default apt repositories, the added friction will definitely put people off switching to what is otherwise quite a good distro for people to convert to.

[Chunchunmaru_]

19 minutes ago, Sauron said:

At worst it should revert to the mesa driver, it shouldn't ever get to the point where the installer can't boot.

Never happened to me, so far Udev checks for the device PCI ids and automatically prioritizes KMS + nouveau, and doesn't know if it's going to boot at all (it's not clear to me why they push patches with the udev match support before stable support)

 

The only way is to use nomodeset boot flag which surely gives a working environment

 

5 minutes ago, colonel_mortis said:

It does simplify the packaging process (no need to produce multiple binaries), which I guess is quite a significant reason. However, I imagine that the intersection between people running Steam and people running a 32 bit OS in 2019 is extremely small, so it seems to me like it would be easier for them to switch to compiling for 64 bit, at least on Linux, than to switch target distro (32 bit Linux Steam users << Ubuntu Steam users).

So far even if Steam itself comes with 64bit, steam play support (wine) relies on 32bit, and wine games as well will still make 32bit calls,

it's not totally clear to me if putting graphics and audio drivers as steam runtime, I have my doubts it will break ABI someway... But so far canonical/valve doesn't intend to do so, probably some community effort is going eventually to come out with a solution.

I just hope it cares about being easy to install.

[SenKa]

10 hours ago, Chunchunmaru_ said:

Wine the Windows emulator

Wine

Is

Not

(an)

Emulator

[Chunchunmaru_]

4 minutes ago, SenpaiKaplan said:

Wine

Is

Not

(an)

Emulator

Does Wine the Windows-Like compatibility layer system API emulation for Unix-Like systems sound that more suitable?

[Sauron]

18 minutes ago, Chunchunmaru_ said:

Never happened to me, so far Udev checks for the device PCI ids and automatically prioritizes KMS + nouveau, and doesn't know if it's going to boot at all (it's not clear to me why they push patches with the udev match support before stable support)

 

The only way is to use nomodeset boot flag which surely gives a working environment

Huh, in that case I guess they could update the installation image down the line. Still, the workaround is pretty easy.

20 minutes ago, Chunchunmaru_ said:

So far even if Steam itself comes with 64bit, steam play support (wine) relies on 32bit, and wine games as well will still make 32bit calls,

Actually the FAQ says Steam itself ships the required libraries directly in the installer so that shouldn't be a problem; as for the games themselves Canonical is working with Valve to resolve the issue. It should just be a matter of including the required libraries with the game download. I strongly doubt it will be a big deal.

 

Also wine is on flathub if it ever comes to that.

[mr moose]

2 hours ago, colonel_mortis said:

I'm sure they have a reason, but I'm really struggling to see what it is.

It's probably just money, too few people using it. 

 

 

[Chunchunmaru_]

59 minutes ago, Sauron said:

 

Actually the FAQ says Steam itself ships the required libraries directly in the installer so that shouldn't be a problem; as for the games themselves Canonical is working with Valve to resolve the issue. It should just be a matter of including the required libraries with the game download. I strongly doubt it will be a big deal.

 

Also wine is on flathub if it ever comes to that.

But if you notice it's the steam package itself that has dependencies, and a lot of them are i386, don't look at the runtime ones

 

One should try to experiment with them on an isolated environment with an amd64 chroot or Ubuntu

 

As for flatpak and snaps their dependencies are isolated from the rest of the system and cannot be used outside, they are meant to be exclusively used on their own container, so what will work here is just wine being called from other programs, which could happen on Lutris, but not on Steam Play which relies on the system ones

 

Also, I still don't think OpenGL, Audio and Vulkan 32 bit libs are even included, you could check the snap/flatpak

 

I still have doubts this will break some ABI compatibility

 

EDIT: I mostly forgot the most important thing like a dumb, NVIDIA has their own libGL, so the system is an important choice here.... They cannot just bundle their own Mesa library.

 

This is a pretty huge problem.

[Drak3]

49 minutes ago, Chunchunmaru_ said:

Does Wine the Windows-Like compatibility layer system API emulation for Unix-Like systems sound that more suitable?

Technically, yes.

 

But Windows compatibility layer rolls off the tongue easier.