…The “Software Heritage” project is a sort of Wayback Machine for software. The project plans to create an archive of computer code source files as they appear on the web — an undertaking that has implications not just for history, but for science and research, too.
Since 2015, archivists at the Software Heritage project, which is hosted by the French Institute for Research in Computer Science and Automation, have been collecting open source code available at various online repositories and websites. To date, the archive contains more than 4 billion source files from more than 80 million projects, says Roberto Di Cosmo, a computer scientist who is directing the project in Paris. In cases where open source code disappears, or the server it is stored on is hacked, destroyed or lost, the platform aims to become the go-to place for a backup version.
In the coming weeks, Di Cosmo and colleagues plan to release the archive for anyone to access for the first time. Adding code to the platform, however, will continue in the same fashion, Di Cosmo says. He speculates that the archive currently contains only around a quarter of the world’s open source software, noting that code is often published in hard-to-access places on the internet.
What are some of the challenges open source project maintainers face? One common issue is “The Maintainer’s Paradox,” which refers to the fact that open source maintainers are presented with more ideas along with more challenges as their communities grow. This occurs even when they take very minor patches from contributors. This topic was recently tackled by Tim Bird, Senior Software Engineer at Sony, in a keynote address at the Embedded Linux Conference.
Bird is the maintainer of theFuego test system, which provides a framework for testing embedded Linux. During his keynote, he provided examples of challenges that maintainers face, within the context of maintaining Fuego.
If you’ve wanted to deploy the Arch Linux operating system on your computers with the latest Linux 4.16 kernel series out-of-the-box, now you can with May 2018’s snapshot.
The Arch Linux 2018.05.01 snapshot for May 2018 is here, and it’s the first to be powered by the Linux 4.16 kernel series, which brings mitigations for Meltdown and both variants of the Spectre vulnerabilities for ARM64 (AArch64) architectures, as well as Spectre mitigations for IBM System z (s390) architectures…
As usual, the Arch Linux 2018.05.01 snapshot is intended only for new deployments of the Linux-based operating systems, including fresh installs or reinstalls. If you have a healthy Arch Linux installation, there’s no need to download the new ISO image, just make sure you have all the latest updates installed.
Thanks to Docker, containers are everywhere now. But, while containers have revolutionized how we develop, package, and deploy applications, we’ve not done a great job of securing them. That’s where Google has a new answer in locking down containers: gVisor.
With gVisor, Google has introduced a new way to sandbox containers. These are containers that provide a secure isolation boundary between the host operating system and the application running within the container.
It does this by providing a Linux user-space kernel, written in Go. This implements a substantial portion of the Linux system surface and intercepting application system calls from containerized programs.
At the recent Embedded Linux Conference in Portland, National Instruments software engineer Julia Cartwright, an acting maintainer on a stable release of the RT patch, gave a well-attended presentation called “What Every Driver Developer Should Know about RT.” Cartwright started with an overview of RT, which helps provide guarantees for user task execution for embedded applications that require a high level of determinism. She then described the classes of driver-related problems that can have a detrimental impact to RT, as well as potential resolutions.
Cloud native computing is transforming cloud architectures and application delivery at organizations of all sizes. Via containers, microservices, and more, it introduces many new efficiencies. One of the world’s leading experts on it, Adrian Cockcroft, Vice President of Cloud Architecture at Amazon Web Services (AWS), focused on cloud native computing within the context of AWS in his keynote address atKubeCon + CloudNativeCon in Austin.
“The Civil Infrastructure Platform is the most conservative of The Linux Foundation projects,” began Yoshitake Kobayashi at the recent Embedded Linux Conference in Portland. Yet, if any eyelids started fluttering shut in anticipation of an afternoon nap, they quickly opened when he added: “It may also be the most important to the future of civilization.”
The Linux Foundation launched the Civil Infrastructure Platform(CIP) project in April 2016 to develop base layer, open source industrial-grade software for civil infrastructure projects, starting with a 10-year Super Long-Term Support (SLTS) Linux kernel built around the LTS kernel. CIP expects to add other similarly reusable software building blocks that meet the safety and reliability requirements of industrial and civil infrastructure.
In this series, we are previewing the Cloud Foundry for Developers training course to help you better understand what Cloud Foundry is and how to use it. So far, we’ve covered:
The Cloud Foundry command-line interface (cf CLI) is your primary tool for interacting with your Cloud Foundry instances: manage apps, view logs, run health checks, manage buildpacks, manage users, and manage plugins. Today, we will learn how to install the tool and run commands. You’ll need a Cloud Foundry instance; see How Can I Try Out Cloud Foundry? to learn about some hosting providers to try, some of them free.
Installing cf
Install the cf CLI by following the instructions at Installing the cf CLI. Verify that it installed correctly by checking the version:
$ cf --version
cf version 6.30.0
Localization
The cf CLI supports localization. The default language setting is en-US. To change it follow the directions at Installing the cf CLI: Localize. This controls the language only for the cf CLI, and does not affect your system settings.
Getting Started with the cf CLI
The cf CLI has an inbuilt help system. cf --help displays the main help menu, and you can get help on specific commands with cf [command name] --help, for example:
$ cf login --help
Logging In
The first step to interacting with a Cloud Foundry instance, also called a target, is to log in. You are logging into an API endpoint, using this syntax: cf login api.cloudfoundry.system.domain. It will always have the api prefix.
For example, to log into Pivotal Web Services located at run.pivotal.io, your target is api.run.pivotal.io.
Orgs And Spaces
When you log in, you are asked to target an org and a space. If there is only one org and one space these become your default targets. When there are multiple orgs and spaces then you must specify the ones you want.
cf target displays your current API endpoint, user, org and space.
cf orgs prints a list of orgs that you can access.
cf target -o org switches to a different org.
cf spaces prints a list of spaces that you can access.
cf target -s space switches to a different space.
Correct cf CLI Version
It is possible for multiple Cloud Foundry targets to run different versions, so you should verify that your CLI version works with your current target. Use the cf curl command to determine version information.
All Cloud Foundry targets expose an info endpoint, which prints the release name, build number, description, and various endpoints. Run cf curl /v2/info to see this information, and look for the "min_cli_version". The version you installed should be equal to or newer than the "min_cli_version".
Debugging Connection Issues
The CF_TRACE environment variable prints API request diagnostics, showing your login API, cf CLI version, API version, and lot of other useful information. First set the environment variable, then run the cf target command:
$ export CF_TRACE=true
$ cf target
Unset it with export CF_TRACE=false. Or you can use it per command by prepending your commands:
$ CF_TRACE=true cf target
Now that you know the basics of using cf CLI, come back for the fifth and final blog to learn how to create and push a simple app.
These steps walk you through the process of setting up an SFTP server on Linux for the secure transfer of files for specialized file transfer-only users.
CentOS 7 or any Linux server distribution is a very powerful server that performs above and beyond what your business might need. Whatever task you throw at the server, it will be ready. And, if it isn’t ready out of the box, you can make it so.
Take, for instance, the ability to easily configure CentOS 7 to work as an SFTP server. If you aren’t sure about SFTP, it is the FTP service built into Secure Shell (SSH), which allows users to securely push and pull files to and from the server, using SSH. With CentOS 7, there’s no third party software to install to make this work—everything is installed out of the box. There is, however, a slight bit of work to be done to get this configured.
CoreOS, the Linux distribution and container management startup Red Hat acquired for $250 million earlier this year, today announced the Operator Framework, a new open source toolkit for managing Kubernetes clusters.
CoreOS first talked about operators in 2016. The general idea here is to encode the best practices for deploying and managing container-based applications as code. “The way we like to think of this is that the operators are basically a picture of the best employee you have,” Red Hat OpenShift product manager Rob Szumski told me. Ideally, the Operator Framework frees up the operations team from doing all the grunt work of managing applications and allows them to focus on higher-level tasks. And at the same time, it also removes the error-prone humans from the process since the operator will always follow the company rulebook.
