Live data from Hacker News

Make Apps for Linux

makealinux.app

141–150 of 422 posts

Re: Make Apps for Linux

#141

The problem is OSS software not even trying to compete with the market. People using OSS software taking it for granted that the UX is going to be subpar, and it really is. Regular propriety software faces the risk of their users not paying, therefore adapting to make end user experience great. OSS usually doesn't have that risk. Open source needs to be exposed to risk from end users. I tried to change that with Note…

I understand your frustration, but I have a couple of counter-examples, and I don't offer them in any derogatory way.

1) Notes looks a lot like Standard Notes. If you built Notes using copy-left, OSS it's hard to complain unless you pay "royalties" to all the programmers whose work was incorporated into yours.

2) I am probably atypical. I have used Linux for over 20 years, but I can't write so much as a Bash script or a Perl one-liner. Yet I have spent a whole lot more money on software than I would have (or most individuals do) on other platforms. Because I can't code and appreciate the work of others and the freedom it gives me I support the following (not exclusive):

* Kaisen (my distro) and Debian (the distro Kaisen is built on) both

* tFSF for both core utilities and Emacs

* My DE (KDE), and even if I prefer the UI of other applications I mostly try to use those provided by KDE,tFSF, Debian, or Kaisen (e.g Akregator over RSSGuard) unless I donate, like:

* Mozilla (for Firefox), but

* Betterbird for my email client

* Syncthing

* LaGrange (gopher/gemini)

* Joplin

* ClipTo

* and more, including services (e.g. SoulSeek, envs.net)

Some annually, some monthly, some one-time.

In fact, when Standard Notes first came out I paid for a seven year subscription, and then ended up using it for about 2 months before becoming dissatisfied. There are some, like Alacritty, that I use extensively but which I have found no way to donate to, but I try to keep it to a minimum.

Re: Make Apps for Linux

#142
post #28

It's not an attractive scene for GUI developers on Linux. Gnome, Qt, and Electron all have some unappealing aspects. Many people who get the itch to make a Linux GUI app will immediately be discouraged by having to choose between them.

Have you tried WebUI? It's like a ultra minimalist version of electron. It uses available browsers instead of shipping its own. You simply write your App in html/js and everything that goes beyond (e.g. file access) is delegated to C with a simple callback mechanism.

Re: Make Apps for Linux

#143

Earlier quoted context omitted.

I had read somewhere that Win32 (via Wine or Proton) is the most stable target for Linux right now.

>Win32 (via Wine or Proton) is the most stable target for Linux right now Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass. Pretty wild that the same thing is not the norm in other OSs. Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childho…

The most underrated feature of windows probably ever.

Re: Make Apps for Linux

#144

Earlier quoted context omitted.

Stuff like Flatpak and Snap exists because the framework side kinda is built-out. Isolation technology had matured, newer desktops emphasized per-window security and needed APIs to portal in and out of each instance. The desktops needed a packaging/infrastructure solution to tie that together and make it presentable to the user.

Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.

On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.

Re: Make Apps for Linux

#145
post #34

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java.

Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework.

So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?

Re: Make Apps for Linux

#146

Earlier quoted context omitted.

This has the case for 10 years with games on steam. The worst being libstdc++ ABI issues still around because many devs forget to statically link their c++ libs with -static-libstdc++. Because in windows, ABI stability is really good and then devs are used to that.

As far as I understand, Windows solves this libc++ versioning issue using the side by side cache. I guess this is a little bit like flatpack.

Windows solves this issue by not making language runtime part of the OS libraries in a way that pollutes other libraries.

That means that you can have your application linked with library A version X, and load another library that is linked with library A version Y, and so long as certain practices are followed, everything works because you're not getting cross-contamination of symbols.

Meanwhile on Linux the defaults are quite different, and I can't load OpenGL ICD driver that depends on GLIBC_2.38 symbol on application that was loaded with glibc-2.37. Moreso, a lot of APIs will use malloc() and free() instead of language-independent allocator, unless the allocation comes from kernel. And no, you can't mix and match those.

Re: Make Apps for Linux

#147

Earlier quoted context omitted.

Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.

On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.

On a long enough time scale we are all dead, and Linux doesn't exist. That doesn't mean that in the decades that computer software has to be useful to actual people that things have to suck this badly right now.

Re: Make Apps for Linux

#148
post #68

The problem is OSS software not even trying to compete with the market. People using OSS software taking it for granted that the UX is going to be subpar, and it really is. Regular propriety software faces the risk of their users not paying, therefore adapting to make end user experience great. OSS usually doesn't have that risk. Open source needs to be exposed to risk from end users. I tried to change that with Note…

Personally I think KDE is light years ahead of macOS and Windows. In fact I find macOS to have been be of the worst window managers of all the popular platforms (sure it’s pretty and easy to use, but trying to do anything beyond the basics requires magical incantations that are impossible to discover organically). Each to their own though.

KDE _functions_ well, but my god does it need someone with an actual design education to help out.

Re: Make Apps for Linux

#149
post #34

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management ins…

And on a lower level, `fgetwc()` gets crashed deliberately in `libc` when applied to a stream created with `fopencookie()`. It should be incredible, but Linux `libc` is not Unicode-capable in 2023.

Re: Make Apps for Linux

#150

Earlier quoted context omitted.

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?

Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.
Post reply on HN