I thought most of the Google tpu magic is on wiring up these chips into supercomputer like clusters with specialized interconnects and whatnot. The chips themselves are less interesting in isolation.
There is no real way to prevent this, but there are ways to increase the cost of doing so. For example, one level of obfuscation is, OAI could internally run synthesis and adopt a “netlist-in” model in which Broadcom gets a netlist - a description of a huge amount of gates and wires and how they connect - instead of the plain Verilog (or other language). It is possible to reverse engineer the netlist, but it’s a certain level of indirection and effort.
A big part of the semiconductor industry also operates on a reputation basis. Broadcom (like TSMC) is a neutral party as a design house, but if they did something like this, it might ruin that reputation.
Hardware is getting more specialized these days. It's becoming more difficult than ever to write bare metal code. I don't think most (any?) software wants to manage the details a BSP solves for them.
If you pay for the privilege of using the app, that makes sense. I can't imagine such a law would ever be made for free apps as controlling the client experience is key for enabling them to offer it for free. The reason free apps often don't have a paid tier is because the folks who would pay for it are often the key demographic they need to not pay for the entire thing to be profitable for subsidizing the less desirable demographics.
I'm not trying to suggest that these sorts of things should be this way, but if there is a server involved in the economics of maintaining that endpoint come into play and can't be ignored. Ideally things were federated and you could point your car or whatever device at and endpoint you maintain, but that comes at a cost as well as maintaining software where both client and server are controlled by the same party is an order of magnitude easier than cases where they aren't the same.
Good engineering isn't always about building new things, but making existing ones continue to work well. Funding new ideas is generally a hard problem for large organizations and that's not entirely an engineering culture problem.
There are a lot of terrible practices out there in the world that you should stay wary of. Too many false positive alerts, flakey tests, not enough tests, not listening to users, taking a solution because it's easy and popular but not necessarily a good fit for your specific requirements, etc. Many of these practices are popular unfortunately. That's not to say others don't have great ideas, just don't copy them blindly.
Say what you will about MS, but the fact that Windows was backward compatible for so long (it may still be, I haven't kept up) is damn good engineering.
Having led engineering in SF big tech and now building my own startup, I’ve heard this exact argument countless times. I believe it is precisely why large tech companies are losing their ability to innovate.
Engineering shouldn't be an academic pursuit of "good engineering" for its own sake. It is fundamentally a business function. The objective is to achieve real world goals and build things people actually want, even if that means the solution is scrappy and unpolished today, so long as it solves an important problem cheaply and effectively.
In large organizations, accountability for actual value delivery is so diluted across the org chart that it practically disappears.
Leaders gravitate toward building bloated "internal platforms" that offer little external utility. Engineers over-engineer simple problems because their performance reviews reward technical complexity, not business impact. It becomes a systemic shield, allowing the old guard to justify their headcount without delivering new value.
Software engineering is uniquely plagued by this. Civil engineers understand their objective: build a bridge that safely carries traffic within a specific budget. They don't invent a novel, hyper-complex suspension architecture when a standard short-span bridge will do the job.
I would decouple "build things people want" from "business function". I would put in the former bucket things like: making the computer work smoothly and run apps. I would put in the latter bucket things like: show advertising to the user when the log in. Engineering should always be about the first, or it's bad engineering. The second is far more controversial - business leaders would like you to consider it good engineering to do that, but you get to interpose your own ethics, but you'll probably be fired for having ethics, but that doesn't make it bad engineering.
Considering the large increases in revenues bug tech extracts year over year, the maintenance and small improvements are not necessarily completely disregarding the business side of things. You cannot keep sustained performance without proper practices. Too much short term thinking like you see in startups leads to loss of confidence that new changes won't break existing customers, or hellish on call that no one wants to be part of. There is a lifecycle to product development and different phases require different tradeoffs. You sound like you align with the builder phase and that's great.
I will also note that most civil engineering is about maintaining existing structures and roadways, not building new ones.
> Engineers over-engineer simple problems because their performance reviews reward technical complexity, not business impact.
Having tech led teams at both high-profile and low-profile tech companies, that is _not_ my experience.
Most engineers worth their salt value quality. Product Management generally doesn't see quality as a feature, therefore doesn't take it into account. For short-lived code, quality is indeed over-rated. For long-lived code, quality is the thing that determines whether you can keep improving or tuning other features or whether you'll miss deadlines. Sadly, retrofitting quality in an existing codebase is awfully expensive.
There's also one important, but often undervalued, aspect. Overwhelmingly, today's tech world has been built by neurodivergent engineers. In my experience, neurodivergent engineers tend to value getting to the end of things, rather than letting them drop mid-way. This can absolutely be seen as over-engineering, but it's often a cognitive scaffolding that will ensure that the work can be resumed (by them or anyone else) even after context-switching to something entirely different.
Whether it actually _is_ over-engineering often depends on how well the engineer is aware of the actual needs, rather than being spoon-fed instructions without visibility. Or on the maturity and skill of the engineer, depending on the case.
There is nothing about Android as a platform that forbids installation of your own OS. That's a phone oem choice and the fact Pixel phones can be unlocked proves as much. In fact this is the reason this project is even possible.
There isn't, but part of Google's requirements for using the trademark "Android" is iirc shipping a locked bootloader. If you also want to provide your users with the Play Store (many people will perceive the device as unusable without that), you also can't ship it with a su binary or something. It needs to come in a locked state where people only get user-level access, no permissions to read the data stored on there (outside of Downloads and DCIM and the like), no permissions to use TCP port 22, etc. Like the level of access many employers provide to non-tech personell as a device they don't own. As to why manufacturers are less and less often adding support for unlocking the hardware, I can only make assumptions
Google is requiring it be closed and leaving the unlock entirely optional. That's a choice
Right, because the android security model considers app developers independent entities with security privileges equal to those of the device owner (in that both parties need to authorize access for things to work, the device owner doesn't have more privileges than the application developer when it comes to the application). Those mechanisms are necessary for that security model to work. If you want to operate with a different security model that's fine, but you just need to use something other than Android. The bootloader situation being optional is Google not getting overly involved in the device maker's business outside of the scope they should have influence on. And they set the precedent via Pixel for how they think others should do it.
I use public transit but it comes with a lot of inconvenience. You need to stand on a moving vehicle more often than not, it takes more time, there are panhandlers, you might not feel safe, transfers don't generally seem to time well, going up and down multiple flights of stairs is a fair bit of exercise, some people don't shower as often as you'd hope, etc. People generally pay for convenience. I certainly would if I could budget for it. I couldn't care less about status or class.
Nothing with WiFi will ever be coin cell battery powered. But that doesn't mean it couldn't be battery powered for a year or longer with bigger batteries. Otherwise you'll need a different radio technology.
I think some do use regular wifi, especially the amazon ones, but with a button you have an advantage where you could just stay idle and off the network most of the time, and only connect to send an event when pressed.
That likely increases your latency by a fair bit. Most of my devices take a second-ish to connect, configure the WiFi stack and start sending data.
I’m not sure I’d want a full second of latency on button presses. I would have figured Amazon used BTLE to the Alexa and used it as a BT to WiFi gateway
BTLE and/or their IoT mesh network (Sidewalk?) would be a good way to go too, but if it's just a button to reorder laundry detergent or something then I don't think even a 30 second delay would be a deal killer for most people.
reply