rsaxvc

All back now.

Looks like I got hit, nothing showing after Jun 1.

My cat did this, but only started after I was gone for three weeks.

The night I got home he was so happy he started bringing me his toys on bed. All of his toys. Eventually various household objects. Finally a wooden spoon to my face! I was so confused I tossed it away, and he played fetch with it ever since(and later other objects sometimes).

> Right. They're going to get all the streetlights in an entire city to blink in unison. Sure they are.

The article states they use GPS for synchronization. I wish they went into it further, but a number of affordable chipset can do emit PWM at the proposed frequencies, globally aligned in time to PPS(every receiver computes the same top of second), then the telescope exposes during the blanking time.

On a related note I have a 1MHz GPS time source in my office that is synced to a 10MHz OCXO(more common for test gear) so my equipment is phase synchronized to GPS. It's really spooky to sync the oscilloscope to one time source and probe another time source with the scope and watch how their phases don't perceptibly drift from each other.

They need phase locked too. Edit: article says they're using GPS, probably using PWM-aligned-to-PPS.

You could probably do something simpler now since the new ARMs have good hardware virtualization support.

> Moreover there's also the instruction cache, and I'm not sure if you can disable caching for that in a meaningful way?

Intels used to boot with their caches disabled, but I haven't worked with them in forever, and never multicore.

I worked with a lot of microcontrollers, and it's not uncommon to be able to disable the instruction cache there.

There are a few things that require the data caches too, like atomic accesses on ARM. Usually we were doing something fairly short though in our realtime code, so it was easy enough to map just the memory it needed as uncacheable.

You're right! I can think of two cases I've run into where bypassing the cache can be faster compared to a miss.

On some caches the line must be filled before allowing a write(ignoring any write buffer at the interface above the cache) - those basically halve the memory bandwidth when writing to a lot of cache lines. Some systems now have instructions for filling a cache line directly to avoid this. And some CPUs have bit-per-byte validity tracking to avoid this too.

Even on caches with hit-during-fill, a direct read from an address near the last-to-be-filled end of a cacheline can sometimes be a little faster than a cache miss, since the miss will fill the rest of the line first.

I don't know for x86.

But for things that really matter, I've tested by configuring the MMU to disable caching for the memory that the realtime code lives in and uses to emulate 0% hitrate. And there's usually still a fair amount of variance on top of that depending on if the memory controller has a small cache, and where the memory controller is in its refresh cycle.

>That's particularly interesting because at one time years ago, I saw suggestions that Linux could run as a task on an RTOS.

I've worked with systems that ran Linux as a task of uITRON as well as threadX, both on somewhat obscure ARM hardware. Linux managed the MMU but had a large carveout for the RTOS code. They had some strange interrupt management so that Linux could 'disable interrupts' but while Linux IRQs were disabled, an RTOS IRQ could still fire and context switch back to an RTOS task. I haven't seen anything like this on RPi though, but it's totally doable.

I thought it was a marketing gimmick to get big iron competitors off homebrew risc solutions. Because Intel.

Three appropriately spaced antennas will give you azimuth and elevation of a ray to the transmitter, but not distance.

But using two of the above in different, known locations would allow you to compute the intersection to a 3D location.

If you want to get really spicy, you can use two antennas and an SDR to compute angle of arrival using nothing but a BLE advertisement's data . This is different from BLE AoA as it doesn't require a cooperative transmitter.

You could use the BLE AoA extension as well to derive an angle: https://www.bluetooth.com/blog/new-aoa-aod-bluetooth-capabil...

You could mount one at each corner and use a directional antenna to help.

Back in the days before Oracle, Sun would sell you a dual socket Opteron desktop and you could add your own FPGA right on the hypertransport in the second socket.

Exciting to see that capability becoming more standardized with CXL.

Edit: phrasing.

> Under the circumstances, SBF’s wisest course would have been to just say yes—or yep—to her questions.

Why did he take the stand at all?

To continue the analogy: probably, you're just not on the right subnet.

In the US many states collect DNA samples at birth, as well as for citizens born abroad.

That's a good question, I don't know.

I suspect the specific case of sdiv may be practically handled already for post-div Armv7a and ARMv8a AARCH32 on dynamically loaded operating systems, either by the dynamic loader or the compiler support library choosing to swap in a different implementation of __aeabi_idiv according to the available capabilities.

It seems a lot like photoplethysmograph (PPG), in that you get a time domain signal of something related to instantaneous capillary blood pressure, and you process that signal to derive heart rate, and sometimes HRV and other things. The APG transducer is a microphone rather than a PPG LED+photodiode optical pickup.

I don't know how far you could take it though. Irregular heartbeat in a resting patient, possibly. Clogged artery not in the measurement path in an active patient - probably not. The further from the heart the less and less it looks like an ABP blood pressure wave. I bet activities like jumping up and down would show some amount of interference from blood sloshing around in APG just like in PPG.

If you want to look at some data, https://physionet.org/ has some recordings of PPG and ABP and you can see how they differ. (Edit) like this one: https://physionet.org/content/mimic3wdb-matched/1.0/

Ext4 has changed their binary format twice with only forward compatibility. Mounting a new, large ext4 partition often won't work on old machines.

Source: had to patch yaboot(PowerPC Mac bootloader) to update ext4 to boot with /boot on ext4.

I think you're right that it serves only as a way to communicate to the kernel that userspace wants MTCP socket.

See also: Intel SKX102, whose documentation has nice diagrams.

I had assumed that since IPPROTO_MPTCP(262)!=IPPROTO_TCP(6), they were using another protocol number for everything, but you're right that there's a TCP option involved too.

But also, plenty of stateful firewalls will strip unknown options. Here's how to enable Ciscos to forward it: https://www.cisco.com/c/en/us/support/docs/ip/transmission-c....

Edit: here's checkpoint: https://support.checkpoint.com/results/sk/sk114666

If I understand correctly, the protocol stack is built on TCP, but they use different IP protocol numbers, so a router or firewall may easily pass TCP, but not MPTCP(either by configuration or age).

> I think an example is something like opcodes crossing I-cache lines

Consider also a 16-bit aligned 32-bit instruction crossing a page boundary, potentially with different access permissions. This type of bug allowed userspace applications to hang early Cortex-A8 based phones(ARM errata 657417).

Do you know if Pi5 has SD/A2 support?

> What never happened is local, highly parallel algorithms.

GPUs maybe? Also, excellent answer.

This. Every one of these attacks I've worked were loud due to the volume of logins and ratio of failures.

Lol. "Hey Bob - why are we in the news for a breach?" Seems closer given the news reporting and their tardy response.