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:42 UTC

> 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.

Another way to think about this: If you want some kind of manual sync,
it means you want a guarantee that a system crash will wipe out less
than 30 seconds worth of data. What kind of home/office scenario is so
critical that every minute counts? More likely it's some kind of server
collecting live financial or scientific data from an expensive source.
Which means those organizations would also spend money on expensive
reliable server hardware to gather that data (high-end servers might not
be that expensive compared to the instruments that source the data and
the value of the data). And if the hardware is that sophisticated, does
it really use Unix sync() as the interface to the instant reliable sync?