Open-source News

AMD engineers on the ROCm team have released AOMP 15.0-0 on Monday as the newest version of their Radeon OpenMP compiler code. It also turns out they are working on another Radeon GPU compute compiler called "AFAR"...

4 questions about the essence of openness Brook Manville Tue, 04/05/2022 - 03:00 Up Register or Login to like.

Despite some quibbles I voiced in the first part of my review of Johan Norberg's Open: The Story of Human Progress, the author's argument remains engaging—especially at this historical juncture, as the world witnesses Russia's invasion of Ukraine, and authoritarian movements around the world are threatening the sustainability of the liberal democracies Norberg identifies as bastions of openness.

But if the world were to somehow make a transformational leap towards more global openness, what would actually be required? The conceptual challenge of that is daunting—but a first step might begin simply by articulating some of the unexplored questions that follow from Open's overall vision.

These are meaty questions, to be sure—about the actual "performance gains" more openness will deliver, about design considerations that any community would need to make if to pursue open transformation, and about how, precisely, that work would have to be undertaken in different contexts.

Open Organization resources Download resources Join the community What is an open organization? How open is your organization?

So in this second part of my reviewI want to elaborate a few of these. I'll also offer some explanation of how they pertain to the historical narrative Norberg lays out, and why now getting clear on them bears attention from any would-be open advocates and reformers. At the heart of inquiries here is a single, probing question: What can we actually do to promote more openness of the sort that Norberg envisions—if that is indeed something we desire?

What's the point of openness?

The first question Norberg raises for me is this: What, overall, is the purpose of pursuing more openness for one's entity? How do we more concretely define the goals of becoming more open?

This question may sound so obvious that it needn't even be raised. But, surprisingly, Norberg is much less explicit on the point than he should be. His argument waivers between the notion of "open" as a self-evident truth and, at other times, as the basis for a given historical success he imputes to this or that nation, based on, say, features like "greater innovation" and "community-wide problem-solving." My point here is not to deny the benefits of openness, but rather to push for an articulation of more specific and concretely defined benefits of open strategies that an organization or other entity is right to reach for.

For instance, if a benefit of greater openness is its impact on human "progress," then we need to articulate precisely what that term signifies. And that means the possibility of inviting criticisms. Recently, for example, in another spirited but also controversial book, Enlightenment Now, Steven Pinker took a cut at the difficult work of defining "progress." For him, progress can be made concrete and measurable by assessing modernity's improvement against several specific variables of human civilization (e.g., increase in life-span, more positive healthcare outcomes, growth of wealth, increase of knowledge, etc.). Pinker associates such improvements that benefit us today with the growth of reason, science and humanism—Enlightenment values forged over the last several centuries. His charge to modern societies is to keep building progress by fortifying and extending such Enlightenment practices. Pinker's approach to explaining progress has been variously challenged, but his case at least begins with a firm definitional stake in the ground.

We should expect the same of Norberg's manifesto. As Norberg explains, humans' psychological and sociological tendencies often create ongoing barriers to sustaining open approaches to life and work. If we're to undertake the (clearly difficult) work of fostering more open institutions, we'll want to understand specifically the value these approaches deliver, and why we should push for them.

In other words, what's the real prize for all the trouble?

If the world were to somehow make a transformational leap towards more global openness, what would actually be required? The conceptual challenge of that is daunting.

Norberg's overall conceit about purpose (to which I'm sympathetic) is fundamentally practical: we should pursue openness because it creates and facilitates material improvements and superior success for whatever members of a society are trying to achieve, as well as broader economic welfare. But he also says little about less material aspects of life in an open community: the joys and fulfillment of greater individual freedom, and the horizon-broadening exposure to new ideas and cultural inputs. These are more intangible and somewhat relative, historically contingent, and perhaps more fraught. As Norberg observes, horizon-broadening exposure to other cultural influences can also be the fuel of tribal antagonism—not a benefit for many people, but rather a source of identity-threatening fear.

And how does this intersect with the view that greater openness is less about any benefits to incumbent members of a nation and more about satisfying the human rights of newcomers to it? For many constituents in liberal democracies, openness is less an opportunistic strategy and more a moral obligation to fellow humans. Tensions between this view and others point to the need for more intentional discussion of the purpose of—and goals in potentially pursuing—any stance of greater openness.

What's the scale of openness?

The next question Norberg's Open raises for me is: What 'unit(s) of analysis' are the appropriate focus of "open-building?"Do different entities require different approaches to "open?"

By "unit of analysis," I mean the size and nature of the entity being studied—a fancy phrase that asks about the "relative bigness" and make-up of whatever human grouping one is trying to make more open. Norberg's aim is bold: raise existing discussions about open innovation and cross-boundary collaboration in business organizations and open software networks to much greater scale, examining political, cultural, and economic entities (including nation states, empires, and entire civilizations). From time to time, he also focuses on smaller organizational forms (cities, indigenous communities, and groups of nomadic peoples). For Norberg, "more open" benefits human groupings of any size.

But does it always? Because his understanding of what makes for "progress" is so fluid, one wonders if the concept itself not only needs stricter definition, but also if it scales in all the ways Norberg believes. Taking as a hypothesis that the answer to the latter is "yes," further analysis would look for differentiation, segmentation of type, and appropriate qualification of what "open" can expect to deliver at these various scales.

If indeed "open" always delivers some kind of progress, we could sharpen our understanding of why and how it does this, given the substantial differences among different kinds of organizations and human groupings. We might also examine the question of whether there's some upper limit to size. Can a culture and set of practices for open innovation expand infinitely, or does it ultimately hit a ceiling?

What's the limit of openness?

Next, I wonder: Does "open" ever need to respect certain boundaries? When, where, and why?

The "unit of analysis question" presumes that some entities might strive to be open, but others—perhaps because they're bigger, smaller, or simply different—may not. The implication here is that openness involves limits or boundaries. But Norberg leaves unresolved the question of whether "open" has boundaries. Does an open world, for instance, mean one in which significant distinctions between all entities eventually disappear, because no boundaries should exist between any human groupings, lest tribal enmity flourish and progress cease? If this latter condition is part of Norberg's vision (when discussing climate change, he edges slightly in this direction), it's certainly not implied in most of his discussion. Instead, following the lessons of history, he suggests that some entities will be more open than others, and those that are will fare better.

Does an open world mean one in which significant distinctions between all entities eventually disappear, because no boundaries should exist between any human groupings, lest tribal enmity flourish and progress cease?

Then, a follow-on issue: If leaders or citizens of a certain society, nation, or extended community decide to open themselves up, when and how do they draw any kind of boundaries at all? This leads to a host of related questions, all familiar to anyone who has studied open organizational design, implementation, or practice:

• Who defines membership for participating and enjoying the fruits of openness?
• What (if any) rights and privileges confer to members of a community or society who aren't full "members," and how will those be determined?
• Who, if anyone, should not be allowed to join an open community? Is potential exclusion based on nefarious designs for individual greed and power? Because an entity wishes ill upon the well-intentioned, more open members? Or are there other suitable prohibitions?
• What principles, practices, and institutions are necessary to decide and defend certain boundaries (both in terms of people and territory, and even including virtual networks), given that boundaries themselves can undermine openness, even if they are also necessary to defend and preserve it?

What's the best way to foster openness?

Norberg's book raises one final question for me: What form of governance is needed to advance and sustain openness?

Towards the end of his book, Norberg seems to imply that liberal democracies are the most appropriate stewards of open societies. That seems logical enough. But as we've seen, his historical survey celebrates openness as achieved and/or utilized by the harsh Mongolian emperor Genghis Kahn, Roman imperial rulers, and 18th C. Britain under William of Orange (who worked with an elected parliament but remained a monarch with still substantial powers). Norberg also notes that modern China has been experimenting, so far relatively successfully, with a blend of authoritarian rule and more open economic practices. To what degree, and in what ways, is "open" independent of the kind of rule that organizes the society that might benefit from it? What systems or regimes of governance espouse the most viable "vision" of openness? And how do those systems structure decision-making power?

An organization's governance model is critical not just to creating openness but also to sustaining that posture over time (especially given all the human tendencies to retreat from the natural challenges and setbacks it brings, as Norberg elaborates). Consider, for example, some of the critical, but also enduring, decisions that governing institutions and their leaders must make in connection with both development and maintenance of openness:

Agreeing on the boundaries of and membership in an open community: Decisions about both are never static or settled. Expansion or contraction of territory, growth of new populations, changing diversity and complexity of members who compose the community—all require new decisions and potential changes or refinements to past agreements. Maintaining what it means to be open, and for whom and where, must be a continuing process managed on behalf of all members (and would-be members, too).

Defending those boundaries and membership(s): The maintenance of the open society is not only about achieving what might be called "internal agreement" among membership stakeholders, but also about warding off external threats or major challenges to those decisions by hostile outside powers. Open societies must ultimately struggle with both domestic and foreign challenges to how open they think they wish to be.

Defining the excellence that justifies openness: Norberg glosses over any explicit discussion of this, but the book's implied premise is that open societies ultimately thrive because they foster competitive selection of the "best ideas," which leads to innovation. In other words, open societies win and thrive because they make decisions according to some standard of "excellence"—not familiarity, parochial preferences, or ideological priorities. But "excellence" is not always always simple and self-evident to any particular community: What criteria will be used to define it? How will conflicts about it be resolved? How will it be maintained as the pre-eminent basis for action? These are governance questions, and members of open communities themselves—or those entrusted to govern it—must agree on how those challenges will be met and differing opinions among members mediated.

It is the great value of Norberg’s book that it can inspire and raise hope for a generally more open world. But the conundrums that come along with such aspirations now require much more thinking from the rest of us—from both academic study but also the harsh lessons of practice.

Defining whether and how those who achieve excellence will be differentially entitled or rewarded: This question, which follows directly from the above issue, moves from understanding what excellence is to agreeing who deserves to benefit from it. In short, it's a question of organizational governance. And as I've framed it here, it's a question of a governance model often called "meritocracy" (meaning those with the greatest knowledge, skills and accomplishment should be recognized by a society's people as most worthy to lead, and also to bear the greatest burdens of ensuring the greater good for all). Today, however, meritocracy is a term fraught and contested, particularly among those who criticize its associated systems of excessive credentialism (status conferred by educational degrees, not objective performance), and concerns that reliance on judgment by excellence unfairly discounts the social scaffolding that helps some people more than others achieve success. Others simply argue that meritocracy undermines the dignity and equality upon which democratic governance models depend. Such controversies do not directly relate to social and economic strategies for pursuing openness, but they will ultimately be pulled into efforts aimed at intentionally creating it. Similarly, like questions of boundaries and membership, societal concepts of what makes excellence and how merit should be judged will require ongoing adjustment and revision, as the entity grows larger and more complex (which performance success tends to drive).

When and how to modify any community's state of "openness" when required: The history of democratic (or generally "open" communities or nations) is filled with examples when their peoples decide that openness must be reduced or curtailed—sometimes temporarily, sometimes more enduringly. Ancient Athens became steadily more elitist—less open—about its citizenship during the "Golden Age." Ancient Romans, during the period of their Republic, enacted a law to allow temporary suspensions of freedoms and the appointment of a dictator in times of grave emergency, a measure abused by Julius Caesar when he made himself a more permanent king. But during Rome’s later imperial age, despite the overall autocratic rule, social mobility and commercial relationships became steadily more open. Modern American democracy has witnessed periods of welcoming immigration and open trade and others of exclusionary practices and high tariffs. Openness inevitably becomes a moving target, as populations, external events, and social beliefs change. How should future open-seeking societies and nations govern a process that can never stand still?

It is the great value of Norberg’s book that it can inspire and raise hope for a generally more open world. But the conundrums that come along with such aspirations now require much more thinking from the rest of us—from both academic study but also the harsh lessons of practice.

A more open world isn't inevitable. Building one will take work—and it raises complex questions like these.

Image by:

Opensource.com

The Open Organization Read the series Open exchange, open doors, open minds: A recipe for global progress Making the case for openness as the engine of human progress This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

What Git aliases are in your .bashrc? AmyJune Hineline Tue, 04/05/2022 - 03:00 Up Register or Login to like.

Many open source users love a good Bash alias and are usually happy to show off a particularly robust .bashrc file when given the chance. If you're a frequent user of Git, you might benefit from a few Git aliases mixed in with your other Bash aliases. Alternately, you can create aliases specific to Git with this git config command. This example sets the git co command to git checkout.

$ git config --global alias.co checkout

I asked our contributors for their favorite and most useful Git aliases so that you could take advantage of their ideas. Here are their suggestions.

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Aliases

Here's an easy way to see just the most recent log entry:

git config alias.last 'log -1 HEAD'

Opensource.com author Sachin Patil uses hist for reviewing logs:

log --pretty=format:'%h %ai [%an] %s%d' --graph

Sachin creates this Bash alias for pull requests:

# github pull request. 
# Usage: git pr

pr="\!sh -c 'git fetch $1 pull/$2/head:$3 && git checkout $3' -"

The git diff command is helpful for all kinds of comparisons, but sometimes all you really want is the file name of what's changed. Kristen Pol creates an alias to shorten the --name-only option:

git diff --name-only

Kristen says, "We typically have a lot of development happening simultaneously, so knowing the most recent commit across all branches is handy." Here's a command Kristen aliases for that purpose:

git branch --remotes --verbose --sort=-committerdate

Everybody appreciates a fresh start. This is Kristen's alias for wiping out a branch, leaving it fresh and clean:

alias gitsuperclean='git reset --hard; git clean --force -d -x'Custom filter-repo command

Chris has been using a "third-party" Git command called git-filter-repo.

Chris explains the alias. "Ever want to pull a specific directory out of a larger Git repository and make it its own, separate repo, while keeping all the Git history? That's exactly what filter-repo does."

Your aliases

What Git command do you use so often that you alias it? Do you use Bash aliases or Git aliases, or a mix of both? Tell us in the comments!

I asked our contributors for their favorite and most useful Git aliases so that you could take advantage of their ideas.

Image by:

kris krüg

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

My guide to understanding Git rebase -i Vaishnavi R Tue, 04/05/2022 - 03:00 Up Register or Login to like.

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. It is an essential tool in an open source developer's toolkit.

This article covers why and how to use the git rebase --interactive (-i for short) command. This is considered an intermediate Git command, but it can be very useful once you start working with large teams.

This command is one of the most powerful in Git. The git rebase command helps you manage multiple commits, including:

• Flatten (or squash in Git terminology) several commits so that they look like they were all done at once
• Delete one of the commits
• Split one commit into two
• Reorder the commits

Yes, the git rebase command can rewrite your repository's commit history by rearranging, modifying, and even deleting commits. So let's get started!

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Helpful instructions in the rebase message

The git rebase -i interface is, as its long form --interactive flag implies, an interactive interface. It provides a list of commits, and then you choose what actions you want Git to take on each of them. Taking no action is a valid choice, but at least one commit must be marked as the one to squash, or the rebase is functionally meaningless.

• p, pick — Pick this commit to keep.
• e, edit — Edit this commit to amend the commit message.
• r, reword — Use this commit, but also edit it.
• s, squash — Squash this commit into a previous commit. When performing a git rebase -i, you must have at least one commit marked as squash.
• d, drop — Delete this commit.

Squashing commits

Suppose you have two commits, and you want to squash them into one. This is achieved by using git rebase -i HEAD~2 (that's two commits from your current position) command and by putting the word squash before the commit.

$ git rebase --interactive HEAD~2

Running this command gives you a list of commits in your text editor that looks something like this:

pick 718710d Commit1.
pick d66e267 Commit2.

If you want to make a single commit from two commits, then you have to modify the script to look this:

pick 718710d Commit1.
squash d66e267 Commit2.

Finally, save and exit the editor. After that, Git applies all the changes and opens an editor to merge the two commits:

# This is a combination of 2 commits.
# This is the 1st commit message:

Fuse smoke test versioning.

# This is the commit message #2:

Updated the code.

# Please enter the commit message for your changes.

Saving this results a single commit that introduces the changes of two previous commits.

Reordering commits

Suppose you have three commits, and you want to change their order such that Commit3 is first, Commit2 is second, and then third is Commit1. Run git rebase -i HEAD~3 to make this happen:

$ git rebase --interactive HEAD~3

This script is opened in your editor:

pick 8cfd1c4 Commit1
pick 718710d Commit2
pick d77e267 Commit3

Modify the script like this:

pick d77e267 Commit3
pick 718710d Commit2
pick 8cfd1c4 Commit1

When you save and exit the editor, Git rewinds your branch to the parent of these commits, and applies d77e267, then 718710d, and then 8cfd1c4 as the commit numbers are not matching.

Delete a commit

Suppose you have two commits and want to get rid of the second one. You can delete it using the git rebase -i script.

$ git rebase -i HEAD~2

This script is opened in your editor:

pick 8cfd1c4 Commit1
pick 718710d Commit2

Place the word drop before the commit you want to delete, or you can just delete that line from the rebase script.

pick 8cfd1c4 Commit1
drop 718710d Commit2

Then save and exit the editor. Git applies the changes and deletes that commit.

This can cause merge conflicts if you have many commits later in the sequence that depend on the one you just deleted, so use it carefully. But you have an option to revert the changes.

Rebase with caution

If you get partway through a rebase and decide it's not a good idea, use the git rebase --abort command to revert all the changes you did. If you have finished a rebase and decide it's wrong or not what you want, you can use git reflog to recover an earlier version of your branch.

Rebasing is powerful and can be useful to keep your repo organized and your history clean. Some developers like to rebase the main branch so that the commits tell a clear story of development, while others prefer for all commits to be preserved exactly as they were proposed for merging from other branches. As long as you think through what your repo needs and how a rebase might affect it, the git rebase command and the git rebase -i interface are useful commands.

The git rebase command is one of the most powerful in Git. It can rewrite your repository's commit history by rearranging, modifying, and even deleting commits.

Image by:

Image from Unsplash.com, Creative Commons Zero 

Git What to read next How to reset, revert, and return to previous states in Git This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

The post Installation and Review of Q4OS Linux [Lightweight Distro] first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

Q4OS is a new Linux distribution that’s based on Debian; a common base that’s shared with other distributions like Ubuntu and Linux Mint. It’s aimed at users who just want a simple, stable, easy

The post Installation and Review of Q4OS Linux [Lightweight Distro] first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

Installation of OCI CLI on WSL [Windows Subsystem for Linux] in Windows 10 or above  hackernoon.com

Formed last year was the CentOS Hyperscale SIG for back-porting major package versions and other features back to CentOS and other interesting features for modern enterprise environments...

CentOS Hyperscale SIG Updates systemd & Linux Build, Eyeing Btrfs Transactional Updates  Phoronix

GNOME developer Chris Davis has laid out plans for at least some of the work items he and other open-source developers hope to accomplish for GNOME 43 and future releases...

Penetration Testing Software Market Size, Growth And Forecast | Leading Players – Netsparker, Acunetix, Core Impact, Metasploit, Wireshark, w3af, Kali Linux, Nessus, Burpsuite, Cain & Abel – FortBendNow  FortBendNow

Maui Shell Alpha released (convergent desktop environment for Linux phones and PCs)  Liliputing

1. How to install Ubuntu Linux (It's easy!)  ZDNet
2. Linux Release Roundup #22.14: Ubuntu 22.04 Beta, Nitrux 2.1, Lutris 0.5.10, and More Releases  It's FOSS News
3. Ubuntu 22.04 LTS Beta Released with GNOME 42 Desktop, Linux Kernel 5.15 LTS  9to5Linux
4. Install and setup Plex Media Server on Ubuntu 22.04 LTS  Linux Shout
5. Ubuntu Linux 22.04 'Jammy Jellyfish' Beta now available for download  BetaNews
6. View Full Coverage on Google News

How to install Ubuntu Linux (It's easy!)  ZDNet

How to install Ubuntu Linux (It's easy!)  ZDNet

Dirty Pipe: What you need to know about the major exploit affecting Pixel 6 and Galaxy S22 devices [Updated]  9to5Google

Microsoft Edge 100 Rolls Out for Windows, macOS, and Linux › Edge 100 Update Closes 25 Safety Holes  Tech Gaming Report

How to Install the WSL 2 on Windows 10  BollyInside

When it comes to system recovery on Linux, users are most often only left with a command-line for trying to recover from a failed kernel boot, borked boot loader configuration, or other show-stopping problems. With Fedora Workstation right now they have only their CLI-based Linux recovery process but are eyeing the possibility of creating a complementary GUI-based recovery environment...

Fedora Workstation Brainstorming A Possible GUI-Based Linux Recovery Environment  Phoronix

“Here’s a question from the new guy”. I have been using this a lot the past few weeks after starting here at the Linux Foundation as the lead editor and content manager. How long can I pull that off? 

The reality is that I am new to working professionally in open source software – and really the software/technology industry. But, it has been a long time passion of mine. I spent my formative years in the 1980s and had a drive to learn to program computers. When I was 12, I asked my mom for a computer. Her response, “you have to learn to type first”. 

I went to the library, checked out typing books, and taught myself on our electronic typewriter. We couldn’t afford a computer, but I received a hand-me-down TI-994A and then a Commodore 64 with a tape drive. I taught myself BASIC and also dialed into bulletin board systems (BBS) at a mind-blowing 300bps. If you have never experienced 300bps, imagine yourself reading at 10% of your normal pace. 

I mention BBSs because, in many ways, they were the precursor to open source software. Someone dedicated their PC and a phone line for others to dial in, share messages, exchange software, answer technical questions, etc. 

Fast forward a bit – I taught myself to code enough to get a couple of coding jobs in high school but ended up getting a business degree in college and then working in politics for 15+ years. My passion for software and technology didn’t lapse, but it was mostly a tech hobbyist – taking classes in front-end web development and writing a couple basic web apps, teaching myself some PHP, Python and WordPress development, and reading/writing about software development. And, for the record, I already had a GitHub repo before starting here. 

With that bit of background, let me say that I am very excited about working at the Linux Foundation and diving into the open source community. I am a self-driven, life-long learner, and I want to take you along my journey here to learn about what we do, all of our projects, what open source is, how to advance it, and more. 

At LF, we embrace what we call the three H’s: humble, helpful, and hopeful. It isn’t just lip service. I see it lived out every day, in every interaction I have with my coworkers. My goal with this journey is to be: 

• Humble: There is so much I don’t know about the open source community and the LF. I am learning every day. 
• Helpful: I want to be helpful by sharing what I am learning. Much you may already know, but some you may not.
• Hopeful: My hope is two-fold: I hope others learn too; I am hopeful that our community will continue to grow and thrive and solve some of the world’s toughest challenges. 

The three H’s are perfectly aligned with the general culture of open source. One of the LF’s onboarding tasks for new employees is to take a class entitled Open Source 101. Within that class they teach us Ten Open Source Culture Cores: 

1. Be open. Openness breeds authenticity. Be consistently authentic in all of your work. 
2. Be pragmatic. Action > talk. Work towards measurable value, not obscure, abstract, or irrelevant ideas. (Side note: when I worked in politics, my go-to line when speaking to groups was that I was a bit of an anomaly in Washington, I was long on action and short of talk.) 
3. Be personal. Always focus on a personal level of service and interaction. People don’t join open source communities to talk to computers. 
4. Be positive. Highly positive environments generate positive engagement.
5. Be collaborative. Involve people, gather their feedback, get a gut check, and validate your ideas. The only problem silos solve is how to store grain. 
6. Be a leader. Be open and collaborative–focus on the other 9 Culture Cores too. 
7. Be a role model. Be the person you want to be and you will be the leader other people want you to be. 
8. Be empathetic. Don’t just be empathetic in the privacy of your own mind. Say it, demonstrate it visibly. This all builds trust. Empathy is a powerful driver for building inclusion, which is a powerful driver for innovation.
9. Be down-to-earth. Leave your ego at the door. 
10. Be imperfect. We all make mistakes. Acknowledge them, share them, and learn from them. 

What a great synopsis of the culture of open source technology. 

With that, let me close out this week by first stating the obvious – a lot has transpired in technology since my first TI-994A (never mind the fact that my network speed is literally one million times faster). I hope you will join me on my “Questions from the New Guy” journey. Look for weekly-ish blog posts diving into all aspects of The Linux Foundation, our projects, and open source technology. 

The post Question from the New Guy! appeared first on Linux Foundation.