ymse

Nix packages can not modify the system globally, by design. Not even on NixOS. This is why Nix allows unprivileged users to install anything.

When you install a package with Nix, all you are doing is drop a symlink in your ~/.nix-profile pointing to some /nix/store/<unique-identifier> item.

When you build a package with Nix (also does not require root privileges), it happens inside a container that can only write to /nix/store/<unique-identifier>.

The <unique-identifier> is a cryptographic hash based on all the inputs (dependencies) to the package (also /nix/store/<hash> items) as well as the build script.

Hi, thanks for the link, very interesting.

Indeed the similarity with Ganeti is only on the surface: being a scalable infrastructure management tool, DRBD as a first-class supported disk backend, etc.

The cluster replication and consensus model is very different: Ganeti has a single "master" node that makes all the decisions and replicates cluster state to other nodes.

Only if you don't care about stability or maintenance costs.

LXC is supported too.

Thanks for checking the dates, I thought Proxmox was newer.

> I don't think there is another notable, proven, open source clustered manager of both actual VMs and containers.

Googles Ganeti is strikingly similar to Proxmox, to the point where I suspect Proxmox started as a reimplementation:

http://www.ganeti.org/ (developed at https://github.com/ganeti/ganeti)

It does not come with a GUI, though there are a few third party ones. It has API endpoints for everything, a fully featured CLI client, and is extremely stable.

Googles marketing department does not want you to know this, but Ganeti runs most of its internal infrastructure (not public facing stuff).

No affiliation, just a happy user.

OpenSSL actually did a breaking API change as recent as 1.1.1e (reverted in 1.1.1f to be fair):

https://bugs.python.org/issue40018

And broke the ABI in 1.0.2g:

https://bugzilla.redhat.com/show_bug.cgi?id=1313509

I don't mean to bash on OpenSSL here and agree they generally do an exceptional job at keeping the public interface stable. Just offering some context. These things are difficult.

It's one of the things you just can't do without once you become accustomed to it. I can not imagine going back to needing root privileges just to install or try a package, or being unable to roll back to earlier revisions.

I hear Nix even works on macOS too! :-)

The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork.

There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix

I think you mean inverted method? I would not recommend it though. The risk of spills is too high (it will fall over at some point), and there are simpler ways to brew with more consistent (and IMO better) results.

Here is a technique I have developed after many years of almost daily brewing. I call it the "30-30-30" (anyone get the reference?), but each step has a lot of room for variance, no timer necessary.

* Mount the AeroPress on a 3dl mug and add ~17g of medium-coarse freshly ground coffee.

* Add 20-30g of hot water to let it "bloom", which releases CO2 and other gases trapped in the beans from the roasting process. Leave it for 15-30 seconds until most bubbles have popped (if any). Very fresh beans should bloom longer.

* Pour water up to just above the 4 mark. I like to spin the AeroPress while pouring to stir it, but you can also pour in circles like a pour-over. Try to make it foamy by having the water break just before it hits.

* Let it drip for ~30s (or until the water level is just above the 3 mark).

* Slowly plunge for another 20-30s.

That's it! The water temperature should be between 85 and 95 °C; any hotter will burn the grounds and lower temperatures won't be able to extract as much flavour.

I recommend skipping the article and jump straight to the movie if you have the time: https://archive.org/details/The.Yes.Men.Fix.The.World.P2P.Ed...

It was released under a Creative Commons license on recommendation from the EFF, so that the U.S. House of Chambers could not stop it (yes, they tried!).

The movie is a documentary of sorts, featuring two people who go to conferences posing as high-profile businesses, promoting oft-ridiculous products to make a point...the only problem is, people keep taking them seriously (even Halliburtons SurvivaBall).

At one point they end up live on BBC news and inadvertently wipes $1B+ off a companys public stock value.

It is hilarious, and well worth the watch.

Sorry, I think my use of "artifact" here caused some confusion.

Each of these "artifacts" are actual isolated builds of complicated programs such as Chromium or GCC. The technical term is "derivation", which produce "outputs".

All of those packages can be reproduced from source now or 100 years into the future and SHOULD produce the exact same binary output. If they don't, it's a bug.

It means that the items could not be found on the remote server(s).

Nice!

In case any Nixers are reading this, here is how I got NSPR to build reproducibly in Guix:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=6d7786...

I think GNU Guix offers what you are after.

I maintain my own build farm and tried comparing my results against the official CI server:

  $ guix challenge --substitute-urls="https://ci.guix.info"
  14,224 store items were analyzed:
    - 4,972 (35.0%) were identical
    - 265 (1.9%) differed
    - 8,987 (63.2%) were inconclusive

Of the 5237 build artifacts that were available on the substitute server, only 265 (5%) differed.

All of these items can be (and have been) built entirely from source, starting with Guix' initial "binary seeds", on (probably) different hardware and kernel compared to the CI system.

I can't speak for Nix, but getting Guix up and running on your favourite distribution can be achieved with this two-liner:

  wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
  sudo bash guix-install.sh

> Then there's the whole promise of it being usable from multiple platforms ("you don't even have to use NixOS, just use the package manager for awesome builds") -- It was supposedly amazing for building some software packages, but the reality was always so sticky and never quite panned out.

The vast majority of Guix users are on other (so-called "foreign") distributions (i.e. not GuixSD) -- I think the opposite is true for Nix/NixOS.

I'm not sure what's "sticky" about it, can you elaborate?

Interesting. I only had one Android repo on this computer, but found one commit from "Anonymous Coward" (2012):

https://android.googlesource.com/platform/system/core/+/4474...

Can we find others? :-)

A friend of mine speculated that total surveillance (and thus control) of society will eventually make the world consistent in logical terms.

Which necessarily makes it incomplete following Gödel's incompleteness theorems. Here completeness refers to diversity: to maximize completeness is to encourage genetic (and memetic) variation. If society is consistent, such a proposition becomes absurd.

It's an interesting thought experiment, and I don't think the consistent state is reversible. Luckily it requires that all of the world (intelligentsia) agree on the same set of rules, so there's still time.

Taking this argument to the extreme: perhaps the reason we haven't met civilisations from other worlds is simply that they all made the same logical error once the tech was available.

As someone who has packaged a lot of software for Debian, CentOS, Gentoo, NixOS, and GNU Guix, I have to agree -- it's by far the most difficult platform.

I actually believe much of the Docker hype can be attributed to this. Why bother learning packaging when you can just script something and throw it in a container.

Now I just use Guix on any distro for my up-to-date/custom software needs.

Ha, funny you should mention that. I am in fact looking for a job. Luckily the one interview I've had since losing the phone was on-site.

If I need to participate in on-call rotation or similar, I expect the employer to issue a phone. For a remote job, I will obviously get one myself -- but then strictly for job-related activities.

(by the way, if anyone is looking for an experienced infrastructure engineer/"DevOps" guy, give me a cal...errh email)

I lost my phone somewhat recently. It's been great: I read more books, and get a lot less distractions throughout the day. The privacy implication is a huge bonus.

The main drawback have been that people rarely label apartment doorbells anymore, so if you don't know which button to press you're in trouble. Another is getting hold of old friends if you don't know their email address (I don't have Facebook either).

Overall, I'm fairly content with the situation, and am seriously considering not getting a new one. Another benefit is that I'm more likely to bring my laptop if I go somewhere, and thus when I do connect to the internet and have time to kill, I often get work done instead of mindlessly browsing HN/reddit or playing games.

I'm sorry if the post came across as assuming. I just wanted to spread awareness, not necessarily aimed at you.

There are good and trustworthy projects out there IMO. I use GuixSD and OpenBSD for all my computing needs and have 0 reason not to trust them. Curious to hear any arguments against either.

To paraphrase the venerable Mutt email client: All operating systems suck. These ones just sucks less...

> I've worked a few gigs, and shipped some products, where we didn't use any GNU software at all.

That's very impressive (assuming you were developing for Linux). I guess no one used Emacs, or GDB, and you were cross-compiling (using Clang and LLD) from Windows or macOS?