From: swedebugia <swedebugia@riseup.net>
To: George Clemmer <myglc2@gmail.com>
Cc: Mark H Weaver <mhw@netris.org>, help-guix@gnu.org
Subject: Re: *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS ***
Date: Wed, 7 Nov 2018 12:40:36 +0100 [thread overview]
Message-ID: <a7412d43-1664-0bbe-b743-67b1091481bd@riseup.net> (raw)
In-Reply-To: <cucva5anjx2.fsf@gmail.com>
Hi
On 2018-11-06 19:24, George Clemmer wrote:
> Hello swedebugia,
>
> swedebugia <swedebugia@riseup.net> writes:
>
>> Hi
>>
>> On 2018-11-01 01:09, George Clemmer wrote:
>> snip
>>> And, with the current state of the guix infrastructure, even a 'guix
>>> pull' on a fresh vm-image triggers guile bootstrap. And a guile
>>> bootstrap, on the best of days, displays these symptoms: howling CPUs
>>> and hardly any disk activity.
>>>
>>> So, relative to what one expects when installing a distro this feels
>>> hung. Not the most confidence inspiring experience to subject a guix
>>> noob to ;-)
>>>
>> I react a little on the wording of you last phrase.
>> We did not subject anyone to anything.
> I am sorry this came across as a potshot. That was not my intent.
Ok, no worries, thanks for clarifying.
>> Trying out beta software like guix (especially when our servers are
>> down) and pulling the latest guix commit is in my view (with my
>> earlier guix-experience) asking for trouble.
>>
>> Pulling a commit like the one that points to 0.15 see
>> http://git.savannah.gnu.org/cgit/guix.git/tag/?h=v0.15.0 is far better
>> -
>> I did that 2 days ago with no trouble. No building locally of the few
>> packages I needed on a bare-bone install, berlin had 30-40% of the
>> substitutes available.
>>
>> We do a rolling release with NO testing branch currently. So everybody
>> who pulls the latest and greatest is a tester willingly or not.
> Yes I know, I have used GuixSD as my daily driver for nearly 3 years ;-)
Wow, I tried multiple times during the last few years to use it on bare
metal daily but eventually ended up not coping with the brittleness and
lacked a basic understanding of guile and scheme to avoid the potholes
and get things done.
GuixSD has matured a lot since I first installed 0.9 and now I
understand way more scheme compared to then.
Having the beta-GuixSD contained in a VM is quite nice as I get to hack
and submit patches and still have a stable Antergos/Parabola on bare
metal that I can handle.
> Please let me restate the key points in hopefully more neutral terms:
Thanks for taking the time to do this :)
>
> The fact that Guix can build anything from source means that a new user
> may think the Guix install is hung when it is, in fact, working as
> designed. This may cause failure to recruit new users.
I agree that the casual user expects to be able to visually see when
their PC is working on something.
(Windows did this by changing the icon of the pointer, others do this
with progress bars or moving stuff that enables a casual user to
distinguish a hung versus a working state of a program)
>> Thus what we could do to improve the situation is to instruct users to
>> NOT pull the latest guix unless they know what they are doing or are
>> willing to deal with anything that comes up...
> Do you mean we should tell users specific commits to pull? Or 'guix
> pull' should not pull from the latest commit? Or something else?
Yeah my personal opinion is both actually.
Newcomers should refrain from pulling other commits than what was tested
(e.g. release commits) until they feel confident about the workings of guix.
If they need a package not yet available in the latest release I propose
to instruct them to make their own package e.g. via $GUIX_PACKAGE_PATH.
For this to work we should probably release more often than now.
> PS: Maybe further discussion should be taken off the bug?
We are to my knowledge posting to the help-guix list.
--
Cheers
Swedebugia
next prev parent reply other threads:[~2018-11-07 11:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 15:42 *** TRYING TO INSTALL GUIXSD v0.15.0 FOR DAYS *** Brian Woodcox
2018-10-31 17:41 ` Leo Famulari
2018-10-31 18:23 ` Brian Woodcox
2018-10-31 18:35 ` Mark H Weaver
2018-10-31 18:47 ` Brian Woodcox
2018-11-01 7:35 ` Mark H Weaver
2018-10-31 20:50 ` Brian Woodcox
2018-10-31 21:54 ` George Clemmer
2018-10-31 22:30 ` Brian Woodcox
2018-10-31 23:44 ` George Clemmer
2018-11-01 2:33 ` Mark H Weaver
2018-11-01 3:35 ` George Clemmer
2018-10-31 22:47 ` Mark H Weaver
2018-10-31 23:57 ` George Clemmer
2018-11-01 0:09 ` George Clemmer
2018-11-06 15:27 ` swedebugia
2018-11-06 18:24 ` George Clemmer
2018-11-07 11:40 ` swedebugia [this message]
2018-11-07 13:01 ` George Clemmer
2018-11-07 15:16 ` Christopher Lemmer Webber
2018-11-01 1:35 ` Mark H Weaver
2018-11-01 2:58 ` Brian Woodcox
2018-11-06 5:14 ` Mark H Weaver
2018-11-06 17:08 ` Brian Woodcox
2018-11-06 23:22 ` Brian Woodcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7412d43-1664-0bbe-b743-67b1091481bd@riseup.net \
--to=swedebugia@riseup.net \
--cc=help-guix@gnu.org \
--cc=mhw@netris.org \
--cc=myglc2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).