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
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. Glenn -- sks-keyservers.net 0x6d656d65
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).
participants (3)
-
Glenn McIntosh -
Russell Shaw -
Sven＠GMX