Live data from Hacker News

Make Apps for Linux

makealinux.app

401–410 of 422 posts

Re: Make Apps for Linux

#401

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 other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuf…

Snaps will not work on anything but Ubuntu.

AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.

Re: Make Apps for Linux

#402

Earlier quoted context omitted.

+1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example image-editor.AppImage image-editor.AppImage.home (folder, all settings are stored there)

Actually, I don't think I've tried AppImage. Does it do static linking or does it do something more similar to flatpak?

It's a self-mounting image so closer to flatpak than static linking but without the strict isolation.

Re: Make Apps for Linux

#403

Earlier quoted context omitted.

The "actual people" using Linux on the desktop are not running .so files off the internet. I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.

> The "actual people" using Linux on the desktop are not running .so files off the internet. They do this all day every day when they use a little something called Steam or when they install Google Chrome. > I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too. It is...

> They do this all day every day when they use a little something called Steam

Which while (initially) officially only released for a specific Ubuntu version ran on pretty much any up to date distro from day zero.

Re: Make Apps for Linux

#404

Earlier quoted context omitted.

On other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuf…

Snaps will not work on anything but Ubuntu. AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.

>Snaps will not work on anything but Ubuntu.

I installed VSCode as a snap on my Fedora install and it worked fine as far as I could tell. This was in Mar 2021, and I chose the snap because code.visualstudio.com/docs/setup/linux said that "Due to the manual signing process and the system we use to publish, the yum repo may lag behind and not get the latest version of VS Code immediately. . . . Updates are automatic and run in the background for the Snap package."

(I don't have an opinion on Snap as compared to Flatpak or AppImage or none of the 3.)

Re: Make Apps for Linux

#405
post #344

Earlier quoted context omitted.

> there still doesn’t exist a core set of frameworks that are abi stable on Linux Motif ? WxWidgets ? Openstep ? Gnome and Kde do reinvent the wheel with every release, but they shoouldn't be taken seriously. There is a general problem on the SW world. They like to reinvent the wheel every now and then.

How many distros are motif and wxwindows installed on by default? How many distros come with the full GL and vulkan stack?

> How many distros come with the full GL and vulkan stack

All of the ones intended to run grahical applications. Unless extraneoous stuff like GLUT which noone should be using anyway.

Re: Make Apps for Linux

#406
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.

I'd rather use Wine than Electron tbh.

Re: Make Apps for Linux

#407

Earlier quoted context omitted.

Java simply has a much higher barrier of entry. Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. Electron isn't just cross platform, it is cross platform based on technologies (html, css and javascript) that also by a huge margin have the largest amount of developers available.

> Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. What external dependencies does Java need that's not in the JDK itself? I have an app with Mac and Windows installers (and thus bundles JDKs), it also runs on Linux (via a fat jar), I tested it on Ubuntu, but for the life of me I couldn't figure out how to package it p…

The JRE itself is an external dependency that you need to bunle because it is not part of most Linux distributions. And even if there is a JRE installed it is not guaranteed to be able to run your Java application.

Re: Make Apps for Linux

#408

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?

The JRE itself is an external dependency that you need to bunle because it is not part of most Linux distributions. And even if there is a JRE installed it is not guaranteed to be able to run your Java application.

So yeah if you redefine your problem to "run on systems with the right JRE" then Java makes things "easy" (your program will still stick out like an unpolished turd). But if you can just require stuff like that than you can also require the right dependency versions for native programs.

Re: Make Apps for Linux

#409

Earlier quoted context omitted.

> but I've never looked into what that accomplishes ABI versioning.

Oh, that makes perfect sense. I assumed there was a valid reason, and that makes far more sense than anything I could think of offhand.

Except something as fundamental as libwayland should not have an ABI version because the goal should be to never break the ABI. Well, it should also be called libX11.so.6 and extend that ABI instead of making a new ABI.

Re: Make Apps for Linux

#410
post #322
post #13

Earlier quoted context omitted.

Arch and its derivatives (mostly) don't have any of that. Though -dev means stuff only needed when developing against it. Number means major version number (so compatibility number). This way you can easily install multiple major versions as dependencies for different packages without clashing or breaking.

Arch Linux packaging is the only one that makes sense. If I install openssl, I want everything that upstream ships, which means command line tools, headers, libraries, man pages. The Debian/Ubuntu convention is terrible, and anachronistic. Disk space is cheap, my time is not.

You might but most people don't want OpenSSL headers cluttering up their system just because they installed something that needs to make TLS connections.
Post reply on HN