Yes, just one obvious example -- extrapolate to general life. That said, ease of access and scale beyond a critical point can make it qualitatively different.
The uniquely problematic aspect of prediction markets is not really the personal aspects of gambling. There are plenty of speculative vehicles. The problem is it subverts natural incentive structures that society has evolved to reward, by introducing another incentive signal; one that sometimes can be many times bigger, thereby manipulating the natural, real-world, outcomes.
If you were playing in the World Cup in the lesser teams, very often betting+sabotage/plausible negligence would have been a more profitable enterprise for you than to actually do your best to win.
Stock markets have this problem too, but they are much more regulated, and even if manipulated by insiders, the blast radius is smaller and often auditable.
I am old enough to remember Do Not Track and its failure and problems associated with it. What's new here? Why wasn't it adopted in the first place for GDPR?
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 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.
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.
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.)
I think there's a categorical difference between paying for long term maintenance voluntarily vs paying for something to exist. The latter works much better as the value prop is clear and you can scratch an itch. Kickstarter is similar.