Announcing nixlang.wiki

Announcements
38

Ideally, we manage to become a shared notepad for the nix community

That sounds like a really good idea. And if you manage to do the proactive moderation with the velvet glove of quality control, asking people to complete some things that are missing (this is a real issue right now on the existing wiki), while leaving out things that are unnecessary, technically or socio-politically, I think it might turn out very well. :slight_smile:

I’ve seen that many people wish there was a way to keep track of what’s “happening in nix” without having to constantly be plugged into discourse, matrix, and nix/nixpkgs issues and PRs

Yes, count me in here. I think this is just a necessary point of friction in transitioning from a purely experimental project that runs on personal connections mainly, to one that is so big that it gets impersonal by default. At that point learning nix and NixOS can no longer depend on knowing someone who knows it already. I am not using it for that long, but I still switched before the current popularity boost, because someone else told me to try it. Maybe this is phasing out now.

2 Likes
39

I’ve just reworked the landing page a bit, and icluded a basic news section. Fleshing out some guidelines for what should and shouldn’t go there however will probably be a process, but now that ball is also rolling.

Sorry, but allow me to dissect this.

I’m not sure what you mean here, but to be clear, we have a code of conduct that will be enforced, specifically the contributors covenant code of conduct. It includes a mention of politics in examples of unacceptable behavior.

Trolling, insulting or derogatory comments, and personal or political attacks

However, I can imagine some people will find it political that I think our editorial view should be that of a community, not of companies, and that remaining somewhat independent of the large consulting and venture capital firms that have a rather large pressence in the nix project will ensure the quality of the content, even when it might come to highlight flaws in Nix and NixOS.

As someone that runs multiple FOSS projects, my efforts are inherently political, Free Software is inseparable from politics, and projects like nixlang.wiki are part of my praxis, in the sense that its my goal to make sure our primary knowledge source is a thriving FOSS platform, not a proprietary, or weakly licensed one.

Licenses will be strong copyleft, contributors will treat each other with respect, and minorities have to feel welcome to contribute to the wiki. I mention this because I know some people think it’s political to be inclusive, in which case I wanna make clear that then you’ll think this is a political project.

Also, I would welcome pages that discuss the socio-politics of the nix project, I think having such insight into a project can be very helpful for newcomers.

I don’t want a “minimal”, streamlined wiki. Ideally, I want people to post long infodumps with everything I could possibly want to know, regardless of the quality, and then have readers slowly increase the quality as more eyeballs pass over the page.

Like wikipedia, quality isn’t enforced at point of contribution, it’s created through iterations on the content that people upload. This is already a behavior I’ve noticed contributors have, where I’ve seen some cases of people that just fix typos, move things around, change the wording, which is great!

I very much lean “worse is better” over "the right thing"1 and I would attribute the existence of the wiki and it’s rapid iterations to this view. It’s also a pattern I see in general in successful FOSS projects.

6 Likes
40

I suggest movement toward an official wiki is a good idea because the consequences of this decentralizing are showing itself clearly currently. Since now, we have 3 different competing wikis, and if there is no official wiki there is just going to be more fracturization, I propose that we should just take a page out of Arch’s book and create an official wiki.

3 Likes
41

TL;DR: decentralization and being unofficial has worked well for me, and I remain convinced it’s the right approach, but I’ll happily accept the “official” label, if it’s without any strings attached.

I disagree, we don’t have 3 competing wikis. We have one wiki that was closed, one wiki with an awol maintainer, and https://nixlang.wiki.

We’re willing to move nixlang towards the nixos foundation more, but not to relinquish control, because we think we’d be better at running it, at least for now.

I’ve literally been here before with eza, where waiting for some higher power to come and fix the problem just stalled development’ for several years. Instead of doing that and trying to build consensus about simple things such as code of conducts, I just forked it and told people they could contribute, and while there were initial detractors and people with a political axe to grind with inclusivity, eventually we became the default, and with the added bonus of having an actually great community.

Same story with https://rime.cx really, instead of waiting for flakehub to eventually, if ever, be made open source, we just went to work creating great alternative with the features we wanted (specially not being github only), with a strong copyleft license and no venture capital to steer the direction of development.

I’d rather focus on quality, easy of use, accessibility, inclusivity, usefulness, all those things, and without having to wait for RFC processes and community consensus and endless concern trolling and bikeshedding.

Our goal is also to contextualize nix, and I think decentralization is imperative to fixing fundamental problems with nix documentation. The official documentation for nix, nixos, and nixpkgs are all excellent to me, yet many users find the nix documentation unapproachable. I think this is partially because there is a lack of usecase examples and workflows, and because there is a lack in diverse perspectives.

Rather than one-size-fits-all, documentation should be a constellation of sources, and part of nixlang.wiki’s job should be contextualizing and interconnecting these, as well as being a platform for easy creation and hosting of such sources.

I think this view owes back to very foundational ideas about the internet and hypertext and a longing for neocitis and userpages and personal blogs. Ultimately, if nixlang.wiki specifically should become official, whether de facto or de jur, it would be because it was the best alternative, I imagine, not because it was debated endlessly and finally approved as being official.

By making a wiki now, we are creating glue between these parts, by waiting for a solution we’re just bikeshedding. IF creating this wiki divides the community and the documentation, it’s a division between inaction and action.

8 Likes
42

Sorry, but allow me to dissect this.

This could be seen as an invitation to more and deeper dissections. However I am not going to go there this time. :smile:

Since you didn’t see the point I was trying to make: I just see a tension in your approach between this statement:

to be clear, we have a code of conduct that will be enforced

and this statement

I very much lean “worse is better” over “the right thing”

On the one hand you have strong emphasis on enforcement upfront. Yet you combine this with another strong emphasis on iterative experimentation and incremental correction / improvement.

In my experience this is a target conflict.

My attempt was just to make you sensitive to the possibility of another style of proactive moderation that avoids this target conflict, or is at least less susceptible to it. The velvet glove instead of the iron fist, if you will, metaphorically. A style that is more in line with nudging people in a desired direction iteratively rather than with threatening strict enforcement preemptively.

I believe this doesn’t necessarily compromise any of the explicit political goals you might have. It might actually help you integrate people to your political goals who, in an explicit political discussion upfront, would be in open conflict with you.

there is a lack in diverse perspectives

As relating to improving the documentation I am really curious what you would suggest as improvement here. I do relate very much to the lack of usecase examples and workflows. But the lack of diverse perspectives is much too abstract to me. I am not sure how to implement a change on that. What do you have in mind here?

43

Ohh well yes of course, the iron fist was just a tongue in cheek kinda thing :woozy_face:

There seems to be a core group of developers that produce a lot of the documentation (and well, really most of nix), and the few on-ramps that do exist are way too steep. Hopefully, by making the wiki easily available, even allowing anonymous contributions, we’ll get contributions from those that are new to nix, as they are learning, and from those that might find official nix efforts too intimidating or hostile to contribute to.

3 Likes
44

See this comment from @wamserma

1 Like
45

I put this on a container registry and tried deploying this to the nixlang cluster, but both there and in my local testing, the latest version seems like it’s not working properly. Also the build time after deployment being >25 mins has me a bit skeptical of the quality of their solution.

Perhaps we could achieve something similar with much less complexity, I could imagine e.g. serving just a static page with some css still being easy enough to use if made correctly, or a "simple" rust webapp that parses entries from a config file (yaml, toml, or perhaps even nix).

1 Like
46

v1 (Go) or v2-beta (Rust)?

1 Like
47

I’ll take a look at v2 >_>

EDIT: after playing with v2 for a bit, it does looks a lot nicer, I might try to deploy this later

1 Like
48

@cafkafk, thank you for the wiki, and thank you for eza (which I just installed on all my systems) :grin:

1 Like
49

TCC compiler uses a mob branch approach:

https://repo.or.cz/tinycc.git

https://repo.or.cz/h/mob.html

1 Like
50

I present to you, https://landscape.nixlang.wiki, and GitHub - nixlang-wiki/nixos-landscape: The Landscape of NixOS and associated projects, where people can add projects through PRs and such.

9 Likes
51

I agree. It’s understandable that making something official has to be done with some care, as unofficial things don’t have to adhere to anything but their own rules. However, after multiple years of nothing official, faulting somebody for actually creating movement on the issue and taking things into their own hands is questionable.

If official members believe nixlang.wiki shouldn’t exist or contributions should go to some other place, then IMO the obvious actions are:

  1. provide an official wiki
  2. make contributions to that wiki (or other place like nix.dev) as easy or easier than alternative wikis

Or declare nixlang.wiki official.

I for one am glad @cafkafk took this action. nixlang.wiki looks way better than nixos.wiki, has moden features, and supports MarkDown (:heart:). The git storage module is pretty sweet too. nixos.wiki has needed an upgrade for a while.

7 Likes
52

This is really, very cool. I also love the approach you’re taking here. Great job. I appreciate and am encouraged by your willingness to try stuff. It is hard to be on the receiving end of criticism about how you did something, like you’re somehow required to contribute in some precise way instead of exactly the way you want to. It’s bogus. Scratch your itch, get messy, make progress in the way free and open source software always has. Good for you. Thank you. Keep going :).

14 Likes
53

I don’t mind multiple wikis, as long as i’m able to find the information i need with my often too vague duck-duck-go searches. What i fear is that critical information may get fragmented, but i also know that writing a new one now that the old one already exist is a great chance to restructure all the content and prune outdated information. This does however require a principled approach.

But ultimately I’d like a wiki to also be available in the nixpkgs tree. The strength with wikis compared to in-tree documentation is the lower barrier to edit. The con is that it is more prone to become outdated.
meta.doc in the nixos modules have been a major step in the right direction, but adding additional pages to the in-tree nixpkgs and nixos manual is not easy becuase you don’t know where certain information neccesarily fits and you can’t get a decent live preview on github.

Do you think there would be interest in a contrib-wiki/ folder in nixpkgs? Its documentation would pop up in rg searches which is common while making treewide changes. Then to not loose the lower barier to contribute that wikis provide, how about a two-way sync schedule with humans in the loop? I’m not familiar with wiki.js, but does it support exporting and importing markdown?

1 Like
54

Are you sure Flakestry counts as “Official?” It looks like it would be better suited to be in “Community,” unless I’m missing something.

1 Like
55

Ahh, I see, there also already is a PR to fix this (Correct the project status of flakestry by grahamc · Pull Request #1 · nixlang-wiki/nixos-landscape · GitHub), I’ll take a look.

EDIT: the type of flakestry has now been corrected to community.

56

The nixos wiki is used by people who are newbies in all respects, which is why most of the content is copy-pasted or otherwise low-quality. It’s very much a situation of newbies leading each other around, because anyone who’s half-knowledgeable would be using the arch wiki, because they know the nixos wiki won’t have what they need.

What the nixos wiki is lacking is a) knowledgeable contirbutions, b) content moderation, and c) automation (bots that would clean up links, update references/versions, etc.) I hope this new wiki will incorporate this.

2 Likes
57

Most icons are the same. I think it’d be helpful to display the name too.

2 Likes