It's like those articles that say super high IQ people are not always successful.
So I think human brain development is like some kind of optimization algorithm, like simulated annealing or gradient descent. I think this because there is way more complexity in the brain than there is in human DNA, which has pretty low information by comparison. Anyway, child prodigies occur when the algorithm happens to find a good minimum early on.
The receiver is like the asset tag on computer servers- it's the one thing that is definitely not replaceable since it has the serial number used for entitlement.
That's true, and without any legislation or such prohibiting lead they would most likely have continued to use it as anyone who would have phased out lead would have been at a competitive disadvantage. But once it was banned, everybody was again on an even playing field, and as OP explained fuel is a commodity so the higher cost just flowed through to the end user prices, refinery margins stayed about where they were.
In an industry where everyone sells a completely fungible product such cost savings generally are passed on to consumers. Oil companies can profit in the short term due to fluctuations in the price of oil and things like that, but not from something like lead additives, which everyone had been using for decades.
If the end product ends up marginally cheaper, the company will be able to sell more of it, and this will lead to more profit. And sure, when you ignore the cost of the pollution, this certainly benefits the consumer, by allowing them to afford more energy and energy-based products (i.e., just about everything).
But then we come back to ignoring the cost of the pollution. It certainly gets paid for eventually, but by who? Also, it's cheaper for everyone if the pollution is eliminated to begin with rather than being cleaned up later (which is certainly a more energy intensive endeavor).
I think you're missing the point -- the point is that gasoline companies KNEW ABOUT alternative lead-free substitutes for anti-knock (such as ethanol) and chose lead because they perceived it was less profitable. [1] Specifically because ethanol wasn't patentable and TEL was, and ultimately it WAS patented.
It is more than that - lead and ethanol have other properties that engines that use them need to handle. Lead also acted as a lubricant and parts designed for engines that assumed lead fuel were designed with softer valve seats - switch to unleaded with otherwise equal octane and your will destroy the engine. (though experience shows that unless you were driving your car on a race trace most cars worked fine for longer than the car lasted). Ethanol will destroy some forms of rubber and so you need to use different seals in some parts.
TEL was patentable, but those patents were long expired before there was a big push to eliminate leaded gas.
Also, TEL being patented by Dow (which isn’t an oil company) actually was a reason oil companies would want to use an alternative, if possible. Why would they want to pay Dow to use a patented product, all else being equal?
Ethanol has a propensity to suck up ambient moisture and is more demanding of rubbers and happily attacks aluminum.
In an age of natural rubber components, poorly sealed fuel systems with steel tanks and aluminum carburetors pretty much anything other than ethanol is the "right choice".
And once they ruled out ethanol they settled on lead because it was cheap/profitable. Obviously they chose wrong, they should've picked something more expensive but less terrible.
These weren't cartoon villains with monocles twirling their mustaches. They were normal humans making pragmatic decisions based on the constraints they faced. Without knowing the details people cannot understand what future similar fact patterns may look like.
That said, it should be no surprise to anyone that nobody wants to talk about "well we don't know how bad the harm of leaded exhaust is, we know it's not good, but it's diffuse and undefined so we'll round it to zero/negligible" type decision making, for that sort of unknown rounds to zero logic underpins in whole or part all manner of modern policy discourse.
>Ethanol has a propensity to suck up ambient moisture and is more demanding of rubbers and happily attacks aluminum.
Actually, moisture problems are from using things like homemade alcohol or alcohol from unknown sources, where the likelihood of it already containing a sizable percentage of water has been a problem since the Model T days.
And if that water has a bit of an aggressive pH, it can have an effect on aluminum components.
This is just not a problem with gasoline-alcohol blends from reputable suppliers unless there is serious failure in the supply chain after that, where any fuel would have been contaminated by water regardless. The fuel-grade alcohol is tested before it is added, then the finished gasoline fully analyzed afterward.
Neither moisture nor corrosion is a problem with fuel ethanol or methanol, and when you see convincing information to the contrary (like from a pro mechanic) it often originates from misguided sources, "old wives' tales" for which actual evidence existed without being well-understood. But sometimes the most professional are the ones who don't take any chances, whether "common knowledge" is factual or not, if it doesn't hurt, no big deal.
Miscellaneous polymer compounds were the real question for cars that were not originally made for modern alcohol mixtures.
Ethanol just doesn't absorb moisture into your fuel tank by itself, even from a very humid environment.
Not any more than plain hydrocarbon fuel. In old ventilated fuel tanks, extreme temperature cycling under very humid conditions draws moist air into the tank when the fuel shrinks or is consumed. Kilos of cold fuel and cold metal can continue to condense moisture from the air, when the dew point is greater than the temperature of the tank. After a while you can get grams or ounces of water rolling around in the bottom of the tank. This could build up and stall out the vehicle or keep it from starting.
If it was only an ounce or two of water at the bottom of the tank full of all hydrocarbons, it would actually help to add a gallon of plain (good) alcohol to help dissolve the separated water into the gasoline so it can pass through harmlessly like it always has since gasoline has always had trace amounts of water anyway. Condensation is about as clean as rainwater so it's nothing the engine hasn't seen.
When most mechanics see something like this it has already gotten way out of hand, and there have been waves of anti-alcohol propaganda disseminated through time which reinforce the superstitious component.
Another problem from the '80's was when you do first start using alcohol-containing gasoline in an older car, it can break up varnish that has built up in the tank for years which never would come off until some alcohol came along. This could be a few grams, end up clogging the fuel filter, and the car stalls out no different than from water in the fuel line. Direct cause-and-effect relationship undeniably due to the use of alcohol, with many independent observations. Not a water problem, but who's keeping score.
Just not any more of a problem in the 21st century, similar conditions are so rarely encountered now.
Alcohols have a strong tendency to pull water out of the atmosphere if the percentage of water in the alcohol is below whatever that particular alcohol favors. The only way to keep it dry is to seal it up.
They picked lead because it was the cheapest additive, not because it was more profitable for the industry as a whole. Those two things aren’t the same. In the oil industry, the products are identical and companies compete only on price. If you use the $0.10 per gallon additive when everyone else is using the $0.05 per gallon additive, then your sales collapse because customers just cross the street to save $0.05 per gallon. But if every company switches to the $0.05 gallon additive, that doesn’t mean the companies pocket the extra $0.05 per gallon. Most of that goes to the consumer, because, again, consumers can just cross the street to get the better price.
It’s really a collective action problem. Nobody wants their gasoline to be more expensive than other companies’. So everyone has the incentive to use the cheapest ingredient. If you ban that ingredient, prices go up. But since everyone's prices will go up, you remove the competitive disadvantage.
I think you're missing the point. Without a market-coordinating motivation (i.e., legislation), any company that adopted a more expensive anti-knock would be competed out of the market.
Schubfach, Ryū, Dragonbox etc support round-tripping and shortest-width, which (it sounds like) is not important for you. The idea of round-tripping is that if you convert a double to a string and then parse that, you get the exact same value. Shortest-width is to correctly round and generate the shortest possible text. I tried to implement a version that does _just_ round-tripping but is not shortest-width, it is around 290 lines for both parsing and toString [1]
They're different problem spaces, TrustZone is a trusted execution environment and TPM is an API for performing key storage and attestation which revolves around system state (PCRs).
Essentially, TPM is a standardized API for implementing a few primitives over the state of PCRs. Fundamentally, TPM is just the ability to say "encrypt and store this blob in a way that it can only be recovered if all of these values were sent in the right order," or "sign this challenge with an attestation that can only be provided if these values match." You can use a TEE to implement a TPM and on most modern x86 systems (fTPM) this is how it is done anyway.
You don't really need an fTPM either in some sense; one could use TEE primitives to write a trusted application that should perform similar tasks, however, TPM provides the API by which most early-boot systems (UEFI) provide their measurements, so it's the easiest way to do system attestation on commodity hardware.
Sure, why not? You have a reference implementation for both TrustZone OP-TEE (from Microsoft!) and in-Linux-kernel. No need to code anything, everything is already there, tested and ready to work.
As I understand it, you can not actually deploy a fTPM (in embedded and other scenarios) unless you run your own full PKI and have your CA signed off by Microsoft or some other TPM consortium member. So sure the code exists, but it's also just a dummy implementation, and for any embedded product that is not super cost conscious I will forever recommend to just buy the $1 chip, connect it via SPI and live happily ever after. Check the box, in embedded most non-technical people can't even begin to understand what FDE means anyway.
If you don't need the TPM checkbox, most vendors have simple signing fuses that are a lot easier than going fTPM.
Well, you have much more control of lower-level boot process on ARM chips, and each of the SoC manufacturers have their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process.
In context of trusted boot — not much. If your specific application doesn't require TPM 2.0 advanced features, like separate NVRAM and different locality levels, then it's not worth to use dedicated chip.
However if you want something like PIN brute force protection with a cooldown on a separate chip, dTPM will do that. This is more or less exactly why Apple, Google and other major players have separate chip for most sensitive stuff—to prevent security bypasses when the attacker gained code execution (or some kind of reset) on the application processor.
> their own implementation of Trusted Boot which relies on the cryptography and secrets inside the SoC rather than TPM as in x86/UEFI boot process.
TPM and x86 trusted boot / root of trust are completely separate things, linked _only_ by the provision of measurements from the (_presumed_!) good firmware to the TPM.
x86 trusted boot relies on the same SoC manufacturer type stuff as in ARM land, starting with a fused public key hash; on AMD it's driven by the PSP (which is ARM!) and on Intel it's a mix of TXE and the ME.
This is a common mistake and very important to point out because using TPM alone on x86 doesn't prove anything; unless you _also_ have a root of trust, an attacker could just be feeding the "right" hashes to the TPM and you'd never know better.
On ARM, you control the whole boot process on many SoCs, and can make your own bespoke secure/trusted/measured boot chain, starting from bootrom to the very latest boot stages (given that your SoC manufacturer has root of trust and all the documentation on how to use it), without TPM.
You more or less can't do that on x86, and have to rely on existing proprietary code facilities to implement measured boot using TPM (as the only method), for which you can implement trusted boot, using TPM and all the previous measures proprietary code made to it.
You can do that on x86 too, the main difference is a combination of openness and who you need to sign an NDA with (which, granted, is a big difference, since most ARM vendors are more likely to be your friend than Intel). However, there are a ton of x86 based arcade machines, automotive systems, and so on which have secured root of trust and do not use UEFI at all. On Intel, you get unprovisioned chips and burn your KM hash into the PCH FPFs to advance the lifecycle state at EOM, which is basically the same thing you'd do with most ARM SoCs.
I cracked into many x86-based arcade machines (and non-arcade gambling machines), and none of them used anything really bespoke. I never seen non-BIOS/UEFI x86 system in my life.
Not going to say they are non-existent, but probably the only mention of not using UEFI on Intel chips was in the presentation of Linux optimization for automotive from Intel itself, where they booted Linux in 2 seconds from the cold boot.
I've seen the Intel bare-metal stuff in enough automotive products to call it extant in the wild; I've only heard of it being used in video arcade stuff so maybe I was misinformed there.
Anyway, I think we're both on the same page regardless that TPM and hardware root of trust are not the same thing. In some configurations TPM can (weakly) attest that the hardware root of trust is present, but it doesn't actually do any hardware trust root, and that looks architecturally very similar on x86 to how it looks anywhere else (mask ROM verifies a second bootloader against RTL or manufacturing fused chipmaker public key hash, second bootloader measures subsequent material against OEM fused key hash, and so it goes).
I think the general problem is that SoC-based security relies on internal "fuses" that are write-once, as the name suggests, which usually means that they are usable by the manufacturer only.
TPMs can be reprogrammed by the customer. If the device needs to be returned for repairs, the customer can remove their TPM, so that even the manufacturer cannot crack open the box and have access to their secrets.
That's only theory though, as the box could actually be "dirty" inside; for instance it could leak the secrets to obtained from the TPM to mass storage via a swap partition (I don't think they are common in embedded systems, though).
Their have been many vulnerabilities in TrustZone implementations and both Google and Apple now use separate secure element chips. In Apple's case they put the secure element as part of their main SoC, but on devices where that wasn't designed in house like Intel they had the T2 Security Chip. On all Pixel devices I'm pretty sure the Titan has been a separate chip (at least since they started including it at all).
So yes incorporating a separate secure element\TPM chip into a design is probably more secure, but ultimately the right call will always depend on your threat model.
>V8 emits a near-jump for all forward jumps. If the target ends up too far away, the near-jump target is adjusted to a jump pool entry that contains a long-jump to the actual target
This sounds weird to me... Why not assume that all jumps need to be long to start with (so that the code is valid), then relax them to short jumps during an N-pass optimization stage- so that you get the smallest possible code?
Sounds like it's probably emitting the machine code in a single pass (compilation speed matters for a browser JIT), perhaps even together in a single pass with lowering (so don't even know the amount of instructions beforehand), and for such adjusting things afterwards would mean parsing & rewriting bytecode, and adjusting already-hardcoded backwards jump distances.
Maybe they benchmarked it and processors are so good at predicting the indirection, it doesn't matter much. In out-of-order processors there is a lot of untapped potential. As an example, Rust inserts bounds checks almost for free.
They only want the screen for the stereo and backup camera, not anything else. It's easier to update a car from 2004 say to have Android Auto than to fix one made in 2024 that doesn't have it. $400 aftermarket stereo from crutchfield..
I would say that 2005 was peak car, except 2000 is slightly better because they had not yet gone nuts with serialized components.
(another reason is that direct inject fuel injection hadn't taken over yet, it's a disaster)
EDOS was a direct 6800 port of FDOS. FDOS was the first DOS available for microcontrollers, using iCOM's FD360 8-inch floppy drives.
https://github.com/jhallen/exorsim
https://www.youtube.com/watch?v=TpHKygZ7OHY
reply