Re: Introduction
Urs Gleim
Hi, my name is Urs Gleim. I am with
Siemens Corporate Technology. I have a history in embedded
systems development with all the big proprietary embedded
operating systems out there. I worked in projects in the domains
automotive (mainly infotainment), industry automation, healthcare
and others. Today I am more in the managing role pushing the
shift to open source software and (embedded) Linux in particular
in the company (lessons learnt from the work with other OS's :-)
We run the internal "Corporate Competence Center Embedded Linux"
and support businesses units migrating to and maintaining Linux
for their products. The experiences of the last years showed that the way each and every company is building their own customized Linux versions, tool chains, and test infrastructure could be done much more efficiently and more sustainable. Even inside each company there are several solutions for different products. We have different product cycles and
requirements compared to consumer products, data centers, for
example. So what every company in the area of systems used in
rail, traffic control, healthcare, power generation/transmission,
etc. does is: i. adapting Linux for their needs (in terms of
build environment, test, features, ...), ii. maintaining these
solutions for years. Furthermore, having standard
configurations would lead to a common platform as a basis for
others building upon those platform (libraries, network
protocols, tools). At the end this is an ecosystem involving and
bringing together different communities/projects, suppliers, and
the companies creating products. In other domains there are
efforts going in the same direction (e.g., AGL, Genivi). So we
believe we can do much more by joining forces in the operating
system area and Linux will be established even more in the
industrial world. One of the strongest pain points today is the
effort we spend for (super) long-term maintenance, for each
product, in each company. So we start addressing this by
creating a harmonized build and test infrastructure and
agreeing on common super long-term maintained kernel versions
and patch cycles. I am looking forward working with you. Best regards,
On 16.09.2016 09:53, KOBAYASHI
Yoshitake wrote:
Hi all,
|
|
Re: Use cases behind CIP story
Urs Gleim
Hi,
On 16.09.2016 12:30, Agustin Benito Bethencourt wrote: let me try to sketch one example for typical rail automation products:It might be better to provide some typical development and maintenanceAgree. - development time of a new system: 3-5 years - customer specific adaptions: 2-4 years - initial safety certifications / authorization: 1 year - safety certifications / authorization for follow-up releases: 3-6 months (depending on amount of changes) - lifetime today typically 25 years, for some systems up to 50 years Especially the time (and money) required for the certification for new releases explains why in general there are no frequent updates. If new releases are necessary, e.g. because of security reasons the above mentioned efforts can be drastically reduced by only changing minor parts (efforts of course vary on type of system and safety level). Less changes mean less effort. Switching a kernel version is not considered to be a small change. That's why these products typically stick to a kernel version for long time which has been tested extensively in the system environment. We have similar situations in other domains. Healthcare, for example. The product lifetimes are shorter, typically 10-15 years. Still there are certifications (like FDA) which have to be done on system level which lead to the same problems. In addition to this there is a general trend that safety critical functions are more and more implemented in software. This means that the number of products having those certification need will further increase. I would also like to state one important point: the super-long-term maintenance is not a crazy idea by some industry people. It is done already. Only that it is done behind closed doors by privately maintained patch-sets. And this is what we would like to change. best regards, Urs
|
|
Re: cip-dev Digest, Vol 4, Issue 14: IRC not Practical
Don Brown <don.f.brown@...>
Hi Everyone, #Alternatives to a Mailing List Slack has been taking the business world by storm, however, The free version has some serious limitations on it. So I started looking for Slack alternatives and found the (4) alternatives listed below. For comparison, I captured the features and pricing (if any) In my research, I wanted to find solutions that were free and preferably Open Source Software. I wanted to make it easy to use, especially for anyone outside the group. I also wanted to find a solution that would allow sub-groups to be formed. Lastly, the ability to download the software and host the site myself would be a plus, but not a requirement. ##Google Groups ###Features - All of your discussions in one place - Express yourself with rich-text editing including images - People power discussions - Photos, nicknames, and automatic translations for the international community members - Speed matters - Keyboard shortcuts Mobile friendly - Access from anywhere using your mobile device. ###Pricing 100% Free ##Fleep ###Features - Unlimited message history - Unlimited number of conversations - Unlimited number of integrations - Share up to 5GB files per user - Native Mobile & Desktop apps for - Android - iOS - Windows - Mac - Teams - create and manage unlimited number of Fleep teams ###Pricing Free, but Limited to 5GB of file storage per use before having to upgrade to Premium - which has 50GB of storage per users ##Ryver ###Features: - Unlimited users - Unlimited guests - Unlimited teams - Unlimited chats - Unlimited posts - Unlimited search - Unlimited data - Native Mobile & Desktop apps for - iOS - Android - Mac Desktop - Windows Desktop ###Pricing 100% Free! ##Rocket.Chat ###Features: - Can be self-hosted - Video Conference - Helpdesk - File Sharing - Voice Messages - Link Preview - API for GitLab, JIRA, Confluence, etc... - Extendability Native Mobile apps for: - Android - iOS ###Pricing 100% Free! ##Summary Overall, my biggest concern was being able to extract all of the information in a group if it became necessary to move it to another platform, like if a company went out of business, changed their terms of service or they abandoned the application. Clearly, Google Groups provide the most stability in this regard. Additonally, it integrates to Google Hangouts where team members can video chat, share screens and collaborate on a whiteboard. As a side note, many comments included a reference to encrypted communications. In a corporation with trade secrets and development of patentable technology, I might agree. However, for an open source platform like CIP, I believe this is a "nice to have," and not a "need to have." ##References: Burger, R. (2016). The top 13 Slack alternatives [Blog entry]. Capterra. <http://blog.capterra.com/the-top-13-slack-alternatives/> --- Right before I posted this, I saw that a Google Group has already been created. I decided to post it anyway so the team members can see the alternative in case we ever need to move. Thank you Nori & Jeff for creating the Google Group! Don Brown. PMP don.f.brown@... Mobile: (317) 560-0513 Here's to Life, Linux and the Pursuit of Happiness
On Sat, Sep 24, 2016 at 8:00 AM, <cip-dev-request@... Send cip-dev mailing list submissions to
|
|
Re: New IRC channel for
#cip
Paul Sherwood
On 2016-09-24 12:52, Gleim, Urs wrote:
just a remark: we have some proxy restrictions in the company whichThis is a problem for many companies, actually, but I hope we can still encourage people to participate in IRC, mainly because there are so many established FOSS projects and contributors actively using IRC. It's old-school, but it has been working very well for several decades now. Using the newer services (Slack, Google Groups etc) may seem to achieve similar functionality but they don't achieve the same direct connection to other communities. Codethink's default recommendation to get IRC in the situation you have at Siemens would be to setup a web-based service. We've had success with Shout [1] and its fork The Lounge [2]. Basically these allow people to participate in IRC directly from a web-browser. Normally people run the server on a tiny/cheap cloud machine, eg AWS. Both relatively easy to setup, either by members directly, or maybe by Linux Foundation? Alternatively we'd be happy to create accounts on our existing Shout instance [3] if that's of interest. br Paul [1] https://github.com/erming/shout [2] https://thelounge.github.io [3] https://chat.codethink.co.uk
|
|
Re: Maintenance policies and early considerations IV
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
On 22/09/16 14:59, Agustin Benito Bethencourt wrote: Hi,Correction: Upstream fixes frequently change the kernel module API and/or ABI and backporting them in a way that is difficult and risky - CIP users set their own kernel configurations, so there will not be a single kernel ABI for IHVs to target anyway Best regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@...
|
|
Re: Maintenance policies and early considerations III
Daniel Sangorrin <daniel.sangorrin@...>
Hi Agustin,
Sorry for the late reply. +++ Request to members from maintainerI think that one possible guideline for backporting security patches to the CIP kernel is to look at kernel CVEs [1]. A table (probably only accessible by members) indicating whether a CIP kernel is vulnerable or not to a CVE would be of great help. Another source of bug/security fixes will be the PREEMPT RT patch. We will probably need to check whether bugs found in new versions are properly backported to our CIP kernels. # I see that Ben is already doing this! [2] Finally, we may need to decide how to disclosure bugs that we may find ourselves while testing the CIP kernels. I guess we will need to make sure that all members are ready for the disclosure. Best regards Daniel [1] http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 [2] https://lkml.org/lkml/2016/9/29/473
|
|
Public wiki
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
CIP ha set up a public wiki. It has very little content at this point and there is no policy yet to add editors. We are sorting things out. https://wiki.linuxfoundation.org/civilinfrastructureplatform/start Please take a look and let me know what can we do to improve it. we will include the link in tomorrow's presentation at LinuxCon EU. Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@...
|
|
Re: Public wiki
Urs Gleim
Just a remark, the presentation is tomorrow, 10/6
toggle quoted messageShow quoted text
-- Urs Gleim | Siemens AG | Corporate Technology
Am 04.10.2016 um 19:50 schrieb Agustin Benito Bethencourt <agustin.benito@...>:
|
|
Re: Public wiki
Yoshitake Kobayashi
Hi Agustin,
toggle quoted messageShow quoted text
Here are some links for CIP presentations. Probably the following information is also a candidate contents for CIP wiki. * Towards Sustainable Systems with the Civil Infrastructure Platform (LinuxCon NA 2016, August 2016) URL: http://events.linuxfoundation.org/sites/events/files/slides/CIP-LinuxConNA.pdf * Introducing the Civil Infrastructure Platform Project (LinuxCon Japan, July 2016) URL: http://events.linuxfoundation.jp/sites/events/files/slides/Intriducing_the_CIP-LCJ2016.pdf * Introducing the Civil Infrastructure Platform Project (ELC 2016, April 2016) Note: This is the first official presentation by the CIP URL: http://events.linuxfoundation.org/sites/events/files/slides/Introducing%20the%20Civil%20Infrastructure%20Platform.pdf ----------------- The following presentation was made before the CIP launch, but it might be a good reference to know how and why we start the CIP. * Applying the Linux to the Civil Infrastrucure (LinuxCon Japan 2015, June 2015) URL: http://elinux.org/images/7/74/Applying_Linux_to_the_Civil_Infrastructure-LinuxCon_Japan_2015.pdf * Applying Linux to the Social Infrastructure BoF (ELC 2015, Apr 2015) URL: http://events.linuxfoundation.org/sites/events/files/slides/ELC_2015_SIP.pdf * Using Embedded Linux for Infrastructure Systems (ELC Europe, October 2014) URL: http://events.linuxfoundation.jp/sites/events/files/slides/ELCE2014-Using%20Embedded%20Linux%20for%20Infrastructure%20Systems.pdf ----------------- Best regards, Yoshi
On 2016/10/05 2:50, Agustin Benito Bethencourt wrote:
Hi,
|
|
Re: Public wiki
Agustín Benito Bethencourt <agustin.benito@...>
Hi,
I think it is already there. On 5 October 2016 20:58:09 CEST, KOBAYASHI Yoshitake <yoshitake.kobayashi@...> wrote: Hi Agustin, Sent from mobile. Please excuse my brevity. -- Agustín Benito Bethencourt @toscalix
|
|
Re: Maintenance policies and early considerations IV
Takuo Koguchi
Hi Agustin,
Let me understand what you wrote. Is the correction correct?CIP should avoid making any such promise because:Correction: I thought you wrote; * Upstream fixes frequently change the kernel module API and/or ABI and backporting them in a way that does not (change the kernel module API and/or ABI )is difficult and risky - CIP Am I wrong? Takuo Koguchi
|
|
Re: Maintenance policies and early considerations IV
Daniel Sangorrin <daniel.sangorrin@...>
Hi Koguchi-san,
toggle quoted messageShow quoted text
I think you are right. It's my fault, sorry. Daniel
-----Original Message-----
|
|
Re: Maintenance policies and early considerations IV
Ben Hutchings <ben.hutchings@...>
On Fri, 2016-10-07 at 07:34 +0000, 小口琢夫 / KOGUCHI,TAKUO wrote:
Hi Agustin,The first version is what I wrote, and the correction says something I did not mean to say. I thought you wrote;No, you understand me rightly. Ben. -- Ben Hutchings Software Developer, Codethink Ltd.
|
|
ELCE talk about embedded systems long term maintenance
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
the slides[1] from the talk "Long-Term Maintenance, or how to (mis-)manage embedded systems for 10+ years" by Jan Luebbe are available. I assume by next week we will have the video. [1] http://events.linuxfoundation.org/sites/events/files/slides/PRE-trunk-ELCE-LongTermMaintenance.pdf -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@...
|
|
First CIP kernel will be 4.4
Agustin Benito Bethencourt <agustin.benito@...>
Hi,
At LinuxCon EU, during the CIP talk it was announced that the first CIP kernel will be 4.4 Please find the slides of all the 2016 talks about CIP in our wiki[1]. [1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito@...
|
|
Re: Maintenance policies and early considerations II
Jan Kiszka
On 2016-09-22 11:42, Agustin Benito Bethencourt wrote:
Hi,Ack. Not sure how to read these threads as I didn't manage to follow their evolution: This aspect of support constraints is still in scope? I think it will be important in order to keep backporting and testing efforts realistic. The enterprise distros are doing the same. Regards, Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
|
|
Re: Maintenance policies and early considerations IV
Jan Kiszka
On 2016-09-22 14:59, Agustin Benito Bethencourt wrote:
Hi,Nit: it's stable_kernel_rules.txt. We should start this way and augment/adjust rules after discussions as we find potential conflicts. Sounds reasonable to me in general. Jan -- Siemens AG Corporate Technology Research & Technology Center CT RDA ITP SES-DE Corporate Competence Center Embedded Linux Otto-Hahn-Ring 6 81739 Muenchen Tel.: +49 89 636-634006 Fax: +49 89 636-33045 mailto:jan.kiszka@... Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
|
|
Re: Maintenance policies and early considerations I
Hidehiro Kawai
Hi,
I'm sorry for the late response. (2016/09/22 18:31), Agustin Benito Bethencourt wrote: Hi,Assuming we release new products in every 2 years, 2-3-year release cycle would be feasible. Maintaining multiple branches is hard work, but its effort would be decreased after 5 years from the release. Best regards, Hidehiro Kawai Hitachi, Ltd. Research & Development Group +++ Backport effort
|
|
Re: Maintenance policies and early considerations II
Hidehiro Kawai
Hi,
(2016/09/22 18:42), Agustin Benito Bethencourt wrote: Hi,Basically, releasing the kernel as source is sufficient. But if we release it as binary only for the specific reference board, users may be happy. +++ Kernel featuresTo reduce the maintenance effort, we should limit drivers and features to be supported (`support' in this context means tracking security/critical bug fixes, backporting requested patches, and so on). One idea is to express the supported features in the form of kernel config. It is machine-readable, and it's not so difficult to covert it to human-readable. But I'm not sure if it actually work well because there are non-configurable features. Best regards, Hidehiro Kawai Hitachi, Ltd. Research & Development Group
|
|
Re: Maintenance policies and early considerations III
Hidehiro Kawai
Hi,
(2016/09/22 21:56), Agustin Benito Bethencourt wrote: Hi,I agree on that. CIP don't need to care about out-of-tree drivers. +++ Security updatesI think it is important to prepare for zero-day attacks, and the Kernel Self-Protection Project would help it. If it could be backported, doing it is preferred. But does it make the long-term maintenance difficult? +++ Request to members from maintainerBasically, I expect CIP supports all CVEs which are related to supported features by CIP. But human resources are limited, so CIP members might need to prioritize them depending on their impact. Best regards, Hidehiro Kawai Hitachi, Ltd. Research & Development Group
|
|