klempner

>HDDs typically have a BER (Bit Error Rate) of 1 in 1015, meaning some incorrect data can be expected around every 100 TiB read. That used to be a lot, but now that is only 3 or 4 full drive reads on modern large-scale drives. Silent corruption is one of those problems you only notice after it has already done damage.

While the advice is sound, this number isn't the right number for this argument.

That 10^15 number is for UREs, which aren't going to cause silent data corruption -- simple naive RAID style mirroring/parity will easily recover from a known error of this sort without any filesystem layer checksumming. The rates for silent errors, where the disk returns the wrong data that benefit from checksumming, are a couple of orders of magnitude lower.

The almost as interesting takeaway I have (which I am sure is in their internal postmortem) is that they presumably don't have any usage of glibc getaddrinfo clients in their release regression testing.

The actual algorithm (which is pretty sensible in the absence of delayed ack) is fundamentally a feature of the TCP stack, which in most cases lives in the kernel. To implement the direct equivalent in userspace against the sockets API would require an API to find out about unacked data and would be clumsy at best.

With that said, I'm pretty sure it is a feature of the TCP stack only because the TCP stack is the layer they were trying to solve this problem at, and it isn't clear at all that "unacked data" is particularly better than a timer -- and of course if you actually do want to implement application layer Nagle directly, delayed acks mean that application level acking is a lot less likely to require an extra packet.

Speaking of Slashdot, some fairly frequent poster had a signature back around 2001/2002 had a signature that was something like

mv /bin/laden /dev/null

and then someone explained how that was broken: even if that succeeds, what you've done is to replace the device file /dev/null with the regular file that was previously at /bin/laden, and then whenever other things redirect their output to /dev/null they'll be overwriting this random file than having output be discarded immediately, which is moderately bad.

Your version will just fail (even assuming root) because mv won't let you replace a file with a directory.

Sure, in the middle of a magnitude 9 earthquake I'd rather be in the middle of a suburban golf course (as long as it is far from any coastal tsunami) than any building, but I don't spend the majority of my time outside.

Two issues: 1. If you're making this choice during an earthquake, "outside" is often not a grassy field but rather the fall zone for debris from whatever building you're exiting. 2. If the earthquake is big/strong enough that you're in any real danger of building level issues, the shaking will be strong enough that if you try to run for the outside you're very likely to just fall and injure yourself.

As someone who is super nearsighted, the smaller screen on a phone is great for reading, especially in contexts like bedtime reading where I want to have my glasses off.

I have read many hundreds of books this way.

The problem with a tablet is that most tablets, especially the sort that are good for seeing entire as-printed pages at once, are too big for me to keep the entire screen in focus without wearing glasses. (with that said, foldables improve things here, since the aspect ratio bottleneck is typically width so being able to double the width on the fly makes such things more readable.

There's a weird fetishization of long uptimes. I suspect some of this dates from the bad old days when Windows would outright crash after 50 days of uptime.

In the modern era, a lightly (or at least stably) loaded system lasting for hundreds or even thousands of days without crashing or needing a reboot should be a baseline unremarkable expectation -- but that implies that you don't need security updates, which means the system needs to not be exposed to the internet.

On the other hand, every time you do a software update you put the system in a weird spot that is potentially subtly different from where it would be on a fresh reboot, unless you restart all of userspace (at which point you might as well just reboot).

And of course FreeBSD hasn't implemented kernel live patching -- but then, that isn't a "long uptime" solution anyway, the point of live patching is to keep the system running safely until your next maintenance window.

Are you sure you're not thinking of "SmartDay" days that are part of the SmartRate program?

Flex Alerts are CAISO and ultimately about grid stability. SmartRate/SmartDay are ultimately about marginal cost of production on PG&E. The two are certainly correlated -- at the very least, a Flex Alert day is almost guaranteed to be a SmartDay.

Notably, the SmartRate program is capped at 15 days per year, and in practice PG&E will keep a few in reserve for surprise late season events, but even if there are no Flex Alert days they're still going to be called on electricity-is-expensive-even-if-the-grid-is-stable days.

Are you sure these "cheap vape pens" don't just use 5V3A, which doesn't require any PD negotiation at all? (a lot of them screw even that much up, and a lot of people confuse "PD negotiation" with simply having the right resistors on the CC pins)

There is real cost savings here -- the RPi5 avoided the need for a buck circuit, and for that matter probably a dedicated PD controller chip.

In contrast, in the context of a "cheap vape pen" you have a battery which means you need to be able to convert to (and from!) battery voltage, so you need that conversion circuitry anyway.

Any currently existing (to say nothing of two years ago) "TB/USB4" chipset would dramatically increase the price of something with a retail price on the order of $50.

With that said, DisplayPort Alternate Mode would be considerably more straightforward.

> That would be 100 watts!

The point is that power dissipation in a cable is a function of the current going through it. The cable will get exactly as hot carrying 5 amps with a voltage of 5 volts as it will carrying 20 or 48.

(now, that is more *wasteful* -- you lose the same amount of power to heat carrying 25W at 5V5A as you do at 100W 20V5A, but that's 4x the relative waste in power)

> Many people just grab any usbc cable, and solder it directly to GPIO power pins.

You're not going to get *any* 5 amp mode out of a standard PD power supply unless the cable indicates it is 5 amp capable, which isn't going to happen unless that "any usbc cable" has the right emarker on it.

> limit for 5 volts is 3 amps.

There is no such limit.

What there is is two things: 1. There are a standard set of PDOs a standard "X watt" PD power supply is supposed to provide. 5V3A 9V3A 15V3A 20V5A, (then 28, 36, and 48 volts for EPR) with the highest one limited to the power limit of the supply. These only go up to 3 amps until you get to 20 volts. 2. Devices are supposed to support those standard PDOs.

Anything other than those standard PDOs is optional (at least before 3.2 which starts introducing AVS as a requirement at 27W+). 12V support is common, as for that matter is PPS support. 5A support below 20V in fixed PDOs is 100% allowed but is super rare.

(5A lower voltage PPS is a different story, but unfortunately the RPi5 doesn't know how to negotiate 5V PPS. That is a shame because it would 100x its power supply compatibility because most chargers targeting higher end Samsung phones support it.)

A power supply is 100% allowed to support 5V5A. It just isn't required to. It would have been 100% legitimate for the RPi5 to have a buck circuit to handle a standard 27W 9V3A power supply and then turn that buck off if the power supply and cable support 5V5A.

> Initial batches of Pi4 did not even had a resistor, to request 3.0 amps!

To be precise, it had *a* resistor (connected to the shorted together CC pins) when it was supposed to have one separate resistor for each pin, and that broke cables with emarkers.

> NEVER. EVER. EVER. Leave a test early.

It has been nearly 20 years, but my rule of thumb was that I wouldn't leave until I had done *three* review passes of the test. That is, quadruple checking, completing the exam and then reviewing my answers three times. That is pretty far into the diminishing returns for me catching my own errors.

That *almost* never happens, but there are exceptions -- sometimes they really do give way way more time than you need, especially if you are already strong at the material in question.

With that said, the key point is that the time tradeoff here for leaving early is terrible in typical college classes that have heavy weight on exams. Especially the first 10 -20 minutes of double checking is very likely worth 5+ hours of homework time or study time in terms of points towards the grade.

Huh? There are plenty of good reasons to complain about the 5V5A thing, but "fire hazard" is not one of them.

It is even entirely within spec for a PD power supply to offer a 5V5A PDO, as long as it is only doing so with a 5A capable cable (i.e. 100W or 240W). 5V5A is no more a fire hazard than 20V5A.

The spec violation isn't that it negotiates 5V5A when available, but that it isn't willing to buck from 9V or 15V to get those 25W which means that power supply compatibility is incredibly limited.

At the very least, the benefits of QUIC are very very dubious for low RTT connections like inside a datacenter, especially when you're losing a bunch of hardware support and moving a fair bit of actual work to userspace where threads need to be scheduled etc. On the other hand Cloudflare to backend is not necessarily low RTT and likely has nonzero congestion.

With that said, I am 100% in agreement that the primary benefits of QUIC in most cases would be between client and CDN, whereas the costs are comparable at every hop.

The somewhat moribund Foresight Exchange which is a ~30 year old play money idea futures market has discussed this idea a lot over the years, even to the point of having a number of "True" claims of exactly the form described in the article, such as http://www.ideosphere.com/fx-bin/Claim?claim=T2015

Speed of light is very relevant for actual performance sensitive software, not just shitty overly chatty trash.

While in practice the latency is over an order of magnitude larger, the speed of light round trip distance between two sockets on the same motherboard is likely on the scale of 1-2 nanoseconds which is already several cycles. Once you're talking about warehouse sized datacenters the speed of light distance can get into the microseconds even in a straight line through vacuum/air.

How exactly does this interact with fork()?

The idea that RAII covers "99% of your ass" is "the low-IQ level statement".

Temporal safety is the primary hard problem from a memory safety standpoint, and RAII does nothing to solve it at least the moment a memory allocation crosses abstraction boundaries.

And browsers don't support them either, at least in any useful manner.

What's particularly confusing is that this appears to be coming from the dev team themselves -- this isn't some rando pointing at an interesting unprepared github they found.

Like, if they're looking for publicity by sharing their github page, I'd expect the readme to have a basic elevator pitch, but their benchmarking section is a giant category error and it's missing even the most high level of summary as to what it is doing to achieve good throughput at high packet loss rates.

Try living in Japan, where you're generally forced to use the name in your passport, including any middle names included (with space) in given name.

Meanwhile a typical Japanese name is no more than three characters each for family and given names, but someone with a western name will have several times that, complete with spaces. And of course most of the companies running various websites and computer systems don't care, because foreigners are a single digit percentage of the market. If you're lucky you can use a separate but equal foreigner flow with fewer features available. (I am looking at you, JAL Mileage Bank and your SEVEN character family+given name limit!)

It is typically possible to circumvent this using paper systems, but that's a particular shame -- one of the nice points about online computerized forms is that it is easy to send them back and forth through browser integrated machine translation which can make them vastly easier to fill out.

This is ultimately just a bunch of bog standard USB and DisplayPort (even the HDMI is going to look like DisplayPort to the host). It should work as well as any other Thunderbolt dock works in Linux.

There's some room for driver issues, but if it works with "Ubuntu" it almost certainly is fine in that respect assuming you're using a recent enough kernel.

Yes, grpc_cli tool uses essentially the same mechanism except implemented as a grpc service rather than as a stubby service. The basic principle of both is implementing the C++ proto library's DescriptorDatabase interface with cached recursive queries of (usually) the server's compiled in FileDescriptorProtos.

See also https://github.com/grpc/grpc/blob/master/doc/server-reflecti...

The primary difference between what grpc does and what stubby does is that grpc uses a stream to ensure that the reflection requests all go to the same server to avoid incompatible version skew and duplicate proto transmissions. With that said, in practice version skew is rarely a problem for grpc_cli style "issue a single RPC" usecases: even if requests do go to two or more different versions of a binary that might have incompatible proto graphs, it is very common for the request and response and RPC to all be in the same proto file so you only need to make one RPC in the first place unless you're using an extension mechanism like proto2 extensions or google.protobuf.Any.

Unfortunately such a tax would be limited by prop 13 in California.

While the proposals here can be implemented on a local level, any change to prop 13 would be a state level ballot proposition.

(For the record, I'd love to see reform of prop 13. While I love the idea of smoothing out over a number of years the impact of sudden inflation or increases in local housing prices on existing residents, it should be a smoothing rather than an entitlement for long term owners of multi-million dollar homes to avoid property taxes.)

In practice the only widespread attack that either TOTP or SMS authentication help with is credential stuffing, and if you use a password manager to use unique passwords on each site you're not susceptible to credential stuffing to begin with.

I will remark that, excluding cases where some idiot is offering several times what the company is worth, it is rare that the fiduciary duty issue would force the management of a company to choose unsustainable immediate gains.

The value of a company's equity is based on the net present value of future returns. That means that while short term earnings are important, so are earnings in the moderately distant future. (depending on risk free interest rates)

If a company like Boeing were properly managed, they'd give suitable priority to engineering excellence, at least to the point of not having critical failures like these, because that's core to their ability to compete with Airbus/etc in the future.

The real issue you're concerned about is that it is very difficult to align the interests of corporate managers with the interests of the company. It is relatively easy to align senior management with short term stock prices, but it is difficult for the public to figure out that the gains they see (less engineering cost, faster turnaround time, etc) come at the expense of the longer term viability of the company, so the former gets priced into the short term stock price (and so executive compensation) and the latter does not.

And of course that guarantee has its own problem, namely that (especially in a multithreaded process) a use-after-close error is vastly more likely to cause corruption via a write to a newly opened file in the old file descriptor.

And in all fairness, nobody was thinking of multithreading when these APIs were designed. We're lucky enough that errno mostly works as a thread local rather than a global.

The funny thing is that select's APIs are compatible with a non-broken implementation, such as something that heap allocates if above a constant size. My recollection is that some implementations (winsock?) even do this.

Of course, that's never going to actually happen on implementations people care about between ABI breaking on the one hand and the existence of poll/epoll on the other.

(My biggest concern in practice is random shitty libraries using select behind the scenes and then silently corrupting memory in processes that have more than a few file descriptors.)

How can you come up with an "upper bound estimate" without having some idea of the structure of the computation of the specific 748 state Turing Machine in question?

Imagine you had an oracle telling you BB(748) excluding this machine. How do you get an upper bound on the runtime of this machine?

(There is an answer: this is surely not the optimal construction, and so such an oracle would give you an answer for some smaller ZFC machine which you could likely use to extrapolate a value for this machine. However, eventually you'll find a minimal state ZFC machine and that won't work anymore.)

The flip side here: the ads I get on Quora are just terrible -- about 1/3 of it is some "stud briefs" underwear and about 1/3 is promoted CCP propaganda.

These are the ads of "they can't come up with enough ads to show me because not enough people are advertising on this platform".