Open-source News

GM Teams Up With Red Hat For Linux Vehicle Operating System  CleanTechnica

Last week marked the first update to the jemalloc memory allocation library since August of 2019. This malloc() implementation focused concurrency and memory fragmentation avoidance has seen more speed optimizations and other improvements in this new jemalloc 5.3 release...

Microsoft warns: This botnet has new tricks to target Linux and Windows systems  ZDNet

In addition to Linux 5.19 set to add NVMe support for the Apple M1 systems, the Apple eFuse driver also from the open-source community is geared up for landing in this next version of the Linux kernel...

Consulting firm Igalia that has been working on the Mesa V3DV open-source Vulkan driver for the Raspberry Pi 4 and newer has published a summary of recent accomplishments for this Mesa solution...

Mesa's Radeon Vulkan driver "RADV" continues working on maturing its ray-tracing implementation after the initial code was merged last year. RADV ray-tracing is still treated as experimental and not as reliable as the proprietary NVIDIA Vulkan driver's ray-tracing support that has been around much longer, but it's getting there and at least is open-source -- unlike AMD's official AMDVLK driver that continues to not support Vulkan RT unlike their proprietary driver alternative...

Google engineer Sami Tolvanen has posted the second "request for comments" patch series on KCFI as a Control-Flow Integrity implementation better geared for Linux kernel usage than the existing CFI support...

Mesa developer Timothy Arceri of Valve's Linux graphics driver team has added a NIR varying linker for GLSL...

Mesa 22.2 Continues Modernizing With More GLSL IR Code Replaced By NIR  Phoronix

9to5Linux Weekly Roundup: May 15th, 2022  9to5Linux

Linus Torvalds has released what is likely the last release candidate before officially declaring Linux 5.18 next weekend if all goes according to plan...

With 19.8% CAGR, Global Linux Operating System Market Size Worth USD 22.15 Billion in 2029  GlobeNewswire

LifeSavers Gummies Recall : (Scam or Legit?) Is It Worth Buying? - Linux & Unix  BleepingComputer

Microsoft has another Linux distribution and it is based on Debian  It's FOSS News

The Linux Foundation Initiates "World of Open Source" Research Series  PR Newswire

5 benefits of switching from Google Analytics to Plausible Tom Greenwood Mon, 05/16/2022 - 03:00 Register or Login to like Register or Login to like

Google Analytics (GA) has been the industry standard web analytics tool for about as long as there have been analytics tools. Nearly every brief that my WordPress agency receives specifies that GA must be installed. And there is rarely any debate around whether it's the best tool for the job.

My team at Wholegrain Digital has had concerns about GA in terms of privacy, General Data Protection Regulation (GDPR) compliance, performance, user experience, not to mention Google as a global advertising, and search monopoly. However, we continued using GA for 99% of our projects because we didn't feel that there was a strong enough alternative.

Well, that has changed. We've made a decision that GA will no longer be our default analytics tool. Instead, our default analytics tool will be Plausible.

In this article, I'll outline why we consider Plausible a better choice as a default analytics solution, the compromises to be aware of, and how it will impact our clients.

Why use Plausible instead of Google Analytics

We believe that using Plausible over GA is not a purely ideological choice. There are in fact a number of tangible benefits that make it an objectively better product in many cases. Let's take a look at some of these benefits.

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 Privacy

One of Plausible's headline benefits is that it has been designed as a privacy-first analytics tool. This might sound like an ideological factor, but it has real practical implications too.

Plausible only collects anonymous user data, and does not use cookies. This means that unlike most analytics solutions, it complies with both the GDPR and the European Cookie Law, so it's a tick in the box for legal compliance. It's also hosted in the EU and the data is owned by you so it doesn't get shared with any other organizations, which is another tick.

This has a positive knock-on effect for user experience, because without privacy-invading cookies, you don't need to implement a cookie banner on the website (unless you use cookies for other things). Considering that the first few seconds of a website visit are the most critical to brand experience and conversion rates, cookie banners are arguably the single most damaging thing to the success of any online service. Avoiding these banners puts your brand and message first, helps you make a good first impression, and increases conversion rates.

Simpler user interface

The GA dashboard was never a great case study in intuitive design, but as the functionality of GA has expanded, so too has the complexity of the interface. I'm increasingly hearing frustrations from even experienced web marketers that they sometimes struggle to find basic data inside GA.

Plausible has taken the opposite approach and focused on ease of use over quantity of features. The dashboard is beautifully designed to showcase the data you want in a way that is easy to find and understand. It's what most people wish GA to be and it's a breath of fresh air.

Image by:

(Tom Greenwood, CC BY-SA 4.0)

This is not just a pleasantry. The reality is that if a tool is easy to use then you will use it, and if it is hard to use then you won't. The simplicity of the Plausible interface means that even though it has less features, many users are likely to get a lot more insights and value from their analytics.

Better web performance

The Plausible tracking script is the smallest we are aware of for any analytics service, coming in at less than 1kb compared to 17kb for GA and even more if you're using Google Tag Manager.

Better web performance improves user experience, helps your website to rank better in search engines and improves conversion rates. Web performance matters, and when it comes to web performance, every kilobyte matters.

Reduced environmental impact

Plausible's tiny tracking script isn't just good for web performance, it's also good for the environment. At Wholegrain we are world leaders in sustainable web design and understand that every bit of wasted data is also wasted energy and carbon emissions.

This adds up. As a minimum, switching to Plausible would save 16kb per visitor, so for a website with a modest 10K visitors per month this would be 160MB of data per month, or 2GB per year. A back of an envelope calculation using the latest methodology that we have developed for website carbon calculations put this at about the equivalent of 800 grams of CO2. Now multiply that up by the millions of websites running worldwide and you are talking about significant amounts of wasted energy and unnecessary carbon emissions.

[ Read also: 5 open source tips to reduce waste in web design ]

But it doesn't stop there. Analytics tools consume energy on the end user's device as they harvest data, in the transmission networks as they send that data back to the data center, and in the data center to store it all for eternity. By tracking less, Plausible is using less energy in its operation than bloated analytics tools such as GA that are tracking many more metrics that most people don't need.

Plausible also hosts the data in data centers with a commitment to using renewable sources of electricity, which is great (though to be fair Google also does that), and they donate 5% of their revenue to good causes, so the money you are paying is also helping support environmental and social projects.

More accurate data

Finally, Plausible breaks one of the greatest myths about GA, which is that it is accurate. Plausible's own research and our own experiences with client websites show that GA can significantly under report data, sometimes by as much as 50-60%.

When you look at GA and you think you are looking at all of your website data, you are most likely only looking at a portion of it. This is because GA is more likely to be blocked by ad blockers and privacy friendly web browsers, but perhaps more significantly because GA should not be tracking your visitors unless they have accepted cookies, which many visitors do not.

Plausible therefore offers us a simple way to get a more complete and accurate view of website visitors. Needless to say, if you are a digital marketing manager and you want to make yourself look good, you want to use the analytics service that reports all of your visitors and not just some of them.

Are there any downsides?

There are very few downsides to using Plausible. If you are a GA power user and genuinely need a lot of its more advanced functionality then Plausible is not going to meet all of your needs. Plausible can track events, conversions, and campaigns but if you need more than that then you'll need another tool.

The only other notable downside to Plausible is that it is not free. There is a monthly fee but it is very reasonable, starting at $6 per month. It's a small price to pay for such a good tool, to protect the privacy of your website visitors and to maintain ownership of your data.

What are the impacts?

Here at Wholegrain Digital we are implementing Plausible in a way that we hope will offer many of our clients the benefits listed above without the downsides. Nobody will be forced to stop using GA, but we will be talking about the benefits of Plausible proactively with our clients and including it in our proposals as the default option.

In many cases, Plausible is not just capable of meeting a project's requirements, but is objectively a better solution than GA, so we'll be trying to help our clients to reap the benefits of this.

In cases where advanced GA features are required, we will of course stick with GA for now. And in some cases, we may run GA and Plausible in parallel. This has a small overhead in terms of carbon footprint and performance, so it isn't our first choice. However, in some cases it may provide a necessary bridge to help our clients gain confidence in Plausible before making the leap, or help them gain a complete data set while ensuring compliance with privacy laws.

As for the costs, Plausible is a very good value for what it offers, but we will be offering it free of charge to our clients for any websites cared for on our WordPress maintenance service. We hope that this will help lower the barrier to entry and help more of our clients and their website visitors gain the benefits of Plausible.

It is Plausible!

I hope I've convinced you that Plausible is not just a viable but a really great alternative to GA. If you need any advice on how to figure out the best analytics solution for your website or how to ensure that you are GDPR compliant without compromising user experience, get in touch with me.

This article originally appeared on the Wholegrain Digital blog and has been republished with permission.

Plausible is an open source alternative to Google Analytics.

Image by:

Opensource.com

Alternatives What to read next Why choose Plausible for an open source alternative to Google Analytics This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Use Composer to require Git repositories within PHP projects Jonathan Daggerhart Mon, 05/16/2022 - 03:00 Register or Login to like Register or Login to like

The dependency management tool Composer provides multiple ways to include Git repositories within a PHP: Hypertext Preprocessor (PHP) project.

In many cases, repositories have been created on Packagist, so requiring them with Composer is very straightforward. But what do you do when a repository has not been created as a package on Packagist? You use Composer to require the package directly from the repository. This article explains how.

Note: Some of the terminology in this post is confusing because multiple words are used to describe different things. Here is a quick vocabulary list that will help:

• Project: The custom software you are building. This can be a website, a command-line utility, an application, or anything else you dream up.
   
• Package: Any third-party software you want to download and use within your project. It can be a library, Drupal theme, WordPress plugin, or any other number of things.
   
• Git repository: Also called the Git repo, this is the version-control host for a package. Common hosts include GitHub, GitLab, or Bitbucket, but any URL-accessible Git repository will work for this tutorial.
   
• Composer repositories: In a composer.json file, there is an optional property named "repositories." This property is where you can define new places for Composer to look when downloading packages.

When adding a Git repo to your project with Composer, you can find yourself in two situations: Either the repo contains a composer.json file, which defines how the repo should be handled when required, or it does not. You can add the Git repository to your project in both cases, with different methods.

Git repo with composer.json

When a repository includes a composer.json file, it defines aspects of itself that are important to how Composer manages the package. Here is an example of a simple composer.json file a package may include:

{ "name": "mynamespace/my-custom-library", "type": "library" }

This example shows two important properties that a composer.json file can define:

• Name: The package's namespaced name. In this case, "mynamespace" is the namespace for the package "my-custom-library."
• Type: The type of package the repo represents. Package types are used for installation logic. Out of the box, Composer allows for the following package types: library, project, metapackage, and composer-plugin.

You can verify this by looking at the composer.json file of any popular GitHub project. They each define their package name and the package type near the top of the file. When a repository has this information defined in its composer.json file, requiring the repository within your project is quite simple.

More on Git What is Git? Git cheat sheet Markdown cheat sheet New Git articles Require a Git repository that has a composer.json file

After you've identified a Git repository with a composer.json file, you can require that repository as a package within your project.

Within your project's composer.json file, you need to define a new property (assuming it doesn't exist already) named "repositories." The value of the repositories property is an array of objects, each containing information about the repository you want to include in your project. Consider this composer.json file for your custom project.

{ "name": "mynamespace/my-project-that-uses-composer", "repositories": [ { "type": "vcs", "url": "https://github.com/mynamespace/my-custom-library.git" } ], "require": { "mynamespace/my-custom-library": "dev-master" } }

You are doing two important things here. First, you're defining a new repository that Composer can reference when requiring packages. And second, you're requiring the package from the newly defined repository.

Note: The package version is a part of the require statement and not a part of the repository property. You can require a specific branch of a repo by choosing a version named "dev-".

If you were to run composer install in the context of this file, Composer would look for a project at the defined URL. If that URL represents a Git repo that contains a composer.json file that defines its name and type, Composer will download that package to your project and place it in the appropriate location.

Custom package types

The example package shown above is of the type "library," but with WordPress and Drupal you're dealing with plugins, modules, and themes. When requiring special package types in your project, it's important to install them in specific locations within the project file structure. Wouldn't it be nice if you could convince Composer to treat these types of packages as special cases? Well, you're in luck. There is an official Composer plugin that will do that for you.

The Installers plugin for Composer contains the custom logic required for handling many different package types for a large variety of projects. It is extremely helpful when working with projects that have well-known and supported package installation steps.

This project allows you to define package types like drupal-theme, drupal-module, wordpress-plugin, wordpress-theme, and many more, for a variety of projects. In the case of a drupal-theme package, the Installers plugin will place the required repo within the /themes/contrib folder of your Drupal installation.

Here is an example of a composer.json file that might live within a Drupal theme project as its own Git repository:

{ "name": "mynamespace/whatever-i-call-my-theme", "type": "drupal-theme", "description": "Drupal 8 theme", "license": "GPL-2.0+" }

Note that the only meaningful difference here is that the type is now drupal-theme. With the drupal-theme type defined, any project that uses the Installers plugin can easily require your repo in its Drupal project, and it will be treated as a contributed theme.

Require any Git repository with Composer

What happens when the repo you want to include in your project does not define anything about itself with a composer.json file? When a repo does not define its name or type, you have to define that information for the repo within your project's composer.json file. Take a look at this example:

{ "name": "mynamespace/my-project-that-uses-composer", "repositories": [ { "type": "package", "package": { "name": "mynamespace/my-custom-theme", "version": "1.2.3", "type": "drupal-theme", "source": { "url": "https://github.com/mynamespace/my-custom-theme.git", "type": "git", "reference": "master" } } } ], "require": { "mynamespace/my-custom-theme": "^1", "composer/installers": "^1" } }

Notice that your repository type is now "package." That is where you will define everything about the package you want to require.

Create a new object named "package" where you define all the essential information that Composer needs to know to be able to include this arbitrary git repo within your project, including:

• Name: The namespaced package name. It should probably match the repository you're requiring but doesn't have to.
• Type: The type of package. This reflects how you want Composer to treat this repository.
• Version: A version number for the repo. You will need to make this up.
• Source: An object that contains the following repository information:
  • URL: The Git or other version-control system (VCS) URL where the package repo can be found
  • Type: The VCS type for the package, such as git, svn, cvs, and so on
  • Reference: The branch or tag you want to download

I recommend reviewing the official documentation on Composer package repositories. Note that it is possible to include zip files as Composer packages as well. Essentially, you are now responsible for all parts of how Composer treats this repository. Since the repository itself is not providing Composer with any information, you are responsible for determining almost everything, including the current version number for the package.

This approach allows you to include almost anything as a Composer package in your project, but it has some notable drawbacks:

• Composer will not update the package unless you change the version field.
   
• Composer will not update the commit references. If you use master as a reference, you will have to delete the package to force an update, and you will have to deal with an unstable lock file.

Custom package versions

Maintaining the package version in your composer.json file isn't always necessary. Composer is smart enough to look for GitHub releases and use them as the package versions. But eventually you will likely want to include a simple project that has only a few branches and no official releases.

When a repository does not have releases, you will be responsible for deciding what version the repository branch represents to your project. In other words, if you want composer to update the package, you will need to increment the "version” defined in your project's composer.json file before running composer update.

Overriding a Git repository's composer.json

When defining a new Composer repository of the type package, you can override a package's own composer.json definitions. Consider a Git repository that defines itself as a library in its composer.json, but you know that the code is actually a drupal-theme. You can use the above approach to include the Git repository within your project as a drupal-theme, allowing Composer to treat the code appropriately when required.

Example: Require Guzzle as a drupal-theme just to prove that you can.

{ "name": "mynamespace/my-project-that-uses-composer", "repositories": [ { "type": "package", "package": { "name": "mynamespace/guzzle-theme", "version": "1.2.3", "type": "drupal-theme", "source": { "url": "https://github.com/guzzle/guzzle.git", "type": "git", "reference": "master" } } } ], "require": { "mynamespace/guzzle-theme": "^1", "composer/installers": "^1" } }

This works! You've downloaded the Guzzle library and placed it within the /themes folder of your Drupal project. This is not a very practical example, but it highlights how much control the package type approach provides.

Summary

Composer offers plenty of options for including arbitrary packages within a project. Determining how those packages are included in the project primarily comes down to who defines the package information. If the Git repository includes a composer.json file that defines its name and type, you can have Composer rely on the repository itself for the definition.

But if you want to include a repository that does not define its name and type, then it is up to your project to define and maintain that information for your own internal use. Alternatively, if a repository doesn't define a composer.json file, consider submitting a pull request that adds it.

This article originally appeared on the Daggerhart Lab blog and is republished with permission.

This dependency management tool makes it easier to require a repository even when it hasn't been created as a package.

Image by:

CC BY 3.0 US Mapbox Uncharted ERG

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.

Fudgie? The Awesome Budgie Desktop is Coming to Fedora Linux Soon  It's FOSS News

The post How to Install Graylog Log Management Tool on RHEL Systems first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

Graylog is an industry-leading opensource log management solution for collecting, storing, indexing, and analyzing real-time data from applications and a myriad of devices in IT infrastructures such as servers, routers, and firewalls. Graylog helps

The post How to Install Graylog Log Management Tool on RHEL Systems first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

China's KylinOS Linux targets second RISC-V platform  The Register