Earlier quoted context omitted.
It rather supports the site's core point, because that point is about plain text files, not HTML and CSS. Plain text is as readable as it is possible to be. Besides, this is exactly the kind of site HN constantly laments the loss of - unique, quirky, basic and rough around the edges.
> Plain text is as readable as it is possible to be. Which is nonsense, of course, just like this site illustrates. Trivial formatting and layout changes make it more readable. > Besides, this is exactly the kind of site HN constantly laments And this is exactly the beside-the-point response you sometimes encounter on HN. I'm not a representative of the collective HN, so why does it matter that some other people did…
Why Prefer Textfiles? (2010)
21–30 of 50 posts
Re: Why Prefer Textfiles? (2010)
#22Or if you prefer magnet/ed2k download links: https://pastebin.com/UZNDd564
Re: Why Prefer Textfiles? (2010)
#23Earlier quoted context omitted.
> Plain text is as readable as it is possible to be. Which is nonsense, of course, just like this site illustrates. Trivial formatting and layout changes make it more readable. > Besides, this is exactly the kind of site HN constantly laments And this is exactly the beside-the-point response you sometimes encounter on HN. I'm not a representative of the collective HN, so why does it matter that some other people did…
text files don't have "formatting" or "layout." They're just streams of ASCII characters. HTML is not plaintext.
But also, you continue to miss the point - this lacking/bad layout/formatting is precisely the reason not to use plain text
Re: Why Prefer Textfiles? (2010)
#24It's always interesting to me that these plaintext sites are flagged as "insecure" and "risky" by modern browsers. I don't have a good solution, but it reminds me of [1] [1]( https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites... )
They are insecure, because your ISP can change website responses and text format doesn't protect from that. So basically browser can't guarantee that you're looking at original web server response.
Re: Why Prefer Textfiles? (2010)
#25Interesting video story: https://youtu.be/9aHfK8EUIzg (2016)
Data site: https://xd.saul.pw/data
Re: Why Prefer Textfiles? (2010)
#26Earlier quoted context omitted.
They are insecure, because your ISP can change website responses and text format doesn't protect from that. So basically browser can't guarantee that you're looking at original web server response.
With checksum & sign nothing can be guaranteed, right ?
Re: Why Prefer Textfiles? (2010)
#27So what exactly distinguishes them? The OS knows how to render them? It's just a linear list of characters? The reliance on a fixed font to allow some form of layout or positioning? Good basis for embedded DSL's, like Markdown?
Don't forget they are a binary format also. Oh, I just said that. I anticipate the day UTF8 will be a fond memory of a big mistake we made in our youth, that held us back for decades.
Don't forget that all of IT is a shit show sprinkled over with dollar paint, much like alchemy was. We don't yet know what the formation in Information is.
Re: Why Prefer Textfiles? (2010)
#28Turns out text files are a binary format also, with any number of encodings, ever more binary as UTF8 grows, requiring constant updates, hidden by the OS. Text files are just the name for a renderer built in into every OS. So what exactly distinguishes them? The OS knows how to render them? It's just a linear list of characters? The reliance on a fixed font to allow some form of layout or positioning? Good basis for…
Alternative that would be better?
Re: Why Prefer Textfiles? (2010)
#29Turns out text files are a binary format also, with any number of encodings, ever more binary as UTF8 grows, requiring constant updates, hidden by the OS. Text files are just the name for a renderer built in into every OS. So what exactly distinguishes them? The OS knows how to render them? It's just a linear list of characters? The reliance on a fixed font to allow some form of layout or positioning? Good basis for…