unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Review of pros and cons of package managers including Guix
@ 2018-11-08  9:09 swedebugia
  2018-11-08  9:43 ` Thorsten Wilms
  2018-11-11 13:33 ` Ludovic Courtès
  0 siblings, 2 replies; 5+ messages in thread
From: swedebugia @ 2018-11-08  9:09 UTC (permalink / raw)
  To: guix-devel

Hi

I stumpled upon this today:

https://www.slant.co/topics/344/~best-linux-package-managers

Insights from the Guix-section:

4 pros: (missing the roll-back feature) see link.

1 cons:

"Cannot handle filetypes that have different semantics across different 
versions
While the functional approach that Guix takes is great for sandboxing 
binary artifacts of packages, it seriously lacks any power in handling 
configuration files or user data. It's difficult to upgrade and 
downgrade files where semantics and syntax can change between versions."

Do you agree with this critique?

Should we ask the author to give an example of this?

-- 
Cheers
Swedebugia

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Review of pros and cons of package managers including Guix
  2018-11-08  9:09 Review of pros and cons of package managers including Guix swedebugia
@ 2018-11-08  9:43 ` Thorsten Wilms
  2018-11-08 15:31   ` Adam Van Ymeren
  2018-11-11 13:33 ` Ludovic Courtès
  1 sibling, 1 reply; 5+ messages in thread
From: Thorsten Wilms @ 2018-11-08  9:43 UTC (permalink / raw)
  To: guix-devel

On 08/11/2018 10.09, swedebugia wrote:
> 
> https://www.slant.co/topics/344/~best-linux-package-managers
> 
> Insights from the Guix-section:
> 
> 4 pros: (missing the roll-back feature) see link.
> 
> 1 cons:
> 
> "Cannot handle filetypes that have different semantics across different 
> versions
> While the functional approach that Guix takes is great for sandboxing 
> binary artifacts of packages, it seriously lacks any power in handling 
> configuration files or user data. It's difficult to upgrade and 
> downgrade files where semantics and syntax can change between versions."
> 
> Do you agree with this critique?

The whole page is far from a worthwhile comparison, because the "cons" 
and "pros" are all over the place. Characteristics that are listed  as 
either for one manager do not appear for all others that have them, too.

This specific con could be listed for most, if not all others, too, 
right? Curious, if anyone knows an exception.

The best handling of configuration files I got to know is offered by 
Debian, which, if a package comes with a new configuration file, asks 
what to do about it. Better than nothing, but still not exactly a good 
user experience. There quite simply isn't the right level of granularity 
and encoding of intentions given with plain text configuration files.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Review of pros and cons of package managers including Guix
  2018-11-08  9:43 ` Thorsten Wilms
@ 2018-11-08 15:31   ` Adam Van Ymeren
  2018-11-08 16:11     ` swedebugia
  0 siblings, 1 reply; 5+ messages in thread
From: Adam Van Ymeren @ 2018-11-08 15:31 UTC (permalink / raw)
  To: t_w_



On November 8, 2018 4:43:23 AM EST, Thorsten Wilms <t_w_@freenet.de> wrote:
>On 08/11/2018 10.09, swedebugia wrote:
>> 
>> https://www.slant.co/topics/344/~best-linux-package-managers
>> 
>> Insights from the Guix-section:
>> 
>> 4 pros: (missing the roll-back feature) see link.
>> 
>> 1 cons:
>> 
>> "Cannot handle filetypes that have different semantics across
>different 
>> versions
>> While the functional approach that Guix takes is great for sandboxing
>
>> binary artifacts of packages, it seriously lacks any power in
>handling 
>> configuration files or user data. It's difficult to upgrade and 
>> downgrade files where semantics and syntax can change between
>versions."
>> 
>> Do you agree with this critique?
>
>The whole page is far from a worthwhile comparison, because the "cons" 
>and "pros" are all over the place. Characteristics that are listed  as 
>either for one manager do not appear for all others that have them,
>too.
>
>This specific con could be listed for most, if not all others, too, 
>right? Curious, if anyone knows an exception.
>
>The best handling of configuration files I got to know is offered by 
>Debian, which, if a package comes with a new configuration file, asks 
>what to do about it. Better than nothing, but still not exactly a good 
>user experience. There quite simply isn't the right level of
>granularity 
>and encoding of intentions given with plain text configuration files.

Guix is in a position to do better than most in this area.  I love how most services in Guix are configured via s-expressions which then generate the appropriate plain text config from that.  Don't have to learn a new syntax for every service.

It also means that configurations are usable data in the Guix world, allowing us to automatically upgrade configs to new syntax if a package decides to change it.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Review of pros and cons of package managers including Guix
  2018-11-08 15:31   ` Adam Van Ymeren
@ 2018-11-08 16:11     ` swedebugia
  0 siblings, 0 replies; 5+ messages in thread
From: swedebugia @ 2018-11-08 16:11 UTC (permalink / raw)
  To: Adam Van Ymeren, t_w_, guix-devel

Hi

On 2018-11-08 16:31, Adam Van Ymeren wrote:
> On November 8, 2018 4:43:23 AM EST, Thorsten Wilms <t_w_@freenet.de> wrote:
>> On 08/11/2018 10.09, swedebugia wrote:
>>> https://www.slant.co/topics/344/~best-linux-package-managers
>>>
>>> Insights from the Guix-section:
>>>
>>> 4 pros: (missing the roll-back feature) see link.
>>>
>>> 1 cons:
>>>
>>> "Cannot handle filetypes that have different semantics across
>> different
>>> versions
>>> While the functional approach that Guix takes is great for sandboxing
>>> binary artifacts of packages, it seriously lacks any power in
>> handling
>>> configuration files or user data. It's difficult to upgrade and
>>> downgrade files where semantics and syntax can change between
>> versions."
>>> Do you agree with this critique?
>>
>> The best handling of configuration files I got to know is offered by
>> Debian, which, if a package comes with a new configuration file, asks
>> what to do about it. Better than nothing, but still not exactly a good
>> user experience. There quite simply isn't the right level of
>> granularity
>> and encoding of intentions given with plain text configuration files.
> Guix is in a position to do better than most in this area.  I love how most services in Guix are configured via s-expressions which then generate the appropriate plain text config from that.  Don't have to learn a new syntax for every service.
>
> It also means that configurations are usable data in the Guix world, allowing us to automatically upgrade configs to new syntax if a package decides to change it.

I totally agree!

The Scheme s-expressions was a somewhat steep learning curve but now 
having passed it and beginning to understand the error messages from the 
Guile IT IS AWESOME.

1 powerful extension language to rule all the packages and configuration 
files :D

I keep track of my config.scm with git and it is simple to see the 
changes over time as I customize and tweak things.

I wish Guix had existed when I started with GNU/Linux 15 years ago. I 
began with Xandros and then moved on to Debian, Ubuntu and then Parabola.

-- 
Cheers
Swedebugia

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Review of pros and cons of package managers including Guix
  2018-11-08  9:09 Review of pros and cons of package managers including Guix swedebugia
  2018-11-08  9:43 ` Thorsten Wilms
@ 2018-11-11 13:33 ` Ludovic Courtès
  1 sibling, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2018-11-11 13:33 UTC (permalink / raw)
  To: swedebugia; +Cc: guix-devel

Hello,

swedebugia <swedebugia@riseup.net> skribis:

> I stumpled upon this today:
>
> https://www.slant.co/topics/344/~best-linux-package-managers

This web page is very weak IMO, which is a bit sad.

> "Cannot handle filetypes that have different semantics across
> different versions
> While the functional approach that Guix takes is great for sandboxing
> binary artifacts of packages, it seriously lacks any power in handling
> configuration files or user data. It's difficult to upgrade and
> downgrade files where semantics and syntax can change between
> versions."
>
> Do you agree with this critique?

Yes and no, it’s too vague to provide a definite answer.

On GuixSD (not Guix), configuration files of system services are
generated from a more abstract representation of the config in Scheme.
For instance, you define an ‘openssh-configuration’ object and from that
we generated ‘/etc/sshd_config’ or whatever it’s called.  In that sense,
users of GuixSD have the guarantee (modulo bugs of course) that the
generated configuration files use syntax that is compatible with the
service in use—in this case, OpenSSH.

The problem of “user data” is different.  If you have a system running
PostgreSQL and the on-disk database format changes, then indeed, you
won’t really be able to roll back to a previous GuixSD generations since
the old PostgreSQL may be unable to read the new on-disk format of the
database.  This is a known problem, but it’s not really specific to
GuixSD and NixOS; it’s just that the problem becomes visible precisely
because NixOS and GuixSD support rollbacks.

HTH,
Ludo’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-11-11 13:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-08  9:09 Review of pros and cons of package managers including Guix swedebugia
2018-11-08  9:43 ` Thorsten Wilms
2018-11-08 15:31   ` Adam Van Ymeren
2018-11-08 16:11     ` swedebugia
2018-11-11 13:33 ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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).