wtallis

The HDMI standard defines an Ethernet channel as an optional feature. Approximately zero consumer products have ever implemented it. There's no need to worry about an unsuspecting consumer having supporting devices at both ends of the cable.

It doesn't make a lot of sense to me as a default, but there's an option to turn off the automatic switching of spaces when switching applications, and it pretty much eliminates the unwanted switches from closing the last window on the current space.

It's also not exclusive to Apple; the normal product cadence from Intel and AMD usually has the large workstation and server chips falling behind the consumer chips in peak single-core performance for part of the product cycle. Some market segments just don't sustain annual updates very well, and it's always easier to get a smaller chip out the door first before a larger chip.

There's no happy medium here that would satisfy everybody: when they make marketing claims about improvements relative to products from several years ago, they get criticized for not focusing on the improvements relative to last gen (even if those comparisons are also somewhere in the announcement). When they focus on the most recent generations, people complain that it doesn't make sense to upgrade every year.

Just accept that even if you aren't still using an Intel MacBook Pro, the comparison is still relevant to some part of their target market.

They only just dropped support for Intel Macs from this fall's operating system release (but are still doing security patches for the releases that Intel Macs can run). A year from now, it actually will be fairly reasonable to expect them to give up marketing to the holdouts.

The white plastic iMacs from the PPC and early Intel era were about four times thicker than the current design. Back then they were putting optical drives and 3.5" hard drives and AC power supplies behind the display; now, it's too thin to fit an Ethernet port. The current set of tradeoffs really doesn't make sense to me, but if you accept the thin design as a constraint the continued existence of the chin is pretty obviously necessary; those older iMacs could have much more easily ditched the chin.

DRAM on die isn't a thing at all. eDRAM was a niche technology for a while but hasn't been relevant to PCs for over a decade.

Did the drive give you more sectors when you used a smaller sector size and fewer sectors when you used a larger sector size? If the number of sectors didn't change, it probably didn't actually do a low-level format and instead just toggled whether the drive firmware would skip over the extra bytes as if they didn't exist.

The entire sentence is:

> For a reported security vulnerability affecting any Apple platform to be eligible for an Apple Security Bounty award, you must not disclose it to anyone other than Apple until after Apple has released a software update and published a security advisory for the reported security vulnerability.

Which does not have the meaning of prohibiting disclosure to third parties or the public; it only means that you forfeit the bounty.

The answer is obvious: we would rather have no home automation than have home automation that can't be trusted.

So do you believe that it's acceptable for your comments here to be laced with insults throughout, as long as they aren't intentionally and specifically targeted at the author of the comment you're replying to? Because I definitely don't think it's appropriate behavior to be denigrating an entire Linux distro and anyone whose values align with the purpose of that distro as merely participating in a meme.

Do you honestly expect anyone to believe that you didn't intend "memeOS" to be an insult?

The article says all colors and storage configs were showing ship dates of January 25 or later, so >3 months.

Native doesn't mean "not a web view", it means native. The eight Qt apps on my Mac are really obvious, with basic fundamentals like toolbars, drop down boxes, and context menus bearing no resemblance whatsoever to any native Mac app from any decade.

10-15 years ago it was possible to reliably clock a Qt on Mac app before it finished launching, simply from the app using the wrong hourglass cursor. (The old cursor that had once been a hallmark of classic Mac OS apps ported through Carbon frameworks, and which disappeared from daily usage when the Finder was finally rewritten atop the NeXTSTEP-derived Cocoa frameworks.)

> "and if they are, not more than the median application."

Comparing against the median means you've already thoroughly missed the point.

There's nothing distributed about GCD; it only works within a single machine.

Half of what you're listing as features people should be impressed are stuff that causes as much frustration as it solves. The image pasting behavior is a super-annoying footgun, because sometimes I just want to tell the LLM the path to the image file without it trying to burn a ton of tokens on computer vision—and dragging and dropping a file into the terminal pastes the path in any normal context. The auto-updating session titles, recap, and notifications are token-burning distractions that are glitchy; I had to disable them when I found that having the agent launch an app would mean I'd get a random beep about a minute later when the agent had been waiting for further input in the background.

And they can't seem to go two whole months without scrolling breaking in some new way.

I don't see how that excuses anything. It certainly doesn't give harness developers an excuse to be disrespectful to their users. It shouldn't give harness developers any reason to not even try to produce a stable release with a well-designed UI instead of a janky mess that gains new bugs every time you try to use it.

There are contexts where "move fast and break things" can make sense, but usually not when it's other people's workflows that you're breaking.

Just how old do you think a category of software product needs to be before it's reasonable for users to start expecting professionalism from the developers?

Only until consumers get fed up with everything from their TV to their coffee maker spying on them and start demanding IOT products that don't actually connect to the Internet and instead interact with a local gateway device. That may never happen, but the barriers to making all your gadgets cooperate and speak the same protocol instead of requiring vendor-specific apps are definitely getting lower.

Serious tools shouldn't do this. Sure, you can offer an opt-in rapid release beta update option, but if you can't go more than a month without forcing me into a "stable" update that changes the UI and behavior I'm getting used to, then I'm not going to consider your software stable and reliable enough to be worth developing expertise in using.

You say that Windows is fine if you have a whole IT department taking on the burden of fighting against the annoyances, but then accuse people who complain about those annoyances of regurgitating second-hand complaints!?

You don't even need to upgrade your system. You just need to be willing to install another newer Python alongside whatever versions you already have, as a dependency of whatever newer tool you want to run.

If python interpreters masqueraded as versioned .so libraries, we probably wouldn't even be having this conversation, because having multiple versions of those lying around is ancient precedent.

If you're writing or packaging software for a specific OS that bundles an old Python, then there's sometimes a reasonable argument for wanting to retain compatibility with that old Python. But now that uv has started bringing some sanity and relative ease to Python package management, it's not much hassle for end users to start running a Python newer than the one shipped by the OS when they want to use a tool or library that requires a newer Python or performs better on a newer Python.

> But I don't see any models with Iris and a dGPU

I don't remember exactly what the chip options were back then, but currently Intel enforces that by ensuring that the laptop chip with the larger iGPU doesn't actually have enough PCIe lanes to connect a dGPU.

Hot-swappable memory is probably much more common in mainframes than mainstream servers. A typical x86 server still requires you to power it off before replacing DIMMs. Meanwhile, NVIDIA and AMD have both recently done some rather Apple-like server processors that solder CPU, GPU, and RAM to the same package/module.

Does it really? When systems get 5+ years of supported OS upgrades, it doesn't seem like the annual OS release cycle is driving users to upgrade hardware in any meaningful way. If anything, the hardware update cycle is driving the software update schedule, because there needs to be an OS to run on the new hardware when it ships. This is especially apparent for the iPhone.

If Firefox isn't responsible for rendering the menu bar, then Firefox doesn't own the menu bar. It sounds like what you're describing is a process where Firefox tells the OS what items it wants the OS to put in the menu bar. Whether or not the app provides a new set of top-level menu entries during a window switch, it still seems to be entirely the responsibility of the OS to actually manage the rendering and respond to user interaction, including the OS keeping track of which top-level menu should be rendered as selected, and the OS should be enforcing that there's only zero or one selected menu.

> Firefox bugs are bugs in Firefox. (I also keep experiencing the stuck menu bug, but again, Firefox bug.)

Glitches in context menus could theoretically be just Firefox bugs. Glitches in the global menu bar can't be just Firefox bugs. Those pixels don't belong to Firefox. It shouldn't be possible for an application to cause the OS to lose track of which menu the user has open in the global menu bar. Even if Firefox is buggy here (quite likely), there's clearly a deficiency in the OS itself, too.

The problem with stating that 27 is an improvement over 26 is that it's ignoring the elephant in the room. It doesn't make any sense for the conversation to just stop there, and implicitly forgive all of the regressions 26 brought as water under the bridge. macOS 15 isn't just some nebulous hypothetical alternative, it's a readily-available example of what Apple actually shipped in recent history, and it should be a point of reference in discussions like this. Narrowly focusing on 27 vs 26 while ignoring 15 doesn't make any more sense than praising Windows 8.1 for fixing some problems from Windows 8 when neither was worth upgrading from Windows 7 for most people.

I don't usually see Claude leaving comments that are obviously out of date compared to the code. The problem is that the comments are just a dumping grounds for Claude's stream of consciousness, verbosely recording random bits of history and context that are true and at least somewhat relevant, but without cohesively explaining why the code is the way it is. And some sentences in the comments will be beginner-style restating what's obvious from reading the code.

Source? I don't know what happened for the Linux drivers, but the Windows drivers definitely booted and ran benchmarks without ReBAR when the Arc A380 launched, because there were lots of published comparisons of the performance impact on workloads that definitely didn't fit in 256MB.