Open-source News

Mesa's AGX "Asahi" Gallium3D driver for providing OpenGL / GLES support on Apple M1/M2 SoCs has begun making some early preparatory changes for eventually supporting the in-development DRM/KMS kernel driver. The kernel driver is still a work-in-progress and not close to being merged yet and the user-space API not yet set in stone, but some early changes in better preparing the Mesa driver for actually running on the Apple Silicon hardware under Linux have been merged...

Red Hat introduces latest versions of its enterprise Linux  IT Brief New Zealand

This week's batch of platform-drivers-x86 "fixes" for the ongoing Linux 6.1 kernel is a bit more notable than usual. In particular, the Surface Pro 9 and Surface Laptop 5 devices are now supported along with some other hardware support enablement...

Linux 6.1 Adds Support For The Microsoft Surface Pro 9  Phoronix

Adding to the material queuing in DRM-Next is another drm-misc-next pull which is likely the last batch of DRM core and small driver feature updates expected for Linux 6.2...

FBDEV Drivers Will Honor "nomodeset" With Linux 6.2  Phoronix

Windows Subsystem for Linux Has Reached v1.0 Stable Release  It's FOSS News

Canonical Releases New Ubuntu Linux Kernel Security Updates to Fix 16 Vulnerabilities  9to5Linux

Seamlessly Run Windows Apps on Your Linux Desktop With WinApps  MUO - MakeUseOf

Say hello to Red Hat Enterprise Linux 9.1  ZDNet

What Is a Linux Hypervisor and What Does It Do?  MUO - MakeUseOf

Git concepts in less than 10 minutes Dwayne McDaniel Thu, 11/17/2022 - 03:00

Git has become the default way to store and transport code in the DevOps generation. Over 93% of developers report that Git is their primary version control system. Almost anyone who has used version control is familiar with git add, git commit, and git push. For most users, that’s all they ever plan to do with Git, and they're comfortable with that. It just works for their needs.

However, from time to time, almost everyone encounters the need to do something a little more advanced, like git rebase or git cherry-pick or work in a detached head state. This is where many devs start to get a bit nervous.

[ Read next How to reset, revert, and return to previous states in Git ]

I'm here to tell you it is ok! Everyone who has or will ever use Git will likely go through those same pangs of panic.

Git is awesome, but it's also intimidating to learn, and it can feel downright confusing sometimes. Git is unlike almost anything else in computer science. You typically learn it piecemeal, specifically in the context of other coding work. Most developers I have met have never formally studied Git beyond perhaps a quick tutorial.

Git is open source, meaning you have the freedom to examine the code and see how it works. It's written mainly in C which, for many devs and people learning computer science, can make it hard to understand. At the same time, the documentation uses terms like massage parameters and commit-ish. It can feel a little baffling. You might feel like Git was written for an advanced Linux professional. That is because it originally was.

A brief Git history

Git started as a specific set of scripts for Linus Torvalds to use to manage patches.

Here's how he introduced what would become Git to the Linux kernel mailing list:

So I'm writing some scripts to try to track things a whole lot faster. Initial indications are that I should be able to do it almost as quickly as I can just apply the patch, but quite frankly, I'm at most half done, and if I hit a snag, maybe that's not true at all. Anyway, the reason I can do it quickly is that my scripts will _not_ be an SCM, they'll be a very specific "log Linus' state" kind of thing. That will make the linear patch merge a lot more time-efficient, and thus possible.

One of the first things I do when I get confused about how Git works is to imagine why and how Linus would apply it to managing patches. It has grown to handle a lot more than that and is indeed a full SCM, but remembering the first use case is helpful in understanding the "why" sometimes.

Git commit

The core conceptual unit of work in Git is the commit. These are snapshots of the files being tracked within your project folder ( where the .git folder lives.)

Image by:

(Git-scm.com, CC BY-NC-SA 3.0)

It's important to remember that Git stores compressed snapshots of the file system, not diffs. Any time you change a file, a whole new compressed version of that file is made and stored in that commit. It does this by creating a super compressed Binary Large Object (blob) out of the file, and then keeping track of it by generating a checksum made with the SHA hashing algorithm. The permanence of your Git history is one of the reasons it's vital never to store or hardcode sensitive data in your Git projects. Anyone who can clone the repo has full access to all the versions of the files.

Git is really efficient. If a file does not change between commits, Git does not make a whole new compressed version for storage. Instead, it just refers back to the previous commit. All commits know what commit came directly before it, called its parents. You can easily see this chain of commits when you run git log.

Image by:

(Git-scm.com, CC BY-NC-SA 3.0)

You have full control over these chains of commits and can do some pretty cool things with them. You can create, delete, merge and reorder them as you see fit. You can even effectively travel through time, explore and even write your commit histories. But it all relies on understanding how Git sees chains of commits, which are generally referred to as branches.

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

Branching lets you work with multiple chains of commits inside a project. Working with multiple branches (especially when you work with rebase) is where many users start to sweat. A common mental model most people have about what branches even are adds to the confusion.

When thinking about branching, most people conjure up images of swim lanes, diverging, and intersecting dots. While those models can be helpful when understanding specific branching strategies and workflows, thinking of Git as a series of numbered dots on a graph can muddy the waters when trying to think about how Git does what it does.

An alternative mental model I find helpful is to think of branches existing in a big spreadsheet. The first column is the parent commit ID, the second is the new commit ID, and then there are columns for metadata, including all the pointers.

Image by:

(Dwayne McDaniel, CC BY-SA 4.0)

Pointers keep track of where you are, and which branch is which. Pointers are convenient human-readable references to specific commits. Any reference that leads back to a specific commit is referred to as commit-ish.

The special pointer used to name a branch always points to the newest commit on the chain. You can arbitrarily assign a pointer to any commit with git tag, which doesn't move. When you git checkout or git switch between branches, you're really telling Git that you want to change the point of reference of Git and move a very special pointer called HEAD in every .git folder.

The .git folder

One of the best ways to understand what is going on with Git is to dig into the .git folder. If you've never opened this file before, I highly encourage you to open it up and see what's there. If you're very nervous you might break something, clone an arbitrary open source project to play around with until you feel confident to look into your own project repos.

Image by:

(Dwayne McDaniel, CC BY-SA 4.0)

One of the first things you notice is how small the files are.

Things are measured in terms of bytes or kilobytes, at the largest. Git is extremely efficient!

HEAD

Here in the .git folder, you find the special file HEAD. It's a very small file, only a handful of bytes in size. If you open it up, you see it’s only one line long.

git > HEAD
  ref:refs/heads/main

One of the phrases you will often encounter when reading about Git is "everything is local." From Git's perspective, wherever HEAD is pointing is "here." HEAD is the point of reference for how Git interacts with other branches, other refs, and other copies of itself.

In this example, the ref: is pointing at another pointer, a branch name pointer. Following that path, you can find a file that looks much like the spreadsheet from earlier. Git just takes the latest commit ID from the file and knows that is the commit HEAD is referring to.

If HEAD refers to a specific commit with no other pointer attached, then HEAD is referred to as "detached." Working in a detached HEAD state is completely safe, but limits what you can do, like make new commits from there. To get out of a detached HEAD state, just checkout another pointer, like the branch name, for example, git checkout main.

Config

Another critical file for helping Git keep track of things is the .git/config file. This is just one of the places Git leads and stores configuration. You're likely already familiar with the --global level of Git config, stored in your home directory in your .gitconfig file. There are actually five places Git loads config, each overriding the previous configuration. The order Git loads config is:

• --system This loads config specific to your operating system

• --global Affects you as a user, user.name and user.email stored here

• --local This sets repo specific info, like remotes and hooksPath

• --worktree The worktree is what is compressed into an individual commit

• --blob individual compressed files can have their own settings

You can see all config for a repo by running git config --list --show-origin

You can leverage your local config to use multiple Git personas. Override the user.name and user.email in .gitconfig. Leveraging the local config is particularly useful when dividing your time between work projects, personal repos, and any open source contributions.

Git hooks

Git has a built-in powerful automation platform called Git hooks. Git hooks allows you to execute scripts that will run when certain events happen in Git. You can write scripts in any scripting language you prefer that is available to your environment. There are 17 hooks available.

If you look in any repo's .git/hooks folder, you see a collection of .sample files. These are pre-written samples meant to get you started. Some of them contain some odd-looking code. Odd, perhaps, until you remember that these mainly were added to serve the original use case for Linux kernel work and were written by people living in a sea of Perl and Bash scripts. You can make the scripts do anything you want.

Here's an example of a hook I use for personal repos:

#!/sur/bin/env bash
curl https://icanhazdadjoke.com
echo “”

In this example, every time I run git commit but before the commit message is committed to my Git history, Git executes the script. (Thanks to Edward Thomson's git-dad for the inspiration.)

Of course, you can do practical things, too, like checking for hardcoded secrets before making a commit. To read more about Git Hooks and to find many, many example scripts, check out Matthew Hudson's fantastic GitHooks.com site.

Advanced Git

Now you have a better understanding of how Git sees the world and works behind the scenes, and you've seen how you can make it do your bidding with scripts. In my next article, I'll address some advanced tools and commands in Git.

Understanding Git is essential to open source development, but it can be intimidating to learn. Let this tutorial be your first step to getting to know Git.

Image by:

Opensource.com

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.

Linux commands: Drop these old utilities for modern alternatives Seth Kenlon Thu, 11/17/2022 - 03:00

Linux has a good track record for software support. There are about 60 commands in man section 1 of Unix 1st edition, and the majority still work today. Still, progress stops for no one. Thanks to vast global participation in open source, new commands are frequently developed. Sometimes a new command gains popularity, usually because it offers new features, or the same features but with consistent maintenance. Here are ten old commands that have recently been reinvented.

1. Replace man with cheat or tealdeer

The man page is functional, and it works well for what it does. However, man pages aren't always the most succinct at demonstrating how to use the command you're trying to reference. If you're looking for something a little more to the point, try cheat or tealdeer.

2. Replace ifconfig with ip

The ifconfig command provides information about your network interfaces, whether they're physical or virtual.

$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
  inet 10.1.2.34  netmask 255.255.255.0  broadcast 10.0.1.255
  inet6 fe80::f452:f8e1:7f05:7514  prefixlen 64
  ether d8:5e:d3:2d:d5:68  txqueuelen 1000  (Ethernet)
  [...]

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1360
  inet 10.2.3.45  netmask 255.255.254.0  destination 10.2.14.15
  inet6 2620:52:4:1109::100e  prefixlen 64  scopeid 0x0<global>
  unspec 00-00-00-00-00-00-00-00-[...]0-00  txqueuelen 500  (UNSPEC)
  [...]

The newer ip command provides similar information:

$ ip -4 address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.1.2.34/24 brd 10.0.1.255 scope global noprefixroute eth0
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1360 qdisc pfifo_fast state UNKNOWN group default qlen 500
    inet 10.2.3.45/23 brd 10.2.15.255 scope global noprefixroute tun03. Replace yum with dnf and apt-get with apt

Package managers tend to be slow to change, and when they do they often work hard to maintain backward compatibility. Both the yum command and the apt-get command have had improvements lately. The changes are usually aliased or designed to work in both their old and new syntax:

$ sudo yum install foo
$ sudo dnf install foo $ sudo apt-get install foo
$ sudo apt install foo4. Replace repoquery with dnf

Before there was dnf there were a variety of utilities for yum to help users get reports on their packaging system configuration. Most of those extra functions got included by default with dnf. For instance, repoquery is a subcommand of dnf, and it provides a list of all installed packages:

$ sudo dnf repoquery5. Replace pip with pip

The pip command is a package manager for Python. It hasn't been replaced, but the preferred syntax has been updated. The old command:

$ pip install yamllint

The new syntax:

$ python3 -m pip install yamllint6. Replace ls with exa

The ls command hasn't been replaced.

Rather, it hasn't been replaced again.

The ls command was originally its own binary application, and it's still available as one. Eventually, though, the Bash shell included its own ls built-in command, which by default overrides any installed ls command.

Recently, the exa command has been developed as, depending on your preferences, a better ls. Read about it in Sudeshna Sur's exa command article, and then try it for yourself.

More Linux resources Linux commands cheat sheet Advanced Linux commands cheat sheet Free online course: RHEL technical overview Linux networking cheat sheet SELinux cheat sheet Linux common commands cheat sheet What are Linux containers? Our latest Linux articles 7. Replace du with dust or ncdu

There's nothing wrong with the du, which reports on how much disk space is used on your hard drives. It does its job well, but to be fair it's pretty minimal.

If you're looking for a little variety, try the ncdu command or the dust command.

8. Replace cat with bat

The cat command is, aside from being overused by the best of us, is a simple and direct command. It reads the contents of any number of files, and outputs it to standard input.

Its output is pretty basic, so if you're looking for something with syntax highlighting and flexible output options, try the bat command instead.

Does bat also replace the tac command? No, don't worry, for now at least tac is safe in its position as the command that outputs a file in reverse. (Unless, that is, you count sed.)

9. Replace netstat with ss

The netstat command has largely been replaced by the ss command, although of all the commands on this list it's possibly the most hotly debated. The ss command provides much of the same functionality, but as Jose Vicente Nunez points out in his six deprecated commands article, there are gaps and differences in functionality. Before switching wholesale to ss, try it and compare it with how you use netstat now.

10. Replace find with fd

I use find to located files, as an input source for GNU Parallel, and more. I'm pretty familiar with it, but I have to admit that its syntax is a little clunky. The fd command seeks to improve upon that. For instance, suppose you're looking for a file called example, but you can't remember what file extension you used. With find, the syntax might look something like this:

$ find . -name "*example*"
/home/tux/example.adoc
/home/tux/example.sh

With fd, the syntax is:

$ fd example
/home/tux/example.adoc
/home/tux/example.sh

And suppose you want to grep command to search through the results for the phrase "zombie apocalypse". Using find:

$ find . -name "*example*" -exec grep "zombie apocalypse" {} \;
zombie apocalypse

Using fd instead:

$ fd txt -x grep zombie
zombie apocalypse

Read more about it in Sudeshna Sur's fd article, and then try it for yourself.

For even more updates to classic commands, download our cheat sheet below.

These traditional Linux utilities have been revitalized with modern replacements.

Image by:

Opensource.com

Linux Download now: Cheat sheet: Old Linux commands and their modern replacements This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

The post How to Save a File in Vi / Vim Editor in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

It is true that learning Vi/Vim editor – a well-known text editor in the Linux ecosystem, is not as easy as learning Nano or Emacs, as it requires a little effort which is worthwhile.

The post How to Save a File in Vi / Vim Editor in Linux first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

<p><span><span><span><span><span><span>We say this a lot at Red Hat: no single technology vendor holds the key to success, and that includes us.&nbsp;</span></span></span></span></span></span></p> <p><span><span><span><span><span><span>In our new podcast — </span></span&a

Red Hat Enterprise Linux 9.1 was officially released today as the latest update to this leading enterprise Linux distribution. This afternoon also marked the release already of RHEL-derived AlmaLinux 9.1...

Open source community split over offer of 'corporate' welfare for critical dev tools  The Register

StarFighter Linux Linux laptop goes up for pre-order with Intel or AMD and QHD or 4K display options  Liliputing

QEMU 7.2-rc1 Released - TCG For AVX/AVX2, Massive 9pfs Performance Improvement  Phoronix

QEMU 7.2 is gearing up for release in December as the next feature release to this widely-used processor emulator by the Linux virtualization stack. QEMU 7.2-rc1 is available for testing with a number of new features and improvements coming in this release...