Nope. There are non-persistent in-memory databases too.

In fact, a database can be a plethora of things and the stuff they were building is just a subset of a subset (persistent, local relational database)

What I’d be interested to understand is whether changes to materials (be that buildings or home appliances) has caused an increase in the cost to manufacturer.

I’d wager most things have gotten cheaper to produce these days because the same improvements in technology that can be integrated into the product also applies to technology used to reduce the cost to manufacturer. Plus if wages are below inflation then any labour costs would have declined (relatively speaking) in that time too.

US does have some perks for sure. But there are so many issues of its own and those issues are almost always pushed downwards to the most vulnerable groups. Which means, on average, you do end up with a better quality of life outside the US.

I then switched to Wails because I wanted to add Markdown, Jupyter support. And other things too. Quickly I realised it was too much for me to attempt SDL (even just the markdown parser proved an annoying time sink) on my own. I think the terminal itself is worse for change so there might be a point when I revisit this switch and change my mind again.

There was a brief period when both Wails and SDL were supported front ends. The idea being you could chose one based on a Go compiler tag. But that proved hard to maintain.

There was also a time when the terminal was SDL and Wails just did the markdown stuff. They were different applications that passed messages via a rudimentary IPC. But that resulted in a multi-window hacky mess.

So the current design is the compromise I’ve settled on but will likely change my mind at some point again.

As for the AI, there isn’t any compiler flags to disable it. But it doesn’t work without you supplying an API key anyway. And the integration is just a few menu items so, hopefully, not intrusive. Which would also make it pretty easy to hide those options behind a compiler flag.

I’m happy to chat as a GitHub issue if you’d prefer. I don’t hang out in may other places these days (time constraints)

We constantly see people’s PII leaked on the internet, accounts hacked and money stolen, due to piss poor safeguards in the industry. And that’s without touching on the intentional malpractice of user tracking.

And yes, this is a different issue, but it’s another symptom of the same problem. Tech businesses don’t give a shit, and developers make excuses about how it’s not life or death. Except our bad choices do still negatively affect people’s lives even if we try to convince ourselves it doesn’t.

But I will admit I’ve focused more on desktop than mobile app development. And the thing about sizing stuff is it’s a much easier problem for desktop than mobile apps, which are full screen and you have a multitude of screen sizes and orientations.

And why you describe absolutely is not how any of more reputable libraries nor maintainers approach open source software.

So you might feel like you are legally correct. But you’re still completely missing the point.

Except they had been solved in other ways and the problem was people insisted on using web technologies to emulate those other technologies even when web technologies didn’t support the same primitives. And they chose that path because it was cheaper than using the correct technologies from the outset. And thus a thousand hacks were invented because it’s cheaper than doing things properly.

Then along comes Electron, React Native and so on and so forth. And our hacks continue to proliferate, memory usage be damned.

People started browsing on a plethora of devices from the Dreamcast to PDAs. And then Steve Jobs came a long and doubled down on the shift in accessibility. His stance on Flash was probably the only thing I agreed with him on too.

And the ironic thing is you are chatting on a forum that could have easily been built in 1995.

SPAs, for example, require so many hacks to work correctly that I often wonder to myself if they’re not really just a colossal mistake that the industry is too blinded to accept.

How are you trying to build it? Are you calling make? Also what OS are you on?

    make build

Yeah, I agree with you there. Most of my projects are very conservative with their dependencies; as was this one too, originally. But this project was just too large for one person to realistically manage on their own and without reusing the hard work of other libraries.

Unfortunately, the two libraries I need to lean on the most are exactly the kind of libraries that will have big dependency trees:

- GUI (Wails): just because there is a huge amount of code required to draw anything to screen

- AI (langchaingo/mcp-go): though mostly for tool use here but they’re optional

Both of these libraries were chosen because they are well maintained and have a high number of contributors/eyeballs On the code. But, as you said, the risk is still there.

And your comment that I should pay every…single…maintainer of every…single…project on GitHub, just for them to disclose whether or not their project is experimental… well that’s just insane and completely misses the point of open source.

If we are talking about businesses relying on open source libraries then that would be a different matter. But not ever fscking thing being built is a VC-backed startup.

I say all of this as an open source maintainer. Just be honest in your READMEs.

A little honesty in the README costs nothing and we should be expecting more of it. And suggesting we lock that honesty behind a paywall is possibly the worst idea for open source imaginable. That simply isn’t the right way to monetise open source.

Edit: just to add, even if we were talking about software quality (which we wasn’t) paying for software doesn’t guarantee to you a better product. I could name a multitude of commercial solutions that I gave up on because the open source alternative was at least equivalent. But often even superior. And that’s before we talk about then enshitification phenomena.

Edit 2: sorry for all the edits. I should have just waited until I had proper time to reply calmly rather than commenting while doing chores and stuff around the house. My bad.

I actually don’t like control mode much though. It’s a terrible protocol. Absolutely abysmal design which leads to a plethora of edge case bugs.

At some point I’ll replace tmux control mode entirely but for the moment it solves the immediate problem.

No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code.

Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is.

It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it.

All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is.

All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.

If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”