-
Posts
452 -
Joined
-
Last visited
Content Type
Forums
Status Updates
Blogs
Events
Gallery
Downloads
Store Home
Everything posted by Chunchunmaru_
-
UPDATE: Ubuntu NOT Dropping 32-bit App Support After All
Chunchunmaru_ replied to matrix07012's topic in Tech News
I am a bit skeptical about this, that means different things 1) Unupdated 32bit libraries mean, unupdated mesa drivers, both OpenGL an Vulkan, with: new features and bugfixes, security updates, and pretty much critical bugfixes for DXVK/D9VK which requires an almost edge-updated Vulkan driverr - DXVK always recommends you to be using the latest vulkan drivers - NVIDIA GPU's are not affected with this, as long you use the correct repository, but in general It's unclear to me how they are going to ship 18.04 32bit libraries to the nvidia proprietary driver???? Doesn't make sense at all since they directly package from the NVIDIA website the driver for every driver update They do not even compile it, they just extract the libraries and DKMS. And they said they will just leave 18.04 32bit libraries??? 2) In general mixing different 32bit and 64bit library versions can make things working unexpectedly, and in the future could break functionality 3) Wine ABI could, or will surely break, mixing different 64bit and 32 bit version can cause unexpected things on Wine WoW64 installations which rely on both 32bit and 64bit, and mixing different libraries versions and updates is not going to help, even on snap and flatpaks (which anyway requires 32bit libraries from the root lib directory itself) and honestly by myself I don't use neither snap or flatpaks due to limitations in usability But it could probably not even compile at all on those platforms because of headers version mismatch It's not clear if they are building Wine with multiarch support at all because of this, I think not, Wine folks already addressed they won't personally but I guess time will just tell. Probably Canonical will just build a 64bit only Wine version (pretty much useless) 4) Just hope they will at least fix critical bugs, security updates in libraries like openssl, pulse and alsa really mean something, it's really odd they are shipping those at first just for "compatibility" they open a LOT of security holes 5) apt will surely complain about different libraries versions in the system when trying to install some software that doesn't satisfy it's requirements I also honestly think that all this fuss will just be a reason for people and primary gamers to just sticking back in Windows The only decent solution to this is just not a PPA, but a centralized repository with auto-builds and signed packages which I hope projects like PopOS or mint will offer, in that case probably gaming wouldn't be dead at all -
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.
-
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 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.
-
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
-
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
-
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 Maybe that was a worth statement for someone like Microsoft, at this moment Linux desktop distributions must rely on Wine for decent software support and everything done as a lesson to lazy developers is just making them laugh. This is not a discussion whether or not is right to deprecate an old architecture because the answer is simple On Linux it will just hurt the user base Good luck building a project with wine all static LMAO, how do you expect integrating video, audio and userspace drivers? And if I don't get wrong, wine cannot be build under static by design, 6 years ago I was in their devel about a similar question
-
You didn't get my point... 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 And by default the design is pretty crappy, for unsupported graphics chipset the nouveau driver comes in even when it's not remotely supported instead of the vesa driver, which would let you install an updated kernel with working drivers Oh unless people want to dig with the CLI
-
As I said decent Nvidia Optimus support on laptops... Most laptops out there basically Bumblebee present on other distros: buggy, no GUI, no Vulkan (so dxvk) support, and not officially supported by Nvidia That's why it's just harmful to Linux usability in general, there is no point of choosing it for gaming instead of Windows unless you want your life complicated, it wasn't that much before at this point honestly...
-
Nope, it's not just 32bit support, it's 32bit support on 64bit called Multiarch, WoW64 on Windows Yeah pretty much my thought, but this should be happen only when Windows does this first as Steam Play focuses on Windows gaming and it's pretty common to find 32bit dependencies Also, 64bit only wine is useless... The amount of windows programs working without 32bit deps is very small, also some winetricks and net 2 requires 32bit as well
-
Summary: Ubuntu recently announced to be dropping 32bit library support in the upcoming versions starting from 19.10 as already discussed in this forum On a tweet, a Valve developer contrary to what was known before, they were working with Ubuntu to eventually release a compatibility library in their runtime, said: And valve is not the only one being so harsh to Ubuntu, even CodeWeavers, the company behind Wine the Windows emulator, which mainly supports 32bit only, said they were not going to build for Ubuntu and make a compatibility layer because of inconsistencies with the different 64bit system libraries that would make My opinion: As I already addressed in the previous thread, even if basically no one understood what I meant and why I was so skeptical about this, I expected this to be happening. The Linux world has already issues on their own for desktops and since it depends on windows especially for gaming, and Microsoft is not going to drop 32bit anytime soon, I was almost sure this would hurt. I was also being told Windows installers have a LOT of 32 bit dependencies generally. As neither Wine or Steam is going to officially support Ubuntu, it's all in the hand of the community to do (or not) something about, that would probably take a reasonable amount of time causing harm to users. For some people not using Ubuntu is not an alternative. Ubuntu is the most supported distros at all, and seeing those big giants dropping support for it is certainly not good, this fragmentation is not going to help at all, I would like to be optimistic like the folks in the previous thread but we'll just see what will happen in the future I guess. I highly doubt since I'm present and interested basically all development groups related to gaming, the resources are actually focused on other things which tbh really matter. LTS would also not be the solution to everyone, as new graphics card are going to be out soon, the support on it is not going to be backported to the LTS soon and means most likely they won't even boot. Same applies on laptops, and Ubuntu is the main supported distro by NVIDIA for easily switch between graphics card in Optimus laptops. And it's the only way to get Vulkan to work on Optimus since Bumblebee doesn't officially support Vulkan, and it's old and pretty much buggy (it's the solution present on Manjaro) I also think generally is ok telling people to stop shipping 32bit dependencies on their programs, but Linux is not ready to this, making life harder to developers and consumers, is not widespread on desktop as it deserves to be and is should be the last one to be dropping support for it, especially since I already said depends on Windows. Like it or not, this is going to create problems and would be again behind Windows as an alternative before this situation would be improved, and considering the 19.10 release its only a matter of 3 months, time will just tell us. Creating a solution in this case for a thirst party as I already said in another threads, is a cost which requires funding for storage and build farms, for only basic support I don't think 3 months are enough honestly. Also, this is not simple as it looks to address making less issues to users. EDIT: I also forgot that programs cannot just ship their own Mesa drivers, as having different 32/64 bit drivers can lead to ABI break (probably) but I'm almost certainly sure it's the case for NVIDIA drivers, as they are not Mesa and use a different libGL from open source drivers... Source: https://www.phoronix.com/scan.php?page=news_item&px=Valve-Dropping-Official-Ubuntu
-
Uhmmm.... Looks like Valve is not going to officially support Steam for Ubuntu starting from the 19.10 version.... SteamOS time again? Who said I was being to harsh about this and things would go solved really easily? This means all people can rely of is the community, and could mean we could have wait a lot of time and not have support at all https://www.phoronix.com/scan.php?page=news_item&px=Valve-Dropping-Official-Ubuntu
-
There is no need to use one on it, but it's still vulnerable like an unupdated windows pc just do security updates
-
I mean it's pretty reasonable and makes sense for deployers... Oh anyway Wine developers already addressed as they don't have the intention to manually ship 32bit libraries in their builds for Ubuntu 19.10, looks like I was at least a bit right to criticize this sudden decision, I expected not everyone would agree at this (read the mailing list) https://www.winehq.org/pipermail/wine-devel/2019-June/147869.html Also as I said, they agree mixing 32 and 64 bit libraries in different versions us not going to work And DXVK developers are just also mad as well
-
This, but so far they are the only one making that decision A lot of distros already deprecated 32bit only installations which was the right thing to do only imo, and are all community projects, Ubuntu only supports 64bit and arm too, some distributions with less revenue like Debian develop and maintain 5 as much architectures So really I this point idk, whatever. I just hoped them to wait time at least instead of sudden decisions, as you said they could have announced this one year before To be clear, that was already addressed 3 years ago, but they didn't come up to a conclusion
-
To be honest the only thing I see about canonical leading this decision is making more money, they are competing against clouds services after all and it's not like desktops are their concern at all... supporting i386 also means offering builds and storage Ubuntu phone was a failure, as unity and Mir (which was actually a good project anyway)
-
I just thought some ideas by myself for addressing this I had in mind to create an automated build system like it already happens for some PPA autobuilds for the basic 32bit libraries synchronized with their Ubuntu counterpart, but will still need help for eventual build errors to address but I don't probably have the resources to do that alone, so I hope I give some ideas to someone, to get the repo easily installed and signed, would require just a Deb package with the key on it, the sources.conf in /etc/apt/sources.d/, and for the postinstall just the command to enable i386 dpkg. That would be just one click it be installed and will already show i386 libraries after the apt update.
-
Lol I would put some memes here, I don't know if you ever compiled wine but already it's been a nightmare from years... I could give details on that if it will be, that would require some time and I'm almost 70% sure as it always happened to get support late on it for projects like those, wine has other things to care rather than compatibility for distributions, like they also offer some binaries but most of the time are outdated. Even if there is the LTS I'm pretty sure this is not going to be harmful, as I said before not everyone wants and can use it, especially for newer hardware support. Unless they release a new LTS with backported drivers, which I hope will happen. I think the main concern of a distro developer is to simplify things, not getting things harder, you want people to use you, not to hassle with alternatives even for good reasons like making developers stop using 32 bit. (which for Linux, won't anyway soon)
-
The fact is for Linux is a bit different matter imo, to get adopted it has to be easier to use, not to install thirrd party repos, or compatibility layer or other lxd containers to get full application support (which is at the current time with both 32 and 64bit sufficient) which ok should be the standard in 2019 but considering for gaming also depends on 32bit windows support, this will just damage end users who don't want hassle with their OS. That's my main concern at all and damages Linux in desktops tor everyone
-
Well...I can just tell you discord developers just led an insane bug unresolved for months where pressing alt would crash the application, at least in the end they solved that. Linux Is and will always be low priority except for open source projects I just think that there will be the need of some other time differently from other operating system with more market share to be at the same level. I don't know how much That's why I said this is not what an OS with few market share needs, I could have accepted that for something like Windows
-
I do still think that for Apple and apple developers are going to manage things better, they also announced this 1 year before For ubuntu is just one distribution, and ok you can still use the LTS but not everyone will be using LTS especially for new hardware, where some GPU do not have support even for installs Also linux distributions pretty much depends on wine for program support, which most of the time is 32 bit because windows is still using it, Apple has most of the time their own counterpart and better support at first from developers, and the company itself behind actually cares about the user base
-
I don't think 32 bit gpu's even exist... Maybe you refer to 32 bit drivers? But even in this case it's a different thing, kernel drivers could be 64bit only as far I know, the Linux kernel drivers does not require 32 bit kernel drivers for 32 bit apps but anyway I'm pretty sure GPU have their own instruction set, what in this specific case GPU-related will be missing are OpenGL and Vulkan implementations and userspace drivers for interface with 32bit applications