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

131–140 of 422 posts

Re: Make Apps for Linux

#131

Post by dragontamer »

berkes wrote: post #24
dragontamer wrote: post #9

Earlier quoted context omitted.

Just say Download Ubuntu and sign up at Mastodon.world. If they push back that's not a problem. If they're actually noob, they got the info they wanted out of you, which was where to start.

Why would people push back at that? I'd personally say "use mastodon.social", but your advise is just as good. Simply because it is a solid advise, offers a single option and points people at where to start . Ubuntu is good to start ¹, and if people say "but it's bad at thingy foo" or "it has default bazoombas! default! on!": no-one said it's where you must now commit yourself to forever. Distro's aren't religions (a…

> Why would people push back at that?

Because they already have an opinion on which Linux or Fediverse thing to use.

Pay it no mind. People are allowed to be wishy-washy with their opinions. Maybe its just a conversation starter, or maybe they enjoy debate / feeling things out through words and discussion.

Re: Make Apps for Linux

#132

Post by yjftsjthsd-h »

zer0zzz wrote: post #114
znpy wrote: post #91

Earlier quoted context omitted.

> and they don’t break as often. Meh, kinda. It's not a case that proprietary software vendors only target RHEL, Suse and Ubuntu. RHEL is a perfect target for stable software and Ubuntu might be as well if you decide to only support LTS releases.

Targeting only a hand full of frozen releases is not abi stability. Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too).

> Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too).

Hang on, if that's the standard why is MacOS getting a pass? I'd believe that Windows meets that bar, but I see posts on a routine enough basis about Apple forcing rewrites, unless I really misunderstood something there.

Re: Make Apps for Linux

#133

Post by FirmwareBurner »

abhinavk wrote: post #100
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…

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 childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point.

If that's not stable, I don't know what is.

Re: Make Apps for Linux

#134

Post by rubymamis »

freedomben wrote: post #120
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…

There are definitely some challenges with getting people to pay for OSS, but I wouldn't be so quick to blame that all on what happened in this situation. I think you'd be experiencing the same (or worse) if your app was closed source for reasons I'll mention in a minute. I'm the exact type of person who would be in your target market and likely to pay, but aside from having never heard of your app (which may be your…

I appreciate your opinion.

Notes has been quite a success for me. With over 1,300,000 downloads[1], and being featured in awesome tech websites[2]. Just on Ubuntu alone there are 7000 weekly active users (that have downloaded it from the Ubuntu Store).

My new app Plume is going to be a big improvement over Notes. First, your data is and will always be as simple as Markdown/plaintext. My new block editor is based completely on plain text while still offering advance views (with a minimalistic syntax). It's also faster than any other in its category, even faster than native apps on macOS! I'll soon put benchmarks on the website.

All I can say is, sign up to get an email update and check it out when it's ready. Most of the features will be free with only some advance features paid.

BTW, what do you mean by "logseq's on-disk format"? That it's local-first? If so, Plume is also.

[1] https://tooomm.github.io/github-release-stats/?username=nutt...

[2] https://www.omgubuntu.co.uk/2022/09/open-source-qt-notes-app...

Re: Make Apps for Linux

#135

Post by zer0zzz »

fragmede wrote: post #130
zer0zzz wrote: post #106

Earlier quoted context omitted.

None of that core is standardized across even a hand full of distros.

Chrome/Chromium is quite standardized, across many distros.

Name one distro that ships with chrome out of the box? I dont even think ubuntu comes with a chromium browser. That means devs cant write apps against it and just hand out exes like they do on Mac and windows.

Re: Make Apps for Linux

#136

Post by worksonmine »

rafram wrote: post #60

> Target All The Linux Distributions > Unlike other platforms, Linux is a very diverse target. There are hundreds of Linux distributions, some more popular than others. Once published though, applications can generally work everywhere. > There are well documented software packaging and distribution systems which enable developers to get their applications into the hands of users. > Each developer framework and Linux…

Most of them work the same way though. In reality there are like 3 big distributions to target, Arch, Debian and Fedora and from there it will trickle down. Linux and the *BSDs generally work the same, put the executable in the $PATH and you're good. Where this is may differ but not by much and these days the FHS is adopted pretty much everywhere I know.

Re: Make Apps for Linux

#137

Post by jancsika »

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…

> But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run.

Hm, not sure what you mean here.

At least with the nw.js toolkit (from which Electron was forked IIRC) I've never gotten a report of a distro where it would refuse to run because of an incompatible GTK version.

Re: Make Apps for Linux

#138

Post by yjftsjthsd-h »

pjmlp wrote: post #86
olddustytrail wrote: post #84

Earlier quoted context omitted.

Really? Do you communicate with ChatGPT by pointing at pictures?

That is a REPL, not a CLI.

A shell is a REPL. Though I do I agree there's something to using one with good features (ex. I would completely understand someone using exclusively zsh just for the better tab-completion).

Re: Make Apps for Linux

#139

Post by zer0zzz »

yjftsjthsd-h wrote: post #132
zer0zzz wrote: post #114

Earlier quoted context omitted.

Targeting only a hand full of frozen releases is not abi stability. Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too).

> Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too). Hang on, if that's the standard why is MacOS getting a pass? I'd believe that Windows meets that bar, but I see posts on a routine enough basis about Apple forcing rewrites, unless I really misunderstood something there.

Apple's actually quite good at this, but they do break things on purpose from time to time for reasons which they announce pretty publicly at WWDC when they do (32->64bit, deprecating GL, etc).

So, for example a dev can target an app at iOS 8 and it still works fine on iOS 17. Thats almost a decade of OS updates that didn't affect an app. Here's an example:

https://apps.apple.com/us/app/bebot-robot-synth/id300309944

Re: Make Apps for Linux

#140

Post by yjftsjthsd-h »

pjmlp wrote: post #59
dwattttt wrote: post #55

Earlier quoted context omitted.

If you consider a container to be a limited distro, we turned one into the other

I consider a container, shipping the developer's computer into production, or the revenge of microkernels, take your pick.

I mean, kind of? But "shipping the developer's computer into production" implies a lot of things that really shouldn't be happening even with containers - the images you ship in prod should always come from git (or such) by way of CI, and shouldn't include ex. compilers. So I'd argue we managed to mostly get the upsides of just shipping the dev's machine but without the downsides.
Post reply on HN