AbacusAvenger

Personally I have two major issues with macOS: CPU usage and bugs.

There are a ton of background services that periodically spin up for no obvious reason, consuming a ton of CPU for a few minutes at a time, then go back to idle. I don't know what they're doing or why. Luckily since they're background services, they're bound to the efficiency cores on Apple Silicon, so they don't hurt battery life or thermals too much most of the time.

And as far as bugs go, the worst part is that bug reports through the Feedback app go largely ignored and bugs seem to keep accumulating. Even for bugs with clear and well-documented repro cases, Apple doesn't seem to pay any attention.

I'm a game developer, so the majority of my bug reports come from issues I've experienced with the graphics drivers or with Xcode. Here's a few examples:

- On macOS devices with > 60Hz displays, there is some awful stuttering with Metal apps in full screen mode. For some reason, CAMetalLayer nextDrawable sometimes just takes a very long time whenever it uses direct-to-display mode for presentation. That mode is implicitly enabled for full screen Metal apps, in order to bypass the display compositor and theoretically reduce latency. This bug also applies to MacBooks with the built in "ProMotion" (120Hz) displays. I'd be perfectly happy if there was just some flag to say "don't use direct-to-display", but if there is one, it's not documented anywhere. I haven't found a workaround yet. I originally reported this in August 2022. Apple replied once in October 2022 to say "we can't reproduce this, please provide a demo app". I provided the app that reliably reproduces the problem within an hour of their reply, but they've been silent since.

- Metal and OpenGL (the latter is emulated via Metal on Apple Silicon Macs) both exhibit a bug with triangle merging that causes partial derivatives to go very wrong along primitive edges. There's a usable workaround for this on the Metal side (just enable a [[sample_mask]] even if you're not doing multisampling). There's no such workaround for the OpenGL side, unfortunately. I was able to work with Asahi Lina to fix this for Mesa on Asahi Linux, and the fix itself was actually really trivial and didn't require a sample mask hack (it took a lot of debugging to figure out, though -- but that's how reverse engineering goes). To solve it, Apple would simply need to set a particular bit to disable triangle merging whenever the fragment shader uses derivatives. I reported this issue in December 2022, and Apple hasn't replied.

- This one is not as egregious as some of the bugs I've reported, and the Xcode team has responded reliably in the past. This is the first Xcode bug report I've had where they didn't acknowledge the report within ~14 days or so. In the current Xcode beta, using the graphics debugger will suspend the app but hitting "resume" leaves the app stuck suspended. The normal application debugger path does not do this, just the graphics debugger. I reported this in mid-June 2023, but haven't heard anything yet.

Amazon would still be in charge of enforcement, they'd just be held liable for not doing so. Which is not a pleasant place to be, because blocking automation is not an easy problem, and it's difficult to measure success.

It's more than that, it's the official conformance tests:

https://github.com/KhronosGroup/VK-GL-CTS/blob/main/external...

Also remember that native code can use multithreading, so if your challenge is something that could be farmed out to multiple CPU threads until one finds the solution, that's another factor in favor of native code performance.

About the benchmark data:

It looks like your pow_sha256 library is using is the "sha2" crate, which is a pure Rust implementation of SHA2. So your benchmark is around the delta of your library compiled to native code vs. your library compiled to WASM, which is an interesting benchmark but I don't think it answers the right question.

A more interesting benchmark would probably answer the question "what would those looking to defeat mCaptcha use and how does that performance compare?" So perhaps an implementation of an mCaptcha challenge solver using OpenSSL would be warranted for that.

I looked into doing something like this once and decided it wasn't going to be very effective, for a few different reasons.

JS engines (or even WASM) aren't going to be as fast at this kind of work as native machine code would be. Especially when you consider that libraries like OpenSSL have heavily tuned implementations of the SHA algorithms. Any bot solving a SHA-based challenge would be able to extract the challenge from the page and execute it using native machine code faster than any legitimate user's browser could. And if you increase the difficulty of the challenge, it's just going to punish real users running the challenge in their browser more than it would the bots.

It's also based on the assumption that proof-of-work is going to increase the cost of doing business for the bots in some way and discourage their behavior. Many of the bots I was dealing with in my case were either using cloud compute services fraudulently or were running on compromised machines of unknowing people. And they tended not to care about how long it took or how high-effort the challenge was, they were very dedicated at getting past it and continuing their malicious behavior.

There's also the risk that any challenge that's sufficiently difficult may also make the user's browser angry that a script is either going unresponsive or eating tons of CPU, which isn't much different from cryptocurrency miner behavior.

That's Numberwang. (Wordwang?)

I've been running it for almost a year, using docker-compose. It seems rather unstable for me. Every week or so, Sentry will just stop handling incoming events, and the request queues just keep growing. And if you try to upload symbols in this state, it will pause forever when trying to process them. So I've got a script[0] I can run that will unbreak it, but I don't fully understand what it actually does (I cobbled that script together based on a GitHub issue[1] that described the same problem). The Sentry architecture is complicated and not trivial to debug.

When it works, it's pretty good. I'm using it with sentry-native on the application side, which uses Crashpad to capture stack traces of native binaries (x86/ARM, Windows/Mac/Linux, whatever). It often doesn't deduplicate events properly, and the stack trace qualities vary dramatically by platform. Sometimes the stack traces it provides are total nonsense, but it does allow downloading the minidump files, so I can dig at them in Visual Studio and see what's really going on. I have discovered and solved many real bugs using it, so I've put up with the frustrating stability issues.

[0] https://gist.github.com/tycho/4279ce2ca47b293a85696695968263...

[1] https://github.com/getsentry/self-hosted/issues/478

It could be an ANGLE change responsible. I know Apple's been working on the Metal rendering backend. Maybe something in that is breaking for you.

I'm not sure if the video represents what's going on perfectly, but it appears like maybe it's reading old data from an improperly cleared framebuffer or something?

I swear, the guy must be a genius.

Out of curiosity, what are the WebGL bugs you ran into?

I had a very similar pattern happen a year or so ago on one of my bank debit cards. The difference in my case was that they made one fraudulent charge on the card beforehand to lend authenticity to the "we're the fraud team" claim. They knew the card number, and the details about the charge (presumably because they were the ones who made the charge). Then they tried to reset the password for my online banking login and asked me to read the security code I received via SMS to confirm my identity. Luckily the code sent to me was clearly labeled as a password reset code (though not with the "we won't ask for this code over the phone" line), so I froze the card and went down to my bank to talk about it. Apparently it had happened to a lot of my bank's members, and I was one of the few to not fall for it.

"Discrete TPM" means you have a daughter board that you plug in to a physical TPM port on the motherboard (check your motherboard manual for where it is, and which kind is compatible). If that device is physically not actually there, then that BIOS option does nothing for you.

You should check and see if the "Firmware TPM"/"fTPM" option is available, because that one will work without the physical add-in card.

Whoah, that's news to me.

I used PostgreSQL fairly recently (a year or so ago?) and ended up abandoning it after I was forced to do the export/import dance through a few version upgrades.

When did that requirement go away?

Gallium, Indium, and Tin, I believe.

The CN is "*.transip.nl" instead of "timetagger.app" for some reason.

The Nest endpoints are returning 500 as well.

I don't have much to add here, except to say that this really matches my experience with Wave G.

Wave G's support team also doesn't even realize that the CondoInternet network they acquired provides IPv6, and when asked about IPv6-related issues they just say "oh we don't have IPv6 yet" which is nonsense. I really miss the local CondoInternet support people. They were amazing.

Yes, their IPv6 support has been mediocre.

The big advantage to Wave G is that they have symmetrical gigabit download/upload rates. Comcast, on the other hand, provides gigabit download rates but ~30-40Mbit upload rates.

They only announce a /64 prefix via RA (with no DHCPv6 or DHCPv6-PD), so address assignments are via SLAAC. For that ISP (Wave G), I use NDP proxying to allow the LAN side to utilize those addresses as well.

The major problems I've run into with IPv6:

- Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this).

- My dhcpcd.exit-hook script is becoming a monstrosity to maintain the prefixes and routes for two different ISPs. With NDP proxying I need to have routes with metrics defined or else the LAN-side IPv6 global addresses are inaccessible to the outside world. I also need to maintain route advertisement configs for these prefixes via either radvd or dnsmasq (and need to restart the relevant services when those prefixes change).

- Prefix deprecation route advertisement (i.e. when one global address prefix is no longer valid because that ISP went down) is difficult to implement properly. dnsmasq refuses to advertise a prefix (even with 0 lifetime to mark it deprecated) if there isn't an address for that prefix on an interface -- and tools like dhcpcd will remove those addresses automatically when the WAN-side interface goes down or the RAs expire, etc. radvd can deprecate all advertised prefixes on shutdown/restart, but that's not entirely desirable either.

- Multihoming has no truly good solution right now. If you advertise two different global network prefixes (e.g. for different ISPs), then the individual client nodes decide which source address to use via the "longest common prefix" match (RFC 6724). This implicitly decides which ISP their outbound traffic will go through. The problem is that these individual clients are poorly placed to make those kinds of route decisions. With the two ISPs I have, some remote hosts exhibit better behavior (i.e. higher raw throughput, lower loss, lower latency, whatever) with one network or the other. With IPv4, I am using NAT and doing load balancing across the two ISPs (round robin selection basically). I also have some hard rules on the IPv4 NAT side about which network to prefer for specific remote addresses. With IPv6, I could do the same approach (via IPv6 ULA + NAT), but that defeats the main advantage of IPv6 where everything can have global addresses.

- Debugging IPv6 problems can be a pain, because you have to check several more moving parts than with IPv4. Route advertisements, neighbor advertisements, DHCPv6, routing tables, IGMP/multicast snooping (which on some NETGEAR switches will drop IPv6 multicast traffic necessary for advertisements), etc.

My apartment building had a very brief (less than a few seconds) power outage at the time 1600M seconds rolled over. Weird.

Out of curiosity, do you know of any implementations where ssize_t has that kind of range limitation?

How many applications are left that still use Mercurial? I can only think of two big ones, the JDK and Mozilla's entire code base. Are there still others around? Seems like everyone's moving to Git these days, which is great considering I never did get the hang of Mercurial.

> The KDE desktop environment has been updated to version 5.18.4.1.19.12.3.

Is that... actually the version number? I thought KDE just used a 3-part version number (major.minor.maintenance or something).

Does not work in what way? Doesn't report anything, reports incorrect values, what?

It seems to be working fine for me on kernel 5.5.0 on a 3800x and on a 3950x...

Neat find. Clang seems to be consistent about it in all 3 cases though: https://godbolt.org/z/iH7ydo

Deletion doesn't mean the data is actually gone from disk though, so it would basically leave unencrypted evidence of incognito browsing history. There are multiple use cases for incognito, and tracking inside the browser is only one of them.

Presumably the investment in MacOS applications. Switching from Mac to whatever else would require finding replacements for those.

I don't think they'll back out of RF tech entirely. The best WiFi chipsets I've used in recent years have been Intel-vended, and they're broadly used.

On the other hand, I've been bitten by Broadcom WiFi chipsets too much recently -- two different laptops with different Broadcom chips having a variety of different connectivity problems. One of them would spontaneously drop the WiFi connection when doing a TCP streaming workload (downloading a large file via HTTP/HTTPS). Admittedly this was probably some kind of driver issue, but I wasn't excited about the prospect of using an out-of-tree driver on Linux to solve the problem (and that didn't help my Windows install either). I swapped the mini-PCIe boards out with some Intel wireless cards and they've been running perfectly since.

But of course, if the rest of the business suffers, they may have to make cuts all over the place. I just hope the WiFi stuff doesn't end up on the chopping block or the competition improves.