-- Leo's gemini proxy
-- Connecting to gemini.tuxmachines.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Tux Machines
Posted by Roy Schestowitz on Aug 24, 2023
> We're long time users specifically of NFS v3, not NFS v4, and so for a long time we also did everything we could to disable NFS v4 on our NFS servers. When our NFS servers became Linux ones in 2018, one of the things we did was to run mountd with a command line option to disable NFS v4: [...]
> No, we are not joking; we're deadly serious. There is an excellent explanation at useplaintext.email, and its URL is the "TL;DR" summary. It will tell you why to use plain text, as well as how to configure your email client to do it, and it does it all in a single page.
> The main way to format text online is HTML, and HTML email is as unsafe now as it was in 2004 when Network World warned against it – as The Reg did, too.
> HTML email is a malware vector, it enables spam, and it lays users open to phishing attacks. (Incidentally, formatting using Word is even worse.) We've repeatedly warned about it, but it keeps happening. Oh, by the way, HTML messages also offer a way to crack open encrypted mail, too.
> HTML e-mail will guarantee that you get more spam, because of something called a "web bug". It also puts you at much greater risk of phishing. You could just take my word for it and turn off HTML, but keep reading for the details. Let's look at the phishing risk first.
> I've recently written about things like finding who owns NFS v3 locks on a Linux server, breaking NFS locks on 22.04, and experimenting with NFS v4, where I mentioned in an aside that NFS v4 seemed better regarded for file locking. All of this work has been quietly motivated by it becoming obvious to us that we have some sort of NFS (v3) file locking problem on our Ubuntu 22.04 ZFS fileservers.
> To my surprise, many people replied that they agreed, default to light DOM, and only opt-in when it makes sense. I'm glad because it confirmed my feeling and encouraged me to rethink and restructure some of the components I built. Shadow DOM has its justification but does not always have to be the first choice.
> To help you make similar decisions, I summarized my pros and cons of Shadow DOM and style encapsulation. Please note that I'm writing this from the perspective of someone who, first and foremost, cares about accessibility and well-structured, semantic HTML. For me, JavaScript is an optional add-on and not the foundation of my code. That implies that I might not have to solve the same problems as others who primarily work with JS-heavy websites. That might also explain why my list of cons is longer than the list of pros.
-- Response ended
-- Page fetched on Sat Jun 1 07:35:48 2024