14 ms·
i386 in Ubuntu won't die
- ladyanita22 3y agoSometimes I sympathize with the snap developers to be honest
- amelius 3y agoReally? Yesterday I tried to open GIMP over a remote SSH connection to quickly edit something. Turned out that it couldn't open the display because snap doesn't work over remote connections ... Imho, the least they can do is get the basics right. Of course, it's Canonical's fault for pushing something that is not ready for the real world.
- rany_ 3y agoIt's probably because the env from the host system is sandboxed. You should explicitly set the DISPLAY somehow when you run the snap
- amelius 3y agoThat's strange because xeyes (not a snap app) worked just fine, so $DISPLAY was certainly set.
- sph 3y agoThat's because xeyes is not sandboxed, snaps are. They don't automatically inherit the environment.
- chasil 3y agoWould it be as simple as:? DISPLAY="$DISPLAY" gimp
- sph 3y agoI don't run Ubuntu so I wouldn't know, but the other sandbox system I know, Docker, has its own syntax to set environment variables. It's worth having a look at the man pages. DISPLAY="$DISPLAY" gimp This is a no-op. It sets DISPLAY in the current env with the value of DISPLAY in the current env. Processes spawned from the shell already inherit the current environment (unless they're running in a separate namespace, of course)
- rlpb 3y ago> because snap doesn't work over remote connections Nor does Wayland, which is the default in Ubuntu now.
- raverbashing 3y agoHappy to be proven wrong, but I really don't think Gimp would be usable over X/SSH in anything slower than local LAN. VNC or something similar might be a better choice
- amelius 3y agoFwiw, I was trying to do this over LAN. In fact to a headless machine in the same office. This kind of basic thing should just work. I use VNC all the time, but sometimes it is just more convenient to use a remote X connection.
- deleted 3y ago[deleted]
- hnfong 3y agoIt was 20 years ago, I tried running GIMP over remote X on a 100base-T LAN. It was pretty much un-useable. Granted modern day Gigabit networks might have made it more palatable, but I suspect with all the modern UI toolkit assumptions about the X server being on the same machine, the end result is that it will still be worse than an optimized VNC. As a comparison, windows remote desktop on the same network was pretty snappy at the time.
- amelius 3y agoVery true, but there is no excuse for prioritizing performance over correctness.
- loloquwowndueo 3y agoUm the L in LAN stands for “Local”. Sorry I’m from the department of redundancy department just conducting an inspection here.
- raverbashing 3y agoTrue, but actually I wanted to mean that if you're out of the 1st router it might be too slow already (especially for something like GIMP)
- yjftsjthsd-h 3y agoWe can sympathize with the problem they want to solve without agreeing with their proposed solution.
- amelius 3y agoYes if they'd do this inside a research lab far away from regular users.
- hedora 3y agoI wonder how long it will take for people to claim X11 doesn’t support remote displays (in the same way they claim it doesn’t support high DPI displays).
- bakugo 3y agoGlad to see the Ubuntu devs decided not to make the same mistake as Apple, a lot of recent desktop linux adoption is being driven by Steam and its huge library of Linux-compatible games.
- planb 3y agoI thought exactly the opposite. Why keep all the old clutter around just for some edge cases that can easily be resolved by virtualization?
- ant6n 3y agoBecause lot of recent desktop linux adoption is being driven by Steam and its huge library of Linux-compatible games. I wonder though, whether with GeForce (etc), streaming games from the cloud, the local OS becomes even less important after all. Even a MacBook could be a decent gaming laptop (the hardware is already a superb gaming laptop, just apple keeps the software crippled).
- jeroenhd 3y agoIf Steam doesn't work on Ubuntu, Ubuntu may as well kill off what remains of their consumer desktop product. Barely anyone uses Linux at all, and 9f the few people that do a significant amount of people like to play a video game on their computers every once in a while. Based on the Steam hardware survey and the number of Steam users, I'd estimate about 8 million people would suddenly lose the ability to play games. Many of them would go back to Windows. Others would move to another Linux distro. Either way, Ubuntu would make a lot of people mad.
- ungamedplayer 3y ago]barely anyone uses Linux at all The steam console runs Linux. Android runs a Linux.
- IshKebab 3y agoIt was clear from the context that he was talking about traditional Linux desktops with Gnome, KDE etc; not systems that happen to use the Linux kernel as a base but are otherwise completely different. (That's the case for Android at least; I'm not sure about the Steam Deck.) Android could swap out Linux for some other kernel (e.g. Fuchsia) relatively easily and users wouldn't notice. Google already did that with the Nest Hub.
- BirAdam 3y agoI just want to point out something a bit pedantic, but I feel is an important distinction: Linux community and devs need to stop saying i386 and say i586 or even i686 as this is closer to what is meant. Linux doesn’t support 386 anymore, you can make it work on 486 but most distributions don’t enable support for this. Pentiums (586) are usually the minimum and some even push toward Pentium MMX/Pentium II which would be 686.
- rurban 3y agoTell that the big vendors. Only mingw AFAIK ships i686 packages (with simd support), all others stay in the safe i386 camp still, without simd support.
- westurner 3y agoGentoo ebuild USE and CFLAGS flags allow the user to specify custom compilation settings as necessary for optimization on a given processor architecture like i386, i486, i586, or i686. For example, with ebuild (or dpkg-repack or rpmrebuild) a person could build the compiler packages with all of the appropriate optimization flags for the chipset on the box where the package will be installed: https://packages.gentoo.org/useflags/custom-cflags https://packages.gentoo.org/useflags/custom-cflags Cross-compilation is easier with clean build containers. With distrobox (and qemu, qemu-user-static, and binfmt-support) https://github.com/89luca89/distrobox/blob/main/docs/useful_tips.md#using-a-different-architecture https://github.com/89luca89/distrobox/blob/main/docs/useful_... : $ uname -m x86_64 $ distrobox create -i aarch64/fedora -n fedora-arm64 $ distrobox enter fedora-arm64 user@fedora-arm64:$ uname -m aarch64
- zokier 3y agoAfaik Debian is fully i686 these days: https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#i386-is-i686 https://www.debian.org/releases/stable/i386/release-notes/ch...
- dralley 3y agoFedora ships i686 packages. At least that's what they're called.
- jchw 3y ago> Plenty of other pieces of software such as WINE only work when 32-bit libraries are installed on a 64-bit system. Funny to mention Wine specifically; they're implementing a more sophisticated Wine-on-Wine64 setup that, among other things, will make having 32-bit system libs unnecessary, through the power of Heaven's Gate, not unlike how Windows handles syscalls in real WoW64. (As far as I understand it, Linux, having a stable syscall interface, just supports the old software interrupts for 32-bit syscalls, making this unnecessary. In fact, they seem to even work from a 64-bit process to some degree.)
- hef19898 3y agoI had some weird issues with Ubuntu 22.04, the OEM Steam Installer and some missing 32-bit library. Steam required it, everytime I tried to install it it broke somethong, mostly WiFi. No idea why, and I am no expert, not even close.
- Dalewyn 3y ago>will make having 32-bit system libs unnecessary, ... , not unlike how Windows handles syscalls in real WoW64. WoW64 literally has an entire 32-bit equivalent to Windows's native 64-bit libraries and binaries.
- jchw 3y agoI should've known better than to be vague here. I'm talking about just syscalls. Windows differs from Linux in that Windows doesn't have backwards compatibility for the kernel ABI but the userspace ABI; all of the syscalls HAVE to be dispatched by NTDLL, because the syscall numbers are not stable between kernel versions anyway. (Not that this entirely stops crapware like anti-cheat from doing so, but nonetheless.) From my point of view, the closest Wine equivalent of a "syscall" would be calling out to UNIX system libraries, so it does bear some similarities even if it's not quite the same. I don't personally want to open WOW64 NTDLL in IDA because doing so would probably limit me from contributing to Wine, but my understanding is that WOW64 NTDLL is just thunks to Win64 NTDLL, using an intermediate library (one of the wow64*.dlls presumably?) to perform a Heaven's Gate call into the 64-bit NTDLL.
- SomeoneFromCA 3y agoi386 will not dies in Ubuntu because it is not dead in Debian. Once it is dead in Debian, it'll die in Ubuntu too.
- remram 3y agoWhy do you think that? They decided to drop it before, as pointed out in the article: https://lists.ubuntu.com/archives/ubuntu-announce/2019-June/000245.html https://lists.ubuntu.com/archives/ubuntu-announce/2019-June/...
- SomeoneFromCA 3y agoI mean, my point was is that they are free to drop earlier than Debian will, but if Debian drop they will not maintain it by themselves.
- remram 3y agoThat makes sense, but it's the opposite of what you did say.
- zokier 3y agoEventually all Steam games will need to run in containers or something similar to manage the dependecy hell, expecting the host system to have some collection of libraries in compatible versions is just recipe for disaster.
- deleted 3y ago[deleted]
- Dalewyn 3y agoExcept Windows by and large satisfies that expectation. Linux throwing backwards compatibility and stability out the window is one of the biggest reasons it doesn't appeal to the common user. Note that Android provides this (granted less than Windows does), and we see common people use Android. And before you mention it: Yes, I know Linus Torvalds is (sort of) adamant about backwards compatibility; the problem is the rest of Linux does not and will not care.
- c0l0 3y agoThat "rest of Linux" that you talk about is not Linux at all.
- jadamson 3y agoWhat's another term you think they should use?
- c0l0 3y agoMaybe "commonly encountered Free Software desktop and server userspace components"? After all, much of that is what you will also find on BSDs et al., and will give you the same trouble (if any) there. The Linux kernel itself is in fact very, VERY extensively backwards-compatible, which is why I find it particularly unfair (on top of being wrong) to use the label Dalewyn did. It's the installed userspace libraries that aren't - at least not in all cases, but the situation sure has improved a lot over the last decade or so.
- hedora 3y agoNow that Ubuntu is treating 32-bit like a second class citizen (by having an explicit allow-list of 32 bit packages that are required by Steam), can the BSD’s just take the same narrow target and provide good Steam support, or have they already? There are only a few things keeping me on Linux: Steam, Slack and Zoom. I haven’t checked for BSD support for any of that recently, but Slack used to(?) run better in the browser than in their app. Edit: Also native docker, does that still have to live in a vm, windows/mac style?
- AshamedCaptain 3y agoThis is yet another thing I find particularly disappointing of the "open source era". Linux probably has the best hardware support of all OSes out there, having long surpassed Windows itself. However, no other open OS even comes close. I am now as stuck with Linux as I was stuck with Windows.
- snvzz 3y agoi386 will die, and so will x86-64. RISC-V is inevitable.
- olliej 3y agoThis is more “steam remains a crappy app we’re still forced to use for the vast majority of games”. After multiple years it’s still an intel binary on Mac, despite being a chrome wrapper and the Mac games in the catalogue all being native binaries at this point. I would assume if not for the 64bit transition it would still be i386 on Mac as well.