HN user

tgma

5,596 karma

tgmmx@proton.me

Posts12
Comments850
View on HN

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.

It won't be just a couple. That's the point.

The curve is at 50% after an astonishingly long time and is already flattening.

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.

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.

It’s basically in maintenance mode

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.

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.

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.

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.

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.)

People who spew I'd rather pay, I'd rather pay often majorly underestimate how expensive Google and Facebook would have to be in the western world to offset the ad revenue per person. The irony is this is especially true for you if money is no object to you, as you'd be disproportionately valuable to the ad machine. It's not going to be ten bucks folks.

Googlebook 2 months ago

If anything the causality is exactly the opposite. The labor cost will go up (empirically provable) in such "shithole countries" once work is outsourced to them, improving their livelihood.

Googlebook 2 months ago

I was talking about a specific device on a specific dimension brought up by the GP, i.e., "freedom to tinker for the owner while preserving security for the masses." Whether that became a standardized process is a different story. By and large it has changed across models, but nevertheless it was a good balance of ownership/hackability without compromising security that can be emulated by other devices if they choose to.

Googlebook 2 months ago

Isn't that a feature not a bug? That means labor, a proxy for quality of life of the laborer, is more expensive than parts. That's abundance.

In fact, in "shithole countries" where everyone wants to emigrate from, it is exactly the opposite: i.e. you try to fix everything even if it takes sooo long.

Googlebook 2 months ago

You can easily remove the nag screen by opening the device and unscrewing a screw and running coreboot with SeaBIOS. Pretty neat security approach (not too hard to do, not too easy for a layman to fall for instructions to self-compromise). I have two that work just fine today.

If you actually start writing big stuff in assembly, esp a macro-assembler, you'd quickly realize it is more verbose, but not fundamentally that different from higher level programming. You basically need to get a hang of how to build abstractions with procedures and macros and you'd be good to go. Reading assembly effectively is often much harder than writing it.

Law does not run on a CPU with certainty. There is risk analysis going on: there are many jurisdictions at play. When you are big enough, something that has fundamentally viral characteristics by design can have catastrophic impact even if reading of the license as linked would be almost certainly accepted as correct and likely. Therefore, especially for a company like Google that has a unified codebase, that treatment is justified. So goes for other big companies who would be at least wary of just taking AGPL.