4 ms·

Assuming the GP was using x11, then yeah it's very likely almost all of those things worked fine (depending on how they structured the chroot to include their h

Assuming the GP was using x11, then yeah it's very likely almost all of those things worked fine (depending on how they structured the chroot to include their homedir). The only one that probably doesn't is the URL->browser one, just because the chroot probably wouldn't have access to run the browser directly, even if the right MIME-type/xdg config files were present in the chroot. X11 as a protocol if anything is probably more backwards compatible than windows has ever been, and most of the extensions that enable the things you're asking about have been available for decades. ABI and libc aside xclock from 1996 probably still works on ubuntu 22.04. > Heck, distros should consider automating this when users try to launch old apps, if at all possible. This is more or less what snap and flatpak are trying to do.

Wowfunhappy 5y ago
Isn't the Linux world (slowly) moving away from x11, though? (If you can't tell, I'm not a Linux user, I was many years ago and I'd like to go back some day. These types of library compatibility issues are a major part of what's keeping me away—I want to know that most apps from 15 years ago will still work, and most of the apps I have today will still work in another 15 years.)
- stormbrew 5y ago
  Things are moving to wayland, but x11 is never going to go completely away. Xwayland provides an xserver that can be used within wayland. Some of the things you listed as problems would be problems anyways in wayland, because they have to do with the fact that wayland doesn't, for example, give unrestricted access to every single program's image buffer from any program (for good reason).
  - account42 5y ago
    > for good reason For reasons that do not apply to all use cases like local applications that already have full access to ~/.
    - stormbrew 5y ago
      I don't really agree. There's a lot of information on my screen at any given moment that's not usefully represented on disk.
- deleted 5y ago
  [deleted]
dzaima 5y ago
X11 doesn't provide anything for opening a file dialog. afaik you have to just call GTK-specific things to achieve that (hell there's a C library specifically for just opening a file/folder open/save dialog). X11 itself doesn't provide that much beyond opening & managing windows (and the copy&paste mess it provides is, well, a mess.)
- stormbrew 5y ago
  Sure, but the question wasn't "will a file dialog open at all" it was "will it open in a weird place". If the app was using gtk and you're running it in a chroot with period-appropriate gtk that gtk file open dialog will probably open just fine, and then it's a matter of if you bind mounted your homedir and /etc into the chroot so it'd know where to go. From there it'll open in approximately as weird (or un-weird) a place as it did in 2007. Like, this isn't a problem almost specifically because x11 isn't trying to do anything very clever here. There's no OpenFileDialog along with an OpenFileDialogEx and OpenFileDialogExtraArgumentsFor2016Ex APIs to keep going. If your program had a file dialog then, it has one now. It's probably just ugly. As for copy/paste, it is a bit of a mess but it's a mess that works pretty well for this kind of situation. If the copyer and paster windows are in the same x11 context and use the same (widely used) protocol over x11 window properties, they will be able to copy and paste with each other regardless of if they're running natively, in a chroot, in a vm, or on a remote machine. Incidentally I really miss having the second "select/middle click" copy/paste context when I'm using windows or a mac. It's really frickin' useful and by far more useful than almost any other middle mouse button uses I've ever seen in any non-game. But then I also miss having normal copy/paste in the common linux gui terminal emulators so...
- account42 5y ago
  You can now provide a DE-agnostic way to get the "native" file dialogs via xdg-desktop-portal. Granted that is faily new. > and the copy&paste mess it provides is, well, a mess. Still much better than any windowing system that only has a single paste buffer.
heavyset_go 5y ago
Even if they use Wayland, XWayland works flawlessly with X11 applications in my experience, and Plasma/GNOME/etc all load XWayland support by default.

Wowfunhappy 5y ago

Isn't the Linux world (slowly) moving away from x11, though? (If you can't tell, I'm not a Linux user, I was many years ago and I'd like to go back some day. These types of library compatibility issues are a major part of what's keeping me away—I want to know that most apps from 15 years ago will still work, and most of the apps I have today will still work in another 15 years.)

stormbrew 5y ago
Things are moving to wayland, but x11 is never going to go completely away. Xwayland provides an xserver that can be used within wayland. Some of the things you listed as problems would be problems anyways in wayland, because they have to do with the fact that wayland doesn't, for example, give unrestricted access to every single program's image buffer from any program (for good reason).
- account42 5y ago
  > for good reason For reasons that do not apply to all use cases like local applications that already have full access to ~/.
  - stormbrew 5y ago
    I don't really agree. There's a lot of information on my screen at any given moment that's not usefully represented on disk.
deleted 5y ago
[deleted]

dzaima 5y ago

X11 doesn't provide anything for opening a file dialog. afaik you have to just call GTK-specific things to achieve that (hell there's a C library specifically for just opening a file/folder open/save dialog). X11 itself doesn't provide that much beyond opening & managing windows (and the copy&paste mess it provides is, well, a mess.)

stormbrew 5y ago
Sure, but the question wasn't "will a file dialog open at all" it was "will it open in a weird place". If the app was using gtk and you're running it in a chroot with period-appropriate gtk that gtk file open dialog will probably open just fine, and then it's a matter of if you bind mounted your homedir and /etc into the chroot so it'd know where to go. From there it'll open in approximately as weird (or un-weird) a place as it did in 2007. Like, this isn't a problem almost specifically because x11 isn't trying to do anything very clever here. There's no OpenFileDialog along with an OpenFileDialogEx and OpenFileDialogExtraArgumentsFor2016Ex APIs to keep going. If your program had a file dialog then, it has one now. It's probably just ugly. As for copy/paste, it is a bit of a mess but it's a mess that works pretty well for this kind of situation. If the copyer and paster windows are in the same x11 context and use the same (widely used) protocol over x11 window properties, they will be able to copy and paste with each other regardless of if they're running natively, in a chroot, in a vm, or on a remote machine. Incidentally I really miss having the second "select/middle click" copy/paste context when I'm using windows or a mac. It's really frickin' useful and by far more useful than almost any other middle mouse button uses I've ever seen in any non-game. But then I also miss having normal copy/paste in the common linux gui terminal emulators so...
account42 5y ago
You can now provide a DE-agnostic way to get the "native" file dialogs via xdg-desktop-portal. Granted that is faily new. > and the copy&paste mess it provides is, well, a mess. Still much better than any windowing system that only has a single paste buffer.

heavyset_go 5y ago

Even if they use Wayland, XWayland works flawlessly with X11 applications in my experience, and Plasma/GNOME/etc all load XWayland support by default.