[HN Gopher] Make Apps for Linux
___________________________________________________________________
Make Apps for Linux
Author : jay-barronville
Score : 181 points
Date : 2023-12-09 16:50 UTC (6 hours ago)
(HTM) web link (makealinux.app)
(TXT) w3m dump (makealinux.app)
| jstanley wrote:
| The article could do with a few examples.
|
| I'm not aware of anyone who is making a distro who should instead
| be making an application. Maybe LinuxCNC if you squint?? But that
| has very specific kernel requirements which are arguably best
| served by a custom distro.
| Barrin92 wrote:
| any desktop environment is effectively just an application
| that's trivially to install via one or two clicks or commands.
| Never made sense to me why there's derivatives of derivatives
| that just ship a different DE.
| colesantiago wrote:
| 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 are the barrier to mass adoption here for Linux
| unfortunately, and the paralysis of choice is the double edged
| sword for the massive amount of Linux distros.
|
| Thousands of years of effort spread across many distributions
| that not many people would use.
| righthand wrote:
| It's because the answer is "just pick one". Many people have
| already made the decision before you and unless you have
| special requirements. You'll probably be fine.
| amne wrote:
| Unfortunately it still takes a lot of effort to actually switch
| and not just poke around to see what's what. Most things do
| work these days but inevitably you will have to open the
| dreaded terminal (or be forced into runlevel 3 because 4 now
| fails as your new TV doesn't play well with your gpu)
| dragontamer wrote:
| 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.
| berkes wrote:
| 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_ 1, 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 (and even religions can be
| switched), they are just stuff that sits on your computer.
| Your next re-install or next machine might be anything else.
|
| 1edit: to be clear: it's also good for experienced people or
| grumpy bearded linux-veterans like myself (24 years in and
| counting). I use Ubuntu. It's hardly configured even, just
| the defaults (well, my shell and vim have some 20+ years of
| config tweaks).
| dragontamer wrote:
| > 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.
| cardanome wrote:
| The Linux ecosystem isn't as splintered as people think it is.
| Yes, there are technically lot's of distros but most of them
| are really just derivatives that don't add much.
|
| The vast majority of Desktop users just use Debian or Debian-
| based distros like Ubuntu, Linux Mint and so on.
|
| So in the end, it is just a matter of whatever pre-installed
| software you get. It used to be that vanilla Debian was a bit
| hard to use but I don't think that is true anymore. (Though I
| still recommend Linux Mint for the absolute "just works"
| experience.)
|
| For 90% of users, they are not going wrong using Debian or one
| of the popular Debian-based distros. After that is is basically
| just a matter of specialized needs.
|
| Want to make administering your system a hobby and part of your
| personality? Have some Arch.
|
| Need professional support? OpenSuse.
|
| Need reproducible builds? Nix/Guix.
|
| Need a minimalist distro that runts on potatoes? Puppy Linux
| and whatever else.
|
| Wayland vs X11? Systemd? If you know these words, you are
| already way too deep in the rabbit hole.
| timfsu wrote:
| This is true for the user, but not good enough for
| developers, who unfortunately need to stay on top of all of
| this to build functioning software. If users report bugs you
| can't repro, you may have to dive into all of these.
|
| And that's the point of the article really, to try and get
| more app developers onboard.
| mcpackieh wrote:
| Developers don't need to test in every distro, or even all
| the most popular distros. All they need to do is test in
| one distro. It will probably work in most of the rest and
| linux users expect that if something breaks they'll be the
| one tweaking things to make it work. Sometimes you'll get
| bug reports from those users saying _" I had to do X on
| distro Y for reason Z"_ and you can act on those reports,
| or not. It doesn't matter.
|
| Honestly, linux users don't expect more. There's tons of
| proprietary software out there supporting linux in this
| manner and it works out fine. Linux users are easy to
| please. The hardest people to please are the developers
| with Windows/Mac backgrounds who mistakenly believe they're
| expected to test on every distro and rightly balk at that.
| zlg_codes wrote:
| What do you think we'll gain by putting every idea into the
| same cookie jar?
|
| This drive to create One True Linux is commercial behavior.
| People that want One True Linux want to put products on there
| to sell.
|
| These people need to read the GNU Manifesto and realize they
| are not in the correct social structures to push for
| centralization.
| zjp wrote:
| Maybe I'm just too ignorant to know the pattern that determines
| whether I need to specify 'dev' and 'version' on a package or
| some random trailing '1' or '0', but the first linux distro with
| a sensible and consistent naming scheme for packages is the one
| that wins my heart.
|
| `libgnutls-dev` `libgtk-3-0` `libwayland-server0` `libxcb1`
| `libx11-6` `libffi-dev` `libncurses5-dev`
| juunpp wrote:
| Separating binaries from sources is a Debian convention. If
| you're just using a library, non-dev is sufficient. If you're
| developing with that library, you'll also want -dev, which will
| install the headers.
|
| Nothing special about the trailing 1 or 0; that's just part of
| the package name/version.
| tasn wrote:
| 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.
| o11c wrote:
| If you are building a program, install the -dev package.
| Numbered -dev packages are usually not relevant; there should
| be an unnumbered one that forwards if needed.
|
| During the build of a program, you record which numbered suffix
| (= ABI version, should be the same as the .so.N suffix but
| that's not how you look it up; this allows you to install
| multiple incompatible copies of the library and they will be
| used by the appropriate, though distros usually prune these
| after each major release) is used. This should be automatic.
| (if there's more than one number, all but the last are part of
| the library name itself. There might be exceptions for BSD-
| style libraries?)
|
| When installing, you should be automatically using the
| dependency you recorded during the build.
| everforward wrote:
| -dev contains the headers, that ones pretty easy.
|
| The number is a version for when they provide more than one
| that can be installed at once (excepting where it's part of the
| library name, presumably like xcb1).
|
| I.e. at some point you could probably install libgtk-3-0 and
| libgtk-2-$something at the same time. They likely leave it that
| way when they get rid of libgtk-2 so that existing tutorials
| that reference libgtk-3-0 don't fail because the package is now
| libgtk.
|
| The libwayland-server0 one does get me, I don't know why
| there's a 0 at the end. I do know that in /var/lib there is
| often the same library with various .$number endings, but I've
| never looked into what that accomplishes.
| seba_dos1 wrote:
| > but I've never looked into what that accomplishes
|
| ABI versioning.
| tesdinger wrote:
| ABI stands for application breakage interface
| deafpolygon wrote:
| This is one of the biggest issues holding the Linux platform as a
| whole. It's often cited as a strength, but I don't see it as
| such. Many times, the plethora of choice is pushed forward by
| devs as an advantage of Linux ("you have so many choices to pick
| from!") but for many users this presents the paradox of choice -
| and pushes many people back to the platform they came from.
|
| You get less choice on macOS and Windows, but the choices
| available are much more polished and less fragmented.
|
| i.e. How many different tiling window managers do we need? Can't
| we take the best tiling wm's and start developing better docks
| and applets for them? How about apps and launchers that integrate
| with the tiling WM paradigm? Instead we end up with 10 different
| varieties of tiling wms and half-baked half-assed workarounds and
| programs for them.
| cycomanic wrote:
| I would say there are even more launchers and docks then tiling
| WMs.
|
| Also I don't know what would need to be better about them.
| Something like ulaucher or Albert is much more powerful than
| what is available in other platforms and I don't know how one
| would improve their UI.
| deafpolygon wrote:
| Maybe the work needs to go into developing better UX, not so
| much UI or what the various tools can do. Look at PySimpleGUI
| (of which I was reminded of from a recent post here) for a
| good example of a nice project for the masses - we need
| better software for users.
|
| We need better applications that have better UX.
| Muromec wrote:
| But writing a tiling wm is fun. Writing software
| collaboratively is the point in itself, not just the means of
| getting some kind of artifact in the end.
|
| Being an open source developer means having agency over your
| goals and means to get to them, which you often don't have when
| doing commercial software development.
|
| You sure end up with roughly edges, but the. IKEA-effect kicks
| in and you like it anyway.
| deafpolygon wrote:
| Right and this holds the platform back. I'm all for hobby
| development- I've been an supporter of open source software
| for over 2 decades. But nothing much has changed since that
| time in terms of UX and user-friendliness. (Yes I am aware a
| lot of things have changed, but as much as things have
| changed - much of it is still the same.)
| michaelmrose wrote:
| It doesn't hold the platform back because if the hobbyist
| didn't scratch his own itch he was never going to spend
| 1000x as much development effort creating a Photoshop
| competitor or even yet join the effort to triage gnome
| bugs. We would almost certainly just be less their
| contribution for no benefit. This whole faulty analysis
| relies on treating open source developers as a fungible
| resource like employees of a firm that ought to be tasked
| with something different. It's not so.
| zlg_codes wrote:
| Agreed. If I couldn't write my own packages for my OS and
| scratch my own itch, I'd never bother contributing to the
| big stuff.
|
| The appeal behind libre software is the power to go your
| own way. If the only way to access it was to interact
| with groups and get your things added through a political
| process, I'd have found some other thing. Too much of our
| world is wrapped up in processes and busywork and other
| empty interaction, it's a waste of time.
|
| Give me the code, the license, a text editor, and a nice
| cup of coffee, and I'm good. Hold the interpersonal
| drama. :P
| michaelmrose wrote:
| People don't make choices by exhaustive analysis they consider
| a small quantity of options and by popularity or proximity
| select one and run with it. Successful ecosystems make it
| reasonably to pick a highly visible option and come out with
| something good enough. The proliferation of Linux distros is
| largely small difference that don't meaningfully decrease
| fitness because only a tiny minority who themselves had little
| problem finding a distro think its an issue.
|
| By contrast issues like Wayland wherein your plumbing and
| hardware suddenly matter and you have to become at least
| somewhat familiar with the plumbing in order to select a usable
| set of options DO matter because they increase the chance of
| crapping out when you stroll down the aisle metaphorically and
| pick a box and end up somewhat satisfied.
|
| It honestly makes little sense to compare Mac or Windows to
| Linux. In the eyes of 95% of consumers an OS either an
| immutable characteristic of a computer or a feature thereof and
| they aren't interested in it as a separate product. They might
| well buy a computer with that OS if the overall package makes
| sense but they sure as hell wont install it on their windows or
| mac machine. Those who are technically literate enough to be
| satisfied are unlikely to be confused if people add 3 more
| Ubuntu derivatives and 2 more arch ones.
| zlg_codes wrote:
| This is a problem that is meant to be solved by distros. People
| who don't want many choices should be using a distro that makes
| a bunch of choices for them, instead of pushing to remove
| choice from the ecosysytem altogether.
|
| Everybody using the same software creates a monoculture which
| is more prone to attack than a diverse ecosystem. There's a
| reason Windows was targeted so much by viruses: not only was
| the target BIG, but it was also _consistent_. If you broke into
| one normie 's Windows machine, you could probably break into
| the rest. You're going to have a harder time of that if you
| target Linux.
|
| Also, it's libre software. Unless you pay someone to do
| something for you, most of it is volunteer activity. And who
| are we to tell someone what they should do with their volunteer
| time?
|
| It's also an indictment of the dominant social structures if
| there are all these groups and nobody wants to join them. They
| could start by getting rid of Codes of Conduct that give them
| permission to punish you for out-of-project behavior. Try that.
| deafpolygon wrote:
| > People who don't want many choices should be using a distro
| that makes a bunch of choices for them, instead of pushing to
| remove choice from the ecosystem altogether.
|
| You don't need to remove choice to push better UX and
| software. It's not a zero-sum game here; we can foster better
| conversations with people in the Linux community and start
| talking about what would make the experience better for the
| average user, not just technically proficient power-users.
|
| > Everybody using the same software creates a monoculture
| which is more prone to attack than a diverse ecosystem.
|
| That's wrong - you're using a sort of strawman argument. What
| makes Windows a monoculture? There's a much larger, thriving
| developer community on that platform with many more
| developers making free and/or open-source software.
|
| > You're going to have a harder time of that if you target
| Linux.
|
| "Achkshully..." Linux has had some serious bugs, but the
| damage was relatively low to end users because of it's low
| adoption rates. It has very little to do with "Linux is more
| secure because we're diverse" and everything to do with "1%
| of end users use Linux, so the target is less likely to be
| worth my time." And furthermore, that 1% - the majority will
| be more technically proficient and less likely to be tricked
| into running arbitrary software.
|
| > one normie's Windows machine
|
| This. Is. The. Problem. Framing an end-user as a mentally
| deficient 'normie'. Why? What's the point and what's to be
| gained from this?
|
| > And who are we to tell someone what they should do with
| their volunteer time?
|
| No one is suggesting we tell hobbyists / volunteers what to
| do with their time. What people _are_ suggesting is that we
| spend a little time talking about tackling common problems
| together, rather than re-inventing the wheel every single
| time.
| zlg_codes wrote:
| It's how the Bazaar model of development works. You're free
| to join a Cathedral and follow their policies if you want.
| zlg_codes wrote:
| Missed a few things, my bad.
|
| > This. Is. The. Problem. Framing an end-user as a mentally
| deficient 'normie'. Why? What's the point and what's to be
| gained from this?
|
| Most end-users are, okay? If _anything_ unusual happens at
| the computer they come running for the nearest nerd, poorly
| explain the problem, waste the nerd 's time when it turns
| out it was simple, and the most important part, _they don
| 't learn from the experience_.
|
| It also serves as a useful distinction between types of
| users. Normies browse the web, maybe use an e-mail client,
| some office software, maybe Steam or Zoom, etc.
|
| Power users want to explore the fullest capabilities of
| their computer. They're going to want different software
| and different experiences from the normies.
|
| Developers will want to explore how much they can do and
| control. That's _another_ type of user with different needs
| and software preferences.
|
| Frankly, I'm not interested in talking about the needs of
| average users, because more average users will cause
| communities to believe their software doesn't need advanced
| features because there are greater numbers of simple users.
| Flooding Linux with normies won't make the software any
| better. It will create an Eternal September problem where
| you'll get loads of criticism and bug reports and problems,
| but almost nobody from that crowd will have the insight
| necessary to help devs decide on solutions.
|
| There really isn't any third option. Everyman software ends
| up toddler-fied, and bespoke software overloads the
| normies. Both groups cannot be served by the same software.
| I challenge you to find any piece of software that
| adequately serves both groups.
| Kalanos wrote:
| I recently switched from Mac to Linux so that I can use beefy
| refurbished machines as my daily driver. I've installed Linux on
| lots of different machines previously, but this time it's not
| just a hobby.
|
| Ubuntu has great support for my hardware and peripherals, but the
| app store feels unfinished and forced. Pretty much everything
| works as expected.
|
| I'm interested in checking out Mint (also Debian) and Arch, but
| it feels like there's a lot of software written with Ubuntu in
| mind, so I'm wary.
| garrisonhh wrote:
| There is almost nothing written for ubuntu that won't work on
| arch or really most current distros. When I ran arch I did have
| to get familiar with assumptions people make due to ubuntu, but
| this would never be more than patching a config file or
| configuring some environment variable. And those are useful and
| transferable skills.
| Kalanos wrote:
| hmm. thanks for sharing. that's the kind of stuff I don't
| want to do though. i already have my own software to write
| and use a wide array of tools. i can't afford to lose a
| morning on that kind of stuff. plus i want to be able to tear
| down and rebuild without a ton of custom config
| cardanome wrote:
| Linux Mint is based on Ubuntu. You can use all Ubuntu packages
| just fine. It is really just a strictly better Ubuntu.
|
| There is a Debian-based Mint version as well but that is more
| as a security so that they are not deadly dependent on the
| Ubuntu people.
|
| Though these days, even using exotic distros isn't that
| problematic, as you can always use appimage/flatpack/snap if
| you native package manager doesn't have the specific app you
| need.
| znpy wrote:
| Do yourself a favor and give Fedora a try.
|
| I wish I had done that earlier.
| Kalanos wrote:
| I used AWS Workspaces for a while and that ran Fedora. It was
| nice, but I wasn't blown away. I seem to remember not being
| able to find some yum packages where there were apt
| counterparts.
| seba_dos1 wrote:
| > Stop making Linux distributions, make applications instead.
|
| Stop listening to people trying to tell you what you should do or
| not.
| whitepaint wrote:
| Stop listening to people who say to stop listening to people
| trying to tell you what you should do or not. It is not all
| relative, there are good and bad choices.
| seba_dos1 wrote:
| Not hacking on a distro because someone thinks there are too
| many is one of those bad choices.
|
| If you actually manage to get a distribution rolling with a
| viable community around it, it means enough people have
| decided that there _weren 't_ too many.
| SantalBlush wrote:
| "Gotcha" replies like this aren't helpful. The GP comment is
| just a pithy retort to the title that uses the same language
| for effect.
| whitepaint wrote:
| Agreed.
| berkes wrote:
| Yea, the tone was off-putting to me too.
|
| But the message and information is good though.
|
| I'd personally word it something like "Linux users don't want
| more distributions. They want software". At least, this is the
| case for me.
| rubymamis wrote:
| 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 Notes[1] but I find it hard to live
| on solely on ads. I tried to incorporate paying for some premium
| features (like Kanban) but the app is still fully FOSS therefore
| everyone can compile it from source easily.
|
| I think I'll close-source my next app[2] before it launches. I
| just can't risk not being paid for my hard work. I also believe
| the Linux community will benefit from that, since getting paid
| will allow me to invest more in making UX-focused apps on Linux.
| I might open source some parts of it tho (or maybe all of it in
| the far future).
|
| [1] https://github.com/nuttyartist/notes
|
| [2] https://www.get-plume.com
| thebigspacefuck wrote:
| What does this have that Joplin doesn't have?
| 360MustangScope wrote:
| For one thing, it's a lot prettier than Joplin
| thebigspacefuck wrote:
| Personally I think Joplin looks better and this looks like
| a poor macOS clone that lacks many of the features like
| markdown support or synchronizing across devices including
| mobile. IMO if Joplin's problem is the UI, or even just
| something OP is passionate about, why not contribute and
| open a PR? Why is the pattern "I care about this one thing
| so I reimplemented it in a new app from scratch"?
| rubymamis wrote:
| - Plume supports Markdown (plus additional plaintext
| syntax).
|
| - Plume is a block editor, unlike Joplin. Therefore plume
| can have advanced views inside the editor itself (like
| Kanban, image handling, columns, etc)
|
| - Plume is faster than Joplin's non-native editor (the
| one that renders your Markdown)
|
| - IMO Plume is way prettier with far more attention to
| detail.
| beebmam wrote:
| The CLI is peak UX for anyone technically competent.
| Gualdrapo wrote:
| I agree but CLI just can't cover all use cases - just on top
| of my head are graphics, animation software, video editing,
| circuit making...
| throw10920 wrote:
| Well, they think it is. Most of the time, it's not. Command-
| line tools have terrible ergonomics for many workflows and
| use-cases.
| nvy wrote:
| For a subset of tasks, maybe. But I'd rather use Firefox than
| lynx. And I'd rather use Thunderbird than mutt or pine.
| worksonmine wrote:
| I get Firefox (with keyboard navigation) over Lynx but Mutt
| has been fantastic for my productivity.
| IshKebab wrote:
| Utter nonsense. The CLI lets you do complex custom things
| that you _sometimes_ can 't do with a GUI. But it is pretty
| awful from a UX point of view. Terrible discoverability,
| terrible UI, very unfriendly, no contextual help, etc. etc. I
| can't think of a worse interface from a UX perspective.
| nilsherzig wrote:
| Terrible discoverability? A shell with tab completion is
| (in my opinion) a lot easier to navigate than for example
| Photoshops menus.
| olddustytrail wrote:
| Really? Do you communicate with ChatGPT by pointing at
| pictures?
| pjmlp wrote:
| That is a REPL, not a CLI.
| yjftsjthsd-h wrote:
| 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).
| pjmlp wrote:
| A traditional UNIX shell is more of a poor man's REPL,
| hence the difference in wording.
| fragmede wrote:
| Conversation mode, where you talk with it, is quite an
| improvement over having to type at it, especially for
| slow, hunt and peck typers.
| IshKebab wrote:
| What has ChatGPT got to do with it? We're talking about
| Unix style CLIs.
| worksonmine wrote:
| The manual exists for a reason. I find it much easier to
| type `man program` then `/whatever` until I find what I'm
| looking for rather than scanning the screen for the correct
| icon. There are also some conventions and after a while you
| get to a point where it's intuitive to use any new program.
| Just like with a GUI and icons, what does the wand do?
| IshKebab wrote:
| "You just have to read the manual" and "you get used to
| it" are basically synonyms for "the UX is bad".
|
| 1 second of googling: https://fstoppers.com/opinion/stop-
| telling-people-read-manua...
|
| I'm sure there are better articles if you search more. If
| you have time for a book, I highly recommend "The design
| of everyday things". If you don't agree with me that book
| will change your mind.
| worksonmine wrote:
| You get used to it as in "used to how CLI programs are
| usually designed". Just as you get used to what the
| select icon in a GUI does. Without any prior experience
| in any both seem like alien technology, but coming from
| GUI to CLI you have the bias of already knowing one when
| comparing.
|
| People claim macOS is intuitive and everything works the
| same, but I'm handicapped in it. I just call it
| inexperience not being bad UX.
|
| Regarding the manual, does GUI programs have a unified
| way to access guides and documentation? Can I scroll to
| the bottom with G and find the configuration files and
| example uses?
| curt15 wrote:
| That assumes that you can already articulate the action
| you are looking for in the program's vocabulary. For
| people who think more pictorially, they may have a sense
| of what they want but benefit from visual cues.
| worksonmine wrote:
| I don't target specific options, but different words of
| what I'm trying to achieve, crop/cut/extract as a pretty
| bad example. It takes me to the description of the option
| I'm looking for where it will also have useful extra
| options to combine.
|
| I can't say the same for GUI icons, many times hidden
| behind dropdowns. If I hover it will say select, then I
| have to find how to crop that selection, behind another
| dropdown, probably a few levels deep. And none of them
| searchable. If I need help there's no one place to find a
| guide, my best bet is google or the website.
|
| For both an intuition has to be learned from use, but GUI
| people act like they were born with computer literacy. I
| used to think the CLI was stupid as well, but now that
| I've seen the light I can't imagine going back.
| lupusreal wrote:
| In principle maybe, but all present implementations fall a
| bit short. Why can't I use my mouse to position the cursor in
| any shell? Placing the cursor with the mouse is something
| people commonly do in terminal editors like vim or emacs; the
| efficiency arguments against it fall flat because this is
| entirely optional and besides, many people use laptops with
| either a track-point directly in the middle of the home row
| keys or with a touchpad directly below the keyboard.
|
| And there's no technical reason it couldn't be done; years
| ago I once did it as a proof of concept. It just hasn't made
| it into any major shell yet.. besides eshell anyway. It does
| work on eshell.
|
| Anyway, it's not really a big deal, not important enough for
| me to pursue, but I do think it counts as a counterexample to
| disprove the "peak UX" claim. Command line interfaces in
| principle are great but in practice we're doing it by
| emulating hardware that went obsolete decades ago and piling
| cludges and hacks on top of that to make it feel a bit more
| modern.
|
| Another example; there are a few ways to inline images in a
| terminal emulator but they're all kind of shit in their own
| ways; graphical thumbnails have clear utility when listing
| some directories; every serious file manager supports it but
| to do this in a terminal emulator is cludgy hacks.
| pjmlp wrote:
| We should have kept using MS-DOS...
| chefandy wrote:
| That's what people who gained their technical competence in a
| CL environment always think: we're always most productive in
| the interfaces we are familiar with. I'll agree that most
| technically competent people probably prefer using the
| command line for many tasks, but _correlation != causation_.
| It 's really easy to mistake our own preferences for being
| objectively good, generally... which is why designers exist,
| why most user-facing commercial software doesn't require
| reading a single line of documentation, and why most FOSS
| projects-- almost entirely indifferent to or hostile towards
| deliberate design-- are only useful to people who have a
| working mental model of what's happening under the hood.
|
| I was strictly a vim guy for a decade and a half... my
| coworkers occasional snicker merely steeled my resolve, but I
| _knew_ I was doing the _pure_ and _efficient_ and
| _technically correct_ thing by sticking to barebones vim.
| Lots of vim stuff and ex commands are beneficial to my
| workflow, but after a coworker convinced me to try out some
| more modern options with vim modes, I realized that my
| attachment to vim as an editor was driven by my emotional
| investment in how many times I struggled with vim 's
| clunkiness. I wore it as a badge of honor. I thought it gave
| me cred. In reality it just showed how utterly inflexible I
| was. The Jetbrains editors, for example, offered more
| functionality out of the box than I could practically cram
| into my vim setup, yet was completely configurable, and the
| features were generally intuitive and discoverable. I didn't
| have to look up how to do some relatively obscure thing in
| ex-- there was probably a menu option for it so I just didn't
| have to keep it in my head. Sure, vim is and always will be
| my default editor for light editing, and there are obviously
| people whose use cases are perfectly satisfied by using it.
| However, assuming for _years_ that I was more technically
| competent for doing intensive professional work in complex
| codebases using that clunky old editor was plain old self-
| indulgent arrogance, like most other nerd badge-of-honor
| things are.
|
| I've been using command line environments daily for decades,
| and usually head there first to do many tasks, but many of
| these archaic tools only persist because of a reverse
| eternal-September problem. By the time someone gets
| technically advanced enough to start influencing how our
| technical environments work, the curse of expertise
| obfuscates their downsides and they mistake their own comfort
| with something for it being objectively good.
| curt15 wrote:
| The best CLI will never have the discoverability of any
| competently designed GUI.
| SushiHippie wrote:
| What's the difference between "notes" and "plume"?
| godelski wrote:
| Hows it different from Obsidian or any other note taking app
| that has a larger community. I'm sure OP put in lots of hard
| work and it looks good, but it's not apparent to me why I
| should abandon my existing platform (stickiness) for another
| one. There are a lot of note apps out there already which
| probably makes it hard to sell.
| rubymamis wrote:
| Plume's editor is a block-editor I wrote completely from
| scratch using C++ (model) and QML (view). This allows me to
| create an advance editor that can have complex elements (like
| Kanban, Columns, advance image components, etc) within the
| text. The performance using Qt C++ compared to Electron is a
| mssive improvement over current web apps (like Notion and the
| likes), and actually, i's even faster than native apps on
| macOS (Craft, Bike) and apps made in Flutter (AppFlowy).
|
| Example: https://imgur.com/wajSjbn (I'll implement the Kanban
| feature next week (:)
| alwayslikethis wrote:
| There is a large intersection of Linux users and people who
| cherish their freedoms. For many people, using non-open source
| note taking software is a non starter because of the vendor
| lock-in and privacy concerns. Thus, you'll probably lose out
| more by not open sourcing the program than by open sourcing it
| and risk having some people not pay. I wager a lot more people
| is willing to pay than use proprietary software. Also note that
| open sourcing doesn't require you to distribute the code to
| everyone, you can give source code only to paying users if you
| are charging them money, though they will have the right to
| modify and redistribute. If they don't care about open source,
| they might as well just use Notion or Evernote. If someone is
| looking for an open source state of the art note taking
| program, I recommend Logseq.
| lupusreal wrote:
| There are some programs that sell binaries but also give away
| the code.
|
| The premier pixel art editor Aseprite is free (source
| available, not open source) if you're willing to build it
| from source yourself, but most users buy the prebuilt
| binaries. I think this way you satisfy both the privacy
| conscious / cheapskates, and also the developer's economic
| needs. RMS doesn't approve I'm sure, but you can't please
| them all.
| rubymamis wrote:
| I'm a big believer in open source software. I've had
| wonderful contributors and I'm using qutie a few open source
| libraries/components in my own apps. That's why I open
| sourced my own app.
|
| I've tried many different options so I could make a living
| with it (ads, donations, premium features). There are
| definitely more ways to explore. But for now, I need to
| ensure that my financial situation is stable before anything
| else. Then, maybe in the future I'll be able to afford
| tinkering with a sustainable way of open sourcing.
|
| I've also started to notice many VCs starting to invest in
| open source software (just today saw Godot featured on HN).
| So that can also be a potential route.
| throw10920 wrote:
| I think you're making the right decision. Open-source is
| extremely difficult to make even a living wage off of - the
| number of people who do is orders of magnitude smaller than
| those who make a living off of commercial software.
| lovelyviking wrote:
| >Open-source is extremely difficult to make even a living
| wage off of...
|
| So are you saying it's even possible? I wish to learn at
| least one option to do it. Few is even better. How at all you
| can realistically make living this way?
|
| Ok, not living , just partial income. Ok not partial. Some
| income?
|
| I am not making fun of I honestly look some way .
|
| I understand that if you maintain 10 years some essential
| part of essential software project then people eventually
| come to you for consulting or will pay you to shift this part
| toward their requirements.
|
| But other then that? Like can you write useful free software
| program and really have some money from it ?
| throw10920 wrote:
| The main options that I'm aware of are: selling support
| (RedHat), donations (I can't recall examples but they do
| exist), open-core (GitLab), and paid hosting (WordPress).
| In the past, there was also the option of selling physical
| media (which the FSF did for GNU projects, for instance)
| but that's been killed by the Internet.
|
| All of these models are very hard to get working (e.g. the
| donations model requires that you have a very large number
| of people interested in your work who are generous with
| their money, kind of like Twitch streaming), but they _can_
| work. They 're not an option for the majority of
| programmers, though.
| shwouchk wrote:
| Joey Hess (https://joeyh.name/) did, at least partially. I
| remember him raising money to develop git annex.
| rubymamis wrote:
| It's definitely possible to make a decent living with FOSS
| software. One of the main contributors to my note-taking app
| is @bjorn[1] who developed the awesome Tiled editor[2] and
| managed to figure out a sustainable way to earn a living from
| donations/sponsorships. There are probably more instances of
| that. I tried to go the same route, but other than a $5
| monthly payment on Patreaon (thank you awesome contributor!)
| I couldn't figure it out.
|
| I hate serving shitty Google ads. They are also not a stable
| source of income and the revenue is low in my case. It's time
| for me to move on.
|
| [1] https://github.com/bjorn
|
| [2] https://github.com/mapeditor/tiled
| throw10920 wrote:
| Oh, yeah, it's totally possible - just do a HN search and
| you'll find people who are doing it (e.g. Andrew Kelley,
| the Zig designer - and he's making a _programming language_
| , which nobody will pay for in this day and age!).
|
| However, like being a social media "influencer" (e.g.
| Twitch streamer), it requires a lot of both hard work and
| luck, has a limited amount of "capacity", and isn't a
| viable source of income for most people.
| tomcam wrote:
| Thanks for sharing. Appreciate your fighting the good fight,
| and sorry for the results so far. Maybe apply for a Futo
| scholarship for one? But definitely close source for Plume.
| rubymamis wrote:
| No need to be sorry, really. I'm just learning how to
| navigate this world. I've been pretty lucky so far. Notes is
| one of the top results in Google (for the keyword "notes").
| So I get a lot of traffic and a nice passive income. But it's
| not something I can fully live on (plus it's unstable and I
| hate serving ads).
| hnlmorg wrote:
| 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.
| rubymamis wrote:
| Well, I'm a Qt programmer (and love it!), so I know a bit
| about this ecosystem. Unfortunately in terms of UX and
| aesthetics, KDE apps don't come even close to the macOS
| ecosystem.
|
| But that's alright. I'm here to change that.
| lovelyviking wrote:
| Can you share some of this 'love' to me? Because my
| experience with QT so far was : it does 'who knows what',
| 'who knows when' and 'who knows why' And if you wish it to
| work the best tactic is "do not change anything, it will
| surprise you and there will be no way to go back" :)
|
| May be I am missing something important in understanding? I
| was trying to tweak some projects for my needs. I
| successfully did it but it was a nightmare.
| rubymamis wrote:
| If you learn how to separate your logic in C++ and your
| views (GUI) in QML you can achieve the best of both
| worlds. C++ is fast and I love programming with it. QML
| is easy and powerful you can create slick looking apps
| with it with beautiful (and easy!) animations.
|
| I bought the Udemy course of Bryan[1] and learned QML in
| one day. The next day I already had a prototype for a
| Kanban[2] that is based on Markdown.
|
| [1] https://www.udemy.com/course/qml-for-beginners/
|
| [2] https://rubymamistvalove.com/notes/kanban.mp4
| lovelyviking wrote:
| Can you elaborate more? What features you are talking about?
|
| I can criticise Mac OS endlessly and was even actively
| downvoted here when reported facts of my personal experience
| with bugs on newly purchased M1 (you can dig the history if
| you wish). I was shocked how quality degraded in my opinion.
|
| People here were even claiming that it's my specific faulty
| machine was to blame. This 'faulty' machine by the way works
| to this very day without any hardware problems except
| flickering of the monitor which is idiotic in my opinion
| design decision (to use PWM).
|
| So as you can see I am very critical of macOS and consider
| using Windows after macOS like completely unbearable. And yet
| your comment have puzzled me.
|
| When I was learning macOS after years with Windows I remember
| that certain things were like you say "impossible to
| discover". Yet with all that being said I find other GUI
| implementations in GNU/Linux not any better.
|
| Perhaps I've missed something in KDE? What did I miss? What
| "doing anything beyond basic" means in your usage? What kind
| of tasks/workflows are those ? How KDE better in those?
| askonomm wrote:
| KDE _functions_ well, but my god does it need someone with an
| actual design education to help out.
| lovelyviking wrote:
| on your 'com' site mentioned in github page download button
| does not offer (near by) payed options. Why? Why it is only in
| the separated Pricing link? Why not to present the same choice
| in download ?
| rubymamis wrote:
| Thanks for your remark! I never thought about it. I suspect
| it will drive down the number of downloads? How do you think
| it will be beneficial?
| bachmeier wrote:
| A few thoughts:
|
| 1. I've never heard of your app, and I follow this space
| closely. It's _extremely_ competitive.
|
| 2. I clicked to check how much you're asking for premium. It's
| reasonable on an annual basis, but I only saw an option for a
| monthly subscription. That's not happening.
|
| 3. I'd be more likely to give you a donation than to pay for a
| premium version for an app like this. That model has worked
| well for Obsidian. I don't think getting early access to
| features is worth much, but a lot of people have paid them to
| support their work.
|
| 4. My observation is that a closed core product with a large
| open source ecosystem around it gives folks a reason to pay.
| rubymamis wrote:
| Hi! Thanks for your comment.
|
| > but I only saw an option for a monthly subscription.
|
| What do you mean? The annual subscription doesn't work? Or
| something else?
|
| > I'd be more likely to give you a donation than to pay for a
| premium version for an app like this.
|
| Well, for my Notes app, I can understand. Hopefully you will
| find my new app as a breath of fresh air in this space. Sign
| up to get an update please! I would love to hear what you
| think when the app is out.
|
| > My observation is that a closed core product with a large
| open source ecosystem around it gives folks a reason to pay.
|
| Overall, I think people will pay if an app gives them enough
| value.
| freedomben wrote:
| 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 biggest problem), these are the reasons
| I'm not buying. I'm only sharing this in the hopes that it
| helps you, not trying to make you feel bad or anything like
| that. Overall I think you're _awesome_ for making your app open
| source, and I have a mountain of respect for you for doing
| that.
|
| 1. You're targeting a very crowded and competitive market where
| top-quality options are 100% free. This would be a huge
| challenge regardless of whether you're open source or not.
|
| 2. Your app is still very young/new. Winning in such a
| saturated area is going to take some time to even build
| awareness, let alone get mature/feature complete enough to get
| people to change.
|
| 3. With something like notes, you're looking at people with
| substantial pre-existing sources. Migration is not trivial
| either, so there's a big barrier of entry there for people to
| use your software.
|
| I wish you the best, but I think you'd only be harming yourself
| by closing your next app. You definitely lose people like me
| for whom my notes are incredibly important and I won't risk
| losing them to a proprietary tool. Open is mandatory for me to
| even consider it.
|
| I'm pretty happy (maybe even in love) with Logseq, but the
| performance is definitely a downside and the idea of a C++ app
| is highly appealing to me, so I'm going to give your app a try.
|
| Side note: If your GUI was compatible with logseq's on-disk
| format, that would make your app quite compelling to me
| rubymamis wrote:
| 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...
| kilolima wrote:
| I really like the functionality of your notes app, but I don't
| think emulating Apple UI design is the solution to subpar UI on
| Linux.
|
| Linux users expect basic desktop conventions like toolbars,
| dropdown menus, and not mobile design concepts like cramming
| everything into a hamburger menu.
| rubymamis wrote:
| Have you even tried using my app? It doesn't have any of the
| "mobile design concepts" that you're talking about.
|
| > cramming everything into a hamburger menu
|
| - Import/Export
|
| - Check for updates
|
| - Start automatically
|
| - Hide to tray
|
| - Change database path
|
| - About Notes
|
| - Quit
|
| Is that EVERYTHING?
|
| No. It's not. I don't like using hamburger menus for
| everything myself. This is why the options are minimalistic.
| Look at other Gnome apps using hamburger menus, no need to go
| as far as "Apple UI" (which actually discourages hamburger
| menus for desktops apps).
| vcg3rd wrote:
| 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.
| rubymamis wrote:
| There are some amazing people that valued what I'm doing. One
| person even donated $1000 years ago. But that doesn't make it
| sustainable.
|
| I think it's time for me to compete on the market. I believe
| Plume is going to be a good addition to the pool of
| productivity apps today, but I'll let people judge that when
| it's released. I hope you will sign up to get an update[2]
| and let me know what you think of it when it is released.
|
| BTW, are you suggesting I copied Standard Notes? Not really,
| I don't like their design. Notes is in active development
| since 2014 (first commit on GitHub in 2015), back then I
| didn't even know about Standard Notes and the core design
| barely changed.
|
| [1] https://github.com/nuttyartist/notes/releases/tag/v0.8.0-
| bet...
|
| [2] https://www.get-plume.com/
| blt wrote:
| 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.
| 360MustangScope wrote:
| Imo, I think that Flutter is one of the best ways to make
| native Linux applications at the moment. It can look just like
| a GTK, macOS and Windows app and you have a more enjoyable
| experience.
| blt wrote:
| Don't know it, but from the website it looks mobile-first and
| intended for simple apps like Spotify. Don't get the
| impression that I could build something like Blender or
| Kdenlive with it. Maybe my impression is wrong, but I would
| hesitate to use a framework for a purpose that the developers
| consider fringe.
| alwayslikethis wrote:
| What's wrong with Qt? It works well enough if you want to write
| C++ or Python. Electron works on Linux the same way it does on
| Windows. GTK has some more issues on other platforms, but
| mostly works on Linux too.
| blt wrote:
| I should have said "Many people" instead of "Anyone" in my
| original comment -- edited.
|
| I would use it myself, but a lot of developers don't want to
| use C++ (too complicated) or Python (too slow, dynamicness
| becomes unwieldy for large projects). Languages in between -
| like Swift and C# - are the sweet spot for desktop GUI apps.
| nektro wrote:
| > What's wrong with Qt? It works well enough if you want to
| write C++ or Python.
|
| answered your own question
| sprash wrote:
| 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.
| underseacables wrote:
| Segmentation has been tough for a Linux newbie like myself. I
| hope there can be greater unification some day so that
| applications have one install type, and come with greater
| predictability.
| seabrookmx wrote:
| It's still annoying even if you're experienced with Linux.
| Especially if there's multiple install methods for the same app
| with different levels of support.
|
| Flatpak is the closest thing thus far, but certainly hasn't
| "won" yet.
| michaelmrose wrote:
| This is actually a solvable problem. You provide a single
| store interface where you install flatpaks and traditional
| packages. Linux Mint does a pretty good job of this.
|
| With Arch you can basically rely on system packages and the
| AUR for 99.9% of everything.
|
| Either way wrapping an interface around 1 or more method is a
| fairly trivial matter.
| zer0zzz wrote:
| 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 instead of doing it in the frameworks and
| programming languages themselves (which are what you are asking
| people to write apps in).
| smoldesu wrote:
| 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.
| zer0zzz wrote:
| 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.
| smoldesu wrote:
| 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.
| zer0zzz wrote:
| 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.
| smoldesu wrote:
| 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.
| api wrote:
| Packaging is fairly simple on Mac and Windows if you use
| the dev tools for the platform and are not doing things
| like installing services or drivers or changing OS
| configuration.
|
| Your packaged app will almost always work too. There are
| not 50 distributions of these OSes.
| zer0zzz wrote:
| exactly
| zer0zzz wrote:
| > 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...
| sylware wrote:
| 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 binaries have
| version names requiring at least a glibc 2.36 (often, rarely
| not). They have to force the right version names with... the
| binutils gas symver directive (see binutils manual) until all
| their version names are compatible with a glibc reasonably
| "old" (I would go for a reasonable 5 years... 7/8 years?):
|
| https://sourceware.org/glibc/wiki/Glibc%20Timeline
|
| Of course normal game devs have not the slightest idea of those
| issues, and even so, they won't do it because it is a pain,
| that for 1% of their market. Not to mention they better
| statically link libgcc (and libstdc++ if they use c++) to avoid
| the ABI issues of those abominations (the word is fair) which
| have been plagging game binaries for TEN F.... YEARS ! (getting
| better has more and more game binaries default to -static-
| libgcc and -static-libstdc++, if c++, gcc/clang options).
|
| There is light at the end of the tunnel though as godot engine
| is providing build containers which are very careful of all
| that (unity seems clean there too, dunno for UT5.x though).
|
| 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. And packaging properly a full google
| blink engine for binary distribution targetting a wide spectum
| of elf/linux distros? Yeah... good luck with that.
|
| elf/linux is hostile to anything binary only, that due to manic
| ABI breakage all over the board, all the time (accute in the
| SDK and core libs).
|
| If it is already that hard for game binaries, good luck with
| apps. I can hear already their devs saying: "we don't care,
| just use and install microsoft suze gnu/linux, every else is
| unsupported"... I think you get the picture where all that is
| going.
| zer0zzz wrote:
| I agree. I recall a talk from Linux Torvalds on how bad the
| glibc folks break things and why he won't ship a binary
| version of his scuba tool. If the binary breakages start with
| the darn C lib, you're gonna have recurring problems all the
| way up the stack on a regular basis I feel.
| sylware wrote:
| 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.
| zer0zzz wrote:
| 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.
| sylware wrote:
| I think there are very few c++ ABI versions on windows
| and it is easy to select the one you want until it is
| installed, they can be there side by side.
| p_l wrote:
| 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.
| zlg_codes wrote:
| _What_ language independent allocator? I 'm unaware of
| any memory interfaces in programming languages that
| aren't specific to that language.
|
| What would you use instead of malloc and free?
| sylware wrote:
| This what the "pressure-vessel" container from collabora
| (used by valve on dota2/cs2), is trying to solve... but
| now the issue is the container itself as it does _NOT_
| follow fully the elf loading rules for all elf binaries
| and does ignore many configuration parameters of many
| software packages (data files location, pertinent
| environment variables, etc), basically presuming "ubuntu"
| to be there.
|
| Basically, I have my vulkan driver requiring fstat from
| 2.33 but the "pressure-vessel" (sniper version), has a
| glibc 2.31, then it does parse partially my global elf
| loading configuration and the configuration of some
| packages to import that driver and all its
| dependencies... including my glibc elf loader... ooof!
| That level of convolution will have a very high price all
| over the board.
|
| I have arguments often with one of "pressure-vessel" devs
| because of some shortcuts they took which do break my
| distro (which is really basic and very vanilla, but not
| "ubuntu"). It took weeks to get the fixes in (I guess all
| of them are in... until the glibc devs manage to do
| something which will wreak havock on "pressure-vessel").
| Oh... that makes me think I need to warn them about that
| super new and recent ELF relocation type they will have
| to parse and detect in host drivers...
|
| On my side, I am investigating some excrutiatingly simple
| modern file format which should help a lot fighting those
| issues, there will be technical trade-offs obviously (but
| would run-ish on "old" kernels anyway with elf "capsules"
| and an orthogonal runtime). Like json is for xml, but for
| elf/pe.
|
| It seems only the linux ABI can be trusted... til Linus
| T. is able to hold the line.
| okanat wrote:
| Windows standard C and C++ ABI is stable since 2017. So
| the last 3 releases of the Visual C Compiler and C
| runtime hasn't changed the ABI.
|
| However Windows also has a lower level system API / ABI
| i.e. Win32 that's always stable all the way to Win 95.
| WinSXS sometimes helps for certain legacy apps too. This
| allows apps using different C libraries to work together.
| Win32 contains everything about the OS interface.
| Creating windows, drawing things, basic text, allocating
| pages from the OS, querying users, getting info about
| files is all stable. Win32 is the lower level of the C
| library. There is also a better separation of the
| functions in different DLLs. Win32 has multiple DLLs that
| has different jobs and they are mostly orthogonal.
| Kernel32 contains core almost system call stuff. Shell32
| contains interactions with the OS shell i.e. creating
| windows, message boxes, triggering different UIs.
|
| The surrounding libraries like DirectX / DirectPlay /
| DirectWrite that are also used by the games are also part
| of the system libs starting from 7. They are also stable.
|
| On Linux world there is no separation of the system level
| libraries and normal user libraries. Glibc is just
| another library that one depends on. It contains the
| entire lower level interface to kernel, all the network
| stuff and POSIX user access stuff. It also contains a
| component that has no job in a C library: the dynamic
| executable loader. Unlike Windows on the Unix systems the
| C library is at the lowest level and Glibc being the
| default libc for Linux and making itself the default
| provider of the dynamic executable loader makes writing
| stable ABI almost impossible. Since other libraries
| depend on Glibc and executables depend on Glibc's dynamic
| loader everything is affected by the domino effect.
| jancsika wrote:
| > 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.
| zlg_codes wrote:
| > If it is already that hard for game binaries, good luck
| with apps.
|
| Video games are some of the most complex and most difficult
| pieces of software both to build and to get right. Modern
| games are coded so poorly that driver makers have to release
| patches for specific games.
|
| It's the gamedev world that can't get its shit together.
| Valve settled on an Arch-based distro for the Deck. The
| specific distro doesn't matter since Steam already
| establishes its system requirements and comes with a runtime.
|
| Beyond that, I really don't see the issues you're talking
| about. Generally, any issues you have are fixed by symlinking
| the correct .so files. This is a side effect of targeting a
| specific version of software instead of keeping to its more
| base features. That's on the dev, not the user or distro.
|
| You act like Windows has never had ABI breakage or versioning
| problems. I'd like to see the specific issues you ran into;
| maybe there's an easy fix like a symlink.
| pjmlp wrote:
| 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
| naturally those are the winning Linux distributions for regular
| consumers.
| zer0zzz wrote:
| None of that core is standardized across even a hand full of
| distros.
| fragmede wrote:
| Chrome/Chromium is quite standardized, across many distros.
| zer0zzz wrote:
| 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.
| charcircuit wrote:
| Play Protect Certified Android and ChromeOS are popular
| ones among consumers
| zer0zzz wrote:
| Nice. Maybe more desktop distros should build on android
| as a core. That could solve a lot of problems.
| fragmede wrote:
| Chromium is the default browser on Raspberry Pi OS.
| pjmlp wrote:
| Naturally, you missed the part I mentioned it was the plan
| 20 years ago, not how it looks like today.
| zer0zzz wrote:
| tldr
| znpy wrote:
| > 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.
| zer0zzz wrote:
| 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).
| yjftsjthsd-h wrote:
| > 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.
| zer0zzz wrote:
| 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
| zlg_codes wrote:
| Such a platform is doomed to never take a step forward
| because "oh no, something changed and now I have to
| increment my dependencies".
| abhinavk wrote:
| I had read somewhere that Win32 (via Wine or Proton) is the
| most stable target for Linux right now.
| zer0zzz wrote:
| Yeah exactly!
| FirmwareBurner wrote:
| _> 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.
| zer0zzz wrote:
| The most underrated feature of windows probably ever.
| Dalewyn wrote:
| 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
| Microsoft achieves and continues to do.
| EvanAnderson wrote:
| 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
| FirmwareBurner wrote:
| There's no guarantee that all the older apps from the
| Windows 9x/XP days will work today, as some apps back
| then, especially games, made use of non-
| public/undocumented APIs or just straight up hacked the
| OS with various hooks for the sake of performance
| optimizations. Those are the apps guarantee not to work
| today even if you turn on compatibility mode.
| pizza234 wrote:
| > If that's not stable, I don't know what is.
|
| What is? An immense amount of resources (developers) poured
| into developing live patches to make applications work on
| newer version of Windows (or anyway, helping the
| application developers).
|
| It's an interesting conceptual grey area - it's not
| backward compatibility in the common sense.
|
| This is documented in the book "The old new thing" by
| Raymond Chen (it's possible also to read the blog, but the
| book gives an organic view).
|
| It's fascinating to observe how far-sighted Microsoft was;
| this approach, clearly very expensive, has been fundamental
| in making Windows the dominant O/S (for desktop computers).
| chefandy wrote:
| 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.
| FirmwareBurner wrote:
| 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?
| zer0zzz wrote:
| 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.
| FirmwareBurner wrote:
| Why is it terrible? Asking for real.
| LeoNatan25 wrote:
| Because it's not "sexy" anymore. Now "sexiness" lies with
| web crap, so Electron is a "great tool", while Java is
| "terrible".
| zer0zzz wrote:
| Well, so I can only tell you as much as I know and
| understand. Some of this pulls in some outdated
| information too.
|
| So, JVMs and languages that abstract the underlying
| machine are always going to have overhead. The original
| interpreted stack-based JVM model is really bad for
| performance because you can't do great optimizations on
| the code because you can't have a great view of the
| operands that are being defined and then subsequently
| used, on top of that you have to either JIT or interpret
| code which also has overhead. This is why Android's
| original Dalvik VM originally started by converting the
| Sun byte code format to a register based format. So, now
| you have a format you can do some optimizations on:
| great. But you still depend on a VM to generate and
| optimize for native code: that means code-caches and that
| means using excess memory to store the fast optimized
| code you want to run (which could have been evicted, so
| more overhead when you have to regenerate). Next you have
| frameworks like the classic Swing in Java that were
| frankly implemented with priorities that did not include
| having a really great and responsive experience even
| though its platform agnostic as far as the way it draws
| widgets. These days we can take GPUs for granted to make
| this approach work, but a lot of the Java UI stuff came
| from another era.
|
| I am not really sure if I am right here, but to me all
| this means that to have made the Java system work well
| for modern PCs and mobile it would have required a ton of
| investment. As it turns out, a lot of that investment
| went into the web and android instead of polishing Sun
| and Oracle's uh... product.
|
| Java's also kinda been sidelined because for years Oracle
| threatened to sue anyone that dared fork it as Google
| had, and Microsoft kinda spent a decade making C# and
| .NET more confusing than it already was so theres that
| too.
| FirmwareBurner wrote:
| _> The original interpreted stack-based JVM model is
| really bad for performance _
|
| And we addressed that today by launching a copy of Chrome
| with every app?
| zer0zzz wrote:
| yes
|
| I think it's hard to beat the tide that is the web as a
| content and app delivery system. The web is also getting
| all the billions in investment from every massive faang.
| mikrotikker wrote:
| It's got more security holes than Swiss cheese.
| creesch wrote:
| 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.
| whartung wrote:
| > 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 properly.
| It was more complicated that I cared to invest it at the
| time.
|
| As for the barrier to entry, I feel the same way about
| the web. I find the JS and Web ecosystem to be utterly
| overwhelming, one reason I stuck with Java over something
| like Electron, and the installers/footprint of the app
| are smaller to boot.
| creesch wrote:
| > What external dependencies does Java need that's not in
| the JDK itself?
|
| I mean that it doesn't come with Java itself, but you as
| a developer need to pick a UI framework and not all of
| them actually work all that well cross platform or will
| get you an actual modern interface.
|
| Edit: I should also note that the threshold for entry I
| am talking about is for people just generally starting
| out. There simply are way more resources available for
| web related development than there are for java.
|
| Also, when you start bundling your JDKs I am not sure you
| can talk about a smaller footprint anymore.
| ElectricalUnion wrote:
| > Also, when you start bundling your JDKs I am not sure
| you can talk about a smaller footprint anymore.
|
| What, do you bundle Electron source and Electron build
| environment with your Electron app?
|
| Why would you do the same and bundle Java source code +
| Java compilers in your Java app?
|
| Why would you do the same and bundle <any language>
| source code + <any language> compilers in your <any
| language> app?
|
| If you need to create a "just works without dependency
| b.s." experience in Java, you use the correct tooling for
| that, jlink.
| zlg_codes wrote:
| It's the JS kiddies. They got Node and then decided the
| whole world should be written in Javascript, lol.
| chefandy wrote:
| Java is great for making huge well-organized codebases with
| a lot of developers, especially if you've got good tooling
| support or a rich ecosystem of existing code to work with.
| Outside of that... If it was a good development ecosystem
| for native gui-based apps targeted at end users, why
| wouldn't the preponderance of native user-facing apps be
| written in Java, anyway? Ask nearly any experienced mobile
| app developer if they're more productive in Java on Android
| or Swift on iOS-- it's not even close. Sure, some of that
| is the OS itself, but a whole lot of it isn't. On the
| desktop, the one time I tried to make something with
| _Swing_ I wanted to _Fling_ my computer out the window.
| Clunky.
| zlg_codes wrote:
| As someone who uses Linux as a daily driver, I can recognize
| these gargantuan apps a mile away and stay away from them.
| They are absolute hogs of system resources, and for something
| simple like Etcher there's no excuse.
|
| Things like Electron are good for devs but bad for users. We
| have more computation power than ever and yet programs
| _still_ run slow.
| FirmwareBurner wrote:
| Oh, it gets better. Even the default Weather app shipping
| with Windows 11 is also an Electron pile of trash that uses
| ~520 MB of RAM. Just let that sink in. 500MB of RAM just to
| show you the weather forecast for the day and week. That
| was my entire system RAM of my Windows XP gaming rig.
|
| Same for the Widgets app, it's not only bad because it
| shows you news and ads when you open it, it's worse because
| it's also, you guessed it, an Electron app.
|
| Some VP in Redmond must be off their meds.
|
| I assume Microsoft just can't find devs to write C#, their
| own damn programing language for their own OS, and one of
| the dozens of frameworks they have for Windows GUI, that
| they need to resort to using Electron for what are just
| Windows-only apps.
| ziml77 wrote:
| The Weather app in Windows 11 a UWP .NET Native wrapper
| around WebView2 controls. It's exceptionally silly that
| it's basically just a web browser with predefined tabs
| and that it uses so much RAM, but it's not Electron.
| FirmwareBurner wrote:
| Oh my bad. I think I saw it call Edge and I assumed it
| must be Electron.
| chefandy wrote:
| Worse for users than nothing? IT shouldn't be a default,
| but if it's that or nothing-- as it often is when it comes
| down to limited resources-- I think it's better than
| nothing. If you're looking to make a useful tool for a
| broad audience that must run locally, you _have_ to support
| windows because that 's where 80% of the users are. You
| _should_ support OSX because that 's where 15% of the users
| are. That's two codebases with dramatically diminishing
| returns. You need a damn good reason to justify adding
| ANOTHER codebase on there to scoop up the remaining handful
| of users on Linux.
|
| Also, aside from startup time, I don't have any trouble
| with electron apps running slow on my machines. I think
| many developers are conceptually annoyed with the absurd,
| bloated architectural underpinnings rather than the
| experience that translates into when using them. Perception
| means a lot when judging performance, and I'll bet with
| most end users using, say, slack, the speed of their
| internet connection affects the speed of their work more
| than the speed of the application.
| prmoustache wrote:
| Your postulate that it is electron or nothing is wrong
| from the very start.
| chefandy wrote:
| You postulate that I said that, which is wrong.
|
| > IT shouldn't be a default, but if it's that or
| nothing-- as it often is when it comes down to limited
| resources-- I think it's better than nothing.
|
| _Sometimes_ it is. _Sometimes_ it 's not. It's certainly
| an option that's very efficient for dev resources, which
| is often the primary limiting factor. It's certainly the
| only real option if you've already got a team of web
| developers, which is very common.
|
| The current state of commercial software supporting linux
| with native apps is a pretty good indicator of how
| companies are viewing this equation. The amount of
| resources it takes to make a native java app is vastly
| different than the amount of resources it takes to make a
| native electron app. If you don't understand how that
| would be something that would open the possibility of
| supporting linux in many cases, I'm not sure what to tell
| you.
| jwells89 wrote:
| If I could have that spread of frameworks that macOS offers on
| Linux, I'd be targeting Linux with my side projects yesterday.
| Having such a wide selection of tools to readily reach for with
| zero consideration about how long it'll be supported, which
| fork is best, how well it meshes with a pile of other third
| party libraries, etc is amazing. It reduces friction massively
| and you just build stuff.
|
| The KDE Qt ecosystem and its GNOME/GTK analogue are closest but
| still aren't quite there.
| tempodox wrote:
| 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.
| zlg_codes wrote:
| Which libc?
|
| There's glibc, musl libc, etc. Also consider you may be using
| the functions incorrectly.
| squarefoot wrote:
| More software? Wonderful! I'm all for it, but before starting
| something from scratch why not contribute to something that
| already exists, or possibly pick some project that was abandoned
| or simply needs to be worked on for example to be built with
| newer compilers, run on newer hardware, etc. Which makes me
| wonder if there is somewhere a database of dormant/dead projects
| that would deserve to be resurrected.
| nmstoker wrote:
| Yes, I would echo this. In most categories there are loads of
| subpar efforts when putting all that effort behind the top few
| would yield a handful of excellent apps.
|
| Collaboration can seem daunting and hard work, but it's work
| that will yield results which is time better spent than that
| devoted to projects that end up abandoned.
| zlg_codes wrote:
| Who gets to take the credit?
|
| I'm not convinced these efforts to put everyone's ideas in
| one place and one software are good. Often, design
| disagreements arise which are incompatible. Under this model
| of "everybody love everybody" lameshit, if you can't get the
| group to accept your idea, it doesn't happen.
|
| You don't run into this problem when you write alone.
| zlg_codes wrote:
| That something that already exists may not be built in the way
| you are aiming for.
|
| That other something might be led by a dickhead that you can't
| get along with, or a community that's not receptive to your
| suggestions or patches.
|
| Social processes and blockages can lead to losing motivation to
| contribute. Not everyone is cut out to be this happy-go-lucky
| team player that has no personality.
|
| As for myself, I'd rather start from scratch because 1) I'll
| control every variable, 2) I don't have to mess around with
| some existing social and tech infra, 3) I don't have to talk to
| anyone and convince them my ideas are good, 4) who wants to
| spend more time arguing or discussing than writing code?
|
| The solodev experience is just better. You're not hamstrung by
| politics and social process. Being a team player has only led
| to misery for me.
| pjmlp wrote:
| > Too often they fall into the trap of creating more Linux
| distributions. We don't need more Linux distributions. Stop
| making Linux distributions, make applications instead.
|
| Right on the spot.
| dwattttt wrote:
| If you consider a container to be a limited distro, we turned
| one into the other
| pjmlp wrote:
| I consider a container, shipping the developer's computer
| into production, or the revenge of microkernels, take your
| pick.
| yjftsjthsd-h wrote:
| 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.
| pjmlp wrote:
| There are plenty of blog posts about how containers work
| in Linux is still dependent on external resources, unless
| care was taken when creating those images.
| danans wrote:
| > Target All The Linux Distributions
|
| If you are going through the trouble of targeting _all Linux
| distributions_ , why not just target _all platforms_ by using a
| framework like Flutter or React?
| zb3 wrote:
| I hope nobody will take your comment seriously, because the
| performance of these is horrible compared to "truly" native
| apps
| danans wrote:
| I've seen few apps anymore whose performance is bounded it by
| the choice of UI framework.
|
| If they're slow, it's usually because of design choices, like
| making common user interactions wait to retrieve data.
|
| Yes, games are an exception. But for the majority of software
| that is concerned with displaying text, it doesn't matter a
| hill of beans if you use a cross platform framework. We're
| far past the days of slow Java AWT apps.
| fullspectrumdev wrote:
| Then you are stuck using basically a browser wrapper for your
| UI, which frankly _sucks_ for performance and native
| integration most of the time.
|
| The move to making everything a webapp is great for development
| velocity right until you smash into one of the many, many
| corner cases where it sucks.
| danans wrote:
| > Then you are stuck using basically a browser wrapper for
| your UI,
|
| AFAIK, Flutter compiles to native code, no browser needed.
| rafram wrote:
| > 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 distribution will have their
| own recommended route to users. When you're ready to share your
| creation, the development documentation will signpost their
| suggested packaging guides.
|
| "Your apps will generally work everywhere" and "there are
| hundreds of distros and you have to do work to support each one
| individually" are essentially contradictory, no?
| worksonmine wrote:
| 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.
| zb3 wrote:
| Why would anyone do this given a) it's harder and b) linux users
| don't pay for stuff not worth paying for?
| oooyay wrote:
| There's also wails.io that is a much better alternative to
| Electron, imo, and uses native APIs for OS functionality. Added
| benefit: Wails is also cross platform.
| georgeoliver wrote:
| I'm definitely for more guided resources on making Linux apps
| from idea -> release, which I wish TFA was more of.
|
| I think there's a common misconception that if the developers of
| ten similar apps would just pool their resources, then one great
| app would result. Fragmentation certainly can be a problem but I
| feel like this is some kind of corollary to the mythical man-
| month.
| jay_kyburz wrote:
| Does anybody have much experience with the difference between
| Electron and NW.js.
|
| Electron seems to get all the limelight, but from reading the two
| websites, nw.js sounds like a better solution to me.
| tumdum_ wrote:
| Is this a parody site?
| nektro wrote:
| instead of getting more people to make new apps, gnome and kde
| should be trying to coral developers to improve the existing ones
| germandiago wrote:
| Looks nice but in my experience, developing apps only for Linux
| is not cost-effective.
|
| I would choose WxWidgets or Qt and add some extension points
| where needed via interfaces to keep the codebase portable.
|
| Sticking to just native APIs is just locking yourself down into
| Linux.
| emptysongglass wrote:
| There's a lot of complaints that there isn't much in the way of
| tooling to create cross-OS compatible apps but I disagree. Just
| looking at solutions which aren't Electron:
|
| - Telegram uses Qt and ships a performant native app across all
| three OSes
|
| - Flutter compiles down to native code across all three (and
| mobile)
|
| - Kirigami is a QtQuick framework that will give you an
| executable app across all mobile and desktop targets
|
| Go and build your app. There's no reason this needs to an excuse
| to flame on Linux.
___________________________________________________________________
(page generated 2023-12-09 23:00 UTC)