5 ms·

> The main reason must companies don't publish Linux electron apps is fragmentation. If you're doing anything more than rendering a webpage as an app, it starts

> The main reason must companies don't publish Linux electron apps is fragmentation. If you're doing anything more than rendering a webpage as an app, it starts to get complicated. Can confirm. At a past company we worked hard to release a Linux desktop client for our customers who wanted it, even though the number was small. It turns into compatibility hell very fast. You think you can target a couple recent Ubuntu releases and everything will be good, but then you’re getting peppered with complaints from people using distributions you’ve never heard of because some part of the app isn’t working right. So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere. The number of tickets with Linux issues keeps growing and each one is taking more time to debug, all for a number of customers that is so small you can’t justify doing it. But those customers are angry. And vocal. They’re posting all over Twitter, Hacker News, and Reddit about how your company’s software is garbage, without mentioning that they’re running an unknown distribution on a 13 year old ThinkPad. This even impacts open source projects. Several popular OSS Electron apps don’t work on many popular distros unless you set some command line workarounds, and even then it’s flakey. The open source projects get a pass because it’s open source, but if your company releases something you might be picking up a lot of angry, vocal customers that you didn’t want.

seabrookmx 5mo ago
Flatpak mostly solves this for GUI apps.
- Aurornis 5mo ago
  It does not. You just get more vocal angry customers who hate Flatpak and hate you for using it.
  - asveikau 5mo ago
    Can confirm, I hate flatpak
    - Loeffelmann 5mo ago
      Why?
      - jm4 5mo ago
        I'm not the one who hates flatpak, but I will point you to this comment a little further up: https://news.ycombinator.com/item?id=48435993 https://news.ycombinator.com/item?id=48435993 Flatpak serves a need, there are plenty of users who like it and there are probably even more who just use it without thinking much about it. Personally, I like it for a few reasons: - Being able to install something dependency-heavy with just one package - Sandboxing - Getting a newer package than what my distro provides - Being able to update apps independently of the rest of the OS - Being able to easily install apps that my distro doesn't provide The people who hate it, especially without giving a reason, are largely irrelevant when flatpak is filling a need for so many other people. Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.
        DaSHacka 5mo ago
        > Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise. And how do you know the userbase for GP's specific product is all Flatpak users? In fact, based on their comment, it appears as though they are explicitly not, hence their vocal frustration.
      - badsectoracula 5mo ago
        Not the person who wrote that but i also avoid anything related to Flatpak. The reason is that it adds a lot of extra friction to anything it touches (despite what its proponents may claim), apps ignore various settings, it wastes disk space with pointless duplication and a bunch of other issues i do not remember right now (it isn't like i write those down - i just sometimes decide to try it for something exactly because i forgot all the issues i faced and somehow someone convinced me things aren't as i remember, then recoil in horror afterwards as it turns out things are as i vaguely remember -- of course the main thing i always remember is the distaste i have for the thing, not the individual microdetails that led to the distaste). Ultimately if something isn't in my distro's repository, i try to compile it from source and if that isn't available, i just use something else.
  - Normal_gaussian 5mo ago
    This feels analogous to the old Google latency improvement story - improve performance and p99 goes up, not down, because more people are now able to use your product. These angry customers are a symptom of having more customers; in this direction (compatibility) companies shouldn't be KPI'ing on angry customers. It is very legitimate that high compatibility means more very obscure, low value, high cost, bug reports that are hard to classify as such. And my gosh, I hate working with rude ticket writers.
    - Aurornis 5mo ago
      > These angry customers are a symptom of having more customers; No, it's a symptom of having more of a very specific type of customer who is more demanding and difficult to please than your other customers. When you don't officially support Linux, the Linux users are not surprised. It's normal for them. They find other ways to use the product. When you do announce Linux support, you open Pandora's box of complaints. They're extra angry that you claim Linux support but it doesn't work perfectly on their unique combination of laptop, distro, display protocol, and window manager. You gained a small number of happy customers, but picked up a disproportionately large number of angry, vocal customers in the process.
      - tormeh 5mo ago
        This is when you say "We support Ubuntu", and honestly that's fine.
        trumpdong 5mo ago
        Indeed. You make anything past that the customer's problem. I have a few Ubuntu apps that needed a bit of jiggery-pokery to make them run on not-Ubuntu.
      - Normal_gaussian 5mo ago
        You start with 'no', but rather than disagree, you've effectively restated my comment. I wasn't looking to anger you, just to provide a different lens in which to view the situation.
  - NotPractical 5mo ago
    There is a difference between mandating that your customers use one specific Linux distro which is maintained by a controversial company, and supporting all Linux distros through an imperfect-but-fully-working method. Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.
- aaddrick 5mo ago
  https://news.ycombinator.com/item?id=48434436#48435801 https://news.ycombinator.com/item?id=48434436#48435801 Made comment about flatpack below the comment above.
nbardy 5mo ago
This does feel like the perfect setup for Claude though. Much easier to create a vm testing swarm of 100 disitributions with llms
jareklupinski 5mo ago
> they’re running an unknown distribution on a 13 year old ThinkPad. "Tony Stark can do it in a cave! With rocks!"
hparadiz 5mo ago
You compile for the lowest possible Linux kernel and bundle your libs. Don't use container formats for stuff like this. tar.gz with an installer script is king. I dunno why this is always so difficult.
- aaddrick 5mo ago
  It's mostly dealing with different backends\compositors\etc. My reply to the comment below outlines the shape of the problem. https://news.ycombinator.com/item?id=48434436#48435801 https://news.ycombinator.com/item?id=48434436#48435801
- hamandcheese 5mo ago
  From experience: I work on a small team maintaining build infrastructure for my entire company. My goal, as much as possible, is to maintain a single build environment that can serve all purposes. But it has proven quite the challenge to support old Linux distros. We have tried using nix to pin deps, but this easily leads to new issues: hardcoded RPATHs leaking into binaries, glibc compatibility issues, etc. If we instead fork the build environment and use an old Ubuntu for building our Linux app, then my life gets harder, because now I have two targets for a whole lot of internal tooling that my team maintains, and that tooling needs to be deployed to both build environments. Again, its the same shit: glibc mismatches, missing/different shared libraries, etc. Just causing problems in a different place. There is certainly some element of skill issue at play. But I wouldn't call it easy.
  - hparadiz 5mo ago
    Me too but my job is easier since I can target a specific version of ubuntu so I'm making debs and I don't have that problem. I have recently been working on a C11 GTK+ based task manager where I run into this. https://github.com/hparadiz/evemon/tree/main/packaging https://github.com/hparadiz/evemon/tree/main/packaging This is why I said bundle your libs. If you bundle ALL of your libs you can't possibly run into an issue if your install script is run as root. Unless it's an extremely eccentric non desktop oriented system at which point that's kind of on them. If you wanna cover 99.9% of Linux you build fedora, ubuntu, debian, nixos, arch and have a tar.gz as your overflow. For each target the lowest available LTS and don't waste time on distros that aren't getting security updates. It's not reasonable to ask for binaries built against your specific 11 year old gcc. edit wanted to add one more thing. I'm a big believer in having your tar.gz and install script inform your deb, rpm, aur, etc. It should be basically the same exact thing as your tar.gz just done in the format those distros want.
aaddrick 5mo ago
Yeah. I just dropped another repackaging repo for Wispr Flow. https://github.com/wispr-flow-linux/wispr-flow-linux https://github.com/wispr-flow-linux/wispr-flow-linux A lot of that is keyboard shortcuts for push-to-talk. Easy right? X11 is mostly fine, but the world is moving into Wayland. Wayland doesn't have shortcuts native and relies on xdg-desktop-portal, which in turn relies on each backend to implement it's own version. COSMIC from the Pop!OS team's xdg-desktop-cosmic doesn't support GlobalShortcuts yet (might now, haven't checked in a bit). So XWayland for them. Tray icons? GNOME doesn't have a tray out of the box, but there's an extension. There's no standard for whether it's light mode or dark mode across distros and when you map out the options, no api's indicate whether the tray is light or dark while in light/dark mode. At some point you have to just accept it's not always perfect or patch in an override.
- WD-42 5mo ago
  A lot of us are happy gnome doesn’t support tray icons. We are sick of devs thinking their app is so important it needs a visual presence at all times. If I need your app I’ll bring it to the foreground, we have the technology. Global shortcuts definitely a pain point with Wayland but the portals are making progress.
  - jm4 5mo ago
    I don't like tray icons. What I like less is an app that runs in the background anyway when I didn't ask it to and that behavior is hidden. It's infuriating to "quit" an app and it's still there. At least gnome finally addressed that with the little background apps widget.
  - aaddrick 5mo ago
    Yeah, I don't want want to take away from anyone. The COSMIC team is doing amazing and hard work. I started dev on claude-desktop-debian with Pop!OS COSMIC as my daily. We're just in a weird spot for that particular issue right now. In 3 years, it'll be something else. That's the nature of fragmentation. While GNOME tray lovers and haters both exist, only one of those two groups is liable to submit an issue against my repo looking for help getting icons working correctly.
trumpdong 5mo ago
Reminds me that I occasionally have to set _JAVA_AWT_WM_NONREPARENTING=1 because it's not always inherited from my login shell. Otherwise Java windows won't display anything because I suppose Java waits for them to be reparented.
- GrayShade 5mo ago
  On systemd, you can use ~/.config/environment.d to set it. Don't rely on your shell.
  - trumpdong 5mo ago
    Screw systemd
WD-42 5mo ago
Did you hire a Linux release engineer? Or was the situation the typical team of devs maining macOS that have never heard the term “Wayland” before plus That One Guy who switched to Ubuntu last year and advocated for it? There are companies that do this right. But it often requires a hire. Too many companies think they can just yolo it because Linux isn’t a serious OS or whatever and then are surprised when it doesn’t work out well.
- eptcyka 5mo ago
  Even for those who do this right, some things change under your feet because OSS maintainers of kernel feature A want to stop supporting V1 of A when V2 has been out for a decade. But the features missing in V2 are supposed to be provided by userspace B - and they are yet to tackle the functionality altogether. So now your app will just have to regress in features. It is very easy to ship OSS code as a maintainer of a project, it is very difficult to keep up with Linux as a developer unless you stick to libc. There is no one source of truth with regards to how things should work, there is no one roadmap, and maintainers care a lot more about complexity than maintaining feature parity of backwards compatibility. I do not blame them, but then it is difficult to target linux. Much easier to support a platform with guarantees and a shared vision. Saying this as someone who has only used Linux at home for 20 years.
  - jlokier 5mo ago
    Thanks to the Linux kernel's extremely high backward compatibility, and virtually all the libraries being open source, you can ship old or frozen versions of libraries with your application if you have to. You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality, while using the distro version if that's more up to date and still has the functionality. You can do the same for auxiliary programs your application uses. I agree that sticking to libc is most reliable, if you can. But the experience is poor if you do that for desktop applications. There's no singular source of truth, but there's a de facto frontier of only a few mainstream distros, as well as upstream heads for your dependencies. It's extra work, but there are systematic workarounds to the feature drift over time and the tendancy of some open source projects to aggressively deprecate older functionality and older system compatilbilty. You can, to an extent, automate testing on newer versions of distros to be alerted when something no longer works, and often you can do this before the official distro release date. Unfortunately even libc is not reliable. Unless it's a static build, Glibc is often broken (with symbol version errors) when trying to run a binary compiled on one distro on another distro, or an older version of the same distro. Static binaries have other problems, though work very well if the application is self contained and isn't a GUI. One thing that I find works very compatibly, though, is OpenGL / Vulkan binary-compatibility across distros and versions. There was a lot of work done on making libGL something you can link to or dynamically load reliably and take it from there. The OpenGL extension spaghetti is an interesting problem from then on, but that's more to do with the individual user's GPU and GPU drivers, independent of the Linux distro or even which OS it's running on.
ai_slop_hater 5mo ago
[flagged]
esseph 5mo ago
Just ship a flatpak?
the__alchemist 5mo ago
I don't have experience with Electron, but... IMO if you compile on something like Ubuntu 20, many applications will work reliably on Ubuntu 20, 22, 24,+, and Debian 2020 editions +. (Assuming same CPU arch as the compiling computer). Obviously this will probably fail on other distros, but I've found in the past similar groupings. Backwards compatibility is different: I expect a package a compile on Ubuntu 24 not to work on Ubuntu 22. This is anecdotal, and in the context of rust + EGUI, so I'm not sure how applicable it is to Electron. I recently hit a Wayland snag: It doesn't support Device Events other than mouse movement. I worked around it by changing to Window events. I could see that being annoying if this substitution weren't acceptable, but it was in this case.
- ryandrake 5mo ago
  Man, I remember 25 years ago writing commercial software that worked across a half a dozen Linux distributions, at least two BSDs, Solaris, AIX, HP-UX, and Irix, and close to half a dozen CPU architectures. Yet today, developers struggle getting a build for two different versions of the same Linux distribution. The industry has lost a critical skill.
bazmattaz 5mo ago
Could you not be extremely clear and state which distros are supported and make it clear that it may work on others but that they are untested
- jay_kyburz 5mo ago
  Unity Game Engine does this, They support x distro only. So you mess around installing their chosen OS only to find stuff still doesn't work properly. :)
gambiting 5mo ago
Yep, I've seen the same issue in video games. A few passionate engineers convince PMs to make a Linux version of the game, they test on few popular distros, everything is great. Then the game launches , and a very very very small minority of Linux users can't run your game, but they file 75% of all your support tickets. If you don't respond to them in the manner they find acceptable, they are extremely vocal on social media about how you as the developer are lazy and incompetent. It's 10000% not worth it for that reason alone. Nowadays I'd personally advocate for making sure the game runs well under Proton and leaving it at that.
- lukan 5mo ago
  The sad part is, that those people usually think, they help linux this way.
bazmattaz 5mo ago
I guess compatibility hell is why Linux will never go mainstream. Users like their favourite apps just working on their favourite OS. It’s not a great experience if only some apps on supported on your favourite Linux distro while others aren’t.
smarx007 5mo ago
Sounds like a product management problem. If you declare that you support RHEL and Ubuntu LTS and LTS-1 yet still process bug reports from other installations, the product owner is not doing their job properly. Any bug reports from Nix or Fedora got to be closed due to a wrong operating environment. Even accepting bug reports from the latest non-LTS Ubuntu release should be avoided.
whatshisface 5mo ago
I understand this story, and I have heard it many, many times - but I do not understand how something that is possible for thousands of hobbyists writing text editors on their weekends is not possible for professionals! "You can't buy Linux-compatible software because it is too difficult to write. Instead, get it for free."
rstuart4133 5mo ago
> Can confirm. At a past company we worked hard to release a Linux desktop client for our customers who wanted it ... you’re getting peppered with complaints from people using distributions you’ve never heard of ... but the problem is in upstream somewhere You have taken on the work the distributions do in the open source world. No upstream open source developer takes that on. Instead of getting bug reports from users, upstream developers insist bug reports are filtered by the distro maintainer first. They fix problems on their side so you never see them, and the ones that do make it through have been triaged. It's a win for everyone. So the solution is to handle it the way they do. Choose a couple of baselines: maybe Debian Stable and Fedora. Publish packages for them, and make it plain they are only certified for those platforms. Make the rest someone else's problem: if you want it working on distro X, you package it for distro X. You've done the bulk of the work for them anyway, as most of them are either Debian or RPM based.
- NotPractical 5mo ago
  > No upstream open source developer takes that on The key words here are "open source", right? Some problems can't be solved without cooperation with the developer.
  - rstuart4133 5mo ago
    > Some problems can't be solved without cooperation with the developer. Those problems are the ones package maintainer forwards upstream. It's well understood common and common workflow because lots of closed source packages are distributed by distro's now. Debian distributes firmware; Ubuntu and RedHat distribute closed source drivers.
gerdesj 5mo ago
"So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere." So get to grips with "upstream"! Managing upset "opinionated" and "entitled" users is par for the course anywhere. Have a look at how Veeam do it, for example. Obviously that sort of compatibility nonsense never happens in say Windows (fairly popular OS). Let's take a quick look at say web proxies. Proxies are quite popular in corporate environments but blow me if Windows and vendors who use it make it as hard as possible to deal with: You might think group policy would sort it all out - lol! You have loads of elderly policies relating to IE (several versions) hanging around smelling rather fishy and mildly useful if you have older Windows hanging around. You can use GPOs to fix the following but it will be Preferences and involve a bit of ingenuity. You have .Net Framework apps - eg AD Sync (Entra, Smentra whatever its called today). That will need you to fiddle with a specific XML file. winhttp api? Powershell. OK you have two sets of settings here: proxy and advproxy. proxy has string properties that you set and is a bit crap and advproxy has a JSON flavour and is a bit shit. advproxy seems to ignore anything in the ignore list apart from or exclusively <local>. At least advproxy allows you to fall back on a proxy.pac file (which IE decided to call wpad.dat and who can forget an IE5 version that called it WPAD.DA?) Picking on Linux users is disingenuous - all OSs can be customized to the point of tricky to support and besides who on earth is Twitter?
winter_blue 5mo ago
Couldn't just a single Flatpak release be sufficient? Flatpak can be set up on many/most distros.
- aaddrick 5mo ago
  Flatpack packages everything under one distributable, but doesn't solve the quirkiness of all the different frontends, backend, compositors, etc. - titlebar - tray icon w/light and dark mode support - global keyboard shortcut - redraw events after resizing Those are a subset of the many items that don't play well between various distros. Like Ubuntu Gnome w/X11 vs Pop!OS COSMIC w/Wayland or any of the tiling window managers like hyprland.
  - amlib 5mo ago
    > titlebar Consistency of titlebars has been dead in every OS for decades now. This is not even a flatpak problem anyway, but I do think wayland/gnome ought to have some kind of fallback decoration. This wouldn't even be meant to solve this problem, but would be a nice gesture for situations where a dev really don't care about how the decoration functions or looks, like when opening a game window or movie player like mpv or even just having a friction-less experience when creating your first window in a new app. > tray icon w/light and dark mode support Flatpak and specially gnome are championing the background app portals. I have reservations on how it's not a full replacement for tray icons, but Desktop Environments are free to implement it like a tray icon. > global keyboard shortcut AFAIK it's a solved problem, but there is an adoption lag for DE's and apps. > redraw events after resizing Not sure what you mean by that? Apps resize fine in flatpak Every problem in flatpak can be addressed. It sucks they weren't addressed sooner but I suggest you look into the efforts being made for flatpak-next. Even right now it's the closest thing we got to a unified gui experience in linux.
arikrahman 5mo ago
The problem is using the build system. Using Nix flakes could help alleviate a lot of concerns, I wrapped a target meant for debian. After wrapping it with a flake, it worked on NixOS. But since I'm building it declaratively and not imperatively, it could target any distribution, even mac. I've done this with Bitwig, https://github.com/ArikRahman/Nixwig https://github.com/ArikRahman/Nixwig and Jank lang (https://github.com/jank-lang/jank https://github.com/jank-lang/jank) in this PR: https://github.com/NixOS/nixpkgs/pull/523741 https://github.com/NixOS/nixpkgs/pull/523741
tw04 5mo ago
> but then you’re getting peppered with complaints from people using distributions you’ve never heard of because some part of the app isn’t working right. Honestly, it sounds like you guys need to learn to say no. Worked at an OEM and we had device divers for RHEL. If you got it working on something else, good for you. But if you wanted to open a support case, you better be able to reproduce the bug on a supported version of RHEL. I would occasionally humor people running CentOS if I had some spare cycles, but if you were on Debian the answer was: sorry, would love to help but I can’t. The people who can’t understand why you have a tight support matrix are the people you don’t want to get sucked into the rabbit hole with anyway.
bigpeopleareold 5mo ago
I know you are being facetious that there are a few that are a little bit too persnickety with old ThinkPads, but if they used a known distribution on the said 13-year old ThinkPad (that would probably be in the T430 territory), would it be better? I have a T430s and that is still a fine computer, even if my primary one is an 8 year old ThinkPad. Maybe those same people can just prefer using OpenCode. It's at least free software, particularly if that old computer is running only free software with free firmware, and OpenCode can run free models.

seabrookmx 5mo ago

Flatpak mostly solves this for GUI apps.

Aurornis 5mo ago
It does not. You just get more vocal angry customers who hate Flatpak and hate you for using it.
- asveikau 5mo ago
  Can confirm, I hate flatpak
  - Loeffelmann 5mo ago
    Why?
    - jm4 5mo ago
      I'm not the one who hates flatpak, but I will point you to this comment a little further up: https://news.ycombinator.com/item?id=48435993 https://news.ycombinator.com/item?id=48435993 Flatpak serves a need, there are plenty of users who like it and there are probably even more who just use it without thinking much about it. Personally, I like it for a few reasons: - Being able to install something dependency-heavy with just one package - Sandboxing - Getting a newer package than what my distro provides - Being able to update apps independently of the rest of the OS - Being able to easily install apps that my distro doesn't provide The people who hate it, especially without giving a reason, are largely irrelevant when flatpak is filling a need for so many other people. Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise.
      - DaSHacka 5mo ago
        > Design for the people who are using and who like your product. Make adjustments based on their feedback. Ignore the people who just make noise. And how do you know the userbase for GP's specific product is all Flatpak users? In fact, based on their comment, it appears as though they are explicitly not, hence their vocal frustration.
    - badsectoracula 5mo ago
      Not the person who wrote that but i also avoid anything related to Flatpak. The reason is that it adds a lot of extra friction to anything it touches (despite what its proponents may claim), apps ignore various settings, it wastes disk space with pointless duplication and a bunch of other issues i do not remember right now (it isn't like i write those down - i just sometimes decide to try it for something exactly because i forgot all the issues i faced and somehow someone convinced me things aren't as i remember, then recoil in horror afterwards as it turns out things are as i vaguely remember -- of course the main thing i always remember is the distaste i have for the thing, not the individual microdetails that led to the distaste). Ultimately if something isn't in my distro's repository, i try to compile it from source and if that isn't available, i just use something else.
- Normal_gaussian 5mo ago
  This feels analogous to the old Google latency improvement story - improve performance and p99 goes up, not down, because more people are now able to use your product. These angry customers are a symptom of having more customers; in this direction (compatibility) companies shouldn't be KPI'ing on angry customers. It is very legitimate that high compatibility means more very obscure, low value, high cost, bug reports that are hard to classify as such. And my gosh, I hate working with rude ticket writers.
  - Aurornis 5mo ago
    > These angry customers are a symptom of having more customers; No, it's a symptom of having more of a very specific type of customer who is more demanding and difficult to please than your other customers. When you don't officially support Linux, the Linux users are not surprised. It's normal for them. They find other ways to use the product. When you do announce Linux support, you open Pandora's box of complaints. They're extra angry that you claim Linux support but it doesn't work perfectly on their unique combination of laptop, distro, display protocol, and window manager. You gained a small number of happy customers, but picked up a disproportionately large number of angry, vocal customers in the process.
    - tormeh 5mo ago
      This is when you say "We support Ubuntu", and honestly that's fine.
      - trumpdong 5mo ago
        Indeed. You make anything past that the customer's problem. I have a few Ubuntu apps that needed a bit of jiggery-pokery to make them run on not-Ubuntu.
    - Normal_gaussian 5mo ago
      You start with 'no', but rather than disagree, you've effectively restated my comment. I wasn't looking to anger you, just to provide a different lens in which to view the situation.
- NotPractical 5mo ago
  There is a difference between mandating that your customers use one specific Linux distro which is maintained by a controversial company, and supporting all Linux distros through an imperfect-but-fully-working method. Sure, you'll still get a few complaints from ideological purists, but there's no avoiding that regardless of what you do.
aaddrick 5mo ago
https://news.ycombinator.com/item?id=48434436#48435801 https://news.ycombinator.com/item?id=48434436#48435801 Made comment about flatpack below the comment above.

nbardy 5mo ago

This does feel like the perfect setup for Claude though. Much easier to create a vm testing swarm of 100 disitributions with llms

jareklupinski 5mo ago

> they’re running an unknown distribution on a 13 year old ThinkPad. "Tony Stark can do it in a cave! With rocks!"

hparadiz 5mo ago

You compile for the lowest possible Linux kernel and bundle your libs. Don't use container formats for stuff like this. tar.gz with an installer script is king. I dunno why this is always so difficult.

aaddrick 5mo ago
It's mostly dealing with different backends\compositors\etc. My reply to the comment below outlines the shape of the problem. https://news.ycombinator.com/item?id=48434436#48435801 https://news.ycombinator.com/item?id=48434436#48435801
hamandcheese 5mo ago
From experience: I work on a small team maintaining build infrastructure for my entire company. My goal, as much as possible, is to maintain a single build environment that can serve all purposes. But it has proven quite the challenge to support old Linux distros. We have tried using nix to pin deps, but this easily leads to new issues: hardcoded RPATHs leaking into binaries, glibc compatibility issues, etc. If we instead fork the build environment and use an old Ubuntu for building our Linux app, then my life gets harder, because now I have two targets for a whole lot of internal tooling that my team maintains, and that tooling needs to be deployed to both build environments. Again, its the same shit: glibc mismatches, missing/different shared libraries, etc. Just causing problems in a different place. There is certainly some element of skill issue at play. But I wouldn't call it easy.
- hparadiz 5mo ago
  Me too but my job is easier since I can target a specific version of ubuntu so I'm making debs and I don't have that problem. I have recently been working on a C11 GTK+ based task manager where I run into this. https://github.com/hparadiz/evemon/tree/main/packaging https://github.com/hparadiz/evemon/tree/main/packaging This is why I said bundle your libs. If you bundle ALL of your libs you can't possibly run into an issue if your install script is run as root. Unless it's an extremely eccentric non desktop oriented system at which point that's kind of on them. If you wanna cover 99.9% of Linux you build fedora, ubuntu, debian, nixos, arch and have a tar.gz as your overflow. For each target the lowest available LTS and don't waste time on distros that aren't getting security updates. It's not reasonable to ask for binaries built against your specific 11 year old gcc. edit wanted to add one more thing. I'm a big believer in having your tar.gz and install script inform your deb, rpm, aur, etc. It should be basically the same exact thing as your tar.gz just done in the format those distros want.

aaddrick 5mo ago

Yeah. I just dropped another repackaging repo for Wispr Flow. https://github.com/wispr-flow-linux/wispr-flow-linux https://github.com/wispr-flow-linux/wispr-flow-linux A lot of that is keyboard shortcuts for push-to-talk. Easy right? X11 is mostly fine, but the world is moving into Wayland. Wayland doesn't have shortcuts native and relies on xdg-desktop-portal, which in turn relies on each backend to implement it's own version. COSMIC from the Pop!OS team's xdg-desktop-cosmic doesn't support GlobalShortcuts yet (might now, haven't checked in a bit). So XWayland for them. Tray icons? GNOME doesn't have a tray out of the box, but there's an extension. There's no standard for whether it's light mode or dark mode across distros and when you map out the options, no api's indicate whether the tray is light or dark while in light/dark mode. At some point you have to just accept it's not always perfect or patch in an override.

WD-42 5mo ago
A lot of us are happy gnome doesn’t support tray icons. We are sick of devs thinking their app is so important it needs a visual presence at all times. If I need your app I’ll bring it to the foreground, we have the technology. Global shortcuts definitely a pain point with Wayland but the portals are making progress.
- jm4 5mo ago
  I don't like tray icons. What I like less is an app that runs in the background anyway when I didn't ask it to and that behavior is hidden. It's infuriating to "quit" an app and it's still there. At least gnome finally addressed that with the little background apps widget.
- aaddrick 5mo ago
  Yeah, I don't want want to take away from anyone. The COSMIC team is doing amazing and hard work. I started dev on claude-desktop-debian with Pop!OS COSMIC as my daily. We're just in a weird spot for that particular issue right now. In 3 years, it'll be something else. That's the nature of fragmentation. While GNOME tray lovers and haters both exist, only one of those two groups is liable to submit an issue against my repo looking for help getting icons working correctly.

trumpdong 5mo ago

Reminds me that I occasionally have to set _JAVA_AWT_WM_NONREPARENTING=1 because it's not always inherited from my login shell. Otherwise Java windows won't display anything because I suppose Java waits for them to be reparented.

GrayShade 5mo ago
On systemd, you can use ~/.config/environment.d to set it. Don't rely on your shell.
- trumpdong 5mo ago
  Screw systemd

WD-42 5mo ago

Did you hire a Linux release engineer? Or was the situation the typical team of devs maining macOS that have never heard the term “Wayland” before plus That One Guy who switched to Ubuntu last year and advocated for it? There are companies that do this right. But it often requires a hire. Too many companies think they can just yolo it because Linux isn’t a serious OS or whatever and then are surprised when it doesn’t work out well.

eptcyka 5mo ago
Even for those who do this right, some things change under your feet because OSS maintainers of kernel feature A want to stop supporting V1 of A when V2 has been out for a decade. But the features missing in V2 are supposed to be provided by userspace B - and they are yet to tackle the functionality altogether. So now your app will just have to regress in features. It is very easy to ship OSS code as a maintainer of a project, it is very difficult to keep up with Linux as a developer unless you stick to libc. There is no one source of truth with regards to how things should work, there is no one roadmap, and maintainers care a lot more about complexity than maintaining feature parity of backwards compatibility. I do not blame them, but then it is difficult to target linux. Much easier to support a platform with guarantees and a shared vision. Saying this as someone who has only used Linux at home for 20 years.
- jlokier 5mo ago
  Thanks to the Linux kernel's extremely high backward compatibility, and virtually all the libraries being open source, you can ship old or frozen versions of libraries with your application if you have to. You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality, while using the distro version if that's more up to date and still has the functionality. You can do the same for auxiliary programs your application uses. I agree that sticking to libc is most reliable, if you can. But the experience is poor if you do that for desktop applications. There's no singular source of truth, but there's a de facto frontier of only a few mainstream distros, as well as upstream heads for your dependencies. It's extra work, but there are systematic workarounds to the feature drift over time and the tendancy of some open source projects to aggressively deprecate older functionality and older system compatilbilty. You can, to an extent, automate testing on newer versions of distros to be alerted when something no longer works, and often you can do this before the official distro release date. Unfortunately even libc is not reliable. Unless it's a static build, Glibc is often broken (with symbol version errors) when trying to run a binary compiled on one distro on another distro, or an older version of the same distro. Static binaries have other problems, though work very well if the application is self contained and isn't a GUI. One thing that I find works very compatibly, though, is OpenGL / Vulkan binary-compatibility across distros and versions. There was a lot of work done on making libGL something you can link to or dynamically load reliably and take it from there. The OpenGL extension spaghetti is an interesting problem from then on, but that's more to do with the individual user's GPU and GPU drivers, independent of the Linux distro or even which OS it's running on.

ai_slop_hater 5mo ago

[flagged]

esseph 5mo ago

Just ship a flatpak?

the__alchemist 5mo ago

I don't have experience with Electron, but... IMO if you compile on something like Ubuntu 20, many applications will work reliably on Ubuntu 20, 22, 24,+, and Debian 2020 editions +. (Assuming same CPU arch as the compiling computer). Obviously this will probably fail on other distros, but I've found in the past similar groupings. Backwards compatibility is different: I expect a package a compile on Ubuntu 24 not to work on Ubuntu 22. This is anecdotal, and in the context of rust + EGUI, so I'm not sure how applicable it is to Electron. I recently hit a Wayland snag: It doesn't support Device Events other than mouse movement. I worked around it by changing to Window events. I could see that being annoying if this substitution weren't acceptable, but it was in this case.

ryandrake 5mo ago
Man, I remember 25 years ago writing commercial software that worked across a half a dozen Linux distributions, at least two BSDs, Solaris, AIX, HP-UX, and Irix, and close to half a dozen CPU architectures. Yet today, developers struggle getting a build for two different versions of the same Linux distribution. The industry has lost a critical skill.

bazmattaz 5mo ago

Could you not be extremely clear and state which distros are supported and make it clear that it may work on others but that they are untested

jay_kyburz 5mo ago
Unity Game Engine does this, They support x distro only. So you mess around installing their chosen OS only to find stuff still doesn't work properly. :)

gambiting 5mo ago

Yep, I've seen the same issue in video games. A few passionate engineers convince PMs to make a Linux version of the game, they test on few popular distros, everything is great. Then the game launches , and a very very very small minority of Linux users can't run your game, but they file 75% of all your support tickets. If you don't respond to them in the manner they find acceptable, they are extremely vocal on social media about how you as the developer are lazy and incompetent. It's 10000% not worth it for that reason alone. Nowadays I'd personally advocate for making sure the game runs well under Proton and leaving it at that.

lukan 5mo ago
The sad part is, that those people usually think, they help linux this way.

bazmattaz 5mo ago

I guess compatibility hell is why Linux will never go mainstream. Users like their favourite apps just working on their favourite OS. It’s not a great experience if only some apps on supported on your favourite Linux distro while others aren’t.

smarx007 5mo ago

Sounds like a product management problem. If you declare that you support RHEL and Ubuntu LTS and LTS-1 yet still process bug reports from other installations, the product owner is not doing their job properly. Any bug reports from Nix or Fedora got to be closed due to a wrong operating environment. Even accepting bug reports from the latest non-LTS Ubuntu release should be avoided.

whatshisface 5mo ago

I understand this story, and I have heard it many, many times - but I do not understand how something that is possible for thousands of hobbyists writing text editors on their weekends is not possible for professionals! "You can't buy Linux-compatible software because it is too difficult to write. Instead, get it for free."

rstuart4133 5mo ago

> Can confirm. At a past company we worked hard to release a Linux desktop client for our customers who wanted it ... you’re getting peppered with complaints from people using distributions you’ve never heard of ... but the problem is in upstream somewhere You have taken on the work the distributions do in the open source world. No upstream open source developer takes that on. Instead of getting bug reports from users, upstream developers insist bug reports are filtered by the distro maintainer first. They fix problems on their side so you never see them, and the ones that do make it through have been triaged. It's a win for everyone. So the solution is to handle it the way they do. Choose a couple of baselines: maybe Debian Stable and Fedora. Publish packages for them, and make it plain they are only certified for those platforms. Make the rest someone else's problem: if you want it working on distro X, you package it for distro X. You've done the bulk of the work for them anyway, as most of them are either Debian or RPM based.

NotPractical 5mo ago
> No upstream open source developer takes that on The key words here are "open source", right? Some problems can't be solved without cooperation with the developer.
- rstuart4133 5mo ago
  > Some problems can't be solved without cooperation with the developer. Those problems are the ones package maintainer forwards upstream. It's well understood common and common workflow because lots of closed source packages are distributed by distro's now. Debian distributes firmware; Ubuntu and RedHat distribute closed source drivers.

gerdesj 5mo ago

"So your engineers spend a half day installing that in a VM and debugging it, but the problem is in upstream somewhere." So get to grips with "upstream"! Managing upset "opinionated" and "entitled" users is par for the course anywhere. Have a look at how Veeam do it, for example. Obviously that sort of compatibility nonsense never happens in say Windows (fairly popular OS). Let's take a quick look at say web proxies. Proxies are quite popular in corporate environments but blow me if Windows and vendors who use it make it as hard as possible to deal with: You might think group policy would sort it all out - lol! You have loads of elderly policies relating to IE (several versions) hanging around smelling rather fishy and mildly useful if you have older Windows hanging around. You can use GPOs to fix the following but it will be Preferences and involve a bit of ingenuity. You have .Net Framework apps - eg AD Sync (Entra, Smentra whatever its called today). That will need you to fiddle with a specific XML file. winhttp api? Powershell. OK you have two sets of settings here: proxy and advproxy. proxy has string properties that you set and is a bit crap and advproxy has a JSON flavour and is a bit shit. advproxy seems to ignore anything in the ignore list apart from or exclusively <local>. At least advproxy allows you to fall back on a proxy.pac file (which IE decided to call wpad.dat and who can forget an IE5 version that called it WPAD.DA?) Picking on Linux users is disingenuous - all OSs can be customized to the point of tricky to support and besides who on earth is Twitter?

winter_blue 5mo ago

Couldn't just a single Flatpak release be sufficient? Flatpak can be set up on many/most distros.

aaddrick 5mo ago
Flatpack packages everything under one distributable, but doesn't solve the quirkiness of all the different frontends, backend, compositors, etc. - titlebar - tray icon w/light and dark mode support - global keyboard shortcut - redraw events after resizing Those are a subset of the many items that don't play well between various distros. Like Ubuntu Gnome w/X11 vs Pop!OS COSMIC w/Wayland or any of the tiling window managers like hyprland.
- amlib 5mo ago
  > titlebar Consistency of titlebars has been dead in every OS for decades now. This is not even a flatpak problem anyway, but I do think wayland/gnome ought to have some kind of fallback decoration. This wouldn't even be meant to solve this problem, but would be a nice gesture for situations where a dev really don't care about how the decoration functions or looks, like when opening a game window or movie player like mpv or even just having a friction-less experience when creating your first window in a new app. > tray icon w/light and dark mode support Flatpak and specially gnome are championing the background app portals. I have reservations on how it's not a full replacement for tray icons, but Desktop Environments are free to implement it like a tray icon. > global keyboard shortcut AFAIK it's a solved problem, but there is an adoption lag for DE's and apps. > redraw events after resizing Not sure what you mean by that? Apps resize fine in flatpak Every problem in flatpak can be addressed. It sucks they weren't addressed sooner but I suggest you look into the efforts being made for flatpak-next. Even right now it's the closest thing we got to a unified gui experience in linux.

arikrahman 5mo ago

The problem is using the build system. Using Nix flakes could help alleviate a lot of concerns, I wrapped a target meant for debian. After wrapping it with a flake, it worked on NixOS. But since I'm building it declaratively and not imperatively, it could target any distribution, even mac. I've done this with Bitwig, https://github.com/ArikRahman/Nixwig https://github.com/ArikRahman/Nixwig and Jank lang (https://github.com/jank-lang/jank https://github.com/jank-lang/jank) in this PR: https://github.com/NixOS/nixpkgs/pull/523741 https://github.com/NixOS/nixpkgs/pull/523741

tw04 5mo ago

> but then you’re getting peppered with complaints from people using distributions you’ve never heard of because some part of the app isn’t working right. Honestly, it sounds like you guys need to learn to say no. Worked at an OEM and we had device divers for RHEL. If you got it working on something else, good for you. But if you wanted to open a support case, you better be able to reproduce the bug on a supported version of RHEL. I would occasionally humor people running CentOS if I had some spare cycles, but if you were on Debian the answer was: sorry, would love to help but I can’t. The people who can’t understand why you have a tight support matrix are the people you don’t want to get sucked into the rabbit hole with anyway.

bigpeopleareold 5mo ago

I know you are being facetious that there are a few that are a little bit too persnickety with old ThinkPads, but if they used a known distribution on the said 13-year old ThinkPad (that would probably be in the T430 territory), would it be better? I have a T430s and that is still a fine computer, even if my primary one is an 8 year old ThinkPad. Maybe those same people can just prefer using OpenCode. It's at least free software, particularly if that old computer is running only free software with free firmware, and OpenCode can run free models.