Thoughts on making Crux more `alive' and `attractive'.
Dear fellow Crux-users, Recently there was some discussion in the IRC channel about how to make crux more `alive' and `attractive'. Being a relative new user I would like to share my thoughts. First of all, Crux has a lot of good things to offer: It's simplicity and script based orientation are unique. The package management through ports is simple but effective. Also there is some good documentation (but may be improved). And (last but not least) there's a friendly and helpful community. When I started out with Crux it took a while before I had everything up and running. Although I had used Arch for some while, went through the LFS-book twice, there was still a lot of ground to make up before I had my laptop configured the same way when using Arch. I had to hone several skills: building my own kernel, creating some udev rules, setting up networking using wpa_supplicant only (I know nm is at hand) and so on. 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. First of, maybe Crux can become a rolling distro, with a new iso every month / 2 months. In practice it already seems to be. There are unofficial updated iso's and once you got everything installed everything can be kept up-to-date. As a new user I used the official iso (which is good practice I think), but after building the kernel, running a sysup was a bit of a showstopper. Almost all of the packages needed to be updated. When using the more recent unofficial iso, this is obvious not the case. Secondly, there is a lot of good documentation -especially on the 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.). 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. 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 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? Kind regards, Hans
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 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]
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.
Secondly, there is a lot of good documentation -especially on the 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 24 Jun 2020, Tim wrote:
Hey Hans, hey everybody,
Hi everyone, in general, I agree with Tim, I'll only point out, where I have a (slightly) different opinion.
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? :-) )
This may sound nice, but it will also be a lot of work - and the benefit might be smaller than expected.
- 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, it would help to be able to sort by version in the portdb search. My usual approach is: "I need port 'x'" -> search for 'x' in the portdb - -> look at the 3 results for 'x' -> take the newest -> try to build -> add it to my repo -> try to improve further (e.g. newer version) If everyone is encouraged to create their own repo (and if it's really easy), then we will have one repo per user in the end - and I don't see, why that would be bad. I think, it's hard to mark repos as a whole as "good content" or "bad content" - I, for example, have definitely "bad content" in my repository: Stuff, that noone besides me uses. But otoh, I think, this does not apply to *everything* in my repo :-) regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl7zBakACgkQCu7JB1Xa e1rK3hAAu/UeFvJ2OK33R+7hnA0+4zXHefIFRCYJcpkrv8AA3z6QhIkX192bm/pB pUkQFPT9S5BC2HxY8PW7DgQ2rl8OEwDUcHYqzZVXymbE+rynIqoYgvfmmHnLS6+O bwNnirpAGtty0gxDFVd5qF1sbniIr33hPZwUKoplTwECg2OaNqZkFRusxT52tui4 vMk+5D1b5FX7jYY8Hz/ZoCXw2h8zjSkuoALeORFdseOoKjM36+2lLcDiesNd2Dif vqamewsN7KyYRtOYNZZsGXoV6xnO1QQ4nxseO3vv0yc3AjbEvv/UzkCHYoJ1S0MI s7BFyXT/2hb2X2em0P2CrJI/++UIm6C9oxedWaX3elLmtcJ5PWtWJJSYM9XaUhtZ jepFeozHjkV/MpbvtTlKggZ/MpaBEx5f748wUiKSbkGnhsQusCC9If7P4EvDnUJa Rd6KQg+xDWnDHszNMoN9lDjeqnlFFzA26HTiMvwXzgezXF6H2R1P2PVW1Xhh14Tu le0m7OMCRmfTE5F+F59rRDYbmCILEeSqMcMppfIMyNR8Wuw62SbFnVRLh0NMuqj/ bBxyiutPXFh/rYm/024wMHfMw7BWvrkMk9wCSzupofME2mewo/OgCAHVNaUnwrnp 7GNVbHWc3qufOoSWVLve/e5W1X28WTL4uDOA0pTX0iLNg/CFBhc= =K973 -----END PGP SIGNATURE-----
Hi Erich, hi everybody On Wed, 24 Jun 2020 09:49:59 +0200 (CEST) Erich Eckner <crux@eckner.net> wrote:
- cgit is fine but something like gitlab could combine that ... This may sound nice, but it will also be a lot of work - and the benefit might be smaller than expected.
Well, I am not saying all the features are needed, but migrating the git repos is swiftly done, tickets from flyspray might be a bit harder but it's not like we are having a lot of tickets open and flypsray could still be accessible as read-only for history reasons if there is no way of importing the entire db. CI is just a wish :) I know christmas won't come early. The basic idea is to have a platform that makes our development process more visible and maybe a bit more agile? (don't stone me, I'm not whipping you through a sprint :))
I think, it would help to be able to sort by version in the portdb search. My usual approach is: "I need port 'x'" -> search for 'x' in the portdb - -> look at the 3 results for 'x' -> take the newest -> try to build -> add it to my repo -> try to improve further (e.g. newer version)
I do it the same way, and I imagine that most CRUXers do it like that. A function like this surely would help to guide newbies to pick the best decision.
If everyone is encouraged to create their own repo (and if it's really easy), then we will have one repo per user in the end - and I don't see, why that would be bad. I think, it's hard to mark repos as a whole as "good content" or "bad content" - I, for example, have definitely "bad content" in my repository: Stuff, that noone besides me uses. But otoh, I think, this does not apply to *everything* in my repo :-)
I really try to keep my public ports, as clean as possible. Same counts for my non public ports, but the rules are less strict there :-) While encouraging users to get active, I feel like it's also important to encourage a good quality. Those "work on my system" kind of ports really aren't fun to deal with and will drive newbies away, if they aren't able to get out of that mess or get stuff running like it is supposed to. Have a great day, Tim
Hi All, I wanted to throw in too that I agree that there should perhaps be separate handling for "personal" ports of things. I've spun through a few of them and, as expected, get mixed results. I suppose the argument could be made "We already have core, opt, contrib , etc; anything else should be treated like the wild-west" I personally am mostly happy with how things are now..with the only exception being that (forgive me I forget the unit term) adding other ports-collections, take romster for instance, AFAIK the process to add a collection is a manual process and I can't just one-line it. I would hope there'd be like a Col-get in addition to Prt-get where I could : col-get install romster and then prt-get the ports inside that collection. Or maybe that already exists and i'm totally off track. Other than that, Crux does all the things I want it to and , of absolutely paramount importance, it does not do the things I never want my OS to do. Someone mentioned updating the website crux.nu, I have mixed feelings. In a world of flashy interfaces and visual chaos, crux.nu is kind of a nice oasis of simplicity. I absolutely would not change how it functions in terms of presenting information, though I do agree manuals/wikis could be more supportive and explanitory. On Wed, Jun 24, 2020 at 3:21 AM Tim <tbier@posteo.de> wrote:
Hi Erich, hi everybody
On Wed, 24 Jun 2020 09:49:59 +0200 (CEST) Erich Eckner <crux@eckner.net> wrote:
- cgit is fine but something like gitlab could combine that ...
This may sound nice, but it will also be a lot of work - and the benefit might be smaller than expected.
Well, I am not saying all the features are needed, but migrating the git repos is swiftly done, tickets from flyspray might be a bit harder but it's not like we are having a lot of tickets open and flypsray could still be accessible as read-only for history reasons if there is no way of importing the entire db. CI is just a wish :) I know christmas won't come early.
The basic idea is to have a platform that makes our development process more visible and maybe a bit more agile? (don't stone me, I'm not whipping you through a sprint :))
I think, it would help to be able to sort by version in the portdb search. My usual approach is: "I need port 'x'" -> search for 'x' in the portdb - -> look at the 3 results for 'x' -> take the newest -> try to build -> add it to my repo -> try to improve further (e.g. newer version)
I do it the same way, and I imagine that most CRUXers do it like that. A function like this surely would help to guide newbies to pick the best decision.
If everyone is encouraged to create their own repo (and if it's really easy), then we will have one repo per user in the end - and I don't see, why that would be bad. I think, it's hard to mark repos as a whole as "good content" or "bad content" - I, for example, have definitely "bad content" in my repository: Stuff, that noone besides me uses. But otoh, I think, this does not apply to *everything* in my repo :-)
I really try to keep my public ports, as clean as possible. Same counts for my non public ports, but the rules are less strict there :-) While encouraging users to get active, I feel like it's also important to encourage a good quality. Those "work on my system" kind of ports really aren't fun to deal with and will drive newbies away, if they aren't able to get out of that mess or get stuff running like it is supposed to.
Have a great day,
Tim _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
Hi Steve, On Wed, 24 Jun 2020 11:33:41 -0500 Steve Volumetric <volumetricsteve@gmail.com> wrote:
Someone mentioned updating the website crux.nu, I have mixed feelings. In a world of flashy interfaces and visual chaos, crux.nu is kind of a nice oasis of simplicity. I absolutely would not change how it functions in terms of presenting information, though I do agree manuals/wikis could be more supportive and explanitory.
I am not saying that it should change it's style. But information is too fragmented for my taste, and the quality of presentation of information could improve a lot. -- Tim Biermann
Steve Volumetric wrote in <CABr5XP30gFzkr_dA_edQbXCTAz7hLRjXEW18q8wQ2NVhcVb7VA@mail.gmail.com>: ... |I personally am mostly happy with how things are now..with the only \ Yeah. ... |Other than that, Crux does all the things I want it to and , of absolutely \ |paramount importance, it does not do the things I never want my OS to do. I mean, rc.d "status" stuff could return the actual error code. rc scripts could offer hooks so that updating them does not cause trouble, because hooks could be in rc.conf or so. I.e., i load entropy, get my hostname via the kernel command line, may adjust the EFI kernel if booting a new kernel succeded, adjust loadkeys because my G key is broken. Whatever. |Someone mentioned updating the website [1]crux.nu[/1], I have mixed \ |feelings. In a world of flashy interfaces and visual chaos, [2]crux.nu\ |[/2] is kind of a nice oasis of simplicity. I absolutely would |not change how it functions in terms of presenting information, though \ Yeah. |I do agree manuals/wikis could be more supportive and explanitory. I like the handbook. The wikis of the world are terribly outdated or incomplete, this one is, too. You find some pearls, but mostly... And things like ArchLinux Wiki are now systemd manuals. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
More and more projects migrate to gitlab for reasons, just two days ago KDE announced their move and the reasons behind it: https://about.gitlab.com/blog/2020/06/29/welcome-kde/ On Wed, 24 Jun 2020 10:21:09 +0200 Tim <tbier@posteo.de> wrote:
Hi Erich, hi everybody
On Wed, 24 Jun 2020 09:49:59 +0200 (CEST) Erich Eckner <crux@eckner.net> wrote:
- cgit is fine but something like gitlab could combine that ... This may sound nice, but it will also be a lot of work - and the benefit might be smaller than expected.
Well, I am not saying all the features are needed, but migrating the git repos is swiftly done, tickets from flyspray might be a bit harder but it's not like we are having a lot of tickets open and flypsray could still be accessible as read-only for history reasons if there is no way of importing the entire db. CI is just a wish :) I know christmas won't come early.
The basic idea is to have a platform that makes our development process more visible and maybe a bit more agile? (don't stone me, I'm not whipping you through a sprint :))
I think, it would help to be able to sort by version in the portdb search. My usual approach is: "I need port 'x'" -> search for 'x' in the portdb - -> look at the 3 results for 'x' -> take the newest -> try to build -> add it to my repo -> try to improve further (e.g. newer version)
I do it the same way, and I imagine that most CRUXers do it like that. A function like this surely would help to guide newbies to pick the best decision.
If everyone is encouraged to create their own repo (and if it's really easy), then we will have one repo per user in the end - and I don't see, why that would be bad. I think, it's hard to mark repos as a whole as "good content" or "bad content" - I, for example, have definitely "bad content" in my repository: Stuff, that noone besides me uses. But otoh, I think, this does not apply to *everything* in my repo :-)
I really try to keep my public ports, as clean as possible. Same counts for my non public ports, but the rules are less strict there :-) While encouraging users to get active, I feel like it's also important to encourage a good quality. Those "work on my system" kind of ports really aren't fun to deal with and will drive newbies away, if they aren't able to get out of that mess or get stuff running like it is supposed to.
Have a great day,
Tim
-- Tim Biermann
Please everything less github, crosstalk going on how free and opensource become fully dependent on Microsoft. A simple stuff there just to point back to official website. Crux don't have to be the most famous one because it don't lack self confidence. On July 1, 2020 9:51:11 AM GMT+01:00, Tim <tbier@posteo.de> wrote:
More and more projects migrate to gitlab for reasons, just two days ago KDE announced their move and the reasons behind it:
https://about.gitlab.com/blog/2020/06/29/welcome-kde/
On Wed, 24 Jun 2020 10:21:09 +0200 Tim <tbier@posteo.de> wrote:
Hi Erich, hi everybody
On Wed, 24 Jun 2020 09:49:59 +0200 (CEST) Erich Eckner <crux@eckner.net> wrote:
- cgit is fine but something like gitlab could combine that ... This may sound nice, but it will also be a lot of work - and the benefit might be smaller than expected.
Well, I am not saying all the features are needed, but migrating the git repos is swiftly done, tickets from flyspray might be a bit harder but it's not like we are having a lot of tickets open and flypsray could still be accessible as read-only for history reasons if there is no way of importing the entire db. CI is just a wish :) I know christmas won't come early.
The basic idea is to have a platform that makes our development process more visible and maybe a bit more agile? (don't stone me, I'm not whipping you through a sprint :))
I think, it would help to be able to sort by version in the portdb search. My usual approach is: "I need port 'x'" -> search for 'x' in the portdb - -> look at the 3 results for 'x' -> take the newest -> try to build -> add it to my repo -> try to improve further (e.g. newer version)
I do it the same way, and I imagine that most CRUXers do it like that. A function like this surely would help to guide newbies to pick the best decision.
If everyone is encouraged to create their own repo (and if it's really easy), then we will have one repo per user in the end - and I don't see, why that would be bad. I think, it's hard to mark repos as a whole as "good content" or "bad content" - I, for example, have definitely "bad content" in my repository: Stuff, that noone besides me uses. But otoh, I think, this does not apply to *everything* in my repo :-)
I really try to keep my public ports, as clean as possible. Same counts for my non public ports, but the rules are less strict there :-) While encouraging users to get active, I feel like it's also important to encourage a good quality. Those "work on my system" kind of ports really aren't fun to deal with and will drive newbies away, if they aren't able to get out of that mess or get stuff running like it is supposed to.
Have a great day,
Tim
-- Tim Biermann
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sun, 21 Jun 2020 23:18:11 +0200 Hans Bezemer <hbezemer@kliksafe.nl> wrote:
Dear fellow Crux-users,
What do you think? Would this be helpful? Or are there other / better options?
I forgot to post that. I asked James Mills (prologic) about his opinion as he mentioned the thread. This is his reply: 10:34 beerman prologic: if you got opinions on the 'making crux more alive' matter, feel free to share some thoughts on the ml though 10:35 prologic I maintain my position that we should have presence on Gihtub. 10:35 prologic I don't think its necessary to have an ISO more frequently than we do 10:36 prologic I think improving the docs/handbook is a good idea 10:36 prologic nice pretty docs is always good 10:37 prologic besides this you're only left with marketing-type stuff, you would hurt CRUX's design if you significantly change too many things -- or it becomes Arch (which is what Arch borrowed from / took inspiration from) 10:37 » prologic has been around for a long whiel :) prologic even back to Per Liden days :) 10:38 prologic as has jaeger and tilman and Romster :) 10:38 prologic Yes those docs-style wikis are good 10:38 prologic with the "Edit this page on Github" type thing 10:38 beerman this needs to be on the ml 10:38 prologic that has the least friction I think 10:38 prologic beerman you put it there :) 10:38 prologic I don't have time sorry :) -- Tim Biermann
I feel like a lot of points from this thread have been worked on with the past few weeks server work :)
Well the simplest change would be to put noteworthy news post on the website. at least once a year! A synopsis of the recent changes would be of interest. maybe another outlining tasks for 24/25 ? Sent from my iPhone
On 2 Mar 2024, at 00:01, Tim Biermann <tbier@posteo.de> wrote:
I feel like a lot of points from this thread have been worked on with the past few weeks server work :) _______________________________________________ CRUX mailing list -- crux@lists.crux.nu To unsubscribe send an email to crux-leave@lists.crux.nu
You are certainly right with that! I got that on my todo list and I will try to post an insightful news post soon™ :-)
Hi everyone, Kudos to Tim for all the updates these past few weeks! There has been a bit of a learning curve (e.g., creating pull requests in the new Gitea instance, verifying that all our subscriptions transferred correctly from pipermail to hyperkitty, or reinstalling the pmwiki plugin that generates a table of contents), but for the most part all the new services appear to be working smoothly. On Tue, 23 Jun 2020 Tim wrote:
- 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.
One side effect of the bridge between IRC channels and Matrix rooms might be an increased visibility of CRUX in the wider world. But we've already run into some reports of abandoned Matrix rooms still advertising CRUX 3.6, so it might need more work to fully unify these two chat protocols. Despite prologic's misgivings about hurting CRUX's design if we change too many things, and Erich's warning that "the benefit might be smaller than expected", I can't see any harm in opening up the CRUX chat to Matrix users.
- some saner defaults for pkgadd/pkgmk/prt-get.. - runscripts by default? - writelog with rmlog_on_success by default? - advertise /var/lib/prt-get.aliases more prominently
I do find it odd that prt-get.aliases is so poorly documented. None of the man-pages installed by prt-get even mention this file, and the example that we distribute under /etc does not demonstrate the one-line mechanism for declaring that a package can serve as a replacement for more than one dependency: https://git.crux.nu/tools/prt-get/src/branch/master/src/pkgdb.cpp#L83 Only by inspecting the source code will the user discover the possibility of writing a line with a comma-separated list of dependencies satisfied by a given package. If the lack of documentation means that nobody has been writing alias lines like that, then we've been allocating memory to the private variable m_splitAliases for no good reason; it would be simpler just to ask the user to put the information on separate lines of prt-get.aliases. In the fork of prt-get that I've been working on, some of the new capabilities include: - do something useful with the optional dependencies line - support Alan's --group flag to abort an operation if one target fails - remove build log when uninstalling a port - handle correctly a mix of installed and not-yet-installed targets passed as arguments to 'install' or 'update' (FS#1910) - respect --install-root when runscripts is enabled If any of these features sound interesting, feel free to download my forked repo and try it out. Perhaps later this weekend I'll get around to adding the feature that lets the 'listorphans' command take aliases into account, so that pkgfoster does not prompt for removal of a package that actually satisfies a dependency. On Wed, 24 Jun 2020 Steve Volumetric wrote:
adding other ports-collections, take romster for instance, AFAIK the process to add a collection is a manual process and I can't just one-line it.
Yesterday's IRC discussion mentioned sepen's portdbc tool, which allows you to do a one-liner like portdbc getup baguette | doas tee /etc/ports/baguette.httpup (assuming you know the name of the collection you want to add). Searching for ports by name does not work with the latest rewrite of the portdb, but jaeger gave us a shell function to fill that gap: https://libera.irclog.whitequark.org/crux/2024-03-15#36004199; On Thu, 25 Jun 2020 Steffen Nurpmeso wrote:
I like the handbook. The wikis of the world are terribly outdated or incomplete, this one is, too. You find some pearls, but mostly...
I agree with Steffen. It's easy to criticize a wiki for omitting a page that would have addressed your current question directly. But a handbook that can be read from start to finish in a few hours is better at getting the new user oriented to the CRUX way of doing things. With the solid base of understanding imparted by the handbook, a new user is empowered to search more intelligently for answers in the upstream documentation. If they eventually decide to share what they learned by creating a page on the CRUX wiki, great, but there's no expectation that new users should contribute in that manner. Contributions in the form of bug reports and suggestions to the port maintainers are arguably more valuable (hence the switch to Gitea for its increased user-friendliness). On Mon, 4 Mar 2024 Joseph Bennie wrote:
A synopsis of the recent changes would be of interest. maybe another outlining tasks for 24/25 ?
Some time ago I started a TODO page for the next release (https://crux.nu/Wiki/TODO37-1). It's impressive to see how many of those bullet points have already been addressed! In short, Tim's comment "thanks to the core team for their hard work!" deserves to be repeated. They carry out their work in dignified silence, refraining from drawing attention to themselves but letting a rock-solid distro and a no-nonsense website testify to their labors. Cheers, John
participants (9)
-
Erich Eckner -
Hans Bezemer -
John McQuah -
Joseph Bennie -
Silvino Silva -
Steffen Nurpmeso -
Steve Volumetric -
Tim -
Tim Biermann