It's not the case anymore. HN is not reflecting it, but HarmonyOS is very much a 3rd option. Huawei got banned from using Android, and they decided to start a mobile OS from scratch. They are binary compatible with Android, so most apps work straight away. Unless they use play services.
They wrote it from scratch in C++ so they could avoid some of the legacy cruft in Android. And they are getting adoption. It's a major OS in China and in many developing countries (phones with it are cheaper, and it flies on underpowered hardware!)
Before we judge the magnitude of this event (HarmonyOS existing and being successful), let's remember that last time anyone tried to disrupt the duopoly Android-iOS, it was MS, the largest company on earth by market capitalization at the time. And they failed.
Well, it very much looks like Huawei is not failing. We in the west don't see it as much, because propaganda is working well. But last tech conference I attended (GITEX Berlin, if you are wondering), had their app available to download with... 3 logos, not 2. Harmony OS was there. This is a major win for consumers all over the world.
And this being HN, I hope the inevitable comment "but China!" is slightly more informed that the average internet user.
If this comes to fruition, my next phone is going to be Harmony OS. I hate the CCP with passion, but if there's sideloading on Harmony - that's where I'm going to go.
I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.
Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1].
In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype).
Agreed on Guix. Used it for a few years, absolutely loved it, excited to go back (had to move off for unimportant and unrelated reasons).
Would love to hear from someone who has used both though.
I've never seen an excellent, detailed comparison actually, as conversation on the subject tends to devolve into a "discussion" on ethics. Meaning, people who dislike GNU or GPL or Lisps or something get testy and argue uncharitably (imho, please prove me wrong, not flaming here, etc).
This is ironic, to say the least, as one of the main points of the proponents of the "anti-GNU" side tends to be how Guix is too opinionated and pushy and hard-line etc. So we've a classic upside-down situation, which is a real shame, as Guix seems to be in reality a practical project with lovely people involved that's doing very interesting work.
The Guix blog has really good and detailed discussions of things Guix has done differently than Nix! Posts on the choice of different abstractions for modeling services in Guix is probably a good starting point.
The UI differences are also striking right away. Guix has a more unified CLI, and the main Guix repo seems to more quickly absorb functionality that's split into various community projects in Nix.
Guix not supporting non-free packages out of the box is the only real issue I have and that’s directly tied to the gnu origins. If guix were as pragmatic as NixOS and nixpkgs then I don’t think I’d have anything to say, lisp is way nicer.
Guix already has as many packages as Nixpkgs did back when I started using it, and like Nixpkgs, the package set is growing exponentially. What you say is true but it also seems to me like for many, Guix already provides a very useful starting point.
I think it’s “only” that yeah. Both have fundamentally the same capabilities. Nixpgs may provide more out of the box library functionality than guix, I’m not sure, but as far as I know there’s nothing possible in one that isn’t possible in the other. Would be glad to be corrected by anyone with more experience, though. I’ve run NixOS for years now, but have only dabbled with guix.
I guess relentlessly dylibbed software like AppImage is the elephant in the room. Nix struggles to handle those types of programs, but they tend to work fine in Flatpak or with a special tool (eg. appimage-run or steam-run).
There’s an entirely mechanical workflow for calling patchelf when packaging a binary that was compiled dynamically against library paths outside of the Nix store.
Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace.
When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.
I think Nix is getting an unfair reputation for being too hard. Simple things are IMHO simpler in Nix than in any other distribution, and what one needs to know to accomplish them is tiny. It has basically reduced my sysadmin maintenance tasks to zero. In case of regressions, Nix makes it trivially easy to go back in time 2 or 3 years, cherrypick some packages and install them, or change your entire desktop environment, and then go back to the previous state with no effort.
Nix is hard if you need to build something difficult to package or something that has very unusual or dirty build processes. If you need to that regularly, Nix is not worth the effort unless you are an organization that values reproducibility and is prepared to pay for its cost upfront. If these particularly messy usecases are something that you don't encounter so frequently, you can always use an escape hatch to be able to make your install impure. For instance, distrobox is quite convenient to run e.g. an Arch or Ubuntu container. In my case, this has been helpful to run Julia, whose Nix packages are quite brittle.
I've been using Nix and NixOS since 2022. I can't imagine not using Nix at this point and agree that the reputation for "being too hard" is not quite accurate. Nix is different - that's the point.
The learning curve is a thing, although I'd argue that it's nowhere near as steep as the tools many of us use every day (C++, Rust, AWS/GCP, etc.)
Nix's "difficulty" IMO comes from defaults that are not sane and a split community. For example, if you use the official Nix installer, flakes are not enabled by default (despite being widely used [1]), but they are if you use the Determinate Systems Nix installer.
Flakes are realistically the only way to obtain the benefits that motivate learning Nix (deterministic pure builds, fine-grained control over dependencies) and are the "primary driver of Nix's adoption" [2]. AFIK there isn't a viable alternative to flakes other than maybe atoms [3], which are relatively new (like "lock files are totally hand made" new [4]). Yet, the official Nix stance on flakes is to wait... for... what?
For a day-in-the-life look at more of Nix's rough edges, I posted some rambles here [5].
Unless it becomes a typed language with clearer syntax around what is what, it’s painful at the scale of nixpkgs and nix without nixpkgs just isn’t all that useful.
I think the reputation is fair. Why is flakes still experimental, for example? That's a subtle bit of encouragement to do things the old way and as a result, documentation is always mixed and you end up "but how do I do that in a flake".
Something that is in theory nice is using the same packages in development and production. But "everyone" uses Mac OS for development and Linux for production, and if you want to guarantee that every developer on your team isn't recompiling Node from scratch, you want to use nixpkgs-25.05-darwin instead of nixos-25.05 on Mac OS. The result is that you aren't actually getting the same package across systems, which is rarely problematic but is something that Will Go Wrong someday. Why not keep Darwin stable in the main stable branch?
I have also found the entire system incredibly unstable during release pushes. Lots of stuff broke in 24.11 and unstable as 25.05 was being prepared (notably nodejs_20). What I learned from this experience is "don't touch package updates in May or November" which isn't amazing if you care about security updates.
So basically, Nix is incredibly rough around the edges. nixpkgs is a much better package repository than anything else I've used, but it's not perfect. It's generally more up to date than Debian unstable. It supports more platforms than Homebrew (which doesn't work on linux-aarch64, a platform I use heavily). Overall the philosophy of making each package entirely self-contained is the right approach.
NixOS is also fine, mostly... but I use Bazel to build all my personal projects. Bazel does not work well on NixOS. For some reason, nixpkgs doesn't have Bazel 8 which is the version I use (because if you don't update your project to a recent Bazel today, you'll have to do it tomorrow). If you get a NixOS-compatible bazel 8 from some random flake, you can solve that problem. But then there are a lot of assumptions the Bazel ecosystem makes, and those are unresolveable. To the Nix folks, having your build system download the official distribution of Go, verifying the sha256, and execing it to do your builds is unthinkable. Personally, I'm fine with it. The Go team knows how to release Go better than anybody. But this impedance mismatch makes it nearly impossible to have a project that builds on "normal" Linux and NixOS. You can go full Nix and get go, c++, etc. from nixpkgs, but then everyone has to have Nix before the can work on your project. I would be OK making that decision for myself (I already use Nix), but I imagine it's a hard sell if you just want to fix development at work. People would complain. People will run into problems. To some extent, this is Bazel's fault (and the ecosystem) for assuming that /bin/bash and some vaguely recent /lib64/ld-linux-x86-64.so.2 exists. NixOS says "no it doesn't unless you declare it and get it out of $PATH" but honestly which version of bash runs "exec bazel-out/program-that-was-just-built" is irrelevant in practice, so it's just an unnecessary barrier. There is an attempt at compatibility for those that don't care about versioning the version of Bash that each shell script runs (envfs, nix-ld), but at least for me, it doesn't work. All in all, the net result is that I can't actually do work on NixOS, and I can't write a flake so my home-manager configuration can install all the software I've written for myself, which is a pretty bad feeling. Building my projects is easy... "git clone git@github.com:jrockway/monorepo; cd monorepo; bazel build //jlog/cmd/jlog; cp bazel-bin/jlog/cmd/jlog/jlog_/jlog ~/bin". But it's literally impossible on NixOS simply because something in the 10,000 lines of other people's code wrote "#!/bin/bash" somewhere. That's pretty rough.
My TLDR is if you want the latest version of Git on Mac OS, linux-aarch64, and linux-x86_64, you should probably look at nixpkgs and home-manager. I like 'em. I don't think there's anything better. Everything else... it's rough. When you commit to leaning into Nix, a lot of your free time is going to disappear for a while.
For reference, I use Nix to manage three different machines, always via home-manager and nix-darwin (I left NixOS awhile ago and haven't looked back). I don't think it's "inevitable" that you'll hit the difficulty wall, but certainly likely.
As an example, I was recently playing with Pyinfra which is like a pure Python version of Ansible. It turns out that one of the dependencies uses an archaic version of setuptools and the package owner had inserted some _very_ hacky code that ended up breaking on two of my systems. Now I'm relatively experienced with Nix, so it took me a few hours to track down, but it would have been days if not impossible for a beginner.
Nowadays I package brew along with my machines and as soon as something smells funky in Nix I just manage it with brew. Much more peaceful.
Nix Pills are probably the best way to get a deep understanding of Nix and some underpinnings of nixpkgs. I read the pills when I started using Nix in 2018 and never had much difficulty understanding the language or most of nixpkgs.
The biggest thing I've hit is linking issues with Rust -sys crates (ie. C/C++ libraries wrapped). There's some very strange behavior if you include gcc and clang (for example) into the same environment.
My biggest issue with Nix tbh is it adds an annoying step to every random repo I want to clone and build.
I've actually gone the other way - not everything is meant to be run. If it's not in the nix repos, I'll try the fhs, and if that doesn't work - well I probably don't care enough to beg it to run. For me the fact that my base installation can never break is not negotiable.
I definitely didn't learn much of nix(os|pkgs). I never bothered learning about flakes. I just have a configuration.nix and a user config.nix, and a "fhs" default.nix and that's it.
My servers don’t have that many dotfiles because most server software can be configured in /etc (zsh, vim), while my work computers have a lot of dotfiles symlinked into ~/.config/ via Nix, e.g. VSCodium, ghostty, …
Most people prefer to Nix up their dotfiles, which provides some advantages (e.g. universal styling via Stylix), but the main drawback that I’m not buying is: I can’t share my app-specific config with non-Nix users.
> these sub-societies will dwindle until there's nothing left of them, and all that's left is The Culture
This would be a terrible result. Google 'urban monoculture'
A pluralistic society is more resilient to catastrophes, and preserving all these small, dwindling cultures is as important if not more as preserving species that are endangered.
> At it's core an LLM is a sort of "situation specific simulation engine." You setup a scenario, and it then plays it out with it's own internal model of the situation, trained on predicting text in a huge variety of situations. This includes accurate real world models of, e.g. physical systems and processes, that are not going to be accessed or used by all prompts, that don't correctly instruct it to do so.
This idea of LLMs doing simulations of the physical world I've never heard before. In fact a transformer model cannot do this. Do you have a source?
Data Science Retreat | Lead software engineer, C or lua | Berlin Germany | REMOTE
---
We are building a collaborative thinking tool with live editing like google docs but outside the browser and with much simpler technology
Why? Security; We want to create knowledge that is not going to end up in the belly of an LLM
Tech stack:
- Wireguard
- zeromq
- WASM for client, handcrafted server code for server. No browser needed on client
- DSL (for gui; probably you won't touch it)
- NixOS
Our approach to security is simplicity; we won't use dependencies unless we really have to; libs of more than 50k LOC are frowned upon. Every line in the codebase, including deps, should be understandable by someone in the team.
Servers are nixOS. No docker anywhere.
About you:
- Are self-motivated and can work independently
- Understand how to build highly reliable systems and be responsible for taking code to production
- Understand that code simplicity and readability are more important for long term maintainability
- Strong CS fundamentals (B.S./M.S. equivalent)
We start out on a full-time trial contract basis for up to 3 months and use this period as an extended work interview for both sides to assess fit for long-term employment
With any questions or to apply, email me at org@datascienceretreat.com
Thanks, I suspect the LLM companies would ignore this, and of course getting into a legal battle is beyond the means of most content producers. so perhaps the license is not the solution, and we need to create a complete world outside http...
By their current interpretation of copyright law (which hasn't yet been successfully challenged), the license is almost completely irrelevant, because they believe it is fair use. You need to first establish that what they are doing is copyright infringement before you can apply any license terms.
Yes, I think the design of GTK and GObject worked out really well in the long run. On the surface it seems stupid to use C and then just "bolt on" a C++-like system on top. Why not just use C++? But clearly it's worked out.
They wrote it from scratch in C++ so they could avoid some of the legacy cruft in Android. And they are getting adoption. It's a major OS in China and in many developing countries (phones with it are cheaper, and it flies on underpowered hardware!)
Before we judge the magnitude of this event (HarmonyOS existing and being successful), let's remember that last time anyone tried to disrupt the duopoly Android-iOS, it was MS, the largest company on earth by market capitalization at the time. And they failed.
Well, it very much looks like Huawei is not failing. We in the west don't see it as much, because propaganda is working well. But last tech conference I attended (GITEX Berlin, if you are wondering), had their app available to download with... 3 logos, not 2. Harmony OS was there. This is a major win for consumers all over the world.
And this being HN, I hope the inevitable comment "but China!" is slightly more informed that the average internet user.