@prettygood Oh yeh, way back they were /dev/hd* when they were IDE compatible interfaces, and in VMs you often get lots of other things (like /dev/vda for virtio block devices)
@prettygood I'm confused, certainly for me on Linux, my NVMe drives appear as /dev/nvme* rather than sd*. And I try and use /dev/disk/by-path or id or label or anything to avoid using /dev/sd* since it is slightly clearer which drive it is.
@lanodan@neil Yeh that's true; although hmm I bet they'd try and help outside the US, the people involved in many of their projects are based all over the place.
@GossiTheDog I guess you could ask NCSC to comment? The individual councils (bexley etc) are probably impossible for anyone to push, but you'd think *someone* should be looking after justice.gov.uk
@GossiTheDog The JLR one is tricky because their parent company is Tata Motors; so I'm assuming that using TCS is 'keeping it in the family' so feels more logical to them than to others. But I'm also confused, there's speculation that JLR lost it due to salesforce, so then is it entirely unrelated to TCS/outsourcing at all?
@scribe@ParadeGrotesque (Which if you think that giving 4 answers and referencing @ParadeGrotesque 's post is cheating, then I'd point out I'm mostly a programmer, so can use recursion and often make fence-post-errors)
Other #mutt users - how do you deal with long URLs received? - like in the 'confirm your address' type of mails from companies. I tend to run mutt under an ssh rather than on my desktop, sometimes piping a mail into w3m or similar and then if I needed a URL locally I'd copy/paste - but now the embedded URLs are *HUGE* - many hundreds of characters. Ideas?
@revk@neil My reading of the Spanish slides via translation is that it's not a remote backdoor - it's a set of undocumented commands that let you write/read the firmware. Meh.