For me, it maps to pandemic, which was midway through my time at GOOG. That's when the COVID-sparked Zero Interest Rate Policy caused the company to hire engineers and PMs like crazy. There were suddenly too many new hires to inculcate with the old leadership and engineering ethos—especially via remote work—and the values got diluted, probably beyond the point of recovery.
Obviously what you said is not some unheard-of secret or deep analysis. It is a running joke inside the Google system.
But... many Googlers who have a tendency of repeating these things have (1) not seen how shittier things are on the outside (2) are not in management and do not know how much manager lies to them (3) have unrealistic expectations of how well any process applied to 100-200k people can work. If you see a place that has a better overall promo system, you'll almost certainly find that it is a much smaller shop and things are decided more ad-hoc at the top with higher information flow.
Specifically, for (2) the manager and their adjacent group can clearly flag the slipping under the rug behavior and ding one's promo. However, sometimes when they message it back they would lie about it to the employee and blame some other management or requirement or complexity, etc. Other times, the manager is a "people manager" moron and non-technical, and can't really evaluate (in which case it's not the process that's at fault, but useless management.)
It's also not clear that the optimal quality is achieved by spending more time "perfecting" things. At Google, people already work much less than other companies. Perhaps the answer is in fact the opposite: pushing to ship more milestones per unit of time and driving harder to then perfect it. My bet is if the promo packet was accepted without a full "launch"[1] they would have still shipped the same half-baked crap at a later point in time.
[1]: many years ago, they wanted to reduced half-baked "launches" and said we want "landings" not "launches" and wrote some documents explaining the difference and self-congratulated themselves. Net result: s/launch/landing in promo packets.
Haha, almost everything at Apple that is not seen by the user is full of crap (and increasingly you see user facing bugs and schedule slippage too). Possibly still somewhat true in hardware, but in software, they have far worse engineering practices than Google: remember "goto fail"?
Back in Snow Leopard days you could instantly crash the kernel with a fuzzer. In fact I managed to do that accidentally by hand. NT kernel had much more systemic hardening than XNU.
Apple also treats employees capriciously and in non-standard ways. Your experience is almost entirely dependent on who your manager is. I have never heard any of big tech make so many false promises to employees. I have friends who negotiated for an immediate green card application upfront, but they later found out they were bait and switched, etc.
As a host seems to refer to the machine that executes the tool not the machine that is being DFU'd.
Intel Macs with T2 actually do have a DFU process as the primary processor is in fact T2, which loads UEFI image in RAM once it validates boot situation and resets the Intel chip.
I mean, NSA-blessed or not, the way this happened was not some hidden conspiracy. It was in the open. The reason it happened is all of these machines are basically made to run Windows, so they need to have Microsoft keys. Microsoft was pushing for Secure Boot, for security and "trusted computing" (evil or good, depending on your PoV,) and open source complained that this is a way to lock in users to Windows, so the compromise choice was to have them sign a GRUB shim so that Linux could just as easily be run without enrolling your own keys.
Is this a failure? Absolutely. The article tries to brush this off, but there is no denying it. Operating without an IPv4 stack is not going to happen with v6.
I have no v4 on this machine. I'd disable the v4 stack on it if that was a thing Linux could do, but as it stands it's just sitting there doing nothing.
The thing you're claiming is not going to happen is something I'm already doing.
I was talking about internet at large. You, and many clients, are of course able to do it on your box, but to use the whole internet, you will at some point hit a translation point which uses v4. The point is the internet at large is never going to reach a point where there won't be two internets; at this point it is pretty clear v6-only will not be a thing with the current set of technologies before a future protocol supersedes one or both.
Has been in more of a maintenance mode with a multiple of those people. If anything, the pace of the product has improved. Regardless of what you think about Musk, the company he bought was a bloated mess.
I mean, the answer is obvious if you do not deliberately try to put a message in the worst light possible:
- "Space company" has a major LLM+datacenter business called X.ai.
- LLM for coding is a big business, as you can see from trillion dollar valuations of Anthropic.
- Cursor is popular and gives you a headstart on the business.
- Instagram was bought for the price of many many hospitals. Uber is more valuable than companies owning the cars. Different business models, entirely different valuation models. Not sure what that comparison entails. You know it. I know it.
Whether it is a good purchase or not, we may not know, but we know your characterization is just outright dismissal without much rationale behind it.
It does not have to be brushed away as "brute force" necessarily. We can, and do, build more reliable systems out of less reliable components. In fact, most industrial engineering accepts some defect rate and builds margins around it.
Software is no different. Even without AI, you already have buggy compilers and buggy OSes and buggy libraries. You just tend to accept the risk because you have some idea of what the failure modes are and can work around it or manage the risk in some other way (buy literal insurance.)
> you already have buggy compilers and buggy OSes and buggy libraries.
Which run, I must add, on effectively infallible hardware. Most of the software straight up assumes that the CPUs and the RAM will function perfectly and don't bother even trying to detect such failures (unless those failures manifest themselves in a catastrophic manner, the show will simply go on).
So in effect, we also can, and do, build less reliable systems out of more reliable components, and that's how software is different.
I am not sure if I correctly understood your point. On one dimension, you are basically hinting at another anecdote that proves my point: hardware failure (specifically bit flip in non-ECC memory) is pretty much guaranteed to happen at scale, but people are mostly okay with absorbing that risk. I feel you are overselling the hardware reliability story. For sure, we can build less reliable systems out of reliable components. That goes without saying, and no, that's definitely not software specific. Almost by default most composite systems are less reliable than their primitives (simple example would be nailing two pieces of wood) unless specific care is taken to build in those guardrails or redundancies. The point, however, is it is possible, and there is a vast precedent for it.
>Which run, I must add, on effectively infallible hardware.
Keyword: effective. Hardware is also built on top of components with error tolerances. What do you think ECC memory is for? Or why chips have "yields" and parts that were "turned off" while shipping? Or how thermal throttling happens? Or CPU clocks, which have jitter to be corrected, and tons of other examples, all the way to transistors and capacitors.
My point is, when you go from hardware to software, there is a noticeable change in attitude and corresponding drop in reliability. Inside hardware, there is a lot of effort to detect and correct glitches and provide reliably correct behaviour; in software, the most common assumption is that the hardware will just work as intended. How many filesystems store checksums? Even back in the days when HDDs were way less reliable? And ECC exists in no small part because writing software that's reliable in the face of memory-corruption (at the very least can detect such corruption) while is possible, it's hard, costly, and produces less performant software (obviously).
Anyway, a larger point of my comment is that when we go from traditional software to AI, there a) seems to be an even bigger drop in reliability, b) the attitudes are even more cavalier, c) the software people largely lack most of discipline/knowledge required to build more reliable system from less reliable ones — because they spent most of their careers doing exactly the opposite: building software that they know will work incorrectly even on perfect hardware, and being fine with it. "You just tend to accept the risk", my ass. Yes, when it comes to software, people do this, but when it comes to hardware — remember when Intel messed up the division algorithm inside their chips?
> remember when Intel messed up the division algorithm inside their chips?
Yea, and what do you remember about that? Pretty much no normal person noticed before someone constructed a specific test case.
You know what I also remember? Meltdown, Spectre, which were indeed worked around by software tweaks in OS and compilers. There have been dozens of other microcode patches, etc. You are being too lenient in your assessment of the crap that hardware engineers ship. There's just a lot more of software out there with errors that are in your face, so you tend to notice them immediately. I give you one thing though: precisely because the remediation cost of a software defect is less than a hardware defect once shipped, people are not as worried about validation in most use cases. That's not inherently a mistake though, just intuitive cost-benefit assessment.
That it was a rather big PR disaster, and it cost Intel lots of money to recall the chips. Such things don't really happen with software; software is expected to have bugs, some of them maybe even catastrophic, but that's just the way the things are.
> because the remediation cost of a software defect is less than a hardware defect once shipped, people are not as worried about validation in most use cases. That's not inherently a mistake though, just intuitive cost-benefit assessment.
Yes, and also, the users are told to simply bear up with software bugs (and some low-priority ones sometimes never get fixed). So let's jump several levels of comments up:
> > > People who acknowledge the quality problem, but think they can deal with it by applying more AI to the output.
> > Brute Force: if it doesn't work, you're just not using enough.
> > What if they're right though?
> It does not have to be brushed away as "brute force" necessarily. We can, and do, build more reliable systems out of less reliable components... Even without AI, you already have buggy compilers and buggy OSes and buggy libraries.
My problem with the last comment is that it at the same times both dismisses the software and AI's quality problem ("nah, we 'can' build reliable systems") and also acknowledges that it very noticeably exists and needs to be dealt with somehow! And really, "buy literal insurance"? Who even sells insurance against software bugs?
You don't buy insurance for existence of a singular "bug." You can and people very often do buy liability insurance against damage caused by software bugs. You need to buy this stuff to be able to attach indemnification to enterprise contracts.
Is that only when mass hysteria is pushed against internet companies? How are they okay with this?