All the READMEs these days are such a tell. It's okay when explicitly prompted, but now thanks to reinforcement learning through people who have no clue, all the models just top off every change with some pointless documentation change.
You can't put 3 lines in a Dockerfile but will be "shopping for alternatives", "identifying the best option" and "get it rolled out"? Do you ever get anything done, "rather quickly"?
Their trend towards walking away from the community is a major red flag to me. If we're going to need to swap them out for an alternative at some point, better to get on it now than wait until we're forced to do so.
> It's a meaningless nonsense tautology? Is that the level of leadership there?
I don't understand why everyone always likes to bitch about why their preferred wordsmithed version of a layoff announcement didn't make it in. Layoffs suck, no question, but the complaining that leadership didn't use the right words to do this generally shitty thing is pointless IMO. The words don't really matter much at that point anyway, only the actions (e.g. severance or real possibility of joining another team).
My read of the announcement is basically saying they over-hired and had too many people causing a net hit to forward progress. Yeah, that sucks, but I don't find anything shocking or particularly poorly handled there.
There's a segment of people convinced that leadership must somehow be able to perfectly predict the future or they're incompetent losers, like running a business is somehow the easy part of capitalism.
Running a business is definitely the easy part of capitalism. Most leadership isn't just bad, they're bafflingly incompetent. Most companies fail. Of those that fail, they usually fail in extremely obvious ways built off of fundamental character flaws, like stubbornness or greed.
Tell me you've never a business without telling me you've never run a business. You're pulling things out of thin air and using it to support a position with no foundation.
The irony is that in 2025, this answer is now wrong again. Starting with smartphones, scanout hardware supports multiple planes/overlays again that are composited on the fly by fixed function blocks. This bypasses having to power on the GPU and wasting memory bandwidth (a large amount of power use in a smartphone).
No longer involves hacks with green pixels though.
Not necessary for blending in video overlays, and wasteful. Well, necessary inside the overlay if that is where the controls should appear.
Alpha blending is two reads, one write per pixel, for the whole affected region (whatever that is, could be the whole screen). An opaque overlay is one read, one write, only for every pixel in the desired rectangle.
The video overlays in question are not drawn by blending into a framebuffer in memory. They're two separate display planes that are read in parallel by the display path, scaled, and blended together at scan-out time. There are only reads, no writes. Modern GPUs support alpha-blended display planes using the alpha channel that is otherwise often required to exist anyway as padding.
As OP noted, using hardware display planes can have efficiency advantages for cases like floating controls over a video or smoothly animating a plane over a static background, since it avoids an extra read+write for the composited image. However, it also has some quirks -- like hardware bandwidth limits on how small a display plane can be scaled.
Keep in mind this is part of Nvidias embedded offerings. So you will get one release of software ever, and that's gonna be pretty much it for the lifetime of the product.
Brick is now slang for a lot of fail conditions that aren't classically 'bricked.' This has become really common I've noticed. Honestly, this ship has sailed and isn't even worth fighting anymore. Its like Xerox asking people to stop calling copies Xeroxes.
We just never bothered to develop a new term. Maybe 'soft-bricked?' 'Semi-bricked?' I would like journalists at least to start using more accurate terms, but 'bricked' I imagine gets a lot more engagement and ad impressions, so here we are.
Wikipedia has a section about this. They call it soft bricked vs hard bricked, according to the difficulty of restoring device function and how the broken state presents. Even hard bricked is usually recoverable with appropriate tools, so it is a spectrum.
I’m sorry, but you’re incorrect the vehicle completely shutting down while driving and not working again until you put it into park and then it’s shutting down five minutes later is effectively bricked and extremely dangerous. Myself and my family almost died just trying to get home from dinner. It was a complete loss of propulsion and power steering.
Being temporarily unusable is not how I've seen "bricked" used, bricked means unrecoverable and the item is completely unusable except for as a brick/paperweight/door stop.
Then it would better be described as a life-threatening event rather than a bricking - especially as, in the hierarchy of concerns, the former is more serious than the latter.
And then it was fixed with another OTA, so it was not bricked. Why bring up this pedantic point you may ask? Because the grandparent raises a scenario that doesn't apply here. A/B updates or not were not at all the issue here.
I for one am always grateful when things are engineered thoughtfully and with redundancy as it is symbolic of respect for the people who are your customers. Especially in something as important as a car, "can be bootstrapped from a central computer" - when? how easily? how reliably? - is not good enough because things will inevitably go wrong for some portion of the user base.
Indeed the Adam Dunkels, poor guy, trying to have IoT take off for 25 years and they just keep making the hardware bigger obsoleting his previous genius.
reply