wtallis

The client/consumer desktop market hasn't actually disappeared, and soldered memory is almost unheard-of in that market segment.

The iGPU's video decoder could even be drastically less efficient than the dGPU's decoder, and it would still be better to use the iGPU, because just powering up the PCIe link and VRAM for the dGPU costs far more power than the video decoding itself.

You might want to not only re-evaluate what you consider a real GPU, but also take a look at what the latest Intel integrated graphics is capable of (Panther Lake laptop chips with 12-core GPU chiplet fabbed by TSMC). Intel is still way behind NVIDIA and AMD in the discrete graphics card market, and their drivers don't have the decades of accumulated hacks to work around badly-written games, but their good iGPUs aren't a nightmare of incompatibility and missing features like they were 15 years ago.

I was including USB history before USB-C, because HDMI and DisplayPort have been around much longer than USB-C. And limiting the discussion to "fully-featured USB-C cables" is ignoring most of the real problems.

The critical difference is that USB versions keep adding new wires and active components, while the display cables largely stick to tightening the analog signal integrity requirements. Whether an old HDMI cable works for a new display is largely a question of how high the data rate is for the new resolution and refresh rate, vs how much the manufacturer of the cable overshot their analog bandwidth target.

I guess I just don't really buy your argument, because if their CPUs had turned out poorly, you could have applied the same argument to their CPUs instead of the GPUs.

Doesn't the argument work fine on the CPU side? Apple doesn't seem to be hurting for lack of a Threadripper competitor.

You say "that's exactly why they do it" then go on to describe something entirely different: an organization with plenty of options to spend their development resources on, and they make their decision not out of a lack of options but due to misaligned incentives. Which is exactly the point I already made.

Yes, get-childitem is a little weird to remember,

That's not the problem. The problem is that it's way too much typing, and with the default tab completion behavior it's often way too much backspacing if I didn't get what I want. A good command-line shell designed for interactive use should be terse enough that it's clearly faster than using a GUI. And the OS should ship with such a shell out of the box; building your own on top of a weird scripting language is silly and not at all the same thing as the OS having a reasonable shell built-in. (Most of the value in PowerShell comes from having it installed by default on all Windows systems, and it's sad that Microsoft decided to just freeze it at 5.1.)

I don't think software companies ship UI churn because they're running out of things to do with their development resources. They're just bad at rewarding bug fixing and bad at saying no to user-visible changes that aren't meaningful improvements big enough to overcome the pain of making users re-learn a changed UI. Microsoft doesn't need to scale down their Windows development resources, they just need to make them do the less-fun parts of their jobs instead of shipping new intern project rewrites of Notepad.

PowerShell has always struck me as being fine for scripting (especially since the OS ships with an editor with autocomplete), but absolutely insane for everyday interactive use, especially given how many places Microsoft applied their usual tactic of making their clone of an existing thing arbitrarily different. The design was clearly heavily informed by Unix shells, but it's like they were operating under a mandate to apply the principle of maximum surprise. Stuff like the default tab completion behavior very obviously interacts badly with the extreme verbosity.

You seem to be conflating "RGB" with one particular RGB color space: sRGB. That's a common enough conflation to make, but not appropriate when you're trying to be pedantic.

Do any operating systems update file access time after every read operation instead of just at fopen?

It's kinda irresponsible to talk about read disturbance without clarifying that it takes an extremely large number of reads to cause a read disturb error, and it can be corrected by a single rewrite of the data. Read disturb errors are something SSD engineers need to account for, but from an end user perspective it's a smaller problem by multiple orders of magnitude than write endurance, which is already rarely a real problem in practice.

I guess they're just welding the memory to the CPU chip, but still curious.

Unified memory is more of an architectural and performance characteristic, and does not imply much about the physical layout of the machine. Most unified memory PCs not from Apple don't have the memory on the same package as the SoC. For stuff like AMD Strix Halo and NVIDIA DGX Spark, it's just standard LPDDR packages soldered on the motherboard in the general vicinity of the SoC, and the only difference from mainstream laptops for the past decade+ is that the memory bus is twice as wide.

And you probably won't pull more than 100 Watts

I've played with ds4 on such a machine, and the battery drains when using only a 96W power brick. But you can put it in low power mode and the fans won't even turn on while it delivers something like a third of the performance.

So you're just repeating the assertion that SDR vs HDR and absolute vs relative brightness aren't orthogonal, but haven't even attempted to explain or construct an argument to justify the assertion.

I think it's quite obvious that you can have a system to represent 17 stops of dynamic range without anchoring brightness to an absolute scale, and that you can have a system to represent 6 stops of dynamic range that is anchored to an absolute brightness scale. The two properties are separable.

The only reason that you can get away with saying "half the point of HDR is that the filmmaker can say I want this bit to be this bright" is because of exactly the conflation I'm criticizing: the "HDR" label as used for marketing was redefined to mean high dynamic range plus a standard representation that encodes absolute brightness.

It has always struck me as strange and user-hostile that most of the computing and entertainment world has decided to couple together the transition from SDR to HDR with a conceptually unrelated switch from relative to absolute brightness scales, and to not really make any effort to explain to users what's going on with that.

The contract terms could very well have actually had a meaning that included filming inside the apartment. The existence of other laws overriding the contract isn't actually the same thing as the contract not having that invasive meaning.

I think X11 terminology may be causing some confusion. Refer to https://nouveau.freedesktop.org/MultiMonitorDesktop.html

The normal, usable way to have multiple monitors for your X11 desktop environment is for them to all be combined into one logical screen that you can move windows around in, and that applications aware of the right extensions can discover the actual physical layout of the monitors that comprise the single logical screen. Multiple screens in that X11 sense is a far more obscure feature than simply supporting more than one physical monitor.

I think there's also a major difference between the kind of weird intermediate frames that are acceptable for a highly-stylized cartoon at 24FPS and the kind of intermediate frames that are acceptable for a UI running at 120FPS.

It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.

When people talk about whether something like a Pi is aimed at industrial customers, that is largely not a statement about the cost vs specs, nor about the level of engagement with the DIY community. It's usually about having a suitable supply chain and long-term support and stable BOM and a mature software platform for customers to start building on.

It could instead require third parties to improve theirs.

Apple made it sound like their proposal for that was rejected by the EU. And it would be consistent with previous regulatory decisions by the EU for them to not want Apple to be setting the rules for how third-party interoperability partners/competitors ensure privacy.

It seems to me that the EU has a preference for protecting privacy with legal mechanisms, and generally doesn't approve of Apple's attempts to protect privacy with technical mechanisms because that inevitably limits interoperability with systems that aren't designed around the same restrictions and assumptions.

The data bus was only 16 bits wide, but that doesn't really have much impact on OS compatibility; it just means that transferring a 32-bit value to or from memory takes two bus clock cycles instead of one. The address bus is only 24 bits wide, but that only affects physical memory address space; it still uses 32-bit pointers and a 32-bit virtual address space.

On non-Apple platforms, you generally have at least 2+(number of supported silicon vendors) different AI frameworks to worry about. I guess Apple's there now too, between Core ML, MLX, Core AI.

I haven't seen any sign that the framework fragmentation problem is going away anytime soon. NVIDIA wants everyone to do all training and inference with CUDA and to deny that NPUs have any usefulness. Everybody making an NPU has a different framework tailored to their architecture and the limitations they inherited from hardware designed before LLMs existed, and most of them have a another framework for targeting a GPU. And the OS vendor has one or two frameworks they would prefer you use rather than something hardware-specific.

Even if you set aside the stupid charging situation, it's still a bad mouse. The multitouch capabilities are not well used by the software, and it's the only mouse I've ever used that routinely sends scroll events while I'm just trying to click or drag. Their laptops are pretty good at rejecting accidental touchpad inputs despite those touchpads being quite large, but the mouse is a constant source of unintentional inputs.

That's the way to phrase it if you want to ignore or downplay the leverage that big tech companies have over their users to get them to consent to shady business practices using dark patterns. But this wouldn't be an issue to begin with if it was safe to assume that users fully understand what an app will do with their data, and if it was safe to assume that the app's data-handling practices could not drastically change at the developer's whims.

The M5 Max with the 32-core GPU is ~7200MT/s,

Ok, so the problem is you doing the math wrong. Note that the MacBook Pro configuration you're talking about has a DRAM capacity of 36GB, compared to 48+ GB for the ones with all the cores enabled and the full memory bandwidth. That 32-core config isn't running the DRAM slower, it's running with a narrower bus and fewer DRAM chips: https://theapplewiki.com/wiki/MacBook_Pro_(16-inch,_M5_Max)

There is no "package" here. Apple's processors are soldered to the logic board, as are Intel's in laptops.

Denying the difference between putting the RAM on-package vs on the motherboard doesn't make that difference stop being real.

Apple being the first to ship LPDDR5-9600 when it was that recent doesn't imply that it needs to be soldered

Apple wasn't even close to being the first to ship LPDDR5-9600. Android phones using DRAM at that speed started shipping at the end of 2023, and moved on to 10700MT/s starting in 2024. The situation here is not anywhere close to being one of Apple paying a premium to get faster DRAM chips that other laptop manufacturers can afford. Rather, for most of the past several years, laptop manufacturers (especially on the x86 side) have been unable to buy DRAM chips with a rating slow enough to match what their processors are capable of running at. It's become quite common to see on a Thinkpad spec sheet that eg. the DRAM parts are rated for 7467MT/s but will only operate at 6400MT/s due to processor limitations, then the next year see that the DRAM parts are rated for 8533MT/s but run at 7467MT/s, and so on. LPDDR speed increases have been driven primarily by flagship smartphones, and even the leftover slower-binned parts are faster than what most laptops can handle.

Framework already sells LPCAMM2 at 8533MT/s with full validation:

From your link:

Framework Laptop 13 Pro (Intel® Core™ Ultra Series 3) supports one slot of LPCAMM2 memory up to 96GB at the native 7467 MT/s speed. It is compatible with LPCAMM2 modules with memory speed rated above 7467 MT/s, but the speed will be capped at 7467 MT/s because of the platform limitation.

The modules in question can only theoretically operate at 8533MT/s. Framework has yet to sell a system where the modules actually operate at more than 7467MT/s.

It turns out Apple isn't getting 9600MT/s either. I assumed that soldering would be getting them at least what LPCAMM2 is rated for, but if you actually do the math, they're getting ~8500MT/s for their most expensive systems and ~7500MT/s for the others.

You're either doing the math wrong, or just plain looking at the wrong systems. Try looking at the M5 generation.

CAMM modules use a compression fitting to attach the chips to the system board using approximately the same amount of space as the solder pads would for soldered chips. If you get to the point of having so many channels that the chips are in the way of the other chips then the soldered ones have the same problem.

Yes, that's a problem, and Apple has solved it by moving the DRAM on-package. Datacenter GPUs have also solved it that way by putting the DRAM on a silicon interposer to allow even wider bus widths. Soldering standard DRAM packages on the motherboard is not the limit of how memory can be soldered down.

A single LPCAMM2 module is a 128-bit bus. Every system that uses it has at least that.

Yes, 128 bits at lower speeds. Did you forget that the whole point I'm making here is that the speeds are not the same?

Nobody is really using a bus that wide with soldered memory either though, outside of the couple of Macs that start at ~$3500 and are getting the same speed Framework does with LPCAMM2.

The Mac Studio with the M3 Ultra is actually running the DRAM at a lower frequency than what Framework and other Intel-based systems could, but more than making up for it in bus width, to provide far more total memory bandwidth than any plausible LPCAMM2-based system that could be built today.

Upgradable memory and unified memory aren't entirely mutually exclusive. You can design a chip that uses DDR5 and has a decently-powerful iGPU that can use that whole memory pool. But you'll be starving that GPU of bandwidth relative to what you'd achieve with soldered LPDDR, and it's not really worth the trouble of building a large iGPU unless you're also going to feed it with the fastest memory you can reasonably put down.

If you look at eg. an Intel laptop chip, you'll see they design and build a memory PHY that can interface with either DDR5 or LPDDR5x. They don't support splitting it to have one controller operating with DDR5 and the other with LPDDR5x, for fairly obvious reasons: more complex hardware, harder for software/operating systems to manage optimally, and not a lot of benefits to drive demand and justify the expenses. The speed difference between LPDDR5x and DDR5 isn't really large enough to use LPDDR5x as an L4 cache; it would be more like two different NUMA nodes, with complications for laptop power management.

If you want somebody to build a chip with more than the usual 128-bit bus and make some of the memory controllers use LPDDR and some DDR5, then you're asking for a significant increase in chip cost due to the extra memory PHYs and pin count. That cost is only justified if almost all products using the bigger chips are going to actually take advantage of the full complement of memory controllers.