A mechanism for intercepting kernel upcalls

By corbet Last week, Containers as kernel objects
looked at an attempt to add a formal “container” concept to the kernel,
partly as a way of ensuring that kernel upcalls (calls to a user-space
program from inside the kernel) would run inside the correct namespaces.
This week, David Howells is back with a
different approach
: a way for a daemon process to intercept and handle
specific key-related upcalls.

In particular, the keyctl() system call is enhanced with a
KEYCTL_SERVICE_CREATE command, which returns a special file
descriptor. Subsequent calls can add “filters” describing the upcalls that
should be intercepted; they are described by name and a set of flags
indicating a set of relevant namespaces. If the calling program’s
namespaces match those of a process creating an upcall, that program will
be allowed to handle the call. See the patch posting for a more detailed
description of how it works.

From: LWN

Share

The problem with Linux packaging in large organizations

By Bryan Lunduke

One of the challenges of implementing and utilizing Linux across a large organization—an organization where there are many different people with significantly different computing needs—is … packaging.

Seriously. Packaging is a big problem.

Just as an example:

Let’s say you are in charge of IT for a 1,000-person organization. Your server needs dictate that you’ll need (or at least likely want) a server-oriented Linux distribution with some sort of paid support contract. Easy enough. You can choose Red Hat Enterprise or SUSE Linux Enterprise. Server needs met.

But what about the marketing department? Does an enterprise-grade, server-focused distribution make sense for all of them? Probably not. Maybe you can standardize on one of the media production-focused distributions—or perhaps the community-driven sides of the enterprise distribution you already chose for your servers.

To read this article in full or to leave a comment, please click here

From: Network World

Share

The problem with Linux packaging in large organizations

By Bryan Lunduke

One of the challenges of implementing and utilizing Linux across a large organization—an organization where there are many different people with significantly different computing needs—is … packaging.

Seriously. Packaging is a big problem.

Just as an example:

Let’s say you are in charge of IT for a 1,000-person organization. Your server needs dictate that you’ll need (or at least likely want) a server-oriented Linux distribution with some sort of paid support contract. Easy enough. You can choose Red Hat Enterprise or SUSE Linux Enterprise. Server needs met.

But what about the marketing department? Does an enterprise-grade, server-focused distribution make sense for all of them? Probably not. Maybe you can standardize on one of the media production-focused distributions—or perhaps the community-driven sides of the enterprise distribution you already chose for your servers.

To read this article in full or to leave a comment, please click here

From: Network World

Share

The first open source 3D printer filament

Until very recently, 3D printing companies sold only proprietary hardware and materials (including plastic filament) to print with them. This plastic was sold at exorbitant prices (up to hundreds of U.S. dollars per kg), even if it was a common material like ABS (the plastic used for Lego blocks). These companies were following the path of traditional desktop printing companies that rake in large profits selling toner and ink. Some companies still attempt to extort their customers by threatening warranty loss if they use filament from other manufacturers.read more

From: LXer

Share