Final thoughts on the embedded Linux seminar
The embedded Linux seminar was held last week, and in general I feel that it went pretty well in line with my expectations. It’s been a long time since I held any real presentations, so the first two presentations in Gothenburg I was very much nervous and lost myself a few times along the line. The two presentations in Stockholm and Oslo went surprisingly well however, and I don’t think I made any huge errors from a pure presentation point of view.
Licensing
Now, that said, we did run into a few snags and after pondering what we can learn from the whole presentation/seminar — and there are a few points I’d like to raise both for the attendees and anyone else who might be interested. Being an “engineer”, I like to consider what went wrong, etc. Most points are of minor interest, but one of the absolute major points that we really didn’t get across properly, licensing issues with open source, or rather, licensing issues are manageable, however this was not the main area that we (or at least me) where there to talk about. Our main error was simply that we forgot communicating properly with each other, and correlate what we where saying. Also, this seminar wasn’t really about licensing issues, Nohau has an entire seminar/course on that topic alone, and you could easily fill out an entire university course on open source licensing.
The main point I tried to get across was that, yes, you need to be wary about licenses and you need to look at what is required of you, but that’s nothing different from any closed source licenses either, and you should be putting policies as well as processes in place to handle it, and push knowledge on how to handle licenses must be disseminated throughout the project.
So, to address some of the main licensing questions we received:
- No you will not have to give away your code if you link the code properly.
- You will have to set up proper procedures to handle any third party sources.
- You will have to create processes for everyone to follow to get any third party sources “accepted”.
- You will have to adhere to third party licenses, if you don’t, be prepared to be forced to and receive some bad publicity for it. (A lot of companies/people do get away with it, but is it worth risking it?)
Reliability
The second large question we got was, when would you use Linux, and when wouldn’t you use it, in a life or death situation? Simply put, I wouldn’t put it in a system where a person or persons would die if the process/hardware/appliance crashes, but that’s me. I would generally speaking make the life supporting/critical system run on a separate hardware, and then make all the critical stuff run in that context/hardware, and then a second piece which communicates with the critical hardware and do the higher end “stuff” that might be interesting (communicate to centrals, user interfaces, settings, etc). This way, the critical stuff can be kept simplistic and reliable (in my experience, reliability is a function of complexity, the more complex, the higher the failure rate).
In most projects, this has to be decided on a case by case basis, and due diligence must most of the time be taken with the laws and standards of each area. What is possible and advisable to do in house and home automation is not the same as in airplanes or medical systems for pretty obvious reasons.
Presentation depth/breadth/focus
Finally, a minor point, I got some criticism for being too shallow, not going enough in depth. Well, I could have stayed on discussing tool-chains and how to make one for hours, or I could have talked entirely about Linux internal boot order and why it works the way it does, but that wasn’t the goal of the entire seminar. That stuff could be studied to death, in the end your better off “getting” the top-down structure of an embedded Linux project and then just experiment on your own rather than get everything served in forum that can not make justice to everyones requirements. Next time however, I will try to maintain a deeper focus on a bit fewer topics, or get more time to speak in.
Anyways, I think it was fun and a huge experience. I hope most people visiting found the seminar interesting and had something out of it.
embedded Linux seminar 25-27/11 2009
On the 25-27 of november I will be on tour with nohau.se and hold a embedded linux seminar. The entrance is free, but requires a registration, see the embedded linux seminar webpage. according to the following schedule:
- Göteborg 25/11, em 13-16. Plats: Centralhuset Konferens, lokal Orientkusten
- Stockholm 26/11, em 13-16. Plats: Kista Konferens, lokal Alfa
- Oslo 27/11, fm 8-12. Plats: Thon Hotel Vika Atrium, Munkedamsveien 45, Oslo
I will specifically do the Development using Embedded Linux track, which will be 50 minutes long. The presentation is still fairly crude and rough around the edges, but some of the bulletpoints I’m going to talk about is:
- When to use Linux/ When NOT to use Linux
- Pitfalls of open source vs closed source and vice versa
- Hardware vs Development time cost decisions
- Choosing the right hardware
- Choosing the right software
- Security.
I hope to see some of you at the seminars!
Added papers section
The papers section has been added under the Documents section of the site. It currently is rather empty with only 2 semi-old papers added and two more coming within a few weeks. This is one of the reasons I actually switched over to wordpress as it enables much easier updates and additions of new material. The first paper out is about lessons learned from a embedded linux project with Freescale MCF5329 running uCLinux. The second paper is an old but cancelled IETF RFC draft I made almost 6 years ago to enable connection state transfers between multiple firewalls and/or routers for failover, high availability and load balancing reasons. This was put on ice for various reasons, but I thought it may have some value to anyone who would be interested in doing something alike. If there is any interest in carrying on the work, I’m open for questions and suggestions.