bacongobbler

Nope. Congratulations on winning the lottery!

Because their shareholders expect the biggest return for their money. This isn't a problem for self-funded companies (they don't have to live beyond their means if they don't need to), but if investors don't see growth they'll sell shares while it's still at its peak. That's business for you.

tig. It's been under active development for over 10 years now. https://github.com/jonas/tig

Can you elaborate more on some of those production ready defaults the stdlib doesn't have? Genuinely curious.

Is this a new wiki page? I've seen bits and pieces here and there in the net/http docs but nothing nearly as extensive.

I think the stdlib is awesome, but the biggest gripe I have with the standard net/http library would be the multiplexer (ServeMux). Out of the box if you provide it with a handle like /foo but the user making a request adds a trailing slash (e.g. GET /foo/), it returns a 404, compared to other libraries like julienschmidt/httprouter which will handle cases like this for you.

For example: https://play.golang.org/p/Q96EulBUfI

Other than that I think the stdlib is bang-on for simple http servers. Wouldn't recommend it if you're planning on writing a web server backed by a database, however. Compared to other web frameworks like django, the stdlib is a great library for working at a lower level in the stack, whereas Django is more of a content-oriented framework built around higher level concepts like basic CRUD applications.

I think it's just to demonstrate a fun and cool hack. Security wasn't at the forefront here when designing it.

It wouldn't be a daily thing. Maybe once every other year at most. The cost would be minimal to the government to hire a few contractors for a one-day thing.

Yep, we made the shift over from Fleet (a CoreOS project) to Kubernetes in v2. We were just evaluating Kubernetes at that time.

Agreed. That's the problem with running your own private Heroku; you've gotta know the entire stack to use it.

We had this dream that users can use Deis as a self-serve dev shop but we've been seeing a lot of people interested in running their entire PaaS stack, so the docs definitely reflect the administrator more so than the platform user (like Heroku).

> Deis and Convox are both trying but not really "hitting it".

Can you elaborate on this? Any feedback on how we "missed the mark" is always helpful.

(I am an engineer working @ Deis)

...which is for hobbies, not businesses.

The end result is what matters for most people, not the politics. Discovering a cure for ALS would be an amazing medical feat.

To answer your question, the ALS association raises public awareness about ALS, provides care services to ALS patients and distributes funding to research projects on ALS. The politics to when one of these research facilities discover a cure for ALS is up to them. They are just receiving grants from the ALS Association.

Typically offsites (for me, as a senior level engineer) happen during the work week, not during a weekend. I feel that people are more productive and creative at offsites during regular work hours because they're not thinking about what they could be doing instead (like going on a camping trip with friends, for example).

I agree that my weekends are mine, and there needs to be a work/life balance no matter what position you are in.

Hootsuite

Thanks! I swore it was 7, but you're completely right.

12.04 is still under LTS support by Ubuntu for another 4 years (LTS releases are supported for 7 years), so even if it's "old" it's also receiving active support. That being said, there's nothing stopping you from upgrading to 14.04 yourself.

> For increasingly many developers (potential contributors) a project effectively does not exist if it is not on GitHub.

I believe that's more to do with the process than the platform. Having to remember different processes to contribute fixes/features is a pain. I can't count how many times I had to register an account, log into their custom bug tracker, find the darned obscure remote (looking at you, apache SVN), check out, figure out who I have to email the patch... And then doing it all over for a different project makes the entire process a little ridiculous. With Github, it's ridiculously simple: Log in, fork, clone, push, PR, repeat.

> I see this dependence as very bad and dangerous for the global free software movement.

OTOH, having a place to call "home" for FOSS developers generates a better sense of community. It's like hosting a conference across multiple buildings: sure, the venue's big enough to hold X amount of people, but it doesn't seem like there's X people attending if I can't see everyone without having to traverse buildings.

Also,

> It's trivial to push your local copy to bitbucket, or even your own git server. Lock in is not really an issue, in my opinion.

I feel and share your pain. I dislike the model of having to vendor in every third party library's source code, so I'm trying to build an alternative tool to Godep[1]. It's still a work in progress but the basic functionality is there :)

[1]: https://github.com/fishworks/dis

I believe this is why you are getting downvoted:

> It's not going to be displacing low-level programming any time soon, unless radical changes are in store for 2.x and beyond, hypothetically

What radical changes are you referring to, and why are they needed in order for Go to be a de-facto language for system programmers?

pure speculation, but I'm pretty sure brands which are already socially tainted by the general public (e.g. adult entertainment) would gladly take up 4chan for ad space and visibility.

Yes, it was previously written in Ruby. https://github.com/github/hub/releases/tag/v2.2.0-rc1 has a standalone binary release for Windows.

This is mainly due to the current issues in Go with how package imports are handled. Since the Go port of hub relies on third party libraries, it uses Godep[1] to vendor its dependencies.

With /Godeps: 44838 LOC

Without /Godeps: 14733 LOC

[1]: https://github.com/tools/godep

It's not really tied to github. If you look at the source[1] it's just a `git clone` wrapped in a shell script.

[1]: https://github.com/armish/evsrc/blob/master/scripts/evSource...

we have a bunch of sample applications which we run nightly integration tests against. As for application tutorials themselves, we have the buildpack[1] and the dockerfile[2] workflows.

[1]: http://docs.deis.io/en/latest/using_deis/using-buildpacks/

[2]: http://docs.deis.io/en/latest/using_deis/using-dockerfiles/

I can't give you an answer on how many apps you can run on a 3x2GB cluster. It really depends on how much memory/clock cycles your apps require.

yes, tcp support in the router is something we'd like to work on but is not there yet for v1.0.

application logs are aggregated and shipped to a logger component[1]. if you scale processes and run `deis logs`, you'll see the log output of every running process for that app.

[1]: https://github.com/deis/deis/tree/master/logger

Just a quick note, Rackspace has been notoriously slow with getting CoreOS's latest images up, so we've had to work around that with noting that you have to update your machines first before deploying Deis. They just updated to v494 though so it should be good to go IITB now :)

> Deis = heroku-like interface on top of your own private cloud

There are a few things like Dockerfile deployments and a `deis pull` workflow for importing your docker images from either DockerHub or an in-house registry as an app, but for the most part you have the right idea. Open-source Heroku has been the general elevator pitch but there are a few docker goodies in there.

> and certain other things like Ceph distributed filesystem

That's an implementation detail of the platform itself, not a hard requirement that you need to set up yourself. We spin up a containerized ceph cluster for database, docker-registry and logger HA.

> if you might want to run a non-Linux node, a specific filesystem or node-local configuration for performance, security or other purposes, or have infrastructure that is not feasibly manageable with a manual process, Deis is not currently useful.

We're quite receptive to suggestions and proposals such as compliance, security, node-local configurations et al. We're always happy to discuss changes in either the mailing list or in an issue in order to make the platform work for a range of environments, so it is definitely possible to bridge these two sides together :)

This is one of the general problems about PaaS. One of the tenets of 12 factor is that "12 factor processes are stateless and share nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database"[1] which is why we want to avoid persisting state in the container.

Content Management Systems like Drupal or Wordpress typically store file uploads or configuration files directly onto the filesystem. With Deis or any other PaaS, this filesystem is ephemeral unless there is a shared filesystem mounted inside the container, typically via SSHFS[2] or some other remote filesystem.

We want to tackle this problem with a service gateway[3] for apps to attach backing services like a shared filesystem, but for the moment there's always S3 :)

[1]: http://12factor.net/processes

[2]: http://fuse.sourceforge.net/sshfs.html

[3]: https://github.com/deis/deis/issues/231

I used to work on Cloud Foundry for a while. I eventually left the project and became a core maintainer of Deis and have never looked back. Why?

The community is absolutely amazing here. I have had pleasant conversations with everyone from day 1. The OpDemand folks were very welcoming to my suggestions and they really helped me get started in the early days. everything is done in the open. Not a single feature goes by without a fair trial or a discussion from the community.

Hacking on Deis, getting started and tuning it to your liking has always been there from the get-go. Cloud foundry... not so much.

Cloud Foundry provides the application deployment workflow, but they're missing a few core features, most notably application rollbacks and zero-downtime app migrations at the router level. There is also no scheduler tag support so you cannot control what node your apps will be scheduled to.

They use forks of heroku buildpacks, making them heroku-incompatible in some cases. Their java buildpack is specific to cloud foundry. Hello vendor lock-in.

In-place upgrades work beautifully. I've been dogfooding a running Deis cluster for about a month now, testing upgrade paths from version to version. Just stop the components, bump the platform version and boot them up again. Boom, v0.14.1 to v0.15.0. Cloud Foundry's upgrade path is to basically stand up a second production cluster, migrate your data, app slugs, cluster config and cut over DNS records to your new cluster.

If you have any more questions on Cloud Foundry vs. Deis, Gabriel or myself would be more than happy to discuss with you over IRC or email. My email is matthewf@opdemand.com