operator-name

That partially explains why nobody noticed the change being made 2 weeks ago.

What did your final Nix and Docker file look like, and did you have to use `buildFHSEnv` at all to support the odd 3rd party binaries?

I think Nix really needs some articles outlining how to play well and smoothly transition from an existing system piece by piece.

I'd give this article a read, as it can explain it more clearly than I can: https://serokell.io/blog/what-is-nix

But to briefly answer your specific questions: Docker files are commonly not reproducible because they contain arbitary stateful commands like `apt-get update`, `curl`, etc. For a layer with these kinds of commands to be reproducible you would need a mechanism to version and verify the result.

Nix provides such a mechanism, and a community package repository with versioned dependancies between packages. These are defined in a domain specific language called Nix (text files) and kept into a git repository. This should be familiar if you've used a package manager with lock files before.

You can guarentee the package version will stay in the repository by pinning your build to an exact commit hash in the repository.

This is great if you've already adopted Nix, and I'd love for nothing than more declarative package management solutions like Nix or Guix to take off.

If you're already using Docker but want to gradually adopt Nix, there is an alternative approach outlined by this talk: https://youtu.be/l17oRkhgqHE. Instead of migrating both the configuration AND container building to Nix straight away, you can keep the Dockerfile to build the nix configuration.

The biggest downside is that you don't take advantage of layers at all, but the upside is that you can gradually adapt your Dockerfiles, and reuse any Docker infrastructure or automation you already use.

The capitalisation has just made me realise that it's "Photo Pea" and not "Photo-pe-a".

There's also been a greater focus on reproducibility: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

For some reason it's actually bundling both LLaMA 13b (24.5GB) and Ministral 7b (13.6GB), but only installed Ministral 7b. I have a 3070ti 8GB, so maybe it installs the other one if you have more VRAM?

Having installed this, this is an incredibly then wrapper around the following github repos:

https://github.com/NVIDIA/trt-llm-rag-windows https://github.com/NVIDIA/TensorRT-LLM

It's quite a thin wrapper around putting both projects into %LocalAppData%, along with a miniconda environment with the correct dependnancies installed. Also for some reason the LLaMA 13b (24.5GB) and Ministral 7b (13.6GB) but only installed Ministral?

Ministral 7b runs about as accurate as I remeber, but responses are faster than I can read. This seems at the cost of context and variance/temperature - although it's a chat interface the implementation doesn't seem to take into account previous questions or answers. Asking it the same question also gives the same answer.

The RAG (llamaindex) is okay, but a little suspect. The installation comes with a default folder dataset, containing text files of nvidia marketing materials. When I tried asking questions about the files, it often cites the wrong file even if it gave the right answer.

The source is available, minus the installer. You could always use the base repo after verifying it:

https://github.com/NVIDIA/trt-llm-rag-windows

Yeah, seems a bit odd because the TensorRT-LLM repo lists Turing as supported architecture.

https://github.com/NVIDIA/TensorRT-LLM?tab=readme-ov-file#pr...

I found some official benchmarks for enterprise GPUs, but no comparison data. I couldn't find any benchmarks for commercial GPUs.

https://nvidia.github.io/TensorRT-LLM/performance.html

Last time I used it, LM Studio doesn't include RAG.

This looks quite cool! It's basically a tech demo for TensorRT-LLM, a framework that amongst other things optimises inference time for LLMs on Nvidia cards. Their base repo supports quite a few models.

Previously there was TensorRT for Stable Diffusion[1], which provided pretty drastic performance improvements[2] at the cost of customisation. I don't forsee this being as big of a problem with LLMs as they are used "as is" and augmented with RAG or prompting techniques.

[1]: https://github.com/NVIDIA/Stable-Diffusion-WebUI-TensorRT [2]: https://reddit.com/r/StableDiffusion/comments/17bj6ol/hows_y...

This is a tech demo for TensorRT, which is ment to greatly improve inference time for compatible models.

Honestly, this is a really cool demonstration of how their foveated rendering works.

It seems to come with Google One (2TB), so with that factored in its actually quite competitive.

When you registered for 2FA it will have given you backup tokens to be written down. They're designed for this exact situation.

Given the number of software projects that use github as their canonical distribution platform and the number of supply chain attacks due to hacks, it's no pretty obvious why they've started enforcing 2FA.

Note that cheerpj is not open source: https://labs.leaningtech.com/cheerpj3/licensing

Announcement from the Rust side: https://news.ycombinator.com/item?id=39263750

It's interesting that they use liquid metal for the CPU thermal interface. Unlike normal liquid metal it seems to be solid at room temperature, which I'm guessing was for ease of (re)application.

> We’re using Coollaboratory’s Liquid MetalPad through their Taiwan-based partner CCHUAN. (https://frame.work/gb/en/blog/framework-laptop-16-deep-dive-...)

It looks like the part is sold with the surrounding protective sheet: https://frame.work/gb/en/products/16-liquid-thermal-pad-amd-...

Gandi lists lol.meme as a premium domain for over $800. We're also in the early access period where even normal domains cost thousands of dollars to reserve.

There is an equally good solar eclipse in April 2024 that crosses the country the other way around.

https://science.nasa.gov/eclipses/future-eclipses/eclipse-20...

This is complete speculation, but the luminance difference between the red sprites and greyscale shirt is greater than that of the other colors.

This is beautiful. The simple paragraph accompanied with links to "The Dictionary of Obscure Sorrows" so eloquently expresses what I've been mulling on.

That was the decoy behind the secondary infection vector, not the motivation.

> The shellcode used in this exploit is constructed in a similar manner to shellcode observed in previous North Korean exploits.

At minimum the payload.

Imgur mirror: https://i.imgur.com/TgfKL9a.jpg

Same topic, but a news article: https://news.ycombinator.com/item?id=37311239