← Back to team overview

c4c-dev team mailing list archive

Re: Large Binary Files

 

Hi All,

see comments below

On 05/18/2015 03:34 PM, Israel wrote:
> Hi again,
> zenity is a gtk application, and AFAIK there is no real Qt equivalent..
> but I have only used KDE a handful of times, and the same goes for LXQt.

Zenity is ok, but it's not as robust as say Whiptail and Dialog is
better (IMHO) than Whiptail, so I would vote for using Dialog.

Dialog and Whiptail do not require Gtk2/3, as they are ncurses based and
would working without a desktop installed at all.

> 
> So, if we want to make an installer we would need to do a few different
> things.

> a) make Qt and GTK installers
> b) use a different toolkit (I am very familiar with FLTK using c++)
> c) look into Qt dialog programs (do they exist, how good are they?)

I don't understand the need for an installer here? The installer would
be the shell script / package I would think.

> 
> A bash script is going to be the quickest and easiest way for me to
> sketch out a program we can test, and use.
> 
> @Greg do you know any programming languages?

I'm pretty much a bash / shell / core-utils / autotools person. I can
deal with Cmake and the like also.

A Bash / shell script seems the most sensible language for this. We
don't really need a full GUI of any sort I don't think.

> 
> I don't have much experience using curl/rsync so my vote is for zsync,
> as it is used for ISO downloads

Either one is fine, they both will do the job equally. Zsync if fine by me.

> 
> I think as a further precaution we need to look into some sort of
> passkey type thing for use with the binary files, in order to further
> protect things, or some other way of verifying that the zsynced files
> are going solely to a c4c machine (or someone installing c4c-music or
> whatever)

This will take some thought, as anything we do with a shell script could
no doubt be circumvented. In the end, all we are tying to do is present
a *reasonable level of protection* or at least a valid attempt at
adhering to the EULA.

> I don't have any real suggestions for this right now... but just the
> thought that we should do this

<snip>

best regards,

Greg


References