I have radicale installed on my server with a self-signed certificate. It stores data in standardized clear-text files and has good documentation on how to setup all sorts of clients.
Sure, and this is what HTTPS certificates from a CA are for. If your users are willing to click through the "warning: self-signed certificate" popups, then they're vulnerable, of course. But if they don't make that mistake, then your DNS result is reliable unless someone compromises the CA. Of course, CAs do get compromised.
IsTom's comment was about how an HTTP-served page might be modified to make the "secure" links actually point to a non-HTTPS fake login page (for example). This assumes the user will not notice that the connection is not secure (which I think is a fair assumption).
Given that, another attack might be to mitm DNS and serve an entirely fake Amazon site, all in HTTP, and the user will not notice there's anything wrong.
I think that's the point mro and troels were trying to make.
The only way I can imagine to mitigate this would be to use HSTS on the amazon.com home page.
That blog post is from 2005. There was a major rework of how the block layer handles flushes back around 2010 and I'm pretty sure the issue he was having with fsync not being reliable has been resolved.
To go into the details, essentially, its the AHCI-driver(SATA) that handles 2 use-cases differently.
The more common being the case where there is an additional VFS driver between the app attempting sync-I/O and the AHCI driver which simply issues an asynchronous I/O command to the disk and returns immediately. The new data is guaranteed to be on the HDD but NOT guaranteed to be written to the non-volatile platter of the HDD. Data is often still in the HDD internal-cache, waiting to be written to the disk platter.
The 2nd case (very rare) is when the application attempting sync-I/O opens the HDD in raw mode i.e. opens the block device directly(without any VFS layer in between) with O_SYNC. Now following each disk-write, the AHCI driver issues a CMD_FLUSH to ensure that even the HDD cache is immediately flushed to the platter. As this eliminates any chance for NCQ to kick in, the performance drops by an order of magnitude but data-integrity is ensured.
I was only six at the time, so I don't have first hand knowledge, but from what I gather there was no really free kernel/operating system at that time. Minix was under license restrictions, the BSDs was tied up in legal battles, and GNU was still on it's endless search for the perfect kernel.
The other thing to remember was Windows was still 16 bit at the time. Linux started off as 32bit. Being free was great, but I would have also (and did) payed for a 32 bit operating system at the time. I actually used OS/2 in the mid-90s before moving to Linux.
I can't stress enough how basic it was. Getting the kernel up and running was only 1/2 the battle. Getting X to run was a significant undertaking, and probably more difficult.
