Fwd: Re[2]: Thoughts on making Crux more `alive' and `attractive'.
Tuesday, June 23, 2020 11:13 PM +01:00 from Tim < tbier@posteo.de >: Hey Hans, hey everybody,
I promised an answer and I am still not really able to process my thoughts into one, but I'll try to keep the ball rolling here beacuse I'd love to see CRUX grow harder/better/faster/stronger too :-)
On Sun, 21 Jun 2020 23:18:11 +0200 Hans Bezemer < hbezemer@kliksafe.nl > wrote:
Also there is some good documentation (but may be improved). I do the best I can at doc.leetio.dev and wiki.leetio.dev if is useful just copy it. I feel the same way. There is one ticket in flyspray opened that actually tried to go over things, but didn't get too much attention [1] I have no idea how to attract people to this beautiful project. Although the somewhat steep learning curve belongs to the way Crux works, there can be some minor improvements made which may help newcomers finding their way around more easily.
I found that if one understand tar then understand crux, the only thing that will miss to is that text file with all the stuff installed in pure text.
Secondly, there is a lot of good documentation -especially on the
I don’t think I have «good» again I give my best ;)
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/6cf010c0c10d67faf98ae03e62ffb029
Glad 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 _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux -- silvino silva
-- silvino silva
Thanks for all the input guys. While pondering on it, I realised that compared to other distro's crux has a lot less `types' of users. Using mint or debian you can be an everyday user: don't worry about how maintaining packages work, just do a regular update and that's it. On the other end you can be a packager / maintainer and doing a lot of important but behind the scenes kind of things. And a lot in between. On CRUX you've to able / are encouraged to maintain some ports and be able to keep your kernel up-to-date. This means that the users are more or less peers (with of course some being primus inter pares). Well, that was a more general thought... Let's dive in. On 20/06/24 09:45PM, silvino silva wrote:
??
??
Tuesday, June 23, 2020 11:13 PM +01:00 from Tim < tbier@posteo.de >: ?? Hey Hans, hey everybody,
I promised an answer and I am still not really able to process my thoughts into one, but I'll try to keep the ball rolling here beacuse I'd love to see CRUX grow harder/better/faster/stronger too :-)
On Sun, 21 Jun 2020 23:18:11 +0200 Hans Bezemer < hbezemer@kliksafe.nl > wrote:
Also there is some good documentation (but may be improved). I do the best I can at doc.leetio.dev and wiki.leetio.dev if is useful just copy it.
I feel the same way. There is one ticket in flyspray opened that actually tried to go over things, but didn't get too much attention [1] I have no idea how to attract people to this beautiful project. ??
Although the somewhat steep learning curve belongs to the way Crux works, there can be some minor improvements made which may help newcomers finding their way around more easily.
I found that if one understand tar then understand crux, the only thing that will miss to is that text file with all the stuff installed in pure text. ??
Secondly, there is a lot of good documentation -especially on the
I don???t think I have ??good?? again I give my best ;)
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] I agree that the documentation has to be kept as minimal as possible. It should be geared at getting CRUX up and running, creating and maintaining
That's some cool stuff you got there, Silvino! ports and on how to become a fellow maintainer.
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.
Maybe we can make the testing process more transparent and give other users the opportunity to preform one or tests and share the results.
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/6cf010c0c10d67faf98ae03e62ffb029
Glad 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]
I looked at the portdb replacement and that looks nice. This would give new users a good insight in how useful a repo might be. How are the repo's checked? Are ports downloaded and checked if they build? What are the disadvantages of making this portdb the default db?
?? - 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? :-) )
Tim, Could you elaborate on why moving to gitlab would be a better solution?
??- 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?
I agree on this. Also found Steve's suggestion on creating a col-get for adding collections a good one. In addition I would like to be able to nitpick specific ports from a user repo. I've tested this a while ago by modifying the httpup driver and adding a line in the *.httpup files containing a comma separated list of ports which are to be downloaded. I got it working but it wasn't perfect yet.
- 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
This I thought of also. It would make things cleaner. I'm thinking of having a designated build computer and use the packages to install updates on other (older) computers. Having packages in their own directory would be handy.
- 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] :-)
Yes I agree. I was thinking of Luke Smith, although a avid Arch user, he really `advocates' scripting and keeping things simple.
??- 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
I think the new portdb takes care of this issue for the most part.
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. I totally agree, thanks so much. When I got CRUX up and running it was like coming home.
The thread is becoming a bit long, would it be wise to give each above mentioned subject it's own email thread? Something like: 1. Documentation / website `overhaul' 2. Technical stuff default settings updating / testing iso's adding col-prt 3. Promotion Or maybe weed out the thread. I don't know what is customary. Regards! Hans
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 ?? _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux ??
?? ?? -- silvino silva ?? ?? ---------------------------------------------------------------------- ?? -- silvino silva ??
_______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
participants (2)
-
Hans Bezemer -
silvino silva