<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [Live-demo] Rethinking osgeo-live</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>hello,<BR>
we are working to complete the requirements for 'i3geo' can be included<BR>
regards,<BR>
<BR>
Valenty<BR>
Asociacion gvSIG<BR>
<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: live-demo-bounces@lists.osgeo.org on behalf of Cameron Shorter<BR>
Sent: Thu 10/25/2012 11:07 PM<BR>
To: Barry Rowlingson<BR>
Cc: Jody Garnett; live-demo@lists.osgeo.org<BR>
Subject: Re: [Live-demo] Rethinking osgeo-live<BR>
<BR>
Barry,<BR>
An interesting idea you have brought up.<BR>
Here are some thoughts that Jody Garnett mentioned in IRC today...<BR>
<BR>
<jgarnett> there is a slightly different approach to consider<BR>
<jgarnett> if you look at things like "home brew"<BR>
<kalxas> but I don't believe it fits the way GNU/Linux works<BR>
<jgarnett> they are very similar to what osgeo live does<BR>
<jgarnett> osgeo live has a bunch of tested install scripts<BR>
<jgarnett> that "grab what is needed"<BR>
<jgarnett> we have caught developers just running the scripts on their<BR>
linux machine<BR>
<jgarnett> (and indeed they sometimes work for mac as well)<BR>
<jgarnett> home brew, and its ports to linux, are similar<BR>
<jgarnett> would turn the project into a set of install scripts<BR>
<CameronShorter> jgarnett, got a url for home brew?<BR>
<jgarnett> the "live demo" would be a downstream project; where the<BR>
install scripts have been applied to a ISO<BR>
<jgarnett> or to a VM<BR>
<jgarnett> <A HREF="http://mxcl.github.com/homebrew/">http://mxcl.github.com/homebrew/</A><BR>
<sigabrt> Title: Homebrew - MacPorts driving you to drink? Try Homebrew!<BR>
(at mxcl.github.com)<BR>
<jgarnett> (it is not so much this specific "home-brew" project - it is<BR>
the approach that is similar to the core of osgeo live)<BR>
<jgarnett> (i.e. the part we ask projects to maintain)<BR>
<jgarnett> but yeah - was not going to wade into that email debate<BR>
<jgarnett> (here is a port of homebrew to linux<BR>
<A HREF="http://blog.frameos.org/2010/11/10/mac-homebrew-ported-to-linux/">http://blog.frameos.org/2010/11/10/mac-homebrew-ported-to-linux/</A> )<BR>
<sigabrt> Title: Mac Homebrew ported to Linux - Automation Inc. (at<BR>
blog.frameos.org)<BR>
<kalxas> "Caveats * The port is still a work in progress * Most of the<BR>
existing haven't been tested. * Port has been tested only in Ubuntu and<BR>
RHEL"<BR>
<BR>
On 25/10/2012 7:26 PM, Angelos Tzotsos wrote:<BR>
> And something I forgot to write down:<BR>
><BR>
> What about security updates? We would need to maintain libraries like<BR>
> Qt, while this is done upstream right now.<BR>
><BR>
> Best,<BR>
> Angelos<BR>
><BR>
> On 10/25/2012 11:16 AM, Angelos Tzotsos wrote:<BR>
>> Hi Barry,<BR>
>><BR>
>> On 10/25/2012 10:29 AM, Barry Rowlingson wrote:<BR>
>>> On 25 October 2012 03:33, Brian Hamlin <maplabs@light42.com> wrote:<BR>
>>>> this is breathtakingly unrealistic :-)<BR>
>>> Thanks! :)<BR>
>>><BR>
>>> I'll approach some of the criticisms...<BR>
>>><BR>
>>> * Alex, yes, correctly compiling Windows things is hard. But someone<BR>
>>> has done it for OSGeo4W, Jo has done it for Portable GIS. That<BR>
>>> expertise exists.<BR>
>>><BR>
>>> * Alex, Angelos: this wouldn't be statically linked binaries<BR>
>>> (HUUUUGE!) but more like a python virtual env. There would be some<BR>
>>> wrapper to make sure qgis always links with /osgeo/lib/libqt4.so, and<BR>
>>> never with /usr/lib/libqt4.so. Essentially it would be everything that<BR>
>>> is currently on the live disc (except the kernel and user tools), with<BR>
>>> the applications configured to get their dependencies from the right<BR>
>>> place.<BR>
>> I see what you mean, I am not sure it is wise to bypass<BR>
>> distributions. How many software providers do this today?<BR>
>> Even Google with all those resources available has not been able to<BR>
>> provide one binary for all Linux machines...<BR>
>><BR>
>> We would need to re-invent the wheel in some cases to do this.<BR>
>> But this does not mean I don't like the way you are thinking.<BR>
>>><BR>
>>> * Angelos: I demand (and get) freedom for my desktop, at the cost of<BR>
>>> not having central IT back my machine up. However, if I take a live<BR>
>>> DVD to a Windows-using, central-IT supported colleagues desk and go<BR>
>>> 'hey, look at this', all I get is frustration and eventually a BIOS<BR>
>>> password prompt. So I then have to go back with OSGeo4W.<BR>
>> Unfortunately freedom is still an every-day battle.<BR>
>> At least we are winning on the server side.<BR>
>>><BR>
>>> * Angelos: running in your favourite OS should be as simple as<BR>
>>> copying the things you want to run to your currently existing and<BR>
>>> configured-exactly-how-you-like-it OS.<BR>
>> I know packaging is not perfect today, but is much better than it<BR>
>> used to be 5 or 10 years back.<BR>
>>> I don't see the point in making<BR>
>>> an openSUSE version - we're trying to promote OSGeo s/w here, not<BR>
>>> GNU/Linux distributions.<BR>
>> This is exactly why this version is not available...<BR>
>>><BR>
>>> I'm just thinking that there's more worth in concentrating efforts in<BR>
>>> getting OSGeo applications out there rather than spinning up new<BR>
>>> Ubuntu distributions every six months. To that end, a simple,<BR>
>>> user-driven binary installation process would seem to be optimal. We<BR>
>>> have OSGeo4W, why not OSGeo4L and OSGeo4M?<BR>
>> Because GNU/Linux is all about freedom of choice. No matter how we<BR>
>> decide to create packages, people will want native packages for their<BR>
>> distribution through UbuntuGIS, DebianGIS, EL, OBS, AUR etc.<BR>
>><BR>
>> I agree that OSGeo4W is a huge project that fits exactly the needs of<BR>
>> Windows users. I am sure a OSGeo4Mac would also be very successive.<BR>
>>><BR>
>>> I don't see a technical barrier to this, so it's just limited by<BR>
>>> resources (our time!). Anyone got a spare 20 years?<BR>
>> If we had the spare time and I was to make this decision, I would<BR>
>> prefer offering deb and rpm files for all OSGeo related projects and<BR>
>> I would be left with 10 years for vacations :)<BR>
>>><BR>
>>> Barry<BR>
>>> _______________________________________________<BR>
>>> Live-demo mailing list<BR>
>>> Live-demo@lists.osgeo.org<BR>
>>> <A HREF="http://lists.osgeo.org/mailman/listinfo/live-demo">http://lists.osgeo.org/mailman/listinfo/live-demo</A><BR>
>>> <A HREF="http://live.osgeo.org">http://live.osgeo.org</A><BR>
>>> <A HREF="http://wiki.osgeo.org/wiki/Live_GIS_Disc">http://wiki.osgeo.org/wiki/Live_GIS_Disc</A><BR>
>>><BR>
>> Cheers,<BR>
>> Angelos<BR>
>><BR>
><BR>
><BR>
<BR>
<BR>
--<BR>
Cameron Shorter<BR>
Geospatial Solutions Manager<BR>
Tel: +61 (0)2 8570 5050<BR>
Mob: +61 (0)419 142 254<BR>
<BR>
Think Globally, Fix Locally<BR>
Geospatial Solutions enhanced with Open Standards and Open Source<BR>
<A HREF="http://www.lisasoft.com">http://www.lisasoft.com</A><BR>
<BR>
_______________________________________________<BR>
Live-demo mailing list<BR>
Live-demo@lists.osgeo.org<BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/live-demo">http://lists.osgeo.org/mailman/listinfo/live-demo</A><BR>
<A HREF="http://live.osgeo.org">http://live.osgeo.org</A><BR>
<A HREF="http://wiki.osgeo.org/wiki/Live_GIS_Disc">http://wiki.osgeo.org/wiki/Live_GIS_Disc</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>