road to hell is paved with good intentions. one could argue it would've made browser vendors fix their bugs, but with the side-effect that any behavior that isn't bug-compatible with IE becomes a bug. this would've ironically entrenched IE permanently.
The mistake was not claiming features rather browser client versions...
JS devs were kinda able to patch around the nonsense because they were able to feature-detect - part of the reason this stuck around was because no legitimate user or dev cared (or should care). But the header was mostly (useless) noise, and the people spoofing were dealing with the couple bad apples of the time.
Of course, defining features is easier said than done, and a standards body is a challenging environment to define these in...
I get why people are fingerprinting bots and others are working around it, but neither are "legitimate" applications - if your content is public, it's public, end of story. And working around these controls to sell botnet access to sites is equally illegitimate - nobody has a right to resell content they do not own...
I just can't see how it could make sense to define features when a ton of the the behavior wasn't even intentional but just tons of bugs. I recall debugging issues that only reproduced in "IE7 compatibility mode of IE8" which didn't reproduce in either IE7 or IE8. And that was already after the standards were taken at all seriously
I can't say I agree with you here, if anything FPGAs and general purpose microprocessors go hand in hand. It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm. Currently this is all handled by fixed function silicon which rapidly becomes obsolete. AV1 support is only just now appearing in mainstream chips after almost 8 years, and soon AV2 will be out and the cycle will repeat.
This is such a severe problem that even now, (20+ year old) H.264 is the only codec that you can safely assume every end-user will be able to play, and H.264 consumes 2x (if not more) bandwidth compared to modern codecs at the same perceived image quality. There are still large subsets of users that cannot play any codecs newer than this without falling back to (heavy and power intensive) software decoding. Being able to simply load a new video codec into hardware would be revolutionary, and that's only one possible use case.
> It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm
That relies on "FPGAs everywhere", which is much further out than "GPUs everywhere".
I'm not sure where the state of the art is on this, but given the way that codecs work - bitstream splitting into tiles, each of which is numerically heavy but can be handled separately - how is development of hybrid codecs, where the GPU does the heavy lifting using its general purpose cores rather than fixed function decoder pipeline?
But why would it be amazing? The alternative right now is that you do it in software and just dedicate a couple of cores to the task (or even just put in a separate $2 chip to run the decoder).
Like, I get the aesthetic appeal, and I accept that there is a small subset of uses where an FPGA really makes a difference. But in the general case, it's a bit like getting upset at people for using an MCU when a 555 timer would do. Sure, except doing it the "right" way is actually slower, more expensive, and less flexible, so why bother?
...which are playing back video, so they're likely blowing most of their power budget on the display and on radio. I guess my threshold of "amazing" is different. Again, I'm not denying some incremental utility in specialized uses, but most of the time, it just doesn't seem to be worth the pain - especially since nothing about the implementation will be portable or maintainable in the long haul.
In the same vein, no one is writing a smartwatch software stack in 100% bare-metal assembly, although in the hands of a capable developer, I'm sure it could prolong battery life.
And you think that a downloaded codec on an FPGA would perform anywhere close to custom silicon? Because it won't; configurability comes at a steep cost.
Why not? The firmware was already public at one point. If people are analyzing your app to find an S3 bucket full of firmware, I'd assume they'd have a pretty good reason to go through the effort.
Doesn't matter really, keeping blobs hidden doesn't actually do anything except make it slightly harder to analyze the software. Making all blobs easily and readily available is exactly what I want the vendor to do. Black boxes don't make things secure.
I agree with you in principle here, but to play devils advocate, $1,000,000 isn't a whole lot of money. A worker will make around that much at $25,000 a year over 40 years. If we have to keep money/capitalism, the limit should probably be around 10-15 million. That's still pretty high, but not egregious. Give or take ~40yrs on a high FAANG salary ($375k/yr). Still firmly upper middle class IMO.
I don't mean earnings over a lifetime or career, but currently. A worker making $25,000 a year will still probably never see a million dollars regardless of the limit. Maybe everything above that is taxed 100%. I don't know.
But the point is kind of to eliminate the upper classes and scale the economy back into the reach of most people. So there would be no FAANG salaries. The cost of everything (healthcare, education, housing) would go down. It would place a hard limit on political influence that isn't too far out of reach of current Congressional salaries and would probably limit pork barrel politics and insider trading as well. It would end inherited wealth and maybe even limit the length of copyright.
That's an admittedly naive and utopian view and I'll admit there are bound to be complexities and externalities I'm not taking into account because I'm not an economist. But it's either that or we seize the means of production and put the rich to the guillotines until the sewers choke on their blood. And then something something luxury space communism.
That's because the data is inherently flawed. The poverty line this year is $15,650 for an individual. That's not poverty, that's destitution. From personal experience, living in WV, you cannot survive on that amount of money without either sleeping under a bridge/in a car or dumpster-diving/shoplifting all of your meals.
Folks say just get on food stamps or medicaid, but it's not that simple. At that level of destitution you may not have a phone, an address, basic ID/documentation, or even a means of getting to the office to apply. Means-testing makes the process so drawn-out and convoluted, that many folks (including myself) don't even bother, because there are more immediate things to worry about (once again speaking from experience).
After years of destitution, I finally managed to make a bit more than twice the FPL and I was still struggling (but significantly better off). Just recently I lost that job for reasons outside my control and after my unemployment runs out I'm back where I started. Everyone I know has a similar story. Any data that says that poverty is decreasing in the US is detached from reality.
Thanks for your story and I'm sorry it's been such a struggle to stay on your feet. I agree that too many people never make it outside of their social and economic bubble and never bother to see what reality is like for most Americans.
I'd argue it's probably time to drop 32-bit x86 support, but the rest of this stuff is arbitrary and doesn't have any tangible benefit except conveniently providing hardware manufacturers with an excuse to unload new hardware onto people when there's nothing wrong with what they have. (not to mention, pardon the conspiracy theory, they're probably trying to use the TPM to turn the PC into a smartphone-like platform)
It's surprising that when we had Win7 they did that brief "XP Mode" experiment with some virtualized-penalty box.
Why didn't that go further? Presumably virtually any x86-64 box currently in circulation would be fast enough to run a VM running a full copy of 32-bit XP/Win7/Win10, or even a full carousel (or download store) of DOS and early-windows releases. It could be the most compatible Windows ever, solving the weird "64-bit systems can't run some 16-bit apps" gotcha and perhaps allowing some way to bridge in support for devices that can only be driven by old 32-bit XP drivers.
Here's a significantly more credible (stacksmashing) video that demonstrates how ineffective some TPM implementations are. If the TPM was integrated into the CPU die, this attack would likely not be possible. https://www.youtube.com/watch?v=wTl4vEednkQ
Despite the TPM being a pretty good and useful idea as a secure enclave for storing secrets, I'm concerned that giving companies the ability to perform attestation of your system's "integrity" will make the PC platform less open. We may be headed towards the same hellscape that we are currently experiencing with mobile devices.
Average folks aren't typically trying to run Linux or anything, so most people wouldn't even notice if secure boot became mandatory over night and you could only run Microsoft-signed kernels w/ remote attestation. Nobody noticed/intervened when the same thing happened to Android, and now you can't root your device or run custom firmware without crippling it and preventing the use of software that people expect to be able to use (i.e. banking apps, streaming services, gov apps, etc.).
Regardless, this is more of a social issue than a technical issue. Regulatory changes (lol) or mass revolt (also somewhat lol) would be effective in putting an end to this. The most realistic way would be average people boycotting companies that do this, but I highly doubt anyone normal will do that, so this may just be the hell we are doomed for unless smaller manufacturers step up to the plate to continue making open devices.
