Open-source News

How Linux Became the New Bullseye for Bad Guys  SecurityWeek

Red Hat Enterprise Linux 9 Beta is out and is ready to take your servers to new heights  TechRepublic

Red Hat Enterprise Linux 9 Beta is out and is ready to take your servers to new heights  TechRepublic

How to Use the sar Command on Linux  How-To Geek

How to Check CPU Information on a Linux system  BollyInside

AMD Radeon RX 6400 On Linux  Phoronix

Last week AMD quietly launched the Radeon RX 6400 series as the new low-end RDNA2 graphics. With Radeon RX 6400 there are finally low-profile, single-slot PCIe RDNA2 graphics cards whether they be for 2U servers, mini ITX builds, or other interesting use-cases. Up for testing today is an XFX Radeon RX 6400 4GB low-profile graphics card for Linux benchmarking.

As written about earlier this week, concerns have been raised over the "new" NTFS Linux driver that it's effectively unmaintained already less than one year after being mainlined. Linus Torvalds has since commented on the matter and opens up the door for other developers to maintain it...

Linus Torvalds Comments On The NTFS Linux Driver Situation  Phoronix

Get 'Linux for Networking Professionals' ($44.99 value) FREE for a limited time  BetaNews

Monte Vista taps Foundries.io for edge Linux  eeNews Europe

A few patch series were fired off yesterday for enabling new IP blocks on upcoming Radeon graphics processors...

Install Adobe Acrobat Reader DC on Ubuntu 22.04 LTS Jammy  Linux Shout

Install Adobe Acrobat Reader DC on Ubuntu 22.04 LTS Jammy  Linux Shout

Valve overnight released a beta of SteamOS 3.2 with some notable improvements for Steam Deck users...

One of Mesa's smaller drivers that continues advancing but not receiving as much attention as the big names is Etnaviv for providing open-source, reverse-engineered graphics support for Vivante graphics IP used across different SoCs...

Archinstall’s New Menu System Makes it Even Easier to Install Arch Linux  It's FOSS News

Create a blog post series with navigation in Jekyll Ayush Sharma Thu, 04/28/2022 - 03:00 Up Register or Login to like.

Blogging about individual self-contained ideas is great. However, some ideas require a more structured approach. Combining simple concepts into one big whole is a wonderful journey for both the writer and the reader, so I wanted to add a series feature to my Jekyll blog. As you may have guessed already, Jekyll's high degree of customization makes this a breeze.

Goal

I want to achieve the following goals:

1. Each article should list the other articles in the same series.
2. To simplify content discovery, the home page should display all series in a category.
3. Moving articles into different series should be easy since they may evolve over time.

Step 1: Add series metadata to posts

Given Jekyll's high customizability, there are several ways to handle a series. I can leverage Jekyll variables in the config to keep a series list, use collections, or define a Liquid list somewhere in a global template and iterate over it.

The cleanest way is to list the series and the posts contained in that series. For example, for all the posts in the Jekyll series, I've added the following two variables in the post front matter:

is_series: true
series_title: "Jekyll"

The first variable, is_series, is a simple boolean which says whether this post is part of a series. Booleans work great with Liquid filters and allow me to filter only those posts which are part of a series. This comes in handy later on when I'm trying to list all the series in one go.

The second variable, series_title, is the title of this series. In this case, it is Jekyll. It's important that posts in the same series contain the same title. I'll use this title to match posts to a series. If it contains extra spaces or special characters, it won't match the series.

You can view the source code here.

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 Step 2: Add links to posts

With the series defined, I now need to show other articles in the series. If I see a post in the Jekyll series, there should be a list of other articles in the same series. A series won't make sense without this essential navigation.

My blog uses the posts layout to display posts. To show other posts in the same series as the currently viewed post, I use the code below:

>
{% if page.is_series == true %}
"text-success p-3 pb-0">{{ page.series_title | upcase }} series>
{% assign posts = site.posts | where: "is_series", true | where: "series_title", page.series_title | sort: 'date' %}
 
{% for post in posts %}
        {% if post.title == page.title %}
 

"nav-link bullet-pointer mb-0">{{ post.title }}

>
       {% else %}
 "nav-link bullet-hash" href="{{ post.url }}">{{ post.title }}>
       {% endif %}
{% endfor %}

{% endif %}{% endraw %}

The logic above is as follows:

1. Check if the is_series boolean of the current page is true, meaning the post is part of a series.
2. Fetch posts where is_series is true and series_title is the current series_title. Sort these in ascending date order.
3. Display links to other posts in the series or show a non-clickable span if the list item is the current post.

I've stripped some HTML out for clarity, but you can view the complete source code here.

Step 3: Add links to each series to the home page

I now have the post pages showing links to other posts in the same series. Next, I want to add a navigation option to all series under a category on my home page.

For example, the Technology section should show all series in the Technology series on the home page. The same for Life Stuff, Video Games, and META categories. This makes it easier for users to find and read a complete series.

>
{% assign series = "" | split: "," %}
{% assign series_post = "" | split: "," %}
{% assign posts = site.posts | where:"Category", cat.title | where: "is_series",true | sort: 'date' %}

{% for post in posts %}
{% unless series contains post.series_title %}
{% assign series = series | push: post.series_title %}
{% assign series_post = series_post | push: post %}
{% endunless %}
{% endfor %}

{% if series.size > 0 %}
"row m-1 row-cols-1 row-cols-md-4 g-3 align-items-center">
"col">
"h3 text-success">Article series →>
>
   {% for post in series_post %}
        {% include card-link.html url=post.url title=post.series_title %}
    {% endfor %}
>
{% endif %}
{% endfor %}{% endraw %}

To identify all series for a particular category, I use the code above, which accomplishes the following:

1. Initializes two variables: one for series names and another for the first post of each series.
2. Fetches all posts that have is_series set to true and belong to the current category.
3. Adds the series_title to the series names array and the first post to the series post array.
4. Displays the name of the series, which links to the first post in that series.

You can find the full source code here.

Why I love using Jekyll for blogging

Jekyll's high degree of customization is why I enjoy working with it so much. It's also why my blog's underlying Jekyll engine has survived redesigns and refactors. Jekyll makes it easy to add dynamic logic to your otherwise static website. And while my website remains static, the logic that renders it doesn't have to be.

You can make many improvements to what I've shown you today.

One improvement I'm thinking of is handling series post ordering. For example, the posts in a series are currently shown in ascending order of their publish date. I've published several posts belonging to a series at different times, so I can add a series_order key and use it to order articles by topic rather than by publish date. This is one of the many ways you can build your own series feature.

Happy coding :)

This article originally appeared on the author's blog and has been republished with permission.

Jekyll's high degree of customization makes it easy to add dynamic logic to your otherwise static website.

Image by:

Jonas Leupe on Unsplash

Web development Open Studio What to read next A practical guide to light and dark mode in Jekyll How I dynamically generate Jekyll config files This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

Why use Apache Druid for your open source analytics database David Wang Thu, 04/28/2022 - 03:00 Up Register or Login to like.

Analytics isn't just for internal stakeholders anymore. If you're building an analytics application for customers, you're probably wondering what the right database backend is for you.

Your natural instinct might be to use what you know, like PostgreSQL or MySQL. You might even think to extend a data warehouse beyond its core BI dashboards and reports. Analytics for external users is an important feature, though, so you need the right tool for the job.

The key to answering this comes down to user experience. Here are some key technical considerations for users of your external analytics apps.

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 Avoid delays with Apache Druid

The waiting game of processing queries in a queue can be annoying. The root cause of delays comes down to the amount of data you're analyzing, the processing power of the database, and the number of users and API calls, along with the ability for the database to keep up with the application.

There are a few ways to build an interactive data experience with any generic Online Analytical Processing (OLAP) database when there's a lot of data, but they come at a cost. Pre-computing queries makes architecture very expensive and rigid. Aggregating the data first can minimize insight. Limiting the data analyzed to only recent events doesn't give your users the complete picture.

The "no compromise" answer is an optimized architecture and data format built for interactivity at scale, which is precisely what Apache Druid, a real-time database designed to power modern analytics applications, provides.

• First, Druid has a unique distributed and elastic architecture that pre-fetches data from a shared data layer into a near-infinite cluster of data servers. This architecture enables faster performance than a decoupled query engine like a cloud data warehouse because there's no data to move and more scalability than a scale-up database like PostgreSQL and MySQL.

• Second, Druid employs automatic (sometimes called "automagic") multi-level indexing built right into the data format to drive more queries per core. This is beyond the typical OLAP columnar format with the addition of a global index, data dictionary, and bitmap index. This maximizes CPU cycles for faster crunching.

High Availability can't be a "nice to have"

If you and your dev team build a backend for internal reporting, does it really matter if it goes down for a few minutes or even longer? Not really. That's why there's always been tolerance for unplanned downtime and maintenance windows in classical OLAP databases and data warehouses.

But now your team is building an external analytics application for customers. They notice outages, and it can impact customer satisfaction, revenue, and definitely your weekend. It's why resiliency, both high availability and data durability, needs to be a top consideration in the database for external analytics applications.

Rethinking resiliency requires thinking about the design criteria. Can you protect from a node or a cluster-wide failure? How bad would it be to lose data, and what work is involved to protect your app and your data?

Servers fail. The default way to build resiliency is to replicate nodes and remember to make backups. But if you're building apps for customers, the sensitivity to data loss is much higher. The occasional backup is just not going to cut it.

The easiest answer is built right into Apache Druid's core architecture. Designed to withstand anything without losing data (even recent events), Apache Druid features a capable and simple approach to resiliency.

Druid implements High Availability (HA) and durability based on automatic, multi-level replication with shared data in object storage. It enables the HA properties you expect, and what you can think of as continuous backup to automatically protect and restore the latest state of the database even if you lose your entire cluster.

More users should be a good thing

The best applications have the most active users and engaging experience, and for those reasons architecting your back end for high concurrency is important. The last thing you want are frustrated customers because applications are getting hung up. Architecting for internal reporting is different because the concurrent user count is much smaller and finite. The reality is that the database you use for internal reporting probably just isn't the right fit for highly-concurrent applications.

Architecting a database for high concurrency comes down to striking the right balance between CPU usage, scalability, and cost. The default answer for addressing concurrency is to throw more hardware at it. Logic says that if you increase the number of CPUs, you'll be able to run more queries. While true, this can also be a costly approach.

A better approach is to look at a database like Apache Druid with an optimized storage and query engine that drives down CPU usage. The operative word is "optimized." A database shouldn't read data that it doesn't have to. Use something that lets your infrastructure serve more queries in the same time span.

Saving money is a big reason why developers turn to Apache Druid for their external analytics applications. Apache Druid has a highly optimized data format that uses a combination of multi-level indexing, borrowed from the search engine world, along with data reduction algorithms to minimize the amount of processing required.

The net result is that Apache Druid delivers far more efficient processing than anything else out there. It can support from tens to thousands of queries per second at Terabyte or even Petabyte scale.

Build what you need today but future-proof it

Your external analytics applications are critical for your users. It's important to build the right data architecture.

The last thing you want is to start with the wrong database, and then deal with the headaches as you scale. Thankfully, Apache Druid can start small and easily scale to support any app imaginable. Apache Druid has excellent documentation, and of course it's open source, so you can try it and get up to speed quickly.

Your external analytics applications are critical for your users. It's important to build the right data architecture.

Image by:

Opensource.com

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

Install LineageOS on Samsung s7 phone using Linux Mint - Cell Phones  BleepingComputer