The MacBook Pro introduction in October caused unusually negative reactions among professional users due to the realization that Apple no longer caters equally to casual and professional customers as it had in the past [YouTube video]. Instead, the company appears to be following an iOS-focused, margin-driven strategy that essentially relegates professionals to a fringe group. This has well-known developers such as Salvatore Sanfilippo (of the Redis project) consider a move back to Linux. Perhaps that's a good moment to look at the current state of Mac hardware support in the kernel. While Macs are x86 systems, they possess various custom chips and undocumented quirks that the community needs to painstakingly reverse-engineer.
There is an interesting subset of Linux users that prefer to run it on a Mac. Yes, a Mac. That might seem odd given how Apple is known for its closed ecosystems and high cost hardware, but the Linux on Mac folks really do exist out there.
But how well does the Linux kernel support Mac hardware? LWN.net has a “state of the union” article for Linux on the Mac that could be quite helpful if you are thinking about installing Linux on your Mac.
There is yet another new Linux kernel vulnerability being disclosed today that allows for unprivileged processes to gain kernel code execution abilities.
This new vulnerability is CVE-2016-8655 but it doesn't seem to be getting too much attention yet. CVE-2016-8655 comes down to a race condition within the af_packet.c code for gaining local root access. The researcher that found it was able to write an exploit to gain root shell on an Ubuntu 16.04 LTS system and defeats SMEP/SMAP protection too.
Just a quick note: on recent versions of systemd it is relatively easy to block the vulnerability described in CVE-2016-8655 for individual services.
Since systemd release v211 there's an option RestrictAddressFamilies= for service unit files which takes away the right to create sockets of specific address families for processes of the service. In your unit file, add RestrictAddressFamilies=~AF_PACKET to the [Service] section to make AF_PACKET unavailable to it (i.e. a blacklist), which is sufficient to close the attack path. Safer of course is a whitelist of address families whch you can define by dropping the ~ character from the assignment. Here's a trivial example:
The IBM i operating system is proprietary; its Licensed Internal Code (LIC) is private, and good luck getting into the innards of DB2 for i. But for all the top-secret code running in an IBM i server, there's a surprising amount of open source technology available for the platform, too. Here are the top seven open source products every IBM i shop should have, or at least be aware of.
These products are in no particular order. But we would be remiss if we didn't start with the big one from IBM itself.
Docker aims to directly integrate storage capabilities into its container engine, while still leaving room for organizations to choose other storage technologies.
Docker Inc. announced on December 6 that it is acquiring privately-held distributed storage vendor Infinit. Financial terms of the deal are not being publicly disclosed.