There's a question about the right units here. Your CPU performs more operations in its first millisecond* than most mechanical devices do in their entire lifetime. So in per operation units, they are staggeringly reliable.
Actual operating life is often determined by the economic feedback loop which causes manufacturers to cut costs until basically all consumer products have roughly the same expected lifetime, regardless of the potential of the underlying technology.
* Or at least, the first millisecond after it starts using its normal operating clock, which might not be the very first millisecond
> Actual operating life is often determined by the economic feedback loop which causes manufacturers to cut costs until basically all consumer products have roughly the same expected lifetime, regardless of the potential of the underlying technology.
Which is why, despite being a huge BEV proponent, laugh when I hear people say things as "BEV are inherently more reliable due to having no transmission and less moving parts that could break". It might have been true in the early stage, that we're currently at the end of, but we already know that the reliability of a second-hand mid-range ICE car is what market has been bearing for decades, so we can be certain BEVs will be "value-optimized" until they are just as unreliable.
Agents are new, but dumb coding practices are not. Despite what it may seem, the knowledge of how to manage development has increased. One practice I haven't seen for a while is managing by limiting the number of lines changed. (This was a dumb idea because rewriting a function or module is sometimes the only way to keep it comprehensible - I'm not talking about wholesale rewriting, I'm talking about code becoming encrusted with conditions because the devs are worried that changing the structure would change too many lines)
Buffer size is the product of bandwidth and delay, so if communicating with something close, it can still go fast.
Had an illustration of this once when my then-employers IT dept set up the desktop IP phones to update from a TFTP server on the other continental land mass. Since TFTP only allows one outstanding packet, everyone outside head office had to wait a long time for their phone to update, while head office didn't see any issue.
I see where you're coming from, but I disagree. If we see it as a dilemma between:
* trust giant unaccountable organisations
* do things yourself, because you're the only one you can trust
we won't solve the issue, because there are too many things that every individual would have to understand, execute correctly , and do so with perfect OpSec.
We need to work out the social bit, as well as the technical. How do we make it practical for individuals to delegate trust to smaller organisations, so that they can switch between them if they show signs of abusing that trust? This needs social innovation as much as technical - how do we bootstrap trustworthiness for small organisations? How do we do it fast enough that the next move is to an ecology of small organisations, not just to the next Facebook/Play Store?
Agree completely. A solution would probably need to involve:
1. The alternatives being relatively easy to setup and use. This has already happened with some FOSS software.
2. Social norms changing around them (ie, it's "cool" / "normal" / "expected" to use privacy and ownership preserving alternatives). Basically has not happened at all.
3. Laws prohibiting, or limiting to a significant degree, the extent of the abuse that can be inflicted, changing the incentives. GDPR, whatever you think of its execution or effectiveness, is at least proof this kind of thing can be done.
The latter two are both very difficult problems, but I don't see any other way out.
Occasionally people in the UK get caught putting cooking oil in their (diesel ) cars, which is not illegal per se - but technically if you do it, you should pay fuel tax, which they generally don't. McDonald's are large enough that they will be, knowing that they would inevitably be caught.
True, but in this case you'd need to make the PCB larger as you can't put any components on the part the USB plug will attach to (unlike the case with USB-A, where the contacts are only on one side. Nevertheless, this is worth considering if your goal is cost reduction rather than size reduction.
Unfortunately python does add features in a drip-drip kind of way that makes being behind an experience with a lot of niggles. This is particularly the case for the type annotation system, which is retrofit to a language that obviously didn't have one originally. So it's being added slowly in a very conservative way, and there are a lot of limitations and pain points that are gradually being improved (or at least progressed on). The upcoming lazy module loading will also immediately become a sticking point.
Shocking? Taxed on payout is a discount versus ordinary stiffs who get taxed every year. A percentage taken from the increase of an amount every year, is more than the same percentage taken at the end; as the former foregoes the opportunity to earn a return on the amount taxed earlier. This is quite significant over longer periods. (I learned that from one of Warren Buffet's annual letters - I think he was explaining why insurance is a great business to be in, because the same effect applies to long-horizon insurance policies).
Getting a lump-sum payment at the end of three years is worse than getting paid incrementally, and is sort of the opposite of how insurance companies make money (which is taking frontloaded payments for long-term liabilities and investing the float).
No; just the difference between someone who gets a fixed number of shares and has to sell them (and pay the tax on them) that year, versus someone who is allowed to accumulate the shares and pay the tax at the end.
This may assume that there is more alpha in the shares than other investments you have access to, which is perhaps less true today. But it should probably be your position if you're CEO of the company...
All the Buffett letters are online, but I don't remember what year it was. If I get time I may find it and report back.
Why do you think they get to accumulate shares and pay tax at the end.
If options Sundar will have the pay income when exercised, or if RSU, they will have to pay income taxes when granted.
If you want to research the tax imlications, the relevant term is PSU (Performance Stock Units), which is the form almost all of these CEO incentives take.
(edited) My bad, I meant to type "options" not "shares". You get to choose when to exercise options. When tax is incurred will vary according to your jurisdiction.
I'm fairly sure that Sundar Pinchai will have paid someone to research the tax implications before negotiating this deal.
I used to use brown noise, but I find that rain/ thunderstorm sounds are better. It's a noise that your brain is used to ignoring, and other sounds blend into it - even if they are almost as loud -while with the more homogeneous brown and white noise, it has to be louder than the sounds it's trying to mask.
Having said that, I'm not sure how well it would do for high pitched tinnitus.
Edited to add - now listened to the neuro modulator, nice one.
Actual operating life is often determined by the economic feedback loop which causes manufacturers to cut costs until basically all consumer products have roughly the same expected lifetime, regardless of the potential of the underlying technology.
* Or at least, the first millisecond after it starts using its normal operating clock, which might not be the very first millisecond
reply