This is also a problem when reviewing changes through github-like workflows, and even more with patch-based workflows. It's probably either impossible or very difficult to fix that ever.
Certain linker operations can be multi-threaded (not sure if this is specifically true for LLD). Particularly LTO in the GNU toolchain, but also there's been a lot of effort recently to make linking faster by actually having it use all available cores.
Believe me, hCaptcha isn't much better even if you're not blind! They show me minuscule images which are barely distinguishable from each other. It manages to be much worse than reCaptcha, which is some achievement.
I'm not blind, but do have visibility issues. I can get by on my phone with maxed text size, etc. The pictures for hcaptcha are horrible... I keep having to zoom in and out. It's almost as bad as modals that flow off screen.
It sucks more when you work in the space and take a lot of care to usability. It's not that hard most of the time.
On a related topic, has anyone had luck deploying TCP fastopen in a data center? Did it make any difference?
In theory for shortlived TCP connections, fastopen ought to be a win. It's very easy to implement in Linux (just a couple of lines of code in each client & server, and a sysctl knob). And the main concern about fastopen is middleboxes, but in a data center you can control what middleboxes are used.
In practice I found in my testing that it caused strange issues, especially where one side was using older Linux kernels. The issues included not being able to make a TCP connection, and hangs. And when I got it working and benchmarked it, I didn't notice any performance difference at all.
Tape has a tremendous density advantage over disks. Think about how much area a tape occupies if you were to completely unroll it, and compare that to a disk platter. The flip side is access times are extremely long compared to disks, but for the usual application of backup and recovery that doesn't matter much. In this case they're pairing the tape with faster non-volatile storage so writes at least will be very quick (reads not so much, 2 minute access time!)
The 2min number is likely an average over a large volume of drives.
An LTO 9 tape has over a kilometer(!) of tape in it.
You can spool the tape only so fast without risking damage to either the tape itself or the cartridge so if your file is at the end of the tape you’ll be waiting for a while.
It's a single tape. Even without any kind of fast forward, the write speed of LTO-9 is 6 meters per second. It takes three minutes to go completely end to end.
It's basically the same thing, except the initial charges in each cell are created through the photoelectric effect when the sensor is exposed to light. After that, it's the same conveyor-belt-style readout proces as for the BBD.
It's also why CCDs tended to have problem horizontal or vertical halos around bright lights. Nowadays, most cameras use CMOS sensors, where the amplification and readout circuitry is integrated directly into each photosensitive cell.
A bucket brigade delay obtains a sample of a voltage on one end, and then shifts copy of that charge among the cells to the other end. The delay line as a whole contains a window of samples at any point, but that window is such is not accessed.
A CCD line obtains a window of samples directly: the cells are charged according to light sensors. Then this window of samples is shifted out in the same way as a bucket brigade delay line.
So the main differences are that the bucket brigade is clocked continuously, running nonstop and that only one of the cells obtains the sample.
The CCD runs only briefly after an image has been exposed and capture has been triggered, in order to shift out the samples, and sampling takes place at every cell.
A bucket brigade can be slowed down or sped up to change the delay. That affects the sampling rate and therefore frequency resolution. That's how we can create a chorus effect for musical instruments. So the clock speed is a direct functional parameter. Slowing down or speeding up the CCD doesn't make a difference to the result, except that there's likely an ideal range of rates, balancing between the time needed to accurately charge one cell to be equal to its neighbor, while being fast enough to avoid leakage.
Check out the datasheet for this single row CCD sensor[1]. Look at pages 2 and 6, which show the block diagram and control signal waveforms. There is a single analog output pin. To read the device the "analog shift register" is used, which is a bucket brigade device to move the charge from the photo diode to the output buffer.
> A followup article on deliverability would be helpful as many people seem to only have a surface level understanding of the difficulties of deliverability.
I think if one did curate such a list, then importance (both number of users, and societal impact) should be a key factor. KiCad is an important project on both dimensions.
reply