I read this, and thought it was kind of all over the place. Even the first “falsehood” about always immediately crashing is answered as “true for some languages but not some others”. Even the motion of superlatives in CS like “always” and “never” rarely hold, including this very sentence and almost certainly when talking about multiple programming languages.

And on that point, it’s a minor quibble, but while Go’s nil pointers are similar to C null pointers and Rust’s null raw pointers, it’s a strange thing to have the title be about falsehoods about null pointers.

But then much of the other supposed falsehoods are addressed only for the C language, such as null deference being UB or not.

9. On platforms where the null pointer has address 0, C objects may not be placed at address 0.

I would like to see a ©itation [pun intended] for this being a supposed falsehood, since my understanding is that if an implementation uses 0x0 as the null pointer, then the check for a null pointer is to check if it’s equal to 0x0, which would require that no “thing” in C use that address.

Does your freehub body also have the steel strip? I’m hoping that it’s as effective as claimed, but idk

I’m partial to a desire path being “the path of least resistance”. And in that sense, it’s still a desire path because it still carves a path that gets more defined as more people use it, whether or not it’s fully developed. The second person didn’t have to choose the same path as the first, but they did. And so did the next. And so on.

I grant you, it’s kinda like the philosophical question of: how many grains make a mountain.

A recommendation from the “Boglehead” community within personal finance circles is this book, which is a good primer for getting started with investing. https://www.bogleheads.org/blog/portfolio/the-bogleheads-guide-to-investing/

It includes a discussion highly germane to Americans, but it may also be broadly applicable in aspects such as managing risk and timescales, especially the difference between younger investors with the capacity and time horizon to save, versus late-starters with less time available for compound interest to work its magic.

This is the book I lend to friends, and would recommend.

I think the other commenter comparing this to the Quebec/French system of land division has it right. From satellite view, you can see the distinct shape of narrow strip lots perpendicular to the flow of the Bayou Lafourche. In the distant past, waterway access then was the equivalent of truck access from the Interstate freeways today: paramount for getting goods to market.

What I like about this design is that if wind was an issue, it would be the simplest thing to fill the base with sand to anchor it down, without it being permanent, and without impacting its basic functionality. Brilliant and versatile!

A few months ago, we had a question about what would happen if necromancy was possible and an undead was called as a court witness. I gave a rather fun-to-write, tongue-in-cheek answer, which might be germane to your question too. Here’s just a snippet:

So now we come back to zombies. Would a jury be able to set aside their shock, horror, and awe about a zombie in court that they could focus on being the finder of fact? If a zombie says they’re an eye-witness to a mugging, would their lack of actual eyeballs confuse the jury? Even more confusing would be a zombie that is testifying as an expert witness. Does their subject matter need to be recent? What if the case needs an expert on 17th Century Parisian fashion and the undead is from that era and worked in haute couture? Are there no fashion historians who could provide similar expert opinions?

Do most people really only ride on the throttle?

I can only offer a morsel of anecdata from around my area, but a rudimentary sample of the ebiking public while waiting at red lights in the last few weeks would suggest that yes, a good number of people riding bikes have the throttle pinned and are going at a good clip, which I would estimate to be 20 MPH (32 kph), the existing Class 2 limit.

Granted, I’m only really ever at red lights long enough to survey anything when I’m in the suburbs. And I suspect the thinking here is that 20 MPH is plenty fine if the alternative is walking or riding slower on sidewalk. At least around here, most probably know someone who’s eaten pavement on an e-scooter at 15 MPH, so 20 MPH is likely a reasonable pace for a lot of people.

How about a non-stupid firmware update that locks to 20 if a throttle is connected, and unlocks to 28 if there isn’t one?

Such a design could work, but probably can’t be done with a firmware update for existing bikes. A lot of throttles are just – and I’m simplifying for generality – a potentiometer feeding an analog signal to the motor controller. The latter might not be able to detect the absence of a throttle, but merely that if a throttle is present, it is not engaged. That’s not sufficient to meet the clarified laws for 2025, so perhaps the industry will rise to produce throttle-presence detecting ebikes going forward.

Personally, I removed the throttle from my rather-old Class 3 ebike long ago, because I just didn’t use it. When I’m going at the full 28 MPH (45 kph), I’ve got a better feel for the road conditions when I’m actively pedaling, and with the torque sensor backing me up. But I bike as my primary mode of transportation, despite other options available, so it’s also just more fun this way.

Can’t Python be translated into machine code

Yes, and that’s basically what the CPython interpreter does when you call a Python script. It sometimes even leaves the result laying in your filesystem, with the extension .pyc . This is the byte code (aka machine code) for CPython’s implementation of the Python Virtual Machine (PVM).

and packaged into a binary?

Almost. The .pyc file is meant to run with the appropriate PVM, not for x86 or ARM64, for example. But if you did copy that .pyc to another computer that has a CPython PVM, then you can run that byte code and the Python code should work.

To create an actual x86 or ARM64 binary, you might use a Python compiler like cython, which compiles to x86 or ARM64 by first translating to C, and then compiling that. The result is a very inefficient and slow binary, but it is functional. You probably shouldn’t do this though.

While I get your point that Python is often not the most appropriate language to write certain parts of an OS, I have to object to the supposed necessity of C. In particular, the bolded claim that an OS not written in C is still going to have C involved.

Such an OS could instead have written its non-native parts using assembly. And while C was intentionally designed to be similar to assembly, it is not synonymous with assembly. OS authors can and do write assembly when even the C language cannot do what they need, and I gave an example of this in my comment.

The primacy of C is not universal, and has a strong dependency on the CPU architecture. Indeed, there’s a history of building machines which are intended for a specific high-level language, with Lisp Machines being one of the most complex – since Lisp still has to be compiled down to some sort of hardware instructions. A modern example would be Java, which defines the programming language as well as the ISA and byte code: embedded Java processors were built, and thus there would have been zero need for C apart from legacy convenience.

As it happens, this is strikingly similar to an interview question I sometimes ask: what parts of a multitasking OS cannot be written wholly in C. As one might expect, the question is intentionally open-ended so as to query a candidate’s understanding of the capabilities and limitations of the C language. Your question asks about Python, but I posit that some OS requirement which a low-level language like C cannot accomplish would be equally intractable for Python.

Cutting straight to the chase, C is insufficient for initializing the stack pointer. Sure, C itself might not technically require a working stack, but a multitasking operating system written in C must have a stack by the time it starts running user code. So most will do that initialization much earlier, so that the OS’s startup functions can utilize the stack.

Thjs is normay done by the bootloader code, which is typically written in assembly and runs when the CPU is taken out of reset, and then will jump into the OS’s C code. The C functions will allocate local variables on the stack, and everything will work just fine, even rewriting the stack pointer using intrinsics to cause a context switch (although this code is often – but not always – written in assembly too).

The crux of the issue is that the initial value of the stack pointer cannot be set using C code. Some hardware like the Cortex M0 family will initialize the stack pointer register by copying the value from 0x00 in program memory, but that doesn’t change the fact that C cannot set the stack pointer on its own, because invoking a C function may require a working stack in the first place.

In Python, I think it would be much the same: how could Python itself initialize the stack pointer necessary to start running Python code? You would need a hardware mechanism like with the Cortex M0 to overcome this same problem.

The reason the Cortex M0 added that feature is precisely to enable developers to never be forced to write assembly for that architecture. They can if they want to, but the architecture was designed to be developed with C exclusively, including interrupt handlers.

If you have hardware that natively executes Python bytecode, then your OS could work. But for x86 platforms or most other targets, I don’t think an all-Python, no-assembly OS is possible.

It took me a few brain cycles to recognize that this was a spoon. Perhaps others were similarly momentarily confused.

As it happens, I’ve been meaning to get a front fender, as ebike speeds are sufficient for the front tire to fling water up and directly into my face. I’ve never actually owned a bike with a front fender so this is useful info for me. Thanks!

I also want to note that in the year 2025, GitHub still does not support IPv6. Folks behind CGNAT in IPv4-starved geos suffer, as does everyone developing for all-IPv6 networks. And it’s not like they can’t do it, seeing as their various subdomains like pages.github.com have working IPv6 already.

Wait, the fender failed and that led to a crash? Did I miss a post in this community?

My assumption with this PCB is that it switches the GND, meaning 12v is always provided to the LEDs. So the trick is to find somewhere that has a permanent GND and then connect all the LED leads to that. But I don’t see a large enough spot to land three new leads, except maybe where R6 is.

You’ll have to verify if my assumption is accurate, although I do wonder if you could just get a different PSU outright. This sounds like a 12v LED strip, so any sufficiently sized 12v wall-wart would also suffice.

Can you also clarify: you want this strip to be always-on and all-white, but the strip uses RGB LEDs? While it does produce white, it might not have a very high CRI and thus may be unpleasant for certain lighting applications. There are dedicated white LED strips which will perform a bit better for color rendition, and that could potentially be an issue if food needs to look appetizing under these cabinets.

Very nice! Might I suggest a thermocouple rather than a thermometer? A thermocouple would be very compact and for the sort that hooks up to a multimeter, it can be taped into place underneath layers of insulation, so you wouldn’t have to remove or reattach it every time you want to take a measurement between rides.

Can you describe which ebike or what battery pack you’re testing with? I want to get a better idea of what you mean by the top/bottom sides of the pack. A link or photo would be excellent.

just be careful not to let it overheat too

My other comment explores how much insulation might be needed to make a battery pack too warm. And it’s a difficult pickle, since insulating a pack well tends to imply that the insulation won’t be removed later. And yet, the narrow temperature range of li-ion means either the insulation must be shed to keep the pack happy or – bizarrely – some active cooling is needed to keep an insulated pack from getting too warm.

It’s an interesting question and not one I had even considered. Prior knowledge suggests that it’s at least somewhat plausible to thermally manage an ebike battery, seeing as electric automobiles do something similar in freezing weather. However, the large packs of automobiles are unfavorable when it comes to passive heat loss, being made of a lot of metal (which has a higher thermal capacity than air) and having lots of surface area compared to volume. So the heat generated during cell discharge is being wicked away by a larger area. So an ebike battery should stand a better chance, I would think.

So I started crunching some numbers. From a different comment, you suggested a use-case of 3+ hrs in -15 C weather. For the purpose of this exercise, I considered this battery pack, because it seemed fairly representative of a common ebike battery. This is the type of pack which slides into an open slot, exposed on basically all sides to weather. I thought about considering frame-integral packs, but there’s the issue of modeling them generally, and more importantly, I think the frame would become a substantial heat sink in -15 C conditions, since there’s no way to add insulation between a frame-integrated pack and the frame itself. My working assumption is that this specimen battery pack can be wrapped in insulation on all sides, for the most optimistic results. Also, I assume the battery pack is room temperature prior to starting the sub-freezing journey.

This pack is configured as 13s5p, so we know there are 65 cells inside. I think it’s reasonable to assume they are the common 18650 cells. I found this paper regarding a model for heat generation for one particular 18650 cell during discharge, which neatly included the data they collected. As we would expect, the heat output of a single cell depends on the discharge rate, and they recorded data at 0.5C, 1C, and 1.5C (Table 6).

Since the use-case will test the endurance of an ebike battery pack to complete discharge over at least 3 hours, I will use the lowest discharge rate, since a 0.5C rate means every cell would be depleted in 2 hours. Once again, this will give us optimistic results for a 3 hr use-case.

The plot from Table 6 at 0.5C remains substantially at 25000 W/m^3 for the first 80% of time, and then quadruples by the end of the discharge. Since we are assessing the steady-state heat of the battery, we will not consider the increased tail-end heating. A single 18650 cell has a volume of 16 mL, so the entire pack has 1040 mL (0.00104 m^3) worth of heat-generating battery. Using the figure from the literature, this pack has an overall discharge heat of 26 W.

If a single hand warmer produced 26 W continuous, that would make for a very toasty hand. But we need to consider the heat loss for the battery pack’s casing, to see whether a substantial fraction remains to keep the cells warm. To do that, we can observe that this specimen pack is mostly rectilinear, so we can approximate it as a simple 6-sided shape, with dimensions 390x110x75 mm. Crunching the numbers, we arrive at a total exposed surface area of 0.1604 m^2.

For this exercise, we would have to know how much heat the casing can exchange with the environment. But since we’re trying to find an optimistic value, we can instead consider an impractically well-insulated scenario where the cells are enclosed in a thick casing of polystyrene on all sides. Specifically, I am using a value of 25 mm thickness of polystyrene, thus RSI 0.97, aka R-value 5.6. The RSI value has the units m^2*K/W. We can arrange an equation to yield K (the temperature difference in deg C) as follows:

K = (RSI * Watts)/area-in-sq-m

We have all the numbers, so we just plug them in, yielding a temperature difference of +157 C. So at -15 C ambient temperature, this pack would be at 142 C, or basically on fire. 🔥

Ok, that’s obviously way too much insulation, and while shocking, I shouldn’t be too surprised, since even 1 W continuous is enough for a wall-wart to be warm to the touch. Inside a sealed polystyrene compartment, I would also expect a wall wart to rise to a rather high steady state temperature.

What we’ve learned is that it’s actually decently plausible, although every figure here is optimistic. The cell heat output is going to be lower at lower discharge below 0.5C, possibly being half or 1/3 as much. That could sink the heat output to only 9 W. And real world insulation would likely be something like 6 mm of neoprene, so R-value of 1 (RSI 0.17). These more pessimistic numbers bring the temperature difference down to just +10 C delta, so in -15 C ambient, the pack would still be below freezing.

But I think what’s instructive here is that the cell heat can indeed be sufficient, and the insulation can be suitably thick. Other issues will be whether the insulation also absorbs heat from the sun during riding, and what should happen if the pack overheats under all that insulation whilst in slightly warmer weather.

Currently, I’m having good luck with my KMC e9 EPT chain; I’ve not totally understood how KMC’s lineup works, so I’m not sure whether x9e or e9 are substantially similar or not.