Ampere eMAG for Hyperscale Cloud Computing Now Available, LLVM 7.0.0 Released, AsparaDB RDS for MariaDB TX Announced, New Xbash Malware Discovered and Kong 1.0 Launched

5 days 4 hours ago

News briefs for September 19, 2018.

Ampere, in partnership with Lenovo, announced availability of the Ampere eMAG for hyperscale cloud computing. The first-generation Armv8-A 64-bit processors provide "high-performance compute, high memory capacity, and rich I/O to address cloud workloads including big data, web tier and in-memory databases". Pricing is 32 cores at up to 3.3GHz Turbo for $850 or 16 cores at up to 3.3GHz Turbo for $550.

LLVM 7.0.0 is out. This release is the result of six months of work by the community and includes "function multiversioning in Clang with the 'target' attribute for ELF-based x86/x86_64 targets, improved PCH support in clang-cl, preliminary DWARF v5 support, basic support for OpenMP 4.5 offloading to NVPTX, OpenCL C++ support, MSan, X-Ray and libFuzzer support for FreeBSD, early UBSan, X-Ray and libFuzzer support for OpenBSD, UBSan checks for implicit conversions, many long-tail compatibility issues fixed in lld which is now production ready for ELF, COFF and MinGW, new tools llvm-exegesis, llvm-mca and diagtool." See the release notes for details, and go here to download.

Alibaba Cloud and MariaDB announce AsparaDB RDS for MariaDB TX, which is "the first public cloud to incorporate the enterprise version of MariaDB and provide customer support directly from the two companies. ApsaraDB RDS for MariaDB TX provides Alibaba Cloud customers the latest database innovations and most secure enterprise solution for mission-critical transactional workloads." See the press release for more information.

Unit 42 researchers have discovered a new malware family called Xbash, which they have connected to the Iron Group, that targets Linux and Microsoft Windows severs. Besides ransomware and coin-mining capabilities, "Xbash also has self-propagating capabilities (meaning it has worm-like characteristics similar to WannaCry or Petya/NotPetya). It also has capabilities not currently implemented that, when implemented, could enable it to spread very quickly within an organizations' network (again, much like WannaCry or Petya/NotPetya)." See the Palo Alto Networks post for more details on the attack and how to protect your servers.

Kong Inc. yesterday announced the launch of Kong 1.0, the "only open-source API purpose built for microservices, cloud native and server less architectures". According to the press release, Kong 1.0 is feature-complete: "it combines sub-millisecond low latency, linear scalability and unparalleled flexibility with a robust feature set, support for service mesh patterns, Kubernetes Ingress controller and backward compatibility between versions." See also the Kong GitHub page.

News Ampere HPC Cloud LLVM MariaDB Security Kong
Jill Franklin

Moving Compiler Dependency Checks to Kconfig

5 days 6 hours ago
by Zack Brown

The Linux kernel config system, Kconfig, uses a macro language very similar to the make build tool's macro language. There are a few differences, however. And of course, make is designed as a general-purpose build tool while Kconfig is Linux-kernel-specific. But, why would the kernel developers create a whole new macro language so closely resembling that of an existing general-purpose tool?

One reason became clear recently when Linus Torvalds asked developers to add an entirely new system of dependency checks to the Kconfig language, specifically testing the capabilities of the GCC compiler.

It's actually an important issue. The Linux kernel wants to support as many versions of GCC as possible—so long as doing so would not require too much insanity in the kernel code itself—but different versions of GCC support different features. The GCC developers always are tweaking and adjusting, and GCC releases also sometimes have bugs that need to be worked around. Some Linux kernel features can only be built using one version of the compiler or another. And, some features build better or faster if they can take advantage of various GCC features that exist only in certain versions.

Up until this year, the kernel build system has had to check all those compiler features by hand, using many hacky methods. The art of probing a tool to find out if it supports a given feature dates back decades and is filled with insanity. Imagine giving a command that you know will fail, but giving it anyway because the specific manner of failure will tell you what you need to know for a future command to work. Now imagine hundreds of hacks like that in the Linux kernel build system.

Part of the problem with having those hacky checks in the build system is that you find out about them only during the build—not during configuration. But since some kernel features require certain GCC versions, the proper place to learn about the GCC version is at config time. If the user's compiler doesn't support a given feature, there's no reason to show that feature in the config system. It should just silently not exist.

Linus requested that developers migrate those checks into the Kconfig system and regularize them into the macro language itself. This way, kernel features with particular GCC dependencies could identify those dependencies and then show up or not show up at config time, according to whether those dependencies had been met.

That's the reason simply using make wouldn't work. The config language had to represent the results of all those ugly hacks in a friendly way that developers could make use of.

Go to Full Article
Zack Brown

The Future of Open Source

5 days 6 hours ago
Linux and the open source business model are far different today than many of the early developers might have hoped. Neither can claim a rags-to-riches story. Rather, their growth cycles have been a series of hit-or-miss milestones. The Linux desktop has yet to find a home on the majority of consumer and enterprise computers. However, Linux-powered technology has long ruled the Internet.
Jack M. Germain