HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
appc
spec
Go2015–2017
appc / spec · Archived

spec

App Container Specification and Tooling (archived, see https://github.com/rkt/rkt/issues/4024)

Systems & InfrastructureLearning & Reference
Explore on GitHubRead Hacker News discussions
13Distinct people
14Mentions
0Explicit recommenders
1.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

App Container Specification and Tooling (archived, see https://github.com/rkt/rkt/issues/4024)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month14 dated mentions

Observed mentions: 2015-01-17 16:51:46 UTC to 2017-04-20 19:39:51 UTC.

01232015-01-01 00:00:00 UTC to 2015-02-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 20152015-02-01 00:00:00 UTC to 2015-03-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2015-03-01 00:00:00 UTC to 2015-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-04-01 00:00:00 UTC to 2015-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-05-01 00:00:00 UTC to 2015-06-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-06-01 00:00:00 UTC to 2015-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-07-01 00:00:00 UTC to 2015-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-08-01 00:00:00 UTC to 2015-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-09-01 00:00:00 UTC to 2015-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-10-01 00:00:00 UTC to 2015-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-11-01 00:00:00 UTC to 2015-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-12-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2016-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-02-01 00:00:00 UTC to 2016-03-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 20162016-03-01 00:00:00 UTC to 2016-04-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-04-01 00:00:00 UTC to 2016-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-05-01 00:00:00 UTC to 2016-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-06-01 00:00:00 UTC to 2016-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-07-01 00:00:00 UTC to 2016-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-08-01 00:00:00 UTC to 2016-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-09-01 00:00:00 UTC to 2016-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-10-01 00:00:00 UTC to 2016-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-11-01 00:00:00 UTC to 2016-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-12-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2017-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-02-01 00:00:00 UTC to 2017-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-03-01 00:00:00 UTC to 2017-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-04-01 00:00:00 UTC to 2017-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsApr 2017

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 20152015-01-01 00:00:00 UTC2015-02-01 00:00:00 UTC101
Feb 20152015-02-01 00:00:00 UTC2015-03-01 00:00:00 UTC202
Mar 20152015-03-01 00:00:00 UTC2015-04-01 00:00:00 UTC000
Apr 20152015-04-01 00:00:00 UTC2015-05-01 00:00:00 UTC101
May 20152015-05-01 00:00:00 UTC2015-06-01 00:00:00 UTC101
Jun 20152015-06-01 00:00:00 UTC2015-07-01 00:00:00 UTC101
Jul 20152015-07-01 00:00:00 UTC2015-08-01 00:00:00 UTC000
Aug 20152015-08-01 00:00:00 UTC2015-09-01 00:00:00 UTC000
Sep 20152015-09-01 00:00:00 UTC2015-10-01 00:00:00 UTC000
Oct 20152015-10-01 00:00:00 UTC2015-11-01 00:00:00 UTC000
Nov 20152015-11-01 00:00:00 UTC2015-12-01 00:00:00 UTC000
Dec 20152015-12-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
Jan 20162016-01-01 00:00:00 UTC2016-02-01 00:00:00 UTC000
Feb 20162016-02-01 00:00:00 UTC2016-03-01 00:00:00 UTC101
Mar 20162016-03-01 00:00:00 UTC2016-04-01 00:00:00 UTC303
Apr 20162016-04-01 00:00:00 UTC2016-05-01 00:00:00 UTC000
May 20162016-05-01 00:00:00 UTC2016-06-01 00:00:00 UTC000
Jun 20162016-06-01 00:00:00 UTC2016-07-01 00:00:00 UTC000
Jul 20162016-07-01 00:00:00 UTC2016-08-01 00:00:00 UTC000
Aug 20162016-08-01 00:00:00 UTC2016-09-01 00:00:00 UTC101
Sep 20162016-09-01 00:00:00 UTC2016-10-01 00:00:00 UTC000
Oct 20162016-10-01 00:00:00 UTC2016-11-01 00:00:00 UTC000
Nov 20162016-11-01 00:00:00 UTC2016-12-01 00:00:00 UTC000
Dec 20162016-12-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
Jan 20172017-01-01 00:00:00 UTC2017-02-01 00:00:00 UTC000
Feb 20172017-02-01 00:00:00 UTC2017-03-01 00:00:00 UTC000
Mar 20172017-03-01 00:00:00 UTC2017-04-01 00:00:00 UTC000
Apr 20172017-04-01 00:00:00 UTC2017-05-01 00:00:00 UTC101

What Hacker News says

14 sources
stevvooe·Dec 14, 2016
AppC has layers[0]. In fact, an ACI is just a layer. While layers are codified into the OCI specification, the manifest system is flexible and allows for future extension. The main goal of OCI is to provide a specification for what is already widely deployed without introducing too many new concepts. [0]: https://github.com/appc/spec/blob/master/spec/aci.md#image-m... Disclosure: OCI Maintainer, Docker Employee
In What Kubernetes users should know about the rkt container engine
flexd·Aug 26, 2016
I haven't replaced Docker with rkt on a big scale (or ran Docker on a big scale), but I recently changed over some Docker containers to rkt. First off, this and the rest of the rkt docs is a good starting point https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.htm... Second, rkt runs Docker images without modifications, so you can swap over really easily https://coreos.com/rkt/docs/latest/running-docker-images.htm... rkt uses acbuild (which is part of the application container specification, see https://github.com/appc/spec) to build images, and I had a very tiny Docker image just running a single Go process. I just created a shell script that ran the required acbuild commands to get as similar image. A good place to get started is the getting started guide https://coreos.com/rkt/docs/latest/getting-started-guide.htm... Docker runs
Read the rest
as a daemon, and rkt doesn't (which is one of the benefits). I just start my rkt container using systemd, so I have a systemd file with 'ExecStart=/usr/bin/rkt run myimage:1.23.4', but you can start the containers with whatever you want. It's also possible to use rkt with Kubernetes, but I have not tried that yet. http://kubernetes.io/docs/getting-started-guides/rkt/
In What I found wrong in Docker 1.12
philips·Mar 8, 2016
This discovery method is inspired by the way Go does package name delegation. It is really trivial to do. We have gotten feedback that people would prefer to use a well-known URL. At the time we started building appc the well-known URL stuff seemed to not be getting much traction but this has seemed to change over the last few months. See this issue: https://github.com/appc/spec/issues/160 Overall, I think this sort of delegation and naming is really important despite the shortcomings of particular methods. I hope that as the Open Containers Initiative proceeds that we are able to make this part of the standard. If email can do name delegation to hosting providers our server software certainly should too.
In Getting Started with rkt
bobsky·Jun 22, 2015
The proof is in the pudding. Overall this is very positive for the ecosystem as a whole, and glad to see them all come together. But I thought a big selling point of a standard means it's written down, currently the spec returns a 404 on github [1] seems like a lot of unknowns on what's actually being proposed. It’s confusing why the App Container (appc) spec which is written down [2] and has maintainers from RedHat, Twitter, Google, Apcera, CoreOS [3] is not being promoted - what's the new OCP standard offering that isn't in the appc spec? [1] https://github.com/opencontainers/specs [2] https://github.com/appc/spec [3] http://www.infoq.com/news/2015/05/appc-spec-gains-support
In Docker, CoreOS, Google, Microsoft, Amazon to Develop Common Container Standard
chatmasta·Apr 8, 2015
THE STORY OF THE CONTAINER GOLDRUSH As seen by a verbose, presumptuous 22 year old. OPEN SOURCE MOVEMENT lays foundation for containerization: - linux kernel gains mainstream adoption, becomes standardized across distributions - kernel matures to support containerization (i.e., namespacing critical OS operations) - lxc project takes advantage of kernel support, builds tooling around namespace containerization DOCKER (THEN DOTCLOUD) is first company to capitalize on power of containerization: - dotcloud demonstrates clear use case for containers, encouraging developer adoption - dotcloud releases internal infrastructure code ("moves up the value chain") for PaaS - dotcloud develops project into docker, builds existing momentum into early adoption of docker. AT THIS POINT other companies begin to emerge around Docker, e.g. CoreOS. Key facts
Read the rest
: - Docker is an abstraction around LXC, effectively a set of convenient scripts for controlling LXC - Docker is building a platform via a package management system preloaded with their repos - Platform is a threat to new entrants, e.g. CoreOS, because they risk becoming tenants CoreOS realized the risk of the Docker platform, and also that Docker is unnecessary for many of its value-adds. Everything Docker can accomplish, raw linux containers can also accomplish. The problem is that scripting LXC is less convenient than using Docker, but Docker depends on LXC, therefore LXC featureset will always be ahead of Docker. In the developer community, there is a growing acceptance of the fact that Docker is an abstraction over LXC. CoreOS is trying to standardize the abstraction as an implementation of the "app container spec" [0]. This spec puts Docker, Rocket, and lxc-tools on level playing ground. Despite this apparent acceptance, the market continues to build tooling and platforms around Docker, instead of raw LXC containers. This announcement from Microsoft is just the latest example. If a new product wants to support containers, it needs to support Docker. Docker is benefitting from network effects even though its product is not defensible from a technical standpoint. Docker is signing deals with competing enterprises like Microsoft, Google, and Amazon, because those companies are its customers. The risk for Docker is that these big companies eventually cut Docker out of the equation. They may eventually choose to replace Docker with their own "app container runtime," with features only supported on their own platform. Docker was one of the first companies to capitalize on advantages of containers, probably because they have a seriously talented group of engineers writing their code. But the market has now woken up to these advantages, and Docker is being chased by massive companies with massive resources. I hope they can fend them off and keep the upper hand in the relationship, but unfortunately I think it far more likely that Docker will eventually be cut out of the equation or acquired by one of them. This will result in a fragmentation of container technology as each company rushes to develop their own app runtime engine. Ultimately developers will suffer as platforms divide and silo, increasing developer friction and reducing cloud market competition as users consolidate around the single platform with the most momentum. Eventually, I suspect one company will control 80% of cloud computing. [0] https://github.com/appc/spec/blob/master/SPEC.md
In Microsoft announces Hyper-V Containers

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.