This month’s newsletter will be one of our biggest ever! In October, our communities met in person at the Open Source Summit Europe in Bilbao and KubeCon + CloudNativeCon + OSS in Shanghai, China.  At OpenSSF’s Secure Open Source Summit in Washington, DC, we continued advancing important conversations to improve the security of software supply chains. We had a record month at LF Research, with four new reports published since our last newsletter on brand new topics, including the mobile industry and Europe’s public sector, and year-over-year trends specific to European open source and the state of the OSPO. And, of course, there’s lots of project news for you to catch up on, including the announcement of OpenPubkey, a zero-trust passwordless authentication system for Docker.

Read the October Newsletter at the Linux Foundation Blog

The post Linux Foundation Newsletter: October 2023 appeared first on Linux.com.

In 2022, the Linux Foundation, in collaboration with our community, engaged in new initiatives to secure the software supply chain, enabled innovations with social, economic, regional, and environmental impact, supported open industry standards, and continued to embrace diversity and inclusivity.  Read the report today.

The post Linux Foundation Annual Report 2022: Leadership in Security and Innovation appeared first on Linux.com.

The post LF Research: One Year Recap and Imagining the Future appeared first on Linux Foundation.

The post LF Research: One Year Recap and Imagining the Future appeared first on Linux.com.

• Part 1. Review of a kernel module, build strategy, and Ada integration.
• Part 2. Modeling of the problem in Ada.
• Part 3. Practical Ada binding to the C kernel APIs.

You can find the whole project published at https://github.com/ohenley/adacore_jetson. It is known to build and run properly. All instructions to be up and running in 5 minutes are included in the accompanying front-facing README.md. Do not hesitate to fill a Github issue if you find any problem.

Disclaimer: This text is meant to appeal to both Ada and non-Ada coders. Therefore I try to strike a balance between code story simplicity, didactic tractability, and features density. As I said to a colleague, this is the text I would have liked to cross before starting this experiment.

What’s in the Ada name?

Delightfully said by Rod Chapman in his great SPARKNaCL presentation https://blog.adacore.com/sparknacl-two-years-of-optimizing-crypto-code-in-spark-and-counting, the Ada programming language is “Pascal on steroids”. Though, I would argue that the drug is healthy. Thriving on strong typing and packaging, Ada has excellent modelization scalability yet remains on par with C performances. 

It compiles native object code using a GCC front-end or LLVM, respectively called GNAT and GNAT-LLVM.  This leads us to an important reminder: Ada, at least through GNAT, has an application binary interface (ABI) compatible with C on Linux.

Linux driver experiment in Ada, but why?

• First clearing the technical plumbing in Ada facilitates moving to SPARK/Ada where significant value can be added by improving drivers implementation using contracts, pointer ownership, advanced static analysis and associated proof technologies.
• Share Ada’s bare-metal capability, expressivity, and productivity as a system/embedded programming language.
• Demonstrate that Ada sits well at the foundation of heterogeneous real-world technology stacks.

Note that as Ada code is not accepted in the upstream kernel sources and the Linux team made it clear it is not interested in providing a stable kernel API, writing Linux drivers shipped in Ada/SPARK mean you will have to adapt those drivers to all kernel version you are interested in, which is a task outside the scope of this document. For single kernel versions, proofs-of-concept, or organizations having enough firepower to maintain and curate their own drivers this is not an issue though.

Kernel module headfirst

Let’s discuss our overall driver structure from an orthodox C perspective. It will allow us to clear important know-how and gotchas. The following C kernel module (driver) implements a one-second delayed work queue repeatedly registering a callback writing “flip_led_state” to the kernel message buffer. Please, note the usage of the preprocessing macros.

/* printk_wq.c */

#include <linux/module.h>
#include <linux/workqueue.h>
#include <linux/timer.h>

void delayed_work_cb(struct work_struct* work);
struct workqueue_struct* wq = 0;
DECLARE_DELAYED_WORK(dw, delayed_work_cb);   /* heavy lifting 1. */

void delayed_work_cb(struct work_struct* work)
{
   printk("flip_led_state\n");
   queue_delayed_work(wq, &dw, msecs_to_jiffies(1000));
}

int init_module(void)
{
   if (!wq)
       wq = create_singlethread_workqueue("my_wq"); /* heavy lifting 2. */
   if (wq)
       queue_delayed_work(wq, &dw, msecs_to_jiffies(1000));
   return 0;
}

void cleanup_module(void)
{
   if (wq){
       cancel_delayed_work(&dw);
       flush_workqueue(wq);
       destroy_workqueue(wq);
   }
}

MODULE_LICENSE("GPL");

When building a kernel module on Linux the produced Executable and Linkable Format (ELF)  object code file bears the *.ko extension. If we inspect the content of the working printk_wq.ko kernel module we can sketch the gist of binding to kernel module programming.

$ nm printk_wq.ko
...
                 U __alloc_workqueue_key
                 U cancel_delayed_work
00000000000000a0 T cleanup_module
0000000000000000 T delayed_work_cb
                 U delayed_work_timer_fn
                 U destroy_workqueue
0000000000000000 D dw
                 U flush_workqueue
0000000000000000 T init_module
                 U _mcount
0000000000000028 r __module_depends
                 U printk
                 U queue_delayed_work_on
0000000000000000 D __this_module
0000000000000000 r __UNIQUE_ID_license45
0000000000000031 r __UNIQUE_ID_vermagic44
0000000000000000 r ____versions

First, we recognize function/procedure names used in our source code eg. cancel_delayed_work. We also find that they are undefined (U). It is important to realize that those are the kernel’s source symbols and their object code will be resolved dynamically at driver/module load time. Correspondingly, all those undefined signatures can be found somewhere in the kernel source code headers of your target platform.

Second, we are missing some methods we explicitly called, eg.  create_singlethread_workqueue, in the symbol table.  This is because they are not, in fact, functions/procedures but convenience macros that expand to concrete implementations named differently and potentially have a different signature altogether or static inline not visible outside. For example, laying out the create_singlethread_workqueue explicit macro expansion from the Linux sources makes it clear. (Follow order, not preprocessor validation order)

/* https://elixir.bootlin.com/linux/v4.9.294/source/include/linux/workqueue.h*/

#define create_singlethread_workqueue(name)				\
	alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
...
#define alloc_ordered_workqueue(fmt, flags, args...)			\
	alloc_workqueue(fmt, WQ_UNBOUND | __WQ_ORDERED |		\
			__WQ_ORDERED_EXPLICIT | (flags), 1, ##args)
...
#define alloc_workqueue(fmt, flags, max_active, args...)		\
	__alloc_workqueue_key((fmt), (flags), (max_active),		\
			      NULL, NULL, ##args)
...
extern struct workqueue_struct *
__alloc_workqueue_key(const char *fmt, unsigned int flags, int max_active,
	struct lock_class_key *key, const char *lock_name, ...) __printf(1, 6);

Now everything makes sense. __alloc_workqueue_key is marked ‘extern’ and we find its signature in the printk_wq.ko symbol table. Note that we moved from create_singlethread_workqueue taking a single parameter to __alloc_workqueue_key taking more than five arguments. A logical conclusion, as deduced while following the explicit expansion up here, is that the arguments delta are all baked at the preprocessor stage. ‘Baking’ parameters using macros chaining offer polymorphism opportunities for kernel developers. Eg. compiling for arm64 may expand the macros differently than on RISC-V while offering both to retain a unified create_singlethread_workqueue(name) call for device driver developers to use; client of this ‘kernel API function’.

To get an Ada equivalent implementation of this driver I think of three choices when faced with a binding:

I will present an example of each in subsequent parts.

Platform driver and device driver

A Linux kernel module code structure is somewhat simple: you implement an init function, a deinit function. You have other requirements like supporting code reentry (eg. entering function may be called many times asynchronously) and you should not stall (eg. you do not run a game loop inside any kernel driver function). Optionally, if you are doing a platform (subsystem) driver, you need to register callbacks to polymorph a kernel interface of your choice. There is more to it, but you can get a long way just within this structure.

If you were to replace the shipped GPIO platform driver on your target machine, without breaking anything, your driver code would need to provide a concrete implementation of methods exposed in the linux/gpio/driver.h API. Below is some Tegra GPIO platform driver implementation code. If you start from the end, subsys_initcall(tegra_gpio_init), you should find that registering the driver sets a probe callback, in turn setting tegra_gpio_direction_output as the gpio_chip direction_output concrete code.

/* linux/gpio/driver.h */
struct gpio_chip {
	int	(*direction_output)(struct gpio_chip *chip, 
                                unsigned offset, int value);
}

/* drivers/gpio/gpio-tegra.c */
struct tegra_gpio_info {
	struct gpio_chip		gc;
};
static int tegra_gpio_direction_output(struct gpio_chip *chip, 
                                       unsigned offset, int value)
{
...
	return 0;
}
static int tegra_gpio_probe(struct platform_device *pdev)
{
	tgi->gc.direction_output = tegra_gpio_direction_output;
}
static struct platform_driver tegra_gpio_driver = {
	.probe		= tegra_gpio_probe,
};
static int __init tegra_gpio_init(void)
{
	return platform_driver_register(&tegra_gpio_driver);
}
subsys_initcall(tegra_gpio_init);

subsys_initcall is used to build statically linked module only and serves to implement platform driver. init_module can be used to init a built-in or loadable module but subsys_initcall is guaranteed to be executed before init_module. For this experiment we implemented a device driver making use of init_module.

To step into an Ada implementation we needed to concede by creating our driver entry point in C first.

/* main c */

#include <linux/module.h>

extern void ada_init_module (void);
extern void ada_cleanup_module (void);

int init_module(void)
{
   ada_init_module();
   return 0;
}

void cleanup_module(void)
{
   ada_cleanup_module();
}

MODULE_LICENSE("GPL");

The need for a restricted runtime

If you compile the following C code using your default Linux desktop compiler toolchain

STR="void main(){}" && echo -e $STR | gcc -o output.o -xc -

And inspect its symbol table

$ nm output.o 
...
0000000000400510 T __libc_csu_init
                 U __libc_start_main@GLIBC_2.2.5
00000000004004f6 T main
                 U printf@GLIBC_2.2.5
...

You find references to libc you did not explicitly ask for. You need the heads-up that those undefined (U) won’t be resolved at kernel module loading. A lot of libc implements stuff at the userspace level which is not compatible with the kernel operations so it is forbidden altogether.

Using system default GCC, make calling Kbuild using a special syntax, Kbuild will automatically strip those dependencies to libc for you to produce a valid kernel module (*.ko). But what happens when you link object code ‘compiled as usual’ from another rich and complex language like Ada to your kernel module? The object code will most certainly contain machinery from the language runtime, complex routines that end up tapping in libc, or other forbidden operations in the kernel context. This is where you need a constrained, reduced runtime for your language of choice.

What is cool with Ada though is that the GNAT infrastructure has runtime separation architectured to be swapped. Using AdaCore codebases, you can build your runtime by embarking on just what you want/need in it to link against. GNAT Ada runs on countless barebone platforms so the runtime granularity and dependency problems have already, most of the time, been handled for you. To initialize this runtime properly you are given sensible control on where and when to run some elaboration code; more on that later when we cover the Ada side of things.

For this experiment, we built a light aarch64-linux native runtime compatible to run in kernel space while retaining convenient aspects of the language, eg. the secondary stack. Using the https://github.com/AdaCore/bb-runtimes scripts, we augmented a new target aarch64-linux and built the runtime. Getting to know ‘how to do’ took longer, building it takes seconds. You can find and use this runtime in the experiment repository under rts-native-light/ when cross compiling using GNAT Pro. If you are building using the platform GNAT FSF the runtime is found under rts-native-zfp/?.

Kbuild integration

Kbuild is somewhat flexible so GNAT object code can be linked into the kernel driver without too much effort. As implied previously, make understands syntax to leverage and activate Kbuild, eg. to produce our driver called flash_led.ko, start from transient flash_led.o that depends on obj/bundle.o to build. Our module makefile uses this special syntax

obj-m := flash_led.o
flash_led-y := obj/bundle.o

You can ‘trick’ Kbuild/make by providing already existing .o files as long as you also provide dependable *.o.cmd intermediary files to Kbuild. We leverage such substitution by coordinating GPRbuild (GNAT build system), Kbuild/make, and touch using Python. There are two phases, generate and build.

Generate

$ python make.py generate config:flash_led_jetson_nano.json

1. Build, in the background, a bare minimum known to be valid main_template.c kernel driver and extract the compilation switches used by make/Kbuild to successfully produce this main_template.ko guinea pig module. There are around ~80 such GCC switches captured and used to generate the basic, valid *.ko for this kernel-based v4.9.294, arm64 platform. This ‘buried deep into Kbuild’ knowledge extraction turned out to be key in stabilizing the production of valid kernel object code. Note that this trick should work well for any platform because it extracts its specifics.

2. Generate the GPRbuild project file injecting those ~80 switches for the compilation of our project main.c along with all Ada source files using different project configuration data found in the JSON file.

3. Generate Makefile using knowledge of configuration data compliant with Kbuild syntax (cross compiler location, project name, etc found in the JSON file).

You can inspect the different templates and their substitution markers eg. <replace_me_token> by looking inside the template folder of the project repository.

Build

python make.py build config:flash_led_jetson_nano.json rts:true

1. Build the GNAT runtime library (RTS) libgnat.a by driving its runtime_build.gpr project file. (optional on subsequent passes)

2. Build our driver project standalone library libflash_led.a using the generated GPRbuild project file.

3. Link our custom RTS libgnat.a with our project libflash_led.a to a tidy bundle.o object.

4. Create missing *.o.cmd intermediary files to keep Kbuild happy. Remember we are swapping already built objects under its nose!

5. Finally, launch the makefile to cross-compile our flash_led.ko driver for the Jetson Nano aarch64 platform!

The Ada driver

For this experiment we did two implementations of Led.adb (body file, Ada equivalent of C .c source file), one at src/linux_interface/led.adb, the other under src/raw_io/led.adb. You specify which driver implementation you want to build by setting “module_flavor” value in flash_led_jetson_nano.json. make.py will inject the proper source paths in the project driver flash_led.gpr file during the generate phase.

The first version implementation of the LED interface binds to standard kernel API Gpio_Request, Gpio_Direction_Output, Gpio_Get_Value, and Gpio_Free functions exposed in include/linux/gpio.h. This is rather straightforward as the binding is mostly one-to-one to the C functions. In this linux_interface version, as soon as you bind, you end up executing the C concrete implementation of the shipped GPIO driver.

Circumventing most Linux machinery, the second raw_io version implementing the LED interface is more interesting as we control the GPIO directly by writing to IO memory registers. Akin to doing bare-metal, directly driving GPIOs is a matter of configuring some IO registers mapped in physical memory. Remember an OS serves the role of a hardware orchestrator and consequently acts as having implicit ownership over your hardware. To tap directly onto physical memory in a kernel context often requires some kind of red tape crossing.

Here Linux requires (strongly suggests?) you write/read to kernel mapped memory instead of directly to physical memory. First, you need to acquire the kernel-mapped physical address using the in/famous ioremap call. Using the mapped address we read and write to our GPIO registers using ioread32 and iowrite32 respectively. This is the only Linux machinery involved in this raw_io version. As you probably figure this is more a peek at what one would code inside a driver responsible to implement the concrete implementations of functions offered by something like include/linux/gpio.h. We will even end up writing assembly code from Ada to achieve pure rawness!

What‘s next?

I had to set the table to write Linux kernel modules in Ada by first talking about C, object code, Kbuild, constrained runtime, and overall build strategy. The streamlined fun begins as we cross the Ada fence. If I picked your curiosity and you are ready to dig Ada, meet me here. Cheers!

I want to thank Quentin Ochem, Nicolas Setton, Fabien Chouteau, Jerome Lambourg, Michael Frank, Derek Schacht, Arnaud Charlet, Pat Bernardi, Leo Germond, and Artium Nihamkin for their different insights and feedback to nail this experiment.

The author, Olivier Henley, is a UX Engineer at AdaCore. His role is exploring new markets through technical stories. Prior to joining AdaCore, Olivier was a consultant software engineer for Autodesk. Prior to that, Olivier worked on AAA game titles such as For Honor and Rainbow Six Siege in addition to many R&D gaming endeavors at Ubisoft Montreal. Olivier graduated from the Electrical Engineering program in Polytechnique Montreal. He is a co-author of patent US8884949B1, describing the invention of a novel temporal filter implicating NI technology. An Ada advocate, Olivier actively curates GitHub’s Awesome-Ada list.

The post Hacking the Linux Kernel in Ada – Part 1 appeared first on Linux.com.

Moreover, technological development is the backbone of our understanding of the 21st century. The new technologies define our era and make it possible to understand the creations of contemporary human beings: their science, their way of living, their cultural habits, so on.

Contemporary humankind is impossible to be understood without the constant company of technology that allows them to improve and expand their senses. Today, technology has become an extension of the human body.

The human being today is a subject made by technology. Men and women have thus shown themselves to be irremediably permeable to technology, a technology that goes beyond them. The main question is: who is in charge of this factory? With what interests? Who is making us? Who is designing us?

Utopia and dystopia

Since August 1991, when the World Wide Web was made public as a service, the Internet has spread all over the planet and become famous. The first heroic times led to the birth of an autonomous, free zone outside the control of the power of governments and large companies. A place in which to create and communicate without restrictions. A vast blank page on which to start building.

However, the idea of collective intelligence was gradually eroded by the advance of simplifying globalization, ultimately capable of fostering unidirectional and unidimensional currents of communication contrary to the illusionary possibilities from which it started. At the same time, we assist in the triumphal beginning of “democracy,” a new kind of power based on the control (monopoly) of specific tools.

In the end, the medium prevailed over the messages, and the “wall” of the social networks ended up being a torrent of disinformation and banalities. The Internet thus became a way of looking at oneself in a mirror, of forming a continuous selfie based on not seeing beyond prejudice and the saturation of information and images—a tool of individualism and separation from reality. And, what is even worse, an infinite source of personal data to be traded.

Collaboration against individualism

Against the main currents determined by tech giants, there are still many possibilities of using the ways in alternative ways, understanding the vast opportunities open by technologies, some usually forgotten by people.

Facing the idea of an Internet of massive and monolithic movements, there is another open possibility: the return to the collective, to the community, and its needs. Open source thus becomes the counterweight to the dangers of indiscriminate use and the generation of information noise on the Internet.

Open-source projects refer to software development with a license that gives access to the source code so that programmers can freely use, write, modify, and redistribute the code. Open source is developed collaboratively and distributed over the Internet. It allows generating a product with a continuous improvement from the hand of a dedicated community.

AsyncAPI is a project that considers that human beings have naturalized the tools that enhance their capacities. Technology can guide us and define our steps. It’s not merely daily practice. We should be more aware that we humans make technology and that we are the ones who create and determine the future it holds for us. We are the ones who build the future.

The light between the walls

Transparency and horizontality are the axes on which this movement is settled. The absolute exposure of a project or company’s work, economy, and politics in a society with such opaque foundations represent a return to the initial roots of the Internet. In this autonomous zone, projects are built from the ground up.

Doing things following the open-source philosophy promotes a working system based on the open exchange of ideas, teamwork-based on flexibility, and constant innovation.

This working model clashes head-on with a system based mainly on competitiveness and concealment. It appears a stepping stone to repeal opaque and oppressive government models and a step towards a freer, more transparent, and equitable society.

Collaborating in an open-source project offers you the opportunity of a community of people involved and enthusiastic about the same goal. At AsyncAPI, everyone is welcome, regardless of their sector, their experience… all you need is enthusiasm. This enthusiasm is based on the idea that another world is possible, even more so in times of climate emergency and global crisis. Technology is the only tool in our hands to shape it. It is the key element of cultural, social, and political struggle. It cannot be left in other hands. It must be built collectively, with the community’s needs and users in mind.

You don’t take technology; you make it.

The author, Barbaño González, is Education Program Manager at AsyncAPI.

The post Made by Technology appeared first on Linux.com.

In 2021, The Linux Foundation continued to see organizations embrace open collaboration and open source principles, accelerating new innovations, approaches, and best practices. As a community, we made significant progress in the areas of cloud-native computing, 5G networking, software supply chain security, 3D gaming, and a host of new industry and social initiatives.

Download and read the report today.

The post Download the 2021 Linux Foundation Annual Report appeared first on Linux.com.

The post Microsoft’s Dapr Becomes CNCF Incubation Project appeared first on Linux.com.

Introduction

• Back in 2005, IBM wanted to promote Linux, so developerWorks was offering $1000 per article to IBMers who wrote articles for the Linux Zone. The 2005 article is no longer online from IBM but is available on ResearchGate https://www.researchgate.net/publication/272094609_Linux_screensaver_for_Windows for the interested reader.
• This software still works and is still fun to use and to decorate your Windows desktop.
• Since 2005, there have been improvements and changes. Debian is now used instead of the original KNOPPIX. Additionally, full mouse integration now works between Windows and the screensaver due to kernel contributions.
• Future possibilities probably lie with the integration of hardware virtualization acceleration.
• Like all software of significant size, many components need tracking. The modern standard for this is SPDX and SBOM; as this screensaver is built fully from public source code, it makes a cool demo for SPDX and SBOM, which anyone may use.
• Though putting Linux on screen saver is a very interesting idea, there is a bit of a downside: power consumption. Screen savers initially proposed to protect the screen by providing moving pixels (by activating different pixels to avoid pixels burnin) when the user is not using their screen. If the power/energy option is not set properly it may draw more power/energy [1]. Basically, the Linux system (power governers) would prevent the OS from entering the deep power state where there are lots of opportunities to save energy when the system is idle. 

Answering the most common concern about open source software, this article shows that, yes, Linux will run under Windows. 

So why should you read this article? Why, indeed, should I write it? My motive is to help remove two obstacles to the wider adoption of free and open source software. 

Those obstacles are: 

• The perceived difficulty and disruptive effects of installing Linux
• The uncertainty of hardware support for Linux 

Most computer users are familiar with a Microsoft Windows environment and the variety of screensavers available to prevent unauthorized access to the data on the computer when unattended. The good news is that there is plenty of free and open source software available nowadays to enable Linux to install and run as a Windows screensaver. This article shows you how to construct an appropriate package, and in doing so, demonstrates that the “free” and “non-free” sides of the software Grand Canyon are not so far apart after all. 

Running Linux under Windows as a Screensaver App

But which Linux? Without knowing what a client intends to do, it would be irresponsible to make a blanket recommendation. However, on December 25, 2021, the demand for games will be great, and the delivery capability will be sufficient. And if you configure it as a screensaver, even the possibility of pressing the wrong key to start it is eliminated.

Making it work: Nuts, bolts, and screws 

Getting the ISO to run under another operating system requires an open source PC emulator, including an open source BIOS and an open source virtual graphics adapter (such as QEMU version 6.1.0). The emulator enables you to set up a virtual PC within a real one. To construct a screensaver, the best way is to configure it with a virtual DVD drive, keyboard, screen, and mouse, but without any virtual disks. This all runs using the magic of software emulation, but modern PC hardware is sufficiently fast for the task (which we originally designed in 2005). Some corporate environments would require the virtual PC not to have a network adapter — you can run Firefox in the screensavers here. This package has a network adapter, but it is simple to change this if required since all source code is supplied.

Here are the steps to make this work. 

QEMU 

You can build QEMU from source available here https://www.qemu.org/download/ , but there is a suitable prebuilt QEMU for Windows available at https://qemu.weilnetz.de/ . This example was built and tested with QEMU 6.1.0 .

It is necessary to write a small stub program to go into the C:\WINDOWS\SYSTEM32 directory as an SCR file, which runs QEMU with appropriate parameters. https://github.com/tjcw/screensavers/blob/master/packaging/crunqemu-usb.c is sufficient for this; it runs QEMU with 1024 MB of memory, one processor, and the mouse connected as if it were a USB tablet.

This stub can be built with mingw64, from the Cygwin open source package, or presumably (though untested) with a commercial Windows C compiler.

Disabling the network adapter in the virtual PC can be done with parameter “-nic none” on the QEMU command line.

Inno Setup

Inno Setup is an open-source packaging/installation tool for Windows available here https://jrsoftware.org/isinfo.php . I used version 6.0 for this example. Packaging with Inno Setup results in a warning from Microsoft Defender when installing the screensaver; this warning can be overridden with 2 mouse clicks. A future version of this blog will explain how to package with Microsoft-licenced (non-open-source) tooling to eliminate this warning.

Prebuilt screensaver distribution

The screensavers are available here on this torrent feed: 

https://linuxtracker.org/index.php?page=downloadcheck&id=1185c790b15b92b039d616ed742e873ae57db6ce

You will need a torrent client, such as Transmission, to download it. It is especially important to check the sha256sum values as this channel is not under the control of Linux Foundation.

After downloading, you should check the ‘sha256sum’ of the files. This validates that you have indeed got the files the author intends. For Windows there is a no-charge ‘Hash Tool’ in the Microsoft app store which will do the job; for Linux you use the command line.

$ sha256sum *

b483ed3250fbfdb91c3bace04f46ad9ad0b507a9890e3a58185c3342e6711441  QemuSaverOpen-1-6.zip

95f3a8d6217f2ff93932ab5ac6d8a2a30a4d0ea09afe3096f148f5be17961428  QemuSaverOpenGames-1-4.zip

Extract the two zip files using the built-in Windows extract feature, and run the installer .exe files. Then go to the Windows screensaver selection screen and select either ‘fr2’ or ‘gk2’ as appropriate. 

There will be a 4-minute hiatus in the middle of startup while the X server initializes — be patient.

‘QemuSaverOpen-1-6.zip’ is the required base package with the educational screensaver named fr2, and ‘QemuSaverOpenGames-1-4.zip’ is an optional extension package with the games screensaver called gk2.

The source code for all components is available on the public Internet, and these links will lead you to it.

• Debian 11 http://mirrorservice.org/sites/cdimage.debian.org/debian-cd/current/source/iso-dvd/
• Qemu https://gitlab.com/qemu-project/qemu
• Qemu Windows build https://qemu.weilnetz.de/w64/
• Inno setup https://jrsoftware.org/isinfo.php
• Mingw64/cygwin https://www.cygwin.com/
• My GitHub repository https://github.com/tjcw/screensavers

The screensavers can be uninstalled with the standard Windows uninstall tool.

File structure for the extracted zip file

The following file structure is used for the live DVD filesystem: 

• An exe file is the installer. 
• Files in /qemu are the installable QEMU files, which will be copied to C:\Program Files\qemusaver. 
• Files in /extras are the screensaver and the built Live Linux ISO
• Files in /screensavers are a clone of my git repository. They are not used by the installed screensaver but are provided for the convenience of anyone who wants to explore how it works.

Creating the ISO image 

The live-build package does the ‘hard work’ of building the ISO in Debian Testing (There is currently a bug in the Debian 11 version of live-build). You will need to install a (real or virtual) machine with the Debian Testing image available here:

https://www.debian.org/devel/debian-installer/

A script https://github.com/tjcw/screensavers/blob/master/bin/do_oi wraps this to provide a simple interface; see https://github.com/tjcw/screensavers/blob/master/README.md for a short guide on how to use it.

The ISO is bootable, so it is also possible to write this to a USB key and boot your system from there. Rufus https://rufus.ie/en/ is a suitable open-source tool if you want to do this under Windows. You will need a USB key of 16GB or larger to try this option.

That’s really all it takes to install Linux from a zip file to run as a screensaver on a Windows machine.

Future directions

The screensaver could usefully be enhanced to exploit hardware virtualization acceleration. This is done with HAXM on an Intel processor or WHPX on an AMD processor. It requires changing a BIOS setting and some configuration in the internals of Windows, so it is not currently suitable for use in a simple screensaver application.

As Linux and Windows march forward, it may be necessary to rebuild the screensaver package from time to time, mainly to pick up new certificates for web browsing.

Software Bill of Materials (SBOM) for the Live DVD

In furthering the desire to improve education around open source software and increase awareness of how to minimize security vulnerabilities and exposure in the software supply chain, we wanted to update this article with a short tutorial on generating a Software Bill of Materials (SBOM) using the SPDX toolset.

This is how it is done.

The first is the script that needs to be injected into the screensaver build process:

#!/bin/bash -x

cp -pr live-build/config/content/. .

cd /var/cache/apt/archives && (

dpkg --version >/tmp/dpkg.version

COLUMNS=100 dpkg -l >/tmp/dpkg.dependencies

awk '{ print $2 }' </tmp/dpkg.dependencies >/tmp/dpkg.inslist

for p in $(</tmp/dpkg.inslist)

do

  dpkg --info $p*|grep Depends

done >/tmp/dpkg.deplist

for p in $(</tmp/dpkg.inslist)

do

  dpkg -p $p

done >/tmp/dpkg.depdetail

) </dev/null

This results in 5 files that need to be fed to the SPDX/SBOM tool. This script is in place in the ‘screensavers’ repository above and results in the files being placed in /tmp in the screensaver, also available as chroot/tmp on the screensaver build system.

Then it is a simple matter to run the SPDX/SBOM tool, and the ISO standards dependency list is generated.

[1] https://www.environment.admin.cam.ac.uk/resources/mythbusters-facts-top-tips/screens

Author: Chris Ward, Sr. Programmer, IBM
Co-authors: Nirav Patel, Vice President and Chief Architect, Linux Foundation and Eun Kyung Lee, Manager Hybrid Cloud Infrastructure Software Research, IBM

The post Linux as a Screensaver for Windows: The Gift of Open Source Games and SBOMs for the Holidays appeared first on Linux.com.

OLF, previously known as Ohio Linuxfest, has been one of the most popular community-run open source events for nearly two decades. The event brings together individuals from around the country and world to gather and share information about Linux and open source software. This year’s event takes place December 3-4 in Columbus, Ohio, and The Linux Foundation is proud to be one of the event sponsors.

Even if you cannot join us in Columbus, you can help support the event and community by entering an online raffle fundraiser. You can purchase tickets for the raffle and choose the prize you would like to win. The raffle will take place at 7 pm Eastern on December 4. The Linux Foundation has donated the following prizes to the raffle:

• Entry-level certification exam package including the Linux Foundation Certified IT Associate (LFCA) and Kubernetes & Cloud Native Associate (KCNA) exams
• Kubernetes Fundamentals training course plus the Certified Kubernetes Administrator (CKA) exam
• Open Source Management and Strategy seven-course training series

Prizes from other sponsors include a Raspberry Pi kit, original penguin artwork, and more. Purchase your tickets today and help support this great community event!

The post Support OLF and Possibly Win a Prize appeared first on Linux.com.

The Ohio LinuxFest is re-emerging as we reboot Open Libre Free Conference as a hybrid event. Re-emergence can mean simply reopening our non-profit for in-person operation. But to us, it is an invitation to reconsider how you use, experience, modify, and distribute technology in the new economy. 

Perhaps you are considering re-emerging in a new career path, want to upcycle a computer as a gift or have creative ideas to resolve current challenges. Free Software has the solutions.

Gathering once again after 25 long months, Open Libre Free Conference returns to Hyatt Regency Columbus on Friday, December 3, and Saturday, December 4, 2021. 

Join us for a fall classic tradition of 19 years: We’re bringing back many of the features that we all love such as Tech Talks, OLFI Training, Exhibits, Birds of a Feather, Annual Fundraising Raffle, and Receptions. And, with the help of the Linux Foundation, we are re-emerging for a celebration of what has made Linux great for 30 years.

Come join us for a fully masked and vaxxed show. Don’t risk disappointment as we won’t sell tickets at the door. Respond quickly as only 300 tickets will be sold until we sell out or by November 26.

The post Register for Ohio LinuxFest 2021 appeared first on Linux.com.