Hacker News new | ask | show | jobs
by gpderetta 3539 days ago
>At the next start LibreOffice gives a big warning of "Oh shit things are really wrong, should I fix them for you? [Continue | Cancel]" .

> Thank you LibreOffice team for making it so that within the time of a phone call to me plus the time it took to press "Continue" they were able to recover the their document and continue working.

Uh, that's exactly what the OP was advocating, if I understand correctly. On a consistency check failure (i.e. an assert), crash immediately [1]. If the application correctly handle transactional state changes, it will be able to recover on startup from the replay log, as all changes are immediately persisted on the log.

This approach is known as "Crash Only Software", and it is pretty much the only approach for writing robust applications.

[1] Syncing the replay log to stable storage can be a good thing though.

1 comments

Yes, and I'm consistently disappointed that HN no longer gets this - It's becoming an echo chamber of those who can't and won't, rather than those who architect and learn. Timekeeping considerations are rarely-to-never the responsibility of an application programmer, and the scenarios presented - Leap seconds, etc - Are either meaningless (Who cares if your delta-t value is off by a second over a three month report?) or incredibly meaningful to the point you explicitly define them in the spec (High-freqeuncy trading systems should use good linearization mechanisms, not just rely on 'timestamp' - The programmers who are working on these problems have well documented that these are hard problems that throwing more time specificity bits doesn't solve).

High level talks about low-level concerns are rarely helpful. This overview of detailed problems without links or even understanding of the relevant literature (It doesn't even mention the scenario that time runs backwards, which is way more common and terrible than pretty much anything on the list). This was a bad post, and it's bad training - Bringing up superficial questions without giving places to check answers for sanity. Many people will likely think about these issues halfheartedly, form half-baked answers, and propagate mistakes. Good learning not only asks questions, but asks follow ups and helps reach complete solutions.