I have been using SATA SSDs and nVME SSDs for reliable Flash storage, but with Crucial leaving that market, maybe this is no longer a good option.
Companies like Swissbit and maybe Transcend make industrial or at least non-consumer grade Flash sticks.
Last I checked, Toyota claimed their starter motor was good for 100,000 operations. Often times cars use a second starter motor for this feature and if they did consistently fail you’d hear about it.
The starter might be, but what about the pinion gear, ring gear, and starter solenoid?
How much more wear does it apply to the engine parts, like the bearings and lifters? Toyota has been having reliability problems with their bearings and lifters for years now.
The cars have a BMS which turns off the start/stop function if the battery gets low, there are other criteria that affects this too like engine/transmission temp, other electrical draw (heaters/defrosters etc) plus a bunch of others.
I am sure the BMS is as reliable as everything else introduced for fuel economy, like wet belts, roller lifters, intake heaters, and low tension rings, which is to say not reliable at all and expensive to repair.
NAT association tables require a lot of memory. Over the last few days I had been seeding multiple TBs a day worth of Epstein files. Without sufficient memory it could have been a challenge.
The NAT state requires 4KB per connection, so 256 connections per 1MB, hardly exorbitant. This is included in the "state" part of a stateful firewall.
Stateful firewalls are used because they are so much faster. Parts of the packet header are hashed to look up the routing information instead of evaluating the rules for every packet.
Second, whether or not you could make a design work with 128MB of memory (that doesn't leave a lot of room for buffers, for example and may have weird performance issues) the point is that the designs were made when RAM was cheap and plentiful and there's no time now to respin the designs. There could be good reasons for wasting RAM, including making it easy to use off-the-shelf kernels and other software without having to trim and cram, which enable doing software updates easily. Or, again, that the choice of CPU results in needing RAM pretty close to the cutting edge of what's available.
The software still exists to design something to work in 128MB. Buffers are not a problem because the router should not be buffering very much. State requirements are 4KB per connection, so 256 connections per 1MB.
The old m0n0wall did this with a stripped down FreeBSD, of which I forget the name, and would actually work in 64MB.
BSD allocates 4KB per connection for state tracking, which is pretty standard, so 256 connections per 1MB. For years I regularly ran 128MB BSD routers which were much more reliable than anything ISPs provided then or provide now. With 128MB, I never ran out of connections. 1GB would provide 256K connections. Even half of that is more than any reasonable bandwidth will support.
According to Ark there are three recent non-Xeon processors that do:
Core Ultra 5-235
Core Ultra 9-285
Core Ultra 7-265K
Also the 14th gen, 13th gen, 12th gen...
Do you have a source for your position?
With what chipsets? On what motherboards?
Last time I evaluated Intel, it was a twisty maze of ECC passages.
Some of the RAM being close to the CPU is critical, given the speeds being called for.
The RAM was integrated into the CPU package to lower the power requirements of the memory bus. With an electrically short memory bus, series instead of parallel termination can be used. The newest DRAM specifications allow the use of half of the signalling voltage for exactly this configuration.
Speed was never a consideration because the memory bus was never long enough for that to matter. At about 125 picoseconds per inch, the RAM was never that far away.
Power density is irrelevant in a traction application when the size is determined by the energy density.
The extra weight could matter since it is already a problem with lithium batteries.
Also, there can be word-trickery here. It is possible things can be claimed to be "end-to-end encrypted" and yet still have ways for the mothership to decrypt anything at will (by having intentional secret holes/weaknesses, by storing your or another key, or a method they can pull the key from your device through their own control over the app, or by having master keys present at the start). I think that would be a misuse of the term "end-to-end encryption", yet term use/definitions mutate all the time. Anyway this can backfire spectacularly if discovered and lead to a lot of legal issues- if they had denied law enforcement/courts access in the past with the excuse that they can't decrypt it and then it is discovered they could.
I suspect that is what is going on; the traffic is end-to-end encrypted, but the session keys are also made available to Whatsapp, probably by being encrypted with Whatsapp's public key. So there is practically no security despite being "end-to-end" encrypted. It is Clipper for a new generation.
It seems like double/triple dipping.
Cross license with Intel/AMD and get paid per cpu sold.
Cross License with Microsoft and get paid per windows copy sold for the software decode.
And criss license with all of the OEM hardware makers and get paid yet again for each machine sold that can decode in hw.
Great for Nokia to double and triple dip and get paid 3 times for the exact same users. This really indicates we have a royally screwed up patent system.
I do not know that Intel/AMD, Microsoft, and the OEM hardware makers all license the same patents.
Under the doctrine [patent exhaustion doctrine], once an authorized sale of a patented article occurs, the patent holder's exclusive rights to control the use and sale of that article are said to be "exhausted," and the purchaser is free to use or resell that article without further restraint from patent law.
Neither HP nor Dell actually made these encoders in these devices. They are made by Intel and part of the iGPU. If anyone has license concerns it's Intel.
My understanding is that the hardware does not implement HEVC/H.265, but instead implements primitives which can be used to accelerate it.
Yes, but "caught fire and DETACHED" points at something considerably worse than a compressor issue.
It points to turbine failure, including compressor failure. The engine is mounted to the wing structure using shear bolts so that if the turbine seizes, the torque breaks the engine free without destroying the wing structure, which appears to be exactly what happened.
There are countless sedans and coupes that are nice and capable conveyances. That doesn't explain people buying oversized pickups.
For myself, I bought a pickup because it is easier to repair and maintain. Changing the front headlights takes maybe 15 minutes, unlike say a Ford Fusion sedan where the entire front of the vehicle must be removed. Doing my own oil change does not take much longer.
The pickup truck market is distorted by federal regulations such that making smaller pickups is basically illegal.
When my 2002 S-10 was discontinued in 2003 or 2004, it was replaced by basically the same vehicle, but 500 pounds heavier and slightly larger to meet EPA requirements, and that has continued since so now my 2002 S-10 looks tiny compared to today's smallest new pickups.
The reward of a thing well done is to have done it. -- Emerson
