HN user

hiimshort

374 karma
Posts4
Comments72
View on HN
OAuth for all 28 days ago

Just a passerby, but wanted to say thanks for your work. Ory services are a delight and I was excited to see them spring up years ago and even more excited to see them continue to be developed and put to good use!

Gemini Diffusion 1 year ago

I have been wondering about the use of diffusion techniques for text generation, it is nice to see Google release a model that, seemingly, validates some thoughts I had.

Most folks I have seen experimenting with AI are either using a paid service or running high-grade hardware (even if consumer-level). The best I have in my current repertoire is a 5700XT and am not able to upgrade from that yet. The limitation, though, has at least also given some more significant insights into the shortcomings of current models.

Model sizes have gotten quite large and coherence seems to mostly have scaled with the density of a model, leaving the smaller models useful for only smaller tasks. Context size is also extremely important from my experiments with long-running dialogues and agent sessions, but a smaller GPU simply cannot fit a decent model and enough context at the same time. I do wonder if diffusion techniques will allow for a rebalancing of this density-to-coherence connection, letting smaller models produce chunks of coherent text even if limited by context. From my viewpoint it seems it will. Mixed tool call + response outputs also have the potential to be better.

Speed is also another problem I, and everyone else, has had with modern LLMs. The nature of cycling around the input with a new additional output each time is time consuming. On an older GPU with no AI-specific hardware it is an eternity! Being able to at least track 0-100% progress state would be an improvement from the current solution. At the moment one must simply wait for the LLM to decide to stop (or hit the max number of inference tokens). I am hopeful that, even on lower-end GPUs, a diffusion model will perform slightly better.

This does now beg several questions. If we are processing noise, where does the noise come from? Is there a good source of noise for LLMs/text specifically? Is the entire block sized beforehand or is it possible to have variable length in responses?

Lix is excellent. It is already faster (parsing), safer (better defaults, removed footguns), and easier to use (better errors, etc) than Nix. If anyone wants to get started using Nix then I highlight recommend you install Lix from the link in the parent comment.

For those unfamiliar with the game I would highly recommend it if you are interested in CRPG games with excellent writing. There is a lot of text in this game, but with the most recent version of the game most of it is voice acted. Many lines will stick with you later. It's rare to not be taken by something in the game, as expansive as it is.

For a more general description of the game: you are a detective, you must solve the case, and your fractured psyche will not let you do it alone.

The same is true for me on Safari. I've tried with and without AdGuard and the experience on plenty of sites that I just want to get a quick tidbit from is awfully painful.

Pikuma is excellent! I have enjoyed going through the videos on the YouTube channel to help understand some 3d graphics rendering techniques. Everything that I have seen has been as easy to digest as this post. Highly recommend checking out the rest of the catalogue if this kind of content is interesting to you.

This has been a tough one to figure out. I do not think there is a great answer here. GitHub has a large network of people and the barrier to contributing there is fairly low. Cost is also subsidized greatly by GitHub. Nixpkgs being one of the largest and most active repositories on the entire platform would certainly strain any self-hosted or otherwise unprepared service. However, the benefits of a FOSS git forge with commitments to federation and values similar to this project also exist. Perhaps the answer here is to begin on GitHub to ease initial contributions and concerns over cost and to later transition to something like Codeberg.

This page was created by me. I have tried to capture what I feel are important values that are hopefully shared by others who are leaving or have left Nix. With the values, goals, and roadmap clearly stated, others can join to contribute. Part of the reason I felt this was important was to make sure that anyone who would want to contribute did not feel like there would be some rug pull moment. I wanted to outline exactly what was going to happen and how it was going to be better than what we have currently with Nix so that we can build that vision together.

Hi, I (Jake Hamilton) am.

Though, this is not an effort that can be undertaken by one person. My goal is publishing this page was to create a set of values, goals, and a roadmap for people (like myself) who would otherwise be leaving the Nix ecosystem due to its shortcomings. These values, goals, and roadmap can then be used for alignment to actually make it a reality. I worried that if these things weren't specified up front that people would instead continue arguing in circles about past problems rather than building a solution.

The last example reminds me of the once-proposed html imports feature. It was being pushed by Google back when Polymer was a thing and would've given us actual web components delivered as html documents with full support for html, css, and js just like we use normally. If I remember correctly there were a few issues with the approach that needed to be resolved and nobody stepped up to make it a reality. So instead we got the custom elements spec years later which only implemented a small percentage of what made html imports useful.

Declarative home environments are pretty great. Being able to reproduce your entire user setup is fantastic when you manage multiple machines or want to make future migrations.

I run NixOS and use Home-Manager as well. This lets me define my entire system in addition to my user home contents declaratively. So with this configuration I can apply NixOS & Home-Manager to get the same results anywhere.

Here is an example of my Home-Manager configuration: https://github.com/jakehamilton/config/blob/a3da20eeab74a50a...

In this example I configure Git. This gets written to my user home's config directory.

Home-Manager is a project that brings declarative user home directory management to Nix. You can have it set up dotfiles, user systemd services, etc. All the things to do with stuff in your home directory.

The documentation for Home-Manager that is generated is an extremely large html file with every option listed. It is not easy to read or discover options in. The linked tool provides a search field to query the available options for Home-Manager, making it much easier to digest. This is similar to the NixOS Options search tool which does the same job of providing search for NixOS options.

Disclosure: I work at Replit

I think most of the confusion here comes from some users not realizing the difference between the previous hosting solution “Always On” and the new one “Deployments”. Always On was a quick way to keep a dev machine running, but was difficult to consider for production use cases since the dev machine was what you were serving from. Deployments decoupled the two and enabled separate machines (including dynamic scaling) to be used for development and production. So now users have on-demand dev machines with our cloud IDE in addition to persistent deployments. There are a lot of benefits from this approach, but it meant that Always On wasn’t as useful.

This has been a challenge for me to overcome as well. Notes never really worked for me and, of course, simply remembering everything is neither possible nor productive. Personally, I've struck a middle ground that I've called [1]"Boomerang Thoughts". The idea being that the default stance is to let ideas go, expecting the good, compelling ones to come back. It's seemed to improve my ability to focus on important projects in the present and have a more limited, curated list of things that I am driven to act on next.

[1] https://bytesize.xyz/boomerang-thoughts

It's a harmless bit. The joke (if I remember correctly) is that these two creatures are aliens that pop up and don't know what the thing in front of them is. For children (and adults) it is silly because, of course, we know what a computer is – we've seen one dozens of hundreds of times! Compound that confusion with a silly way of speaking to reaffirm that they're not from earth and it makes you giggle.

As for the developmental impact, I think it's quite positive. Sesame Street has been and continues to be a great source of knowledge and useful lessons & morals for children. Adding in some silly situations like this helps keep them engaged and develop their sense of humor.

Sandro is right that the language is called Nix and the CLI is called Nix. Though, part of the trouble is that Nix handles multiple things (eg. Dev environments) and is often referred to separately as the Nix Package Manager. Realistically, people do talk about "Nix" as one of many of these things which confuses a lot of people. Even the name NixOS is confusing for those unfamiliar with Nix.

I mean that it's not clear how time is going to fix Nix's documentation.

This is my estimate based on the work that has happened over the last two years. There is steady movement in the right direction and the community is organized alongside the NixOS Foundation members to make things happen. Just not at a break-neck pace. Places like Determinate Systems, Tweag, etc are the largest forces currently, but there are plenty of others that are trying to move things along. Over time, that steady movement will land Nix in a place where its pains have been largely dealt with. I don't think we're there yet and, at this pace, won't be for a while.

I love Nix, all of my machines run NixOS, but I think it's 5-10 years out from widespread adoption. Currently the biggest issues have to do with severely lacking documentation, lack of developer tooling (missing things like LSP), very slow iteration cycles, confusing or impossible to understand errors, and even naming (Nix refers to the language, package manager, cli, community, etc).

That said, right now it's still the best tool I've ever used. Nix is great at a few things: reproducible development environments, reproducible builds, and reproducible systems. I introduced Nix at my last job to do most of these things and it helped onboarding dramatically: Nix-based development environments with automatic activation, Nix-based Docker image builds which reuse the work done for the dev environment, and Nix-Darwin configuration to configure systems with one command. It's incredibly powerful and you're able to use as much or as little as you like. So the amount of "overkill" is variable.

Of course, the problem here is that knowledge of Nix itself is necessary to build and maintain these things. Due to the reasons outlined previously, it is quite an investment. I believe it is worth it given the stability, flexibility, and efficiency Nix can provide.