Constant Speed is probably what I was thinking of. And speaking of multi engine failure, you’ve just reminded me of the demise of TransAsia Airways Flight 235 where the right engine feathered itself erroneously, but then the crew misdiagnosed the situation and shut down the left engine. Mentour Pilot made a video on that particular accident.
I like this answer. The only thing I would add is that when the fan blades are all stalled, it might seem then that drag and energy consumption should reduce, since there’s not much air moving. But in a cruel twist (fan pun intended) of aerodynamics, the useless spinning of stalled fan blades still causes parasitic drag. So not only does the fan not move air, it’s also consuming more energy than spinning a solid disk of the same moment-of-inertia.
When the engine fails for certain single-propeller aircraft, there’s sometimes a mechanism to lock the propeller to make it stop rotating, since it would otherwise “windmill” in the air and waste the precious kinetic energy that’s keeping the plane aloft. Or so I’m told.
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.
I guess your nephew can start studying to become a network engineer now lol
In all seriousness, a 16 port managed switch exposes enough complexity to develop a detailed understanding of Ethernet and Layer 2 concepts, while not having to commit to learning illogical CLI commands to achieve basic functionality. 16 ports is also enough to wire up a non-trivial network, with ports to spare for exercising loop detection/protection or STP, but doesn’t consume a lot of electricity.
I would pair that switch with a copy of The All-New Switch Book, 2nd Edition to go over the networking theory. Yes, that book is a bit dated but networking fundamentals have not changed that much in 15 years. Plus, it can be found cheap, or on the high seas. It’s certainly not something to read cover-to-cover, since you can skip anything about ATM networks.
Then again, I think students might just simulate switch behaviors and topologies in something like GNS3, so no hardware needed at all.
The other comments correctly mention aspects like managing terrain and the width of railroads vs roadways. What I want to highlight is the development of road building methods at around the same time that metal-on-metal rail developed.
The 1800s were a wild time. Some clever folks figured out that they could put a contemporary steam engine – invented early 1700s; used only for stationary uses in lieu of water power – onto a wagonway. Wagonways are basically wooden or metal guides/flanges so that a horse-drawn wagon could be pulled along and stay perfectly centered on the path.
Up until this point in history, the construction of graded, flattened surfaces for moving goods didn’t change very much compared to what the Romans were doing with their roads. That is, a road had to be dug down and some soil removed, then backfilled with coarse material (usually large stones), and then a layer of smaller stones to try to approximate a smooth surface. The innovations the Roman introduced included a keen eye for drainage – freeze/thaw cycles destroy roads – and surveying methods (also to build things like aqueducts and canals). And concrete, of course.
But even the best built roads of that era were still prone to rutting, where each passing wagon slowly wears a groove into the road. Wooden wagons wider or narrower than the groove would suffer poor performance or outright break down. The wagonways sought to solve that issue by: 1) forcing all wagons to fit within the fixed guides on the sides, and 2) concentrate the grooves to exactly within the guides. The modern steel-on-steel railway takes this idea to its logical end.
An adhesive railroad seeks to be: all-weather, heavy duty, and efficient. Like Roman roads before it, all railways (except maybe on-street tramways) need to excavate the soil and build it up, usually being higher and wider than the rest of the land. It also minimizes the width of the earthworks, by being so compact and building upward. This sturdy base also provides a strong foundation to support heavy loads, preventing the steel rails from sinking or “rutting”. And finally, putting the wheel atop the rail makes for low-friction operation. Early wooden plateways sort-of did this, but they didn’t manage curves like how modern rails do.
All the while, instead of trying to support heavy wagons, another clever person sought to reinvent road building outright, postulating that if a surface could just spread out the load from light/medium traffic, then the soil beneath could be used as-is, saving a lot of earthworks. A gravel surface would meet this criteria, but gravel is not all-weather and can develop rutting. The key innovation was the use of binder (basically glue) to hold the surface together, such as tar. This sealing process meant the surface wouldn’t shift underneath traffic. This neatly avoided the issue of dust, made the surface water impermeable, and reduced road maintenance. So famous is this surfacing process that the inventor’s name can still be found in the surface for airport runways, despite runways always being excavated down to a significant depth.
So on one hand, rail technology developed to avoid all the pitfalls of 1700s roads. On the other hand, road surfacing developed to allow light/medium traffic roads to be economically paved for all-weather conditions. Both developments led to increased speed and efficiency in their domain, and networks of both would be built out.
Rail networks made it possible to develop the “streetcar suburbs” around major historical cities in the late 1800s. But on the same token, cheap road surfacing made it possible to build 1950s American suburbs, with wide, pedestrian-hostile streets sprawling in serpentine patterns. The fact that sealed roads are water impermeable has also substantially contributed to water pollution, due to increased rain runoff rather than absorbing into the underlying soil.
You’re going to have to clarify what jurisdiction, since USA law is going to be vastly different than EU law, in the realms of product, medical devices, and public accommodations liability.
But if we did examine the USA, then we can find some generalized rules. For product liability – the responsibility of manufacturers and distributors of a tangible object – strict liability will lay when a product has an inherent defect (meaning it didn’t become defective after the initial sale) and this defect causes some sort of injury. Although this criteria doesn’t depend on the frequency of injuries, if a product is accumulating a body count, that’s usually a good sign that there’s a defect. Causality is also important to establish, as well as any mitigations that may have existed. On this front, a manufacturer might argue that the warnings in the instruction manual specifically advised against diving headlong into a 30 cm deep swimming pool. And although warning consumers to not do something may be somewhat effective at discharging liability, warnings alone do not prevent someone from trying a lawsuit anyway; the popular wisdom that the “pages of warnings” in manuals are written by lawyers is only partly true, since most manufacturer prefer repeat business by customers that are still alive.
Medical product liability is similar, but slightly different because medical products are built for a specific purpose but a doctor can instruct a patient to use it differently, if medically appropriate. If not used as instructed by the manufacturer, the manufacturer is usually off the hook, but the doctor might be liable for medical malpractice. Maybe. Doctor liability in the USA is framed within a “duty of care”, meaning that the doctor takes on a responsibility to act with a reasonable degree of skill and competency. The “standard of care” idea is related, in that it sets the floor for what is reasonable for all doctors. It is, for example, grossly negligent to a drunk doctor to examine a patient. Harms from such negligence can be litigated through a malpractice suit. But this doesn’t mean all harm is actionable. A successful appendectomy that results in blood sepsis is always going to be a possibility, even with the best infection controls in place. If all the staff discharged their duties within their training, then negligence does not attach. Also, malpractice is not something which can be waived, because even if a patient doesn’t sue, a doctor’s medical license can be suspended. Whereas the risks of a surgery can be described in detail to a patient, for informed consent.
Finally, public accommodations law sets the floor for how public and private businesses conduct themselves if they provide goods or services to the general public. Very prominently in this realm are accessibility requirements, which are rules that assure the disabled will not have undue burdens that able-bodied people wouldn’t face. The Americans with Disabilities Act (ADA) provides for very stiff fines for non-compliance, and because its objective was to set the standard, there is no provision for a “fix it ticket” approach for enforcement. That is to say, the ADA does not allow business owners to wait until a wheelchair user makes a complaint; they must follow the standard from day 1.
No doubt there is abuse of the liability laws – there’s nothing more American than filing “ambitious” lawsuits – and this is just a brief (and uncited, '“from the hip”) summary of possible areas of law that might answer your question. But I hope it gives you an idea of why a warning or sticker or sign might incur liability. Or at the very least, an unexpected lawsuit from left-field.
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.