Google used to indulge employees' interests. They fund, or used to fund, "the generator", a build shop in Reno. I know a Googler who openly worked on a small art project at the office, albeit a small part of the work.
I'm not saying that Google has machine shops purely for burning man. But I strongly suggest that when the idea has been floated in various locations, one recurring theme is "yeah let's! And let's get some lasers and propane burners!", and I also believe that some managers were thinking "great, this is the culture we want."
The register calls it "the chocolate factory" as a reference to Willy Wonka. Shame they descended into evil.
I don’t mean the rank and file but Page and Brin. They’ve only ever gone the glamping sparkle pony route.
> I'm not saying that Google has machine shops purely for burning man. But I strongly suggest that when the idea has been floated in various locations, one recurring theme is "yeah let's! And let's get some lasers and propane burners!", and I also believe that some managers were thinking "great, this is the culture we want."
There was! It was the predecessor to the Garage. I suspect because the machine shop boys wouldn’t let them use the real toys.
Do you have a link ? I was not aware of that, the only thing I can find is that McLaren ran some tests to replace in-cockpit ads with a small eink screen, but nothing on the side of the cars.
also to clarify, I just called it "e-ink" because I didn't know what it was, it just looked like e-ink based on how it seems to change (flicker and then transition to new image). I have no idea what it is :D
Arch Linux is not vulnerable to this specific attack, which requires sshd to be linked to liblzma. This link is provided by out-of-sshd patches, that Arch does not apply to their build.
The point here is there is uncertainty in all commits by Jia Tan, Arch’s focus is on this specific hack, but are there other vulnerabilities in the hundreds of commits to the git repo from the same author?
But as this article points out, liblzma is used in other crucial processes, and is generally trusted, often probably being run as root. The known bad actor contributed lots of code to xz that isn’t involved in the SSH backdoor. To assume it’s all innocuous would be truly foolish.
That may depend on the context and data but you may end the first job at T+28 (runtime of 28 hours) and the second at T+52 (28 hours as well, started at T+24).
If jobs must be executed one after another, then you absolutely create an infinite backlog.
At least according to the Github's language breakdown for https://github.com/Rust-for-Linux/linux, C is still 98.3% of the repository, and Rust is in the 0.1% of "others".
CAN Bus is more like a layer 2 bus, so it should not really bother with encryption, just like Ethernet doesn't provide it. It all comes from the layers above it, and there has been proposal to add encryption or authentication to CAN. The big issue is that in normal CAN you only have 8 bytes to work with.
This is kind of a nitpick, but Ethernet _does_ bother with encryption, at least in recent versions of its standards. Obviously Ethernet has a long history and this is all optional, but it's pretty straightforward to set up 802.1X / MACsec (+MKA) on a LAN in such a way that all traffic is encrypted at L2.
I've never heard of this being used with really low-power embedded stuff, but if you stretch your definition of embedded to the point where you include things running stripped down Linux, this is a pretty viable setup if you have those devices distributed across a LAN with a managed switch in the middle.
Well a lot of cars have a wireless charging pad available in the phone holder, so you just drop your phone there and it starts charging / connects to Android Auto.
Tbh, the charging pad is bad, if I would rely on it a lot, I would keep a cable in the car. I don't know why, but it heats up so much if you use it, that the iphone overheats and starts to throttle.
I also had some experience in that space, and my conclusion was that what was really hard is handling keep-alive correctly. Some mobile networks will very aggressively flush their NAT entries while other will be fine with a packet every hour or so. And sometimes the NAT timeout changes depending on the server's IP range. Building a solution that is both battery-optimal and that will keep the connection alive is pretty hard.
QUIC (or HTTP/3 with enough low-level control) sounds like a good fit: there is no NAT connection that has to stay alive, but the server can remember the handshake for a quick restart. Doesn't matter if you switch between wifi and LTE. When ever the app is told radio is now available, send a single UDP packet to request new notifications, server sends one of more UDP packets back in response.
