Open-source News

More Meteor Lake Enablement Readied For Intel Graphics Driver With Linux 6.1  Phoronix

Earlier this month I wrote about AMD working on s2idle fixes for some AMD Ryzen 6000 series "Rembrandt" laptops. At the time it was just for select ASUS laptops known to have a bug in the firmware resulting in suspend-to-idle issues while now additional models not only from ASUS but also Lenovo have been uncovered...

More AMD Ryzen Laptops See Suspend-To-Idle Fix  Phoronix

How to install Parrot OS 5 Home Edition  AddictiveTips

Chinese hardware vendor Loongson Technology continues working on the LoongArch code for the Linux kernel for their in-house CPU ISA derived from MIPS64. Now that the initial code has been mainlined since 5.19 and some of the necessary other critical bits of code are getting squared away, recently they have been working on other missing functionality for supporting their initial LoongArch-based Loongson 3A5000 series SoCs...

Loongson Preparing Linux For LoongArch Laptops  Phoronix

Adding to the growing examples and early drivers being worked on for the Linux kernel to showcase the possibilities of using the Rust programming language within the kernel, an early port of Intel's e1000 wired networking driver has started...

Rust Porting Begins For Intel's "e1000" Linux Network Driver  Phoronix

Shouldn't Linux Foundation be Officially Present in India?  Analytics India Magazine

Top 10 popular Linux Distros in September 2022 - Linux Shout  Linux Shout

Linus Torvalds: Rust will go into Linux 6.1  ZDNet

Linus Torvalds: Rust will go into Linux 6.1  ZDNet

Linus Torvalds: Rust Will Go Into Linux 6.1 - Slashdot  Slashdot

I got my first pull request merged! Oluwaseun Mon, 09/19/2022 - 03:00

Words cannot express my joy when I got the notification about the merge below, and I owe it to my current engineering school, AltSchool Africa.

Image by:

(Awosise Oluwaseun, CC BY-SA 4.0)

Before this, I had been introduced to open source many times, told about its importance in the tech space, and even attended open source conferences (e.g., OSCAFest). I had all the instant excitement to start, but imposter syndrome set in on opening GitHub to create something.

Fast forward to Monday, the 8th of August, 2022, when I watched Bolaji's video on contributing to open source. I felt pumped again, but I wanted to apply what I learned, so I noted some steps.

The steps:

1. I made up my mind I was going to contribute to a project.
2. I was focused on a site (good first issue) to pick my first project from, which I filtered to suit my skill level. I kept opening the next page till I found one.
3. I made sure I was equipped with the required Git and GitHub knowledge to complete the project.

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 The project

After long hours searching for projects, I finally found one titled, Ensure no missing alt attributes. I was to give descriptive alt values to images from the site. Alt values in images help to improve the accessibility of the site such that screen readers can provide a detailed description of the image to, say, a visually impaired person. Easy right? Yes, but if I didn't make up my mind to get the first contribution, I wouldn't find it, and open source would continue to be a myth to me.

I was still pumped until I discovered it was from MDN. Wait, MDN? As in Mozilla developer? Will they merge my contribution even with how seemingly easy it looks? Imposter syndrome set in.

Upon checking the issue, I saw that people were already contributing. I summoned my courage and started reading about it. Taking my time to read and understand the project and how I needed to approach the issue was another challenge I had to overcome.

The project is as easy as you try to understand it.

So, I picked two images to begin with. I gave alt values to them, committed my changes, then made a pull request. The time between when I made the pull request and when I got the approval mail was full of self-doubts. Should I close the pull request? This is MDN. Well, it's not coding... What if I don't get merged? I might never contribute again. All it took to clear all of the doubts were the emails I got from my reviewer below:

Image by:

(Awosise Oluwaseun, CC BY-SA 4.0)

Image by:

(Awosise Oluwaseun, CC BY-SA 4.0)

Image by:

(Awosise Oluwaseun, CC BY-SA 4.0)

I was indeed delighted, and this inspired me to check for more. It gave me the courage I needed to request additional issues to solve.

Image by:

(Awosise Oluwaseun, CC BY-SA 4.0)

Summary

A few lessons I'd love you to take home from this article are:

• Open source is for all. Do you see that typo on that site you just visited? You helping to correct it is a way of contributing.
• No skillset is too small. A basic understanding of HTML was what I needed to contribute.
• Only you can stop yourself from contributing.
• The first contribution is all you need to get the ball rolling.

I hope you have been able to pick something from my story and apply it today. This is another space I'd like to keep contributing to, so see you in my next article, and happy open sourcing!

This article originally appeared on I got my first Pull Request merged! and is republished with permission.

Experience the joy that contributing to open source brings.

Image by:

Photo by Rob Tiller, CC BY-SA 4.0

Community management What to read next My first contribution to open source: Making a decision New open source tool catalogs African language resources This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

PyLint: The good, the bad, and the ugly Moshe Zadka Mon, 09/19/2022 - 03:00

Hot take: PyLint is actually good!

"PyLint can save your life" is an exaggeration, but not as much as you might think! PyLint can keep you from really really hard to find and complicated bugs. At worst, it can save you the time of a test run. At best, it can help you avoid complicated production mistakes.

The good

I'm embarrassed to say how common this can be. Naming tests is perpetually weird: Nothing cares about the name, and there's often not a natural name to be found. For instance, look at this code:

def test_add_small():
    # Math, am I right?
    assert 1 + 1 == 3
   
def test_add_large():
    assert 5 + 6 == 11
   
def test_add_small():
    assert 1 + 10 == 11

The test works:

collected 2 items                                                                        
test.py ..
2 passed

More Python resources What is an IDE? Cheat sheet: Python 3.7 for beginners Top Python GUI frameworks Download: 7 essential PyPI libraries Red Hat Developers Latest Python articles But here's the kicker: If you override a name, the testing infrastructure happily skips over the test!

In reality, these files can be hundreds of lines long, and the person adding the new test might not be aware of all the names. Unless someone is looking at test output carefully, everything looks fine.

Worst of all, the addition of the overriding test, the breakage of the overridden test, and the problem that results in prod might be separated by days, months, or even years.

PyLint finds it

But like a good friend, PyLint is there for you.

test.py:8:0: E0102: function already defined line 1
     (function-redefined)The bad

Like a 90s sitcom, the more you get into PyLint, the more it becomes problematic. This is completely reasonable code for an inventory modeling program:

"""Inventory abstractions"""

import attrs

@attrs.define
class Laptop:
    """A laptop"""
    ident: str
    cpu: str

It seems that PyLint has opinions (probably formed in the 90s) and is not afraid to state them as facts:

$ pylint laptop.py | sed -n '/^laptop/s/[^ ]*: //p'
R0903: Too few public methods (0/2) (too-few-public-methods)The ugly

Ever wanted to add your own unvetted opinion to a tool used by millions? PyLint has 12 million monthly downloads.

"People will just disable the whole check if it's too picky." —PyLint issue 6987, July 3rd, 2022

The attitude it takes towards adding a test with potentially many false positives is..."eh."

Making it work for you

PyLint is fine, but you need to interact with it carefully. Here are the three things I recommend to make PyLint work for you.

1. Pin it

Pin the PyLint version you use to avoid any surprises!

In your .toml file:

[project.optional-dependencies]
pylint = ["pylint"]

In your code:

from unittest import mock

This corresponds with code like this:

# noxfile.py
...
@nox.session(python=VERSIONS[-1])
def refresh_deps(session):
    """Refresh the requirements-*.txt files"""
    session.install("pip-tools")
    for deps in [..., "pylint"]:
        session.run(
            "pip-compile",
            "--extra",
            deps,
            "pyproject.toml",
            "--output-file",
            f"requirements-{deps}.txt",
        )2. Default deny

Disable all checks. Then enable ones that you think have a high value-to-false-positive ratio. (Not just false-negative-to-false-positive ratio!)

# noxfile.py
...
@nox.session(python="3.10")
def lint(session):
    files = ["src/", "noxfile.py"]
    session.install("-r", "requirements-pylint.txt")
    session.install("-e", ".")
    session.run(
        "pylint",
        "--disable=all",
        *(f"--enable={checker}" for checker in checkers)
        "src",
    )3. Checkers

These are some of the ones I like. Enforce consistency in the project, avoid some obvious mistakes.

checkers = [
    "missing-class-docstring",
    "missing-function-docstring",
    "missing-module-docstring",
    "function-redefined",
]Using PyLint

You can take just the good parts of PyLint. Run it in CI to keep consistency, and use the highest value checkers.

Lose the bad parts: Default deny checkers.

Avoid the ugly parts: Pin the version to avoid surprises.

Get the most out of PyLint.

Image by:

Opensource.com

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

The post 10 Most Dangerous Commands – You Should Never Execute on Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

The command-line interface is a powerful and handy utility for administering a Linux system. It provides a fast and versatile way of running the system, especially when managing headless systems which do not have

The post 10 Most Dangerous Commands – You Should Never Execute on Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

How to Record Audio in Linux With Audacity and Reduce Noise  BollyInside

The Association of Support Professionals (ASP) announced the Red Hat Customer Portal as a winner of the Best Support Websites of 2022 for the 12th consecutive year. Our Customer Portal delivers comprehensive product documentation, intelligent troubleshooting tools, security updates, technical support, as well as Red Hat expert and community-powered knowledge—helping customers plan, deploy, maintain and manage their Red Hat solutions. 

Linus Torvalds just released Linux 6.0-rc6 and it's artificially tiny due to many of the kernel developers being preoccupied for the week...

Linux 6.0-rc6 Released After Kernel Developers Spent The Week In Dublin  Phoronix