The New Stack Analysts

"It was the second-highest user-voiced request," says Neal Shrader, Senior Software Engineer at DigitalOcean, discussing their move to support FreeBSD. "It's understandable why people wanted it. People who are into BSD are passionate about BSD and they have no problem in voicing that."

Dealings with the community have been great, says Thor Swehla, Software Engineer at DigitalOcean. "It helped us make the offering a lot more solid and tailored to what the users were trying to do," he says. "I would definitely look for something with that strong of a community, or make sure that we were talking to the right community, for anything that we launch in the future."

Neal and Thor join The New Stack founder Alex Williams and co-host Donnie Berkholz for this episode of The New Stack Analysts.

Learn more at: https://thenewstack.io/tns-analysts-show-31-digitalocean-learned-adding-freebsd-support/

“It was the second-highest user-voiced request,” says Neal Shrader, Senior Software Engineer at DigitalOcean, explaining their decision to support FreeBSD. “It’s understandable why people wanted it. People who are into BSD are passionate about BSD and they have no problem in voicing that,” Neal says.

Dealings with the community have been great, says Thor Swehla, Software Engineer at DigitalOcean. “It helped us make the offering a lot more solid and tailored to what the users were trying to do,” he says. “I would definitely look for something with that strong of a community, or make sure that we were talking to the right community, for anything that we launch in the future.”

FreeBSD had its beginnings in the early to mid-90s. “I ran a desktop environment on FreeBSD for a while,” says Donnie, recalling his decade-old dalliance. “It was part of that community of sort of RTFM people; FreeBSD has an enormous handbook,” Donnie observes, however, due to its consistency issues at the time, Donnie moved on to Gentoo, “which I’ve been running and contributing to for twelve years now.”

Neal and Thor have seen first-hand that FreeBSD has improved. “In working with the port system recently,” says Thor, “versus in the earlier days, it definitely feels largely the same, but didn’t hit any of the hiccups that I would have expected.”

Neal says that DigitalOcean provides FreeBSD as a blank slate, only touching features that allow it to launch quickly. “From there, it’s in the users’ hands,” he says.

In his earlier piece on The New Stack, “FreeBSD Now Supported by DigitalOcean,” Alex described how DigitalOcean had to first innovate its Metadata service in order to make possible its support for FreeBSD, and how that innovation was necessitated by DigitalOcean’s support for CoreOS.

Donnie cannot help but observe one irony in this chain of events. “CoreOS is actually based on Gentoo, because it’s built on Chrome OS, which is built on Gentoo,” says Donnie. “You could almost argue in some ways that Gentoo is less popular than ever but at the same time it has more users than it ever did.”

Donnie wonders about the support timelines the FreeBSD community is looking for, to which Thor replies that they would consider discontinuing support for an older release only “if it becomes impractical … because of some feature that’s missing.”

Otherwise, “we’d try to keep that support as long as we can,” he says.

“Especially with the way people want to build infrastructure, in terms of reproducibility and immutability,” Donnie says, “if those images are disappearing out from under them, then it makes a real challenge for configuration management, or Vagrant, for example.”

“On our platform, you are able to take a snapshot of your in-time image,” says Neal. “Regardless of what we offer publicly, if you have a snapshot of one of your droplets, that’s yours for as long as you want.”

Donnie asks what the process for creating a release-ready image looks like: “Is that reproducible now, or was it a one-off experiment to see if it would pick up? What’s it going to look like at upgrade time?”

“We’re doing a lot of work on image intake and image automation,” says Neal, “which are big in-flight projects that are going to be going on for the next few months.”

“We have it pretty well established on a few other Linux distros at the moment,” says Thor. “We’re expanding that to cover everything as much as we can.”

Toward the end of the show, Alex debriefs Donnie on his European sojourn to Monki Gras, FOSDEM and ConfigManagementCamp.

Klint Finley, writer for Wired magazine, joins his long-time colleague Alex Williams, founder of The New Stack, in the PDX Airport terminal to record this episode of The New Stack Analysts podcast. Using Klint’s recent piece on Black Duck’s Open Source Rookies of the Year as a touchstone, the conversation covers a number of these cutting-edge projects. Without question, there are some very interesting ideas being realized, and the discussion is well worth a listen. Alex and Klint also talk about past Rookie of the Year winners, the mainstream adoption of Kubernetes, and a wide range of trends and products that will increase in relevance in the months ahead.

Learn more at: https://thenewstack.io/tns-show-30-black-ducks-open-source-rookies-year/

Klint Finley, writer for Wired magazine, joins his long-time colleague Alex Williams, founder of The New Stack, in the PDX Airport terminal to record this episode of The New Stack Analysts podcast. Using Klint’s recent piece on Black Duck’s Open Source Rookies of the Year as a touchstone, the conversation covers a number of these cutting-edge projects. Without question, there are some very interesting ideas being realized, and the discussion is well worth a listen. Alex and Klint also talk about past Rookie of the Year winners, the mainstream adoption of Kubernetes, and a wide range of trends and products that will increase in relevance in the months ahead.

Black Duck assists their customers in complying with licenses and in navigating the logistics of maintaining an inventory of open source code. They select several new projects from each year’s class to highlight on their list, projects “which attract the most contributors, produce the most code, and garner the most attention from the developer world at large,” according to Klint.

“I saw two big themes this year,” says Klint. “One is an interest in radically de-centralized applications. Bitcoin is one of the most famous ones, and there are a couple of projects that use bitcoin-style blockchain technology.”

He mentions “Storj, essentially a cloud storage system, but on the blockchain, so that you don’t have to rely on the Dropboxes and the Boxes of the world. You can put your files out there in this highly decentralized environment, get them from anywhere you need to get them from, but only you have the encryption keys to de-crypt that data,” says Klint. “Another one is called OpenBazaar,” which proposes to do e-commerce on the blockchain, “something like a de-centralized eBay.”

These and some other blockchain-based applications Klint describes strike Alex as “open source projects that are reflections of the times,” a signal that developers are “keeping it as distributed as possible” with blockchain due to the prevailing climate of surveillance and censorship.

Alex notes a corollary with the bitcoin-blockchain trend other big theme Klint sees. “I guess you could call it DevOps,” Klint says, “this whole issue of trying to do IT infrastructure at mega-scale, and particularly, containers are a big part of that.”

Both of these themes represent people “trying to deal with big, distributed systems,” says Klint. “The difference is, in one scenario they are trying to distribute that throughout a whole bunch of people who aren’t unified into a single company. On the other side of it are companies that are trying to build their own big infrastructure to serve lots and lots of people.”

“From a computer science perspective there are probably some similar ideas,” says Klint, “but there a lot of unique challenges to the radical, decentralized systems like bitcoin.”

At the time of recording this episode, Alex was still researching his January 29, 2015 in-depth post on The New Stack, “SDN, Docker and the Real Changes Ahead,” and he engages Michael in quite a bit of thinking out on the topic of SDN.

Referring to a John Willis presentation that he captured at DockerCon Europe, Alex summarizes the transition from traditional, centralized software-defined networking to the current trend toward decentralized, distributed SDN. According to Willis, says Alex, there are two major factors that are affecting the way we think about networking.

One issue is density, “the amount of virtual machines on any physical server, and how heavy they are because they carry that operating system.” Docker containers being more light-weight, “you may have the possibilty of thousands of containers on a server,” says Alex. “Secondly,” Alex continues, “data gravity comes into play because we have lots of services and apps that might be inside of these containers,” requiring more thought toward management and orchestration.

Learn more at: https://thenewstack.io/new-stack-analysts-show-29-docker-density-data-gravity-new-complexity-sdn/

At the time of recording this episode, Alex was still researching his January 29, 2015 in-depth post on The New Stack, “SDN, Docker and the Real Changes Ahead,” and he engages Michael in quite a bit of thinking out on the topic of SDN.

Referring to a John Willis presentation that he captured at DockerCon Europe, Alex summarizes the transition from traditional, centralized software-defined networking to the current trend toward decentralized, distributed SDN. According to Willis, says Alex, there are two major factors that are affecting the way we think about networking.

One issue is density, “the amount of virtual machines on any physical server, and how heavy they are because they carry that operating system.” Docker containers being more light-weight, “you may have the possibilty of thousands of containers on a server,” says Alex. “Secondly,” Alex continues, “data gravity comes into play because we have lots of services and apps that might be inside of these containers,” requiring more thought toward management and orchestration.

“You start to think about the developments over the past several years, and one of the things John cites is this whole idea of how compute resources are allocated. It used to be the life-span of compute might be hours, or even months, and then it went down to minutesIt could go to milliseconds,” says Alex, noting AWS Lambda’s intention to provide instant compute capability.

“That sets up an interesting conundrum in the networking space,” says Alex. With all of these containers with all of this data gravity, how does one obtain the compute to manage it sufficiently and best optimize it? One proposed solution is to “swarm” compute resources from place to place, but this raises further issues with design patterns.

“All of these concerns are concerns of distributed applications,” says Michael. “A distributed application basically means you’re running on more than one server. It’s a lot more complicated than that, but you’re splitting up your application over all different kinds of compute, in different ways, and you’re also trying to take advantage of the fungibility, or people would say ‘elasticity’ or ‘versitability,’ of that. Now we have cloud apps so we’ve got some more triangulation on what’s going on out there.”

Alex notes the trend toward automation in Willis’ discussion of the capability to do segmentation and provide services in the data plane itself.

“If we didn’t have automation we wouldn’t have cloud stuff,” Michael says. “Much of how we experience computers nowadays would not be cool if we didn’t have automation. There’s this notion of ‘batch job’ where every twenty-four hours you can do something. Can you imagine how relaxing it would be if Facebook was just a daily email you received? That would be nice. But we’ve chosen not to live that way. Instead, because of automation, we can go there every second and check on things,” says Michael.

“It’s great.”

Looking forward to a schedule full of conference activity, The New Stack founder Alex Williams and co-host Donnie Berkholz of RedMonk ease into this first-of-the-year episode of The New Stack Analysts by comparing their go-to travel planning tools. RedMonk's Monki Gras is first up later this month, and its theme is "Nordic Craft Culture and Tech."

Donnie explains the impetus behind the choice to focus on the Nordic and Scandinavian influence on technology. "A huge amount of really vital internet infrastructure has come out of the Nordic countries - a lot that I hadn't realized."

"Many people know that Linus Torvalds who wrote Linux grew up in Finland," says Donnie, "but what people may not know is that tools like SSH , IRC, MySQL, Skype - more recently Spotify and Varnish - have all come out of the Nordic countries as well - a lot of these core pieces of internet infrastructure that really do a lot to equalize communication and equalize technology for the rest of us..."

Learn more at: https://thenewstack.io/new-stack-analysts-show-28-monki-gras-nordic-dev-communities-data-science-matters-sysadmin/

Looking forward to a schedule full of conference activity, The New Stack founder Alex Williams and co-host Donnie Berkholz of RedMonk ease into this first-of-the-year episode of The New Stack Analysts by comparing their go-to travel planning tools.

To explore the response to the recently-disclosed Git security vulnerability (which we wrote about at: http://thenewstack.io/major-git-security-vulnerability-discovered-causing-github-to-encourage-update-to-git-clients/) and to provide some context for it in a world of imperfect code, The New Stack Founder Alex Williams called upon Tal Klein of Adallom and Bryan Helmkamp, CEO and Founder of Code Climate, for this episode of The New Stack Analysts.

Bryan refreshes us on the nature of the Git vulnerability: “It allows an attacker who has control of a Git repository to execute arbitrary code on the client machine of anybody connecting to that Git repository with a vulnerable version of the Git client.”

Tal is not at all surprised by this news: “Vulnerabilities are going to happen; there’s no such thing as perfect code,” he says. “Git was another popular attack vector for the Shellshock vulnerability,” says Tal, describing Git as the perfect candidate through which to attempt to obtain privileges to escalation. “It’s actually the second scenario in which Git itself becomes an attack vector,” he says.

Learn more at: https://thenewstack.io/the-new-stack-analysts-show-27-the-git-vulnerability-and-its-aftermath/

To explore the response to the recently-disclosed Git security vulnerability (which we wrote about here) and to provide some context for it in a world of imperfect code, The New Stack Founder Alex Williams called upon Tal Klein of Adallom and Bryan Helmkamp, CEO and Founder of Code Climate, for this episode of The New Stack Analysts.

Bryan refreshes us on the nature of the Git vulnerability: “It allows an attacker who has control of a Git repository to execute arbitrary code on the client machine of anybody connecting to that Git repository with a vulnerable version of the Git client.”

Tal is not at all surprised by this news: “Vulnerabilities are going to happen; there’s no such thing as perfect code,” he says. “Git was another popular attack vector for the Shellshock vulnerability,” says Tal, describing Git as the perfect candidate through which to attempt to obtain privileges to escalation. “It’s actually the second scenario in which Git itself becomes an attack vector,” he says.

Most importantly, this vulnerability appears to have been discovered before it could be exploited in the wild. “I’m always relieved when the CVE is published by researchers rather than after a breach,” says Tal, meaning the good guys got to it first.

Bryan agrees on the importance of this up-side. “GitHub actually ran some analysis of all of the source code repositories that they host, and my understanding of their conclusion was that they have no evidence of any malicious Git repositories on GitHub at this time, and they've also added protections so that nobody could plant a malicious repository on GitHub,” says Bryan, calling this a good indication that the problem was identified and that fixes could be implemented before exploits resulted.

Alex asks, “What are the sources of these vulnerabilities? Are these just gaps that no one has ever seen before, or are they gaps that are created?”

“In this case, it was effectively an interaction between two behaviors: the behavior of the Git program, and the behavior of case-insensitive file systems,” says Bryan. “Most Linux developers,” Bryan continues, “use case-sensitive file systems. However, most Macs and many Windows machines do use case-insensitive file systems.”

“The vulnerability may be much less obvious to somebody who’s developing on Linux, and that is the primary operating system used by the Git core team. But there’s subtle behavioral interplay between the underlying file system and the program itself.”

Bryan expects to see a string of follow-on, ripple disclosures and patches. “I usually recommend people keep their ear pretty close to the ground for a few weeks after something like this for any additional patches.”

Alex then asks Tal to provide Adallom’s perspective on the science of vulnerabilities.

“It’s important work,” says Tal. “I think GitHub should reward their researcher who discovered this. I think they've done a great service to the community. We’re very supportive of it and we think that this needs to be a standardized process where people should not only feel supported by the community to reveal these kind of things, but are actually financially rewarded for doing so.”

“It’s better when a zero-day stops being a zero-day as a result of research rather than as a result of threat actors,” says Tal. “This is the system at work. From our perspective, the more people pay attention to the underlying behavior of code, especially code that’s so vastly popular and utilized, the healthier everybody is.”