[free-software-melb] CuBox

2013-06-28 Thread Sven@GMX
http://solid-run.com/ claims to be an Open Source development platform.
So we can assume all hardware is Open Source as well, isn't it?

I recently came across Embedded Pi, an interfacing board to use Arduino
shields on the Raspberry Pi, which is one of the use cases.
But in order to programm the Embedded Pi you need to install CoocoxIDE,
which is free to use but neither Open Source nor does it run on an Open
Source system such as Linux. No, you need to have the proprietary OS MS
Windows installed/ W.I.N.E. (seems to work here) in order to run that
IDE and develop/ write code for an Open Source platform/ Arduino shield.

What are your thoughts?

-- 
Sven (Andriske)/ VK3SIX, DJ5AND



smime.p7s
Description: S/MIME Cryptographic Signature
___
Free-software-melb mailing list
Free-software-melb@lists.softwarefreedom.com.au
http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb


Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/

Re: [free-software-melb] CuBox

2013-06-28 Thread Russell Shaw

On 28/06/13 18:27, Glenn McIntosh wrote:

On 28/06/13 16:59, Sven@GMX wrote:

But in order to programm the Embedded Pi you need to install CoocoxIDE,
which is free to use but neither Open Source nor does it run on an Open
Source system such as Linux.


Unfortunately this creeping lock-in is all too common in the firmware
world. Often it is a 'not invented here' corporate dysfunction at play.

Many of these IDEs are really only a GUI shell to run openly licenced
tools such as gcc (CoocoxIDE is just one of many such IDEs), and don't
add anything that couldn't be done in any decent IDE. The hardware
specific parts are typically just a few scripts that specify compilation
options and uploading/debugging connnections, and perhaps a device
specific library. Apart from the lack of openness, I find it a major
annoyance when working on multiple firmware platforms, all with
inconsistent IDEs and libraries.

I think we have to resist such lock-in. For projects where we have
control, this may involve separating out the proprietary tools and
discarding them (eg, setting up our own scripts for the hardware that
can work with a non-proprietary IDE, and making them available to
others). If this is not practical, I think it is quite rational to
boycott such hardware. There are good business reasons for avoiding
vendor lock-in, not to mention the fact that it is your own freedom as a
developer that is being restricted here.


I never bothered with the Pi because the most important and interesting part 
(the graphics drivers and graphics register details) is closed. Defeats the 
point of the whole thing. I wouldn't use a Pi if they were free (as in beer).


___
Free-software-melb mailing list
Free-software-melb@lists.softwarefreedom.com.au
http://lists.softwarefreedom.com.au/cgi-bin/mailman/listinfo/free-software-melb


Free Software Melbourne home page: http://www.freesoftware.asn.au/melb/