Open-source News

The best Linux distros for gaming  Digital Trends

GNOME and Red Hat developers are working on integrating firmware security tips and recommendations into the desktop for warning users about platform/firmware security issues like if UEFI Secure Boot is disabled and other possible avenues their system could be exploited...

The GNU Compiler Collection (GCC) developers are preparing for an August release of GCC 12.2 as the first stable point release update to this year's GCC 12 series...

With LLVM 15 branched and main now open for LLVM 16, one of the early changes for this next compiler release cycle is enabling scalable vectorization by default for RISC-V with supported targets for RISC-V vector instructions...

The Mesa V3DV open-source Vulkan driver for supporting Broadcom VideoCore V/VI graphics that is most notably used by the Raspberry Pi 4 and later is now exposing Vulkan 1.2 support...

ACTAMID M8S Intel Windows 11 Linux mini PC  Geeky Gadgets

ACTAMID M8S Intel Windows 11 Linux mini PC  Geeky Gadgets

The post Ebook: Introducing Learn Linux In One Week and Go from Zero to Hero first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

After the success of our RHCSA / RHCE and LFCS / LFCE certification books, we are now happy to present “Learn Linux In One Week”. This ebook will walk you through the beginnings of

The post Ebook: Introducing Learn Linux In One Week and Go from Zero to Hero first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

Linux 5.20 To Bring New Intel & AMD Hardware Support, IO_uring Features & Much More  Phoronix

Learn Rust by debugging Rust Gaurav Kamathe Fri, 07/29/2022 - 03:00 Register or Login to like Register or Login to like

In my previous article about rustup, I showed you how to install the Rust toolchain. Well, what good is the toolchain if you won’t be using it to get more hands-on with Rust? Learning any language involves reading existing code and writing a lot of sample programs. That's a good way to become proficient in a language. However, there's a third way: debugging code.

Learning through debugging involves trying to compile a pre-written (buggy) sample program, understanding the errors generated by the compiler, fixing the sample code, and then re-compiling it. Repeat that process until the code successfully compiles and runs.

Rustlings is an open source project by the Rust team that helps you learn Rust through the process of debugging. It also provides you with a lot of hints along the way. If you're a beginner to Rust and have either started or completed reading the Rust book, then rustlings is the ideal next step. Rustlings helps you apply what you've learned from the book, and move to working on bigger projects.

Installing rustlings

I'm using (and recommend) a Fedora machine to try rustlings, but any Linux distribution works. To install rustlings, you must download and run its install script. It's recommended that you do this as a normal user (not root) without any special privileges.

Remember, for you to be able to use rustlings, you need the Rust toolchain available on your system. If you don't have that already, please refer to my article on rustup.

Once you're ready, download the installation script:

$ curl -L https://raw.githubusercontent.com/rust-lang/rustlings/main/install.sh  > rustlings_install.sh
$ file rustlings_install.sh
rustlings_install.sh: Bourne-Again shell script, ASCII text executable

Inspect the script to learn what it does:

$ less rustlings_install.sh

And then run it to install:

$ bash rustlings_install.sh
[...]
Installing /home/tux/.cargo/bin/rustlings
Installed package `rustlings v4.8.0 (/home/tux/rustlings)` (executable `rustlings`)
All done!

Run 'rustlings' to get started.

Rustlings exercises

The installation provides you with the rustlings command. Run it along with the --help flag to see what options are available.

$ rustlings --help

The installation script also clones the rustlings Git repository, and installs all the dependencies required to run the sample programs. You can view the sample programs within the exercises directory under rustlings:

$ cd rustlings
$ pwd
/home/tux/rustlings
$ ls
AUTHORS.md  Cargo.toml        CONTRIBUTING.md  info.toml install.sh README.md  target Cargo.lock  CHANGELOG.md  exercises install.ps1  LICENSE src tests
$ ls -m exercises/
advanced_errors, clippy, collections, conversions, enums, error_handling, functions, generics, if, intro, macros, mod.rs,
modules, move_semantics, option, primitive_types, quiz1.rs, quiz2.rs, quiz3.rs, quiz4.rs, README.md,
standard_library_types, strings, structs, tests, threads, traits, variablesList all exercises from the command line

The rustlings command provides you with a list command which displays each sample program, its complete path, and the status (which defaults to pending.)

$ rustlings list
Name         Path                                 Status
intro1       exercises/intro/intro1.rs            Pending
intro2       exercises/intro/intro2.rs            Pending
variables1   exercises/variables/variables1.rs    Pending
variables2   exercises/variables/variables2.rs    Pending
variables3   exercises/variables/variables3.rs    Pending
[...]

Near the end of the output, you're given a progress report so you can track your work.

Progress: You completed 0 / 84 exercises (0.00 %).View sample programs

The rustings list command shows you what programs are available, so at any time you can view the code of those programs by copying the complete paths into your terminal as an argument for the cat or less commands:

$ cat exercises/intro/intro1.rsVerify your programs

Now you can start debugging programs. You can do that using the verify command. Notice that rustlings chooses the first program in the list (intro1.rs), tries to compile it, and succeeds:

$ rustlings verify
Progress: [-----------------------------------] 0/84
✅ Successfully ran exercises/intro/intro1.rs!

You can keep working on this exercise,
or jump into the next one by removing the `I AM NOT DONE` comment:

 6 |  // Execute the command `rustlings hint intro1` for a hint.
 7 |  
 8 |  // I AM NOT DONE
 9 |

As you can see from the output, even though the sample code compiles, there's work yet to be done. Each sample program has the following comment in its source file:

$ grep "NOT DONE" exercises/intro/intro1.rs
// I AM NOT DONE

Although the compilation of the first program worked fine, rustlings won't move to the next program until you remove the I AM NOT DONE comment.

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 Moving to the next exercise

Once you have removed the comment from intro1.rs, you can move to the next exercise by running the rustlings verify command again. This time, you may notice that rustlings tries to compile the next program (intro2.rs) in the series, but runs into an error. You're expected to debug that issue, fix it, and then move forward. This is a critical step, allowing you to understand why Rust says a program has bugs.

$ rustlings verify
Progress: [>------------------------] 1/84
⚠️  Compiling of exercises/intro/intro2.rs failed! Please try again. Here's the output:
error: 1 positional argument in format string, but no arguments were given
 --> exercises/intro/intro2.rs:8:21
  |
8 |         println!("Hello {}!");
  |                         ^^

error: aborting due to previous errorGetting a hint

Rustlings has a handy hint argument, which tells you exactly what's wrong with the sample program, and how to fix it. You can think of it as an add-on help option, in addition to what the compiler error message tells you.

$ rustlings hint intro2
Add an argument after the format string.

Based on the above hint, fixing the program is easy. All you need to do is add an additional argument to the println statement. This diff should help you understand the changes:

< println!("Hello {}!", "world");
---
> println!("Hello {}!");

Once you make that change, and removed the NOT DONE comment from the source code, you can run rustlings verify again to compile and run the code.

$ rustlings verify
Progress: [>-------------------------------------] 1/84
✅ Successfully ran exercises/intro/intro2.rs!Track progress

You aren't going to finish all of the exercises in a day, and it's easy to lose track of where you left off. You can run the list command to see the status of your work.

$ rustlings list
Name         Path                                  Status
intro1       exercises/intro/intro1.rs             Done  
intro2       exercises/intro/intro2.rs             Done  
variables1   exercises/variables/variables1.rs     Pending
variables2   exercises/variables/variables2.rs     Pending
variables3   exercises/variables/variables3.rs     Pending
[...]Run specific exercises

If you don't want to start from the beginning and skip a few exercises, rustlings allows you to focus on specific exercises using the rustlings run command. This runs a specific program without requiring the previous lesson to be verified. For example:

$ rustlings run intro2
Hello world!
✅ Successfully ran exercises/intro/intro2.rs
$ rustlings run variables1

Typing exercise names can become tedious, but rustlings provides you with a handy next command so you can move to the next exercise in the series.

$ rustlings run nextAlternative watch command

If you don't want to keep typing verify after each modification you make, you can run the watch command in a terminal window, and then keep modifying the source code to fix issues. The watch command detects these modifications, and keeps re-compiling the program to see whether the issue has been fixed.

$ rustlings watchLearn by debugging

The Rust compiler is known to provide very meaningful error messages, which helps you understand issues in your code. This usually leads to faster debugging. Rustlings is a great way to practice Rust, to get used to reading error messages, and understand the Rust language. Check out the recent features of Rustlings 5.0.0 on GitHub.

[ Practice programming with Rust. Download our Rust cheat sheet. ]

Rustlings is an open source project by the Rust team that helps you learn Rust through the process of debugging.

Image by:

Opensource.com

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

Fix bugs in Bash scripts by printing a stack trace Evan "Hippy" Slatis Fri, 07/29/2022 - 03:00 Register or Login to like Register or Login to like

No one wants to write bad code, but inevitably bugs will be created. Most modern languages like Java, JavaScript, Python, etc., automatically print a stack trace when they encounter an unhandled exception, but not shell scripts. It would make it much easier to find and fix bugs in shell scripts if you could print a stack trace, and, with a little work, you can.

Shell scripts can span multiple files, and well-written code is further broken down into functions. Tracing issues when something goes wrong in a shell script can be difficult when these scripts get large enough. A stack trace that walks the code backward from the error to the beginning can show you where your code failed and give you a better understanding of why so you can fix it properly.

To implement the stack trace, I use the trap in the following manner at the beginning of my script:

set -E

trap 'ERRO_LINENO=$LINENO' ERR
trap '_failure' EXIT

This example accomplishes a few things, but I'll address the second one, trap 'ERRO_LINENO=$LINENO' ERR, first. This line ensures the script traps all commands that exit with a non-zero exit code (i.e., an error), and saves the line number of the command in the file where the error was signaled. This is not captured on exit.

The first line above (set -E) ensures that the error trap is inherited throughout the script. Without this, whenever you drop into an if or until block, for example, you'd lose track of the correct line number.

The second trap captures the exit signal from the script and sends it to the _failure function, which I'll define in a moment. But why on exit and not error if you're trying to debug the script? In bash scripts, command failures are often used in control logic or can be ignored outright as unimportant by design. For example, say at the beginning of your script, you're looking to see if a particular program is already installed before asking the user whether they'd like you to install it for them:

if [[ ! -z $(command -v some_command) ]]
then
   # CAPTURE LOCATION OF some_command
   SOME_COMMAND_EXEC=$(which some_command)
else
   # echo $? would give us a non-zero value here; i.e. an error code
   # IGNORE ERR: ASK USER IF THEY WANT TO INSTALL some_command
fi

If you were to stop processing on every error and some_command is not installed, this would prematurely end the script, which is obviously not what you want to do here, so in general, you only want to log an error and stack trace when the script has exited unintentionally because of an error.

To force your script to exit whenever there's an unexpected error, use the set -e option:

set -e
# SCRIPT WILL EXIT IF ANY COMMAND RETURNS A NON-ZERO CODE
# WHILE set -e IS IN FORCE
set +e
# COMMANDS WITH ERRORS WILL NOT CAUSE THE SCRIPT TO EXIT HERE

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

The next question is, what are some examples where you would probably like your script to exit and highlight a failure? Common examples include the following:

1. An unreachable remote system
2. Authentication to a remote system fail
3. Syntax errors in config or script files being sourced
4. Docker image builds
5. Compiler errors

Combing through many pages of logs after a script completes looking for any possible errors that may be hard to spot can be extremely frustrating. It's even more frustrating when you discover something is wrong long past the time you ran the script and now have to comb through multiple sets of logs to find what might have gone wrong and where. Worst is when the error has been around for a while, and you only discover it at the worst possible time. In any case, pinpointing the problem as quickly as possible and fixing it is always the priority.

Look at the sample stack trace code (available for download here):

# Sample code for generating a stack trace on catastrophic failure

set -E

trap 'ERRO_LINENO=$LINENO' ERR
trap '_failure' EXIT

_failure() {
  ERR_CODE=$? # capture last command exit code
  set +xv # turns off debug logging, just in case
  if [[  $- =~ e && ${ERR_CODE} != 0 ]]
  then
      # only log stack trace if requested (set -e)
      # and last command failed
      echo
      echo "========= CATASTROPHIC COMMAND FAIL ========="
      echo
      echo "SCRIPT EXITED ON ERROR CODE: ${ERR_CODE}"
      echo
      LEN=${#BASH_LINENO[@]}
      for (( INDEX=0; INDEX<$LEN-1; INDEX++ ))
      do
          echo '---'
          echo "FILE: $(basename ${BASH_SOURCE[${INDEX}+1]})"
          echo "  FUNCTION: ${FUNCNAME[${INDEX}+1]}"
          if [[ ${INDEX} > 0 ]]
          then
           # commands in stack trace
              echo "  COMMAND: ${FUNCNAME[${INDEX}]}"
              echo "  LINE: ${BASH_LINENO[${INDEX}]}"
          else
              # command that failed
              echo "  COMMAND: ${BASH_COMMAND}"
              echo "  LINE: ${ERRO_LINENO}"
          fi
      done
      echo
      echo "======= END CATASTROPHIC COMMAND FAIL ======="
      echo
  fi
}

# set working directory to this directory for duration of this test
cd "$(dirname ${0})"

echo 'Beginning stacktrace test'

set -e
source ./testfile1.sh
source ./testfile2.sh
set +e

_file1_function1

In the stacktrace.sh above, the first thing the _failure function does is capture the exit code of the last command using the built-in shell value $?. It then checks whether the exit was unexpected by checking the output of $-, a built-in shell value that holds the current bash shell settings, to see if set -e is in force. If the script exited on an error and the error was unexpected, the stack trace is output to the console.

The following built-in shell values are used to build the stack trace:

1. BASH_SOURCE: Array of filenames where each command was called back to the main script.
2. FUNCNAME: Array of line numbers matching each file in BASH_SOURCE.
3. BASH_LINENO: Array of line numbers per file matching BASH_SOURCE.
4. BASH_COMMAND: Last command executed with flags and arguments.

If the script exits with an error in an unexpected manner, it loops over the above variables and outputs each one in order so a stack trace can be built. The line number of the failed command is not held in the above arrays, but that's why you captured the line number each time a command failed with the first trap statement above.

Putting it all together

Create the following two files to support the test, so you can see how the information is gathered across multiple files. First, testfile1.sh:

_file1_function1() {
   echo
   echo "executing in _file1_function1"
   echo

   _file2_function1
}

# adsfadfaf

_file1_function2() {
   echo
   echo "executing in _file1_function2"
   echo
 
   set -e
   curl this_curl_will_fail_and_CAUSE_A_STACK_TRACE

   # function never called
   _file2_does_not_exist
}

And next, testfile2.sh:

_file2_function1() {
   echo
   echo "executing in _file2_function1"
   echo

   curl this_curl_will_simply_fail

   _file1_function2
}

NOTE: If you create these files yourself, make sure to make the stacktrace.sh file executable.

Executing stacktrace.sh will output the following:

~/shell-stack-trace-example$./stracktrace.sh
Beginning stacktrace test

executing in _file1_function1

executing in _file2_function1
curl: (6) Could not resolve host: this_curl_will_simply_fail

executing in _file1_function2
curl: (6) Could not resolve host: this_curl_will_fail_and_CAUSE_A_STACK_TRACE

========= CATASTROPHIC COMMAND FAIL =========

SCRIPT EXITED ON ERROR CODE: 6

---
FILE: testfile1.sh
  FUNCTION: _file1_function2
  COMMAND: curl this_curl_will_fail_and_CAUSE_A_STACK_TRACE
  LINE: 15
---
FILE: testfile2.sh
  FUNCTION: _file2_function1
  COMMAND: _file1_function2
  LINE: 7
---
FILE: testfile1.sh
  FUNCTION: _file1_function1
  COMMAND: _file2_function1
  LINE: 5
---
FILE: stracktrace.sh
  FUNCTION: main
  COMMAND: _file1_function1
  LINE: 53

======= END CATASTROPHIC COMMAND FAIL =======

For extra credit, try uncommenting the line in testfile1.sh and executing stacktrace.sh again:

# adsfadfaf

Then re-comment the line, and instead comment out the following line in testfile1.sh that caused a stack trace and run stacktrace.sh one last time:

curl this_curl_will_fail_and_CAUSE_A_STACK_TRACE

This exercise should give you an idea of the output and when it occurs if you have typos in your scripts.

Automatically printing a stack trace on unhandled errors in your scripts can make finding and fixing bugs in your code much easier.

Image by:

Pixabay, testbytes, CC0

Linux What to read next How to write functions in Bash Using variables in Bash This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

The post Useful Tips For VLC Player Users in Linux Desktop first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

The VLC media player is arguably one of the most widely used media players. It is a multi-platform media player and framework that supports a wide range of multimedia files and streaming protocols. In

The post Useful Tips For VLC Player Users in Linux Desktop first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

7 Docks to Customize Your Linux Desktop in 2022  It's FOSS

In this article, I discuss a proposal to build a success-primed team to modernize a portfolio of applications.

The Godot open-source game engine developers announced on Thursday that next week will mark the Godot 4.0 feature freeze as they prepare to ship the Godot 4.0 Beta 1 in September. But ahead of that feature freeze, Godot 4.0 Alpha 13 was released on Thursday afternoon with yet more feature work -- including variable rate shading and other renderer improvements...

Firefox 104 Enters Beta Testing with Two-Finger Swipe Back/Forward Gesture on Linux  9to5Linux

This Lenovo ThinkPad with Linux just got a $1,000 price cut  Digital Trends

The OpenGEH Project is one of the many projects at LF Energy. We want to share about it here on the LF blog. This originally appeared on the LF Energy site. 

OpenGEH ( GEH stands for Green Energy Hub ) enables fast, flexible settlement and hourly measurements of production and consumption of electricity. OpenGEH seeks to help utilities to onboard increased levels of renewables by reducing the administrative barriers of market-based coordination. By utilizing a modern DataHub, built on a modular and microservices architecture, OpenGEH is able to store billions of data points covering the entire workflow triggered by the production and consumption of electricity.

The ambition of OpenGEH is to use digitalization as a way to accelerate a market-driven transition towards a sustainable and efficient energy system. The platform provides a modern foundation for both new market participants and facilitates new business models through digital partnerships. The goal is to create access to relevant data and insights from the energy market and thereby accelerate the Energy Transition.

Initially built in partnership with Microsoft, Energinet (the Danish TSO) was seeking a critical leverage point to accelerate the Danish national commitment to 100% renewable energy in their electricity system by 2030. For most utilities, getting renewables onboard creates a technical challenge that also has choreography and administrative hurdles. Data becomes the mechanism that enables market coordination leading to increased decarbonization. The software was contributed to the LF Energy Foundation by Energinet.

Energinet sees open source and shared development as an opportunity to reduce the cost of software, while simultaneously increasing the quality and pace of development. It is an approach that they see gaining prominence in TSO cooperation. Energinet is not an IT company, and therefore does not sell systems, services, or operate other TSOs. Open source coupled with an intellectual property license that encourages collaboration, will insure that OpenGEH continues to improve, by encouraging a community of developers to add new features and functionality.

The Architectural Principles behind OpenGEH

By implementing Domain Driven Design, OpenGEH has divided the overall problem  into smaller independent domains. This gives developers the possibility to only use the domains that are necessary to solve for the needed functionality. As the domains trigger events when data changes, the other domains listen on these events to have the most updated version of data.

The architecture supports open collaboration on smaller parts of OpenGEH. New domains can be added by contributors, to extend the OpenGEH’s functionality, when needed to accelerate the green transition.

The Green Energy Hub Domains

The Green Energy Hub system consists of two different types of domains:

• A domain that is responsible for handling a subset of business processes.
• A domain that is responsible for handling an internal part of the system (Like log accumulation, secret sharing or similar).

Below is a list of these domains, and the business flows they are responsible for.

• Business Process Domains
  • Metering Point
    • Create metering point
    • Submission of master data – grid company
    • Close down metering point
    • Connection of metering point with status new
    • Change of settlement method
    • Disconnection and reconnecting of metering point
    • Meter management
    • Update production obligation
    • Request for service from grid company
  • Aggregations
    • Submission of calculated energy time series
    • Request for historical data
    • Request for calculated energy time series
    • Aggregation of wholesale services
    • Request for aggregated tariffs
    • Request for settlement basis
  • Time Series
    • Submission of metered data for metering point
    • Send missing data log
    • Request for metered data for a metering point
  • Charges
    • Request for aggregated subscriptions or fees
    • Update subscription price list
    • Update fee price list
    • Update tariff price list
    • Request price list
    • Settlement master data for a metering point – subscription, fee and tariff links
    • Request for settlement master data for metering point
  • Market Roles
    • Change of supplier
    • End of supply
    • Managing an incorrect change of supplier
    • Move-in
    • Move-out
    • Incorrect move
    • Submission of customer master data by balance supplier
    • Initiate cancel change of supplier by customer
    • Change of supplier at short notice
    • Mandatory change of supplier for metering point
    • Submission of contact address from grid company
    • Change of BRP for energy supplier
  • Data Requests
    • Master data request
• System Domains
  • Shared Resources
    • Secrets handling
    • DataBricks workspace
  • Validation Reports
    • Log accumulation for all domains
  • Post Office
    • Messaging service for outbound messages
  • API Gateway
    • Authentication and routing

The post What is the OpenGEH (Green Energy Hub) Project appeared first on Linux Foundation.

10 Common Mistakes First-Time Linux Users Make  MUO - MakeUseOf

Open-source device manufacturer Raptor Computing Systems earlier this month teased their new FPGA-based open-source soft BMC product while today that "Arctic Tern" product has been formally announced...