Open-source News

Linux and Ty Sunderland Host Y2Rave: Reloaded for NYE  Papermag

I'm now officially converted to the RGB LED religion and OpenRGB ...  GamingOnLinux

Linux Fu: Miller The Killer Makes CSV No Pest  Hackaday

Steam Deck hits over 7000 games either Verified or Playable  GamingOnLinux

Linux 6.2's Call Depth Tracking Helps Recover Lost Performance On Intel Skylake CPUs  Phoronix

When the Retbleed security vulnerability was introduced earlier this year mitigating it for Intel Skylake and Skylake-derived CPU cores required imposing Indirect Branch Restricted Speculation (IBRS) that further tanked the out-of-the-box performance for these aging Intel CPUs. But being introduced now with Linux 6.2 is a new mitigation technique named Call Depth Tracking that is helping recover some of that lost performance and in turn extending the usefulness of the Skylake-derived processors still in service.

Red Hat lowers barriers to hybrid cloud adoption with expanded public offerings in AWS marketplace  ZAWYA

The Steam Deck really doesn't need exclusives  GamingOnLinux

The Steam Deck really doesn't need exclusives  GamingOnLinux

With the end of the year upon us, it's interesting and fun running GitStats on various prominent open-source projects and looking at some of the key growth metrics over the past year. Here is a look at how systemd's Git activity has paced in 2022 compared to years prior...

Steam Deck OS 3.4 Update Fixes Stuttering Games After Waking ...  DualShockers

LLVM's GPU/device offloading support continues to advance and this open-source compiler stack has now added basic JIT (Just In Time) compilation support to its OpenMP offloading capabilities...

Following yesterday's article looking at the performance of Intel's Clear Linux running on AMD EPYC 4th Gen "Genoa" with great performance results even though Clear's kernel was limited to 320 of the 384 available logical CPU cores for the EPYC 9654 2P setup, the kernel has now been adjusted to handle up to 512 CPUs...

Clear Linux Will Now Handle Up To 512 CPU Cores / vCPUs  Phoronix

11 tips for writing a good Git commit message AmyJune Wed, 12/28/2022 - 03:00

Lately, I have been paying closer attention to the changelogs I get from products and services when updates are needed. Here are some examples:

• Fixed some bugs. 
• Made some accessibility improvements. 
• We've made improvements and fixed bugs for a smoother ride.

When I think about some of the first commit messages I made as a junior developer I have to hang my head in dismay:

• Pointed and clicked around a bit and now things seem to work.
• Did what programmer X told me to do and now the banner is blue.

This can be frustrating! I asked our community of contributors the following questions:

• What makes a good Git commit message?
• What makes a bad one?
• What rules do you think a project should have around what a commit message contains?

Here are their answers:

Great writing is key

As with anything you write, you should think about who is going to read it. Then adapt the amount and depth of information accordingly.

Improving your natural language and writing skills is essential for a healthy career in software development. It's not just code that counts.

—Camilla Conte

Be descriptive and don't assume

I spend a lot of my time collaborating in the OpenStack community, and its code reviewers have some fairly exacting standards compared to what I see from other projects "in the wild."

I'll often spend far longer composing a solid commit message than I do writing the actual code implementation or fix. Sometimes commit messages can end up many times longer than the diffs they're explaining.

To summarize some of the contributor guidance:

• Describe why a change is being made, not just what is changing
• The first commit line is the most important (like the subject line of an email)
• Don't assume reviewers understand the original problem you're fixing
• Don't assume the reviewer has access to external web services or the site (summarize defect reports and other relevant discussions)
• Don't assume the code is self-evident and self-documenting (though there is no need to repeat points you also make in your code comments)
• Don't include information only relevant to earlier revisions of the change (we expect contributors to squash revisions together and edit their commit messages accordingly).

There's a brief section on the topic in the OpenStack Contributors Guide: https://docs.openstack.org/contributors/common/git.html#commit-messages

—Jeremy Stanley

Your future self will thank you

I cannot agree more with Jeremy. +1000

Jeremy said, "describe why a change is being made, not just what's changing."

Imagine you're someone else, in a faraway future, trying to work out this commit.

Put yourself in other people's shoes, as the old saying goes.

—Leigh Morresi

Use the bug ID

I recommend adding the bug ID at the start of the commit message so that it's easier to track the commits at a later stage using the grep command.

For example:

$ git commit -m "BZ#19xxxxx

To come up with thoughtful commits, consider the following:

• Why have I made these changes?
• What effect have my changes made?
• Why was the change needed?
• What are the changes in reference to?

—Agil Antony

Tell the whole story

I like to imagine there is a hidden prefix to every commit message that reads "By applying this."

A good commit message includes exactly what will happen and why. It is insufficient to merely have the work ticket reference because that decentralizes the information; Git is decentralized. As a software developer, I want to know why the proposed changes are being considered. What specific problem is being addressed? What alternate solutions were considered (and discarded)? What unexpected things were discovered during the creation of the changeset that influenced the current content?

There's no prize for shortest commit message. Your future self and future colleagues will appreciate you going into depth to explain the problem and why this changeset is the answer. Harness those cooking blogs where there's a five-paragraph life story. Here, however, make the problem the subject of the life story.

—Lisa Seelye

But don't be overly verbose

A good git commit message contains information about what was done, and nothing else. For instance, if you needed to update the .gitignore, just say "updated .gitignore." Folks can dive into the commit itself for more details. It doesn't need to be verbose.

A bad commit message is something like, "oh crap" or "try this". Granted, I've been guilty of this, but it doesn't help anyone if they need to look at commits at a glance.

Rules are very subjective. They can differ from lead to lead and team to team. But at the very least, give some contextual information about the commit. Especially if it's a large one. No one has time to skim through 1000+ files with a heavy change history.

—Miriam Goldman

Use present tense

I like project manager-styled commit messages written in present and not future terms (for example, "add" instead of "added"). However, it's usually only possible if commits are frequent. There's only so much "how did I do it" you can remember when you're faced with a deadline. Yet, well-written commits not only help collaborators, but are also helpful to the committer in recollecting history.

—Chris Okpada

Don't rely on links

One thing I like to remind colleagues of is that you're not just explaining to the people who are going to decide whether to approve your commit. You're also explaining to future developers and users who have found this commit in a bisect or blame operation and are trying to understand its relevance.

If the only context supplied is a link to some external system, and that far in the future the system it links to is no longer in use or has otherwise become inaccessible to that individual, your commit message has been rendered useless and may just as well be blank.

All too often, I go digging in the Git history of some open source project, and find commit messages which are nothing more than a bug ID or a link to some company's internal and private defect tracker.

Don't be that project!

—Jeremy Stanley

Clear and concise changelogs

As a release communications manager, I often read the entire release board. I also met with developers to discuss any areas that weren't clear yet. Then I tested the release early. After that, I would write a release post by sourcing the changelogs and corresponding revised or new content.

The changelogs are personal reminders for developers, but also have corresponding issues and tickets for them. You should capitalize product names appropriately, use a spell checker, be consistent with punctuation, and sentence structure. The lead developer should proofread these as well. Your customers, that are developers, are reading these. What information should they know before running the update to better serve their customers?

—Courtney Robertson

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Be specific

As a frequent release manager, I like messages that name the component a commit touches, and a brief description of what was changed. Also having a reference back to where the request for this work came from helps to tie fixes together long after we forgot about your clever branch name.

• "fix fatal error" is not ideal.
• "ISS-304: Fix fatal error in Login Access Control function for users
  with the Partner role" is better.
• "ISS-304: Login Access Control: fix fatal error in getPartnerId()" is
  better still.

I can look at the entire relationship between a Git commit, branch, merge commit, and inspect the individual lines and files that were changed. But I don't have that kind of time in the middle of a release. I want to be able to relate back to the source of this work in the project management tool, have some idea of which components are being changed, and in what way.

—Ryan Price

Make it a habit

My favorite commit that I'm guilty of is, "commit before I switch branches" because I have to work on something else more urgent. Sometimes, I need to commit my current work to a totally different project. My manager's strategy is to have us work as we normally do. But then when we rebase, he wants us to squash commits where it makes sense and write better messages. I can't say we always do this, but his method does make sense.

I have a lot of "this is broken don't know why" type messages too (haha) where I try things but want to commit that attempt before I try something else in case method A was closer to fixing the issue than method B. Writing code is a hot mess. And I've been writing it for over 10 years.

—RachieVee

What commit message advice or tips do you live by? Let us know in the comments.

I asked our community of open source practitioners to share their advice for writing helpful Git commit messages.

Image by:

CC BY 3.0 US Mapbox Uncharted ERG

Opensource.com community Git What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. 49 points Milan, Italy

I'm a Software Engineer at Red Hat, working on CI/CD and Automation with cloud-native open-source technologies.

Open Enthusiast Author 232 points Kill Devil Hills, NC, USA

A long-time computer hobbyist and technology generalist, Jeremy Stanley has worked as a Unix and GNU/Linux sysadmin for nearly three decades focusing on information security, Internet services, and data center automation. He’s a root administrator for the OpenDev Collaboratory, a maintainer of the Zuul project, and serves on the OpenStack vulnerability management team. Living on a small island in the Atlantic, in his spare time he writes free software, hacks on open hardware projects and embedded platforms, restores old video game systems, and enjoys articles on math theory and cosmology.

Open Minded People's Choice Award Author 149 points India

I have more than 5 years of experience as a technical writer that specialises in producing accurate, clear, and concise documentation for software products. I have the ability to communicate technical ideas to a variety of audiences, including developers, engineers, and end users. Skilled in using a range of authoring tools, project management applications, and content management systems to produce and maintain technical documentation.

In addition to my technical proficiency, I also possess good interpersonal and communication abilities, which enable me to effectively engage with subject matter experts as well as cross-functional teams. Exceptionally organised and detail-oriented, with a passion for writing excellent documentation that aids users in comprehending and utilising sophisticated software products.

Open Minded Author Contributor Club 77 points Ottawa, Ontario, Canada

Miriam is a technical lead on the WordPress team at Kanopi Studios. She is a full-stack developer, leaning more toward the back end. She loves problem-solving, diving deep into plugin development, and mentoring junior developers.

Miriam is also heavily involved in the WordPress community, speaking and organizing WordCamps and local Ottawa meetups.

Open Enthusiast Contributor Club 62 points

Leigh is a long time open-source enthusiast, started nerding out with Linux kernel 2.0 and dial-up bulletin boards, can often be found hacking on useful code as well as being a product owner and entrepreneur.

Enjoys creating software that is used by people to solve real problems.

Always time for interesting and inspiring projects, feel free to each out - dgtlmoon@gmail.com

| Connect leighmorresi Open Enthusiast Author 16 points Community Member 31 points Chambersburg, PA

Courtney is a Web Designer and Developer Advocate, WordPress Training Team co-rep, and sponsored by GoDaddy Pro. Courtney has instructed WordPress and web development in career-technical high-schools, front-end bootcamps, and adult education. She began using open source in 1999 and contributing to WordPress in 2009.

| Follow courtneyr_dev | Connect courtneyr-dev Open Enthusiast 46 points Portland, OR

Drupal, woodworking, podcasting, community building, photowalking, coworking, beer, hugs, gardening, eating local.

Solutions Consultant for FFW.

Podcast Co-host for DrupalEasy Podcast.

Serial mentor. Meetup organizer. Conference volunteer/organizer.

| Follow liberatr Open Enthusiast DevOps Drupal Maker PHP Web developer Community Manager 31 points

I’m a WordPress developer who has a keen interest in accessibility. #a11y I’m also a technical writer and I share my WordPress and coding experiences on my blog.

| Follow rachelrvasquez Open Enthusiast 115 points

Lisa is a long time Linux user, former Gentoo developer (2003-2007). She is a lifelong gamer, which lead her to spend time in the video game industry and write one of the early API libraries for Eve Online (a video game involving the serious business of Internet space ships). Melding her experience as a long-time Linux systems administrator with software development experience, she is a Senior Site Reliability Engineer at Red Hat, focusing her time on OpenShift Dedicated (a hosted Kubernetes offering).

When not playing video games or tending the needs of her tuxedo cat Clyde, Lisa might be found playing Magic: the Gathering or tinkering with her ARM64 pet Kubernetes cluster, more of which can be read at https://lisa.dev.

| Follow thedoh Open Minded DevOps Cloud Gamer Linux Maker SysAdmin Developer Docker Author Contributor Club Register or Login to post a comment.

5 open source ideas for being more inclusive through accessibility AmyJune Wed, 12/28/2022 - 03:00

As the internet opens the planet into a world stage, inclusion should be at the forefront of how we design, build, and implement our ideas. With 15% of people self-identifying as disabled worldwide, that is far too many people to leave behind due to lack of accessibility. This includes permanent, temporary, episodic, and situational disabilities.

In 2022, we published some great articles about making digital assets more accessible. Here are a few of the top picks.

Accessibility settings in open source tools

In How I use Linux accessibility settings, Don Watkins outlines a few ways different Linux distros support settings for vision, hearing, and typing. There are also links to Linux distributions that meet some specific needs of users.

Another article by Don Watkins, 5 ways LibreOffice supports accessibility, reviews a few accessibility features in LibreOffice that increase usability for everyone. Included in the article are common shortcuts you can learn and how to use the tools without a mouse. There is also a section that outlines more accessibility settings using the tool menu.

Open source screenreaders and voice to text

DeepSpeech is a voice-to-text command and library for developers who want to add voice input to their applications. It can also benefit people who live with low vision, limited mobility, and situational disabilities that keep their hands busy. Use Mozilla DeepSpeech to enable speech to text in your application by Seth Kenlon goes into how to download and install this tool. It also gives some pragmatic examples of how the tool can be used.

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

Use this open source screen reader on Windows really goes into detail about how to use the NVDA screen reader. Peter Cheer moves from why he likes this particular screen reader to how to install the software. Because NVDA is free and open source, it is an excellent tool for testing website accessibility once you have full command of how a native user might use it.

Vojtech Polasek is a blind software engineer focusing on computer security and accessibility for blind users. In his article, Remixing Linux for blind and visually impaired users, Vojtech writes about his challenges accessing digital assets and outlines his assistive technology stack. Since he is a Linux user, he set out with his team to develop the Vojtux project, a remix of Fedora that increases usability for visually impaired and blind users.

Accessibility for the future

It is amazing how far along technology has come over the years to provide software that allows for equal accessibility. One can only hope that tech will continue improving in this direction. Keep an eye out for more articles about this very topic on Opensource.com!

Open source tools and principles pave the way for improved accessibility in technology.

Image by:

Opensource.com

Best of Opensource.com Accessibility Diversity and inclusion 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.

Linux on MicroBlaze: ArtyA7 Linux Design in PetaLinux 2022.1  Hackster.io

DietPi Releases 8.12 With Support For The Rockchip RK3588 SoC  Hackaday

Updated patches were sent out today that aim to reduce the maximum memory usage while compiling the Linux kernel. In turn for memory constrained systems that attempt to compile the kernel this should lead to less swapping and faster build times...

New Patches Aim To Reduce Memory Use While Compiling The ...  Phoronix