Version 6.1 of the GCC compiler suite is out. Changes in this release
include defaulting to the C++14 standard, improved diagnostic output, full
support for OpenMP 4.5, better optimization, and more; see the changelog for a full
list.
The Mozilla Foundation has (in the guise of Gervase Markham) posted an
update on the process of spinning off the Thunderbird mail client as a
separate project. As part of that, they engaged Simon Phipps to write up a
survey of possible new homes [PDF] for the project. “Having
reviewed the destinations listed below together with several others which
were less promising, I believe there are three viable choices for a future
home for the Thunderbird Project; Software Freedom Conservancy, The
Document Foundation and a new deal at the Mozilla Foundation. None of these
three is inherently the best, and it is possible that over time the project
might seek to migrate to a ‘Thunderbird Foundation’ as a permanent home
(although I would not recommend that as the next step).”
Linus has released the 4.6-rc5 kernel
prepatch. “Things continue to be fairly calm: rc5 is bigger than rc4 was, but rc4
really was tiny.
And while we’re back to fairly normal commit counts for this time in
the release window, the kinds of bugs people are finding remain very
low grade: there’s absolutely nothing scary in here. If things
continue this way, this might be one of those rare releases that don’t
even get to rc7.”
One of the key advantages of persistent memory is that it is, for lack of a
better word, persistent; data stored there will be available for recall in
the future, regardless of whether the system has remained up in the
meantime. But, like memory in general, persistent memory can fail for a
number of reasons and,
given the quantities in which it is expected to be deployed, failures are a
certainty. How should the operating system and applications deal with
errors in persistent memory? One of the first plenary sessions at the 2016
Linux Storage, Filesystem, and Memory-Management Summit, led by Jeff Moyer,
took on this question.
Google has announced
the availability of the Android
security 2015 year in review [PDF]. “Android’s open source model
has also allowed device manufacturers to introduce new security
capabilities. Samsung KNOX, for example, has taken advantage of unique
hardware capabilities to strengthen the root of trust on Samsung
devices. Samsung has also introduced new kernel monitoring capabilities on
their Android devices. Samsung is not unique in their contributions to the
Android ecosystem. Blackberry has worked to enhance the security of their
devices by enabling kernel hardening and other features in the Blackberry
PRIV. CopperheadOS has both introduced security improvements to their own
version of Android and made significant contributions to the Android Open
Source Project. These are just some of the various contributions made
possible through open sourcing that improved the Android ecosystem in
2015.”
Christian Schaller celebrates
the completion of the (informal) first phase of the Fedora Workstation
project. “Another major piece of engineering that is coming to a
close is moving major applications such as Firefox, LibreOffice and Eclipse
to GTK3. This was needed both to get these applications able to run
natively on Wayland, but it also enabled us to make them work nicely for
HiDPI. This has also played out into how GTK3 have positioned itself which
to be a toolkit dedicated to pushing the Linux desktop forward and helping
that quickly adapt and adopt to changes in the technology
landscape.”
This
post on the Red Hat Enterprise Linux blog describes the discovery and
repair of the “Badlock” vulnerability. One begins to understand a little
better why it took as long as it did. “The code was rewritten; in
March 2016 the changes needed to fix all eight CVEs amounted to about 200
individual patches against a development version of Samba, with about half
of those responsible for fixing CVE-2015-5370. When backported to previous
stable Samba versions, they needed additional hundred patches. To oldest
supported Samba version — about four hundred patches. What started as an
individual snowflake became an avalanche but it wasn’t finished
yet.”
It appears to be widely accepted that the Linux desktop has achieved
limited success at best, while the Linux palmtop — in the form of
Android — has been wildly successful. The two classes of systems are
generally thought of as being quite different, but it is worth remembering
that the handsets we carry now have more computing power than the desktop
systems we were using in the recent past. Given the right peripherals, an
Android handset should be more than capable of providing a reasonable
desktop experience. The Maru
distribution is an experiment intended to prove that point by turning a
smartphone device into a portable Debian desktop.
The 4.6-rc4 kernel prepatch is out for testing.
“So there really isn’t anything particularly interesting here. Just
like I like it in the rc series. Let’s hope it stays that way.”
CoreOS has announced the
release of its “Ignition” provisioning tool. “At the the most basic
level, Ignition is a tool for manipulating disks during early boot. This
includes partitioning disks, formatting partitions, writing files, and
configuring users.” It runs as the first process — before systemd —
to get the system into the proper shape before the ordinary boot process
takes over.
The details for the “Badlock” vulnerability in the SMB protocol have finally been disclosed, along with the
obligatory logo and domain name; there is no word on the availability of
hats and T-shirts yet. It is a man-in-the-middle attack that can allow an
attacker to access files in an SMB share with the permissions of the
intercepted user. “Please update your systems. We are pretty sure that there will be exploits soon.
Engineers at Microsoft and the Samba Team worked together during the past months to get this problem fixed.”
The Let’s Encrypt project, which is
working to enable encrypted communications across the web, has announced
that it has gained more sponsors and no longer considers itself to be in a
“beta” state. “Since our beta began in September 2015 we’ve issued
more than 1.7 million certificates for more than 3.8 million
websites. We’ve gained tremendous operational experience and confidence in
our systems. The beta label is simply not necessary any more.”
Eben Moglen opines on
the role of the Linux Foundation, and on GPL enforcement in general.
“LF will be as favorable to copyleft as its members are. Copyleft
licensing is easy for businesses to doubt: required sharing of work that
could be instead ‘owned’ by the capital investors seems to be mere loss in
conventional calculations. I have spent most of my adult lifetime not
telling businesses that copyleft was in their interest, but educating them
about copyleft and others’ experience with it, in order to allow them to
draw their own conclusions. Experience has taught me that this process,
though uncertain and unscalable, is absolutely crucial to the attainment of
the free software movement’s fundamental objectives. It is, however, all
too easily destroyed by any form of overly aggressive copyleft enforcement
that fully confirms businesspeople’s skepticism.”
Sasha Levin has announced the creation of the “linux-stable security tree”
project. The idea is to take the current stable updates and filter out
everything that isn’t identified as a security fix. “Quite a few
users of the stable trees pointed out that on complex deployments, where
validation is non-trivial, there is little incentive to follow the stable
tree after the product has been deployed to production. There is no
interest in ‘random’ kernel fixes and the only requirements are to keep up
with security vulnerabilities.”
The 4.6-rc3 kernel prepatch has been released, but there does not appear to
be an announcement from Linus to go with it. As he predicted, the pace of
change has increased a bit; 298 changesets have been merged since -rc2, out
of 491 total since the closing of the merge window.
Peter Hutterer writes
about the cost of configuration options.
“You see, whenever you write ‘it’s just 5 lines of code to make this
an option’, what I think is ‘once the patch is reviewed and applied, I’ll
spend two days to write test cases and documentation. I’ll need to handle
any bug reports related to this, and I’m expected to make sure this option
works indefinitely. Any addition of another feature may conflict with this
option, so I need to make sure the right combination is possible and test
cases are written.’ So your work ends after writing a 5 line patch, my work
as maintainer merely starts.”
Version
1.3.0 of the rkt container system has been released. “rkt
version 1.3.0 improves handling of errors within app containers, tightens
security for rkt’s modular stage1 images, and provides a more compatible
handling of volumes when executing Docker container images rather than
rkt’s native ACI image format. This release further develops the essential
support for rkt as a component of the Kubernetes cluster
orchestrator.”
The collective thoughts of the interwebz
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.