unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* guixsd offline installation media
@ 2015-12-16  4:07 Dika Setya Prayogi
  2015-12-16  4:42 ` Pjotr Prins
  2015-12-17 22:41 ` guixsd offline installation media Ludovic Courtès
  0 siblings, 2 replies; 13+ messages in thread
From: Dika Setya Prayogi @ 2015-12-16  4:07 UTC (permalink / raw)
  To: guix-devel

can we make an offline installation media for future guixsd ? because
it is more reliable and easy to build in slow or problematic bandwith
like in my town

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

* Re: guixsd offline installation media
  2015-12-16  4:07 guixsd offline installation media Dika Setya Prayogi
@ 2015-12-16  4:42 ` Pjotr Prins
  2015-12-16  4:57   ` Pjotr Prins
  2015-12-17 22:41 ` guixsd offline installation media Ludovic Courtès
  1 sibling, 1 reply; 13+ messages in thread
From: Pjotr Prins @ 2015-12-16  4:42 UTC (permalink / raw)
  To: Dika Setya Prayogi; +Cc: guix-devel

On Wed, Dec 16, 2015 at 11:07:34AM +0700, Dika Setya Prayogi wrote:
> can we make an offline installation media for future guixsd ? because
> it is more reliable and easy to build in slow or problematic bandwith
> like in my town
> 

+1 (from Africa). In combination with a conscise description how to
set up a caching server.

-- 

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

* Re: guixsd offline installation media
  2015-12-16  4:42 ` Pjotr Prins
@ 2015-12-16  4:57   ` Pjotr Prins
  2015-12-17 22:35     ` Ludovic Courtès
  0 siblings, 1 reply; 13+ messages in thread
From: Pjotr Prins @ 2015-12-16  4:57 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel, Dika Setya Prayogi

I suggest we brand it GuixSD-Sumo. 

Which reminds me, is there a way of simply rolling back on a 'guix pull' command?

Pj.

On Wed, Dec 16, 2015 at 05:42:36AM +0100, Pjotr Prins wrote:
> On Wed, Dec 16, 2015 at 11:07:34AM +0700, Dika Setya Prayogi wrote:
> > can we make an offline installation media for future guixsd ? because
> > it is more reliable and easy to build in slow or problematic bandwith
> > like in my town
> > 
> 
> +1 (from Africa). In combination with a conscise description how to
> set up a caching server.
> 
> -- 
> 

-- 

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

* Re: guixsd offline installation media
  2015-12-16  4:57   ` Pjotr Prins
@ 2015-12-17 22:35     ` Ludovic Courtès
  2015-12-18  3:40       ` Pjotr Prins
  0 siblings, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2015-12-17 22:35 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel, Dika Setya Prayogi

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> Which reminds me, is there a way of simply rolling back on a 'guix pull' command?

Not yet!

Ludo’.

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

* Re: guixsd offline installation media
  2015-12-16  4:07 guixsd offline installation media Dika Setya Prayogi
  2015-12-16  4:42 ` Pjotr Prins
@ 2015-12-17 22:41 ` Ludovic Courtès
  2015-12-18  8:03   ` Dika Setya Prayogi
  1 sibling, 1 reply; 13+ messages in thread
From: Ludovic Courtès @ 2015-12-17 22:41 UTC (permalink / raw)
  To: Dika Setya Prayogi; +Cc: guix-devel

Hi!

Dika Setya Prayogi <dikasetyaprayogi@gmail.com> skribis:

> can we make an offline installation media for future guixsd ? because
> it is more reliable and easy to build in slow or problematic bandwith
> like in my town

The main difficulty is that the set of packages needed depends on what
the OS configuration file contains.

We could populate the installation media such that it contains
everything needed for the bare-bones.scm config, or for the desktop.scm
config (but it would be big!).

However, as soon as the user would choose a different config, they would
have to download different things, and perhaps those already in the
installation image would happen to be unnecessary.

Thoughts?

BTW, note that our current server at hydra.gnu.org performs very badly,
which explains the slow bandwidth (as well as the current fundraiser,
see <http://www.gnu.org/software/guix/donate/>.  :-)).

Ludo’.

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

* Re: guixsd offline installation media
  2015-12-17 22:35     ` Ludovic Courtès
@ 2015-12-18  3:40       ` Pjotr Prins
  2015-12-18 17:41         ` Mark H Weaver
  0 siblings, 1 reply; 13+ messages in thread
From: Pjotr Prins @ 2015-12-18  3:40 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Dika Setya Prayogi

If it is technically feasibly it would be a great feature to go back
in time without resorting to using a checkout of the guix source tree
:)

Also, I have occassionally regretted doing a guix pull. When facing a
complete download on a slow internet line. Heh. Definitely a feature
request to be able to do an unpull.

Pj.

On Thu, Dec 17, 2015 at 11:35:40PM +0100, Ludovic Courtès wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
> 
> > Which reminds me, is there a way of simply rolling back on a 'guix pull' command?
> 
> Not yet!
> 
> Ludo’.
> 

-- 

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

* Re: guixsd offline installation media
  2015-12-17 22:41 ` guixsd offline installation media Ludovic Courtès
@ 2015-12-18  8:03   ` Dika Setya Prayogi
  2015-12-18  9:19     ` Pjotr Prins
  0 siblings, 1 reply; 13+ messages in thread
From: Dika Setya Prayogi @ 2015-12-18  8:03 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

I understand, that's why I write it "for future guixsd" not for next
guixsd. from my thoughs offline installation is the nicest way to
autobuild a system. for me, I prefer download an 4Gb iso file rather
than failing build 4 times (that will make me angry and wreck
something, lol). and in this modern live there is many download option
like a postponeable download ex:torrent that will cover up an slow
bandwith, but in a case sensitive like building OS, a failed download
can be a disaster. my conclusion is it's nice to have a stable system
first then you can costumize or wreck it as you want, whatever how
many times you misconfigured or break your os you can reinstall the
stable installation and wreck it again. thanks for your attention Ludo
:-)

2015-12-18 5:41 GMT+07.00, Ludovic Courtès <ludo@gnu.org>:
> Hi!
>
> Dika Setya Prayogi <dikasetyaprayogi@gmail.com> skribis:
>
>> can we make an offline installation media for future guixsd ? because
>> it is more reliable and easy to build in slow or problematic bandwith
>> like in my town
>
> The main difficulty is that the set of packages needed depends on what
> the OS configuration file contains.
>
> We could populate the installation media such that it contains
> everything needed for the bare-bones.scm config, or for the desktop.scm
> config (but it would be big!).
>
> However, as soon as the user would choose a different config, they would
> have to download different things, and perhaps those already in the
> installation image would happen to be unnecessary.
>
> Thoughts?
>
> BTW, note that our current server at hydra.gnu.org performs very badly,
> which explains the slow bandwidth (as well as the current fundraiser,
> see <http://www.gnu.org/software/guix/donate/>.  :-)).
>
> Ludo’.
>

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

* Re: guixsd offline installation media
  2015-12-18  8:03   ` Dika Setya Prayogi
@ 2015-12-18  9:19     ` Pjotr Prins
  2015-12-20 12:08       ` Efraim Flashner
  0 siblings, 1 reply; 13+ messages in thread
From: Pjotr Prins @ 2015-12-18  9:19 UTC (permalink / raw)
  To: Dika Setya Prayogi; +Cc: guix-devel

If you are on a slow connection (and 90% of the world IS on a slow
connection) downloads are a problem. I am in Africa now. Guix
pull is one problem - I accidentily did that and now I can't do
anything because it wants to fetch a complete rebuilt Guix. But also 
installing by package is problematic, though I appreciate that
Guix does not load things twice (well, actually it does when a
transaction gets interrupted or fails - we could avoid that by caching
intermediate source tar balls and binary downloads, really no reason
not to since they have hashes too).

Similar to the minimal tar-ball release we could provide a bare-bones,
desktop, desktop for developers, and 'sumo' release quite easily and
seed those with torrents. I think. It would also make sense to sell
DVD's or USB's with Guix installed. Maybe a little side-business for
the FSF?

Pretty much what Debian does.

Even though Guix is a rolling update distribution, tar-ball installs
make sense.

Pj.

On Fri, Dec 18, 2015 at 03:03:31PM +0700, Dika Setya Prayogi wrote:
> I understand, that's why I write it "for future guixsd" not for next
> guixsd. from my thoughs offline installation is the nicest way to
> autobuild a system. for me, I prefer download an 4Gb iso file rather
> than failing build 4 times (that will make me angry and wreck
> something, lol). and in this modern live there is many download option
> like a postponeable download ex:torrent that will cover up an slow
> bandwith, but in a case sensitive like building OS, a failed download
> can be a disaster. my conclusion is it's nice to have a stable system
> first then you can costumize or wreck it as you want, whatever how
> many times you misconfigured or break your os you can reinstall the
> stable installation and wreck it again. thanks for your attention Ludo
> :-)
> 
> 2015-12-18 5:41 GMT+07.00, Ludovic Courtès <ludo@gnu.org>:
> > Hi!
> >
> > Dika Setya Prayogi <dikasetyaprayogi@gmail.com> skribis:
> >
> >> can we make an offline installation media for future guixsd ? because
> >> it is more reliable and easy to build in slow or problematic bandwith
> >> like in my town
> >
> > The main difficulty is that the set of packages needed depends on what
> > the OS configuration file contains.
> >
> > We could populate the installation media such that it contains
> > everything needed for the bare-bones.scm config, or for the desktop.scm
> > config (but it would be big!).
> >
> > However, as soon as the user would choose a different config, they would
> > have to download different things, and perhaps those already in the
> > installation image would happen to be unnecessary.
> >
> > Thoughts?
> >
> > BTW, note that our current server at hydra.gnu.org performs very badly,
> > which explains the slow bandwidth (as well as the current fundraiser,
> > see <http://www.gnu.org/software/guix/donate/>.  :-)).
> >
> > Ludo’.
> >
> 

-- 

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

* Re: guixsd offline installation media
  2015-12-18  3:40       ` Pjotr Prins
@ 2015-12-18 17:41         ` Mark H Weaver
  2015-12-18 20:11           ` Pjotr Prins
  2015-12-19 14:09           ` ‘guix pull’ vs. Git Ludovic Courtès
  0 siblings, 2 replies; 13+ messages in thread
From: Mark H Weaver @ 2015-12-18 17:41 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel, Dika Setya Prayogi

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> If it is technically feasibly it would be a great feature to go back
> in time without resorting to using a checkout of the guix source tree
> :)

I'm not sure why using a git checkout should be considered an
unfortunate thing to have to resort to.  To my mind, it is precisely the
right tool for the job, and far more flexible and efficient than using
"guix pull".  It is the way I've been using 'guix' from the beginning.
I recommend giving it a try some time :)

     Regards,
       Mark

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

* Re: guixsd offline installation media
  2015-12-18 17:41         ` Mark H Weaver
@ 2015-12-18 20:11           ` Pjotr Prins
  2015-12-19 14:09           ` ‘guix pull’ vs. Git Ludovic Courtès
  1 sibling, 0 replies; 13+ messages in thread
From: Pjotr Prins @ 2015-12-18 20:11 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Dika Setya Prayogi

Hi Mark,

On Fri, Dec 18, 2015 at 12:41:27PM -0500, Mark H Weaver wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > If it is technically feasibly it would be a great feature to go back
> > in time without resorting to using a checkout of the guix source tree
> > :)
> 
> I'm not sure why using a git checkout should be considered an
> unfortunate thing to have to resort to.  To my mind, it is precisely the
> right tool for the job, and far more flexible and efficient than using
> "guix pull".  It is the way I've been using 'guix' from the beginning.
> I recommend giving it a try some time :)

I use git *all* the time. No issue with that.

I don't think we can ask that from most users.

We are talking reproducible deployment here.

Pj.

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

* ‘guix pull’ vs. Git
  2015-12-18 17:41         ` Mark H Weaver
  2015-12-18 20:11           ` Pjotr Prins
@ 2015-12-19 14:09           ` Ludovic Courtès
  1 sibling, 0 replies; 13+ messages in thread
From: Ludovic Courtès @ 2015-12-19 14:09 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: guix-devel, Dika Setya Prayogi

Mark H Weaver <mhw@netris.org> skribis:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> If it is technically feasibly it would be a great feature to go back
>> in time without resorting to using a checkout of the guix source tree
>> :)
>
> I'm not sure why using a git checkout should be considered an
> unfortunate thing to have to resort to.  To my mind, it is precisely the
> right tool for the job, and far more flexible and efficient than using
> "guix pull".  It is the way I've been using 'guix' from the beginning.
> I recommend giving it a try some time :)

I think Git is the right tool, but the wrong UI.  :-)  Not to mention
./pre-inst-env.

Ideally, ‘guix pull’ would do exactly the same as what one does with
Git, except in a more automated, user-friendly, and bullet-proof fashion
(no need to wonder about ABI breakage, for instance.)

WDYT?

Ludo’.

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

* Re: guixsd offline installation media
  2015-12-18  9:19     ` Pjotr Prins
@ 2015-12-20 12:08       ` Efraim Flashner
  2015-12-23 10:12         ` Alex Vong
  0 siblings, 1 reply; 13+ messages in thread
From: Efraim Flashner @ 2015-12-20 12:08 UTC (permalink / raw)
  To: Pjotr Prins; +Cc: guix-devel, Dika Setya Prayogi

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

On Fri, 18 Dec 2015 10:19:14 +0100
Pjotr Prins <pjotr.public12@thebird.nl> wrote:

> If you are on a slow connection (and 90% of the world IS on a slow
> connection) downloads are a problem. I am in Africa now. Guix
> pull is one problem - I accidentily did that and now I can't do
> anything because it wants to fetch a complete rebuilt Guix. But also 
> installing by package is problematic, though I appreciate that
> Guix does not load things twice (well, actually it does when a
> transaction gets interrupted or fails - we could avoid that by caching
> intermediate source tar balls and binary downloads, really no reason
> not to since they have hashes too).
> 
> Similar to the minimal tar-ball release we could provide a bare-bones,
> desktop, desktop for developers, and 'sumo' release quite easily and
> seed those with torrents. I think. It would also make sense to sell
> DVD's or USB's with Guix installed. Maybe a little side-business for
> the FSF?
> 
> Pretty much what Debian does.
> 
> Even though Guix is a rolling update distribution, tar-ball installs
> make sense.
> 
> Pj.
> 
I was going to make jokes about apt-cd and the years of issues that's caused
people with fresh debian installs, but all we should need to do is
populate /gnu/store with either/both precompiled binaries/source files.
If/when substitutes fails, the files are already there.

As an aside, I don't think targeting DVD size is a good idea, but maybe
4GB/8GB for usb sticks shouldn't be bad. Also if we had a torrent it would be
easier to not rely directly on hydra for starting up. Also its an easy way to
donate bandwidth without setting up a hydra clone.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

* Re: guixsd offline installation media
  2015-12-20 12:08       ` Efraim Flashner
@ 2015-12-23 10:12         ` Alex Vong
  0 siblings, 0 replies; 13+ messages in thread
From: Alex Vong @ 2015-12-23 10:12 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel, Dika Setya Prayogi

Efraim Flashner <efraim@flashner.co.il> writes:

> I was going to make jokes about apt-cd and the years of issues that's caused
> people with fresh debian installs, but all we should need to do is
> populate /gnu/store with either/both precompiled binaries/source files.
> If/when substitutes fails, the files are already there.
>
> As an aside, I don't think targeting DVD size is a good idea, but maybe
> 4GB/8GB for usb sticks shouldn't be bad. Also if we had a torrent it would be
> easier to not rely directly on hydra for starting up. Also its an easy way to
> donate bandwidth without setting up a hydra clone.
I like the idea of having torrents for those huge binaries, this should
really speed up the downloading process.

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

end of thread, other threads:[~2015-12-23 10:12 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-16  4:07 guixsd offline installation media Dika Setya Prayogi
2015-12-16  4:42 ` Pjotr Prins
2015-12-16  4:57   ` Pjotr Prins
2015-12-17 22:35     ` Ludovic Courtès
2015-12-18  3:40       ` Pjotr Prins
2015-12-18 17:41         ` Mark H Weaver
2015-12-18 20:11           ` Pjotr Prins
2015-12-19 14:09           ` ‘guix pull’ vs. Git Ludovic Courtès
2015-12-17 22:41 ` guixsd offline installation media Ludovic Courtès
2015-12-18  8:03   ` Dika Setya Prayogi
2015-12-18  9:19     ` Pjotr Prins
2015-12-20 12:08       ` Efraim Flashner
2015-12-23 10:12         ` Alex Vong

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