Just a point of clarification. I believe the 128GB Strix Halo can only allocate up to 96GB of RAM to the GPU.

108 GB or so under Linux.

The BIOS allows pre-allocating 96 GB max, and I'm not sure if that's the maximum for Windows, but under Linux, you can use `amdttm.pages_limit` and `amdttm.page_pool_size` [1]

[1] https://www.jeffgeerling.com/blog/2025/increasing-vram-alloc...

I have been doing a couple of tests with pytorch allocations, it let me go as high as 120GB [1] (assuming the allocations were small enough) without crashing. The main limitation was mostly remaining system memory:

    htpc@htpc:~% free -h
                   total        used        free      shared  buff/cache   available
    Mem:           125Gi       123Gi       920Mi        66Mi       1.6Gi       1.4Gi
    Swap:           19Gi       4.0Ki        19Gi

[1] https://bpa.st/LZZQ

Thanks for the correction. I was under the impression the GPU memory had to be preallocated in the BIOS, and 96 GB was the maximum number I read about.

Some older software stacks require static allocation in BIOS, but things are moving pretty quickly and allow dynamic allocation. Newer versions (or patches to) pytorch, ollama, and related, which I think might depend on a newer kernel (6.13 or so). Does seem like there's been quite a bit of progress in the last month.

In Linux, you can allocate as much as you want with `ttm`:

In 4K pages for example:

    options ttm pages_limit=31457280
    options ttm page_pool_size=15728640

This will allow up to 120GB to be allocated and pre-allocate 60GB (you could preallocate none or all depending on your needs and fragmentation size. I believe `amdgpu.vm_fragment_size=9` (2MiB) is optimal.

I've been using it in production for 5 years now for an e-commerce website, and a lot of ETL and web apps for work. It runs flawlessly. The only real annoyance I run into is having to have the Rust toolchain installed in order to build the cryptography package.

I'm interested in it. According to the comparison matrix, it's open source and offers encrypted sync.

I currently use Google's authenticator. It irked me that in order to sync codes for work, I then had to also tie all of my personal codes to an account. This seems like a major backdoor for 2FA.

Only recently. They used to require Symantec's authenticator.

> The problem is this: sslmode=require encrypts, but it doesn’t authenticate. It does all the hard work to make sure your communication channel is secured, while doing nothing at all to check who’s on the other end of it.

I fail to see the problem with this. For a general setup within a secure network, dinking around with CAs and certificates is more headache than necessary. You already know the server you're communicating with. The connection just needs to be encrypted.

I think it comes down to these two questions:

* If the network is secure, why do you want to encrypt?

* If the network isn't secure, why don't you want to authenticate?

Encryption without authentication generally seems like a strange combination.

That's a huge disappointment. Clear Linux has been reliably the fastest distro. I'm going to have to find a replacement distro for my Minecraft server.

I've been running Manjaro (Arch derivative) on my System76 Galago Pro (galp5) for 3 years and it runs great. It's 14", light weight, quiet, and has a decent battery. You won't beat Mac's battery life, and if it's Mac's software that you want, Linux cannot provide that. I prefer the Linux ecosystem personally, and cannot stand Mac's interface and window management.

That would be fine if browsers didn't throw up giant warning signs when using self-signed certificates.

Usually you can just import the leaf self signed cert as a CA in your OS trust store and the problem goes away (assuming it has an IP SAN). Slightly tedious but you can issue the certs with long validity

Chrome provides no simple way to trust a self-signed cert. When you go to certificate details, the only option under the "Details" tab is "Export...". The only work around is to click "Advanced" and "Proceed to example.com (unsafe)". Chrome will then helpfully suffer amnesia in 1-3 days and completely forget you want to allow an exception for the certificate.

iirc Chrome uses OS trust store so the trust needs to be using the operating system's facility

That sounds like a defect in the browser design.

Or maybe it's because you actually want an identity to verify (which an IP address is not.)

All that regex does is split an IPv6 address into groups of 4 digits, joins them with ":", and collapses any sequence of ":0000:" to "::". I don't see anything problematic with it.

> and collapses any sequence of ":0000:" to "::"

Which is an error. Any ip like 2001:0000:0000::1 is going to be incorrect. It willingly produces errors. Whoever wrote this didn't even spend a few seconds thinking about the structure of IPv6 addresses.

> I don't see anything problematic with it.

Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself.

It only operates on a 32 digit IPv6 address so it won't already be abbreviated. My phrasing was inexact. It replaces only the first sequence of any number of ":0000:" to "::".

> Any ip like 2001:0000:0000::1 is going to be incorrect.

This is neither a possible input nor a possible output of that code.

That example doesn't work, but an IPv6 address like: 3fff:0020::

Would be in the IP SAN as 3fff0020000000000000000000000000, which this code expands:

   "3fff0020000000000000000000000000"
                .toLowerCase()
                .match(/.{1,4}/g)
                .join(":")
                .replace(/\b:?(?:0+:?){2,}/, "::")
   '3fff::20:0000:0000:0000:0000:0000:0000'

Which has one too many parts and doesn't parse as an IPv6 address. But like mentioned this is just presentation code. I don't want to waste time if this isn't actually a bug, but maybe someone on the LetsEncrypt trial could actually make a cert to see if IP addresses formatted like that are a problem in reality...

That one does look like a bug. I stand corrected.

> Any ip like 2001:0000:0000::1 is going to be incorrect

How so?

> Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself.

It's not. And the sequence you describe is not even parsed because colons are not part of the IPv6 extension of the SAN. PLease educate yourself before spilling such drivel.

If you're going to lie at least make it believable.

> Amazon annual income taxes for 2024 were $9.265B, a 30.13% increase from 2023. > > https://m.macrotrends.net/stocks/charts/AMZN/amazon/total-pr...