Re: The Little Guixer

[Yasuaki Kudo]

Let's do this together, all of us, and publish in complete Free Software format 
compiled by Guix 😄😄

> On Jun 4, 2022, at 01:41, Ludovic Courtès  wrote:
> 
> Sounds like a great idea; feel inclined to do so?  :-)
> 
> Ludo’.

Re: linux-libre updates, timeliness

[Yasuaki Kudo]

Hi,

Just out of curiosity, is it the case if only Linux Kernel team itself 
separated the controversial (with GNU folks, at least 😄) aspect of Linux as 
some build option, we don't have to maintain this  "LinuxLibre" in the first 
place?

Cheers,
Yasu



> On Oct 5, 2020, at 22:53, Ludovic Courtès  wrote:
> 
> Hi Leo,
> 
> Leo Famulari  skribis:
> 
>> I just pushed commit 51eb3e11 [0], bringing our linux-libre kernel
>> packages up to date.
>> 
>> It's September 30 here. The commit is dated September 28, because that's
>> when I made it. These kernels were released upstream on September 26. 
> 
> Of course we can always do better, but I think 4 days is reasonable.
> 
>> Personally, I am okay with the risks implied by this kind of timeframe,
>> but as a distro we should try to do these updates more quickly. Ideally,
>> they should be updated as soon as the sources are available and the
>> packager has tested the changes. I am committed to helping maintain the
>> linux-libre packages, but I won't always update our packages right away.
>> 
>> Everyone can contribute here! Minor linux-libre kernel updates can be
>> relied upon to work. They almost never cause blocking problems, based on
>> the lack of bug reports about them.
> 
> What update, build, and testing recipe would you recommend to someone
> willing to help?
> 
> Thanks for your work, much appreciated!
> 
> Ludo’.
> 

Re: linux-libre updates, timeliness

[Yasuaki Kudo]

Sorry, I meant to ask really a simple question because I just wanted to 
understand LinuxLibre.   😄  There is an explanation here:

https://en.m.wikipedia.org/wiki/Linux-libre

But I was intrigued, that it felt like a situation where a vegetarian would 
order a pizza from a restaurant that doesn't offer a vegetarian option so he 
has to painstakingly remove meat from it, while it would have been better if 
the cook could make it without the meat in the first place 😄  

Is above a fair analogy for the Linux Kernel?

Cheers,
Yasu


> On Oct 6, 2020, at 23:48, Leo Famulari  wrote:
> 
> On Tue, Oct 06, 2020 at 06:12:15AM +0900, Yasuaki Kudo wrote:
>> Just out of curiosity, is it the case if only Linux Kernel team itself
>> separated the controversial (with GNU folks, at least 😄) aspect of
>> Linux as some build option, we don't have to maintain this
>> "LinuxLibre" in the first place?
> 
> If you are asking if linux-libre is slowing down the process of updating
> the kernel for Guix users, the answer is that it's not a significant
> delay.

Re: Advantages over Nix?

[Yasuaki Kudo]

Hi!

I was in almost the situation a few months ago and I spent a few weeks trying 
both NixOS and Guix.

To me, Nix felt more like a 'minimum viable product' for a startup company - it 
works well but seems to suffer from its own success - practicality is given 
priority over engineering cleanliness.

Guix felt the opposite - package installations and upgrades felt way slower (it 
takes much longer to download, requires more frequent lengthy compilation) , 
not to mention that it is outright useless without proprietary packages 
augmented by nonguix, etc, if you happen to have critical hardware unsupported 
by LibreLinux, the kernel that has been stripped of proprietary code.

I am no expert in neither Nix nor Guix but toward the end of my analysis (I 
have since moved to another assignment), I thought Guix would be better for the 
company because of its superior design (I thought)

I watched this NixOS roadmap video https://youtu.be/8M6yvJC00J4 and thought it 
might be running into many issues that could be more easily addressed by Guix.  
 I think one thing that was discussed was that Nix cannot manipulate nested Nix 
expressions (in order to use Nix as a replacement for Make)

I don't know enough about Guix to see if it directly solves that problem but I 
thought the idea of using Scheme was precisely to avoid reinventing the wheel.

I think Guix packages are easier to understand (I compared package definitions 
of Guix and Nix) and Guix has a far better reference manual compared to Nix.   
But I have not found a good introduction guide to Guix yet.   I was following 
https://guix.gnu.org/cookbook/en/html_node/Direct-checkout-hacking.html  but it 
was far from complete.  To be fair, https://nixos.org/guides/nix-pills/ has a 
lot of outdated information as well...

I wish I could be more precise but this is all I know and I appreciate your 
question!!!

Cheers,
Yasu

> On Oct 27, 2020, at 01:15, zimoun  wrote:
> 
> Dear,
> 
>> On Mon, 26 Oct 2020 at 13:42, Taylan Kammer  wrote:
>> 
>>> On 26.10.2020 11:41, zimoun wrote:
>> 
>> I think pack -f docker is going to be the "killer feature" in this case.
>> 
>> Well, the following doesn't seem so complicated either actually:
>> 
>>   https://nix.dev/tutorials/building-and-running-docker-images.html
>> 
>> But I really like how 'guix pack' can generate a tarball just as well,
>> which could be deployed and tested anywhere...
>> 
>> I'll need to make a few more comparisons.
> 
> Do not miss the '--save-provenance' option. ;-)
> It saves the profile/manifest which can be used to rebuild one
> manifest.scm file.  You could be interested in [1].  I am running out
> of time, but the profile/manifest->manifest.scm converter could be
> nice to have. :-)
> 
> 1:
> 
> 
> All the best,
> simon
> 

Re: Reminder: online Guix Day Conference

[Yasuaki Kudo]

Just curious, what time of day?  😄

> On Nov 3, 2020, at 22:33, Julien Lepiller  wrote:
> 
> Hello guixers!
> 
> The first online Guix Day Conference on Sunday November, 22nd.  This
> conference is open to everyone and will be held entirely online.  No
> registration fee.
> 
> We have received only a few proposals.  Do not be shy!  Please drop us
> an email with your ideas: what you would like to talk about or what you
> would like to discuss.  We are looking for more talk proposals, as well
> as people who are willing to lead discussion sessions with no talk
> (BoF).
> 
> We previously asked you to send your proposal to guix-devel@gnu.org,
> but we understand that a public mailing list might be intimidating.
> Please send your proposals and ideas to guix-d...@gnu.org instead, a
> private alias for the organizers.
> 
> 
> Important dates:
> 
>  + November 6th: Deadline for talk proposals
>  + November 14th: Deadline for releasing your pre-recorded talks.
>  + November 16th: Release of the schedule
>  + November 22nd: Conference day!
> 
> 16th to 21st: watch the talks!
> 
> The agenda for Sunday is:
> 
>  + pre-recorded talks with live question and answer sessions
>  + birds of a feather (BoF) sessions
>  + lightning round talks, if possible
>  + hack together
> 
> Read more details at:
>  
> 
> Spread the word!
> 

Re: Reminder: online Guix Day Conference

[Yasuaki Kudo]

Hi Julien,

Great, I will looking forward to attending the early part of it! (I live near 
Tokyo and go to sleep early 😅)  

BTW, I use Guix on my Microsoft Surface Book using Windows Subsystem for Linux 
https://github.com/giuliano108/guix-packages/blob/master/notes/Guix-on-WSL2.md 
, in addition to my desktop PC.

It would be great if someone can present an 'Experience Report' of running Guix 
on Windows!

Another suggestion - I think Guix is well suited for cooperative organizations 
so they can integrate and customize various free software packages to meet 
their organizational needs.
https://comment.mayfirst.org/t/gnu-guix-support/1856

If nobody is doing it, maybe I can, sometime in the future (too early for me at 
this time 😅)

Cheers,
Yasu




> On Nov 5, 2020, at 22:13, Julien Lepiller  wrote:
> 
> 
> 
> Le 5 novembre 2020 06:17:08 GMT-05:00, Yasuaki Kudo  a 
> écrit :
>> Just curious, what time of day?  😄
> 
> This hasn't been decided yet. Probably all day European time so you might be 
> able to join the beginning.
> 
> We plan to release the talks in advance, so everyone has a chance to watch 
> them, whatever their timezone. The day of the conference, we will have 
> extended Q&A and discussion sessions, but we're not going to broadcast the 
> talks.
> 
> If you plan to give a talk or lead a discussion session, we can arrange to 
> have a time slot that works best for you if you give us your time 
> constraints. You can also provide a talk, and have no Q&A if you cannot be 
> present at all.
> 
> Thanks for your interest! Hope to see you soon at the Guix Day!
> 
>> 
>>>> On Nov 3, 2020, at 22:33, Julien Lepiller  wrote:
>>> 
>>> Hello guixers!
>>> 
>>> The first online Guix Day Conference on Sunday November, 22nd.  This
>>> conference is open to everyone and will be held entirely online.  No
>>> registration fee.
>>> 
>>> We have received only a few proposals.  Do not be shy!  Please drop
>> us
>>> an email with your ideas: what you would like to talk about or what
>> you
>>> would like to discuss.  We are looking for more talk proposals, as
>> well
>>> as people who are willing to lead discussion sessions with no talk
>>> (BoF).
>>> 
>>> We previously asked you to send your proposal to guix-devel@gnu.org,
>>> but we understand that a public mailing list might be intimidating.
>>> Please send your proposals and ideas to guix-d...@gnu.org instead, a
>>> private alias for the organizers.
>>> 
>>> 
>>> Important dates:
>>> 
>>> + November 6th: Deadline for talk proposals
>>> + November 14th: Deadline for releasing your pre-recorded talks.
>>> + November 16th: Release of the schedule
>>> + November 22nd: Conference day!
>>> 
>>> 16th to 21st: watch the talks!
>>> 
>>> The agenda for Sunday is:
>>> 
>>> + pre-recorded talks with live question and answer sessions
>>> + birds of a feather (BoF) sessions
>>> + lightning round talks, if possible
>>> + hack together
>>> 
>>> Read more details at:
>>> <https://guix.gnu.org/en/blog/2020/online-guix-day-announce-1/>
>>> 
>>> Spread the word!
>>> 

Welcome to Grub!... for a minute

[Yasuaki Kudo]

Hi,

I just wanted to report (although this is probably already known) that I had to 
wait for a long time (probably more than a minute) staring at "Welcome to 
Grub!" screen upon reboot, after accumulating thousands of guix system 
generations.  I was experimenting with something and I suspected that was the 
cause - sure enough, after deleting them all with guix system 
delete-generations command, the delay disappeared.

Just reporting 😄

Re: Welcome to Grub!... for a minute

[Yasuaki Kudo]

Hi Everyone,

Thank for responding - I was just experimenting with repeated guix pull and  
build commands (because the "proprietary" packages in those separate channels 
take ages to compile)

In retrospect, this lead me to realize that instead of guix system reconfigure, 
I could just do guix system build, for my purpose.

So mine is probably an "edge case" but wanted to report anyway 😄

Cheers,
Yasu

> On Nov 27, 2020, at 22:16, Tobias Geerinckx-Rice  wrote:
> 
> Hi!
> 
> [CC'ing only guix-devel@.]
> 
> Yasuaki Kudo 写道：
>> I just wanted to report (although this is probably already known) that I had 
>> to wait for a long time (probably more than a minute) staring at "Welcome to 
>> Grub!" screen upon reboot, after accumulating thousands of guix system 
>> generations.  I was experimenting with something and I suspected that was 
>> the cause - sure enough, after deleting them all with guix system 
>> delete-generations command, the delay disappeared.
>> 
>> Just reporting 😄
> 
> And thank you for it!  If this is where Guix ends up when left unattended, it 
> should be fixed.
> 
> Easy to do by making the ‘old generations’ submenu a separate file that's 
> loaded ‘on demand’.  Actually doing so would still take as long, so the next 
> logical step is to split it further into chunks. How, I guess, depends on how 
> people actually use & browse thousands of generations.  Do you?
> 
> Kind regards,
> 
> T G-R

Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Yasuaki Kudo]

Hi Ricardo,

No, it wasn't enough.  (I could be wrong - I am still learning Guix. 😅)  

But I spent a lot of time picking my hair out, trying to figure out why guix 
edit hello would not find the scm file under my locally checked out guix 
repository.

When I followed the instructions on the link, the "bulletproof" way, my problem 
immediately went away.   And I thought it was probably fixed by the  -C option 
(creating a container) 😄

-Yasu



> On Dec 5, 2020, at 01:04, Ricardo Wurmus  wrote:
> 
> 
> Hi Yasu,
> 
>> I rely on the -C option below to compile ./pre-inst-env  .
> […]
>> I hope this is a bug that can be fixed.   Otherwise, it looks like I
>> won't  be able to compile pre-inst-env?
> 
> Is “guix environment --pure” not enough?
> 
> -- 
> Ricardo

Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Yasuaki Kudo]

Hi everyone!

I use both:
* Guix System with Linux(non-Libre) Kernel, straight on my desktop PC
* Guix System on Linux subsystem on Windows 10 
(https://github.com/giuliano108/guix-packages/blob/master/notes/Guix-on-WSL2.md)
 on Microsoft Surface Book

and both started to exhibit the same problem with the commitid I reported.

When switch to the commit id immediately before that, the problem goes away.

I tried to set the number as mentioned but I could not figure out how to do 
it...  Do you know how to do this on Guix System?

Cheers,
Yasu

> On Dec 5, 2020, at 03:55, Pjotr Prins  wrote:
> 
> On Fri, Dec 04, 2020 at 05:32:08PM +0100, zimoun wrote:
>> Have you tried to do the recommandation?
>>please set /proc/sys/kernel/unprivileged_userns_clone to "1"
> 
> As root:
> 
> echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> 
> Yes, it is common on Debian and such.
> 
> Pj.

Re: bug#45069: BUG: Re: guix environment: error: cannot create container: unprivileged user cannot create user namespaces

[Yasuaki Kudo]

Just FYI (sorry to interject) , my original email was stripped of html 
elements?  anyway, I was referring to this link 
https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do#comment442083_209533
  -Yasu

> On Dec 7, 2020, at 21:31, Paul Garlick  
> wrote:
> 
> Hi Pierre,
> 
> Can you try, as root on Guix System:
> 
> $ echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> 
> If you could report success or failure that would be helpful; the
> unprivileged-user-namespace-supported? test in gnu/build/linux-
> container.scm should be the same irrespective of the underlying
> distribution (Debian, CentOS, Guix System ...).
> 
> Best regards,
> 
> Paul.
> 
>> On Mon, 2020-12-07 at 12:57 +0100, Pierre Neidhardt wrote:
>> Hi!
>> 
>> I can reproduce the issue since I 'recondigure'd my Guix System.
>> I'm on cebfb29abb151ede95696181d2446c63504593d7.
>> 
>> Guix' bug?
>> 
>> 
> 
> 

Re: Add Microsoft Cascadia Code font?

[Yasuaki Kudo]

Thank you for your comments!

Because I don't have a lot of time, is it ok to just re-format the original 
submission, get it committed with the comment that the package needs to be 
compiled rather than copied, when someone (or I) wants to so properly?

Cheers,
Yasu


> On Jan 10, 2021, at 18:16, Leo Prikler  wrote:
> 
> Hello Vincent,
> 
> there is no .tar of the fonts however, that's a source tarball
> generated by github.  To be fair, one should probably build this font
> (and other fonts) from source instead.  In particular, we might want to
> package nerd-fonts[1] first, since Cascadia appears to be an iteration
> of it.
> 
> Regards,
> Leo
> 
> [1] https://github.com/ryanoasis/nerd-fonts
> 
> 

Re: Add Microsoft Cascadia Code font?

[Yasuaki Kudo]

Hi Leo,

Understood, and this level of scrutiny is actually an encouraging sign that 
Guix has standards! 😄

I am happy enough to have it this way for my personal use for now.  Later, when 
I have more time, let me revisit.   

I have not experimented with this yet but I also understand I can create a 
separate repository as well.   Maybe that will also do😄

Regards,
Yasu

> On Jan 10, 2021, at 19:38, Leo Prikler  wrote:
> 
> Hi Yasu,
> 
> I don't think it'll be so simple.  It appears, that nerd-fonts already
> includes – or at least has the potential to include – some non-free
> glyphs, which would in turn then be part of Cascadia.  An instance
> would be pomicons [1], which are licensed as CC BY-NC-ND.  A reviewer
> would first have to verify, that Cascadia is indeed wholly covered
> under the OFL or at least under a set of free licenses.
> 
> Yes, it sucks having to put that much effort into packaging a font, but
> if you just want to have a workable font for programming, there are
> probably better solutions than Cascadia, some of which are already
> packaged in Guix – e.g. font-fira-code.
> 
> Regards,
> Leo
> 
> [1] https://github.com/gabrielelana/pomicons
> 
> Am Sonntag, den 10.01.2021, 19:11 +0900 schrieb Yasuaki Kudo:
>> Thank you for your comments!
>> 
>> Because I don't have a lot of time, is it ok to just re-format the
>> original submission, get it committed with the comment that the
>> package needs to be compiled rather than copied, when someone (or I)
>> wants to so properly?
>> 
>> Cheers,
>> Yasu
>> 
>> 
>>> On Jan 10, 2021, at 18:16, Leo Prikler <
>>> leo.prik...@student.tugraz.at> wrote:
>>> 
>>> Hello Vincent,
>>> 
>>> there is no .tar of the fonts however, that's a source tarball
>>> generated by github.  To be fair, one should probably build this
>>> font
>>> (and other fonts) from source instead.  In particular, we might
>>> want to
>>> package nerd-fonts[1] first, since Cascadia appears to be an
>>> iteration
>>> of it.
>>> 
>>> Regards,
>>> Leo
>>> 
>>> [1] https://github.com/ryanoasis/nerd-fonts
>>> 
>>> 
> 

PowerShell core?

[Yasuaki Kudo]

Hi,

Just curious, is there any interest in making PowerShell core available for 
Guix?

I have become quite fond of Powershell over the years (I say Powershell is 
almost synonymous with IT worker rights - gives poor workers in sorry corners 
of corporate world [those who are abandoned without adequate tools to get the 
job done - because Windows is always there and Powershell comes with it!] a 
huge productivity lift 😄)

https://devblogs.microsoft.com/powershell/powershell-core-6-0-generally-available-ga-and-supported/

Cheers,
Yasu

Re: PowerShell core?

[Yasuaki Kudo]

Hi everyone!

Thank you all for replying, and especially because you explored many 
attributes, including my own autography of my sorry existence buried deep 
inside a bank some years ago, where I became a Powershell and Excel "expert"😅

Ok, so all we need is time (which I don't have much at the moment 😅)

There seems real convergence of Windows and open source now - for one thing, on 
my Windows 10 laptop, I run Microsoft's built-in Linux and Guix and top of it!  
There might come a day when "proprietary software business" is no longer a core 
thing at Microsoft?  I think they are probably aware of being made irrelevant 
by Linux on the server side, Chrome on the web, Android and Iphone on smart 
phones 😅

Cheers,
Yasu


> On Feb 3, 2021, at 03:24, Ryan Prior  wrote:
> 
> CLR and the .NET Core tools is the first step there.

Re: PowerShell core?

[Yasuaki Kudo]

Wow! It does look very interesting, indeed!

One of the reasons why I became so interested in Racket (not just PowerShell😅) 
is that it installed without a hitch in my corporate Windows.   (I tried to 
install Haskell as well but it got stuck when it came to using Stack)

It is also interesting that the rash paper on the homepage  
http://willghatch.net/publications/rash-gpce-2018-preprint.pdf mentions 
PowerShell many times. 😄

Empowering the IT workers!  Power to the workers!! 😄

-Yasu


> On Feb 4, 2021, at 03:53, Bengt Richter  wrote:
> 
> Hi,
> 
>> On +2021-02-03 02:28:26 +0100, zimoun wrote:
>> Hi,
>> Well, speaking about an
>>>  attempt to pull command
>>> interpreters out of the 70s
>> ads:  :-)
>> (I previewed the talk and it is worth watching!  Even, I previewed all
>> the talks of the «room» and they are all inspired and inspiring, see you
>> on Sunday. :-))
>> Cheers,
>> simon
> 
> [1]https://docs.racket-lang.org/rash/index.html
> 
> If you have racket or raco at your command line,
> rash is only one or two commands from interaction with you :)
> 
> I.e.,
>   racket -l rash/repl
> and/or to install rash
>   raco pkg install rash
> 
> A repo is at [2]
> 
> [2] https://github.com/willghatch/racket-rash/blob/master/README.md
> 
> Seems interesting, though I'm more into wayland innards right now,
> so I haven't done anything rash :)
> 
> -- 
> Regards,
> Bengt Richter

Re: A "cosmetic changes" commit that removes security fixes

[Yasuaki Kudo]

Hello!

I don't know the details of the case at all but let met mention this:
https://communityrule.info/
It comes from the world of worker cooperatives and I think them "rules of the 
community" is discussed a lot there as well 😄

Cheers,
Yasu

> On May 1, 2021, at 18:16, Pierre Neidhardt  wrote:
> 
> Pjotr Prins  writes:
> 
>> Being a core committer is *not* a badge of honour. It does not give
>> special privileges beyond what is expected.
> 
> But this may not be true.  Quite a few people have expressed otherwise
> over the years.
> 
> Maybe an issue is that much of the organizational structure of Guix is
> implicit.  The roles are not well defined and as a result, they may
> reach beyond what is commonly understood.
> 
> Some time ago, I was discussing the quetsion of implicit structure with
> Ludo, who sent me this essay:
> 
>  https://www.jofreeman.com/joreen/tyranny.htm
> 
> I found it enlightening and quite relevant to the matter at hand.
> 
> Even if in the end my concerns end up being unjustified, I find it good
> practice to always question the status quo: maybe something better could
> come out of it! :)
> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/

Re: The way to promote GUIX package manager

[Yasuaki Kudo]

Does Guix really run out of the box in Debian?

I have never tried it but my friend Debian expert friend keeps telling me that:

* Just apt-get installing Guix doesn't work

* and his really big complaint is evidently he creates "virtual environments" 
(short of full-on VMware, I imagine it is an assortment of Linux native tricks 
that are wrapped by tools like Docker) for every OS he tries but 
* Evidently the same tricks don't work with Guix

* He does not want to try full blown Guix OS without first testing it in above 
ways

* He is very comfortable with Debian - doesn't see any benefit that Guix brings

I cannot comment much because the whole point of my using Guix is precisely 
because I know very little if Linux and its surrounding toolset so I want to 
abstract it, paper it over with Guix 😄

-Yasu


> On Jan 27, 2022, at 06:43, Ricardo Wurmus  wrote:
> 
> 
> Sławomir Lach  writes:
> 
>> Solution is simple:
>> 1. Keep older packages in GUIX repo, so developers could request older 
>> version 
>> in scripts
> 
> Unforunately, it’s really not that simply to keep older packages around.
> I’m maintaining packages for a bunch of bioinformatics tools, for
> example, which are stuck in the past.  Building them becomes more and
> more difficult as time passes and the rest of the world moves on.  It is
> not feasible to maintain an ever-growing collection of outdated software
> and their toolchains.
> 
> But: Guix supports channels, so people who absolutely must use GCC 3 to
> build their abandoned tools to build their old source code that’s stuck
> in the past can totally do that.
> 
>> Minus: possible security hell.
> 
> :)
> 
> -- 
> Ricardo
> 

Re: The way to promote GUIX package manager

[Yasuaki Kudo]

Well I have to tell you I am not too familiar with either Debian or Guix😅  So 
with that disclaimer:

- If I remember correctly, Guix in Debian just doesn't work straight away after 
apt-get install, meaning enabling of certain Guix services also required?

- He needs to have everything that Guix needs "virtualized", including the 
folder /gnu straight under root, (under some /home/xyzuser/blah/ directory I 
presume).   He does not care about Guix-as-container - he needs 
Guix-to-be-contained.

Again, I don't know much, Im' just a casual Guix OS user (and I love it 😄) but 
does it make sense?

-Yasu


> On Jan 27, 2022, at 07:46, Ricardo Wurmus  wrote:
> 
> 
> Yasuaki Kudo  writes:
> 
>> Does Guix really run out of the box in Debian?
>> 
>> I have never tried it but my friend Debian expert friend keeps telling me 
>> that:
>> 
>> * Just apt-get installing Guix doesn't work
> 
> How does “apt install guix” not work?  There’s an older version of Guix
> in Debian.  After installing it “guix pull” should get the latest
> version and it all works.
> 
> There’s also an installer script at https://guix.gnu.org/install.sh
> which skips the detour through apt and gets you the latest release
> directly.
> 
>> * and his really big complaint is evidently he creates "virtual
>> environments" (short of full-on VMware, I imagine it is an assortment
>> of Linux native tricks that are wrapped by tools like Docker) for
>> every OS he tries but
>> * Evidently the same tricks don't work with Guix
> 
> Is this not *exactly* what “guix shell” (formerly “guix enviromnent”)
> does?  “guix shell -C” enters a container, even, using the same Linux
> namespace mechanism that Docker wraps.
> 
>> * He does not want to try full blown Guix OS without first testing it in 
>> above ways
> 
> Guix can comfortably be used outside of Guix System.  And you can
> *still* use most “guix system” commands, e.g. to build containers or
> virtual machines.
> 
> -- 
> Ricardo

Re: The way to promote GUIX package manager

[Yasuaki Kudo]

This is a comment from a very different angle - another way to promote Guix is 
in the emerging (so I would like to believe 😅) worker cooperatives sector - 
there is a call for democratically directed software development (not in the 
do-o-cracy way that happens due to information asymmetry between "producers" 
and "consumers")

GNU Guix can offer maximum transparency and user friendliness 😄

-Yasu


> On Jan 28, 2022, at 08:36, Bengt Richter  wrote:
> 
> On +2022-01-26 23:42:05 +0100, Ricardo Wurmus wrote:
>> 
>> Yasuaki Kudo  writes:
>> 
>>> Does Guix really run out of the box in Debian?
>>> 
>>> I have never tried it but my friend Debian expert friend keeps telling me 
>>> that:
>>> 
>>> * Just apt-get installing Guix doesn't work
>> 
>> How does “apt install guix” not work?  There’s an older version of Guix
>> in Debian.  After installing it “guix pull” should get the latest
>> version and it all works.
>> 
> 
> What does "apt search guix" produce?
> (Nothing, on the puri.sm variant of debian. They maintain a custom
> pool based on debian minus what they want to exclude AIUI)
> 
>> There’s also an installer script at https://guix.gnu.org/install.sh
>> which skips the detour through apt and gets you the latest release
>> directly.
>> 
>>> * and his really big complaint is evidently he creates "virtual
>>> environments" (short of full-on VMware, I imagine it is an assortment
>>> of Linux native tricks that are wrapped by tools like Docker) for
>>> every OS he tries but
>>> * Evidently the same tricks don't work with Guix
>> 
>> Is this not *exactly* what “guix shell” (formerly “guix enviromnent”)
>> does?  “guix shell -C” enters a container, even, using the same Linux
>> namespace mechanism that Docker wraps.
>> 
>>> * He does not want to try full blown Guix OS without first testing it in 
>>> above ways
>> 
>> Guix can comfortably be used outside of Guix System.  And you can
>> *still* use most “guix system” commands, e.g. to build containers or
>> virtual machines.
>> 
>> -- 
>> Ricardo
>> 
> 
> -- 
> Regards,
> Bengt Richter

Re: Documentation of what is appropriate for #guix?

[Yasuaki Kudo]

Or even better, create an alternative community of practitioners who 
don't give a damn (for their purposes)...   Let me know if other people 
also want to create a corruption-admitted-community as well 😁.  We can 
work together.  -Yasu


On 2/20/22 11:33, Vagrant Cascadian wrote:

Every now and then someone stumbles into #guix and ask questions that
I've gleaned over time are off-topic (e.g. non-free software). While I
have a pretty good idea what is appropriate for the channel, it is not
clear to me where that is documentated.

I figured maybe it is referenced in the code of conduct, but then I see
no reference to the code of conduct on https://guix.gnu.org, although it
is in the toplevel directory of guix.git as "CODE-OF-CONDUCT".

Still, the CODE-OF-CONDUCT doesn't really say anything about what is
on-topic for #guix on irc...

It would be helpful to have a link to be able to point to more easily
whenever either subjects come up in the irc channel, ideally somewhere a
little easier to find. :)


live well,
   vagrant

Re: Documentation of what is appropriate for #guix?

[Yasuaki Kudo]

If we were to set up a separate relaxed Guix community that accommodates all 
forms of corruption, one problem would be the impediments that would exist in 
communication, especially if the original Guix takes hostile and 
non-compromising attitude, I think.

If a question arises from that downgraded community how to do this and that, 
precisely to accommodate some unaccountable  binary black box software, the 
chances of getting helpful answers may not be so high from the original Guix 
community. 😅

It is a difficult question - even in the real world the similarities abound.   
While it is easy to ignore and isolate North Korea, a country that offers no 
useful commodity for export (or maybe it does, but let's say, for the sake of 
argument), countries like Japan have no problem importing Saudi Arabian oil. 
Ethics and human rights are thrown out the window - oil is considered far more 
important.

I tend to take the position of strategically 'not caring'  (e.g. 
https://youtu.be/Blz_Eu00Kbw )

Maybe someone like me is called a Libertarian?  I am not sure... (for the 
record, my political philosophy seems to be called Anarcho-Syndicalism 😄)

But I still think a parallel community might be in order 😄

-Yasu


> On Feb 22, 2022, at 07:36, Paul Jewell  wrote:
> 
> 
> 
>> On 21 Feb 2022, at 19:10, raingloom  
> 
>> By the way, I think it's kind of silly that that is completely banned
>> from discussion. When I wanted help on getting my GPU to work, I
>> mentioned for reference purposes that I tried the proprietary driver
>> from The Forbidden Channel - and was subsequently warned that I must
>> not do that.
> 
> I understand that the position taken by guix is more nuanced than that. The 
> project doesn’t seek to control what you run on your computer, but won’t 
> support your choice to run non-free software in the official channels. 
> 
>> Which I find ridiculous. You can't even discuss results
>> obtained by running closed source drivers and firmware, so how do you
>> debug the libre firmwares and drivers, when you have nothing to compare
>> against?
> But you can discuss these results elsewhere.
> 
>> Also, I think people who want to overwhelmingly use free software but
>> need proprietary drivers for their computer to function should be
>> offered better help than "buy a new computer".
> 
> I kind of agree with you here. I don’t want to obsolete perfectly viable 
> hardware, but instead want to use it for its whole life. Next time I am in 
> the market for new hardware, then I will have the ability to run 
> libre-software as a pre-condition for purchase.
> 
>> I think The Forbidden Channel should be raised to a status similar to
>> the AUR: it's recognized and its existence is documented, but all
>> responsibility is very explicitly disclaimed and support is relegated
>> to special channels.
> 
> Users will find it even the way it is configured today. I don’t think it 
> needs any sort of official recognition or promotion, as that will go against 
> the project goals/rules (as I understand it). We should always be aware of 
> the insidious nature of proprietary firmware/software, and work to eliminate 
> the need for it, rather than indicating that its use is acceptable as a first 
> choice.
> 
> 
> Best regards,
> Paul

Re: Building a software toolchain that works

[Yasuaki Kudo]

Hi,

I posted something similar recently but I know there are 100s of banks and 
hedge funds alike that run daily calculations on arrays of servers , and they 
have very tricky changes in both software and data, daily.

Do you think Guix(HPC - i don't know what specializations go there 😅) can be 
the prime tool for the job?

-Yasu

> On Mar 15, 2022, at 17:25, Ludovic Courtès  wrote:
> 
> Hi!
> 
> Olivier Dion via "Development of GNU Guix and the GNU System
> distribution."  skribis:
> 
>> On another note, what I find fascinating is why Guix and Nix are not
>> more used in academic papers.  A quick search on the Compendex database
>> gives me only a handful of papers referencing Guix, mostly all from
>> Ludovic.  I simply can't understand this.  You have a way to factor out
>> the toolchain from the equation of your research's resuls -- making it
>> trivial to reproduce -- and yet every papers that I read is using some
>> Ubuntu LTS or Fedora as their build and testing environment.
> 
> This is what we’re pushing as part of the Guix-HPC effort¹.  Ricardo’s
> research team, for instance, has published bioinfo papers that build on
> Guix for reproducibility.  Colleagues of mine in HPC (linear algebra and
> run-time systems) are also starting to do this.
> 
> That’s still very much niche, but there’s growing awareness of how tools
> like Guix can help build reproducible research workflows.  The next thing
> for us is to provide tools and documents to make it more approachable.
> 
> Ludo’.
> 
> ¹ https://hpc.guix.info
> 

Re: Building a software toolchain that works

[Yasuaki Kudo]

I am very interested in this topic, too!

At work, I have been forced to use the NPM package manager and since the first 
day I have been unable to understand this enigma - how on earth do people work 
with this fuzzy system almost designed to be unaccountable??   Can Guix replace 
NPM?

I think we are really onto something - my hunch is that technicalities are only 
half of the issue and the other is the community building for democratic and 
accountable software(for which, concepts like Free Software will fit naturally)

-Yasu


> On Mar 17, 2022, at 00:29, Ryan Prior  wrote:
> 
> On Wednesday, March 16th, 2022 at 2:02 PM, Josselin Poiret 
>  wrote:
> 
>> Let me chime in on a specific point.
>> [...]
>> I don't think I would've written these patches without Guix's help.
> 
> This is CRUCIAL to Guix's value proposition: by abstracting away so much of 
> the incidental complexity of software, Guix enables a nimble, carefree mode 
> of hacking where you'll create and improve software that would never have 
> been worth the trouble otherwise.
> 
> Proposals like David's `guix contribute` play on the strength of Guix as an 
> enabling technology. That's exactly the kind of thing I meant when I wrote 
> "double down." How can I encourage the improvement & implementation of such 
> proposals? A few notions:
> 
> a. My Guile isn't strong enough to put together a proof-of-concept in Guix as 
> a solo effort. I might be able to write a PoC in concert with a more 
> experienced Guiler. We could schedule some strategy & pair programming 
> sessions to get something on track.
> 
> b. I could work on a PoC using a language I'm better trained with (elisp, 
> Ruby and JavaScript are my three strongest languages probably.) I don't know 
> how that would be received by the Guix commons, I've felt discouraged in the 
> past to extend Guix unless it's in Guile but perhaps that's a false anxiety.
> 
> c. I could also provide some funding if somebody has time & skills to create 
> a PoC and just needs the financial incentive. If this is you, reach out.
> 
> 
> I've been pleased to see ideas resonate in this thread. It makes me believe 
> many of us have some form of this thought in our heads and that by 
> socializing we can bring something fresh to the free software world. What are 
> the next steps?
> 

Re: Building a software toolchain that works

[Yasuaki Kudo]

Hello David,

I am huge fan of Guix on WSL2 and I used to use it a lot 😄.  And yes, it should 
be documented well (or even better, the installation should be made super 
simple) while as you mentioned, it might be easier to do this in another 
community.

I don't share the ideology of hardline rejection of the use of proprietary 
software - I just need everything to be accountable, such as knowing which part 
of the system is Free and which isn't. (and of course more Free the merrier)

Guix, the software, (IMHO, not necessarily the community unless a separate one 
is created) does the most perfect job for this 😄

-Yasu


> On Mar 19, 2022, at 06:14, david larsson  wrote:
> 
> On 2022-03-17 13:56, zimoun wrote:
>> Hi Olivier,
>>> On another note, what I find fascinating is why Guix and Nix are not
>>> more used in academic papers.
>> Indeed.
>> One part of the answer is, IMHO: it is difficult to spread the word.
>> For instance, with co-authors, we have tried to write a short paper
>> detailing what Guix solves, i.e., the computational environment part of
>> the “science crisis“, and targeting especially bioinfo folks.  We got
>> many refusals by the journals that bioinfo folks indeed read and we end
>> in a “specialized” journal.
>> On the top of that, add the fact that most of the time, people use what
>> other people in their lab or collaborators already use.
>> On the top of that, add the fact that the story of Guix on Windows or
>> Mac is not really good.  I am not arguing here, just to mention that
>> many people are still using Windows or Mac and few one Linux variant.
>> Therefore, all in all, the bootstrap of Guix is hard; as always. :-)
>> The initiative Guix-HPC is an attempt to address that.  The name is
>> probably not fully representative since now it looks like Guix in
>> scientific context; HPC being only one component.
>> From my point of view, the bootstrap of Guix in scientific world
>> requires more documentation materials for many common use cases and more
>> popular applications or usual scientific stack.  For instance PyTorch in
>> Guix is one step but many things are still really hard to do with Guix
>> when it is not elsewhere.  Another instance is RStudio for bioinfo folks
>> – it does not work out of the box with Guix when it does elsewhere.
>> Help in these both areas – howto materials and popular applications – is
>> very welcome. :-)
>> Join the fun, join guix-scie...@gnu.org :-)
>> Cheers,
>> simon
> 
> I run Guix including GUI applications from Windows via WSL2 (Windows 
> Subsystem for Linux). It may help some to try it out if this setup was easier 
> and more documented, though I suppose that is somewhat prevented to go via 
> official channels by the FSDG guidelines.
> 
> Best regards,
> David
> 

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

[Yasuaki Kudo]

This is heading in the right direction - in my analysis, many things we do, 
including Free Software, are all forms of creative subversion of Capitalism.   
We need note creativity, not less 😄

> On Mar 20, 2022, at 03:19, Ryan Prior  wrote:
> 
> Zimoun wrote:
>> Today, Guix provides a script that allows to install on any foreign Linux 
>> distribution. [...] Guix provides a “nightly“ VM. And, IIRC, Guix is also 
>> available via upstream Gnome boxes. Somehow, it is already “Guix for 
>> Desktop”, no? ;-)
> 
> An important bit of context here is that I'm talking about the case where a 
> software engineer is the end-user of Docker (or of Guix,) utilizing it 
> specifically as an interface and a tool to build, test, and deploy software. 
> (This is what I meant by "end-user dev tool" in my email title and I regret 
> that I didn't explain up front in more detail what I meant.) This brings a 
> whole different set of assumptions from the common case where the end-user 
> just wants to run some software and the building & testing are incidental.
> 
> When I install Docker for Desktop on macOS or Windows, I do not have to first 
> install a VM manager dependency like QEMU or VirtualBox. The installer for 
> Docker creates and manages a VM automatically, which is treated as de-facto 
> immutable and never exposed to the user at all. It is locked down, 
> automatically updated, and doesn't provide the user any way to install new 
> software or make changes to it. It's not like a distro: it provides only 
> what's necessary to run containers, with no desktop, no coreutils, no SSH, no 
> VNC, practically no userland at all.
> 
> The only point of interaction with the VM is through the Docker daemon. On 
> Windows or Mac when you run `docker build` the client software is connecting 
> to the daemon in the VM, sending it the build context, etc - but the user 
> doesn't have to configure or manage any of this. And thus with each Docker 
> command.
> 
> Liliana Prikler wrote:
>> But who are those users of Docker for Desktop?  For me, that seems to be a 
>> niche even smaller than flatpak et al.
> 
> The target demographic is developers who, whether out of preference or for 
> corporate compliance or some other reason, use macOS or Windows on their dev 
> machine but are deploying to GNU/Linux boxen. By standardizing on Docker for 
> Desktop, organizations are able to provide a consistent GNU toolchain to all 
> their developers and operators, smoothing out the differences between 
> platforms and decreasing complexity.
> 
> I acknowledge that people also sometimes use Docker for Desktop as a Flatpak 
> &c alternative, to just run some software. And that particular use case is 
> indeed niche. But at companies that use Docker on the server to test and 
> deploy software, every developer who uses a non-free OS likely has Docker for 
> Desktop installed. This amounts to hundreds of thousands of daily users, at 
> least.
> 
>> Running a full-blown distro inside docker defeats the purpose of docker, 
>> which is to run only the parts necessary to keep your microservice alive.
> 
> It is uncommon to run a full distro using Docker for Desktop. I wouldn't say 
> unheard of, but overwhelmingly the most common use case is to do exactly what 
> you describe, building and running small containers with a service in them. 
> The value proposition of Docker for Desktop is that you don't have to do the 
> work of managing a VM or even SSH into a VM in order to interact with the 
> Docker daemon. You just install Docker for Desktop and interact with Docker 
> the same as you would with GNU/Linux.
> 
> Zimoun wrote:
>> What do you have in mind for smoothing the workflow of end-user running 
>> Guix? I agree that things are lacking for more adoption but I miss what you 
>> would have in mind with “Guix for Desktop”.
> 
> Some organizations using Docker on the server would be even better served by 
> Guix, and even moreso as our project matures. As Liliana points out, even 
> those who decide to keep using OCI containers can benefit from building them 
> using Guix.
> 
> But for a variety of reasons organizations commonly have a heterogeneous 
> environment, with GNU/Linux on the server and a mix of free and non-free OSes 
> on the client. They would face a much lower barrier to adopt if we were to 
> offer a "Guix for Desktop" installer that enables uniform developer 
> workflows, such that "guix build -f my-app.scm" works the same on any client, 
> and so on for each Guix command.
> 
> This would necessarily exclude some commands, like and "guix system 
> reconfigure," which are expected to mutate the user's base system. Installed 
> this way, every interaction with Guix would be in a Guix container, with 
> files from the host system mounted into it. If I ran "guix install coreutils" 
> then the installed "ls" would be a shell script that runs ls inside a Guix 
> shell in the VM, with the current directory mounted into it.
> 
> This 

Video Conference

[Yasuaki Kudo]

Hello,

From time to time, I think about audio/video mixer (.i.e. video conference 
software like BBB or Jitsi) , with the intension of making it highly modular 
that it can be freely remixed and reinvented by volunteer participants.

Is anyone interested?   Or is can you think about something that already exists?

Cheers,
Yasu

Re: Video Conference

[Yasuaki Kudo]

Hi,

2 years ago, I joined meet.coop , a video conference service cooperative and 
explored the business potential in Japan.

The coop hosted BBB but the gap I discovered was that the potential customers 
in Japan would not be interested unless the service is customized to their 
exact needs - otherwise they preferred Zoom and Google meet.

So ability to to take the video conference service into minimalist components 
and then reassembling  is very important 😄

-Yasu

 

> On Apr 2, 2022, at 03:59, jbra...@dismail.de wrote:
> 
> March 31, 2022 7:53 PM, "Yasuaki Kudo"  wrote:
> 
>> Hello,
>> 
>> From time to time, I think about audio/video mixer (.i.e. video conference 
>> software like BBB or
>> Jitsi) , with the intension of making it highly modular that it can be 
>> freely remixed and
>> reinvented by volunteer participants.
>> 
>> Is anyone interested? Or is can you think about something that already 
>> exists?
> 
> Your proposal sounds a little vague.  What are you hoping to accomplish that 
> BBB or Jitsi 
> does not already do?
> 
>> 
>> Cheers,
>> Yasu

Re: Video Conference

[Yasuaki Kudo]

Well I thought it would be easier to build it natively on Guix from "scratch".

For example, the BBB programs looked almost impossible to disassemble to 
components - at least it looked like it would be even harder than doing it all 
over again.

But the question of what the "scratch" means...  it seems there are a few 
components - WebRTC, audio codec, video codec, etc.

And there are questions over whether to really mix the signals on server (for 
audio) or just bundling all separate lines of communications (for video), etc

I would like to taken advantage of Guix to try different mixes and experiment 😄 

> On Apr 3, 2022, at 03:34, jbra...@dismail.de wrote:
> 
> April 2, 2022 12:26 AM, "Yasuaki Kudo"  wrote:
> 
>> Hi,
>> 
>> 2 years ago, I joined meet.coop , a video conference service cooperative and 
>> explored the business
>> potential in Japan.
>> 
>> The coop hosted BBB but the gap I discovered was that the potential 
>> customers in Japan would not be
>> interested unless the service is customized to their exact needs - otherwise 
>> they preferred Zoom
>> and Google meet.
>> 
>> So ability to to take the video conference service into minimalist 
>> components and then reassembling
>> is very important 😄
>> 
> 
> Sounds like a worthwhile project.  You can always reach out to the BBB or 
> jitsi developers
> and see what they think of your proposal.
> 
>> -Yasu
>> 
>>>> On Apr 2, 2022, at 03:59, jbra...@dismail.de wrote:
>>> 
>>> March 31, 2022 7:53 PM, "Yasuaki Kudo"  wrote:
>>> 
>>>> Hello,
>>>> 
>>>> From time to time, I think about audio/video mixer (.i.e. video conference 
>>>> software like BBB or
>>>> Jitsi) , with the intension of making it highly modular that it can be 
>>>> freely remixed and
>>>> reinvented by volunteer participants.
>>>> 
>>>> Is anyone interested? Or is can you think about something that already 
>>>> exists?
>>> 
>>> Your proposal sounds a little vague. What are you hoping to accomplish that 
>>> BBB or Jitsi
>>> does not already do?
>>> 
>>>> Cheers,
>>>> Yasu

Re: Video Conference

[Yasuaki Kudo]

and this thing WebRTC itself looks like a beast of its own...  This is a 
perfect subject for Guix to handle? 😄

https://github.com/webrtc-rs/webrtc



> On Apr 4, 2022, at 06:14, Yasuaki Kudo  wrote:
> 
> Well I thought it would be easier to build it natively on Guix from 
> "scratch".
> 
> For example, the BBB programs looked almost impossible to disassemble to 
> components - at least it looked like it would be even harder than doing it 
> all over again.
> 
> But the question of what the "scratch" means...  it seems there are a few 
> components - WebRTC, audio codec, video codec, etc.
> 
> And there are questions over whether to really mix the signals on server (for 
> audio) or just bundling all separate lines of communications (for video), etc
> 
> I would like to taken advantage of Guix to try different mixes and experiment 
> 😄 
> 
>>> On Apr 3, 2022, at 03:34, jbra...@dismail.de wrote:
>>> 
>>> April 2, 2022 12:26 AM, "Yasuaki Kudo"  wrote:
>>> 
>>> Hi,
>>> 
>>> 2 years ago, I joined meet.coop , a video conference service cooperative 
>>> and explored the business
>>> potential in Japan.
>>> 
>>> The coop hosted BBB but the gap I discovered was that the potential 
>>> customers in Japan would not be
>>> interested unless the service is customized to their exact needs - 
>>> otherwise they preferred Zoom
>>> and Google meet.
>>> 
>>> So ability to to take the video conference service into minimalist 
>>> components and then reassembling
>>> is very important 😄
>>> 
>> 
>> Sounds like a worthwhile project.  You can always reach out to the BBB or 
>> jitsi developers
>> and see what they think of your proposal.
>> 
>>> -Yasu
>>> 
>>>>> On Apr 2, 2022, at 03:59, jbra...@dismail.de wrote:
>>>> 
>>>> March 31, 2022 7:53 PM, "Yasuaki Kudo"  wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> From time to time, I think about audio/video mixer (.i.e. video 
>>>>> conference software like BBB or
>>>>> Jitsi) , with the intension of making it highly modular that it can be 
>>>>> freely remixed and
>>>>> reinvented by volunteer participants.
>>>>> 
>>>>> Is anyone interested? Or is can you think about something that already 
>>>>> exists?
>>>> 
>>>> Your proposal sounds a little vague. What are you hoping to accomplish 
>>>> that BBB or Jitsi
>>>> does not already do?
>>>> 
>>>>> Cheers,
>>>>> Yasu

Re: Video Conference

[Yasuaki Kudo]

Yes it does help and thank you Maxim!

My almost only hope for a viable citizens-driven Free Software development 
hinges on clean separation of specification and implementation, modularity and 
composability.   Workers in our crazy economies have so little spare time 
(unless they are rich) - therefore, we need to create the software development 
model optimized for spare time programming😄

-Yasu

> On Apr 4, 2022, at 11:58, Maxim Cournoyer  wrote:
> 
> Disclaimer: My employer spearheads the development of Jami.
> 
> Hello,
> 
> Yasuaki Kudo  writes:
> 
>> Hello,
>> 
>> From time to time, I think about audio/video mixer (.i.e. video
>> conference software like BBB or Jitsi) , with the intension of making
>> it highly modular that it can be freely remixed and reinvented by
>> volunteer participants.
>> 
>> Is anyone interested?   Or is can you think about something that already 
>> exists?
> 
> You may be interested in trying out Jami; there's a package for it in
> Guix that works rather well, and there's also a jami service that is
> useful to easily keep a rendezvous point online on servers, for example.
> I've made available such a rendezvous point to the community, feel free
> to try it; it's reachable at 'rdv-jami-guix'.
> 
> About making it modular; I know there's now a plugin system in Jami that
> enable people to author plugins to implement things such as changing the
> background (green screen), applying a blur filter, etc.  The
> architecture of the software also makes it easy to create new clients
> for it, as the core library is a distinct package (libjami).
> 
> Hope that helps,
> 
> Maxim

Re: WhereIsEveryone, Guix Packaging Meetup Tomorrow, April 24th

[Yasuaki Kudo]

OMG this would have been perfect but I will be at the immigration office during 
that time for my wife...   But thank you for the Asian time hosting and I would 
love to get involved with the Guix community around this timezone!!   -Yasu

> On Apr 24, 2022, at 12:13, jgart  wrote:
> 
> On Sat, 23 Apr 2022 22:20:54 -0400 jgart  wrote:
>> Dhruvin worked on packaging SourceHut's awesome CLI tool: 
>> https://sr.ht/~emersion/hut/
> 
> Here's a sneak peek of what hut provides and shown in a guix shell:
> 
> jgart@guixerville ~/guixrus [env] λ hut -h
> hut is a CLI tool for sr.ht
> 
> Usage:
>  hut [command]
> 
> Available Commands:
>  builds  Use the builds API
>  git Use the git API
>  graphql Execute a GraphQL query
>  helpHelp about any command
>  hg  Use the hg API
>  initInitialize hut
>  lists   Use the lists API
>  metaUse the meta API
>  pages   Use the pages API
>  paste   Use the paste API
>  todoUse the todo API
> 
> Flags:
>  --config string config file to use
>  -h, --help  help for hut
>  --instance string   sr.ht instance to use
> 
> Use "hut [command] --help" for more information about a command.
> 
> 

The Little Guixer

[Yasuaki Kudo]

Ahem, so the title says it all?  In the style of The Little Schemer.  I wonder 
who/what/when/how it will be written - why is obvious! 😄 -Yasu