Open-source News

AlmaLinux, CentOS Stream, Clear Linux, Debian, Fedora & Ubuntu On AMD 4th Gen EPYC Genoa

Phoronix - Wed, 01/04/2023 - 20:30
Over the holidays some fun benchmarking was to be had with the dual AMD EPYC 9654 "Genoa" processors providing a combined 192 cores / 384 threads and seeing how various modern Linux distributions were competing for this flagship 4th Gen EPYC server configuration. Up on the testing block was AlmaLinux 9.1, CentOS Stream 9, Clear Linux 37930, Debian 12 Testing, Fedora Server 37, Ubuntu 22.04.1 LTS, Ubuntu 22.10, and Ubuntu 23.04 daily.

RADV Lands A Few More Improvements To Reduce CPU Overhead

Phoronix - Wed, 01/04/2023 - 20:00
Samuel Pitoiset of Valve's Linux graphics team has landed a few patches into Mesa 23.0 for further reducing the CPU overhead of the Vulkan driver's draw path...

Intel Adds "Emerald Rapids" Support To The GCC 13 Compiler

Phoronix - Wed, 01/04/2023 - 19:19
Since GCC 11 there has been support for AMX and the upcoming Sapphire Rapids CPU features, which has been further improved in the open-source compiler over the past two years. GCC 13 meanwhile as the next GNU Compiler Collection release is bringing Meteor Lake and Sierra Forest, Grand Ridge, and Granite Rapids. Basic enablement of Intel's Emerald Rapids meanwhile was merged yesterday for GCC 13 too...

Microsoft's CBL-Mariner 2.0.20221222 Linux Distro Now Allows Hibernation, More Packages

Phoronix - Wed, 01/04/2023 - 19:03
Microsoft released CBL-Mariner 2.0.20221222 on Tuesday as their first update of 2023 for their in-house Linux distribution that is used for a variety of purposes within the company from Azure to other behind-the-scenes Linux OS use...

GNOME's Mutter Now Allows Building Without XWayland - Nearing Optional X11

Phoronix - Wed, 01/04/2023 - 18:47
GNOME's Mutter now allows disabling XWayland support at build-time if so desired. This is part of the broader GNOME effort for making X11 support optional and ultimately allowing for a modern Wayland-only environment if so desired and without carrying legacy X11 cruft...

Customize Apache ShardingSphere high availability with MySQL

opensource.com - Wed, 01/04/2023 - 16:00
Customize Apache ShardingSphere high availability with MySQL zhaojinchao Wed, 01/04/2023 - 03:00

Users have many options to customize and extend ShardingSphere's high availability (HA) solutions. Our team has completed two HA plans: A MySQL high availability solution based on MGR and an openGauss database high availability solution contributed by some community committers. The principles of the two solutions are the same.

Below is how and why ShardingSphere can achieve database high availability using MySQL as an example:

Image by:

(Zhao Jinchao, CC BY-SA 4.0)

Prerequisite

ShardingSphere checks if the underlying MySQL cluster environment is ready by executing the following SQL statement. ShardingSphere cannot be started if any of the tests fail.

Check if MGR is installed:

SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME='group_replication'

View the MGR group member number. The underlying MGR cluster should consist of at least three nodes:

SELECT COUNT(*) FROM performance_schema.replication_group_members

Check whether the MGR cluster's group name is consistent with that in the configuration. The group name is the marker of an MGR group, and each group of an MGR cluster only has one group name:

SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME='group_replication_group_name' 

Check if the current MGR is set as the single primary mode. Currently, ShardingSphere does not support dual-write or multi-write scenarios. It only supports single-write mode:

SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME='group_replication_single_primary_mode'

Query all the node hosts, ports, and states in the MGR group cluster to check if the configured data source is correct:

SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE FROM performance_schema.replication_group_membersDynamic primary database discovery

ShardingSphere finds the primary database URL according to the query master database SQL command provided by MySQL:

private String findPrimaryDataSourceURL(final Map<String, DataSource> dataSourceMap) {
    String RESULT = "";
    String SQL = "SELECT MEMBER_HOST, MEMBER_PORT FROM performance_schema.replication_group_members WHERE MEMBER_ID = "
            + "(SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME = 'group_replication_primary_member')";
    FOR (DataSource each : dataSourceMap.values()) {
        try (Connection connection = each.getConnection();
             Statement statement = connection.createStatement();
             ResultSet resultSet = statement.executeQuery(SQL)) {
            IF (resultSet.next()) {
                RETURN String.format("%s:%s", resultSet.getString("MEMBER_HOST"), resultSet.getString("MEMBER_PORT"));
            }
        } catch (final SQLException ex) {
            log.error("An exception occurred while find primary data source url", ex);
        }
    }
    RETURN RESULT;
}

Compare the primary database URLs found above one by one with the dataSources URLs configured. The matched data source is the primary database. It will be updated to the current ShardingSphere memory and be perpetuated to the registry center, through which it will be distributed to other compute nodes in the cluster.

Image by:

(Zhao Jinchao, CC BY-SA 4.0)

Dynamic secondary database discovery

There are two types of secondary database states in ShardingSphere: enable and disable. The secondary database state will be synchronized to the ShardingSphere memory to ensure that read traffic can be routed correctly.

Get all the nodes in the MGR group:

SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE FROM performance_schema.replication_group_members

Disable secondary databases:

private void determineDisabledDataSource(final String schemaName, final Map<String, DataSource> activeDataSourceMap,
                                         final List<String> memberDataSourceURLs, final Map<String, String> dataSourceURLs) {
    FOR (Entry<String, DataSource> entry : activeDataSourceMap.entrySet()) {
        BOOLEAN disable = TRUE;
        String url = NULL;
        try (Connection connection = entry.getValue().getConnection()) {
            url = connection.getMetaData().getURL();
            FOR (String each : memberDataSourceURLs) {
                IF (NULL != url && url.contains(each)) {
                    disable = FALSE;
                    break;
                }
            }
        } catch (final SQLException ex) {
            log.error("An exception occurred while find data source urls", ex);
        }
        IF (disable) {
            ShardingSphereEventBus.getInstance().post(NEW DataSourceDisabledEvent(schemaName, entry.getKey(), TRUE));
        } ELSE IF (!url.isEmpty()) {
            dataSourceURLs.put(entry.getKey(), url);
        }
    }
}

Whether the secondary database is disabled is based on the data source configured and all the nodes in the MGR group.

ShardingSphere can check one by one whether the data source configured can obtain Connection properly and verify whether the data source URL contains nodes of the MGR group.

If Connection cannot be obtained or the verification fails, ShardingSphere will disable the data source by an event trigger and synchronize it to the registry center.

Enable secondary databases:

private void determineEnabledDataSource(final Map<String, DataSource> dataSourceMap, final String schemaName,
                                        final List<String> memberDataSourceURLs, final Map<String, String> dataSourceURLs) {
    FOR (String each : memberDataSourceURLs) {
        BOOLEAN enable = TRUE;
        FOR (Entry<String, String> entry : dataSourceURLs.entrySet()) {
            IF (entry.getValue().contains(each)) {
                enable = FALSE;
                break;
            }
        }
        IF (!enable) {
            continue;
        }
        FOR (Entry<String, DataSource> entry : dataSourceMap.entrySet()) {
            String url;
            try (Connection connection = entry.getValue().getConnection()) {
                url = connection.getMetaData().getURL();
                IF (NULL != url && url.contains(each)) {
                    ShardingSphereEventBus.getInstance().post(NEW DataSourceDisabledEvent(schemaName, entry.getKey(), FALSE));
                    break;
                }
            } catch (final SQLException ex) {
                log.error("An exception occurred while find enable data source urls", ex);
            }
        }
    }
}

After the crashed secondary database is recovered and added to the MGR group, the configuration will be checked to see whether the recovered data source is used. If yes, the event trigger will tell ShardingSphere that the data source needs to be enabled.

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 Heartbeat mechanism

The heartbeat mechanism is introduced to the HA module to ensure that the primary-secondary states are synchronized in real-time.

By integrating the ShardingSphere sub-project ElasticJob, the above processes are executed by the ElasticJob scheduler framework in the form of Job when the HA module is initialized, thus achieving the separation of function development and job scheduling.

Even if developers need to extend the HA function, they do not need to care about how jobs are developed and operated:

private void initHeartBeatJobs(final String schemaName, final Map<String, DataSource> dataSourceMap) {
    Optional<ModeScheduleContext> modeScheduleContext = ModeScheduleContextFactory.getInstance().get();
    IF (modeScheduleContext.isPresent()) {
        FOR (Entry<String, DatabaseDiscoveryDataSourceRule> entry : dataSourceRules.entrySet()) {
            Map<String, DataSource> dataSources = dataSourceMap.entrySet().stream().filter(dataSource -> !entry.getValue().getDisabledDataSourceNames().contains(dataSource.getKey()))
                    .collect(Collectors.toMap(Entry::getKey, Entry::getValue));
            CronJob job = NEW CronJob(entry.getValue().getDatabaseDiscoveryType().getType() + "-" + entry.getValue().getGroupName(),
                each -> NEW HeartbeatJob(schemaName, dataSources, entry.getValue().getGroupName(), entry.getValue().getDatabaseDiscoveryType(), entry.getValue().getDisabledDataSourceNames())
                            .execute(NULL), entry.getValue().getHeartbeatProps().getProperty("keep-alive-cron"));
            modeScheduleContext.get().startCronJob(job);
        }
    }
}Wrap up

So far, Apache ShardingSphere's HA feature has proven applicable for MySQL and openGauss HA solutions. Moving forward, it will integrate more MySQL HA products and support more database HA solutions.

As always, if you're interested, you're more than welcome to join us and contribute to the Apache ShardingSphere project.

Apache ShardingSphere Open Source Project Links:

Learn how and why ShardingSphere can achieve database high availability using MySQL as an example.

Image by:

Image by Mapbox Uncharted ERG, CC-BY 3.0 US

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.

Learn to code with my retro computer program

opensource.com - Wed, 01/04/2023 - 16:00
Learn to code with my retro computer program Jim Hall Wed, 01/04/2023 - 03:00

I teach university courses part-time, including a class about general computing topics, open to all majors. This is an introductory course that teaches students about how technology works, to remove the mystery around computing.

While not a computer science course, one section of this course covers computer programming. I usually talk about programming in very abstract terms, so I don't lose my audience. But this year, I wanted my students to do some "hands-on" programming in an "old school" way. At the same time, I wanted to keep it simple, so everyone could follow along.

I like to structure my lessons to show how you got from "there" to "here." Ideally, I would let my students learn how to write a simple program. Then I would pick it up from there to show how modern programming allows developers to create more complex programs. I decided to try an unconventional approach — teach the students about the ultimate in low-level programming: machine language.

Machine language programming

Early personal computers like the Apple II (1977), TRS-80 (1977), and IBM PC (1981) let users enter programs with a keyboard, and displayed results on a screen. But computers didn't always come with a screen and keyboard.

The Altair 8800 and IMSAI 8080 (both made in 1975) required users to enter a program using "switches and lights" on a panel. You would enter an instruction in machine language, using a bank of switches, and the machine would light up the ones and zeros of each binary instruction using LEDs.

Image by:

(Cromemco, CC BY-NC-SA 3.0)

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 An open source developer's guide to building applications

Programming these early machines required knowing the machine language instructions, called opcodes, short for operation codes, to perform basic operations like adding two numbers or storing a value into the computer's memory. I wanted to show my students how programmers would enter a series of instructions and memory addresses by hand, using the switches and lights.

However, using an actual Altair 8800 would be too much overhead in this class. I needed something simple that any beginner-level student could grasp. Ideally, I hoped to find a simple "hobby" retro computer that worked similarly to the Altair 8800, but I couldn't find a suitable "Altair-like" device for less than $100. I found several "Altair" software emulators, but they faithfully reproduce the Altair 8800 opcodes, and that was too much for my needs.

I decided to write my own "educational" retro computer. I call it the Toy CPU. You can find it on my GitHub repository, including several releases to play with. Version 1 was an experimental prototype that ran on FreeDOS. Version 2 was an updated prototype that ran on Linux with ncurses. Version 3 is a FreeDOS program that runs in graphics mode.

Programming the Toy CPU

The Toy CPU is a very simple retro computer. Sporting only 256 bytes of memory and a minimal instruction set, the Toy CPU aims for simplicity while replicating the "switches and lights" programming model. The interface mimics the Altair 8800, with a series of eight LEDs for the counter (the "line number" for the program), instruction, accumulator (internal memory used for temporary data), and status.

When you start the Toy CPU, it simulates "booting" by clearing the memory. While the Toy CPU is starting up, it also displays INI ("initialize") in the status lights at the bottom-right of the screen. The PWR ("power") light indicates the Toy CPU has been turned on.

Image by:

(Jim Hall, CC BY-SA 4.0)

 

When the Toy CPU is ready for you to enter a program, it indicates INP ("input" mode) via the status lights, and starts you at counter 0 in the program. Programs for the Toy CPU always start at counter 0.

In "input" mode, use the up and down arrow keys to show the different program counters, and press Enter to edit the instruction at the current counter. When you enter "edit" mode, the Toy CPU shows EDT ("edit" mode) on the status lights.

Image by:

(Jim Hall, CC BY-SA 4.0)

The Toy CPU has a cheat sheet that's "taped" to the front of the display. This lists the different opcodes the Toy CPU can process:

  • 00000000 (STOP): Stop program execution.

  • 00000001 (RIGHT): Shift the bits in the accumulator to the right by one position. The value 00000010 becomes 00000001, and 00000001 becomes 00000000.

  • 00000010 (LEFT): Shift the bits in the accumulator to the left by one position. The value 01000000 becomes 10000000, and 10000000 becomes 00000000.

  • 00001111 (NOT): Binary NOT the accumulator. For example, the value 10001000 becomes 01110111.

  • 00010001 (AND): Binary AND the accumulator with the value stored at an address. The address is stored in the next counter.

  • 00010010 (OR): Binary OR the accumulator with the value stored at an address.

  • 00010011 (XOR): Binary XOR (“exclusive or”) the accumulator with the value stored at an address.

  • 00010100 (LOAD): Load (copy) the value from an address into the accumulator.

  • 00010101 (STORE): Store (copy) the value in the accumulator into an address.

  • 00010110 (ADD): Add the value stored at an address to the accumulator.

  • 00010111 (SUB): Subtract the value stored at an address from the accumulator.

  • 00011000 (GOTO): Go to (jump to) a counter address.

  • 00011001 (IFZERO): If the accumulator is zero, go to (jump to) a counter address.

  • 10000000 (NOP): No operation; safely ignored.

When in "edit" mode, use the left and right arrow keys to select a bit in the opcode, and press Space to flip the value between off (0) and on (1). When you are done editing, press Enterto go back to "input" mode.

Image by:

(Jim Hall, CC BY-SA 4.0)

A sample program

I want to explore the Toy CPU by entering a short program that adds two values, and stores the result in the Toy's memory. Effectively, this performs the arithmetic operation A+B=C. To create this program, you only need a few opcodes:

  • 00010100 (LOAD): Load (copy) the value from an address into the accumulator.

  • 00010110 (ADD): Add the value stored at an address to the accumulator.

  • 00010101 (STORE): Store (copy) the value in the accumulator into an address.

  • 00000000 (STOP): Stop program execution.

The LOAD, ADD, and STORE instructions require a memory address, which will always be in the next counter location. For example, the first two instructions of the program are:

counter 0: 00010100
counter 1: some memory address where the first value A is stored

The instruction in counter 0 is the LOAD operation, and the value in counter 1 is the memory address where you have stored some value. The two instructions together copy a value from memory into the Toy's accumulator, where you can work on the value.

Having loaded a number A into the accumulator, you need to add the value B to it. You can do that with these two instructions:

counter 2: 00010110
counter 3: a memory address where the second value B is stored

Say that you loaded the value 1 (A) into the accumulator, then added the value 3 (B) to it. The accumulator will now have the value 4. Now you need to copy the value 4 into another memory address (C) with these two instructions:

counter 4: 00010101
counter 5: a memory address (C) where we can save the new value

Having added the two values together, you can now end the program with this instruction:

counter 6: 00000000

Any instructions after counter 6 are available for the program to use as stored memory. That means you can use the memory at counter 7 for the value A, the memory in counter 8 for the value B, and the memory at counter 9 for the stored value C. You need to enter these separately into the Toy:

counter 7: 00000001 (1)
counter 8: 00000011 (3)
counter 9: 00000000 (0, will be overwritten later)

Having figured out all the instructions and the memory locations for A, B, and C, you can now enter the full program into the Toy. This program adds the values 1 and 3 to get 4:

counter 0: 00010100
counter 1: 00000111 (7)
counter 2: 00010110
counter 3: 00001000 (8)
counter 4: 00010101
counter 5: 00001001 (9)
counter 6: 00000000
counter 7: 00000001 (1)
counter 8: 00000011 (3)
counter 9: 00000000 (0, will be overwritten later)

To run the program, press the R key when in "input" mode. The Toy CPU will show RUN ("run" mode) in the status lights, and execute your program starting at counter 0.

The Toy has a significant delay built into it, so you can watch the Toy execute each step in the program. You should see the counter move from 00000000 (0) to 00000110 (6) as the program progresses. After counter 1, the program loads the value 1 from memory location 7, and the accumulator updates to 00000001 (1). After counter 3, the program will add the value 3 and update the accumulator to show 00000100 (4). The accumulator will remain that way until the program stores the value into memory location 9 after counter 5 then ends at counter 6.

Image by:

(Jim Hall, CC BY-SA 4.0)

Exploring machine language programming

You can use the Toy to create other programs and further explore machine language programming. Test your creativity by writing these programs in machine language.

A program to flash the lights on the accumulator

Can you light up the right four bits on the accumulator, then the left four bits, then all of the bits? You can write this program in one of two ways:

A straightforward approach would be to load three values from different memory addresses, like this:

counter 0: LOAD
counter 1: "right"
counter 2: LOAD
counter 3: "left"
counter 4: LOAD
counter 5: "all"
counter 6: STOP
counter 7: 00001111 ("right")
counter 8: 11110000 ("left")
counter 9: 11111111 ("all")

Another way to write this program is to experiment with the NOT and OR binary operations. This results in a smaller program:

counter 0: LOAD
counter 1: "right"
counter 2: NOT
counter 3: OR
counter 4: "right"
counter 5: STOP
counter 6: 00001111 ("right")Count down from a number

You can use the Toy as a countdown timer. This program exercises the IFZERO test, which will jump the program to a new counter only if the accumulator is zero:

counter 0: LOAD
counter 1: "initial value"
counter 2: IFZERO (this is also the "start" of the countdown)
counter 3: "end"
counter 4: SUB
counter 5: "one"
counter 6: GOTO
counter 7: "start"
counter 8: STOP
counter 9: 00000111 ("initial value")
counter 10: 00000001 ("one")

The Toy CPU is a great way to learn about machine language. I used the Toy CPU in my introductory course, and the students said they found it difficult to write the first program, but writing the next one was much easier. The students also commented that writing programs in this way was actually fun, and they learned a lot about how computers actually work. The Toy CPU is educational and fun!

I wrote an educational retro computer called the Toy CPU so that my students could learn about machine language.

Image by:

Opensource.com

Programming Education 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.

How to Use “mv” Command in Linux [9 Useful Examples]

Tecmint - Wed, 01/04/2023 - 15:48
The post How to Use “mv” Command in Linux [9 Useful Examples] first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

Brief: In this beginner’s guide, we will discuss some practical examples of the mv command. After following this guide, Linux newbies will be able to rename and move files and directories easily from the

The post How to Use “mv” Command in Linux [9 Useful Examples] first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

Kalray Posts Initial Patches For Bringing Up Linux On Their KV3-1 "Coolidge" DPU SoC

Phoronix - Wed, 01/04/2023 - 05:45
While back in 2018 when the C-SKY architecture was merged to the Linux kernel it was talked about possibly being the last new CPU arch/port to be mainlined given the growing success of RISC-V even back then, it looks like that upstream kernel developer belief might not hold true. France-based Kalray that focuses on high-performance, data-centric computing from cloud to edge posted their initial Linux kernel patches today for their "KVX" kernel port to get the kernel running on their MPPA3-80 "Coolidge" DPU SoC with the KV3-1 CPU architecture...

Pages