zorgmonkey

I recommend trying out PulseEffects, my understanding is that EasyEffects is the same project they just did a rename of it. You might be stuck on an older version or something not exactly sure.

If you're after high clocks I think threadripper has usually been the cheaper option than epyc

I don't know exactly how long loading value from a TPM takes, but my gut says it would be much too long to do it on task switch. Almost certainly fine for waking up from suspend though. Also the problem that physical TPMs communicate with the CPU over plaintext and TPMs in general, including fTPMs, have had notable vulnerabilities.

The man page ld.so has ENVIRONMENT section that looks pretty good.

Otherwise one of the most reliable options is to simply grep the source code for calls to getenv, I would not be that surprised if their are some extra ones that are undocumented.

Please just buy a proper differential probe for stuff like this, you definitely don't need the R&SRT-ZHD mentioned in the article. Otherwise loved the article btw.

The 85ms is configurable per-output delay for time alignment. That same file in the docs claims a typical end-to-end latency of 10 to 15ms.

Their have been many vulnerabilities in TrustZone implementations and both Google and Apple now use separate secure element chips. In Apple's case they put the secure element as part of their main SoC, but on devices where that wasn't designed in house like Intel they had the T2 Security Chip. On all Pixel devices I'm pretty sure the Titan has been a separate chip (at least since they started including it at all).

So yes incorporating a separate secure element\TPM chip into a design is probably more secure, but ultimately the right call will always depend on your threat model.

Here's an excerpt about the anti-rollback feature from Nvidia's docs on how the Tegra X1 SoC in the switch 1 boots [0] (called Tegra210 in the document)

> By default, the boot ROM will only consider bootloader entries with a version field that matches the version field of the first entry, and will stop iterating through the entries is a mismatch is found. The intent is to ensure that if some subset of the bootloader entries are upgraded, and hence the version field of their entries is modified, then the boot ROM will only boot the most recent version of the bootloader. This prevents an accidental rollback to an earlier version of the bootloader in the face of boot memory read errors, corruption, or tampering. Observe that this relies on upgraded bootloader entries being placed contiguously at the start of the array.

[0] https://http.download.nvidia.com/tegra-public-appnotes/tegra...

It isn't that wild; the typical name for it is anti-rollback, and you probably have at least one device that implements it. Most Android devices have anti-rollback efuses to prevent installing older versions of the bootchain\bootloader; they might still allow you to downgrade the OS (depends on the vendor, if memory serves). Instead of using efuse counters, anti-rollback counters can also be implemented by Replay Protected Memory Block (RPMB), which is implemented by many flash storage (eMMC often supports RPMB, but other storage types can as well). It is possible to implement anti-rollback mechanisms on x86_64 by utilizing a TPM [0], but as far as I know, only Chrome OS does this.

[0]: https://www.chromium.org/developers/design-documents/tpm-usa...

It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence).

[0] https://issues.chromium.org/issues/40168998#comment507

Pebble watches run on Cortex-M microcontrollers which have less than 1MB of flash storage and RAM, I like Kotlin multiplatform but getting it to run on them is extremely unlikely. I assume that for the foreseeable future Pebble apps will be only written in languages which are traditionally used for MCUs like Rust and C\C++

Yeah working again for me too, they're probably having some sort of server problems

I found a link to the PDF that seems to work https://data.ntsb.gov/carol-repgen/api/Aviation/ReportMain/G...

Also in case that link stops working I got it from this page https://www.ntsb.gov/investigations/Pages/DCA26MA024.aspx

EDIT: nevermind immediately after posting this comment it is now giving a 403 error

They still use gerrit, that site is a code search UI that they have that is also a very nice way to navigate the code.

Rust moves are a memcpy where the source becomes effectively unitialized after the move (that is say it is undefined to access it after the move). The copies are often optimized by the compiler but it isn't guaranteed.

This actually caused some issues with rust in the kernel because moving large structs could cause you to run out the small amount of stack space availabe on kernel threads (they only allocate 8-16KB of stack compared to a typical 8MB for a userspace thread). The pinned-init crate is how they ended solving this [1].

[1] https://crates.io/crates/pinned-init

With enough effort you could definitely do it. Just remember it is a device that came out in 2006 and it has 256MB of system RAM and 256MB of VRAM, at best you're running a quite small model after a lot work trying to port some inference code to CELL processors. Honestly it does sound a cool excuse to write code for the CELL processors, but don't expect amazing performance or anything.

This is a very important point, careful use of GCs for a special subset of allocations that say have tricky lifetimes for some reason and aren't performance critical could have a much smaller impact on overall application performance than people might otherwise expect.

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.

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.

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

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)

libVLC the library is LGPL licensed, VLC the application is GPL licensed. This plugin was of course just using libVLC so it being GPL was not the issue. As you said several other libraries unity uses are also LGPL licensed.

I don't have a mac, but my understanding is that Safari Technology Preview [0] has WebGPU support (might need a change a setting too).

[0]: https://developer.apple.com/safari/technology-preview/

it is worth pointing out that tink has binding for a bunch languages (C++, objective-c, rust, python, go and java) and has support for a bunch key management systems (GCP, AWS and Hashicorp)