Re: preparing the next release v0.15.0

[Kei Kebreau]

swedebugia  writes:

> On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau  
> wrote:
>
>  Marius Bakke  writes:
>
>   On the NEWS side, here is what springs to mind:
>
> [...]
>
>   * Packages can specify that some CVEs don't apply to them
>
> Around when (or what commit) was this feature introduced?
>
> f4007b25476dfd97885f358d2dabbd463f6f6017
> Nov 30th. By efraim. 

I see, thank you both.


signature.asc
Description: PGP signature

Re: preparing the next release v0.15.0

[Kei Kebreau]

l...@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> Thanks for all the ideas, I’ve updated NEWS accordingly.  I’m sure we’re
> still missing a number things (so much has happened!) so more ideas are
> still welcome.  :-)
>
> Ludo’.

Hi Ludo,

Looking at your changes to the log file increases my confidence that I
was on the right track with updating it. You covered what I'd added and
more, but I do have a quick question: I take it that there exists a
script for determining the new packages and updates for each release?
Maybe I've missed it in the repository or in discussion.

Thanks,
Kei


signature.asc
Description: PGP signature

Re: preparing the next release v0.15.0

[swedebugia]

On June 20, 2018 8:38:46 PM GMT+02:00, Kei Kebreau  wrote:
>Marius Bakke  writes:
>
>> On the NEWS side, here is what springs to mind:
>>
>[...]
>> * Packages can specify that some CVEs don't apply to them
>
>Around when (or what commit) was this feature introduced?

f4007b25476dfd97885f358d2dabbd463f6f6017
Nov 30th. By efraim. 
-- 
Cheers Swedebugia 

Re: Questions regarding "Relocatable" option

[Ludovic Courtès]

Hello Yoann,

YOANN P  skribis:

> - Could we hope to see it included in the next release ?

It’s definitely gonna be there.  :-)  Guix is mostly rolling release, in fact.

> - Could we hope to see it included by default in the binary tar.gz of this 
> next release to be able to use guix directly in an unprivileged environment ? 
> ( i dreaming of this every night ^^ )

I experimented with it a bit a reported my findings here:

  https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00139.html

In short it’s still inconvenient, so it won’t happen for this release.

To address the main limitation, I thought we could have a
“--relocatable” package transformation option as well¹ that people could
use to automatically wrap what they install.  Food for thought…

¹ 
https://www.gnu.org/software/guix/manual/html_node/Package-Transformation-Options.html

> - Does the "relocatable" could be the default option and have an 
> "--no-relocatable" option for people who want to avoid the little extra time 
> to start an application ?

We already discussed this a while back, I think.  :-) I think the
default should remain unchanged given the extra overhead (in space and
build time, not just startup time of the resulting binaries) that
wrappers introduce, and given that user namespaces are missing on many
systems still.

Thanks,
Ludo’.

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello Guix!

Thanks for all the ideas, I’ve updated NEWS accordingly.  I’m sure we’re
still missing a number things (so much has happened!) so more ideas are
still welcome.  :-)

Ludo’.

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Hi Julien and Marius,

>> On the NEWS side, here is what springs to mind:
>>
>> * `guix weather` now reports CI statistics
>> * Guix will give hints for how to resolve common configuration errors
>> * RHEL6 systems are again supported
>> * Reproducibility improvements all around
>> * Lots of new supported AArch64 boards
>> * Packages can specify that some CVEs don't apply to them
>> * `guix pack --relocatable` :-)
>>
>> Others?
>
> * guix manual can now be translated and is partially translated into
> French

These are all good points.  Please feel free to make these changes in
NEWS directly.

-- 
Ricardo

Re: preparing the next release v0.15.0

[Nils Gillmann]

Is it worth mentioning that guix pull for some time now
is back to relatively decent 1GB RAM consumption? I
think I had it even succeed on 512MB RAM per handwritten
notes here, but I haven't had the possibility to test again
on low specs.

Re: preparing the next release v0.15.0

[Kei Kebreau]

Marius Bakke  writes:

> On the NEWS side, here is what springs to mind:
>
[...]
> * Packages can specify that some CVEs don't apply to them

Around when (or what commit) was this feature introduced?


signature.asc
Description: PGP signature

Re: Bleeding edge documentation

[Nils Gillmann]

Joshua Branson transcribed 1.1K bytes:
> Ricardo Wurmus  writes:
> 
> > Nils Gillmann  writes:
> >
> >> swedebugia transcribed 1.0K bytes:
> >>> Hi
> >>>
> >>> I would like to have a continously updated documentation for guix on the 
> >>> webpage in addition to the release documentation.
> >>>
> >>> I'm trying to read up on guix and the guix.texi file is hard to handle on 
> >>> a mobile device and it is quite cumbersome.
> >>>
> >>> The 0.14 docs are now heavily outdated in my opinion.
> >>> --
> >>> Cheers Swedebugia
> >>
> >> This is due to gnu.org using CVS and with every release we have
> >> to upload the documentation by hand.
> >> Instead of moving the entire webpage out of gnu.org (which has
> >> been proposed before), why not create docs.guixsd.org and
> >> use that for updated documentation material?
> >
> > We have applied for a gnu.org subdomain a couple of weeks ago, but
> > progress is slow.  The goal is to move to infrastructure that we can
> > more easily (and automatically) update.
> 
> May I ask what are some of the other infrastructure options are?
> notabug? I'm sure you'll guys will choose a good one, but I'm just curious.

This is about choosing a static webview for the documentation,
not a convenience solution which renders them -- which notabug
doesn't do by the way.
The documentation you view on gnu.org is just checked in into CVS.

Re: Bleeding edge documentation

[Joshua Branson]

Ricardo Wurmus  writes:

> Nils Gillmann  writes:
>
>> swedebugia transcribed 1.0K bytes:
>>> Hi
>>>
>>> I would like to have a continously updated documentation for guix on the 
>>> webpage in addition to the release documentation.
>>>
>>> I'm trying to read up on guix and the guix.texi file is hard to handle on a 
>>> mobile device and it is quite cumbersome.
>>>
>>> The 0.14 docs are now heavily outdated in my opinion.
>>> --
>>> Cheers Swedebugia
>>
>> This is due to gnu.org using CVS and with every release we have
>> to upload the documentation by hand.
>> Instead of moving the entire webpage out of gnu.org (which has
>> been proposed before), why not create docs.guixsd.org and
>> use that for updated documentation material?
>
> We have applied for a gnu.org subdomain a couple of weeks ago, but
> progress is slow.  The goal is to move to infrastructure that we can
> more easily (and automatically) update.

May I ask what are some of the other infrastructure options are?
notabug? I'm sure you'll guys will choose a good one, but I'm just curious.

>
> --
> Ricardo

Re: Improving the README and new user experience

[swedebugia]

On June 20, 2018 10:24:47 AM GMT+02:00, Danny Milosavljevic 
 wrote:

... Snip

>Nano has paren matching (Alt-]) and commenting out (Alt-3).  It allows
>you to select text with cursor keys, then shift-cursor keys.
>
>It might make sense to patch the nano status line to mention that,
>though.
>
>I agree that otherwise it leaves something to be desired - but it can
>be used for editing lisp source code just fine.

That was news to me. Sounds good with a clarifying patch. 
Maybe the commenting out is just e making big changes and is is not needed for 
small incremental initial changes to the config. 
I will try to look into nano and see if I can figure out how to patch it. 

I think the manual should guide new users to a s little painful experience as 
possible. I will try building the installer and test it out as this would 
potentially take us a big step forward. 
-- 
Cheers Swedebugia

Re: Improving the README and new user experience

[Dan Partelly]

It is my oppinion that first you should very clearly define what you want from 
GuixSD 

a) is GuixSD to be a system which sees wide adoption , or is a system by 
developers for developers.
b) What kind of users ? Industrial use or amateurs at home ?
c) Server space, desktop space or both ?
d) if server space, actively think at security  and to the stability of the OS. 
Identify potential security risks of  running the custom kernel you have. 
Document it. Be open about it . Think at the implications of running a 
conservative garbage collector in several system demons. Uptime should be 
measured in year(s). See if it is a problem or not.Measure it .  Document it.
e) GuixSD is decent OS  and  follows NIX on the path of innovation . It would 
be a pitty to remain a niche used by a very small group of ppl . Do not focus 
just on the fact that the system is transactional, atomic and so on. Make it 
rock stable.


> I'm not quite sure yet how to improve the experience to new users.

1. Once you know this there is a lot you can do. Scheme is a good configuration 
language, but if you lack info on all the basics administration tasks and the 
semantics of the DSL the user is screwed. Documenting it is a must, for all 
common adminsitrative tasks
2. Make sure you use sound development practices, do not inflict the users upon 
the bleeding edge of your repository. I cannot stress enough how important this 
is, regardless of what you shoose to be the market of your product.
3. Treat it as a product, not as a hacking playground. I know it is not funny, 
but my guess is that it will help with adoption
4. Once you reach 1.0 , stop. Reflect on the bugs you have, and what 
documentation you lack. Make bug solving a priority for several point releases 
over new features. Or do both if you have sufficient manpower.
e) AIX Smitty is a great rpogram for configuring the system. It generates 
scripts, which the admin can execute and bring the OS in the desired state. You 
can generate Scheme from a similar system configuration tool, indicate the user 
it should review it, then
execute system recofniguration with guix command. 

> On Jun 20, 2018, at 10:20, Pierre Neidhardt  > wrote:
> 
> I'm not quite sure yet how to improve the experience to new users.  I'd
> need to install it several times, with other people and for different
> scenarios before I can be a better judge.

Re: Bleeding edge documentation

[Ricardo Wurmus]

Nils Gillmann  writes:

> swedebugia transcribed 1.0K bytes:
>> Hi
>>
>> I would like to have a continously updated documentation for guix on the 
>> webpage in addition to the release documentation.
>>
>> I'm trying to read up on guix and the guix.texi file is hard to handle on a 
>> mobile device and it is quite cumbersome.
>>
>> The 0.14 docs are now heavily outdated in my opinion.
>> --
>> Cheers Swedebugia
>
> This is due to gnu.org using CVS and with every release we have
> to upload the documentation by hand.
> Instead of moving the entire webpage out of gnu.org (which has
> been proposed before), why not create docs.guixsd.org and
> use that for updated documentation material?

We have applied for a gnu.org subdomain a couple of weeks ago, but
progress is slow.  The goal is to move to infrastructure that we can
more easily (and automatically) update.

--
Ricardo

Re: Bleeding edge documentation

[Nils Gillmann]

Ricardo Wurmus transcribed 888 bytes:
> 
> Nils Gillmann  writes:
> 
> > swedebugia transcribed 1.0K bytes:
> >> Hi
> >>
> >> I would like to have a continously updated documentation for guix on the 
> >> webpage in addition to the release documentation.
> >>
> >> I'm trying to read up on guix and the guix.texi file is hard to handle on 
> >> a mobile device and it is quite cumbersome.
> >>
> >> The 0.14 docs are now heavily outdated in my opinion.
> >> --
> >> Cheers Swedebugia
> >
> > This is due to gnu.org using CVS and with every release we have
> > to upload the documentation by hand.
> > Instead of moving the entire webpage out of gnu.org (which has
> > been proposed before), why not create docs.guixsd.org and
> > use that for updated documentation material?
> 
> We have applied for a gnu.org subdomain a couple of weeks ago, but
> progress is slow.  The goal is to move to infrastructure that we can
> more easily (and automatically) update.
> 
> --
> Ricardo
> 

Ah, good to know. Thanks

Re: Improving the README and new user experience

[Danny Milosavljevic]

>>  Also the editors included in the image are crap because they lack two 
>> important features: 1) keeping track of the damn paranteses and 2) comment 
>> and uncomment region.   
>Yes. nano is crap. vi has paren matching, but doest keep tack of them . 
>Editing lispy code with tracking of parens is not a pleasure. 

Nano has paren matching (Alt-]) and commenting out (Alt-3).  It allows you to 
select text with cursor keys, then shift-cursor keys.

It might make sense to patch the nano status line to mention that, though.

I agree that otherwise it leaves something to be desired - but it can be used 
for editing lisp source code just fine.


pgpYkWkoLG4kT.pgp
Description: OpenPGP digital signature

Re: Improving the README and new user experience

[Pierre Neidhardt]

I think this would be a great addition to Guix.

I agree that for now Guix' learning curve is pretty steep.  Even when
coming from rather barebone / Do-It-Yourself distributions like Gentoo /
Arch.

I'm not quite sure yet how to improve the experience to new users.  I'd
need to install it several times, with other people and for different
scenarios before I can be a better judge.

I know some work is being done to add an installation helper program to
the install image.

Dan Partelly  writes:

>>  Also the editors included in the image are crap because they lack two 
>> important features: 1) keeping track of the damn paranteses and 2) comment 
>> and uncomment region.
>
> Yes. nano is crap. vi has paren matching, but doest keep tack of them . 
> Editing lispy code with tracking of parens is not a pleasure.

Note that Guix also bundles Zile which is a tad better in my opinion.
Emacs would be Awesome but that would make the live image much heavier.

--
Pierre Neidhardt


signature.asc
Description: PGP signature

Re: Improving the README and new user experience

[Dan Partelly]

HI,

When somebody installs an OS , the last thing he wants is to have the OS craps 
on him in the next 10 minutes. And I can safely generalize this. People want to 
install the OS and then get on with their lives, do their work or whatever 
else. This is paramount for an OS. Be reliable and get out of the way. GuixSD 
unfortunately falls short here , but some aspects are easy to mitigate. This 
assumes that you want people to use your OS, and it’s not written by developers 
for developers only. Adoption of software is modulated by social factors much 
more then technical excellence. If somebody wants his tools

> I would like to help new users understand more about GuixSD before they run 
> it (and inevitably into errors) 

First thing, you must ensure that users do not run in the errors. If the users 
go inevitably into errors, then you have an issue with the design of the system 
and you have to rethink it. The simplest best way to mitigate this aspect is 
two fold:
- make a FAQ page as the first thing of the manual. Make sure it 
contains a glossary of specific terms such as  store, system profile, user 
profile, derivation, substitutes, explain structure, and some usual commands. 
Make sure it has a disclaimer the system is in beta, and may break, outlining 
the simplest way to recover. 
   - make sure you follow sane development practices and relase 
engineering. Take this very seriously. By no means have giux pull work by 
pulling from the bleeding edge of a  repository. In my opinion this is 
irresponsible. You just exposed your users to every bug imaginable in a 
development cycle. Guix is inevitably rolling, and to get last packages  you 
have to update it, but do this from intermediary branches such as 0.14.1 … 
0.14.n, branches which where regression  tested before beeing inflicted upon 
the user. 

> Users come from other Distros where tough package manager errors mostly mean: 
> you are screwed, reinstall. Because if you loose the central command to 
> manipulate the system - how can you possibly recover? Imagine apt being 
> corrupt or gone missing. 

This is not true. In classical distros, the central command to recover is not 
the package manager per se. It’s an editor in the first place, and only 
secondary the package manager. You are not screwed if the package manager craps 
on you, you have a lot of options to recover. You do not have to reinstall. 
Guix is much more central to GuixSD then pacman to arch for example, because 
well, it also wants to manage t system configuration for you, not just install 
some packages. 

> wen we need to educate them that this is something completely different where 
> it is actually hard to break (besides when running guix pull and not 
> understanding how to set paths manually) 

What you want is not easy recovery. This is important , but secondary to the 
fact that they **system should not break** in the first place.  guix pull is a 
very problematic command. Users do not want to do a command which supposedly 
gives them access to new packages and then have to recover. Again, user want to 
get the software, and get on with their lives. This means that you must have 
guix pull work flawlessly (industrial strength ) by the time you reach 1.0 I 
cannot stress enough how important this is for the adoption of your OS.

> I would like to tell new users NOT to change the config.scm at first install 
> if they are not confident schemers. (besides the username and timezone 
> perhaps). 

I dont think it’s OK. People want to configure the system. With how much 
fragmentation exist in Linux world it is unlikely you will be able to offer a 
good inital configuration which satisfy ppl coming from othe Linuxes. For 
example the default bare bones loaded a DNS caching demon for me. Why would I 
want that ? The config system should as user friendly as possible, and 
***DOCUMENTED**.  FAQ are in order:

 - how to I modify the base packages set
 - how do I add my own package set
 - how do I alter a package build options
 -what can be inherited and what not, and what inheriting gains me
 - how do I set timezone , locale
 - how do I create a network interface. use DHCP, fixed address. How do I 
create abridge network interface 
 - boot and initrd handling. Add new drenel driver to kmod Options for init 
demon 
 - filesystem handling. software raid handling. encryption of filesystems. 
-  time management. UCT times. NTP options
- conr options. cron administration.

You could offer a sample config which does all those examples. 


>  Also the editors included in the image are crap because they lack two 
> important features: 1) keeping track of the damn paranteses and 2) comment 
> and uncomment region. 

Yes. nano is crap. vi has paren matching, but doest keep tack of them . Editing 
lispy code with tracking of parens is not a pleasure. 

Also document every bug and quirk of this system.

 

> On Jun 20, 2018, at 07:46, swedebugia  wrote:
> 
> Hi
> 
> I 

Re: Bleeding edge documentation

[Nils Gillmann]

swedebugia transcribed 1.0K bytes:
> Hi
> 
> I would like to have a continously updated documentation for guix on the 
> webpage in addition to the release documentation.
> 
> I'm trying to read up on guix and the guix.texi file is hard to handle on a 
> mobile device and it is quite cumbersome.
> 
> The 0.14 docs are now heavily outdated in my opinion. 
> -- 
> Cheers Swedebugia 

This is due to gnu.org using CVS and with every release we have
to upload the documentation by hand.
Instead of moving the entire webpage out of gnu.org (which has
been proposed before), why not create docs.guixsd.org and
use that for updated documentation material?

Re: Fwd: bug#31907: Acknowledgement (New users get wrong/old profile path to guix after reconfiguring )

[Nils Gillmann]

swedebugia transcribed 5.0K bytes:
> Hi
> 
> I just reported this bug. 
> 
> As a reaction to the recent guix pull update and the people who had a bad 
> experience I have an idea.
> 
> We create a new guix command that
> 1) analyze the current users paths and tell them if
> 1.1) they are good and warns them if they are not and propose a solution in a 
> user-friendly way.  
> 2) gives them the possibility to scan and inherit a newer guix from another 
> user without having to run guix pull, build a derivation etc. 

Wouldn't the two points below be something for a man page? At least they would 
include a manpage and
a local mail telling you to read more on it if I'd do it.

> 3) (perhaps) educates the users about what happens when they run pull, 
> reconfures, etc. as different users. 
> 4) (perhaps) helps them to abuse the symlinks so that e.g. roots profile 
> follow the current user's or vice versa. 
> 
> This would enable new users to do a sanity check on guix when they don't yet 
> understand the way guix symlinks, store, pulling, etc. works.
> 
> This would also save time and bandwidth because you really don't want to run 
> guix pull multiple times as different users considering the time it takes to 
> compile. 
> 
> What do you think? 

Some are a bit vague but in general those are good ideass.

> 
>  Original Message 
> From: help-debb...@gnu.org
> Sent: June 20, 2018 5:20:02 AM GMT+02:00
> To: swedebugia 
> Subject: bug#31907: Acknowledgement (New users get wrong/old profile path to 
> guix after reconfiguring )
> 
> Thank you for filing a new bug report with debbugs.gnu.org.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  bug-g...@gnu.org
> 
> If you wish to submit further information on this problem, please
> send it to 31...@debbugs.gnu.org.
> 
> Please do not send mail to help-debb...@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
> 
> -- 
> 31907: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31907
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
> 
> -- 
> Cheers Swedebugia