Dialog package and graphic installer using dialog

[Ivan Gualandri]

Hi all, 

i noticed that now the dialog package compile without problems. 

Then i'm planning to develop an update to the actual minix installer script (setup) using the graphical interface  provided by dialog (that use curses).

At the following links you can find two examples of how the new installer could become (or maybe it could be just an alternate installer):

1. http://i.imgur.com/Vi6le.png

2. http://i.imgur.com/mhdrt.png

The only techincal question for have the  dialog based installer on minix is that the package dialog is needed in the live cd (and i think it could be done). 

Another question is about a potential license issue since dialog is released under LGPL license. It could be a problem? 

Are you interested in that update?

Many thanks,

Ivan

--
"elen sila lumenn omentielvo"

[pikpik]

Hi,

On Jan 8, 1:27 pm, Ivan Gualandri wrote:
>
> Then i'm planning to develop an update to the actual minix installer script
> (setup) using the graphical interface  provided by dialog (that use curses).
>
> At the following links you can find two examples of how the new installer
> could become (or maybe it could be just an alternate installer):
> 1.http://i.imgur.com/Vi6le.png
> 2.http://i.imgur.com/mhdrt.png
>

This is very interesting! Thanks for working on it.

>
> The only techincal question for have the  dialog based installer on minix
> is that the package dialog is needed in the live cd (and i think it could
> be done).
>

Yes, I think this is not too difficult.

>
> Another question is about a potential license issue since dialog is
> released under LGPL license. It could be a problem?
>

I don't remember the differences between GPL and LGPL very well, but I
think LGPL is more permissive and allows use in closed-source things.
If that's true, then I think it should be compatible with our BSD
license.

>
> Are you interested in that update?
>

Yes. If users are given a choice of either a graphical or non-
graphical installer, then I like this idea!

Would you mind if this is changed in the future as a framework for
later graphical installers?

Thank you very much!
pikpik

[Ivan]

I started to work on it.

Here is my fork of minix git repository with the updates for new setup
command:

https://github.com/inuyasha82/minix/blob/setupgui/commands/setup-gui/setup-gui.sh

Ivan

[Ivan]

Sorry,
that link is for the file i had created for the new setup.
The repository address is:

https://github.com/inuyasha82/minix/tree/setupgui

Actually it is not completed, i managed to have the first two dialog
boxes (welcome and keyboard setup) and some error messages.
Probably if you create the cd with that tree, the command setup-gui
still doesn't work, because of some things to be fixed (probably the
will be fixed in the next few days).

Bye,
Ivan

On 14 Gen, 16:27, Ivan <ivan.gualan...@gmail.com> wrote:
> I started to work on it.
>
> Here is my fork of minix git repository with the updates for new setup
> command:
>

> https://github.com/inuyasha82/minix/blob/setupgui/commands/setup-gui/...

[Ivan Gualandri]

Hi all, 

in these days i worked on the dialog based setup (i hope someone is interested). 

It is quite completed, i just need to add the final touches some error checs. I prepared a video to show how it could appear: 

http://www.youtube.com/watch?v=ugqbRCYPYP0&feature=g-all-esi&context=G2926cafFAAAAAAAAAAA 

As you can seeThere are 2 parts that must be done in without dialog:

1. partitioning because it is based on an external program 

2. netconf because it call an external script (in the future also that script could be updated to use dialog)

Actually the dialog  setup works only for automatic setup (not expert).

Now i only want to know, if there is interest in that work, if you think that it could be included as an alternative installer for minix (keeping the old one). 

You find the sources in my minix fork on github: https://github.com/inuyasha82/minix

The command is: setup-gui.

I prepared also an iso with the updated command: http://dl.dropbox.com/u/60798742/minix3_2_0_ide_copy.iso.bz2 

Let me know what do you think :)

Bye, 

Ivan

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

[Tom Chandler]

Watch the video.  GREAT WORK.  I hope this work gets included
in the official release.  Moves the "bar" higher, show Minix3 is
truly a maturing OS and easy to use.

Tom C

[Andy Kosela]

On Thu, Feb 16, 2012 at 9:22 PM, Tom Chandler <tchan...@gmail.com> wrote:
> Watch the video.  GREAT WORK.  I hope this work gets included
> in the official release.  Moves the "bar" higher, show Minix3 is
> truly a maturing OS and easy to use.

Yes, great work but I just hope that Minix will not abandon its CLI
only installer. It is simple but effective and pure, kinda like
OpenBSD installer.

--Andy

[Ivan Gualandri]

Thank you tom, 

i hope too that this update will be considered for an insertion into the official release. 

On 16 February 2012 21:39, Andy Kosela <ako...@andykosela.com> wrote:

On Thu, Feb 16, 2012 at 9:22 PM, Tom Chandler <tchan...@gmail.com> wrote:
> Watch the video.  GREAT WORK.  I hope this work gets included
> in the official release.  Moves the "bar" higher, show Minix3 is
> truly a maturing OS and easy to use.

Andy, my idea is not to replace the old setup script, but is to provide an alternative. 

I think that a good idea is to have 2 separate commands:

1. setup - The old fashioned installer

2. setup-gui - The new dialog installer

 

Yes, great work but I just hope that Minix will not abandon its CLI
only installer.  It is simple but effective and pure, kinda like
OpenBSD installer.

--Andy

 

Ivan

[ben gras]

Fantastic job, very impressive.

The progress bar is a very nice touch too.

I think dialog is GPLled, or uses an LGPLled library, right..? That is unfortunately a problem for using the distribution. Perhaps you can recreate your work with the bsd-licensed clone? And I think the complete forking of setup is a bit suboptimal (double updates). The actions should be shared where possible; or perhaps your code could be merged into setup itself, which then has 2 modes (is is callable from 2 names, etc.).

If you are willing to address these things I don't see why we couldn't adopt it.

Thanks a lot for doing all that work, the video is a nice touch too.

[Evgeniy Ivanov]

Hi,

On Thu, Feb 16, 2012 at 10:40 PM, Ivan Gualandri
<ivan.gu...@gmail.com> wrote:
> Hi all,
>
> in these days i worked on the dialog based setup (i hope someone is
> interested).
>
> It is quite completed, i just need to add the final touches some error
> checs. I prepared a video to show how it could appear:
> http://www.youtube.com/watch?v=ugqbRCYPYP0&feature=g-all-esi&context=G2926cafFAAAAAAAAAAA

Well done! I enjoyed the video :-)

--
Evgeniy

[Ivan Gualandri]

On 17 February 2012 01:43, ben gras <b...@minix3.org> wrote:

Fantastic job, very impressive.

The progress bar is a very nice touch too.

Thanks. 

I think dialog is GPLled, or uses an LGPLled library, right..?

It use LGPL license,  

That is unfortunately a problem for using the distribution.

AFAIK LGPL is compatible with BSD License. Or i'm wrong? 

 

Perhaps you can recreate your work with the bsd-licensed clone?

What is that clone? I didn't knew about it. 

 

And I think the complete forking of setup is a bit suboptimal (double updates). 

Yeah, i'm quite new to git repositories, and probably i didn't thinfs correctly. 

The actions should be shared where possible; or perhaps your code could be merged into setup itself, which then has 2 modes (is is callable from 2 names, etc.).

what do you mean with "the action should be shared"? what actions? 

I'm not sure that is possible to merge code into setup itself, i must check because in some part of code i had to replace the entire portion in order to make it dialog-friendly. I can check if it is possible. 

If you are willing to address these things

 Yeah no problem. 

I don't see why we couldn't adopt it.

Good

 

Thanks a lot for doing all that work, the video is a nice touch too.

Thanks :) 

Ivan

[Erik van der Kouwe]

Hi,

> > Fantastic job, very impressive.

+1

> > That is unfortunately a problem for using the distribution.
>
> AFAIK LGPL is compatible with BSD License. Or i'm wrong?

In a way you are right: using an LGPL'ed component does not require
you to make the code using is (L)GPL. However, the problem is of a
different nature. One of our 'selling points' is that we want to
provide a system that anyone can modify without being forced to open
source their contributions. If our base system contains an (L)GPL'ed
component, they cannot modify that part even if it doesn't affect the
other part's licensing.

> > Perhaps you can recreate your work with the bsd-licensed clone?
>
> What is that clone? I didn't knew about it.

If there is a BSD licensed one in the NetBSD source tree, that would
be the first candidate. Second choice would be FreeBSD if it has one.

Thanks for your hard work,
Erik

[Ivan Gualandri]

On 17 February 2012 10:27, Erik van der Kouwe <eri...@gmail.com> wrote:

Hi,

> > Fantastic job, very impressive.

+1

> > That is unfortunately a problem for using the distribution.
>
> AFAIK LGPL is compatible with BSD License. Or i'm wrong?

In a way you are right: using an LGPL'ed component does not require
you to make the code using is (L)GPL. However, the problem is of a
different nature. One of our 'selling points' is that we want to
provide a system that anyone can modify without being forced to open
source their contributions. If our base system contains an (L)GPL'ed
component, they cannot modify that part even if it doesn't affect the
other part's licensing.

I checked freebsd and netbsd installer, but they are not script based, they are c sources. 

Then probably they don't fit the actual setup script (nor gui/cli scripts). 

If we want to use one from a *bsd distro probably a complete rewrite of the installer must be considered. 

The netbsd and freebsd are completely different each other. So first of all it must be decided which should be used eventually. 

The freebsd installer has a better user interface.

I don't know if there is a BSD clone for dialog, if someone know something about it, please tell me :) 

Maybe could be a good idea, to implement the setup-gui command, but install the dialog package only if the user choose to use setup-gui command, and be warned that he is installing an LGPL component , and he had to accept to continue?

In that way the LGPL package is not needed to be installed, but it is installed on request. Btw i check how hard is to port one of the netbsd/freebsd installer to minix

And i'm not sure, but the installer add already a gpl'd package on it. The binutils package that AFAIK is a gpl-v2 package. Am i wrong? Maybe you found a BSD licensed alternative? I just checked on the netbsd repository and  it has the GPL'd version. If it is correct, do you think it could possible to add the dialog package, that has a less restrictive licens? 

> > Perhaps you can recreate your work with the bsd-licensed clone?
>
> What is that clone? I didn't knew about it.

If there is a BSD licensed one in the NetBSD source tree, that would
be the first candidate. Second choice would be FreeBSD if it has one.

 

As i said above it seems that they are c sources.  

Thanks for your hard work,
Erik

I only hope that a solution to the license issue could be found :)  

Bye,

Ivan

--
You received this message because you are subscribed to the Google Groups "minix3" group.

To post to this group, send email to min...@googlegroups.com.
To unsubscribe from this group, send email to minix3+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/minix3?hl=en.

[ben gras]

Yeah me too; the music really sold it too, or was i just imagining the music ;-)

[Antoine LECA]

Ivan Gualandri wrote:
> The binutils package that AFAIK is a gpl-v2 package. Am i wrong?

The one in current use (v2.17) is such. In the meantime both NetBSD and
DragonFly had switched to respectively v2.20 and v2.21, which are GPLv3.

> Maybe you found a BSD licensed alternative?

The closest such thing is elftoolchain, http://elftoolchain.sf.net or
http://sourceforge.net/apps/trac/elftoolchain/; while there are progress
done there, it is not completely ready, particularly on the linker tool.
A previous version of the underlying library has been ported to MINIX
(lib/libelf), but stays of very much low usage; work has been done
recently by the elftoolchain people to consider MINIX as a possible
target, but I do not know if it will be merged.

A missing component of elftoolchain are assemblers, but here we have the
yasm assembler http://yasm.tortall.net/, which combines the BSD license,
an up-to-date x86 assembler targeting ELF, and a "AT&T syntax" parser
including the numerous GNU assembler specifics which are now considered
"standard"! In fact, there is already even a working package for MINIX
of YASM v1.1. The only defect I found with yasm when used as compiler
back-end, is the high level of noise it produces because of the numerous
"uninitialized space declared" warnings...still a detail!

But I do not know if someone has been assigned to work on such a change.

Antoine

[Ivan Gualandri]

So what do you think about my proposals (read the quoted mails)? 

i try to sum up my consideations: 

1.  freebsd and netbsd installer, but they aren't script based, they are c sources. 

     Then probably they don't fit the actual setup script (nor gui/cli scripts) unless we  decide to move the installer from a script version to a c soruce (maybe trying to port the netbsd installer).

2. I  discovered that there is a freedialog library, that seems to be a BSD licensed dialog clone. But in freebsd that library was removed on 2010. I found a version of 2007, maybe we can try to port it and check if it fits for our purpose? The only problem is that this library seems no longer developed. But if it works maybe we can use it.  

3. Another solution could be to implement the setup-gui command, but install the dialog package only if the user choose to use that command, and be warned that he is installing an LGPL component , and he had to accept to continue?

4. Include direclty the lgpl package (but if my understanding are correct that should be avoided)

What do you think? 

@ben: no you aren't imagining the music. I added it with a very low volume. The music is from Baldur's gate video game. It is Candelkeep theme. 

Bye,

Ivan

[Ivan Gualandri]

Ok guys, 

i asked a list of questions (below) in order to decide how to proceed with the gui installer, but if i don't receive any answer i cannot take a decision, if i can proceed finding an alternative, or the solution in point 3 could be reasonable, or if i must drop the idea etc. 

Let me know what do you think and if possible help me to find a solution to the license issue. Otherwise i simply drop the idea .

Ivan

[ben gras]

My suggestion is to try to do your work using (a) freedialog and (b) without forking setup.

(a) is a license issue and (b) is a maintenance issue - it is unpleasant and dangerous to copy (and have to double-maintain) the setup logic.

Keeping setup script-based would be preferable.

Either merging your work with setup (i.e. both interaction modes are cleanly merged into setup) or factoring out the actions from the gui phases cleanly both seem OK to me.