scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error hga@xxxxxx 10 Jul 2019 18:30 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error Lassi Kortela 10 Jul 2019 18:50 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error hga@xxxxxx 10 Jul 2019 19:43 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error John Cowan 10 Jul 2019 19:56 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error hga@xxxxxx 10 Jul 2019 20:05 UTC
Re: scsh-0.6.7 -> scsh-0.7 has substantial changes, and introduces grievous error Lassi Kortela 10 Jul 2019 20:32 UTC
Systems lie about persistence and consistency promises. A lot. hga@xxxxxx 10 Jul 2019 22:10 UTC
Re: Systems lie about persistence and consistency promises. A lot. John Cowan 10 Jul 2019 22:20 UTC
SQLite only SRFI? hga@xxxxxx 11 Jul 2019 01:49 UTC
Re: SQLite only SRFI? John Cowan 11 Jul 2019 03:22 UTC
Re: SQLite only SRFI? hga@xxxxxx 11 Jul 2019 08:19 UTC
Re: SQLite only SRFI? John Cowan 11 Jul 2019 13:32 UTC
Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:26 UTC
Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:42 UTC
Re: Systems lie about persistence and consistency promises. A lot. John Cowan 10 Jul 2019 22:49 UTC
Re: Systems lie about persistence and consistency promises. A lot. hga@xxxxxx 10 Jul 2019 23:01 UTC
Re: Systems lie about persistence and consistency promises. A lot. Arthur A. Gleckler 10 Jul 2019 22:51 UTC
Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:59 UTC
Re: Systems lie about persistence and consistency promises. A lot. hga@xxxxxx 10 Jul 2019 23:19 UTC
Schemepersist, anyone? hga@xxxxxx 10 Jul 2019 23:40 UTC

Re: Systems lie about persistence and consistency promises. A lot. Lassi Kortela 10 Jul 2019 22:26 UTC

> [ The troika of John, Lassi and Harold excise sync-file (born broken,
>    and still so on Linux) and sync-file-system (badly named, sort of
>    broken by design but traditional, and broken in implementation. ]

:D

> Depend on subject domain experts like the SQLite team and their whole
> software stack when you need the best guarantees available today.

This is a very good point. For general purpose computing, the popular
database vendors have the most incentive to do a good job of this.

> along with notes about system configuration details and trade-offs.

An even better point. There are basically two principled approaches:

1) Be content with the 30-second auto-sync like everyone else.

2) Carefully select and configure your whole hardware, firmware, OS,
database, language and application stack so that every level of the
stack reliably delivers the sync guarantees you need.

Everything in between is voodoo to some degree :)

> Potentially develop a Transaction Manager SRFI that breaks absolutely
> no ground in low level implementation details, concept, and primitives
> and code we ... borrow from the best.  But is easy to grok and use.

This sounds a bit like "fast, safe, easy - pick any two". But major
bragging rights to anyone who manages to pull it off for any scenario.

> This has been a interest of mine since I was given a job to make a
> custom database that just stored data reliable; I'll put it on my
> long term TODO list, during/after tackling the SQL RDBMS issue.

Not the easiest job in the world for one person (or even a team!)