4 ms·

The kernel ABI barely matters for most things. You'd hope libc wouldn't break. What's important is window managing APIs, graphics APIs, file system structure (y

by dzaima 5y ago

The kernel ABI barely matters for most things. You'd hope libc wouldn't break. What's important is window managing APIs, graphics APIs, file system structure (your program location, user config location), environment variables, preinstalled binaries, and many smaller things (acceptable keyboard shortcuts, registering to open a specific file type, opening a native "open/save file/folder" dialog, etc). Those are a lot less stable and may require using various random libraries or writing code for specific WMs/desktops. It's not fun.

jart 5y ago
The tragedy of the Linux desktop is that its CLI is superb and Chrome works really really well. The year of the Linux desktop happened with Android but sadly all that successful GUI stuff that Google did was never able to percolate back into the FOSS world as a WIN32 alternative. It's a sad state of affairs for Linux desktop app developers, because they've had the wind taken away from them on all possible angles. The only Linux desktop app I can personally remember using in the past year (aside from the terminal and Chrome) would probably be kcachegrind. I wish that we as a community could focus more on building outstanding TUIs (e.g. linux perf, gdb --tui, emacs) since most Linux installs are headless and it makes an app more functionally useful it can be used in a terminal via ssh.
- pjmlp 5y ago
  The CLI is just like any other UNIX/POSIX, and as far as Android is concerned, Linux does not exist for userspace coming from Play Store, including apps written with NDK/AGK[0]. Only OEMs have the ability to directly use Linux, doing so from userspace means using what Google considers as being private APIs. Not to mention that Google could at any moment change it by Zircon, if they could so feel inclined. So Android is hardly the best that Linux could make it as desktop. [0] - Native Development Kit/Android Game Kit
  - unfocussed_mike 5y ago
    > So Android is hardly the best that Linux could make it as desktop. Chrome OS Flex might be interesting when it does, eventually, support the linux environments.
    - pjmlp 5y ago
      Another Pyhric victory where Linux runs in a container WSL style and desktop is a browser.
      - unfocussed_mike 5y ago
        I guess, but I am weirdly fine with this if the desktop can see everything it needs from the container.
        pjmlp 5y ago
        Another proof that only POSIX matters.
- deleted 5y ago
  [deleted]
- xialvjun 5y ago
  We can use [anbox](https://anbox.io/ https://anbox.io/).
- okanat 5y ago
  The year of the Linux desktop did not happen and will not happen, if we consider the actual GNU+systemd+curl+gstreamer+freetype+Wayland/Xorg+Gtk/Qt+.... as the desktop layer. None of those projects have shared goal of actually making a useful system with stable API / ABI. Moreover, there is already quite a bit competition inside like Qt vs GTK. What made Android successful is Google seeing that mess and creating an entirely new operating system, from kernel to especially userspace. Android in a way turns Linux into a system that is much closer to a microkernel based OS. The binder IPC on the kernel side resembles the message passing systems of microkernels and almost all communication, except a couple of system stuff, passes through it. From allocating display buffers to "Share" buttons all of them uses this system. It has nothing to do with classical desktop system nor the Unix "way" of doing things, which is oversimplifying the system layer to the point of almost uselessness. While the build system of AOSP and Android apps gives me shivers, the OS works beautifully and it can be continuously upgraded and be kept secure, if greedy SoC and device manufacturers released driver updates.
  - jart 5y ago
    https://c.tenor.com/srlLdtb35fkAAAAC/starwars-anakin.gif https://c.tenor.com/srlLdtb35fkAAAAC/starwars-anakin.gif
account42 5y ago
> You'd hope libc wouldn't break. glibc is quite good about ABI compatibility - not any worse than Win32. X11 also has a stable protocol. Even with Wayland there is Xwayland for backwards compatibility. OpenGL and Vulkan have stable ABIs. Your program location doesn't matter - unless you are installed via the package manager (in which case the package specifies the location) you can load everything relative to the binary. User config location is gained a new standard for where you should put things to not mess up the home directory but that does not break anything. Old programs can still write to ~/.yourfancydotfile. Evenvironment variables only matter if you wrote your program for them to matter. Preinstalled libraries are irrelevant - ship your own like you have to do on windows for anything that is not part of the base system. Acceptable keyboars shortcuts and standard dialogs are integration concerns and not strictly needed. Not saying that you shouldn't provide DE-integration where that makes sense but that can be done on top of sane fallbacks. Also, there is now a cross-DE API for standard file dialogs: xdg-desktop-portals .desktop files have been standardized for a long time so you should not have problems registering file types - it is of course up to the DE to manage the default and that is a good thing.

by dzaima 5y ago

jart 5y ago

The tragedy of the Linux desktop is that its CLI is superb and Chrome works really really well. The year of the Linux desktop happened with Android but sadly all that successful GUI stuff that Google did was never able to percolate back into the FOSS world as a WIN32 alternative. It's a sad state of affairs for Linux desktop app developers, because they've had the wind taken away from them on all possible angles. The only Linux desktop app I can personally remember using in the past year (aside from the terminal and Chrome) would probably be kcachegrind. I wish that we as a community could focus more on building outstanding TUIs (e.g. linux perf, gdb --tui, emacs) since most Linux installs are headless and it makes an app more functionally useful it can be used in a terminal via ssh.

pjmlp 5y ago
The CLI is just like any other UNIX/POSIX, and as far as Android is concerned, Linux does not exist for userspace coming from Play Store, including apps written with NDK/AGK[0]. Only OEMs have the ability to directly use Linux, doing so from userspace means using what Google considers as being private APIs. Not to mention that Google could at any moment change it by Zircon, if they could so feel inclined. So Android is hardly the best that Linux could make it as desktop. [0] - Native Development Kit/Android Game Kit
- unfocussed_mike 5y ago
  > So Android is hardly the best that Linux could make it as desktop. Chrome OS Flex might be interesting when it does, eventually, support the linux environments.
  - pjmlp 5y ago
    Another Pyhric victory where Linux runs in a container WSL style and desktop is a browser.
    - unfocussed_mike 5y ago
      I guess, but I am weirdly fine with this if the desktop can see everything it needs from the container.
      - pjmlp 5y ago
        Another proof that only POSIX matters.
deleted 5y ago
[deleted]
xialvjun 5y ago
We can use [anbox](https://anbox.io/ https://anbox.io/).
okanat 5y ago
The year of the Linux desktop did not happen and will not happen, if we consider the actual GNU+systemd+curl+gstreamer+freetype+Wayland/Xorg+Gtk/Qt+.... as the desktop layer. None of those projects have shared goal of actually making a useful system with stable API / ABI. Moreover, there is already quite a bit competition inside like Qt vs GTK. What made Android successful is Google seeing that mess and creating an entirely new operating system, from kernel to especially userspace. Android in a way turns Linux into a system that is much closer to a microkernel based OS. The binder IPC on the kernel side resembles the message passing systems of microkernels and almost all communication, except a couple of system stuff, passes through it. From allocating display buffers to "Share" buttons all of them uses this system. It has nothing to do with classical desktop system nor the Unix "way" of doing things, which is oversimplifying the system layer to the point of almost uselessness. While the build system of AOSP and Android apps gives me shivers, the OS works beautifully and it can be continuously upgraded and be kept secure, if greedy SoC and device manufacturers released driver updates.
- jart 5y ago
  https://c.tenor.com/srlLdtb35fkAAAAC/starwars-anakin.gif https://c.tenor.com/srlLdtb35fkAAAAC/starwars-anakin.gif

account42 5y ago

> You'd hope libc wouldn't break. glibc is quite good about ABI compatibility - not any worse than Win32. X11 also has a stable protocol. Even with Wayland there is Xwayland for backwards compatibility. OpenGL and Vulkan have stable ABIs. Your program location doesn't matter - unless you are installed via the package manager (in which case the package specifies the location) you can load everything relative to the binary. User config location is gained a new standard for where you should put things to not mess up the home directory but that does not break anything. Old programs can still write to ~/.yourfancydotfile. Evenvironment variables only matter if you wrote your program for them to matter. Preinstalled libraries are irrelevant - ship your own like you have to do on windows for anything that is not part of the base system. Acceptable keyboars shortcuts and standard dialogs are integration concerns and not strictly needed. Not saying that you shouldn't provide DE-integration where that makes sense but that can be done on top of sane fallbacks. Also, there is now a cross-DE API for standard file dialogs: xdg-desktop-portals .desktop files have been standardized for a long time so you should not have problems registering file types - it is of course up to the DE to manage the default and that is a good thing.