aard

It really was just the (very solid) foundation he knocked out in that time - the ui was horrible back then. Linus just did what was required to get the kernel unstuck.

I started moving the first of my own CVS repos to git in late 2007, and it wasn't ready for the average user at that time yet.

Linus handing it off quickly was the right thing to do, though - otherwise we all might be using something else nowadays, with just the kernel and a handful of projects with similar requirements using it. Many great developers would've wanted to hold on to their baby in that situation, preventing it from growing to its full potential.

There also were other distributed VCS around - with arch being available not too long after bitkeeper - but they all typically worked only for some styles of working, and pretty much all of them ran into massive performance issued once the codebasw got large.

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.

Back in 2001 we got ext3, adding journaling to the most widely used filesystem on Linux - which can just roll back transaction on next mount, while previously you'd have to run fsck to get your filesystem back to a consistent state.

A non-journaling filesystem was easier to get into a state where things were broken in interesting ways, as a unclean unmount had a higher chance of impacting critical data.

In the early days of journaling filesystems fsck was also quite lacking - so when things got bad enough that you did need fsck there was a decent chance you'd end up in trouble.

Nowadays both robustness of the file systems as well as quality of fsck have greatly improved.

As a company it is pretty annoying. I have an outgoing payment for what we ordered - getting a commercial invoice for random gifts worth 5 EUR doesn't help me much.

Few weeks ago had a lenghty discussion with one vendor which ended with him asking if I shut up if he gives me everything I need to make my own invoices with his signature and company stamp.

I don't see indecent exposure, only some nude people. Which children have seen plenty of already.

This is from Toronto pride 2011. The original seems to be gone, but there's a more or less complete gallery over at Wikipedia: https://commons.wikimedia.org/wiki/Category:Pride_Toronto_2011

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.

This all is personal stuff. A lot of us started their pages before things like wikis or blogs existed, so the content often has elements of what you'd later find there - and depending on if it makes sense or not a blog may have been added later on, or not. Or still is not what would be considered a classical blog, but just an easier way of updating regular content.