The interest is BECAUSE it's well explored territory. The concept is proven and works fine.
On the low end where RISC-V currently lives, simplicity is a virtue.
On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.
> Do you think Apple spends more money than Intel on chip design?
Absolutely. Apple's R&D budget for 2025 was 34 Billion to Intel's ~18 Billion (and the majority of Intel's R&D budget goes to architecture, while for Apple, that is all TSMC R&D and Apple pays TSMC another ~$20 billion a year, of which, something like 8 billion is probably TSMC R&D that goes into apple's chips).
Sure not all of Apple's 34B is CPU R&D, but on a like-for-like basis, Apple probably has at least 50% more chip design budget (and they only make ~10-20 different chips a year compared to Intel who make ~100-200)
As a kid I took a lot of classes at the Lawrence Hall of Science in Berkeley, which was paradise for fledgling nerds. On the last day they would have a little closing ceremony with some cute little science experiment. One of my favorites was "Going Out With A Bang".
The instructors would bring out a helium balloon and a candle on a meter stick. The balloon goes pop, huzzah.
Then the twist. "Hey, wanna do it again?" All the kids would be like "meh, I guess?" They would then bring out a balloon full of hydrogen (maybe some oxygen too?). It would look identical to the first one, floating there tethered to the lab bench.
When the candle hit the second one, it made a white flash and a really sharp BANG. It was an order of magnitude louder, and you could hear the transient bouncing off the walls and echoing in the halls. It made an impression.
If you have a herd of systems - prod environments, VMs for CI, lots of dev workstations, and especially if your product is an appliance VM: you might want to run your own apt mirror, creating known-good snapshots of your packages. I use https://www.aptly.info/
There's a technical reason for it: the voltage sags when the battery is discharged quickly. Ah is relatively constant, but Wh decreases significantly with faster discharge rates, so it can't specified as a single figure.
That's a bit cursed mental model tbf... The voltages of batteries, in the first place, is function of state of charge. 100% = 4.2V, 0% = ~2.7V, 50% is 3.7V(by volume or something. 2.7 is also technical absolute minimums, cutoff voltage is usually more like 3.2V. Please don't abuse the battery in the ranges between 3.2 to 2.7V, let alone below).
Charge/discharge current capacity is constant throughout, at least so battery manufacturers say, at 1-20x the amp-hour capacity depending on the cell. Usually 5x or less.
Since energy = voltage x current, instantaneous W capacity is higher at first, reducing as it becomes supply side limited rather than load side limited.
But all those is irrelevant to why everyone uses mAh, it's because products with biggest numbers sell fastest. Marking capacity in Wh is noble, but it's a clearance worthy sin if you ask the shelves.
MCAS autonomously adjusts trim downward. The trim switches override MCAS, but when released, MCAS can resume trimming down again. The trim adjustments don't "override" the pilot's elevator inputs (MCAS has no direct control over the elevators), but they can make the controls so heavy that it's impossible to pull up.
If MCAS is running the trim, the thumb switches override it.
MCAS affects the stabilizer, the thumb switches affect the stabilizer, the cutoff switch affects the stabilizer.
The elevators are controlled by the control column and the autopilot.
> The trim switches override MCAS, but when released, MCAS can resume trimming down again.
That is correct. That is why the procedure is to return the trim to normal with the thumb switches, then turn off the trim system. That's it. That's all there is to it.
> but they can make the controls so heavy that it's impossible to pull up.
Almost right - the trim has more authority than the elevators. The trim's ability to travel far is to provide great ability to get out of trouble. I don't really know what factors the aerodynamics guys used to calculate the max travel required. I do know there is a travel limiter on it (as I worked on that, too!) which reduces the max travel at higher speeds, because otherwise it can rip the tail section off, which is a big no-no.
There are sooo many constraints on the design of an airplane I sometimes wonder how anyone manages to make one that works at all. The Wright Bros calculated that their machine would fly, and it did, barely. Their contemporaries did seat of the pants design, which is why they failed.
Thank you. I've had commercial pilots email me telling me I was correct and to keep on the good fight :-)
The Wrights did a lot more than that to be successful. Their innovations were:
1. using a wind tunnel to correctly get lift and drag coefficients for various wing sections (as you wrote)
2. first aviation engine (high power/weight ratio) (as you wrote)
3. first propeller theory, enabling 90% efficiency (other aviation propellers were 50% efficient)
4. first 3-axis control system
5. identified and solved adverse yaw problem
6. first research and development program, where problems were identified in advance, and a machine was developed to solve each problem, then the solutions were put together to make the 1903 Wright Flyer
7. kept meticulous notes on all their work and preserved the evidence of their success, such as photographs and notebooks. Exacting replicas have been built, and their flight characteristics match the Wright's results
The BIOS was an abstraction layer. In the old days, not everything was 100% IBM PC compatible. There were lots of weird graphics cards. Some systems had incompatible disk and keyboard controllers.
There was no memory protection in Real Mode, so you could always poke the hardware yourself, but something written on a Tandy wasn't going to work on a Zenith unless you supported both, or ran everything through the BIOS.
Over time, the OS took over the HAL role, with the BIOS only being used until the OS could load native drivers. Now it's UEFI... same idea with a higher greater level of abstraction and modularity.
For a simple example, let's say you are simply driving in a circle. The car wants to lean toward the outside. The linear motors can provide a countering force, lifting the outside, lowering the inside, so the car stays level. Variable damping can only control the rate that it rolls. It will still roll in sub-second timescales, unless it completely locks down the suspension, which is terrible for both handling and comfort.
For another simple example: going over a speed bump. Linear motors can lift the front wheels over the bump, and then the rear wheels, so the body stays level the whole time. An active damper can go full-soft the moment the wheel hits the bump, but the compressed spring will still start lifting the front of the car. An active damper can do a better job managing the rebound on the far side so it doesn't oscillate, but it can't entirely prevent the bump from pitching the body up and down in the first place.
That's not to say it's worthless. Very fast active dampers can improve both handling and comfort. It's just nowhere near the level which is possible with linear motors.
This is my biggest fear of technologies like these.
The whole point of a speed bump, for example, is to ensure that behaviour that puts others at risk will, at the very least make the driver uncomfortable. If we then deploy technologies that make speed bumps “disappear” from the perspective of vehicle occupants, it’s going to enable people to comfortably drive a lot more aggressively at the expense the people on the other side of the windshield.
Conversely, if we were to deploy technologies like speed governors, then we could do away with the speed bumps and the need for fancy suspension.
My 2004 Land Cruiser has such technology. It's called "being a Land Cruiser". As a sports car fan, I'm quite familiar with how hard it is to make speed bumps that work for every vehicle. You're not wrong, but also it's a pretty crude technology, speed bumps.
The problem with speed bumps is that the level of annoyance is drastically higher for the already-slow prudent driver in a reasonable vehicle, compared to the lackadaisical latently-fast driver in an oversized monster SUV. So most of the intended targets get punished with "wow that was bouncy lol!" while the collateral damage gets comically slow crawling and/or frame damage. Speed bumps also draw the attention of drivers towards focusing on the obstacle, and away from staying alert for pedestrians.
I just had an experience with a parking lot (at a place generally full of kids), that had added a horrible speed bump at the entrance and then removed it a few months later. As far as I know there was no problem with people speeding in the lot, it was likely just some busybody trying to make things "better". Thankfully someone more in charge saw the light of reason.
On the low end where RISC-V currently lives, simplicity is a virtue.
On the high end, RISC isn't inherently bad; it just couldn't keep up on with the massive R&D investment on the x86 side. It can go fast if you sink some money into it like Apple, Qualcomm, etc have done with ARM.
reply