A new discussion about the NixOS logo

[zmberber]

I have made some work on the NixOS logo, which I am presenting here. Only recently have I noticed that my work took pace in parallel to the work done by @djacu.

Relevant links:

• NixOS Logo and Branding Update | Blog | Nix & NixOS
• 2025-04-04 - Branding Redesign Minutes

I wish I could have been part of previous meetings and we could have worked together from the start. Thank you to everyone involved with the current excellent work on improving NixOS branding!

TL;DR

• There have been two versions of the logo in use, one of them in most official logos, the other less commonly.
• The new logo specification and tool by @djacu is now using the less common logo, which is slowly becoming the new “commonly used” logo, instead of phasing out the less commonly used logo.
• I would like to entertain switching to a redesign more faithful to the (so far) more commonly used “old” official version of the logo.

An examination of the NixOS logo

We will now look at the logo(s) used in the past.

The old logo

In the old repository of the logo, there are actually two different versions of the logo.

• The .svg file(s), an adaptation by Simon Frankau of the original design by Tim Cuthbertson.
  • This has more or less been “the” official logo. It seems to be the most used and perhaps more “classic”, it is for example (afaik) being used as the logo in the wiki and in the discourse forum.
  • This file has a bunch of issues with misalignements, non-horizontal lines, and more small inconsistencies.
• The .scad file(s) which were added later to the repository
  • This is being used less, but is now more common, because djacu’s new spec is based on this
  • This is not simply an scad version of the logo in the svg files, this is a different logo with different proportions. Differences have been pointed out here
  • This version does not have faults in terms of misalignments and small inconsistencies

The problem

The svg logo has been more common (in my view by far) and morenornless “the” official logo. Sometimes, the scad version has been used elsewhere and only a few people notice an inconsistency when the latter different logo is being used. It would be nice to use one version of the logo. I would have personally proposed properly specifying the more commonly used logo, and phasing out the less commonly used logo.

The less commonly used (but with less/no errors and better reproducible) is the one that @djacu has now properly made a specification for and written a python tool for it. Again: this is not a specification of the currently mostly used logo, but a specification for a slightly different logo. This means that we are now quietly switching to a different version. I am not necessarily against this, however: I would like to discuss how a new version perhaps more faithful to the previously commonly used logo could look like.

Building the logo

This section shows how the logo can be interpreted in terms of how it can be designed from the bottom up.

Anatomy of a lambda

First, we can start with drawing a skeleton of a lambda. We do this with two line segments, one line half of the size of the other, with the shorter one meeting the longer one at a 60 degree angle (leaving out details about orientation), to form a lambda:

Then, we can “thicken” it by 1/8th of the length of the longer line, in the thick grid this is one unit. What happens at each of the endpoints of the lines is a bit different, I am going to skip the details here, but essentially this is just to make the logo look good in the end, and this is after all just exactly what the NixOS logo does.

Arranging the lambdas v1

Now, if we arrange six lambdas by making the “head” of one lambda touch the “joint” (or “buttocks”) of another lambda rotated 60 degrees clockwise, then we get this:

This particular arrangement also lines up with the origins of the NixOS logo, namely the design by Simon Frankau from the 2009 Haskell logo competition.

Now, if we fatten the lambdas again (also removing the skeleton for better visibility), we get this:

As we can see, they now overlap. If we fill out everything, this is no problem, but with alternating colors, what do we do?

We can “tuck” the “head” of one lambda under the “joint” part of the body of the other lambda (or going with a different word i chose earlier, stick the head of one lambda up the, well, you know…). This of course is not possible by naively using layers for each filled out lambda in an image manipulation program, since there is no lambda that is on top, one part of each lambda is tucked under another part of another lambda. It works with paper in the real world very well, and I can imagine very cool animations. Anyway, with this tucking, and removing the guides, we get this:

Note that this has no gaps (yet), I will talk about this later.

Arranging the lambdas v2

Now, in the step where we arrange the lambdas, to not have an overlap, we can add space in between the lambda skeletons, in precisely such a manner, such that the edges of the “fattened” lambdas (the orange outline) touch each other:

Filling out, and removing the guides, we get this:

This is, to the best of my knowledge and reading of the spec, the exact same logo as the .scad version in the old logo repository, and the same as @djacu’s logo, if we discard the gaps.

This version looks “thinner”, since by construction, we have more space towards the outside of the logo, a bigger hexagon, and longer necks.

The old logo

One interpretation of how the gaps in the logo come to be is that we stroke the outline (edges) of each lambda (before we do the “tucking under” that I described before). Starting off with the v1 design from above, if we choose the stroke thickness as 0.2 (or 0.1 on each side, or “radius” so to speak) of one grid unit as above, we get the following:

Making this stroked line then invisible (which is essentially the case if we have it on a white background, choose light mode on discourse), we have what I believe to be a “geometrically pure” version of the most commonly used NixOS logo, or at least this is the best I was able to come up with.

Note here that naively stroking, as we did here, also removes some of the filled out part of the lambda. This makes the lambdas a bit thinner, and therefore also screws up so many of the proportions that we started off with, since we have essentially added an inside margin of 0.1 units to the visible lambdas (after “tucking in”). This is, in my opinion, why the old logo was so hard to measure out, since we never see these lines, we only saw the filled out inside with proportions all very slightly off what we would like them to be. I also tried out stroking the outline of each lambda as can be seen after tucking in, which would increase the visible gap between the lambdas if we retroactively make the lines “invisible” again.

The only “nice” proportions here are only visible if the stroked lines are visible (dark mode discourse), in which case the empty spaces towards the outside of the logo are the same size as the lambdas. This is not the case if the lambdas are invisible.

Adding nicer gaps

To make a nicer logo, we must, in my opinion, add borders in a “nicer” way.

My personal proposal for a logo.

We shall again for now work with the v1 design from above.

In the above, we have stroked the edges of the lambdas, or essentially added an inner margin. What we should do instead, is just add an outline to each lambda, a border. That way, the nice shape of the lambdas and their nice proportions get preserved. Keeping with the “tucking under” interpretation from before, adding a border of 0.2 units before “tucking in” (so that as above, we get a gap of 0.2 units), we get the following:

This (with invisible lines) is, in my opinion, a better version of the most commonly used official logo.

Again, view this in light mode on to have all of this invisible. I kept them visible (in dark mode) so that you can understand the concept. This is, in my opinion, a much nicer version of the old logo, since the nice proportions are preserved, especially when the lines are invisible. With invisible lines, this amounts to the same as just “cutting off” 0.2 units off of the head/neck.

Now, what I propose, is two things:

• Not work with decimal-base borders/gaps (I believe “0.1” was chosen somewhere as an arbitrary number, and this is also visible in the .scad file of the original repo), but rather working base 2.
• Use thicker gaps. I believe that thick gaps just look better, especially with a small logo or icon, where the otherwise very thin gap can sometimes render weirdly. In my opinion, either use a thick gap, or no gap (which also looks very nice in my opinion).

For the first part, instead of 0.2, we could take 1/4th and be very close to the original (a tiny bit thicker, and I am making this border “invisible” now). It looks very similar to the above, hardly distinguishable, but at least it is easier to construct that way. My first proposal for a logo would be this.

But since I want thicker gaps anyway, together with my second point, I propose a gap of 1/2th of a unit. Therefore the following is my (second) proposal for a logo:

The thicker gaps might look a bit striking to people used to the old logo, but I think it can grow on you. The thickness of the gaps should actually be a seperate issue, this is not the main focus of this post, so for now, I will mainly propose my first version.

Gaps with the v2 design

With the v2 design, as noted before, the .scad file of the old repo chose a parameter of 0.1 somewhere, which is just a weird arbitrary choice. @djacu chose a gap of 1/4th of what I call a unit, which I of course welcome as a change to the .scad-version from the old repo.

Further discussion

I am now just writing out my further thoughts and further endeavors.

Comparison of the logos

I am going to compare my proposal with the one that @djacu has worked on and is slowly being used more and more. I am not aiming to replace their work or design. After all, except for the ever so slightly different gap, it is the same as the .scad in the old repository, most of the work was just writing out a sort of spec in the article, and of course the python toolkit.

My comparison is independent of the gap size. I am rather comparing my proposal (or the “v1” arrangement of the lambdas before) with the spec from @djacu (or the .scad version) in terms of proportions. So really I am comparing the “v1” and the “v2” arrangements from above,

v1 arrangement (my proposal)

• Is, in my opinion, more faithful to the (so far) most used version of the logo
• It is also, in my opinion, more faithful to the original NixOS logo design by Simon Frankau
  • It is possible to overlay the very thin prototype “stick” design from the Haskell competition (what the logo is based on) to this version in a way that makes sense, which is not possible with the v2 arrangement.
• The parallelogram-shaped spaces towards the outside of the logo have the exact same thickness as the lambdas
• The aforementioned parallelogram spaces have a side ratio of 2:3 (3 units “long” and 2 units “wide”), the two sides of the parallelogram that are part of one lambda are not the same length.
• The hexagon-shaped space in the middle is rather small
• The lambdas look closer to the more commonly used glyph for a lambda.
• The lambdas do not retsin their “original” shape, the long line has a 7:4 ratio to the short side (with gaps, especially thick ones the proportions are different anyway)
• This one is hard to explain: For the long line of a lambda, the outer edge (facing inwards of the logo) has two sub-segments that don’t touch the other lambda, they touch “air”. those two sub-segments have same length (3 units). The same goes for the inner edge, which is “interrupted” by the leg of the lambda, the two sub-segments touching “air” have the same length (2 units). This is true with with gaps.

v2 arrangement (old .scad from repo, @djacu’s version)

• Is already slowly being adopted more, and its rendering is already implemented in a nice python tool.
• The parallelogram-shaped spaces towards the outside of the logo have a thickness that is 3/2 as big as the thickness of the lambdas (3 units vs 2 units)
• The aforementioned parallelogram spaces have a side ratio of 1:1 (3 units “long” and 3 units “wide”), and the two sides that are part of one lambda therefore also have the same length.
• The hexagon-shaped space in the middle is rather big
• The lambdas look more close to a hand written lambda (also not uncommon as a glyph)
• The lambdas retain their “original” proportions, the long line still has a 2:1 ratio to the short side

All versions side by side

From left to right: djacu’s version, original, my proposal.

It really does seem like the original version is “in between” djacu’s version and my new proposal. Both djacu’s version and my proposal have better proportions, it is up to interpretation as to which one captures the “original design intention”:

• My version keeps the original “thickness zero” skeleton intact, so the joints are still in the “correct position”, but the lambdas get shorter because they are being “cut off”.
  • Thickening or thinnging the lambdas does not change their arrangement, but more or less of the neck is being cut off.
• @djacu’s version keeps the original shape of the lambdas, but they are now positioned differently, because the thickness of the lambdas changes the point where two lambdas “touch”, so they get moved further apart.
  • Thickening or thinning the lambdas changes how they are arranged, they must be moved around to retain their shape
• The original version kind of has whack proportions.
  • My personal view is, to repeat what I tried to explain in detail above, that this happened due to adding a stroked line leading to an inside margin, which I removed, so that the proportions are simpler numbers, which is how I came to my design proposal

Here are djacu’s version and my proposal with grid lines and a “skeleton” overlayed to illustrate what I described above:

What I want to do in the future

• I would love to have my proposal (the proportions, etc.) incorporated into the python tool that was developed by @djacu
  • I am not sure if they are open to this, or how the community might react.
  • After all, having two versions of a logo that look very similar is kind of annoying, and now I am stirring things up again. It sucks to do a bunch of eork just to have someone say, only after all that work, “but it should be different”.
  • I want to repeat that I am very happy and thankful for all of the work @djacu and others have put into the logo.
  • I haven’t tried out the toolkit, but if I understand it correctly, it should be possible by changing the thickness and gap and length parameters.
• I would like to write something that builds the SVG without external libraries, but strictly within nix, building the parametrized SVG via string templating for XML. Floating point arithmetic might be an issue, I have thought of many solutions. But one thing I have already worked out with a lot of people: Doing rotations is probably bad due to fault propagation. Even when using rotations as a feature of SVG, rendering those can have side effects. This is true especially because you cannot rotate vectors themselves when drawing an initial shape by 60 degrees, as far as I know, and therefore one must work with decimal coordinates, so there are already initial errors there. Instead, I would work with a pre-computed grid in decimal coordinates and work from there.

---

The SVG with a bunch of layers that can be turned off and on can be found here:

• https://cloud.pokemisch.de/s/QP76sPTgRJPGZYe

I do not want to invalidate anyone’s work. I would like to work together with the community.

Please tell me what you think!

[Infinisil]

It’s very cool that we have another person as enthusiastic about the logo design as @djacu! It would be great if you could coordinate to improve the branding guideline together

In the end I personally don’t mind if we use slightly improved numbers and dimensions that make more sense, but the look and feel of the logo should be preserved.

This first proposal (which is close to this) sounds pretty good, I’d have to see a diff to the current one to build a better opinion though.

I’m not a fan of the increased gap size you’re showing with this second proposal though. The lambda’s feel too short and it feels out of place.

[zmberber]

thank you for your feedback!

the thick gaps are indeed controversial. some people think it is too bold, some love it.

it is indeed more strikingly different and perhaps therefore more “off” (or as you say “out of place”), one is not used to it. it deviates more strongly from the known design, and unfamiliarity is then a factor. with my biased opinion, i am of course saying “it will grow on you”.

the same goes for the lambdas. i think they have a great length, the look, to my eyes, exactly like a lambda one would use. the longer neck lambdas (especially in the .scad/@djacu version with ratio 2:1) actually look weird to me. like a “b”/“d”/“p”/“q” with a too long line, or a “t” where the crossing point is too low. some people i have shown it to love it, but others have indeed also said that they like longer lambdas. this part comes down to what kind of lambda one is used to.

however, even though in principle, i think these very thin gaps are not so nice from a design standpoint, i would also primarly vouch for the thinly gapped version of my logo proposal. especislly becsuse it is better not not to deviate too much from what is the ststus quo.

[mich-adams]

This is honestly really impressive. I think all of the logos look good. I really like the bigger gaps, though I can see why people wouldn’t like it for larger logos. I think its perfect for smaller sizes though.

[Sigmanificient]

I’d like to see a 3 unit length lambda tail with the 1/2 unit gap.

In my opinion, the old logo has a better distribution of negative space, which makes it work more effectively—especially at smaller scales:

That said, I believe we should increase the gap from 1/4 to 1/2 unit. This would enhance the shape’s clarity and improve legibility, particularly in the context of subpixel rendering. At around 50 pixels in height, the current 1/4 unit gap translates to less than a pixel, which reduces its visibility.

As an example, the current discourse logo tends to get blurry in gap due to this subpixel rendering (especially the one highlighted here, that almost disappear):

Refining and giving precise definition to the geometry gives strength to the design, and I would love to see this extended to a complete design system, as it has potential to create unique branding tied to Nix/NixOS identity!

[Sigmanificient]

Slightly off-topic, but nixos-artwork was archived, and I couldn’t find the release logo within the branding repo, so does this mean we no longer have release logos? (I know they are not used a lot, but i think it was a nice to have declination with the animals, very biased as I designed the last one )

[Infinisil]

I also struggled to find it, but it’s in the release artifacts of the branding repo: Releases · NixOS/branding · GitHub

Edit: Oh, I don’t think this is what you meant

[zmberber]

yes, these were actually my thoughts, especially with what you said with blurry gaps, this is what I mean with that a very thin gap can sometimes render weirdly, thanks for demonstrating!

also, your point about the better distribution of negative space is what i meant by that the scad/djacu version looks thin. EDIT: apparently, they meant that more negative space is better. My new proposal is closer to the “original” than djacu’s version in terms of proportions and therefore also in terms of negative space, but it indeed has even less negative space than the original, while djacu’s version adds considerably more negative space compared to the original.

in your post, you say “old version”, but you actually inserted my new proposal with the thick gaps. however, since it is rather close to the “old version” in terms of proportions (including the stuff about negative space), the point about negative space is similarly true with the old logo and my proposal.

By “tail”, do you mean what i called the “neck”?

By the way here are two versions with grid, the first one is my new version with thick gaps, the second one is the .scad version (with 0.2 gap instead of 1/4th, i still have to make a version with 1/4th gap): EDIT: removed for less confusion

With the first one, you can see that, if we ignore the gap, the (visible part of) the “neck” is 3 units long (measuring from the intersection of the two lines that make up the lambda, if we draw the “skeleton” again, meaning we take the lines in the grid exactly in the middle of the fattened lambda), ending where it hits the edge of the next lambda. With the second one, it is 4 units long. This is also where the “7:4” ratio comes one.

Did I understand you correctly @Sigmanificient? I am also explaining for the other people reading.

[Sigmanificient]

Sorry for my confusing terminology, here i was referring having the second one with the half unit gaps, will be waiting for the render!

[zmberber]

ok, so what you refer to as the “old” logo, is in your little image the one on the right? then i understood you the wrong way. that to me is the “new” logo, compared to, the “old” one which is for example visible in the logo seen here on discourse.

so you are proposing something even more new: use the scad/djacu version with thicker gaps?

[zmberber]

sorry for all of the confusion above.

it seems like some people like the thick gaps for smaller logos.

so irrespective of which version we take in terms of proportions of the lambdas without gaps, perhaps a version with bigger gaps can be established as an “icon” version?

this would be a separate issue.

i am still more interested in if we like the version that deviates more from the logo mostly used in the past (the scad/djacu version, with a longer neck, with more negative space), or a version more close to what was previously used (in spirit, but also just by measuring the proportions), which is what i tried to aim for. this is mainly the discussion i was looking for, i almost regret having brought up bigger gaps in my original post. well, maybe i don’t because it is also an interesting discussion, as we see.

EDIT: Ok I have made a bunch of updates to my original post to include comparisons, more context, and better images with correct gaps.

[raboof]

Thanks for digging into this! I love the work by @djacu on making the logo more ‘grounded’ and “codify’ing” it, but I also noticed the ‘middle hexagon’ getting rather big. It would be so cool to find a ‘grounding’ that keeps that avoids that.

Intuitively, I like your first proposal (though I’ll admit I haven’t entirely digested the ‘grounding’ yet). I’m less fond of the variant with the bigger margins, that makes the ‘top’ of the lambda a bit of a ‘stump’.

I’m not sure if the margins in the original were arbitrary, btw: if I draw the grid like this over the original logo, making the gaps part of the grid, it looks pretty close (but would suggest it might make sense to make the ‘legs’ slightly longer):

(just a sketch, not as nicely-worked-out as y’all’s work. not sure if this is bikeshedding, but wanted to share )

[zmberber]

thanks! this is indeed what i worked out pretty much! your grey lines are the stroked lines of the lambdas. i have a version of this where your gray lines are white, in the section “the old logo”. so in my interpretation, the “actual” lambda edges are right in the middle of your gray (or my white) lines, since after doing this, the proportions suddenly become nice (with low denominators)! this is how i came up with my redesign of the logo.

[ginkogruen]

With the version with the larger hexagon I always have this issue where a sort of “cross-lambda” line always catches my eye (on the mono-colored version).

Like this (The logo is from the Discord):

I think it may be caused by the parallelogram’s.
With the other version I don’t have this so I like it more and also generally not specific to this issue.

I do also like the version with the larger gaps but I don’t think it fits every context. It somehow feels a bit more playful for me (I’m not sure why that is).

[crertel]

This is really neat!

That said, to my understanding and observation this work was already conducted in public by the marketing team over the last six months (half a year), and all the relevant meetings were open to anybody that wanted to attend.

I don’t see any reason to second-guess the already completed work done on this.

(In the future, better coordination might be the play–I say this having had to run a similar gauntlet for some of my own changes, which is fine.)

[zmberber]

yes, i kind of missed the opportunity to make a PR for the old nixos-artwork repo, or make a discussion about this on duscourse, like i am doing now, end of last year, some people suggested that.

of course my stupid perfectionism (among just having a busy life) kept me from doing this earlier.

my comments about how the logo should be designed could have then possibly been incorporated or discussed.

that is totally on me, and i really wish i had brought things up earlier.

i can’t find public discussions specifically about the (re)design of the logo. i only see notes in the minutes of the marketing team that mention the logo and the python tool and that there is “work being done”. the only sort of discussion was in the comments of the minutes of one of thede meetings (linked in my post at thr top) that did lay out the new proportions of the lambda, i did not see that comment at the time. this would have been the first time that i could have noticed that we are changing the proportions. the blog post announcement (which i also got to see way too late) that then came was the first time i heard of the new proportions, and that made me briefly talk to djacu and make this post.

part of that is all my fault, i could have been more aware of these marketing meetings. some people told me that “djacu is doing some work and building a tool that they will reveal soon” and then when it was revealed (to me), the blog post and everything was already there. i definitely could have engaged more.

please tell me if i am being completely wrong here about when and where there were public discussions about the logo.

it seems like part of why this happened this way is because there is the opinion by djacu that if you look at the new and old logo, you would only see the difference after looking at it for “hundreds of hours”, and that djacu themself can’t see the difference at a glance.

though not strikingly, i see the difference immediately, and i know that i am not alone. the point of my post is that it is not just making the logo “more exact”, it is actually changing it, and i am showing hoe i came up with a different (and i argue more faithful) way of making the logo “more exact”, with exactly the same motivations that djacu expressed.

i am really sorry for stirring things up. i don’t like the fact that after so much work has been already done and stuff has been decided, that i am only afterwards coming with objections to the new proportions. i wish i would have brought this up way earlier.

at the end of the day, if everyone says that they like the new design by djacu best, then of course we should take that, and i am happy. i want to discuss the precise design of the logo publicly, and work together with everyone.

[paperdigits]

This logo doesn’t work for me for two reasons:

1. The “overlapping” causes the loss of the shape of the lambda, now its a logo make out of a bunch of oddly shaped Ys.
2. The thickness of the stroke on your Ys doesn’t go well with the relatively thin stroke of the logo font.

Further, if you got what you say you wanted (for your logo to be added to the python logo generation tool)… then we’d have two versions of the logo? That’s not good.

@crertel

I don’t see any reason to second-guess the already completed work done on this.

I also agree with this. The work is done. If you want to contribute to the branding, the proper way to do it would be to join the marketing team.

[djacu]

@zmberber

at the end of the day, if everyone says that they like the new design by djacu best, then of course we should take that, and i am happy. i want to discuss the precise design of the logo publicly, and work together with everyone.

Thanks, @zmberber. I appreciate that you’re engaging in good faith and putting real thought into your proposal.

To be clear, branding decisions fall under the responsibility of the NixOS Marketing Team. I serve as the Brand and Design Steward, and it is my role to ensure that the NixOS visual identity is coherent, consistent, and maintainable over time.

Community input is welcome, especially on recognizability and perception. But this is not a popularity contest. Design decisions are not made by vote. They are made by applying clear principles, technical requirements, and long-term brand strategy.

The current logo variant is not just a redesign. It is part of a system. It corrects flaws in the original, defines consistent geometry and proportions, and integrates with deterministic tooling. That is what we need for a sustainable brand.

We can continue discussing refinements, but the final decision will be made based on what best serves the project’s design goals, not on which version gets the most support in a forum thread.

[djacu]

@Sigmanificient

Slightly off-topic, but nixos-artwork was archived, and I couldn’t find the release logo within the branding repo, so does this mean we no longer have release logos? (I know they are not used a lot, but i think it was a nice to have declination with the animals, very biased as I designed the last one )

We will continue to have release logos. Finding a new home for the old ones is on my to-do list. Currently, the branding repo is 10MB in size on checkout and the nixos-artwork repo is 600MB. Trying to find a solution that doesn’t bloat the branding repo.

[zmberber]

thank you for your response!

i can of course agree with what you said about popularity.

i of course was also arguing from the standpoint of “what makes sense”, in terms of the system, applying clear principles. i tried to lay this out.

both have their aesthetic qualities, and more importantly, both have their different reasonings with how they work and how they are reasoned in terms principles. i tried to lay out both, in as many points as i coule, in my post.

i might release an animation showing how when going from infinitely thin lambdas to thicker lambdas, morphing in two different ways: one would morph into my version, the other into your version. this would clearly show the essential differences. they are two similar but different approaches.