Open-source News

I am old enough to remember when organizations developed software in-house – all of it. I also clearly remember my information systems college professor teaching it is almost always less expensive and better to use code/programs already written and adapting them for your use than to recreate the wheel from scratch. 

It is a different world now – software is built on a foundation of other programs, libraries, and code bases. Free and open source software (FOSS) is key to this because it is so easy to pickup, use, share, and create code. What an opportunity to speed development and focus innovation on the next thing rather than creating what already exists. This is part of the value of open source software – collaborate on the building blocks and innovate and differentiate on top of that. 

However, there are also challenges in this space, with a good example being the question of how to address licensing. There are A LOT of types of licenses that can apply to a piece of software/code. Each license needs to be understood and tracked with each piece of software it is included in for an organization to ensure nothing is missed. This can quickly multiply into a significant catalog that requires lots of manual work. On top of that, you also need to provide that license information to each of your customers, and they will have their own system and/or processes for providing that information to them and making sure it is up-to-date with each new version of the software. 

You can see where this can quickly consume valuable staff resources and open doors to mistakes. Imagine the possibility of a standard way to track and report the licenses so your teams don’t need to worry about all of the digital paperwork and can instead focus on innovation and adding value to you and your customers.

This is exactly the problem a team of lawyers and governance experts sought to fix back in 2016 and created the OpenChain Project to do just that. They asked, what are the key things for open source compliance that everyone needs, and how do we unify the systems and processes. They envisioned an internationally accepted standard to track and report all of the licenses applicable to a software project. The end result is a more trustable supply chain where organizations don’t need to spend tons of time checking compliance again and again and then remediating. 

The result – a ISO standard  (ISO/IEC 5230) was approved in Q4 2020. The OpenChain Project also hosts a library of 1,000 different reference documents in a wide variety of languages – some are official and many more are community documents, like workflow examples, FAQs, etc.

How are organizations benefiting from OpenChain? I find it encouraging that Toyota is one of the leaders in this. As anyone who has had at least one business class in college knows, Toyota is a leader in innovations for manufacturing over several decades. In the 1970s they pioneered supply chain management techniques with the Toyota Production System (please tell me they had to do TPS reports) – adopted externally as Just in Time manufacturing. They are also known for adopting the philosophy of Kaizen, or continuous improvement. So, as they looked at how to manage software supply chains and all of the licensing, they adopted the OpenChain Specification. They implemented it, in part, with a governance structure and an official group to manage OSS risks and community contributions.

.avia-image-container.av-l20heg6x-cd2d943e933a1c3dd3f8cb175716f4bc .av-caption-image-overlay-bg{ opacity:0.4; background-color:#000000; } .avia-image-container.av-l20heg6x-cd2d943e933a1c3dd3f8cb175716f4bc .av-image-caption-overlay-center{ color:#ffffff; }

Toyota’s OSS governance structure

They are also an active participant in the OpenChain Japan Working Group to help identify bottlenecks across the supply chain, and the group enabled Toyota to develop information sharing guidelines to address licensing challenges with Tier 1 suppliers. They now see reduced bottlenecks, more data for better decision making, and decreased patent and licensing risks. Read more.

PwC is a global auditing, assurance, tax, and consulting firm. As an auditor, much of their business revolves around building trust in society. They also develop software solutions for thousands of clients around the world and receive software from providers of all sizes and maturity levels, making OSS compliance difficult. It was a tremendous effort and caused time delays for them and their clients. Now, PwC is able to provide clients with an Open Source Software compliance assessment based on the latest OpenChain specification. Their clients can share an internationally-recognized PwC audit report to verify OSS compliance. Read more.

And just last month, SAP, a market leader in enterprise application software, announced they are adopting the OpenChain ISO/IEC 5230 standard. It marks the first time that an enterprise application software company has undergone a whole entity conformance. Their reach across the global supply chain is massive – its customers are involved in almost 90% of global trade.

As the ISO/IEC standard is done, what is next for OpenChain? They are looking at security, export control, and more. 

If you or your organization are interested in learning more about OpenChain, adopting the standard, or getting involved in what is next, head over to https://www.openchainproject.org/. We also host an online training course when you are ready to dig in: Introduction to Open Source License Compliance Management. 

My hope is that you now spend less time on compliance and more time on innovation.

The post More Time on Innovating, Less Time on Compliance appeared first on Linux Foundation.

Google has pledged $1 million to the Linux Foundation’s new open source security awards program  BollyInside

Google has pledged $1 million to the Linux Foundation’s new open source security awards program  BollyInside

Microsoft Finally Brings ARM-Based VMs to Azure  thenewstack.io

Sophos upgrades Sophos Cloud Workload Protection  Telecompaper EN

As previously talked about on Phoronix with the in-development Linux 5.18 kernel there is a change to the Linux kernel scheduler around the NUMA imbalance handling when spanning multiple LLCs as is the case with AMD Zen CPUs. Already I've carried out benchmarks looking at some of the areas where AMD EPYC CPUs are enjoying speed-ups on Linux 5.18. Since benchmarking the AMD EPYC 7773X with its hefty 1.5GB of L3 cache for 2P servers via AMD 3D V-Cache, I've been curious to try this forthcoming kernel on that Milan-X configuration. Here are such benchmarks looking at the AMD EPYC 7773X 2P performance on Ubuntu 22.04 with its default Linux 5.15 kernel against Linux 5.17 stable and then the 5.18 development kernel.

A new version of Mold has been released, the high-speed open-source linker successfully challenging the likes of GNU Gold and LLVM LLD...

Running AMD EPYC 7773X Milan-X With Linux 5.18's Performance Improvements  Phoronix

How to Change HiDPI Scaling Settings on Linux  BollyInside

The exFAT file-system driver for the Linux kernel continues maturing nicely with new features, fixes, and performance improvements. The latest Linux exFAT driver improvement worth mentioning is a significant performance improvement from a Sony engineer...

Sony Contributes ~73%+ Performance Improvement For exFAT Linux Driver  Phoronix

While AMD's official graphics driver on Windows has effectively moved to legacy pre-Polaris graphics card support, in the open-source world on Linux even the old "R600" Gallium3D driver for Radeon HD 2000 through HD 6000 series graphics cards sees the occasional new feature work by the community. The latest is a new NIR back-end being rewritten for this R600g driver and should debut soon...

This week saw KDE developers tackling many bug fixes to their open-source desktop software with Plasma Wayland fixes still being one of the dominant areas receiving bug fixing attention...

KDE Has Many Plasma Wayland Fixes In Its Easter Basket  Phoronix

FreeBSD 13.1 is working its way toward release later this month and out today is the second to last release candidate...

Mesa 22.1-rc1 Offers Enhancements For Radeon Vulkan, PowerVR Rogue GPU and Microsoft Dozen Merging  Wccftech

Mesa 22.1-rc1 Offers Enhancements For Radeon Vulkan, PowerVR Rogue GPU and Microsoft Dozen Merging  Wccftech

Razer's Pricey New Linux Laptop Is for Deepfakes Instead of Headshots  Gizmodo

GCC vs. Clang On The Apple M1 Under Arch-Based Asahi Linux  Phoronix

How the C programming language has grown Jim Hall Fri, 04/15/2022 - 03:00

The C programming language will turn fifty years old in 2022. Yet despite its long history, C remains one of the top "most-used" programming languages in many "popular programming languages" surveys. For example, check out the TIOBE Index, which tracks the popularity of different programming languages. Many Linux applications are written in C, such as the GNOME desktop.

I interviewed Brian Kernighan, co-author (with Dennis Ritchie) of The C Programming Language book, to learn more about the C programming language and its history.

Where did the C programming language come from?

C is an evolution of a sequence of languages intended for system programming—that is, writing programs like compilers, assemblers, editors, and ultimately operating systems. The Multics project at MIT, with Bell Labs as a partner, planned to write everything in a high-level language (a new idea at the time, roughly 1965). They were going to use IBM's PL/1, but it was very complicated, and the promised compilers didn't arrive in time.

After a brief flirtation with a subset called EPL (by Doug McIlroy of Bell Labs), Multics turned to BCPL, a much simpler and cleaner language designed and implemented by Martin Richards of Cambridge, who I think was visiting MIT at the time. When Ken Thompson started working on what became Unix, he created an even simpler language, based on BCPL, that he called B. He implemented it for the PDP-7 used for the first proto-Unix system in 1969.

BCPL and B were both "typeless" languages; that is, they had only one data type, integer. The DEC PDP-11, which arrived on the scene in about 1971 and was the computer for the first real Unix implementation, supported several data types, notably 8-bit bytes as well as 16-bit integers. For that, a language that also supported several data types was a better fit. That's the origin of C.

Programming and development Red Hat Developers Blog Programming cheat sheets Try for free: Red Hat Learning Subscription eBook: An introduction to programming with Bash Bash shell scripting cheat sheet eBook: Modernizing Enterprise Java

How was C used within Bell Labs and the early versions of Unix?

C was originally used only on Unix, though after a while, there were also C compilers for other machines and operating systems. Mostly it was used for system-programming applications, which covered quite a spectrum of interesting areas, along with a lot of systems for managing operations of AT&T's telephone network.

What was the most interesting project written in C at Bell Labs?

Arguably, the most interesting, memorable, and important C program was the Unix operating system itself. The first version of Unix in 1971 was in PDP-11 assembly language, but by the time of the fourth edition, around 1973, it was rewritten in C. That was truly crucial since it meant that the operating system (and all its supporting software) could be ported to a different kind of computer basically by recompiling everything. Not quite that simple in practice, but not far off.

You co-authored The C Programming Language book with Dennis Ritchie. How did that book come about, and how did you and Dennis collaborate on the book?

I had written a tutorial on Ken Thompson's B language to help people get started with it. I upgraded that to a tutorial on C when it became available. And after a while, I twisted Dennis's arm to write a C book with me. Basically, I wrote most of the tutorial material, except for the system call chapter, and Dennis had already written the reference manual, which was excellent. Then we worked back and forth to smooth out the tutorial parts; the reference manual stayed pretty much the same since it was so well done from the beginning. The book was formatted with the troff formatter, one of many tools on Unix, and I did most of the formatting work.

When did C become a thing that other programmers outside of Bell Labs used for their work?

I don't really remember well at this point, but I think C mostly followed along with Unix for the first half dozen years or so. With the development of compilers for other operating systems, it began to spread to other systems besides Unix. I don't recall when we realized that C and Unix were having a real effect, but it must have been in the mid to late 1970s.

Why did C become such an influential programming language?

The primary reason in the early days was its association with Unix, which spread rapidly. If you used Unix, you wrote in C. Later on, C spread to computers that might not necessarily run Unix, though many did because of the portable C compiler that Steve Johnson wrote. The workstation market, with companies like Sun Microsystems, MIPS (which became SGI), and others, was enabled by the combination of Unix and C. The IBM PC came somewhat later, about 1982, and C became one of the standard languages, under MS-DOS and then Windows. And today, most Internet of Things (IoT) devices will use C.

C remains a popular programming language today, some 50 years after its creation. Why has C remained so popular?

I think C hit a sweet spot with efficiency and expressiveness. In earlier times, efficiency really mattered since computers were slow and had limited memory compared to what we are used to today. C was very efficient, in the sense that it could be compiled into efficient machine code, and it was simple enough that it was easy to see how to compile it. At the same time, it was very expressive, easy to write, and compact. No other language has hit that kind of spot quite so well, at least in my humble but correct opinion.

How has the C programming language grown or changed over the years?

C has grown modestly, I guess, but I haven't paid much attention to the evolving C standards. There are enough changes that code written in the 1980s needs a bit of work before it will compile, but it's mostly related to being honest about types. Newer features like complex numbers are perhaps useful, but not to me, so I can't make an informed comment.

What programming problems can be solved most easily in C?

Well, it's a good language for anything, but today, with lots of memory and processing power, most programmers are well served by languages like Python that take care of memory management and other more high-level constructs. C remains a good choice for lower levels where squeezing cycles and bytes still matter.

C has influenced other programming languages, including C++, Java, Go, and Rust. What are your thoughts on these other programming languages?

Almost every language is in some ways a reaction to its predecessors. To over-simplify a fair amount, C++ adds mechanisms to control access to information, so it's better than C for really large programs. Java is a reaction to the perceived complexity of C++. Go is a reaction to the complexity of C++ and the restrictions of Java. Rust is an attempt to deal with memory management issues in C (and presumably C++) while coming close to C's efficiency.

They all have real positive attributes, but somehow no one is ever quite satisfied, so there will always be more languages that, in their turn, react to what has gone before. At the same time, the older languages, for the most part, will remain around because they do their job well, and there's an embedded base where they are perfectly fine, and it would be infeasible to reimplement in something newer.

Thanks to Brian for sharing this great history of the C programming language!

Would you like to learn C programming? Start with these popular C programming articles from the last year: 5 ways to learn the C programming language in 2022.

Here's my interview with Brian Kernighan, co-author (with Dennis Ritchie) of The C Programming Language book, to discuss the C programming language and its 50-year history.

Programming 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.