On Sat, 21 Jun 2003 [email protected] wrote:
[...]
> > - Integration: (i) to make maximal use of existing FLOSS efforts;
>
> FLOSS ??
Free/Libre/Open Source Software :-) This term (or FOSS) is often used
in EU documents...
> > - "Free software"
> > - contractually agreed Free Software results: LGPL license for
> > libraries, GPL for applications, and relevant license for parts
> > that are done together with existing FLOSS projects.
>
> what happens to non-lib/non-app i.e. kernel-modules,code-generator
> output (GPL ?)
As I said: comply to the licenses of the relevant project. For the
kernel this would be GPL. But there would not be much kernel-related
work in this project :-)
[...]
> > - "Infrastructure"
> > - not applications in the first place, but everything needed to build
> > applications
>
> toolchains/Linux-control-distribution ?
What do you eman with this remark?
> > - pre-competitive: majority of industrial users can use it as a base
> > for their own products. Cf the status of the operating system and
> > the internet, but now targeted to control applications.
>
> don't get the second sentence ?
Ok, should be more verbose: I mean that at this moment, many
businesses consider the OS and the operating system as a commodity,
that is "just there" for everybody to use. In the area of control,
there is no such common commodity infrastructure yet.
[...]
> > - platform independence.
>
> for low end archs like SH4 I belive platform independance could be very hard
> to achive - platform independance easaly ends up requiring inacceptably strong
> platforms - I wonder if platform independance is such a key issue for some
> parts (i.e. kernel modules)
Keep in mind that this project is for the largest part _very_ far from
the hardware platform and the kernel. So, low end archs are not a
focus point.
[...]
> > - in practice: use the CORBA and Java approach, because these are
> > platform-independent. CORBA has an extra advantage, in that it is
> > also language independent, and much more independent from a single
> > vendor.
>
> I belive that corba/java will exclude a large number of industrial
> target platforms as it will be too heavy waighted...
Most industries I know that are active in the scope of the proposal
use Java or Corba or .NET...
[...]
> what I belive is missing, as in many projects, is a systematic path for
> technology transfere - what I mean is that such a complex conceptual
> approach would need to include something like tutorials/seminars or what
> ever technology migration path one preferes to get the entire framwork
> into industrial R&D .
I included this in the relevant section, in the form of about 3
workshops a year. But I have to flesh out that dissemination section
some more, of course :-)
[...]
> > Research aspects:
> > - discovery and description of relevant software patterns.
> > - high-quality implementation design, with an eye on: efficiency,
> > portability, application-independence, decoupling.
>
> decoupling what ?
Software components. Coupling is the largest source of
non-scalability, complexity, and non-distributability. (Coupling means
that one component's implementation makes use of knowledge about other
components' internals, in order to be "more efficient"...)
> > - definition of the API with which these modules interact.
>
> new API ? no attempt to use the interface capabilities that POSIX provides and
> integrate the interfaces via POSIX coplient API ? what would be the advantage
> of a new-home-brew API here - especially with respect to the anticipated
> integration of external software projects that might allready exist ....
We are _not at all_ talking about OS interfaces! But of interfaces of
the control infrastructure, which is quite far away from the OS :-)
POSIX is completely irrelevant in this scope.
[...]
> > WP6 Configuration and deployment tools
> > - support for the "control kernels".
> > - compatibility with relevant network and field bus standards.
> > - integration on new relevant hardware and operating systems (RTAI,
> > DSP, Ecos, Jaluna, TAO/ACE/CIAO, ...).
>
> If this should make it into industry easy then an integrated something like
> a distribution will be needed - just providing a kernel and compatibility with
> standards I don't think will do it.
Yes, but achieving this is left to cooperation with others.
Yet-another-distribution would not be a smart way to go, I guess.
Anyway, towards the end of the project, one of the "outsourced
subcontracts" could be in this area.
[...]
> with configurability and on-line adaptation/programing and distributed
> systems being on the agenda I'm supprised not to find security as a
> seperate KEY issue.
Good point! But there are much efforts in thsi direction going on
already, that allow security as "plug in" to a large extent. For
example, <http://shibboleth.internet2.edu/index.html>.
[...]
> > Consortium Agreement:
> > - simple "intellectual property" protection policy: every knowledge
> > + software contributed is available under the project free
> > software licenses, and possible patented technology can be used
> > unconditionally in the software.
>
> I'm interested in seeing what trees legal departments will start klimbing with
> statements like this ... will be interesting to see what such a license would
> realy look like - this sounds like a patent-prevention patent :)
Not much different from GPL version 3 I guess :-) And mind you, the
project is about the _infrastructure_ not about the _applications_
that people will want to run on top of it. The recent SCO story has
probably made lots of companies more aware that patents could stand in
between a good and free software infrastructure and using it...
Herman Bruyninckx
--
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.