Yeah, their (Deepseek's) rock-bottom pricing is all you need to know about this sitch. If the numbers don't work w.r.t. profitability (i.e. they are lying about the upfront investment), then their investors will roast them alive and/or they will fall behind with time as their fabricated budge won't be able to keep pace with the actual (i.e. hidden) training costs.

More germanely, it is entirely plausible that their model was orders of magnitude cheaper to train than even their own preceding models (e.g. Deepseek v3) given that it's an MOE with a reasoning fix on top of it. It is DEFINITELY true that they are cheaper to run, esp. given the distillation process + results (i..e you can imbue the reasoning aspects onto small dense models like 32B Qwen, which will run well on current 24/32Gb cards, and even the full-banana MOE R1 deepseek model runs at 8-9 t/s on 12-channel DDR5 systems). That's the really disruptive aspect here, IMHO. The fact that any US business model relying on gatekeeping the model weights behind the huge training costs and then rent-seeking the inferencing API due to the energy constraints (i.e. data centers with nuclear power plants attached) just got a kick in the pants. You can go buy a $5k computer today and have something that benchmarks comparably to the state-of-the-art closed dense models from the big boys. In a few years that will be a $1k computer. In 5-10 years, if not sooner, that will be in your pocket.

Counter points:

https://www.nvidia.com/en-us/a...
https://www.tsmc.com/static/en...
https://www.amd.com/en/corpora...
https://www.asml.com/en/compan...

need I continue?

Disagree.... just make vehicle registration scale by miles driven annually * weight of vehicle (which is at least a linear approximation of both energy consumed and damage caused to roads), and watch those fleet-averaged curb weights go down with time the same way MPG has gone up. People ARE fundamentally motivated by money.

Because we have an existence proof that it's stable (on the order of hundreds-of-thousands of years), survivable for the ecosystems that actually do exist today, and 100% compatible with human life. Maybe we are in a local minima and there is some *more* optimal equilibrium condition for humans out there, but for each one those optimums that *may* exist there are likely infinitely more outcomes that just result in destruction of established ecosystems we rely on, massive loss of human life, or human extinction altogether (as has been the typical outcome for most other species on this planet). We are also unlikely to stumble across some better optimum by just blasting ONE input variable (e.g. atmospheric CO2 concentration) to 11. So why roll those dice?

So just splice them in at some randomized keyframe and landmine those chunks if they are requested from the server. Once your client requests an ad-bearing chunk in the stream, deny all other requests for (non-ad) stream chunks at the server for (length_of_ad)-(length_of_current_stream_buffer) wallclock time. That defeats both sponsorbblock-like blacklisting AND skipping the ad by any third-party client. You could still presumably download the file for offline viewing with some third-party download tool and then skip the ads, but that would require planning everything you want to watch ad-free well ahead of time.

Weird! It's almost as if this move were calculated to elicit this exact reaction. Don't worry, they will keep raising your prices periodically, but never enough to shock the (average) customer into leaving!

Fatal cases among nursing home patients with HIV.... yeah... Fatal cases among healthy 45-year-olds who proactively check themselves into a hospital? Not really.

Hundreds of healthy 45-year-olds die of pneumonia + MRSA in US hospitals every "few months"?!? We're gonna need to see a source for such a claim.

Sounds like somebody never played the educational kids game called "Mousetrap"... You only throw someone out of a window or poison them with a polonium isotope produced only in a very specific type of Russian nuclear reactor IF you want to send a message. On the other hand, if you want actual plausible deniability, you go for some wacky chain of events that causes rubes online to raise questions.

Nah, because EV's are not fundamentally more expensive than other luxury cars in each market segment. It's just that it became exceptionally expensive to make an EV owner whole after an accident, particularly during covid-related supply-chain shortages (i.e. certain models sat un-repaired for months, and that IS NOT cheap). Tesla's insistence on using their own bespoke repair network/parts also doesn't help, nor does the large replacement cost concentrated in the battery-pack alone. Again, this is reflected in the EV owners higher premiums for collision/comprehensive, but also everyone else's higher liability premiums because that's just how insurance works (i.e. you now have an x% chance of hitting a Tesla vs. y% chance of hitting a BMW, and the Tesla costs z% more to repair because of current market reasons)

In time, I expect the costs of repair vs. purchase-price of EV's to equalize w.r.t. other vehicles.

Same in the USA. But the thing everyone is forgetting is the cost of liability insurance. If everyone on the road (except you) suddenly got a Rolls Royce next year, YOUR insurance rates would also go up, because the expectation value of the cost your insurance company has to pay out in the event of a liability claim against you just skyrocketed from "maybe hit a corolla to DEFINITELY hit a brand new Rolls Royce"

Same with EV's, esp. as repair/replacement costs blew past the stratosphere over covid, and insurance providers had to make them whole. EV drivers certainly pay more for their own insurance policies, but now every other driver also faces increased liability premiums as the fraction of "more expensive to repair/replace" cars on the road has increased. (i.e. 6.5% of new cars currently sold in the USA are EV's).

Presumably the update signature is checked the exact same way it is for every subsequent update that is sent to you (e.g. OTA cellular, wifi, usb, etc.). So what's the concern here exactly? If you trust the system enough to update over a random wifi / cellular / USB connection post-sale, then how is this any worse?

Correct... as can be seen by the sharp step-function in used prices between macbook w/ good screen vs. macbook w/ broken screen in models where you *can* replace the screen yourself and models where you need Apple's blessed pairing software (i.e. you have to first buy the part from Apple at their inflated price before they give you cloud access to the tool necessary to program that 1 laptop to that 1 screen). Once you cut out cheap third party + DIY repairs, you drive customers back to your own retail offerings (i.e. applecare, apple official repair services, new device sales when the cost of repair artificially exceeds some fraction of the device).

There is a very simple middle ground which still lowers device theft. Go ahead and serialize the parts, but give access to the pairing software for free to end-users and repair shops. Just limit it to calibrating machine + screen combinations that are not currently icloud locked (which it presumably checks anyway when you purchase an official part... I don't know for sure, but I am assuming it doesn't just let you calibrate a screen from a stolen laptop to a new logic board). If you are serializing parts anyway, you know which pieces belong to which machines along with the real-time lock status of the device each part came from.

The other thing that absolutely REQUIRES regulation is the cloud-based device locking (both MDM and icloud). Recyclers are currently shredding tons of apple hardware coming in from the corporate world daily because it can no longer be resold. This is amazing for Apple's bottom line, but terrible from an environmental, e-waste point of view. IMHO, if you provide device-locking features, you should also be legally required to provide device-unlocking features (for free or a small nominal fee to cover admin costs) if the other party can actually PROVE ownership (e.g. a certified recycler that a device was legally transferred to)

Disagree... all of the compiler horse-shittery here is because Apple CHOOSES to ship their own ecclectic mix of llvm separate from the OSS versions available on other platforms. Like I said, it's not even clear there is a path to re-constituting all of the open-source components in LLVM to make your own copy of AppleClang (because they don't actually have to give you all of the bits in source-code form, much less a way to make your own equivalent binary). This is, of course, 100% their right to do (and the core reason they went this route over abiding by the GCC license). But it does artificially lock you into their way of doing things if you want to reliably develop for OSX.

The one example I gave above was of OpenMP. Presumably it's excluded from AppleClang because they want you to use their proprietary parallelization API's instead. While you can link the library back in from a related version of LLVM, you cannot ever be sure that this hack will continue working in perpetuity (e.g. they *could* make a breaking change to AppleClang that isn't upstreamed at any point in time). You also can't just use vanilla Clang with certainty that you aren't missing some non-upstreamed optimization/fix they made somewhere along the way (e.g. for Apple Silicon).

In short, you have to do it "their way," which often results in the thing you wrote being artificially incompatible with other operating systems . . . or run the risk of a headache later on.

Of course they can... they just have to abide by the license terms. Which effectively preclude them from putting developers into the above-described situation.

FFS, it still doesn't support OpenMP. You have to go find the equivalent version of LLVM, compile your own libomp, and then franken-link it in. It *seems* to work with AppleClang, but given possible divergence in both compiler branches, that's more of a happy coincidence than some sort of ironclad guarantee.

You *could* just use LLVM, but then you don't know if they made any other compatibility-breaking changes in AppleClang, esp. on their own CPU architecture.

Stallman was... right?