Open-source News

NVIDIA this week published JetPack 5.0.2 as their updated development environment and SDK for their Arm-powered Jetson modules and developer kits...

Manjaro ARM 22.08 Released with Orange Pi 3 and 4 LTS Support, Linux Kernel 5.19  9to5Linux

Canonical kernel engineer Kai-Heng Feng posted a patch on Tuesday for capable laptops to switch their external monitor connections to be routed through a laptop's discrete GPU rather than the integrated GPU. With select laptops this can be done with an ACPI call but raises questions among upstream developers rather this change is indeed desirable...

Linux Patch Sparks Differing Views Over External Monitor Handling With iGPU vs. dGPU  Phoronix

Microsoft .NET 6 bundled with Ubuntu Linux  InfoWorld

There's no place like GNOME: Project hits 25, going on 43  The Register

AMD CPU microcode loading to be optimized to per-thread on Linux  Wccftech

Command to List Installed Snap Packages - Linux Shout  Linux Shout

Valve dev understandably not happy about glibc breaking Easy Anti-Cheat on Linux  GamingOnLinux

Commands to Remove a package in Ubuntu  Linux Shout

Blossom Tales 2: The Minotaur Prince out with Linux support  GamingOnLinux

Measure latency for embedded systems with this open source tool Nicolas Rabault Wed, 08/17/2022 - 03:00 Register or Login to like Register or Login to like

When it comes to time synchronization for embedded systems in a distributed architecture, there are "soft" use cases (typical, everyday devices) and complex, or "hard," use cases (car brake systems, aerospace). It's easy to see that a hard use case has unique requirements and a low tolerance for latency. To put it another way, hard use cases have hard, real-time constraints.

Latency is the bitter enemy of real-time computation. Latency, in the context of a critical real-time application, is the time between data generation and data reception. The reality is that when there is an interconnected network of several systems, there's latency.

[ Related read Edge computing: Latency matters ]

What's the difference between soft and hard real-time use cases?

A soft use case is easy to manage. Here are some examples of soft use cases:

• A washing machine with a detergent dispenser that needs to be refilled after every wash.
• A printer that needs to be refilled with paper.
• A car that needs to be refilled with gasoline or recharged with electricity.

Hard cases, however, are complicated to synchronize and complex to connect. The following are examples of hard use cases:

• Car braking systems where no other system (such as steering) can interfere or cause latency.
• Nuclear power plants where a sensor must send back a status report in real-time to enable decision-making without disruption from another component of the system.
• A rocket, which must be able to correct its trajectory in real-time to avoid being compromised by external elements such as weather conditions.

How the embedded world deals with real-time

Consistent latency is no guarantee when working with distributed (multi-MCU) critical and real-time environments. If there happens to be many collisions in a system, a message could be delayed multiple times, dramatically and unpredictably increasing latency. In such a situation, younger (newer) data could arrive before older data, compromising the system's integrity.

Image by:

(Nicolas Rabault, CC BY-SA 4.0)

Typically, there is no real-time clock (RTC) in the embedded world because that requires a power source, which isn't always possible, and even if there were one, the system would lose time measurement in the event of a power disruption. The same problem is true when you try to update time from the Internet.

In embedded systems, nothing handles time tracking when a system is off, and nothing synchronizes time when the system powers on. In most cases, the timeline starts when the system starts.

More great content Free online course: RHEL technical overview Learn advanced Linux commands Download cheat sheets Find an open source alternative Explore open source resources Luos allows timelines management

While it is physically impossible to remove latency completely, monitoring it is important to guarantee data validity. By measuring latencies in real-time, the open source Luos engine, released under the Apache2 license, uses the latency value to know the real, local date of an event. There's no global timeline, just a delta between data generation and consumption. Luos precisely measures that delta with any network.

Luos is an open source software and a modular methodology to simplify the creation and sharing of embedded features. Luos encapsulates hardware and software functions as microservices so that each electronic device has a set of functions that communicate and recognize each other but remain independent.

Without Luos, the developer must synchronize timelines. It's up to the developer to control latency and to update the dates on each system so that each one has the same time repository. It's hard to do and uses a lot of resources.

With distributed latency-based time synchronization, a developer no longer needs to work with a global timeline, which is often difficult, given that each node has a different timeline. Luos consolidates these timelines to avoid having one "correct" point in time and instead allows each system to have control. This design is completely multi-master. The reference timeline is the local timeline of the node the developer is looking through. Luos is able to remap an event date across the node's local timeline by measuring latency.

Real-time developers are used to working with a global timeline and might question whether the method used by Luos is accurate, given such critical use cases. The answer is yes because the nodes communicate and all have the same level of information without having a centralized master. It's as if synchronization were happening each time data is modified in the global system.

[ Get the eBook, Open source data pipelines for intelligent applications ]

How Luos works

Technically, Luos computes latency. Across nodes a sum of delays exists, including the source latency, the target latency, and the network latency. Luos evaluates that information and sums it up to remap the information on the local timeline using a timestamp.

It is possible to measure an event in the past or the future. Thus, Luos can use the measurement for data collection and for precisely programmed commands.

Do you want to get started with Luos and embedded systems? Go deeper with Luos on Luos.io.

By evaluating latency, Luos manages timelines without synchronization on multiple nodes.

Image by:

Opensource.com

Internet of Things (IoT) What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

4 common issues with implementing Agile and how to address them Kelsea Zhang Wed, 08/17/2022 - 03:00 1 reader likes this 1 reader likes this

While working on the open source ZenTao project, I get constant feedback that getting Agile up and running is a big task in many organizations. As with any new process, you will run into issues, and many of them will feel unique to your organization. While context is important, there's a certain amount of abstraction possible after you've coached enough teams. This article covers the four most common issues I've encountered. While your Agile coach should analyze any actual problems in the context of your organization, knowing these general issues can help better prepare you and your teams for the transitional process.

Note that I only discuss issues that have been found and not how to find issues, which is another topic entirely!

Lack of Agile awareness

I consider this the most significant issue. You can detect this issue in conversations between business departments, managers, and team members. They emphasize delivery as a single event that happens at a specific time. They talk about making "more plans," and you hear phrases like "deliver more work results" and "it's Agile, so why don't you work overtime?"

There's no single solution for this. You can only remedy these misunderstandings with results. Don't get bogged down in trying to correct perception; instead, focus on luring people into an Agile way of thinking with the benefit of Agile productivity.

Similarly, to lower any perceived barriers, you can reduce the use of specialized Agile terminology as much as possible when communicating with people who don't understand Agile yet.

Lack of support from business departments

This issue can determine whether Agile implementation can succeed. Business departments may fail to attend meetings, fail to clarify stories, and provide no feedback. At the same time, however, they may ask R&D teams to deliver work results according to "quality and quantity."

There are a few possible reasons for this issue:

• The business department is aggressive. Once they're unsatisfied with the R&D department, they complain arbitrarily.
• The business department focuses on its own work, and working with the R&D department is out of its responsibility and assessment.
• The business department is disappointed with the R&D department and believes support to be pointless.
• The business department has no time to provide support.

Here are some suggestions for addressing the problem:

• Do your best to choose a business team with a high support level.
• Be friendly! You can get a lot of recognition and support by increasing friendly and respectful communication.
• Bind the interests of the business team together with the R&D department.
• Rebuild trust with the business department through transparency.
• Business departments understand contracts. Negotiate with your business department to identify what's expected of them and what's required from them in terms of communication and support.

Lack of team participation

This problem is usually the easiest to detect. Team participation is key; you can generally identify right away when you don't have it. You see it when managers fail to lead a team, and team members don't feel empowered or inspired to improve the team's processes.

There are a few possible reasons for the lack of team participation:

• The company's performance assessment restricts teams from self-organizing. For example, an evaluation might focus on personal performance and actual lines of code.
• Team efforts include complicated processes with a lot of duplicate work. For example, members spend time repeatedly writing working logs and daily reports.
• Low tolerance for mistakes. When the cost of innovation is a high risk to an individual's job, it doesn't happen.
• Frequent changes in team members.
• The team's manager may lack management skills.

Ideally, changes would be made to the organizational policy to help team members engage and participate. In the absence of changes in regulations, conduct interviews with team members to address the problem directly.

Many people believe that team participation can be gained by building trust. That's true, but trust without organizational policy is meaningless because only the larger organization can ensure trust between team members. In other words, systems and regulations are crucial pillars of trust.

More great content Free online course: RHEL technical overview Learn advanced Linux commands Download cheat sheets Find an open source alternative Explore open source resources Poor-quality user stories

This is the biggest problem in development. Poor-quality user stories are manifested by development errors, lots of rework, redundant confirmation, duplicate modifications, and other wastes of development resources. Worse, it's one of the greatest causes of overtime.

Possible reasons for poor-quality stories:

• The client didn't express their requirements clearly or propose solutions directly.
• The project wasn't clearly defined, leading to capacity and sometimes attitude issues.
• The delivered product doesn't solve the client's problems (and even results in complaints in review meetings).
• The stories are unstable and change frequently.

Here's how I address issues of poor quality stories:

• Use visual aids, such as prototype diagrams, sketchnotes, storyboards, and so on.
• Reinforce lessons from business analysis for the product team. Focus on story confirmation procedures and review to ensure every story is correct.
• Establish writing standards for stories and requirements. (Don't assume that Agile doesn't require standards!)
• Be brave enough to say no to unreasonable stories.

Wrap up

Establishing an Agile way of thinking in an existing company is a big task with plenty of potential pitfalls. However, some problems are more prevalent than others and tend to span organizations. I've identified the four most common issues I've encountered. Whether it's lack of awareness, support, participation, or poor user stories, there are certain strategies that make handling these problems more manageable. How can you implement these approaches to help smooth the way for great Agile success?

Whether it's lack of awareness, support, participation, or poor user stories, there are certain strategies that make handling these problems more manageable.

Image by:

opensource.com

Agile What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Deepin 23 is Introducing a New Package Format and Repository, Sounds Interesting!  It's FOSS News

The post 4 Ways to View Disks and Partitions in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

In this guide, we will show how to list storage disks and partitions in Linux systems. We will cover both command-line tools and GUI utilities. By the end of this guide, you will learn

The post 4 Ways to View Disks and Partitions in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

How to Install Ubuntu on Windows Services for Linux  ITPro Today

Chinese-made Linux distribution deepin 23 Preview now available for download  BetaNews

VFX Reference Platform as a standards body that aims to help standardize software platforms in the realm of digital content creation (DCC) has published a detailed report for studios to consider in choosing their next Linux platform. Their new recommendations for visual effects and animation studios about moving to newer Linux distributions over the next year -- especially with many still relying on CentOS 7 -- is for moving to Red Hat Enterprise Linux 9 otherwise one of the downstreams like Rocky Linux or AlmaLinux. Close behind in their recommendations and as a longer-term objective is also tossing some support behind Ubuntu Linux...

VFX & Animation Studios Urged To Upgrade To RHEL 9 Or Rocky Linux / AlmaLinux 9  Phoronix

5 Linux command line classes from Coursera  TechRepublic