__bb

The other replies make fair points, but tillage does still have it's uses.

Quick examples:

  - Inversion tillage (ploughing) to bury green manure crops or bulky organic manure
  - Subsoiling (deep tillage) can help break underground compaction, to allow better root penetration
  - Working with soils prone to surface capping

  - Full inversion tillage
  - Low/min-till
  - No-till

EDIT: This is a response to the question "why do it?" rather than anything in the context of the article itself.

Whenever I read about poisoning LLM inputs, I'm reminded of a bit in Neal Stephenson's Anathem, where businesses poisoned the the internet by publishing bad data, which only their tools could filter out:

So crap filtering became important. Businesses were built around it. Some of those businesses came up with a clever plan to make more money: they poisoned the well. They began to put crap on the Reticulum [internet] deliberately, forcing people to use their products to filter that crap back out.

When I'm in a tinfoil hat sort of mood, it feels like this is not too far away.

EDIT: There's more in the book talking about "bad crap", which might be random gibberish, and "good crap" which is an almost perfect document with one important error in it.

There’s an archive of older versions here: https://files.menial.co.uk/base/

This app is great for writing code comments when you hit one of those “1000 words or 1 picture” cases for an explanation of something.

Just checked and my most recent document is a diagram of data flows between two services.

Highly recommended.

If the code were available I would 100% expect that someone else would distribute a binary with the paywalled features unlocked and that my original version would be relegated to secondary.

I know you could make the argument “the right license wouldn’t allow that”, but that would only be enforced if you follow up through the courts, perhaps internationally. I just can’t be doing with the hassle unfortunately.

That’s not me. I was quite surprised - in a good way - to find it there.

One of the things I found limiting in previous versions was supporting older versions of macOS. I’ve decided this time round to only try to support the latest and previous versions. Since the release of Tahoe is probably quite soon, I’m starting with just macOS 15 and will support that and macOS 26 to start.

And I welcome the feedback, even if I probably won’t follow it. If everyone thought like you do, then it’d be far nicer to publish the code and maybe charge for support. I’m fairly confident that not enough people feel the same way to make it work.

As to pricing, I need to be able to financially justify the time spent working on the app, and the price is one that I hope will let me do that.

In this case, no. It would be nice if it did though.

There’s two main reasons. One is that this is the first paid update in 14 years. The second is that it’s just such a pain to do that on the App Store and I don’t want to have a two-tier system. I’ve tried to strike a balance on the price bearing this in mind.

To add to what xmprt and msephton have said, people have told me they use it for:

  - Storing results for scientific research
  - Local analysis of data exported from server-based databases
  - Experimenting with database designs before exporting SQL to codebases
  - Maintaining relational data where a website or app are not needed (eg. tutors keeping client records)
  - Recovering data from databases used by other products (eg. phone backups, discontinued apps)

Thank you. I don't have any other public apps at the moment.

Because I don't have the capacity for maintaining compatibility between too many versions of macOS. For v3, I've stated the goal - not guarantee - of supporting the current and previous versions of macOS.

Since Tahoe is likely to be released in the next month or so, I judged it better to start with Sequoia and keep it supported rather than start with Sonoma and risk needing to drop it shortly after launch.

I realise you’ve hinted at it, but also think it’s worth explicitly pointing out that it’s more about the number of users writing than just user count. It can handle concurrent readers with little bother.

For those who’ve not seen it already, there’s a good guide on when to use SQLite here: https://sqlite.org/whentouse.html

Thanks! While it has been quite the career change, I am absolutely up for discussing both dairy farming, software development and their overlap. That’s where Base came from!

It's a bit too soon to tell reliably, since I've shipped v3 as a new app and it hasn't settled down yet. For v2 it used to be 60% App Store and the remainder direct/Setapp. So far for v3 it is approximately 60% direct, 25% App Store and 15% Setapp.

This is a bit of a shift, but the numbers aren't really stable yet so it's hard to tell if it'll stay there.

Thanks!

Auto-enabling foreign keys absolutely should be an option. I'll make a note of it.

I don't know about auto-loading extensions though. Will have a look. That might not mix well with the App Store rules and I'm reluctant to let the direct/app store versions drift apart in terms of features.

Sort of, yes. But mostly that I don't want the app to become the "everything to everyone" style of editor. I want it to remain tightly focused on the features that SQLite provides.

It's unlikely that I'll add a form builder or report generator to the app. I don't want it to grow until it can send email.

Thanks, I'll make a note of that. It's not a behaviour I've seen before.

Thank you for the support :)

To my (biased) mind the advantages are:

- It fits with the system better and behaves more like other macOS apps

- I believe Base has better create/alter table support

However Base doesn’t (currently) have support for SQLCipher.

A lot of people use it as a step up from Excel.

I’ve got quite a few scientists using it for data analysis, a whole bunch of people importing sales data for querying.

A good number of folks never write any SQL and just use the GUI to sort/filter data.

I’ve also heard from people who use Base to design a schema and then export the SQL into their codebase.

EDIT: I should add that Base does nothing that that the command line tool can't. But it does offer more convenience, particularly for those who might be less comfortable writing SQL.

It's not required, but you can if you want :)

As others have said, this is written using AppKit and SwiftUI, which are only available for macOS.

This makes for a much nicer app for mac users, even if it does cut your potential audience.

That's a good point and something I'd not considered.

I'd say the main benefit is that it's tailored only to SQLite's features.

You don't have to tweak a UI tailored for remote connections to work with local files. You don't need to have extra sections dedicated to user management or stored procedures which are inactive. I guess I'm saying that in this case less is more!

Thank you for the support! It means a lot.

I use Paddle (https://paddle.com/) as merchant of record because I don't want to deal with the paperwork of doing more myself. In practical terms, it's a key emailed after purchase.

Thank you, that's very kind. I've always like the idea of TUIs, but found it hard to get used to them.

Yes, it's OK to do that, but not to cross the streams. You can't advertise direct purchases from the Mac App Store version.

Farmers are experts in breeding cattle. Point. Not more, not less.

I hope you're going for hyperbole here. If not, you may be surprised at the proportion of farmers who do understand how biology works; who do work with vets and other professionals and follow research into animal health and disease.

Your statement does a large number of people a disservice.