It looks like the API of Alloy was at least designed in such a way that can somewhat easily change the GC implementation out down the line and I really hope they do cause Boehm GC and conservative GC in general is much too slow compared to state of the art precise GCs.

It's not an implementation thing. It's fundamental. A GC can't move anything it finds in a conservative root. You can build partly precise hybrid GCs (I've built a few) but the mere possibility of conservative roots complicates implementation and limits compaction potential.

If, OTOH, Alloy is handle based, then maybe there's hope. Still a weird choice to use Rust this way.

We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice.

I don't think Rust's design in this regard is ideal, but then again what language is perfect? I designed languages for a long while and made far more, and much more egregious, mistakes! FWIW, I have written up my general thoughts on static integer types, because it's a surprisingly twisty subject for new languages https://tratt.net/laurie/blog/2021/static_integer_types.html

> We don't exactly want Alloy to have to be conservative, but Rust's semantics allow pointers to be converted to usizes (in safe mode) and back again (in unsafe mode), and this is something code really does. So if we wanted to provide an Rc-like API -- and we found reasonable code really does need it -- there wasn't much choice.

You can define a set of objects for which this transformation is illegal --- use something like pin projection to enforce it.

The only way to forbid it would be to forbid creating pointers from `Gc<T>`. That would, for example, preclude a slew of tricks that high performance language VMs need. That's an acceptable trade-off for some, of course, but not all.

Not necessarily. It would just require that deriving these pointers be done using an explicit lease that would temporarily defer GC or lock an object in place during one. You'd still be able to escape from the tyranny of conservative scanning everything.

If you're curious the only brand I could find easily purchasable in the USA that uses borosilicate glass is oxo. Their are some other results if you do a search on amazon, but I'm not very convinced those are really borosilicate glass.

In Texas, HEB sells its own brand of borosilicate glass cookware which is labeled as such on the front. All made in France.

If you want borosilicate Pyrex, go to church bazaars and yard sales. The old stuff is better anyway.

That seems the case for just about any product these days, unfortunately. In the modern world, all the products are cheaper but they all suck.

You can almost always pay more (and look harder) to get better items, in my experience.

pretty sure marinex is borosilicate too

You can relatively easily check this before buying, just look for the tint (usually best seen on the edges of the glass). Blueish = borosilicate, greenish = soda lime.

Don’t forget glowing green for uranium.

https://en.m.wikipedia.org/wiki/Uranium_glass

afaik that's a myth; the tint depends on other impurities in the glass.

Why wouldn't it be possible? All it really means is that you need to do the work to make incremental entirely on the local side and not on the remote side.

The answer is boring and annoying, they almost certainly want it to work with TVs and cheap monitors both of which commonly only have HDMI inputs. It has been my experience that you typically have to pay more for a USB-C dock with displayport outputs, even though they don't have the chip just cause of economies of scale.

You can make an email you don't care about with protonmail, I recommend them cause they don't require you to enter an existing email address or a phone number when signing up.

yeah EDL loaders for a bunch of production devices exist here [0] also more on various XDA Forum posts for stuff like unbricking guides. It is worth noting for people who don't

[0]: https://github.com/bkerler/Loaders

But reading QFUSES specifically requires an EL3 loader "edl qfp qfp.bin -> To dump qfprom fuses (only on EL3 loaders)" and I don't believe most devices programmers (especially as relatively new as the OnePlus 6) run under that privilege level.

A better resource is https://www.temblast.com/ref/loaders.htm

I haven't tried it out, but it looks they recently added PKCS#11 which should make it possible to use it with devices like HSMs and cloud KMS solutions.

UAC is not a security boundary, it is instead considered a defense-in-depth feature (aka best effort but bypassable). This is officially documented by Microsoft in multiple places. [0] https://www.microsoft.com/en-us/msrc/windows-security-servic... [1] https://learn.microsoft.com/en-us/troubleshoot/windows-serve...

The price of that system is unfortunately going to end up being a lot more than 4k, you'd need a CPU that has at least 64 lanes of PCIe. That's going to be either a Xeon W or a Threadripper CPU, with the motherboard RAM, etc you're probably looking at least another 2k.

Also kind of a nitpick, but I'd call that 8 GPU system, each BMG-G21 die has 20 Xe2 cores. Also even though it would be 4 PCIe cards it is probably best to think of it as 8 GPUs (that's how it will show up in stuff like pytorch), especially because their is no high-speed interconnect between the GPU dies colocated on the card. Also if you're going to do this make sure you get a motherboard with good PCIe bifurcation support.

Sometimes it is a little more work to get stuff setup, but it works fine I've run plenty of models on my 7900 XTX wan2.1 14B, flux 1.dev and whisper. (wan and flux were with comfyui and whisper with whisper.cpp)