kindle-dash VS go-mysql-server

Instead of using a cronjob you can put the device into sleep and use the RTC to schedule the next wakeup (see [1]). This takes only very little power, as the device is only turned on for mere seconds and sleeps the remaining time.

[1] https://github.com/pascalw/kindle-dash/blob/main/src/dash.sh...

The stopgap solution for this is pascalw's kindle-dash[1]. I set it up on my jailbroken kindle and now it displays some headlines, my google calendar events, and the weather (via OpenWeatherMap API)

[1] https://github.com/pascalw/kindle-dash

This thread or this project might be what you're after. The first is a full screen browser, the second is replacing the screen saver image and going into sleep mode.

Hey HN, I built this project because last year I did a terrible job of actually taking time off work and needed a way to see just how overdue I was to take a day off.

Because so much is already automatically tracked in my calendar (e.g. the HR system adds calendar events for booked holiday), I just needed a way to query it to get the metrics I wanted.

Originally I used a Go MySQL implementation to evaluate queries but it was a bit buggy and didn’t support all the SQL I wanted. Now I’m using a full SQLite database for each user so you can really do some gnarly queries (recursive CTEs, window functions, the works).

Personally, I’m using QueryCal as a Grafana datasource to power a dashboard that’s displayed on an old Kindle on my desk (using this great project: https://github.com/pascalw/kindle-dash).

You will have to compete with much cheaper ideas like this kindle-based dashboard https://github.com/pascalw/kindle-dash

discussed a while ago here: https://news.ycombinator.com/item?id=25939042

We implemented a query optimizer with a flexible intermediate representation in pure Go:

https://github.com/dolthub/go-mysql-server

Getting the IR correct so that it's both easy to use and flexible enough to be useful is a really interesting design challenge. Our primary abstraction in the query plan is called a Node, and is way more general than the IR type described in the article from OP. This has probably hurt us: we only recently separated the responsibility to fetch rows into its own part of the runtime, out of the IR -- originally row fetching was coupled to the Node type directly.

This is also the query engine that Dolt uses:

https://github.com/dolthub/dolt

But it has a plug-in architecture, so you can use the engine on any data source that implements a handful of Go interface.

Might be interested in https://github.com/dolthub/go-mysql-server, which also does this

https://github.com/dolthub/go-mysql-server

One item under "Scope of this project":

Provide a runnable server speaking the MySQL wire protocol, connected to data sources of your choice.

I just wanted to say thanks for https://github.com/dolthub/go-mysql-server

This is incredibly useful for anyone who wants to build their own DB or wrap another datasource so it's queryable via MySQL protocol.

a very cool project they also maintain is a MySQL server framework for arbitrary backends (in Go): https://github.com/dolthub/go-mysql-server

You can define a "virtual" table (schema, how to retrieve rows/columns) and then a MySQL client can connect and execute arbitrary queries on your table (which could just be an API or other source)

Thanks for this write up! I've been really interested in postgres compatibility in the context of a tool I maintain (https://github.com/mergestat/mergestat) that uses SQLite. I've been looking for a way to expose the SQLite capabilities over a more commonly used wire-protocol like postgres (or mysql) so that existing BI and visualization tools can access the data.

This project is an interesting one: https://github.com/dolthub/go-mysql-server that provides a MySQL interface (wire and SQL) to arbitrary "backends" implemented in go.

It's really interesting how compatibility with existing protocols has become an important feature of new databases - there's so much existing tooling that already speaks postgres (or mysql), being able to leverage that is a huge advantage IMO