Oh, because Microsoft is totally unable to pretend to consent to the change, and not revert the TOS as soon as the bug fix is resolved? The expectation that they wouldn't unwind the change immediately seems a bit naive.

You'd need something much stronger than a vulnerability, you'd need to gain permanent data blackmail advantage to get that kind of change to last.

I've tried reaching out to local and state politicos and NFIB and other 'small business' interest groups about this - automation would tend to move in the direction of capital because it costs money to purchase a robot or robo-taxi etc. - but the concentration of capital that results from this is toxic in the long run for the community and the businesses that use automation. At some point not only will the low skilled labor jobs disappear, but the next ripple is that the technicians to keep those very self-same machines will disappear... (c.f.: industrial machining, US/North-America, 1990 to present).

My modest (no hyperbole intended) suggestion is that robo-taxis are a perfect test-case for resolving the Universal-Basic-Income dillema - we (American) generally dont give money to people for nothing, but we're very happy to subsidize and leverage government guarantees to give individuals access to capital (c.f.: mortgages) and that works hugely to grow markets AND get individuals to become stakeholders in their physical/local community through home ownership. In the same way providing financial backstops for owning/operating/maintaining robo-taxis would be an ideal way to provide effectively a Universal-Basic-Income using already existing systems like mortgages and public/private banking. Fund/support the purchase of robo-taxis by individuals, resulting in income for the people owning the robo-taxis, and now they can work a small amount of time to do basic car care & maintenance, and (hopefully) end up with a stable income source.

The only problem is that today there is no limit on the number of robo-taxies a corporation can own and gather profits from, so right now Cruise, Uber and others need merely tap their much cheaper capital to grow their fleets. This completely eliminates any likely entrant into the market to operate robo-taxis regardless of whether the machines themselves are purchasable on the open market - Uber can get every dollar to purchase such a car cheaper than you can, and the more they buy, the more power concentrates there. But if there as an ownership limit, coupled with robust GSE funding (FreddyMac) that would actually result in Uber growing faster even than they can now with direct financial operations.

Comments? Drawbacks I havent seen (yes I know its pretty pie the sky given today's political market, but one can at least ponder a liberty inducing solution to a rapidly growing crisis...)

Apple bought PARISC just for the engineers (not the IP), worked good for them, the IP acquired was obsolete but that team went onto making the ARM based processors for phones, pads and M1 Mac’s. So it could be a good win if the Human Resources are good.

Question is, would Qualcomm be acquiring revenue positive groups with lots of young innovative engineers, or marginal legacy product IP that has short term diminishing revenue with some ‘essential’ staff attached?

Uhh, did you not realize those listicles are limited so that you have to generate clicks? They measure engagement and harvest your eyeball-attention-usage data from those clicks. Even with JavaScript they don’t get much data from you scrolling through a page, but make it clickable and they can behaviorally profile your interest, consumption, and maybe even the person using the mouse, depending on whether we’re thinking Cambridge Analytica/Palintir level magic, or just make a good guess if you don’t believe in the BS. Either way listicles have not a single thing to do with data/bandwidth saving.

What’s the alternative though? Those same HR drones are maybe even _worse_ at resume analysis than a grep search, or they were the last time I had to work with one (hr drone) - they could not (or would not) tell the difference between a MS in Comp Eng. from a diploma mill and a 20 year veteran with a high school music cert (pro tip, the 20 year veteran was hands down the best software artist I’ve ever hired), they kept feeding me “highly qualified” people who were great at doing tests and paying tuition, but lousy at anything requiring independent thought, but then the HR drones were themselves bad at independent thought which is why they were in HR in the first place.

Humans are very bad at judging other people from paper resumes, computers are literal algorithms, even LLMs are limited by their training data, hiring is a risky business full of ways to do it wrong. Maybe we should do a better job teaching mid level developers to be talent scouts and ditch both the CV scanners and the basket-weaving degree holding HR drones?

Not sure if Lynch is somewhere on the spectrum (as in neurologically unable to judge his correspondent's attitude) or just as much of a scumbag as Sweeny (as the great statesman once said "Pity they can't both lose"), but apparently yes, yes he was mad, very mad. Mad enough to go to war with one of the largest companies on earth, lose epically (*snort*) in Federal Court, and keep on digging [cf: EU regulations of late]. At this point Sweeny is going to bankrupt Epic out of sheer spite against all the parties that seem hostile to him, and I'm not sure he's really wrong, just going about it in the most phyrric way possible.

So that begs the question, was Valve aware of how bad Sweeny is at persuasion and winning the long-game and they chose to purposely enrage him, or were they just as clueless about why all this rent-seeking makes the rest of the world hate them?

TFA

The authors mathematically correlate the recession with a reduction in mortality, this is non-controversial (that is if we agree that the mortality statistics are valid). What happens next is where I agree with Junta - this conclusion is some pretty broad hand waiving speculation that is certainly persuasive, but not actually justified as a proven fact:

(1) from Page5 of the article, the source data is CDC (for young people and all cause mortality) and Medicare data (for retiree mortality), Bureau of Labor Statistics for actual employment, EPA Air Quality data as a proxy for drivers of mortality from pollution, Behavioral Risk Factor Surveillance Survey (BRFSS) to identify mortality driven by work activities, and Medicare Health and Retirement Survey for 2002-2014 to account for drivers of mortality amongst nursing home residents.

(2) they (page 10) then attempt to measure the "Shock" impact of the Great Recession in terms of mortality overall, in an attempt to remove confounders, they look at regional variations (between states) and level them out so as to approximate only the median effect of the recession upon Mortality (the claimed reduction),

(3) finally by page 20 the authors begin to make hypothesis about the causation of the decline (which pre-supposes their math in the above sections are sufficiently robust, as I am not a statistician I'll leave that debunking to others). The authors report first on "internal" effects which is about non-aggregate single-person behavior, like seeing your own doctor and eating healthily:

Then they look at external effects, communicable diseases, quality of healthcare, and then _finally_ pollution. They only consider these factors based on prior papers that suggest correlation, they don't provide a rational in the paper itself as to why you discount other possible sources of the change in mortality, so here's the first point where I think this is quite broad speculation masquerading as "hard statistical analysis":

Essentially they restrict the analysis to three possible causes, and with lack of proof of either of the first two analyzed causes they pull a Sherlock Holmes and "ergo the cause must be item number 3". While we can agree that there is correlation, and it seems valid to assume pollution does in fact lead to mortality, the nature of the causation is left as an "a-priori" statement and they proceed immediately to calculation of the magnitude of the connection.

If I mis-spoke let me re-state, I agree this is not a "bug" in UEFI, its a gaping giant hole in the entire security model of UEFI and secure-boot, and it is enabled (in my opinion strongly encouraged) by the UEFI execution model.

Re-read the original justification for the shim and tell me we didn't intentionally imeplement an insecure "Secure boot" mechanism in order to compete with Microsoft?

Reference: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.linux-magazine.com...

From the original article the faulty shim code has valid UEFI signatures, but that code is allowed to load other remote code which is not signature tested!!!

Worse, this happens "before ExitBootServices" - meaning UEFI his technically still in total control of the CPU. UEFI loads the shim and jumps into the shim code, the shim can be forced to load and execute unsecure/unknown code. Since UEFI has not exited, and there is no "user" context here with reduced privileges and privilege separation that occurs after the jump to OS code, the exploit has essentially full access any non-volatile storage (including 'CMOS', attached disks), RAM, cpu microcode, and everything else that runs after this point. The only thing you probably cant compromise is whatever is running in IME or TPM devices.

I don't think that's quite possible, you would have to literally re-program the BIOS option ROM (usually EEPROM/FLASH connected to the Ethernet MAC device) in order to change the PCI Option-ROM code. It's been a while but I don't recall many Ethernet card vendors allowing you to arbitrarily rewrite PCI Option-ROM addresses from the OS without some pretty special tools (and every vendor was different). Here UEFI includes an explicit mechanism to execute non-OEM supplied code during the boot process, which is generic across any UEFI client OS (Linux or Windows), from OS writable disk locations. That makes it a rather large target considering the install base.

OMFG jump to conclusions much? TFA and Ars explicitly place the cause/responsibility on "Linux developers", but as others below point out the issue is in "shim.efi" which technically isn't Linux (and absolutely is not the kernel!), though I'm probably also wrong to state that it is "UEFI" - more like a piece of code that is jointly-terrible, a bad compromise forced on the Linux community by Intel/Microsoft through the UEFI architecture. Its a direct outcome of trying to code a perfect boot security system (SecureBoot) while ignoring many many many years of experience that screams "NEVER TRUST THE INTERNET"... actually it's worse, secure boot turns that on it's head and says "NEVER TRUST THE OWNER OF THE HARDWARE, WE KNOW BETTER"...

I stand by my original point, if your personal non-enterprise, non-cloud computer, can be fooled into looking at insecure internet addresses for boot artifacts (before a single ASM instruction of the Linux kernel itself executes by the way) without requiring evil-maid access to the firmware/FLASH on the motherboard, then the upstream boot processes architects (again Intel/Microsoft and the PCOEMs) are the source of your problem, not "the Linux community".

This is not a Linux vulnerability, this is a UEFI vulnerability exposed by a bug in Linux's boot code. Undoubtedly the exact same mechanism might exist in Windows boot code.

The real lesson - network booting is a nifty thing for specialized circumstances for use only by experienced security-aware administrators, and should not be a default install on any consumer grade hardware...

Except TFA is not talking about password sharing, the entire point is repricing, rebranding and re-selling something you already thought you were paying for, kind of like BMW setting "heated seats subscription" ... its entirely immoral and unethical to bait and switch by taking an established functionality that was part of the marketing campaign which convinced you to sign up for a service tier, and then arbitrarily change the tiers. That used to be called false advertising, but its not like everyone didn't just accept the shrink wrap license agreements and one-sided service contracts... no, wait they did, never-mind, guess it must be ok then.