The rise in cyberattacks and software’s critical role in our lives has brought to light the need for increased transparency and accountability in the software supply chain. Software distributors can achieve this by providing software bills of materials (SBOMs), which provide a comprehensive list of all the components used in a software product, including open source and proprietary code, libraries, and dependencies.

In May 2021, United States Executive Order 14028 on improving the nation’s cybersecurity emphasized the importance of SBOMs in protecting the software supply chain. After comprehensive proof of concepts using the Software Package Data Exchange format (SPDX), the National Telecommunications and Information Administration (NTIA) released the “minimum elements” for an SBOM. The minimum elements require data fields that enable basic use cases:

• Supplier Name
• Component Name
• Version of the Component
• Other Unique Identifiers
• Dependency Relationship
• Author of SBOM Data
• Timestamp

The NTIA recommends that the data contained in these fields should be expressed in predictable implementations and data formats to enable automation support. One of the preferred formats for expressing this data is SPDX. While version 2.3 of the SPDX specification, released in November 2022, was the first version to explicitly describe how to express the NTIA minimum elements in an SPDX document, SPDX has supported these elements since its version 2.0 release in 2015.

Read more about how to create an SPDX SBOM document that complies with the NTIA “minimum elements” at The New Stack.

The post Creating a ‘Minimum Elements’ SPDX SBOM Document in 5 Minutes appeared first on Linux.com.

SAN FRANCISCO, February 23, 2023 – Today, the Zephyr® Project announced that Blues Wireless, IRNAS, and Sternum have joined as Silver members just as the real-time operating system (RTOS) has hit widespread adoption in products. Members such as Google, Meta, Oticon and T-Mobile have products powered by Zephyr RTOS. 

“Adoption of Zephyr has increased dramatically in the last few years,” said Kate Stewart, Vice President of Dependable Embedded Systems. “In addition to Zephyr being used in a variety of industrial applications, we’re finding it in all sorts of emerging markets like wearables, trackers, intelligent IoT devices, animal monitoring systems, and more. We hope being product ready will help these new members and the community with development, delivery, and maintenance across a wide variety of additional devices and solutions.”

Products that are powered by Zephyr include: 

• Google Chromebooks: The embedded controller is an ultra-low-power microcontroller that is always on. It is critical to the all-day battery life as it handles all the things a Chromebook has to do when the application processor is off or sleeping. Google recently decided to move the EC application to Zephyr so that  vendors can write their drivers once and capture design wins in product areas beyond Chromebooks. Zephyr’s device model is based on the industry standards of devicetree⁠ and Kconfig⁠. These technologies simplify the customization steps needed for each Chromebook model, lessening the engineering effort for Chromebook manufacturers. Learn more here.

• Oticon More^TM Hearing Aids: The revolutionary Oticon More is the world’s first hearing aid that allows users to hear all relevant sounds thanks to an on-board Deep Neural Network. It is powered by the Polaris chipset, integrating Zephyr RTOS for Bluetooth LE connectivity. This novel hearing instrument is an advanced medical product that will help millions of hearing-impaired people to a better quality of life. Learn more here.

• T-Mobile’s DevEdge: The DevEdge is a self-serve developer platform that offers access to the T-Mobile network to create connected wireless solutions. The IoT Developer Kit, which runs on Zephyr RTOS, gives developers immediate access to T-Mobile’s network – no testing hardware, no lengthy build time required. Learn more here. 

Even as a new member, IRNAS has been using Zephyr RTOS for the last 4 years as part of their strategy to work with the best technologies to build industrial solutions for global clients, particularly focusing on Zephyr RTOS running on Nordic Semiconductor’s nRF52 and nRF91 series products. Advanced applied solutions range from critical infrastructure monitoring devices such as RAM-1 developed for Izoelektro all the way to livestock management and tracking products engineered for Telespor. As part of the IRNAS responsible environmental strategy, they also formed a partnership with Smart Parks to design Open Collar animal trackers for nature conservation. These are mounted on wildlife animal collars for monitoring and their safety.

“Zephyr has been at our core for a number of years, and now we are happy to take the next step and support the project that enabled us to build better connected products and be part of the Zephyr community,” said Luka Mustafa, CEO and Founder of IRNAS. “Zephyr RTOS has already achieved significant adoption in industry, enabling us to design applications and value add logic to products running on multiple architectures, designing products that can continue evolving over the decades to come without massive rewrites in the process.”

Blues Wireless and Sternum also joined the project as Silver members. 

“At Blues, we are proud to support the Zephyr Project and officially join the community,” said Brandon Satrom, Vice President of Developer Experience & Engineering at Blues. “Zephyr’s open source, multi-architecture approach is perfect for our customers as they scale, and are looking for a robust RTOS to pair with the device agnostic, secure, and simple cellular connectivity that Blues provides. We look forward to introducing more of our customers to Zephyr, and leveraging our expertise to help Zephyr developers add low-power cellular to their tool belt.”

“Zephyr is already the platform of choice for some of our largest customers, allowing us a clear view of how it’s being used to power medical devices, payment devices, gateways, and industrial infrastructure,” says Natali Tshuva, CEO and Co-Founder of Sternum. “We see growing demand from device manufacturers for advanced security controls, post-market surveillance capabilities, and threat mitigation that go beyond perpetual security patching. Our built-in support for Zephyr RTOS and toolchains allows us to address these needs and offer an easy way to bring our patented technology to all Zephyr-based devices.”

Zephyr, an open source project at the Linux Foundation that builds a safe, secure, and flexible RTOS for resource-constrained devices, is easy to deploy, connect and manage. It supports more than 450 boards running embedded microcontrollers from Arm and RISC-V to Tensilica, NIOS, ARC and x86 as single and multicore systems. It has a growing set of software libraries that can be used across various applications and industry sectors such as Industrial IoT, wearables, machine learning, and more. Zephyr is built with an emphasis on broad chipset support, security, dependability, longterm support releases, and a growing open source ecosystem. 

Zephyr Project Platinum members include Antmicro, Baumer, Google, Intel, Meta, Nordic Semiconductor, NXP, Oticon, Qualcomm Innovation Center, and T-Mobile. Silver members include AVSystem, BayLibre, Golioth, Infineon, Laird Connectivity, Linaro, Memfault, Parasoft, Percepio, SiFive, Silicon Labs, Synopsys, Texas Instruments, and Wind River. 

Where to see Zephyr 

Zephyr will be on-site at Embedded World on March 14-16 in Nuremberg, Germany. The booth, located in Hall 4 – Stand 170,  will host live demonstrations from members such as Antmicro,  AVSystem, Blues Wireless, Golioth, IRNAS, Memfault, Nordic Semiconductor, NXP, Parasoft and Sternum. Stop by to talk to project members and ambassadors about these demos and check out products running on Zephyr. Click here for a total list of demos and products featured at Embedded World. 

Additionally, the Zephyr community will be at the Zephyr Developer Summit, which takes place on June 27-30 in Prague, Czech Republic, and virtually as part of the first-ever Embedded Open Source Summit (EOSS). The annual Zephyr Developer Summit, which launched in 2021, is for developers using or considering Zephyr RTOS in embedded products. This year will focus on topics of interest to users, developers contributing upstreams and maintainers who want to learn more about technical details, products that leverage the RTOS and the ecosystem.

To submit a speaking proposal, click here by February 27. Learn more about sponsoring the event here or register to attend the event here.  

About the Zephyr Project

The Zephyr® Project is an open source, scalable real-time operating system (RTOS) supporting multiple hardware architectures. To learn more, please visit www.zephyrproject.org.

About the Linux Foundation

Founded in 2000, the Linux Foundation and its projects are supported by more than 2,950 members. The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, Hyperledger, RISC-V, and more. The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

###

Media Contact:

Maemalynn Meanor

Director of Public Relations & Communications

maemalynn@linuxfoundation.org

The post Blues Wireless, IRNAS, and Sternum join the Zephyr Project as Widespread Industry Adoption of the Open Source RTOS Accelerates appeared first on Linux.com.

Authors: Michael Gielda, Kate Stewart

A Software Bill of Materials (or SBOM) makes the information about the software components running on a system available. Transparency and summarization are needed in embedded systems with resource constraints and where updates may have significant deployment or recall costs.    

In 2021, we saw significant indicators that having an SBOM is going to become a regulatory requirement in some embedded market segments (medical, energy, etc.) and the US Government came out with an executive order in May 2021 that has a timeline with expectations that the industry would be ready for generating SBOMs in 2022.   

Software Package Data eXchange® (SPDX®) is an international standard (ISO/IEC 5962:2021), able to express SBOM information, as well as other facts about software packages, files, and snippets.   It is uniquely able to specify the fidelity of information required for embedded software, and partition the information logically to express system level information.

The Zephyr Project incorporated the ability to generate SBOMs automatically during builds in 2021. This is done when building Zephyr executables using the ‘west spdx’ command. West is Zephyr’s meta-tool that supports the build infrastructure. There are multiple SBOMs created (one for the Zephyr sources,  one for the application sources, and one for the built image) that will link back to all the dependencies in the source files.

Antmicro’s Renode Zephyr Dashboard now includes SBOMs

A Platinum member of Zephyr Project, Antmicro, among other contributions (including maintaining Zephyr support for RISC-V and work around supporting Zephyr on FPGA platforms), has been ensuring Zephyr developers can access powerful simulation, testing, and debug capabilities of their open source simulation framework, Renode. 

Renode shares the vendor-neutral and user-centric approach of Zephyr, focusing on the security and developer productivity of the RTOS.

The two open source projects have been collaborating for many years now, but recently a great showcase of where Zephyr and Renode complement each other is demonstrated by the Renode Zephyr dashboard. 

The Renode tool visualizes the results of a continuous integration (CI) system running real Zephyr binaries on multiple architectures, boards and SoCs from a variety of vendors, incorporating the advantages of portable examples and the structured platform data provided by Zephyr. 

Renode’s flexibility and reconfigurability produces a concise dashboard displaying Zephyr-compatible boards currently supported in Antmicro’s open simulation framework.

This dashboard project utilizes the systemized information from Zephyr – which uses device trees to describe the platform data needed to pick and configure specific drivers and subsystems, which can then be mapped onto the plug and play, building blocks oriented nature of Renode.

Renode Dashboard Includes SBOMs in Standard Builds

As a member of the Zephyr’s Technical Steering Committee, Antmicro collaborates with other Zephyr members (which include many of Antmicro’s customers such as Google, Intel, or NXP) to ensure the use of a standardized and unified approach to implementing new ports. This concept of defining commonalities in platforms is an important step toward improving and generalizing support for silicon in embedded systems tooling.

Currently at 129 passing boards and spanning four different demos, including MicroPython and TensorFlow Lite Micro, the most recent version of the Zephyr Dashboard is enhanced with the ability to generate SBOM artifacts for all of its samples automatically.

This showcases how simple Zephyr makes it to generate reliable and accountable software and have accompanying SBOMs. The dashboard shows a breadth of platforms supported by both Zephyr and Renode, all of which have SBOMs. 

Using Renode helps you track various metrics (performance, coverage, memory use etc.) related to your software across time. The software BOM generation capability complements this picture, providing the traceability and security needed to build real-life commercial products.

About the Authors: 

Michael Gielda is VP Business Development at Antmicro, Chair of Outreach for CHIPS Alliance, and a member of the Marketing Committees in RISC-V International and The Zephyr Project.  Contact: mgielda@antmicro.com

Kate Stewart is VP Dependable Embedded Systems at The Linux Foundation, a technical co-lead in the SPDX project, and a governing board member for the CHAOSS project.    Contact: kstewart@linuxfoundation.org

The post Enhancing Supply Chain Security for Embedded Systems: Renode Dashboard for Zephyr RTOS Adds New Software Bill of Materials (SBOM) Capabilities by Default appeared first on Linux.com.

Linux has been around in various forms for about 30 years, and the kernel is the basis of other operating systems such as Android and Chrome OS. Supercomputers use it at one end of the computing spectrum and in embedded devices at the other. Linux is used on laptops, desktop computers, and servers in between these extremes.

And it’s also used in single-board computers — this category includes popular devices like the Raspberry Pi.

Therefore it’s fair to say that Linux has been widely adopted.

While microcontrollers and lean, mean software frameworks necessarily dominate small electronic products that are generally single-purpose devices and have modest processing requirements, Linux meets the needs of another important subset. Some products have multiple features that need to be available concurrently. Some cases may require significant processor power and need RAM measured in gigabytes rather than the kilobytes of RAM more typically found in microcontrollers. IP security cameras are based on Linux. They can stream live video, respond to motion detection events, identify human faces in video streams in real-time, record video to an SD card, transfer files over FTP, and host a web server for management and configuration purposes. That mix of concurrently available functionality requires both sufficiently powerful hardware and an operating system that supports multiple processes and threads, provides a capable file system, and has a wide selection of applications readily available for it. Linux is a perfect fit. And it’s open source and free.

Bluetooth Technology and Linux

Bluetooth^® technology can be used on Linux. The controller part of the Bluetooth stack is typically a system on a chip that is either an integral part of the mainboard or implemented in a peripheral like a USB dongle. The host part of the Bluetooth stack runs as a system service, and the standard Linux Bluetooth host implementation is called BlueZ.

BlueZ supports both the Bluetooth LE Peripheral and Central roles using GAP and GATT and Bluetooth mesh, provided the underlying controller supports dependent Bluetooth features. And its multi-process architecture means that multiple Bluetooth applications can be running simultaneously on a single device, which offers some exciting possibilities.

But for a developer, working with Bluetooth technology on Linux for the first time can be challenging. BlueZ defines a straightforward, logical API, but the way a developer must use it in applications is dissimilar to how a developer works with Bluetooth APIs on most other platforms. This is a consequence of the system’s architecture, which, whilst not unique, is typically very visible to the developer and usually needs to be well understood so that those logical BlueZ APIs can be used.

The post Understanding Bluetooth Technology for Linux appeared first on Linux.com.

In 2021, The Linux Foundation continued to see organizations embrace open collaboration and open source principles, accelerating new innovations, approaches, and best practices. As a community, we made significant progress in the areas of cloud-native computing, 5G networking, software supply chain security, 3D gaming, and a host of new industry and social initiatives.

Download and read the report today.

The post Download the 2021 Linux Foundation Annual Report appeared first on Linux.com.

Jason Perlow, Editorial Director at the Linux Foundation interviews Thomas Gleixner, Linux Foundation Fellow, CTO of Linutronix GmbH, and project leader of the PREEMPT_RT real-time kernel patch set.

JP: Greetings, Thomas! It’s great to have you here this morning — although for you, it’s getting late in the afternoon in Germany. So PREEMPT_RT, the real-time patch set for the kernel is a fascinating project because it has some very important use-cases that most people who use Linux-based systems may not be aware of. First of all, can you tell me what “Real-Time” truly means? 

TG: Real-Time in the context of operating systems means that the operating system provides mechanisms to guarantee that the associated real-time task processes an event within a specified period of time. Real-Time is often confused with “really fast.” The late Prof. Doug Niehaus explained it this way: “Real-Time is not as fast as possible; it is as fast as specified.”

The specified time constraint is application-dependent. A control loop for a water treatment plant can have comparatively large time constraints measured in seconds or even minutes, while a robotics control loop has time constraints in the range of microseconds. But for both scenarios missing the deadline at which the computation has to be finished can result in malfunction. For some application scenarios, missing the deadline can have fatal consequences.

In the strict sense of Real-Time, the guarantee which is provided by the operating system must be verifiable, e.g., by mathematical proof of the worst-case execution time. In some application areas, especially those related to functional safety (aerospace, medical, automation, automotive, just to name a few), this is a mandatory requirement. But for other scenarios or scenarios where there is a separate mechanism for providing the safety requirements, the proof of correctness can be more relaxed. But even in the more relaxed case, the malfunction of a real-time system can cause substantial damage, which obviously wants to be avoided.

JP: What is the history behind the project? How did it get started?

TG: Real-Time Linux has a history that goes way beyond the actual PREEMPT_RT project.

Linux became a research vehicle very early on. Real-Time researchers set out to transform Linux into a Real-Time Operating system and followed different approaches with more or less success. Still, none of them seriously attempted a fully integrated and perhaps upstream-able variant. In 2004 various parties started an uncoordinated effort to get some key technologies into the Linux kernel on which they wanted to build proper Real-Time support. None of them was complete, and there was a lack of an overall concept. 

Ingo Molnar, working for RedHat, started to pick up pieces, reshape them and collect them in a patch series to build the grounds for the real-time preemption patch set PREEMPT_RT. At that time, I worked with the late Dr. Doug Niehaus to port a solution we had working based on the 2.4 Linux kernel forward to the 2.6 kernel. Our work was both conflicting and complimentary, so I teamed up with Ingo quickly to get this into a usable shape. Others like Steven Rostedt brought in ideas and experience from other Linux Real-Time research efforts. With a quickly forming loose team of interested developers, we were able to develop a halfway usable Real-Time solution that was fully integrated into the Linux kernel in a short period of time. That was far from a maintainable and production-ready solution. Still, we had laid the groundwork and proven that the concept of making the Linux Kernel real-time capable was feasible. The idea and intent of fully integrating this into the mainline Linux kernel over time were there from the very beginning.

JP: Why is it still a separate project from the Mainline kernel today?

TG: To integrate the real-time patches into the Linux kernel, a lot of preparatory work, restructuring, and consolidation of the mainline codebase had to be done first. While many pieces that emerged from the real-time work found their way into the mainline kernel rather quickly due to their isolation, the more intrusive changes that change the Linux kernel’s fundamental behavior needed (and still need) a lot of polishing and careful integration work. 

Naturally, this has to be coordinated with all the other ongoing efforts to adopt the Linux kernel to the different use cases ranging from tiny embedded systems to supercomputers. 

This also requires carefully designing the integration so it does not get in the way of other interests and imposes roadblocks for further developing the Linux kernel, which is something the community and especially Linus Torvalds, cares about deeply. 

As long as these remaining patches are out of the mainline kernel, this is not a problem because it does not put any burden or restriction on the mainline kernel. The responsibility is on the real-time project, but on the other side, in this context, there is no restriction to take shortcuts that would never be acceptable in the upstream kernel.

The real-time patches are fundamentally different from something like a device driver that sits at some corner of the source tree. A device driver does not cause any larger damage when it goes unmaintained and can be easily removed when it reaches the final state bit-rot. Conversely, the PREEMPT_RT core technology is in the heart of the Linux kernel. Long-term maintainability is key as any problem in that area will affect the Linux user universe as a whole. In contrast, a bit-rotted driver only affects the few people who have a device depending on it.

JP: Traditionally, when I think about RTOS, I think of legacy solutions based on closed systems. Why is it essential we have an open-source alternative to them? 

TG: The RTOS landscape is broad and, in many cases, very specialized. As I mentioned on the question of “what is real-time,” certain application scenarios require a fully validated RTOS, usually according to an application space-specific standard and often regulatory law. Aside from that, many RTOSes are limited to a specific class of CPU devices that fit into the targeted application space. Many of them come with specialized application programming interfaces which require special tooling and expertise.

The Real-Time Linux project never aimed at these narrow and specialized application spaces. It always was meant to be the solution for 99% of the use cases and to be able to fully leverage the flexibility and scalability of the Linux kernel and the broader FOSS ecosystem so that integrated solutions with mixed-criticality workloads can be handled consistently. 

Developing real-time applications on a real-time enabled Linux kernel is not much different from developing non-real-time applications on Linux, except for the careful selection of system interfaces that can be utilized and programming patterns that should be avoided, but that is true for real-time application programming in general independent of the RTOS. 

The important difference is that the tools and concepts are all the same, and integration into and utilizing the larger FOSS ecosystem comes for free.

The downside of PREEMPT_RT is that it can’t be fully validated, which excludes it from specific application spaces, but there are efforts underway, e.g., the LF ELISA project, to fill that gap. The reason behind this is, that large multiprocessor systems have become a commodity, and the need for more complex real-time systems in various application spaces, e.g., assisted / autonomous driving or robotics, requires a more flexible and scalable RTOS approach than what most of the specialized and validated RTOSes can provide. 

That’s a long way down the road. Still, there are solutions out there today which utilize external mechanisms to achieve the safety requirements in some of the application spaces while leveraging the full potential of a real-time enabled Linux kernel along with the broad offerings of the wider FOSS ecosystem.

JP: What are examples of products and systems that use the real-time patch set that people depend on regularly?

TG: It’s all over the place now. Industrial automation, control systems, robotics, medical devices, professional audio, automotive, rockets, and telecommunication, just to name a few prominent areas.

JP: Who are the major participants currently developing systems and toolsets with the real-time Linux kernel patch set?  

TG: Listing them all would be equivalent to reciting the “who’s who” in the industry. On the distribution side, there are offerings from, e.g., RedHat, SUSE, Mentor, and Wind River, which deliver RT to a broad range of customers in different application areas. There are firms like Concurrent, National Instruments, Boston Dynamics, SpaceX, and Tesla, just to name a few on the products side.

RedHat and National Instruments are also members of the LF collaborative Real-Time project.

JP: What are the challenges in developing a real-time subsystem or specialized kernel for Linux? Is it any different than how other projects are run for the kernel?

TG: Not really different; the same rules apply. Patches have to be posted, are reviewed, and discussed. The feedback is then incorporated. The loop starts over until everyone agrees on the solution, and the patches get merged into the relevant subsystem tree and finally end up in the mainline kernel.

But as I explained before, it needs a lot of care and effort and, often enough, a large amount of extra work to restructure existing code first to get a particular piece of the patches integrated. The result is providing the desired functionality but is at the same time not in the way of other interests or, ideally, provides a benefit for everyone.

The technology’s complexity that reaches into a broad range of the core kernel code is obviously challenging, especially combined with the mainline kernel’s rapid change rate. Even larger changes happening at the related core infrastructure level are not impacting ongoing development and integration work too much in areas like drivers or file systems. But any change on the core infrastructure can break a carefully thought-out integration of the real-time parts into that infrastructure and send us back to the drawing board for a while.

JP:  Which companies have been supporting the effort to get the PREEMPT_RT Linux kernel patches upstream? 

TG: For the past five years, it has been supported by the members of the LF real-time Linux project, currently ARM, BMW, CIP, ELISA, Intel, National Instruments, OSADL, RedHat, and Texas Instruments. CIP, ELISA, and OSADL are projects or organizations on their own which have member companies all over the industry. Former supporters include Google, IBM, and NXP.

I personally, my team and the broader Linux real-time community are extremely grateful for the support provided by these members. 

However, as with other key open source projects heavily used in critical infrastructure, funding always was and still is a difficult challenge. Even if the amount of money required to keep such low-level plumbing but essential functionality sustained is comparatively small, these projects struggle with finding enough sponsors and often lack long-term commitment.

The approach to funding these kinds of projects reminds me of the Mikado Game, which is popular in Europe, where the first player who picks up the stick and disturbs the pile often is the one who loses.

That’s puzzling to me, especially as many companies build key products depending on these technologies and seem to take the availability and sustainability for granted up to the point where such a project fails, or people stop working on it due to lack of funding. Such companies should seriously consider supporting the funding of the Real-Time project.

It’s a lot like the Jenga game, where everyone pulls out as many pieces as they can up until the point where it collapses. We cannot keep taking; we have to give back to these communities putting in the hard work for technologies that companies heavily rely on.

I gave up long ago trying to make sense of that, especially when looking at the insane amounts of money thrown at the over-hyped technology of the day. Even if critical for a large part of the industry, low-level infrastructure lacks the buzzword charm that attracts attention and makes headlines — but it still needs support.

JP:  One of the historical concerns was that Real-Time didn’t have a community associated with it; what has changed in the last five years?  

TG: There is a lively user community, and quite a bit of the activity comes from the LF project members. On the development side itself, we are slowly gaining more people who understand the intricacies of PREEMPT_RT and also people who look at it from other angles, e.g., analysis and instrumentation. Some fields could be improved, like documentation, but there is always something that can be improved.

JP:  What will the Real-Time Stable team be doing once the patches are accepted upstream?

TG: The stable team is currently overseeing the RT variants of the supported mainline stable versions. Once everything is integrated, this will dry out to some extent once the older versions reach EOL. But their expertise will still be required to keep real-time in shape in mainline and in the supported mainline stable kernels.

JP: So once the upstreaming activity is complete, what happens afterward?

TG: Once upstreaming is done, efforts have to be made to enable RT support for specific Linux features currently disabled on real-time enabled kernels. Also, for quite some time, there will be fallout when other things change in the kernel, and there has to be support for kernel developers who run into the constraints of RT, which they did not have to think about before. 

The latter is a crucial point for this effort. Because there needs to be a clear longer-term commitment that the people who are deeply familiar with the matter and the concepts are not going to vanish once the mainlining is done. We can’t leave everybody else with the task of wrapping their brains around it in desperation; there cannot be institutional knowledge loss with a system as critical as this. 

The lack of such a commitment would be a showstopper on the final step because we are now at the point where the notable changes are focused on the real-time only aspects rather than welcoming cleanups, improvements, and features of general value. This, in turn, circles back to the earlier question of funding and industry support — for this final step requires several years of commitment by companies using the real-time kernel.

There’s not going to be a shortage of things to work on. It’s not going to be as much as the current upstreaming effort, but as the kernel never stops changing, this will be interesting for a long time.

JP: Thank you, Thomas, for your time this morning. It’s been an illuminating discussion.

To get involved with the real-time kernel patch for Linux, please visit the PREEMPT_RT wiki at The Linux Foundation or email real-time-membership@linuxfoundation.org

The post In the trenches with Thomas Gleixner, real-time Linux kernel patch set appeared first on Linux.com.

Read More at Phoronix

The post Linux Getting Fixed Up For Handling Pointing Sticks On Some Touchpads appeared first on Linux.com.

Read More at Softpedia News

The post World’s First AMD-Only Linux Laptop Officially Announced appeared first on Linux.com.

Read More at The Verge

The post Walmart made a $99 tablet with Android 10 and USB-C appeared first on Linux.com.

Read More at Softpedia News

The post Pineloader Is a Brand-New Multi Bootloader for Your Favorite Linux Phone appeared first on Linux.com.