> Crux specific parts- but having two sources (Handbook and wiki) is
> somewhat confusing sometimes. Maybe merge the handbook into the wiki
> with an entry for installing Crux (like the installation guide on the
> Arch wiki)? The guide will walk the new user through a basic
> installation with links to several options (e.q. encrypting
> harddrive, using different bootloaders). At the end of the guide
> there can be some links to other entry (how to install packages,
> e.d.).
I am not into merging the handbook into the wiki idea. I'd rather
expand the wiki and make it a bit better organized. And after all, CRUX
never was out to hold the users hand. The user needs to self motivate
to read stuff, including upstream READMEs, wikis, etc.
{Arch,Gentoo,*}wiki are nice, but we don't have that userbase that
creates these documents as they go. There is a lot of work involved
and the main problem is time. Looking at repology [2] we see 18
maintainers [3] for CRUX. Some are duplicates, some have been inactive
for a very long time. The core team consists of just a few people.
So, with that said, I agree with the ground idea that we could use some
new users that could step up and help out the overall process.
> It would be helpful if there is a basic `how to compile your own
> kernel'-tutorial. Something along the lines of `make defconfig',
> enabling audio and video support, untick some of the wlan firmware
> drivers, etc. Copying the bzImage and System.map and updating the
> boatloader.
I am not sure about that, because it attaches to the point mentioned
above: CRUX doesn't hold the users hand. Setting up a bootloader,
however, is already explained [4]
Certainly it wouldn't be bad though to go into a bit more detail to get
things up and running. Advertising the updated iso otoh might be tricky,
I have no idea how much testing is done on them, so the official release
is always the safest bet as I see it. Testing is just a lot more work,
and if there is little to none done it's not a good choice to advertise
it. It's nice to have around though, and maybe a user wouldn't need to
join #crux to learn about its existance, so mentioning it on a wiki
page might be a good idea, with a warning about the status of it.
> Lastly a guide on creating and maintaining your own repo (which is
> part of the charm of using Crux I think), would be very helpful.
> Beerman / Tim's guide would be a great starting point IMHO.
>
https://gist.github.com/TimB87/6cf010c0c10d67faf98ae03e62ffb029Glad that it's helpful for you! It basically is just me scraping
together different notes I took along the way, that are scattered all
around ~.. there is still stuff missing and more that needs expansion.
I'll try to keep updating it, but I can't promise I'll be doing a lot
on that anytime soon.
Short note that a lot of code/procedures/.. came from romster, jaeger,
possibly others as well. I am just compressing stuff because I want to
have it for myself, but figured others might find it helpful as well.
> As for the documentation, for the most part it's a matter of
> reorganizing. Maybe a `further reading' section can be added at the
> end of an entry, with links to useful sources like the Arch wiki /
> offical kernel documentation and so on. The goal here is to keep it
> simple (of course ;-))
>
> I'll be happy to help out with (re)writing some parts.
> What do you think?
> Would this be helpful?
> Or are there other / better options?
My personal thoughts on how to make CRUX look more attractive:
- crux.nu as a whole could get an overhaul, if you ask me
-There is a great portdb replacement around which is not
official, but imo should be [5]
- cgit is fine but something like gitlab could combine that and
flyspray to be more of a unit and also offer a much greater
possibility to plan and execute projects. It could replace
the wiki with something a lot more powerful at the same time
(Imagine CI for core/opt? :-) )
- some saner defaults for pkgadd/pkgmk/prt-get..
- prt-get
- runscripts by default?
- writelog with rmlog_on_success by default?
- advertise /var/lib/prt-get.aliases more prominently
- pkgadd.conf
- actually don't upgrade prt-get.aliases
- pkgmk.conf
- IGNORE_MD5SUM (for good) by default?
- move the standard locations to maybe not cloud the
directory structure with distfiles and packges?
something like /usr/ports/{distfiles,packages} would
use the same partition, still, but keep things clean
and easier to overview for newbies
- IGNORE_NEW by default? Think about graphite2
and harfbuzz for example, or inkscape that
optionally provides poppler if the abi changed
again and is known to not work
- Advertising. I know, that sounds like selling out, but I mean more
in a way of seeking attention from youtubers etc that spread the
word. There is actually an interview around that basically does
that, talk about CRUX, from 2014 [6] :-)
- while we encourage users to create a repo, some of them in portdb
are unmaintained for a long time, or contain ports of questionable
quality. The new portdb already makes you more aware of 'questionable
content' - maybe it would be fair to filter "known 'bad' repos" from
the standard portdb search in the future? New users might not
care/know, and will be frustrated when stuff doesn't work in the
end, as they try to build an hopelessly outdated port
In my closing I'd like to say my thanks to the core team for their
hard work! CRUX is the linux flavor I love and compare everything else
to. Just like Fredrik said, if development would stop, I'd probably
just continue to use it on my own. I haven't found any other distro
that makes me feel half as comfortable as CRUX does.
Best regards
Tim
[1]
https://crux.nu/bugs/index.php?do=details&task_id=1201&project=1&pagenum=2[2]
https://repology.org/repository/crux_35[3]
https://i.imgur.com/GWK9fXs.png[4]
https://crux.nu/Main/Handbook3-5#ntoc11[5]
https://crux.ninja/portdb/[6]
https://www.youtube.com/watch?v=QtGhvbozIfI