@civodul The GNU Shepherd initial commit dates back to 2012-07-10 and this npm shepherd 2018-07-14, but considering that GNU Shepherd is practically only popular among GNU folks, I'm not surprised that npm Shepherd is the one that have got picked by Nix folks. Fortunately the package description in Nix repo is pretty clear about what user should expect to get.
To save others time, I'm gonna put the links to initial commits here :)
@ramin_hal9001
Tbh, as much as I like Guix and Guile to prosper (I genuinely do), the sad reality is that the barrier to entry is so damn high and even people like me with some understanding of Guile and Guix are repelled. I have a feeling that the level of barrier to entry is the same when it comes to GNU Shepherd too.
So for who wins what, if I want to win the bet, I would never put my money on these.
Just to clarify: I use Guix time-machine in daily basis for my research
@Mehrad@civodul it is true, Guix will need a lot more engineering resources (full-time, paid software developers) before it could become useful. It especially lacks hardware support unless you go out of your way to setup non-free software package channels.
For the most part, if you stick to only using the main package channels, and don't do anything fancy for developing your own apps like changing package dependencies or build options, everything just works. This at least gives you access to instant roll-backs, and things like GNU Shepherd.
I prefer to use Guix as a package manager, in particular, I will use Guix as an alternative to FlatPak, Snap, and AppImage. It co-exists perfectly with any Linux distro's native package manager. So I let my Linux distro handle my operating system and desktop environment, and I install my favorite apps with Guix.
@ramin_hal9001
I do the same. I use Manjaro and I only use Guix for creating reproducible development environment using the time-machine. So I don't use GNU Shepherd.
My main complaint about Guix is not hardware support, but rather lack of cohesive documentation, lack of unified website, lack of using "modern" issue tracker and contribution method (mailing list is a horrible idea), and most importantly, lack of forum (IRC is not a forum even if you cache it and make it searchable).
@Mehrad@ramin_hal9001 Not sure how we went from the package name collision to this discussion…
Regarding “lack of cohesive documentation” and “lack of unified website”, could you point out specific issues or improvements that you think could be made?
for the "lack of unified website":
There is no single entry point. For example as one of the most confusing parts: there is https://packages.guix.gnu.org/ and https://hpc.guix.info/browse to search for packages, (why?) and worse that that, the hpc sometimes falls back to the other one!!
Or there is no unified place to find channels. The packages.guix.gnu.org is completely unclear which channels it includes (poor documentation?), and
🧵 👇🏼
There are helpful pages like https://data.guix.gnu.org/repository/1/branch/master/package/r which is super helpful for people who want to use time machine, but it is in a weird place that is practically impossible to find if I didn't bookmarked it the first time someone pointed me to it!
Also on the same "unified website" topic, see how the layout and theme of all these guix pages are different
🧵 👇🏼
🧵 👆🏼 @civodul@ramin_hal9001
The correct approach imho is to have a clear path for the user to find the information they need. Nix is on Github and because of that users can dive into it using lots of quality-of-life features that Github provides (e.g what you did by sharing a link that contains specific line of a file).
As for "lack of cohesive documentation", Guix extremely relies on info pages. But that is not well known to 99.9% of world population.
🧵 👇🏼
For instance, go to https://guix.gnu.org/ (official Guix website) and try to find a button of link that a beginner user can use. try searching for terms like "how to get started", or "documentation" or "examples", ...
Documentation imho should always use long for of args.
Documentation should have tangible examples that user can literally copy-paste and toy around with to learn, but take the time-machine section for example:
Why is it this weird and complicated? I use time-machine followed by -- shell, but there is no mention of chaining them to get a working environment No one need gnu hello in time machine, but people need Python or R or Perl.
@Mehrad@ramin_hal9001 Okay yes, sure, “we” (that includes yourself) can improve that ‘guix time-machine’ section of the manual. This is useful feedback, thanks!
I definitely share the goal of accommodating a wide range of people. The challenge for the Guix community has been to achieve that without giving in to GitHub, Slack, and other surveillance capitalism platforms.
I truly hope that I have conveyed two things in this thread:
answer to your question
my personal frustration with this spaghetti of websites and the current state of documentation
Guix is super cool and I for one would love to keep using it, but my enthusiasm is not enough. Guix should also accommodate wider range of people and be more inclusive by having better entry points, better examples, better communication platforms, and etc.
Part of the problem is that Guix can be used as an Linux distro and a package manager, and the package manager is highly configurable with various channels. So your "entry point" to Guix might be different from other people, depending on how you want to use it. I think the Guix homepage does a pretty good job of providing resources for general purpose use cases. It seems to me that if you are using the HPC channel, you are not in the group of people who use Guix for general purposes.
The reason why is because there are multiple channels for packages. I recommend you use Guix command line tools to search for packages, rather than using the websites, because the Guix command line will search all the channels that you have access to, rather than you needing to know which channel provides which package and searching the channel website.
guix package --search='name-of-thing*'
> "Guix extremely relies on info pages. But that is not well known to 99.9% of world population."
For what it's worth, I really love the Info manual pages, it is very easy to find all the information I am looking for in this documentation, as long as you use Emacs (which I do) or the stand-alone "info" CLI utility. All you need to do is use the search features: index search (press "i" and type your query with tab completion) and menu search (type "m" and type your query with tab completion). The "index" is the index of all keywords in the manual, it is good to use if you do not yet know what you are looking for. The "menu" is a list of all documentation subsection titles, it is good to use if you already know what you are looking for.
>> I recommend you use Guix command line tools to search for packages, rather than using the websites, because the Guix command line will search all the channels that you have access to
Which is exactly the problem. I rather include a channel to the mix than to package something myself. Less maintenance burden on my soulder. That is why https://toys.whereis.xn--q9jyb4c/ worth millions of times more than Guix official website for the general user!
>> For what it's worth, I really love the Info manual pages, it is very easy to find all the information I am looking for in this documentation, as long as you use Emacs (which I do).
Yes, but it is your setup, which is very similar to the setup of a very tiny minority on this planet.
I use Emacs and I wholeheartedly dislike info pages. There is no breadcrumb and veeery easy to get lost. I use them unfortunately because Emacs documentation is there.
🧵 👆🏼 @ramin_hal9001
The aim of that thread was not ask for help, but was to clarify why from my perspective the Guix lacks certain things and what can in my opinion be improved.
You want to know why Nix is more popular? Well, big part of it is the on-boarding process. Did you attend that patch review session from Guix London? Zero preparation, total chaos to the extent that they literally said they don't record it because of the chaos! That could be good entry point but was it?
One last remark: I am not a fan of Nix and I don't use it in daily basis (I have a dedicated laptop to test stuff and play around with it on weekends if I feel like it). But I do use Guix (not by force, but by my own choice) in daily basis at work and at home. I even spent last weekend working on a proposal on some parts that Guix can be improved by making certain things automated and less error prone to beginner user. So I'm invested in Guix, but certain parts hurt
Add comment