Home Blog Page 725

Go 1.7 Brings a Performance Boost and Mainframe Support

Monday, six months to a tee since the release of Go 1.6, Google has released the eighth version of the Go programming language, version 1.7.

This release of Golang brings some significant changes, such as an updated compiler, the addition of the context package, and hierarchical testing. Google has also ported the language to IBM LinuxOne mainframes. The port for Linux on IBM z Systems is an experimental release in 1.7 and is accompanied by an early Plan 9 port.

While Gos compiler is known to be slow and needs future work, this release of Go begins to bring in significant improvements to the languages compiler. According to Googles benchmarks, the new compiler increases performance by up to 35 percent. Binary size is reportedly reduced by 20-30 percent and compile speeds have noticeably increased in contrast to 1.6.​

Read more at The New Stack

NIST Denounces SMS 2FA – What are the Alternatives?

Towards the end of July 2016, the National Institute of Standards and Technology (NIST) started the process of deprecating the use of SMS-based out-of-band authentication. This became clear in the issue of the DRAFT NIST Special Publication 800-63B, Digital Authentication Guideline. 

NIST Special Publications (SP) 800 series are required by the Office of Management and Budget (OMB) policies for almost all federal agencies. They are not required for privOate business. Nevertheless, they form part of the NIST Risk Management Framework (RMF) that is used by many U.S. organizations as the base framework for their own security policy. Conformance to the NIST RMF would certainly benefit companies wishing to do business with government departments. 

The key paragraph in the new draft comes in section 5.1.3.2. Out of Band Verifiers: Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. If the out of band verification is to be made using a SMS message on a public mobile telephone network, the verifier SHALL verify that the pre-registered telephone number being used is actually associated with a mobile network and not with a VoIP (or other software-based) service. …

Read more at Security Week

Cutting the Cord With Playstation Vue

We just cut the cord, and glory is ours. I thought I would share how we did it to provide food for thought for those of you sick of cable (and maybe so people can stop bickering on my DirecTV blog post from years back).

Photo on 8-16-16 at 2.12 PM

I will walk through the requirements we had, what we used to have, and what the new setup looks like.

Requirements

The requirements for us are fairly simple:

  • We want access to a core set of channels:
    • Comedy Central
    • CNN
    • Food Network
    • HGTV
    • Local Channels (e.g. CBS, NBC, ABC).
  • Be able to favorite shows and replay them after they have aired.
  • Have access to streaming channels/services:
    • Amazon Prime
    • Netflix
    • Crackle
    • Spotify
    • Pandora
  • Be able to play Blu-ray discs, DVDs, and other optical content. While we rarely do this, we want the option.
  • Have a reliable Internet connection and uninterrupted service.
  • Have all of this both in our living room and in our bedroom.
  • Reduce our costs.
  • Bonus: access some channels on mobile devices. Sometimes I would like to watch the daily show or the news while on the elliptical on my tablet.

Read more at Jono Bacon.

Keynote: Making Data Accessible – Ashish Thusoo, Co-founder & CEO, Qubole

https://www.youtube.com/watch?v=tkPDE8yuuKM

In this keynote, Ashish Thusoo, CEO and co-founder of Qubole, will discuss how cloud platforms can offer the elasticity, automation and access planes to alleviate these issues and provide a more accessible data platform.  Additionally, despite a new class of user-friendly tools, there is still a gap between a company’s ability to make data accessible throughout throughout the organization. To truly bridge this gap, Ashish will offer strategies on how developers can take a verticalized approach to building applications on top of data so that users can benefit from easy-to-use visualizations and other tools.

Hyperledger Tests Open Strategy With First Blockchain Explorer

Business blockchain consortium Hyperledger is now building an open-source tool that will let anyone explore the distributed ledger projects being created by its members.

Similar to block explorers already being offered for other public blockchains, the tool would make it easier to learn about Hyperledger from the inside, while still protecting the privacy valued by many of the non-profit organization’s members.

Hyperledger’s newly appointed executive director Brian Behlendorf told CoinDesk: “Rather than have three different projects that all do the same thing and compete essentially as three different code bases, [we thought] why not work together on one common codebase and cherrypick the best parts and use this as an opportunity to talk about standards for talking to different systems?”

Read more at CoinDesk

Flatpak: A Containerized Approach to Developing Linux Applications

Containers are becoming increasingly popular in the enterprise world, which has come to realize that containers not only solve many problems, but also bring agility, scalability, and other benefits to the IT infrastructure. This idea is now trickling down to the desktop world.

Canonical gets much of the credit for creating buzz around a container-like approach toward apps with the announcement of Click, which later evolved into Snap. But the fact is there have been many efforts to bring such a solution to the desktop world. Projects like Klik (which evolved into AppImage in 2014), for example,  have been around for more than 12 years now. Alexander Larsson, a Red Hat developer, has been playing with the idea of a distro-agnostic, self-contained application packaging and delivery solution since 2007.

It’s interesting that none of these technologies gained any traction or mindset in their early days. They largely remained unnoticed. Thanks to the success of Docker containers; however, there is a renewed interest in such technologies.

Allan Day and Alexander Larsson, who are involved with Flatpak, said in an interview, “The way we see it, Docker exploded because it solved real, fundamental issues with the way that server technologies are developed and deployed.”

The co-founder of CoreOS, Brandon Philips, once told me in an interview that containers are the future of apps on Linux. And, while the enterprise world has embraced containers, companies like Google are bringing it to the consumer world. Google is using Linux containers to run Android apps to Chrome OS. It’s already here, the desktop Linux world has to catch up with it.

“With Flatpak, we are aiming to do the same thing for desktop applications. The interest we’ve seen in Flatpak hopefully shows that we’re on the right track: app developers are interested because Flatpak solves real problems that they’re facing,” Day and Larsson said.

The primary goal of Flatpak is ease of distribution for apps and more control for application developers. “We want the Linux desktop to be a single platform that developers can easily target and we want them to be able to build and release their apps the way they want, according to their schedule and not someone else’s. And if we solve that problem, we think it will mean a lot more desktop apps being available,” they said.

Flatpak allows developers to look at Linux as “one” platform, not only among different distributions that use different package formats but also among different versions of the same distributions.

With Flatpak, developers can package their app to run on “any” Linux distribution. Flatpak removes the distro as a middleman. In the current state of affairs, developers must go through the mechanism that distributions have set up to get their apps to users. This causes delays because, unless the apps are tested against the distributions, app maintainers won’t make them available to users.

Another problem to solve is that of dependencies. Developers can’t use the latest libraries or frameworks to make their app more efficient or add new features if those libraries or dependencies are not available for the current version of the distro. Flatpak allows developers to use latest packages to build their apps and run on any distro without having to worry about underneath layers.

The way Flatpak solves these problem is by using shared platforms, which are called runtimes. “These contain a lot of the libraries required by apps and they are produced by the major desktop platforms, so you get GNOME runtime and KDE runtimes, for example. One of the key things about runtimes is that they can be installed in parallel, so the GNOME 3.18 runtime can coexist with the GNOME 3.20 runtime, and you can have different apps on your system using different runtimes,” said the developers.

This also offers forward compatibility: an app will never break because something changed in your distro, and app developers get to choose when to change their dependencies, rather than having those changes forced on them by distributions.

The other main concept is bundling. “If an app wants to use a library that isn’t provided by the runtime it’s using, or if it wants to use a different version of the library, or a even modified version, then it can be included as a part of the app. The point of this is to give complete freedom and control to app developers: they get to use whatever dependencies they want, when they want, and they can be confident that their app will always work. That’s a massive change from the current Linux distribution model,” said Day/Larsson.

The developers added that although Flatpak allows apps to bundle their own dependencies, a lot of dependencies are also provided by platforms that are separate from the apps. “As a result it dramatically reduces the number of libraries that application developers have to bundle. This means less work for app developers and it also results in smaller apps,” they said.

Day and Larsson said this approach not only makes makes developers’ lives easier but also results in more secure apps, because the libraries are maintained by specialists who are experienced at doing that.

Secure by design

Security is central to Flatpak, the developers explained. “It’s something that has been designed into it from the very beginning.” Some pieces are missing to complete the security picture, however, the developers are working on it. X.org, for example, has known security issues, so unless Wayland becomes mainstream, even Flatpak won’t offer the kind of security you would expect from Linux systems. “Under X.org, Flatpak still gives you greater security compared to without it, and Flatpak apps have access to less stuff on your system whether you’re using X.org or Wayland.”

Sandboxing apps is not a piece of cake. While you have to isolate your app from the rest of the system, you also need to access data created or stored by other apps. You also need access to hardware components. “We should also mention that sandboxing requires other changes down the stack,” said Day and Larsson. “There needs to be a video stream processing system for accessing webcam devices, and there needs to be a way for sandboxed apps to store passwords, for example. It’s a major effort that we are driving forward, which other projects will be able to benefit from.”

The Flatpak developers are not approaching the solution in complete isolation. According to them, they are taking the best aspects of the distribution model, which have been tried and tested and which they know to work, and they are combining them with bundling and containerization.

Flatpak vs. Snap

Flatpak may have been in works since 2007 as glick, it’s not the only player in the Linux world. Canonical is the one that created waves with the announcement of Click, that later evolved into Snap.

There is a healthy competition between the two projects and, according to Day/Larsson, “There are obviously technological differences, each of which have pros and cons. The ones I’d pick up on is de-duplication of identical files and delta updates, which means that download sizes are smaller and disk space is used more efficiently.”

Aside from those technical details, there are two major differences. The first is cross-distro support. “[Flatpak] only uses generic technologies that are generally available in all distributions. It doesn’t require any changes to distros. Anyone can use Flatpak to set up a repository or build an app center. Snappy is different. It uses AppArmor, which isn’t used universally. It requires changes to the distro; SELinux must be disabled, for example. Each app is required to bundle parts of Ubuntu. There’s no concept of an upstream platforms that apps can use.” according to the developers.

Michael Hall of Canonical said there are some components of Snaps that are tied to Ubuntu, but they are working on decoupling Snap from Ubuntu to achieve full cross-distro support. They have already decoupled many components.

The second major difference is the idea of having runtimes that are maintained by platform developers and aren’t bundled as a part of apps, said the Flatpak developers. “This cuts down on the size of apps, reduces the amount of work for app developers, and ensures that security updates happen faster and more reliably. In Snappy everything has to be bundled as a part of the app.”

The wider adoption

There are many projects aiming for a similar solution, but Flatpak and Snap seem to be the ones that are gaining mindshare. Fedora has already put its weight behind Flatpak, and Snap has Ubuntu backing.

Which of the two will get wider adoption depends on two factors: technological and political. “One important point to make here is that Flatpak doesn’t require changes to the underlying distribution,” said Day/Larsson. “There’s no special configuration or lots of dependencies: all a distro needs to do to adopt Flatpak is include the package. Cross-distro support was a design goal from the very beginning, and it shows.”

In the real world, some projects like LibreOffice and Pitivi are already offering Flatpak for their apps. But the developers are realistic. “There’s a lot of excitement and community interest, but it’s probably fair to say that Flatpak isn’t quite at the point of being a complete solution. We’re not far away though, and once we pass that mark we’re confident that we’ll see things pick up even further,” they said.

With realism comes optimism. “As far as adoption is concerned, we believe that Flatpak is extremely compelling: it’s solving basic problems the Linux desktop has had since the very beginning. The basic value proposition is there. The goal now is to make it as easy to access and use as possible. That means great tooling for app developers, great documentation, great integration into the desktop. We already have a lot of that. Once it’s all in place, we’re hopeful that we’ll start to see more apps and, resulting from that, distro adoption,” Day and Larsson said.

 

Let’s Encrypt: Why Create a Free, Automated, and Open CA?

During the summer of 2012, Eric Rescorla and I decided to start a Certificate Authority (CA). A CA acts as a third-party to issue digital certificates, which certify public keys for certificate holders. The free, automated, and open CA we envisioned, which came to be called Let’s Encrypt, has been built and is now one of the larger CAs in the world in terms of issuance volume.

Starting a new CA is a lot of work—it’s not a decision to be made lightly. In this article, I’ll explain why we decided to start Let’s Encrypt, and why we decided to build a new CA from scratch.

We had a good reason to start building Let’s Encrypt back in 2012. At that time, work on an HTTP/2 specification had started in the Internet Engineering Task Force (IETF), a standards body with a focus on network protocols. 

Read more at OpenSource.com

Cloud-Based Systems Can Accelerate the Benefits of Big Data

Cloud platforms enable enterprise companies to begin their big data journey much faster than on-premises systems because of centralization of control and administration, massive geographic reach, and because of the elasticity of Infrastructure-as-a-Service (IaaS) that allows you to create just the right amount of computing power on the fly, according to Ashish Thusoo, co-founder and CEO of Qubole and former head of Facebook’s big data initiatives, speaking at the Apache Big Data conference in May.

Those characteristics allow companies just joining the big data revolution to quickly get to the “holy grail:” a system where anyone can make use of the data, across departments and regardless of their job title, Thusoo said.

“In this world where data and analysis has become a competitive advantage across different industries, it’s very important that companies think about systems they put in place in order to make that data accessible to their users,” Thusoo said. “If you put [self-service] systems in place, the results are transformative. We saw that at Facebook, and I’ve seen it in the context of Qubole. That’s really the holy grail.”

Thusoo told the conference crowd in Vancouver that companies have had trouble implementing big data projects because of four major reasons:

  • They have a rigid data infrastructure currently installed and it’s hard to change those legacy systems,

  • The software they’re currently running for business intelligence isn’t adaptive,

  • There is a skills gap in the organization where many people don’t actually know how to gain access to the data or pull insights from it, and

  • New systems are very difficult to build from scratch.0

Each of those problems point to a cloud-based solution, Thusoo said.

“Is there a mechanism where enterprises can get to this vision faster, in a much less risky manner, and in a manner which is much more failure proof?” Thusoo said. “To me, the answer there is really the cloud.”

Cloud can allow a single network administrator to support hundreds of users and open the doors for new roles to gain access to the data, and implement a single point of control on who sees exactly what data set. Because cloud data centers are built around the world, a cloud-based system has no limitations on geographic reach, Thusoo said.

And cloud-based systems allow you to shape your infrastructure to the job you need done, not the other way around.

“You can create infrastructure to fit your applications, as opposed to the other way around, which is generally the norm,” Thusoo said. “This ability to create dynamic infrastructure itself allows us to think of a problem in a very different way: it allows us to completely automate the orchestration of the infrastructure.”

Watch the complete presentation:

https://www.youtube.com/watch?v=tkPDE8yuuKM

linux-com_ctas_apache_052316_452x121.png?itok=eJwyR2ye

Designing Great Command-Line User Experiences

Back in June, Chef launched Habitat, the product that I’ve been working full-time on since fall 2015. Habitat is a system for building and running applications in a way that makes them portable across a wide range of infrastructure platforms, anything from bare metal and virtual machines all the way up to PaaS and containers. Along the way, you get clustering, secrets management, service discovery, runtime configuration injection, and a whole host of other features for free. You can learn more about Habitat at habitat.sh.

Today, I’d like to spend a moment and talk about Habitat’s user experience design, and specifically, how we put a great deal of thought into making the command-line UX awesome.

Read more at Julia Dunn

Linux Bug Leaves 1.4 Billion Android Users Vulnerable to Hijacking Attacks

An estimated 80 percent of Android phones contain a recently discovered vulnerability that allows attackers to terminate connections and, if the connections aren’t encrypted, inject malicious code or content into the parties’ communications, researchers from mobile security firm Lookout said Monday.

As Ars reported last Wednesday, the flaw first appeared in version 3.6 of the Linux operating system kernel, which was introduced in 2012. In a blog post published Monday, Lookout researchers said that the Linux flaw appears to have been introduced into Android version 4.4 (aka KitKat) and remains present in all future versions, including the latest developer preview of Android Nougat. That tally is based on the Android install base as reported by statistics provider Statista, and it would mean that about 1.4 billion Android devices, or about 80 percent of users, are vulnerable.

Read more at Ars Technica