Putting the WiFi SSID and password on the side of the energy monitor sensor box allowed for this:
> The whole thing was quite dissapointing. However, I do have a few Raspberry Pico microcontrollers lying around at home. If I could connect to the WiFi network of the energy manager directly and get the data from the server, I could just extract kW consumption from the API, multiply it by a correct rate and then display it on some Grafana instance.
Regulating here is necessary, but the challenge is steep! IoT devices may include a complex bill of materials (BoM) including software (SBoM). Vulnerabilities can appear in any of those components.
On the one hand, CVE and vulnerability databases are excellent, and with some automation of vulnerability and patch availability the's the possibility of automated re-build.
But the manifests can be huge. And some component could be vulnerable, but was never anticipated to be so, and perhaps doesn't even have the means to be patched. Update processes for sub-sub-components may not have been exercised, and could lead to bricked products.
So labelling and guarantees are welcomed. But the challenge is practically insurmountable, and until the entire industry steps up to meet it, labelling and guarantees are going to be 'best effort'.
Totally valid point. Escrow then open sourced, or perhaps even some insurance policy so that the future patching and vulnerability remediation is guaranteed.
There's a bunch of stuff consequential to EO 14028 which could allow for some automation of library vulnerability.
I was trying to think of ways to finance it, and "future patch insurance" is clever! There are other sorts of business insurance where the insurer is liable even if the business no longer exists, so it would be doable. Though a policy would require a level of technical competency that other insurance policies don't, since their providing a guarantee of service rather than a guarantee to pay out a certain amount in damages.
Someone must have felt very clever when they concluded Erlang would be dimensionless.
Calls per second X seconds per call = no unit.
But that's wrong. Clearly the number of calls ongoing maps on to lines being used for a circuit-switched network, or datagrams in flight, or whatever. Far from dimensionless.
Call_starts per second X call.seconds per call_start = calls as the unit
Well, for languages that are now touting interop with C++, and the emergence of a mainstream memory safe language like Rust, Carbon seems like a retrograde step to me.
Val is probably the next language that fleeing C++ developers should get behind.
Radix sort is theoretically O(N), but memory access is logarithmic so in reality you can't do better than O(log N) no matter what algorithm you use. Only constant factors matter at that point.
Edit: I misremembered, memory access is actually O(sqrt(N)):
Nothing theoretical about it: Sorting a list of all IP addresses can absolutely and trivially be done in O(N)
> in reality you can't do better than O(log N)
You can't traverse the list once in <N so the complexity of any sort must be ≥N.
> but memory access is logarithmic
No it's not, but it's also irrelevant: A radix sort doesn't need any reads if the values are unique and dense (such as the case IP addresses, permutation arrays, and so on).
The author ran out of memory; They ran a program that needs 10GB of ram on a machine with only 8GB of ram in it. If you give that program enough memory (I have around 105gb free) it produces a silly graph that looks nothing like O(√N): https://imgur.com/QjegDVI
The latency of accessing memory is not a function of N.
The latency of accessing physical memory is asymptotically a function of N for sufficiently large N - ie. big enough that signal propagation delay to the storage element becomes a noticeable factor.
This is not generally relevant for PCs because the distance between cells in the DIMM does not affect timing; ie. the memory is timed based on worst-case delay.
> The latency of accessing memory is not a function of N.
How could it not be, given that any physical medium has finite information density, and information cannot propagate faster than the speed of light?
And on a practical computer the size of N will determine if you can do all your lookups from registers, L1-L3, or main RAM (plus SSD, unless you disable paging).
I feel we must be talking past each other. I thought the examples so far were about random access of N units of memory. The standard convention of pretending this can be done at O(1) always struck me as bizarre, because it's neither true for practical, finite, values of N (memory hierarchies are a thing) nor asymptotically for any physically plausible idealization of reality.
You still need to write each element to the target, which costs O(sqrt(N)), so the "strict" running time of radix sort would be O(N^1.5) in layered memory hierarchies. In flat memory hierarchies (no caching) as found in microcontrollers, it reduces back to O(N).
But radix sort doesn't write randomly to the output array like that. Yes, each element ends up in the right place, but through a series of steps which each have better locality of reference than random writes.
In this way, radix sort is usually faster than an "omniscient sort" that simply scans over the input writing each element to its final location in the output array.
If you can't see the clear sqrt(N) behaviour in those plots, then I recommend using an online graphic calculator to see what such a graph actually looks like. The sqrt trend is plain as day.
Also radix is a pretty special case because it assumes you want to sort by some relatively uninteresting criteria (be honest, how often are you sorting things by a number and only a number?). What happens in the real world is that the size of fields you want to sort on tends to grow in log n. If you had half a billion John Smiths using your service you’d use some other identifier that is unique, and unique values grow in length faster than logn.
I’m glad other people are having this conversation now and not just me.
Here’s a different take: if you find yourself needing to sort a lot of data all the time, maybe you should be storing it sorted in the first place.
Stop faffing about with college text book solutions to problems like you’re filling in a bingo card and use a real database. Otherwise known as Architecture.
I haven’t touched a radix sort for almost twenty years. In that time, hardware has sprouted an entire other layer of caching. I bet you’ll find that on real hardware, with complex objects, a production-ready Timsort is competitive with your hand written radix sort.
I develop programs that take unsorted data as input, and sort them as part of the processing... I haven't touched a database in 10 years, because I do graphics programming, nothing that needs a database. Also, I don't actually use radix sort but a hand written CUDA counting sort that beats the crap out of radix sort for my given use cases, since counting sort is often used as part of radix sort, but simple counting sort is all I need.
> and use a real database.
I'm not going to use a database to store tens of billions of 3D vertices. And I'm not going to use a database to sort them, because it's multiple times, probably orders of magnitude faster to sort them yourself.
It's weird to impose completely out-of-place suggestions onto someone who does something completely different to what you're thinking of.
Radix sort works for numbers and so also for characters. Then it also works for lexicographic ordering of finite lists of any type it supports. So it can sort strings. But also tuples like (int, string, float). So it can actually sort all plain old data types.
MSB Radix sort is a pretty good fit for this John Smiths input and will definitely outperform a comparison-based sort that has to check that "John Smith" equals itself n log n times.
random memory access has a non-constant upper bound (assuming infinitely ever larger and slower caches), but radix sort is mostly linear memory access.
Sure, you can force a fiction of O(1) by dramatically increasing latency and strictly limiting the size of memory, as we do with microcontrollers. This would now be O(1) with a very large constant factor overhead, basically pinning memory access to the latency of the memory cells that are furthest from the CPU.
I'm not disputing you can establish an upper bound on latency. You can always do this by using a system's slowest component as the upper bound and pin everything else's latency to that bound, as I said. I'm just pointing out that this upper bound a) doesn't scale well/leaves a lot of performance on the floor, and b) the upper bound is very sensitive to size and geometry.
In high performance systems, constant time random access is just not constant.
