See this comment from @wamserma
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).
v1 (Go) or v2-beta (Rust)?
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
@cafkafk, thank you for the wiki, and thank you for eza (which I just installed on all my systems)
TCC compiler uses a mob branch
approach:
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.
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:
- provide an official wiki
- 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 (). The git storage module is pretty sweet too. nixos.wiki has needed an upgrade for a while.
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 :).
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?
Are you sure Flakestry counts as âOfficial?â It looks like it would be better suited to be in âCommunity,â unless Iâm missing something.
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.
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.
Most icons are the same. I think itâd be helpful to display the name too.