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

371–380 of 422 posts

Re: Make Apps for Linux

#371

Post by chefandy »

zlg_codes wrote: post #325
chefandy wrote: post #255

Earlier quoted context omitted.

Reread what I wrote. I'm not saying they're sane technical decisions and I'm definitely not saying that electron is an objectively good architecture for user-facing apps, and I'm definitely not saying that profit is a good way to determine an ideal engineering strategy. But trying to discuss the viability of an option in real-word software creation without acknowledging that profits are often the driving factor in th…

Part of that is because profit should not take precedence when making a technical decision unless you are a business. The other part is that if we accept only things that lead to easy profit, we'll avoid all sorts of things that take more initiative but become better products. Short-term stock price chasing is not a way to make tech decisions. It's a way to make profit decisions. I seem to be on a website where nobod…

> I seem to be on a website where nobody can picture doing anything without taking money from someone else.

And by the way, I'm not remotely capitalist, but I don't have the privilege of expecting the rest of the world to operate like I wish it would. In the US, unless you're independently wealthy, you've got to work to eat and feed your family, as I do, living together in a tiny apartment in a modestly priced city. Unless you're well-supported enough to spend a ton of time volunteering, which I am currently not, you've got to pull in money for what you do far more often than you give it away. Ignoring the realities of resource distribution in our society means you're more interested in patting yourself on the back for political and ethical purity than actually making a difference in people's lives. I've met a lot of people like that in political circles: their parents supported them and they were more interested in 'cred' and feeling cool than progress.

After years of hoping volunteer-driven FOSS would revolutionize our world, I now realize that the preponderance of developers are way more interested in coding as an intellectual exercise than solving real people's problems with their code. Think I'm wrong? Try putting in a PR, or heck, even a comment on an issue proposing some way to make something easier for non-technical users, and if anybody even responds, it will be to flame it into outerspace while essentially saying "they should just RTFM," or reflexively bikeshed it into oblivion. But what about all of those amazing well-loved heavily used FOSS apps popular among non-technical users, you might ask? Blender? Signal? Tally up the ones that aren't grant-funded and managed by people tasked with making the biggest impact possible with the resources they've got. I'd be pretty surprised if any of them had the luxury of choosing their tech stack completely independent of the resources required to develop with it.

Re: Make Apps for Linux

#372

Post by zer0zzz »

hulitu wrote: post #344
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…

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

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

Re: Make Apps for Linux

#373

Post by mikrotikker »

samus wrote: post #305
mikrotikker wrote: post #200

Earlier quoted context omitted.

It's got more security holes than Swiss cheese.

You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.

I'm living in the future. We have golang and rust now. Java is a pile of junk and should be relegated to the past.

Re: Make Apps for Linux

#374

Post by chefandy »

whartung wrote: post #282
chefandy wrote: post #257

Earlier quoted context omitted.

Java FX seems better than swing, but it's an external dependency now though, isn't it? I thought it got removed from the jdk a few years ago.

It was. Even before it was more "bundled" with the JDK than "part of Java". But, to be honest, that's a real nit. It's a standalone dependency, it's 4 lines in a POM file, it doesn't drag the internet with it, and it only relies on the JDK. So, while it's a large subsystem, it's a "low impact" dependency in terms of side affects and complexity.

Makes sense. I worked a bit with Java years ago, but never with GUI stuff. Most of what I remember about it was drowning in boilerplate and being really good for coordinating a lot of developers around a big well-organized codebase. I probably couldn't write hello world from scratch without reference if I was being held at gunpoint.

Re: Make Apps for Linux

#375

Post by joveian »

penteract wrote: post #302
Zambyte wrote: post #276

Earlier quoted context omitted.

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

> It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it. Have you ever tried building decades old programs from source? It's not as easy as you claim. Here's source for grep from v6 unix. I'd be interested to know the smallest set of changes (or flags to gcc) needed to ge…

Note that this is not a fair comparison since that code is almost 50 years old, predating ANSI C and before even the 8088 existed.

Still, there is only one actual error in gcc 13.2.1 which is the use of =| instead of the later standardized |=. I'm not sure if that was a common thing back then or if it was specific to their C compiler. Either way, I don't think gcc has a switch to make it work. Switching that around in the source gives linker errors since it seems back then the way to print to or flush a particular file descriptor was to set a libc variable and then call flush or printf. If you had the right libc to use with it that one tiny change might be all you need. But you would likely need to set up a cross compile to be able to use the right libc.

My understanding is that most of the compatability issues on Linux are due to not having the right libraries rather than the kernel not supporting older system calls. It is just a lot of not that fun work to keep things working and no one is that interested (instead, some people just use decade old versions of Linux :/ and the rest use package systems to recompile stuff). NetBSD had better practical binary compatability for a long time, although I think some of it was remove fairly recently since there isn't much commercial NetBSD software (there was one lisp binary from 1992ish IIRC that some people were still using and I think that compat was kept).

Re: Make Apps for Linux

#376

Post by AnthonyMouse »

zer0zzz wrote: post #279
AnthonyMouse wrote: post #235

Earlier quoted context omitted.

The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux: 1) The system package manager. It will download a binary from the repository which is the right one for that system. 2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a bin…

That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.

What exactly is wrong with it?

If you have a stable widely used application suitable for being installed by unsophisticated consumers, have the distributions put it in their package managers. This is hardly any different than consumer mobile platforms that require you to use an app store, except that it isn't actually required, just the thing you ought to do absent a good reason to do otherwise.

If you're distributing something sufficiently esoteric or experimental that the package managers won't touch it, your correspondingly sophisticated or adventurous users can compile it from source.

We don't need some malware-facilitating norm that encourages users to install opaque binaries from random websites.

Re: Make Apps for Linux

#377

Post by penteract »

joveian wrote: post #375
penteract wrote: post #302

Earlier quoted context omitted.

> It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it. Have you ever tried building decades old programs from source? It's not as easy as you claim. Here's source for grep from v6 unix. I'd be interested to know the smallest set of changes (or flags to gcc) needed to ge…

Note that this is not a fair comparison since that code is almost 50 years old, predating ANSI C and before even the 8088 existed. Still, there is only one actual error in gcc 13.2.1 which is the use of =| instead of the later standardized |=. I'm not sure if that was a common thing back then or if it was specific to their C compiler. Either way, I don't think gcc has a switch to make it work. Switching that around i…

Thanks for the details, I did give compiling it a try and saw some of the things you mention, but my knowledge of C, pre-standards C, and libc wasn't enough to fully make sense of them. I'll agree it looked better than I expected; I've seen much worse cases of single-decade old programs not compiling/working (one in Haskell and another involving C++ and Java, although they were much larger programs).

But I don't think it was unfair to use that as an example of early Unix software, or to point out that it was harder than "just compiling it". One defense against my argument could be that a version of 'grep' has been maintained through C versions and operating systems, with source code availability playing a part in that (although presumably GNU grep avoided using Unix source code).

Re: Make Apps for Linux

#378

Post by cout »

FirmwareBurner wrote: post #133
abhinavk wrote: post #100

Earlier quoted context omitted.

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

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

In a world where security flaws are so common, I'm not sure I want to run old software outside a virtual machine.

I also wish I could agree that win32 is a stable target on Linux; it may run old software, but in my experience it is often quirky. It's usually a better use of my time to just boot windows thanks to figure out how to get software to run under wine.

Re: Make Apps for Linux

#379

Post by LargoLasskhyfv »

jwells89 wrote: post #356
WillAdams wrote: post #355

Earlier quoted context omitted.

Have you looked into GNUstep? https://gnustep.github.io/

Yep, have been aware of it for a long time. It’s great in concept but as far as I’m aware a good deal behind current macOS — last I knew it was compatible with OS X 10.6 (released 2009) with no support for Swift or for any of the advancements in Objective-C made since then. I’m also not sure how well GNUStep apps would fit into a modern GTK or Qt-based desktop, e.g. if they’d theme controls to match.

Have you had a look at https://github.com/trunkmaster/nextspace ?

Re: Make Apps for Linux

#380

Post by rubymamis »

freedomben wrote: post #361
rubymamis wrote: post #309

Earlier quoted context omitted.

Thanks! With Plume I use a tree data structure (just with parent child relationships), although in the future I would probably use Boost::ptree. The things is, the underlying data structure is just plaintext, so having an ID for each block will make the plaintext look out of place (say, if you wanna move your files to another app). But I'll add some special syntax to allow this feature for specialized blocks.

> so having an ID for each block will make the plaintext look out of place (say, if you wanna move your files to another app). Indeed, this is definitely a problem for Logseq. For example here's some of my recent Logseq notes. This is one page where you can see an "ID" (represented by `id:: ` is created. Then helpful images/diagrams are displayed. This is then referenced later: - Parts of a [[Neuron]] id:: 64f4bdc3-2…

That's actually not too bad, and similar to what I plan to do. They only create an ID for a block/bullet-point when necessary.

I just noticed Logseq doesn't support selecting and editing text across multiple blocks. It's indeed not easy to do, but Plume does support this, I believe it's an essential feature for a text editor. Notion took a long time until they supported this[1]. I implemented it in less than a month using C++ and QML, a testament more to the strengths of Qt than to my own skills as a developer.

[1] https://www.notion.so/releases/2022-01-19

Post reply on HN