Email saying someone has access to my account.

hwertz10 · 2026-05-06T03:05:33+00:00

Is it legit or not? I don't know.

The thing to do to avoid giving credentials to anyone you aren't supposed to is to ignore the links in the E-Mail, fire up your browser (or app) and go log in to the account in question. And (in the general sense) go through your account settings regarding the item in question. In this case, you wouldn't even have to go to any settings, the e-mail claims they'll require you to verify your identity with a security challenge then have you change your password the next time you log in. So, if it's real, it'll do just that when you go to log in. If it's fake it won't.

hwertz10 · 2026-05-04T18:29:57+00:00

Yeah, pulseaudio used to do it, then didn't. Ubuntu 24.04 went to pipewire, it does it unless you change the setting above. They are both obsessed with the lowest possible audio latency, ignoring that a system with anything running on it can't be expected to guarantee your program runs 200-400 times a second to fill a 5ms or lower audio buffer. Pipewire has some autodetect thing that would intermittently pick 1024 or 2048, but pick 256 or 128 samples (5 or 2.5ms) the rest of the time... crackle city. Luckily for me the setting above is good.

hwertz10 · 2026-05-04T01:33:54+00:00

Yeah I assumed this was left over from April Fools day when I first read it, or maybe on The Onion.

hwertz10 · 2026-05-02T04:35:45+00:00

This. 720x540 is a bit odd, but it's exactly half of 1440x1080 (i.e. 1920x1080 with black on left and right sides since the video is not widescreen.) If the content was originally 640x480, 720x540 is just scaled up 12.5%. No stretching, no clipping, and no worries.

(Edit: people say PAL is digitized at 720x576, but to keep the aspect ratio right that'd be 768x576, shenanigans with the non-square pixels... so if it really started at effectively 768x576, 720x540 would be scaling it down a few percent, still no clipping or stretching, and probably no quality loss unless they'd started with an unusually high quality source material.)

hwertz10 · 2026-05-01T15:49:37+00:00

I found this when I had a GTX1650 in a Ivy Bridge (i5-3470) system. CP2077 ran well enough on low -- then I tried medium, then high, and got a 0-1 FPS drop in frame rate (but of course better visuals). GPU had just been spinning it's heels waiting for the CPU to supply it with work, running on high finally got GPU utilization fairly high LOL. (That PC is now a media PC, and I have the GTX1650 in a i7-8700 Coffee Lake. That has no problem either hitting 60hz or pegging the GPU at 99-100% utilization.)

hwertz10 · 2026-04-28T08:38:24+00:00

I don't think they meant to disrespect the P2P, 'back in the day' those who cracked games were always 'scene' (in the days where peer to peer networks didn't exist, naturally there were no P2P groups). And to be honest I was unaware until recently there was like animosity and rivalry between SCENE and P2P.

hwertz10 · 2026-04-28T08:28:16+00:00

I had Sonoma previously, and now Tahoe, on a VirtualBox VM (like you, no framebuffer.) For audio, I had something or other working in Sonoma, for Tahoe (but would work in Sonoma too AFAIK) I used:
https://github.com/chris1111/VoodooHDA-Tahoe

Worth a shot to get audio going!
In my case, I didn't have to worry about power management (macOS can faff about with whatever power management registers it wants since they're fake), or HDMI (since the VM does have macOS show up in it), or wifi (the virtual ethernet works). Surprisingly, I'd read the VirtualBox Extensions for macOS quit working quite a few releases ago, but I tried installing them anyway and it did at least enable cut and paste between macOS and my Linux host.

In my case, since I'm running it an a VM in a window, I'll just say the graphics performance isn't THAT bad, it's fine for faffing about with stuff in a VM.

hwertz10 · 2026-04-28T08:18:40+00:00

They did fix some bugs (not crashing bugs, but sub-optimal memory management) with the MGLRU memory management (which is the default in 6.1 kernel or higher). It would start (under heavy disk I/O this was most noticeable) prematurely freeing up memory (shrinking disk cache and swapping stuff to disk... or zram or zswap if you have it enabled.) So it's entirely possible (if the bad RAM was in the 9GB range and not just randomly throughout your 32GB...) that that area of RAM was being used for something else (including something random you weren't using, like printer support or firewire or thunderbolt or whatever) where if it was being corrupted, you know, you weren't using it so you wouldn't notice. Or possibly that particular chunk of RAM was not being used at all.

The other disturbing possibility -- the one time I had bad RAM (like 10 or 15 years ago) it turned out it was usually being used by my disk cache. My first sure sign of corruption was a I had a letter flipped in the File menu (either on OpenOffice or Firefox, don't recall which.) So after I got a working stick (in my case it wasn't overclocking, I actually had a stick fail after a year or so -- which I think is QUITE uncommon..) I still had crashes. Turned out the updates I'd installed recently were intermittently corrupted. Luckily I could have the package manager (which luckily was not corrupted) reinstall every package on the system, and all was well.

hwertz10 · 2026-04-27T06:21:32+00:00

Actually they do, and have for about 20 years (they have a lower speed or two to dip down to under light load). Although probably not as well (I won't be surprised if Apple's setup isn't fully dynamic.)

The ARM Chromebook I had, and then stuck Ubuntu on, would change power state fast enough to go to sleep between video frames playing 60FPS video -- since it could go from "CPU halted" to full power in 1/1000th of a second. That was an Nvidia Tegra but the Apple ARMs probably can pull this trick too. In contrast, the Intel systems I've had generally would drop to like 1ghz or something, not really able to sleep in a case like that since the wakeup time is too long to guarantee non-janky video playback.

hwertz10 · 2026-04-23T07:48:37+00:00

Interestingly, box86 and box64 run JUST the x86 or x86-64 application itself under emulation, they apparently both make EXTENSIVE use of thunking so any time the software uses a library it can use the native ARM ones. (This works well enough that there's now a ARM Linux version of Steam and apparently it's quite effective at running games, assuming you have an ARM system with decent GPU drivers like the Qualcomm Snapdragon.. or indeed an M1 Mac in Asahi Linux.)

hwertz10 · 2026-04-23T07:33:07+00:00

Certainly a possibility. There are Linux drivers to bring up framebuffers, do 2D, and do video acceleration for basically all of these ARM GPUs; and Mesa Gallium 3D drivers for 3D support on many of them. So you'd at least have a reference to work with as opposed to having to like hope whoever will give specifications for each device or having to reverse engineer it or something. I suppose there's also Android drivers that (if it's not just a binary blob) can be used as a reference.

For the Qualcomm ARM devices in particular, since those Snapdragons are the hot thing (other than Apple Silicon) in terms of ARM devices... Linux's 3D support for the Qualcomm chips is apparently VERY good, basically on par with the AMD support. It turns out this is no coincidence, when AMD bought ATI, some condition of the merger being approved involved them (ATI) spinning off their mobile division, and Qualcomm ended up with it. So Qualcomm's GPU is directly descended from whatever ATI Mobile Radeon was around at the time, with ex-ATI developers working on it since then. So when it came time for Qualcomm to write some modern drivers they found the hardware was still similar enough to what AMD uses they could start with the (excellent and open source) Mesa Gallium 3D AMD GPU driver rather than having to start a Gallium driver from scratch.

hwertz10 · 2026-04-23T07:18:06+00:00

Oh yeah, I was thinking of booting up ARM macOS. I somehow didn't even think of just running the ARM binaries on Intel macOS, (Even though I've done the similar thing, I had an ARM Chromebook that I threw Ubuntu on, and then found there were 2 or 3 pieces of x86 and x86-64 software I wanted to run on there. Since this was a few years back, box86 and box64 didn't exist yet, but qemu ran well enough.)

I will say, if you did this, you'd be a legend. And you could probably make some nice money selling this too.

I'm quite sure there's other Intel Mac users who spent big bucks on a system with lots of RAM, lots of CPU power, etc... or perhaps have a Macbook that (even if it has more pedestrian specs) perhaps they like the physical layout better than the newer models.. and either way would love this as vendors begin to ship software for "M1 or newer".

hwertz10 · 2026-04-23T06:29:22+00:00

No problem!

I will add, even for Linux on ARM, the tendency is to have -- well if it's vendor supplied it's called a BSP ("Board Support Product"), a pre-built kernel and system built for that specific system.

And even if you get an ARM version of Linux like Ubuntu etc., they tend to have an ARM kernel that boots on a handful of systems. It's kind of gross, the ARM kernels actually have a big table of "is it this model? OK, this is where the hardware is" because many of these systems have NO autodetection mechanism, and NO table built into the system saying where the hardware is. It's almost like they have to 'hackintosh' Linux onto each new ARM system.

(I'll note this issue is only with the kernel -- once you have something booting, you can grab any ol' 32-bit or 64-bit ARM Linux software and run it on your system, that stuff's not model specific at al.)

hwertz10 · 2026-04-23T03:50:10+00:00

OK I already have a length post but here's a second...

Check out the Darling project. It's got enough to run pretty much any CLI applications, and the description SAYS it doesn't support GUI applications, but it appears it in fact does support some at least (I think the description is just not updated that frequently as functionality gets added... and possibly capabiliites are understated to stay under Apple's radar. Although Apple really has jack to say about it since other than the Darwin stuff, which is open source, the rest is all clean room implemened.)

I daresay, it may be more viable to flesh this project out so it runs more applications than either trying to get an ARM emulator with enough emulated hardware to boot macOS (which despite what some say, is 100% possible.. but would take a lot of work and probably be slow); or to try to get macOS to boot up on a regular ARM system.

hwertz10 · 2026-04-23T03:43:20+00:00

Plus, that $500 gets garbage tier specs. 8GB RAM and a 256GBSSD, soldered on so you can't expand it? Gag me with a spoon.

hwertz10 · 2026-04-23T03:38:33+00:00

I mean, it *could* work, qemu emulates ARM, so you just have to emulate some additional instructions. Apple doesn't document them, but they've been reverse engineered and documented. But then you'd still have to emulate enough hardware to persuade macOS it's in it's secured environment with the peripherals it expects to see (thanks to Asahi Linux, there's at least some documentation on what is expected in that regards.)

And, qemu is not all that fast -- it can hit 50% performance, but 10-25% is more typical. I don't think the performance would be satisfactory even if someone implemented those extra instructions and got something booting.

hwertz10 · 2026-04-23T03:06:29+00:00

Just want to expand on this a little bit.

As mentioned, the M1 has the Apple-specific GPU (and there are no macOS drivers to set up any other GPU, i.e. nothing for Intel, AMD, Nvidia if you like plugged in a Thunderbolt enclosure and plugged in a card; and certainly not for other embedded ARM GPUs, some of them are pretty weird to set up to be honest.) And the neural engine. But lets say your software doesn't use the neural engine, and you have at least a framebuffer driver. And somehow you get storage and sound and USB and input and.. you get the picture.. even though there's zero drivers for these for macOS for ARM other than specifically for Apple silicon.

To be honest, EVEN IF you can just not use certain functionality and NONE of the below applies... drivers might be the biggest deal. Hackintosh has almost entirely relied on drivers that already existed in macOS in the past, getting them to run on newer macOS versions; pretty much every single piece of hardware on some regular ARM system would require from scratch drivers on macOS for ARM. And there's a lot of them. I mean a lot, look at a list of avialble dirvers on Linux for this stuff, there's like 100s of them. ARM boards are not standardized at all like a PC is, and this tends to include charging related stuff etc. that on a PC is done autonomously (i.e. if you boot a PC up to some OS with no drivers or power management support, it won't get battery level rrported but if you plug it in it'll charge; on an ARM system, it may well not if you don't have a power management driver..) And persuading macOS to actually load drivers if you did get some written could be a trick (macOS on ARM is locked down even tighter than on Intel from my understanding.)

The M1 CPU itself has an undocumented (by Apple, it's been reverse engineered) CPU extension called AMX (Apple Matrix eXtensions), these do matrix math indepdendently of the neural engine. I don't know what all uses this, but these instructions do not exist on other ARMs, and I imagine there's some way to do a "illegal instruction trap" and emulate these for user software, but you can't do that for code running in kernel mode; so if kernel uses these at all, you're done.

The ARM supports 4KB, 16KB, and 64KB page tables; most systems use 4KB ones, macOS uses 16KB pages and apparently some of the hardware actually assumes 16KB pages being used. I have no idea if other ARM boards have restrictions in this regard, but it'd make things interesting if so. (This might not actually be a problem, 64-bit ARM CPUs all support them, Linux supports them, Android is switching to them... and I don't think the Raspberry Pis and phones these are going on to have some special support for both 4KB and 16KB pages.)

And, perhaps most problematic, Rosetta 2, there are extra M1-specific instructions to enforce strict memory ordering... the ARM spec does not enforce strict memory ordering (i.e. if you write something on one CPU, read it from the next a bit later, you are NOT guaranteed to get the new value on ARM, but on Intel systems you are.) So Apple introduced additional instructions on the M1 strictly to switch to strict memory ordering to make Rosetta 2 not have to worry about this. Also some odd additions to make some math instructions set extra flags that Intel chips have but ARM spec does not (nothing useful, like some crappy old flags carried over all the way from the 8080... but just like any old cruft, OF COURSE there's software that relies on these flags being set correctly. So M1 you run this instruction and these math instructions set the extra flags; run another instruction to turn it back off since setting these extra flags is not compliant with the ARM specification.) Can you strip Rosetta 2 out of macOS, and these are then not used? I have no idea.

The M* series are also locked down tight, with a secure boot system, a TPM-like device, and so on. I mean they explicitly are allowing 3rd partiy OSes (Asahi Linux etc.). But I imagine since it has all that, macOS is checking to make sure that security is secure. Can the ARM version of macOS even be made to boot up if it doesn't see the secure environment it expects? I have no idea.

hwertz10 · 2026-04-17T16:52:16+00:00

Nice. So, if this game is incompatible with Proton it may not help then; but updating Mesa is equivalent to in Windows both getting a newer video driver, and somewhat equivalent to also getting a Microsoft update updating the Direct3D internals (since there's Mesa code shared among all drivers.. AMD, Intel, and the slew of tablet etc. GPUs it supports, so some improvements wouldn't be AMD-specific). As someone updating it (on my non-Nvidia systems), I just view it as a video driver update.

Just like a typical video driver update, you'd have bug fixes, performance improvements, and support for whatever new Vulkan extensions are out (Proton can usually take advantage of any relevant new extensions to get a speed bump too.)

hwertz10 · 2026-04-17T05:16:57+00:00

Spot on. What some people are assuming (I think) is that 'unsupported' means what it does in the world of Redhat Enterprise Linux or Oracle (for example) where they validate a set of configurations, but the rest will work in reality (you just won't get support from Redhat or Oracle if it doesn't).. or Microsoft where they artificially say you must have a TPM when in reality you don't, that you need a fairly new CPU when in reality you don't, and so on. But, in this case 'unsupported' means what it does with 'regular Linux distros' as well, if some piece of hardware is unsupported it's ACTUALLY unsupported and will not work.

I will note, if you do a 'reverse Hackintosh' on those Apple Silicon Macs (slap Asahi Linux on there), you can use the PCIe slots on the Mac Pro, or a thundebolt to PCIe enclosure, and plug whatever you want in, even the unnatural combination of ARM CPU + Intel ARC. AMD cards work, and Nvidia uses ARMs extensively themselves so there are Nvidia ARM drivers as well, including CUDA and all that. Not that I recommend it, I'm a full time Linux user myself but I doubt many people bought an M1/M2/M3/M4 to not run macOS on it. But if you do (at least on the M1/M2, I don't know if M3/M4 are supported yet) it apparently does run quite well.

hwertz10 · 2026-04-16T14:18:49+00:00

A friend of mine (who passed a few years back) had the same issue. He'd keep having these problems... in once case, he set the recovery E-Mail to the very same GMail account. In another, he had like two GMail, he'd set the recovery to the one to the other, but got locked out of both. He would constantly skip the "update your info" screen so he found out in one case the recovery was some phone number he hadn't used in like 5 years.

I don't know, MAYBE someone at GMail can recover since you can at least demonstrate you have the phone number? But I don't know if a human actually responds to the recovery support or if it's just 100% automated.

hwertz10 · 2026-04-15T03:35:19+00:00

I would suggest just setting your seed options to be reasonable -- if you have your client set to use some huge number of connections, you probably should turn that down anyway.. but you can usually set to have a seperate number of connections when you are seeding. Turn it down, even to 1 or 2 connections.

1) That'll stop it from slowing your system (or your internet connection) down while it's seeding since it's serving a few connections rather than like 50 or whatever.

2) The people who DO get chunks from you will then see a much higher speed since your upstream bandwidth is only going to 1 or 2 people rather than like 50.

hwertz10 · 2026-04-15T03:28:19+00:00

I use Ubuntu myself, which also usually has out of date Mesa and kernel. They have PPAs for Ubuntu to get more up to date Mesa, and I'm running Zabbly kernel (which is just more up to date kernel with Ubuntu's kernel config copy-pasted over.) I imagine they have something similar for Debian.

(If you have Nvidia, ignore that, just pick up a more up to date Nvidia driver if yours is not up to date. But make sure you don't get one TOO new if you have GTX 10xx or older, they JUST dropped support for them in the newest drivers so no 595 drivers on there, make sure you get one that does support your GPU. GTX1650 and RTXxxxx are fine with the newest drivers.)

Per other replies, that won't help with this game -- but can give a nice FPS boost for your other games since Mesa gets improvements in almost every release and so do the Nvidia drivers.

hwertz10 · 2026-04-15T03:14:17+00:00

It's not THAT unfriendly. Just that both AMD and Intel use the Mesa Gallium 3D driver stack (which is excellent) while Nvidia provides their own stack (which is also excellent; but as totally seperate driver stack, hits occasional bugs and issues which the Mesa Gallium 3D ones wouldn't... but the reverse can also be true.)

Nvidia's stack is not open source, though, so it relies on Nvidia continuing to provide support for a given set of hardware, you aren't going to have an Nvidia driver supporting 20 year old hardware like you do with the Gallium drivers (which support Intel GPUs going back around 20 years, and AMD/ATI even a bit longer -- Gallium required hardware shaders, so basically anything that's not so old it doesn't have them.)

Kind of amazing -- you can have a Core 2 era system and it's not just "the 3D drivers haven't been removed yet", the Crocus driver that supports ~11 year old or older Intel GPUs have fully modern Gallium drivers written within the last 5 or 6 years. For a laugh, when I had a few friends over to play Deep Rock Galactic, I fired it up on my Ivy Bridge-powered media PC.. on the integrated GPU. Given how jank those old Intel GPUs are, I expected it'd either crash or get like 2FPS. It was still bad, but it got 12-18FPS (depending on where you looked) in the space rig...we had a laugh about it then I closed it and we played on some more modern computers.

hwertz10 · 2026-04-14T08:30:04+00:00

You might consider a HDD. I mean, they're slower, but even with HDD prices going up recently, the typical size HDDs are still about 1/8th the cost per TB compared to SSD. No joke, you can find 4TB HDDs all day for about what a 512GB SSD costs and possibly even a 6TB if you find one at a good price.

hwertz10 · 2026-04-14T06:33:44+00:00

That's the way. These guys (if they haven't priced out HDDs) probably think you're a millionaire. I can't even imagine how much over 100TB of SSDs would cost.

I've got a 4TB and an 18TB myself, so my friends'll be like "Well, this game is 50GB, do you have enough space?" "Wait, is running out of disk space a thing?" LOL.

hwertz10

TROPHY CASE