Linux

[keniwhat]

What did you do?

Read documentation.

What did you expect to happen?

Not see 'Linux not supported'

What happened instead?

Saw 'Linux not supported' (gasp, shock, horror)

Are there any plans for Linux support?
What is the main reason it is not supported?

Environment

Demo Project

[groue]

Hello @keniwhat

Saw 'Linux not supported' (gasp, shock, horror)

;-)

Are there any plans for Linux support?

Practically speaking, no plan from any contributor I know.

Nothing against Linux, it just happens nobody works on it.

What is the main reason it is not supported?

Two reasons:

1. Time and people (more on that below)

2. GRDB is focused on applications (Mac, iOS, etc), when Linux people usually want to run servers. The topic of servers has not been explored:

   • Does GRDB apis fit servers well?
   • Servers like to fork processes, spawn threads, and use several parallel SQLite connections. But GRDB defaults assume that all connections are managed by a single DatabaseQueue or DatabasePool instance. Does it create any problem with any GRDB public API? Can those problems be fixed with existing public apis?

---

We could right away change the sentence "Linux not supported" to:

There is no guarantee that GRDB runs on Linux. No support is provided, and you will have to fix eventual issues yourself. But motivated pull requests that fix those issues are welcome.

If you are interested in providing long-term support for GRDB on Linux, please contact us!

For example, some preliminary work was done in #354, merged in v3.0.0, back in 2018, and it was gladly accepted.

---

In order to change the "Linux not supported" sentence to "Linux users are welcome ❤️", we need to:

• Make GRDB run on Linux
• Make it easy to run Linux tests on a Mac (for contributors who don't have any Linux machines)
• Run Linux tests on CI (possibly on several distros)
• Precisely document the requirements
• Check all GRDB apis that depend on SQLite version, make sure (read: test) that they work as expected on the various supported SQLite versions documented by the requirements
• Announce the good news
• Support Linux in the long run:
  • Answer user questions and generally provide support in a timely manner (as you can see, GRDB issues DO NOT accumulate, desperately waiting for an answer)
  • Follow news about Swift on Linux, makes sure GRDB is not broken when Swift, Foundation, and the various supported distros are upgraded.

Nice to have:

• Audit the fitness of GRDB apis for servers
• Write documentation for the recommended GRDB setup on a server
• If there's a need for it, explore how database observation could be extended to support multiple concurrent writer connections.

Since I personally miss the time, and Linux experience, which would allow me to do all this work, I won't have GRDB jump on the Linux train unless at least one contributor or company shows a strongly motivated involvement. And I'll kill Linux support as soon as there remains no such contributor.