Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Make Apps for Linux

makealinux.app

Post reply on HN
Print view View original

291–300 of 422 posts

Re: Make Apps for Linux

#291

Post by phone8675309 »

sylware wrote: post #80
zer0zzz wrote: 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…

Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their bin…

If they're going to put the game on Steam then they should be using the Steam Runtime which is available here[1]. Otherwise they're shooting themselves in the foot.

[1] https://github.com/ValveSoftware/steam-runtime

Re: Make Apps for Linux

#292

Post by kcb »

hnlmorg wrote: post #68
rubymamis wrote: post #20

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 is the definition of all UI and no UX. Like there's no one actually planning out how a user would/should actually use the thing. That's why I generally prefer Gnome despite it's faults. Even if I don't agree with every decision and lack of customization at least it feels like there's some vision on how it should be used.

Re: Make Apps for Linux

#293

Post by __MatrixMan__ »

colesantiago wrote: post #4

This has always been an issue for Linux adoption. Somebody I know (not in tech) wanted to switch from Windows to Linux and I said: "Which one?" It's the same as Mastodon. "Which instance?" The answer is usually the biggest / most popular instance or distro, but not many applications the masses use are on Linux, the same as there is not many interesting people on Mastodon for people to switch over to it. Applications…

> Thousands of years of effort spread across many distributions that not many people would use.

That's a lot more effort towards improving the commons than we'd have gotten if doing it your own way were discouraged. Effort is not fungible, when you squash somebody's creativity it stays squashed for a while.

Re: Make Apps for Linux

#294

Post by michaelmrose »

isodev wrote: post #280
zer0zzz wrote: 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…

Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments. At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.

The "feel" of the app is identical across distributions because the app controls everything inside its window and the look only varies slightly in terms of colorscheme and window decoration if that.

There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic browser experience is simply a website on platforms where fast cpus and 14-28" screens are normal.

Nobody needs a bunch of adware apps you can pay $3 to decrapify or games that are a slog if you don't buy fake potions for real money.

There are enough good free basic apps for virtually any use case and the more complex use cases need up front investment and users not in app purchases.

What use case do you imagine for this feature?

Re: Make Apps for Linux

#295

Post by userbinator »

Zambyte wrote: post #276
Dalewyn wrote: post #202

Earlier quoted context omitted.

It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95 , that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993 , and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Mi…

> It's downright mythological what Microsoft achieves and continues to do. This seems like it was meant in a positive way, but I really don't think that if compatibility with your system requires "mythological" efforts, that should be seen as a good thing for your system. It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX so…

Early UNIX software can run fine on modern GNU by just compiling it.

...providing you can find a suitable compiler that isn't obsessed with exploiting undefined behaviour.

Re: Make Apps for Linux

#296

Post by userbinator »

FirmwareBurner wrote: post #231
EvanAnderson wrote: post #208

Earlier quoted context omitted.

NTVDM could have been ported to 64-bit Windows, but MSFT declined to do so. Leaked Windows source code shows it would have worked[0]. That would have given 16, 32, and 64 bit compatibility. [0] https://github.com/leecher1337/ntvdmx64

I don't get it. Would NTVDM have been better than say, using DOS-box?

Yes, because it's integrated far more closely with the system.

Re: Make Apps for Linux

#297

Post by anonyme-honteux »

pjmlp wrote: post #82
zer0zzz wrote: 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…

That core would be GNOME or KDE frameworks, coupled with the FreeDesktop standards, at least that was the plan about 20 years ago. However as the site says doing distributions is what most folks keep doing, and naturally there isn't a single stack that can keep up with snowflake distributions. In the end, Google took the Linux kernel, placed two core set of frameworks, one in Java, and the other in JavaScript, and na…

You are talking about Android and Chrome OS right? I agree, those are the top two Linux distributions, and everything else is behind by an absolutely huge margin

Re: Make Apps for Linux

#298

Post by tempodox »

zlg_codes wrote: post #161
tempodox wrote: post #149

Earlier quoted context omitted.

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.

Which libc? There's glibc, musl libc, etc. Also consider you may be using the functions incorrectly.

Seriously? “You're holding it wrong”? Read the comment at the crash site (line 584) yourself:

https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/gen...

Re: Make Apps for Linux

#300

Post by arp242 »

Dalewyn wrote: post #202
zer0zzz wrote: post #143

Earlier quoted context omitted.

The most underrated feature of windows probably ever.

It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95 , that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993 , and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Mi…

Linux can do this; binaries from the 90s work today.

Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it.

The problem running the binaries is:

    % ldd ./usr/X11R6/bin/xv
        linux-gate.so.1 (0xf7f82000)
        libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000)
        libjpeg.so.62 => not found
        libpng.so.2 => not found
        libz.so.1 => /usr/lib32/libz.so.1 (0xf7e08000)
        libm.so.6 => /usr/lib32/libm.so.6 (0xf7d0b000)
        libc.so.6 => /usr/lib32/libc.so.6 (0xf7a00000)
        libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7cde000)
        /lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f84000)
        libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7cd8000)
        libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7cd1000)
And Windows has exactly the same problem, but the tradition is to ship these things with the application rather than just assume they're present on the system. And you can "fix" it by getting old versions, or even:

    % ln -s /usr/lib/libjpeg.so.8 libjpeg.so.62
    % ln -s /usr/lib/libpng16.so.16 libpng.so.2
You'll probably run in to trouble with PNG and JPEG files, but e.g. loading/saving GIF and whatnot works fine. Note how libc and libX* work out of the box.

tl;dr: much of the "Windows compatibility" is just binaries shipping with all or most dependencies.

Try it yourself: http://www.trilon.com/xv/downloads.html

Post reply on HN