The save dialog, albeit a little shakey, is nowhere as chaotic as in your example. The buttons in Notes move between panes in a perfect seamless manner. Albeit the animation occasionally glitches out when you repeatedly focus and deselect the Safari bar, the cursor is perfectly timed with the text, only fading in after the text is done moving to the left. The Preview bug must be something recent too, I can't reproduce this.

https://streamable.com/kx7op6

I miss it when companies like Apple, Sony, and IBM paid attention to the smallest details. Apple in particular earned its current valuation with the iPhone, an all-touch device that did nothing extraordinary compared to Windows Mobile and Symbian PDAs of the time (and was in fact functionally lagging behind compared, failing to even match the then-contemporary feature phones in some areas) BUT one that you didn't actually want to smash against a wall after a few minutes of use. Now these animations are bringing back exactly the Windows Mobile and Symbian vibes.

Remember how happy Steve used to be with OS X animations? He would replay them on stage multiple times, in slow motion. These though, these would have the people behind them face the fate of the iPhone 4 antenna man.

Not sure if I should take this as a joke or a sign of an internal power struggle. If it's the former, there's still some catching up to do before you can match Samsung's "Upcycle", but you're on the right track.

Combine that with the operator's rather obvious lack of understanding of what DN42 is revealed at the end, and you get the bigger picture.

> I doubt multiple routing tables are a problem.

The lack of them is a limitation for me (complex VM + VPN setup), which requires me to do pretty unholy static routing and address rewriting with pf.

I think even Apple has come across this; they added "scoped routing" (which IMO is a hacky workaround providing some of the functionality you'd get with multiple routing tables) just before iOS shipped with MMS support. Android, for comparison, uses Linux's routing policies and tables to send and receive MMS.

If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.

That being said, my point isn't that Apple should absolutely focus on making a server OS again. It just saddens me how far behind macOS has fallen as they stopped caring about the fundamentals; back in the day, it would be Linux trailing behind macOS. Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard, and what Apple happily shows off on WWDC is a wrapper around Linux. Something functionally equal can be cobbled up together by anyone sufficiently experienced in minutes, using just Bash, OpenSSH, and QEMU.

I really wish macOS would let me have a similar level of control over applications as Linux with namespaces, without me having to do all the heavy lifting.

A lot of other Python implementations don't have the ability to spin up new processes at all too.

Rsync has to be one of the worst spaghetti projects I've worked with. It's an incredibly decent tool built around a well-though out algorithm, but its code is an exact opposite of what you'd expect. And it's written in C.

I'm not surprised letting Claude loose on it for roughly 2 months already caused visible breakage. The question is, with it being very obviously a bad idea, can the maintainer still be trusted if he let something like this happen?

If our hypothetical developer hasn't used any accessibility-related tags before, what chance is there that those parts of the website will receive adequate testing?

The end result is more crunch and a sharp decline in software quality, maybe even job satisfaction in general. As an (unfortunately anecdotal) example, I started to find myself fixing up broken websites or removing elements that get in the way with dev tools and uBlock every once in a while, and have heard from other people on here that they have been doing the same (https://news.ycombinator.com/item?id=47042747). All to restore basic functionality of websites I go on. This was never required back in the day, Flash and early web browsers didn't even have the option to do this.

Another, less anecdotal example from a while ago: https://news.ycombinator.com/item?id=47390945

It gets worse when you realize that most of the money saved through these cuts only benefits the very top of the hierarchy.

Wow, is this how things were before bureaucratic behemoths took over the tech industry?

At the same time, I very much dislike the layout. Masonry-style layouts, at least to me, feel more "artsy" than practical. Multiple rows being displayed at once, with the most crucial information being chaotically all over the place instead of arranged in a way that makes it easy to scan it with your eyes, make me feel like I'm bombarded with information. It's very hard to follow along and very easy to miss articles; almost anxiety-inducing, even. There's hardly any point to this on a website; it's not like you're wasting any paper.

https://uefi.org/specs/UEFI/2.10/22_EFI_Byte_Code_Virtual_Ma...

It also looks like there's a slight difference in the unwanted effect both companies have reported, despite the bug being seemingly triggered the same way (mov touching the high byte):

- Oodle reports that a low byte is occasionally stored in the intended location.

- Mozilla's fix suggests that a full 16-bit value is stored instead, corrupting an adjacent variable! This could have much more serious consequences.

Technically, this could still be the same exact bug. I found no mention of the order the output buffer was accessed in by the Huffman decoder debugged in the Oodle report, and, since it was a contiguous buffer, it's easy to mistake an occasional out-of-bounds copy there for a copy from a wrong location. But if both analyses are correct, the behavior of high byte accesses on Raptor Lake is way less predictable than those fixes suggest. Haven't managed to find an official erratum from Intel.