Also quite important to make sure we don't have just a single strong x86 vendor - even though currently looking at price/performance you'd almost always go for AMD.

The time before ryzen was horrible - a 4-core-CPU was considered high end, and if you needed something more you needed to go for ridiculously overpriced Xeons. Similar for servers - you could get slightly higher core counts there, but when going for more than 8 cores it'd also get expensive very quickly.

Now we're talking about 16 cores in high end notebook, and 64 cores in still reasonably priced pro workstations.

The Tesla factory in Germany has roughly 3 times as many reportable incidents as comparable factories.

That has changed over the last few years - I'd prefer a proper usb3 to sata bridge over a shitty sata controller - and the quality of integrated sata controllers isn't that great nowadays.

I'd just start from very simple kernel and static init, and work my way up to adding more functionality. I'd use kvm with rootfs on p9fs - that allows playing with it without having to build images. I can throw together the initial invocation, if you're interested.

Then start building simple core elements in a language allowing easy static linking - I'd use C with dietlibc or go. Start adding core userland programs, explore initramfs (without using something like dracut), add dynamic libraries and explore the dynamic linker, ... - if you're interested we could set up a matrix channel for questions (typically with some lag, though), and do a github repo to follow along.

LFS iirc goes for full desktop - the high level userland is very complex, but easy to understand when you know the basics. You pretty much learn how to compile lots of libraries - which has limited use. A full LFS style desktop I'd no longer recommend nowadays - it's just too many dependencies to deal with. I used to build my own system (not following LFS) until the Xorg fork made it sigificantly more complicated - and things got just worse since then, and I never was using a complicated UI stack.

edit: I had a few minutes, so I've thrown this together https://github.com/bwachter/lll - you should easily get a kernel with a custom init running, and have enough to start experimenting. If you or anyone else is interested to go deeper I'll set up a matrix channel for guidance.

Gentoo is useless for learning how things work. Back in the 00s when I still had time to hang out at events it was always quite ridiculous at what kind of basic stuff the gentoo crowd got stuck at - and with the tooling 15+ years more polished now I'd expect what is actually going on is way more hidden than back then.

If you do want to understand how things work just build a minimal system - either on spare hardware, or qemu/kvm. Don't go with systemd, or other fat userland options - that just makes you compile a lot of dependencies not adding value for learning.

Use some lean init (or just write one yourself), and some lean shell.

Not really doing much docker, but a lot of LXC - everything scripted with ansible. I define basic container metadata in a yaml parsed by a custom inventory plugin - and that is sufficient for deploying a container before doing provisioning in it.

I now and then check Tesla share prices after that kind of bad news - and to my amazement it just keeps going up.

That they're not really good at the car building part has been well known for quite a while - and by now it should be blatantly obvious even for people not doing software stuff for a living that they're also not stellar at the software thing (which I assume their valuation is mainly based on, as it doesn't make much sense). They are better at least with the infotainment software than established car makers - but given how those suck at it that's really not hard.

I don't really see them spreading too much in the EU currently - they're currently trying very hard to piss off the Nordics, and I'd expect to see regulation eventually prohibiting new cards with touch only controls. It already is treated like a mobile device by law here - so touching any settings on your Teslas touch screen while driving can be very expensive, up to a temporary loss of license. Also having an accident while touching the screen will shift more of the blame to you.

I have a soft spot for AMD for sticking with the FOSS community to an extent and for their affirmative action towards open silicon initialisation with OpenSIL.

I'm quite happy with having proper graphics cards again thanks to AMD working with their open source driver - and also looking forward to OpenSIL. Though there's still the problem with the PSP in their CPUs.

If you go through my posts, just the other day I was asking if the T440p was the last Thinkpad I could put Coreboot on (the answer is yes)

Did you checkout heads? That's what I'm using on my x230 - seems to be currently the most sensible choice for portable hardware.

I will be employing Faraday cages and metal shielding liberally around my electronics

Also make sure to shield cables. There's not much public research into passive RF, but from the few people who looked into that we can say that the situation is bad, and the bad guys probably can do a lot of bad things (most likely both display signals and keystrokes from a USB or PS/2 keyboards can be recovered reasonably well from some distance by just analysing the RF sent by the cables)

Unless we're talking about undisclosed exploits in Android, removing Google and most other proprietary applications should do the trick

Pretty much all phones sold in a bit over a decade no longer have a separate baseband. With a unified memory architecture you possibly have a remotely exploitable (remember, baseband) access to the OS memory, if you manage to bypass memory restrictions - in which case none of the mitigations in the OS will help you as it's just not aware of you being there. While this is a pretty complex attack it unfortunately has been proven in a few cases to be possible. I don't keep very important stuff on my phone - I don't consider it trustworthy.

Thank you for bringing across the point of spying using an accelerometer (I'm interested in how that would work, could you point me towards what I should look for?)

Seems research about being able to recover a phone password/pin by using the phones accelerometer is shadowing search results - I'm pretty sure I've seen a paper about a phones accelerometer being used to reconstruct key strokes of a keyboard on the same table a few years ago - pretty much same idea as recovering the keystrokes via sound.

Also note that things like hard disks contain their own embedded computer, and in some cases contain an accelerometer. They also have DMA access...

Long range stuff typically is UHF RFID in the 860-960MHz band.

HF NFC at 13.56 MHz can be done up to roughly 20cm, though with passive sniffing you might pick up parts at longer range.

LF NFC is just a mess. I think there were some pretty long range readers available, but nobody should be using that stuff anymore, it's just horrible. Unfortunately there still are companies using that for access control, so I'm now and then handing out copies of their keys to friends. The main security on those things is that sometimes it takes a few tries to get the your reader detect the tag.

You've replaced the whole operating system - in which case they obviously are in control. It is equivalent to a rooted stock Android device.

But if you just install their app installer on a stock Android device you'll have the same problems.

Don't want to go into too much details - from a high level perspective the Windows version integrates better into the overall system. In Rosetta, once you're in the emulation layer it can be rather complicated to execute native components from there. In Windows - with some exceptions - that's not a problem.

Ask Brandon Lee.