If it's running on MMU-less systems, I'd be interested in how it loads multiple programs into memory: does it need to relocate each program binary? If so, doesn't that preclude using execute-in-place (XIP)?
Generally, running in a MMU without static task config would require relocatable binaries. I'm not sure why it'd preclude execute-in-place. As a relocatable binary should be executable from generally any address space. However I suspect that hardware without an MMU is not super likely to be able to support XIP.
It is based on FreeRTOS, so it should be fairly well documented.
> I suspect that hardware without an MMU is not super likely to be able to support XIP.
This seems strange to me. Don't most microcontrollers support executing directly from flash? Some even can't execute from RAM.
Though I agree with the main point, you can compile code as "PIC" - position independent code, and not bother with (ELF) relocations except for linking.
"COM" programs as seen in MS DOS and earlier CP/M systems contain only relative addresses, and can run from any "segment" of RAM, as the addresses are relative to the value of a segment register. This was used to load "background" services, typically servicing hardware devices.
MCUs with MMUs are starting to appear, such as the ESP32-S31.
There is likely a minority of people who are not significantly affected by a lack of morning light and therefore prefer having light in the afternoon. However, the way we set our clocks must work for society as a whole, and there is an abundance of medical research demonstrating the importance of morning light.
Glad to hear that the tyranny of majority works at a societal norms level. Hopefully at some point that will be the case with democracies as well, instead of serving the privilege of few very wealthy individuals :)
I'd like to imagine a parallel universe where society has decided that given shorter days, as law, working hours must be reduced during the winter period to allow people to wakeup and leave work while the sun is still up. And for those unfortunate ones that work during night shifts the bonuses are significant for their added Vitamin D deficiency and life disruption.
The stated preference of the majority in surveys is permanent daylight time, more sunlight in the evening and less in the morning.
The revealed preference is the opposite. Most people, when given the option for flex time, will start and end work later, increasing their morning sunlight and decreasing their evening sunlight.
Voting works on stated preference, so we'll likely end up with permanent daylight time.
I see that example as the opposite, people just like to sleep in in general, and later sunrise/sunset gives them more light in the times that matter. They don't cancel out, doing both gives the best result.
You have to know ahead of time whether people value their sleep over sunlight, or sunlight over sleep, to know which version makes the most sense.
I've started to despise revealed preference for precisely this scenario. When it's applied accurately it rarely says anything normal reasoning couldn't already make abundantly apparent but it's soooo easy to inaccurately apply and then the conversation goes off the rails to focus on what the revealed preference does/doesn't say.
Then parents who do morning routine or drop off have to come in an hour later, and their partner also wants to wake an hour later so they can stay up with the family an hour later, which means they don’t want to open the coffee shop until an hour later, so now the random commuter wants to start later so their coffee shop is open, and pretty soon it’s just as easy to say “ah screw it, we’re just going to change the clocks twice a year…”
Or, we come up with a system that actually follows the rhythms of nature, rather than forcing a standard schedule year round. Like, I get up later and go to bed earlier in the winter like pretty much every other mammal on the planet, and the 9-5 can shove it. This has nothing to do with clocks changing. Just our patterns changing.
I’d like a single, consistent way to mark time, but that shouldn’t dictate my seasonal schedule and rhythms.
I understand the sun enveloping the earth is inevitable and the fate of our species depends on shedding our earthly bonds but, I think we can conform our daily habits to our present reality without sacrificing a distant future spacefaring civilization.
Rigid timekeeping does not preclude compensation for the sun.
We have given it a try. It’s how most of the world worked until industrialization, and how much of the world still works (like my dad’s village in Bangladesh). It’s a recipe for poverty.
Parents already have to make adjustments to their schedules for when their children are out of school in the summer, right? It's not like society isn't used to parental schedules shifting based on the time of year.
One of my favorite life hacks (which really isn't a hack) is to not change my clock, go to sleep and wake up at the exact same time (solar wise, not wall clock), and just view the shift as a shift in schedules as opposed to time.
It’s a majority of people who aren’t farmers and don't wake up at 6AM to feed the chickens in the dark (chickens would wake up with the sun anyways). They’ve done polls on this and it comes up to cities want permanent summer time, and farming communities don’t.
There is no absolute value of when to do things. People used to get up at 6am or even earlier. Over the past century everything became several hours later, so the opposite of the stated preference of doing everything an hour earlier.
This just seem to be another case of people tell you different things, than they do.
The best part of winter for me is waking up in the dark, going to work in the dark, and driving home in the dark. I don't get affected by SAD and it's much more pleasant to me when it's not sunny.
It should be noted that, as seen at your link, at high forward voltages the characteristic curves of a vacuum diode do not look like those of a semiconductor diode, because the current saturates, which does not happen in semiconductor diodes, which at very high forward currents behave like a small resistance in series with a voltage source with a value typically between a half of volt and two volts, depending on the semiconductor material.
The value at which the current saturates in a vacuum diode depends on the temperature of the filament and of the area of the filament, because at a given temperature the filament emits a fixed current per unit of filament area. If the forward voltage is high enough, all the emitted electrons are attracted by the anode and reach it, so the current saturates at that maximum value.
Thus the forward characteristics of a vacuum diode look more like the characteristics of a depletion-mode JFET, with the different filament voltages corresponding to different gate biases of the JFET.
When a vacuum diode is used as a rectifier, the circuits must be designed such that the forward voltage remains always smaller than the voltage at which the diode current saturates, otherwise it no longer behaves like a rectifier.
The same is true for the amplifier tubes, like triodes or pentodes, which also must be used only in conditions when the anode current is smaller than the saturation current determined by the filament, otherwise they no longer behave as amplifiers controlled by the grid input voltage, because the saturation current depends only on the filament voltage.
Due to this saturation of the current emitted by a hot filament, vacuum tubes are usable only at small currents, typically much less than one ampere, even if handling great voltages, even up to one hundred kilovolt, is not a problem for vacuum tubes.
Before WWII, great currents were handled with gas tubes, not with vacuum tubes, e.g. with thyratrons and mercury-arc rectifiers, where the ionization of the gas by the electrons emitted by the filament can generate enough mobile charge carriers to sustain even huge currents.
In typical audio amplifiers, though, power is increased by amplifying at a moderately high voltage (200 V or so) and transforming it down. That's another way of increasing output current if you have the flexibility.
I remember playing with my father's collection of tape recorders when I was young and one of them had such a "cat's eye". Maybe that's where my love for glowing phosphors started.
My father had one as well, an old Magnecord unit packaged into a wooden case with transport and preamp, with the preamp having one of these tubes. Nevertheless, it was also fitted (perhaps by the dealer) with a proper VU meter. I learned the basics of recording on that, which served me well at a variety of times.
Naturally, his FM tuner from that era also had a horizontal magic eye tube.
At this point the American people have no additional say, except indirectly through congress. Barring an impeachment with a successful conviction (extremely unlikely without a blowout loss for the republicans in November), the man will "serve" the rest of his term whether we like it or not.
Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.
For the curious, this is technically possible in Rust using a dynamically sized type [1], but in practice is difficult and doesn't really play nice with the rest of the language. The nomicon entry concludes with "Yes, custom DSTs are a largely half-baked feature for now." [2]
Unfortunately, Rust is not a good choice for this kind of tricks. This is where Zig shines. In Rust, you can’t even use proper arenas, which can help a ton with allocations.
Cloudflare started to pick Zig recently, for projects, that have memory constraints.
You definitely can and this is done a lot. What you might mean is that you can't use standard library's collections with them (this is getting stabilized soon!) and have to use third-party, but that is a different thing than "can't use arenas".
> Rust is not a good choice for this kind of tricks.
Rust can do those tricks, but it's true that it is hard than in C or Zig. That said there are often crates to help.
You can’t allocate collections without nightly or without reimplementing them in the library. Every implementation uses it’s own set of trade offs to provide safety in unsafe implementation.
Rust supports arenas just fine ( https://crates.io/crates/bumpalo ), and if you mean the support for using custom allocators in the standard library collections, that's as stable as Zig is.
I wish more programming languages implemented record types as seen in databases, where dynamically sized fields are packed into a contiguous area of memory.
The CloudFlare manually implemented a clumsy version of this.
Wouldn’t it be nice for the compiler to manage this for you in the same way that your database engine does when it saves a “row”?
> dynamically sized fields are packed into a contiguous area of memory
Are you able to explain this? Do you mean an N sized array where each entry is either a value or a pointer to a value where the 'pointed-to' values are after the end of the array?
I'm trying to underatnd how you'd do this without having to parse M-1 elements to get the Mth entry if you did a [{size0, value0}, ....., {sizeN, valueN}] arrangement
There are various ways of implementing this, someone from a C programming background mentioned on option where the heap-allocated record objects aren't fixed size structs, but instead the allocated space is dynamically sized and the struct is just a prefix.
Physically the compiler would generate something like:
struct FooRecord {
long __length__;
int fixed_sized_field;
char some_other_field;
char* first;
char* last;
char* title;
}
Where 'first', 'last', and 'title' are sequentially stored after the struct in the heap memory.
There are variants of the above, of course. Instead of pointers the compiler could use lengths, offsets, or a pointer to the end of the variable length field -- this works because the beginning of the first field is at a fixed offset, and then pairs of pointers delimit the rest.
You can rely on the heap allocator to track the "__length__" instead, or you can encode it into the record explicitly to make "dynamic sized copies" simple.
Windows APIs generally work this way! You create a buffer, put a length in the first field, and then the API call writes a fixed-sized prefix followed by the dynamic-sized fields into the buffer. The 'length' is replaced too, so you know how many bytes to copy out without having to understand the structure.
Database engines go one step further and pack multiple "records" into a single "row". They typically store the fields "packed" at the start of the row with 16-bit length or offset markers at the end for the various dynamic sizes.
Something like:
fixed_sized_field // Row #0
some_other_field
first
last
title
fixed_sized_field // Row #1
some_other_field
first
last
title
... empty space ...
next_offset // always populated
row#1_title_offset
row#1_last_offset
row#1_first_offset
row#1_offset
row#0_title_offset
row#0_last_offset
row#0_first_offset
row#0_offset // typically the constant zero
The idea here is that every length is the difference between pairs of sequential offsets. I.e. row#1_title has length (next_offset-row#1_title_offset).
Thanks for such a thorough reply! I initially thought you were describing flexible array members, but this sounds like the ability to have different types/members concatenated
I think they mean the cache entry is a collection of dynamically sized fields. It would be nicer to store that as a single contiguous allocation, rather than a bunch of pointers to individually allocated dynamically sized items. At least in this case, it might.
In a row oriented database, you get a contiguous spot for the whole row even when there are multiple variable width fields.
Depends on how the CacheEntry is stored, it's probably stored in a slice of &[CacheEntry] which precludes storing the record data alongside it as the size of each entry must be fixed.
Even in C, if you want differently sized data to be indexable in O(1), you're stuck leaving them as pointers. You definitely could just have a variable-sized area for this, but that level of optimization is pretty seldomly done in C.
reply