aard

I’ve let my google developer account expire quite a while ago after they kept asking for more and more stupid stuff. Nowadays if you don’t get paid a lot for it you must be either a masochist or a bit stupid if you upload to google play.

If you can afford it see if Eaton has a smaller tower UPS suitable for you.

I was referring to work setups with the overengineering - if I had a cent for every time I had to argue with somebody at work to not make things more complex than we actually need I’d have retired a long time ago.

Unless you are gunning for a job in infrastructure you don’t need to go into kubernetes or terraform or anything like that,

Even then knowing when not to use k8s or similar things is often more valuable than having deep knowledge of those - a lot of stuff where I see k8s or similar stuff used doesn’t have the uptime requirements to warrant the complexity. If I have something that just should be up during working hours, and have reliable monitoring plus the ability to re-deploy it via ansible within 10 minutes if it goes poof maybe putting a few additional layers that can blow up in between isn’t the best idea.

Everything is deployed via ansible - including nameservices. So I already have the description of my infra in ansible, and rest is just a matter of writing scripts to pull it in a more readable form, and maybe add a few comment labels that also get extracted for easily forgettable admin URLs.

Had to look that lawyer bit up as it just sounded too much like Gravenreuth - and indeed it was.

I nowadays manage my private stuff with the ansible scripts I develop for work - so mostly my own stuff is a development environment for work, and therefore doesn’t need to be done on private time.

A lot of the Zen based APUs don’t support ECC. The next thing is if it supports registered or unregistered modules - everything up to threadripper is unregistered (though I think some of the pro parts are registered), Epycs are registered.

That makes a huge difference in how much RAM you can add, and how much you pay for it.

It has been a while since I touched ssmtp, so take what I’m saying with a grain of salt.

Problem with ssmtp and related when I was testing it was its behaviour in error conditions - due to a lack of any kind of spool it doesn’t fail very gracefully, and if the sending software doesn’t expect it and implement a spool itself (which it typically doesn’t have a reason to, as pretty much the only situation where something like sendmail would fail is a situation where it also wouldn’t be able to write a spool) this can very easily lead to loss of mails.

I already had a working SMTP client capable of fishing mails out of a Maildir at that point, so I ended up just doing a simple sendmail program throwing whatever it receives into a Maildir, and a cronjob to send this forward. This might be the most minimalistic setup for reliably sending out mail (and I’m using it an all my computers behind Emacs to do so) - but it is badly documented, so if you don’t care about reliability postfix might be a better choice, or if you don’t just go with ssmtp or similar. Or if you do want to dig into that message me, and I’ll help making things more user friendly.

Because it does JBOD if the controller supports it. Pretty much none of the controllers you’ll find in consumer hardware support that.

JBOD relies on an optional SATA extension, which most of your controllers won’t have.

That leaves you with RAID in the controller - which is a bad idea, as you don’t have much control over what is going on, and recovery if it fails will possibly messy.

You still might want to do something like alias pbtar='tar --use-compress-prog=pbzip2 to easily use pbzip2 - unless you have an ancient system that’ll speed things up significantly. And even if you don’t it’d be nice to use it for creation - to utilize more than one core the archive needs to be created for parallel extraction.

A small form factor, small high density connector. Most interfaces are not populated, as on the regular pis, but just lead out via the connector, so you can decide what you want to expose on your compute module carrier. It has a gbit ethernet chip on board, and a pcie chip - rpi4 also has pcie, but it is hooked up to USB3 there. With the compute module you can decide what you want to do with that.

Actually I can’t think of anything that raspberry pi does that can’t be done better by a less expensive alternative.

That has been true even before the price increase - what still makes me use pis now and then is that just so many people are familiar with them, the standardized form factor with lots of extension modules, and the software support - pretty much any software targeting that kind of use has been tested on pi variants.

I’d nowadays go for using compute modules, though - they’re smaller, and you can get them with flash, eliminating the SD card problem many pis had. You can get carrier boards for the compute modules in the classic pi form factor, so you can have the best of both worlds.

I’m using opensuse tumbleweed a lot - this summer I’ve found an installation not touched for 2 years. Was about to reinstall when I decided to give updating it a try. I needed to manually force in a few packages related to zypper, and make choices for conflicts in a bit over 20 packages - but much to my surprise the rest went smoothly.

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 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…

This level of paranoia isn’t really compatible with modern hardware, and requires a lot of effort.

You’re pretty much limited to stuff that has open firmware available, and even then you have to hope there are no bugs or backdoors in the hardware.

For the intel world almost everything with open firmware is pretty old - some nowadays unsupported, which means no longer microcode updates. And those microcode updates also are a problem - you can’t mitigate everything in kernel space, so usually you’d want them, but they’d also be an attack vector against you.

And even if you manage to trust the computer itself there are a lot of attack vectors surrounding it. Do you have anything capable of recording audio in the same room as your computer? If yes, not a good idea - it has been proven possible to extract passwords from audio recordings of a keyboard. Does the room have windows? That counts as an audio recording device.

If you got rid of that, do you have some other hardware with sensors? There’s a high chance that a device placed on your desk containing an accelerometer would also be capable of extracting your password.

Take into account that your average police raid will not attempt that - they just don’t have the means for that.

If you have managed to become an important enough target that either specialists get called in, or you’ve managed to become target of three letter agencies or the equivalent in your country you will have been targeted by other attacks to gain access to your data, both software and hardware - and if you have to ask that kind of question here you’re very unlikely to successfully defend against them.

Yes, but: somebody trying to attack your machine that way would cut the power and try to freeze your memory modules. So that mitigation wouldn’t trigger.

If you think you really need to guard against that attack you’d have to look into physical security: At room temperature there’s a pretty short window available for saving the contents. So if you manage to remove access of possibly used cooling agents to the memory modules you already made things quite tricky.

Now if you can make removing the memory modules hard as well, and prevent booting anything but what you want to be booted there’s a decent chance it’ll be impossible to recover memory contents.

If that still isn’t good enough you’d have to look into providing a means of physical destruction of the memory modules triggered by a backup power source inside the case on unexpected power loss.