guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] A simple draft for channels


From: myglc2
Subject: Re: [RFC] A simple draft for channels
Date: Wed, 24 Jan 2018 00:44:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

On 01/23/2018 at 16:50 address@hidden writes:

> myglc2 writes:
>> On 01/19/2018 at 14:41 Ludovic Courtès writes:
>>
>>> Hi!
>>>
>>> Ricardo Wurmus <address@hidden> skribis:
>>>
>>>> As a first implementation of channels I’d just like to have a channel
>>>> description file that records at least the following things:
> […]
>>> One thing that’s still an open question is how we should treat Guix
>>> itself in that channelized world.
>>>
>>> Should Guix be a “normal” channel?  It’s tempting to think of it as a
>>> regular channel; however, it’s definitely “special” in that it can
>>> update the ‘guix’ command, maybe guix-daemon & co., locale data, etc.
>>> How does that affect ‘guix channel’?
>>
>> ISTM this design allows channels to inject non-free &/or non-safe
>> components into other user's Guix systems. Is that true?
>>
>> If so, how will it impact the Guix promise of software freedom/safety?
>>
>> WDYT? - George
>
> Just commenting on this one for now until I got my mail fixed:
>
> Why is this a problem? Already today you can run Guix with as many
> modifications as you like to, and you are free to install whatever you
> want.  That's one of the very good aspects of Guix - you can use it to
> create whatever you like.  Or maybe you need to expand a bit on the
> sentences you wrote George.

Yes, and this is important to the current user base. But in the future
the majority of our users will be end-users that do not directly use FSF
freedoms & Guix hackability. Still, they will choose Guix because this
freedom and hackability provides indirect benefits such as enhanced
security and safety.

Yes, FSF freedom means we must permit any user to shoot themselves in
the foot. But with GUIX_PACKAGE_PATH, this is not a worry.

Channels dramatically increases the ease with which an end-user can harm
themselves by e.g. using a channel that delivers non-free &/or non-safe
software. This raises the question: are we obliged to, and if so, how do
we help end-users protect themselves from this risk?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]