The kernel project goes out of its way to facilitate building with older toolchains. Building a kernel on a new system can be enough of a challenge as it is; being forced to install a custom toolchain first would not improve the situation. So the kernel developers try to keep it possible to build the kernel with the toolchains shipped by most distributors. There are costs to this policy though, including an inability to use newer compiler features. But, as was seen in a recent episode, building with old compilers can subject developers to old compiler bugs too.
It is an unfortunate fact of life that non-free firmware blobs are required to use some hardware, such as network devices (WiFi in particular), audio peripherals, and video cards. Beyond that, those blobs may even be required in order to install a Linux distribution, so an installation over the network may need to get non-free firmware directly from the installation media. That, as might be guessed, is a bit of a problem for distributions that are not willing to officially ship said firmware because of its non-free status, as a recent discussion in the Debian community shows.
Linux being secure is a common misconception in the security and privacy realm. Linux is thought to be secure primarily because of its source model, popular usage in servers, small userbase and confusion about its security features. This article is intended to debunk these misunderstandings. Due to inevitable pedanticism, “Linux” in this article refers to a standard desktop Linux or GNU/Linux distribution.
EasyOS is able to run an application in a container, but can also run a complete Linux distribution. This web page introduces containers from a user-perspective…
You will recall that in 2004, which is now seventeen years ago, I wrote a document explaining why I made the design trade-offs that I did in XScreenSaver, and in that document I predicted this exact bug as my example of, “this is what will happen if you don’t do it this way.”
And they went and made that happen.
Every time this bug is re-introduced, someone pipes up and says something like, “So what, it was a bug, they’ve fixed it.” That’s really missing the point. The point is not that such a bug existed, but that such a bug was even possible. The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe.
Especially when I have given them nearly 30 years of prior art demonstrating how to do it right, and a two-decades-old document clearly explaining What Not To Do that coincidentally used this very bug as its illustrative strawman!
These bugs are a shameful embarrassment of design – as opposed to merely bad code.
This distribution is considerably different from your usual one, it has its own non-standard libc (tertium), which was used to write the core utilities (ecore), the package manager (ports and venus) and a posix layer (simia) intended to replace musl in the future.
All the packages are statically linked, except for packages that wouldn’t work or would be too painful to make work.
The third-party tools which compose the system are chosen, when possible, based on the same principles which guide the rest of the project, for instance, netbsd curses replaces ncurses, libressl replaces openssl (bearssl may be considered later), quasar m4 replaces gnu m4, etc. (see posix-repo for details).
The init system is composed of sinit (from suckless) and perp (although i am considering replacing both with s6).
Currently the only way to build Glacies is manually, but in a few days you can expect a live-cd with a more friendly way (scripts).
Just because something is traditional does not imply that it is necessarily a good idea. As a case in point, consider LWN’s tradition of starting the year with some predictions for what is to come; some may be obvious while others are implausible, but none of them are reliable. Nonetheless, we’ve been doing this since 2002 so we can’t stop now. Read on for our wild guesses as to what might transpire in 2021.
Get started with your own BPF application quickly and painlessly with libbpf-bootstrap scaffolding, which takes care of all the mundane setup steps and lets you dive right into BPF fun and minimize the necessary boilerplate. We’ll take a look at what libbpf-bootstrap provides and how everything is tied together.
I’ve seen a variety of recommendations for safer shell scripting that use Bash and set its ‘pipefail’ option (for example, this one from 2015). This is a good recommendation in one sense, but it exposes a conflict; this option works great for one usage pattern for pipes, and potentially terribly for another one.
To understand the problem, let’s start with what Bash’s pipefail does. To quote the Bash manual:
The exit status of a pipeline is the exit status of the last command in the pipeline, unless the
pipefailoption is enabled. If
pipefailis enabled, the pipeline’s return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully. […]
The reason to use
pipefailis that if you don’t, a command failing unexpectedly in the middle of a pipeline won’t normally be detected by you, and won’t abort your script if you used ‘
set -e’. You can go out of your way to carefully check everything with
$PIPESTATUS, but that’s a lot of extra work.
Unfortunately, this is where our old friend
SIGPIPEcomes into the picture. What
SIGPIPEdoes in pipelines is force processes to exit if they write to a closed pipe. This happens if a later process in a pipeline doesn’t consume all of its input, for example if you only want to process the first thousand lines of output of something:
generate –thing | sed 1000q | gronkulate
sedexits after a thousand lines and closes the pipe that
generateis writing to,
SIGPIPEand by default dies, and suddenly its exit status is non-zero, which means that with
pipefailthe entire pipeline ‘fails’ (and with ‘
set -e’, your script will normally exit).
Very extensive list.
The following summaries of 150 community-backed Linux/Android hacker boards under $200 are listed in alpha order. They list specs and lowest available pricing recorded in the last two weeks of December 2020 with products either shipping or available for pre-order with expected ship date by the end of December. Another way to tour the catalog is by using one of the spreadsheet links below, which show comparative features. The “new” icon refers to new products included since our Jan. 2020 roundup of 136 boards.
The LibreSSL project has been developing a fork of the OpenSSL package since 2014; it is supported as part of OpenBSD. Adoption of LibreSSL on the Linux side has been slow from the start, though, and it would appear that the situation is about to get worse. LibreSSL is starting to look like an idea whose time may never come in the Linux world.
OpenSSL provides the low-level plumbing for a number of important cryptographic functions; it provides TLS and SSL implementations and a number of utilities for functions like key generation and signing. Most programs that need to communicate securely over the network end up linking to OpenSSL for that functionality. OpenSSL has always had a bit of a strange position in the Linux world due to its special license, which contains an advertising requirement that is deemed to be incompatible with the GNU General Public License. To get around this problem, many GPL-licensed programs include a special exception allowing linking to OpenSSL…
The early Research Edition Unix versions featured a program that would turn a stream of ASCII text into utterances that could be played by a voice synthesizer. The source code of this program was lost for years. Here’s the story of how I brought it back to life.
GNU Readline is an unassuming little software library that I relied on for years without realizing that it was there. Tens of thousands of people probably use it every day without thinking about it. If you use the Bash shell, every time you auto-complete a filename, or move the cursor around within a single line of input text, or search through the history of your previous commands, you are using GNU Readline. When you do those same things while using the command-line interface to Postgres (
psql), say, or the Ruby REPL (
irb), you are again using GNU Readline. Lots of software depends on the GNU Readline library to implement functionality that users expect, but the functionality is so auxiliary and unobtrusive that I imagine few people stop to wonder where it comes from.
GNU Readline was originally created in the 1980s by the Free Software Foundation. Today, it is an important if invisible part of everyone’s computing infrastructure, maintained by a single volunteer.
phosh is graphical shell for mobile, touch based devices like smart phones. It’s the default graphical shell on Purism’s Librem 5 (and that’s where it came to life) but projects like Postmarket OS, Mobian and Debian have picked it up putting it into use on other devices as well and contributing patches.