Hacker Newsnew | past | comments | ask | show | jobs | submit | genericpenguin's commentslogin

Ah good ol' Curtis! Definitely a good watch if you like watching engineering with large machines (and Homeless!).


I believe it's Kurtis with a "K".



Or a battery which is almost a deal-breaker. Probably means hacking a battery controller + battery on the back.


It doesn't. I was also disappointed by this. I'm in Australia and we kept our numbers low by locking down hard and early and distinguishing between community transmission and infection via incoming travellers. We did often hit long periods of no community transmission and only had outbreaks due to breaches in protocol or sloppiness by some people's part.


I think you might be referring to ElectroBOOM - https://www.youtube.com/channel/UCJ0-OtVpF0wOKEqT2Z1HEtA

Full Bridge Rectifier!!!


After a couple of hours of binge watching ...

Turns out he is Iranian.


FULL BRIDGE He lives in Canada, though.


oh, whoops


I've been a heavy Jenkins user for the last three years and I can completely see where you (and Concourse team) are coming from. The page comparing Jenkins and Concourse hits all my right buttons (complexity in build specification, minimal pipeline, etc) but I find that having to BOSH the hell out of a new system (pun intended) just to get CI running seems like a PITA to me (it's the one thing preventing me from recommending it as a solution atm). Maybe I'm missing something, but it seems like a lot of complexity is added to the deployment/worker management system that is pretty much a requirement if you want slaves external to the master. Is there a way to not have to use BOSH (BOSH Lite still tries to shoehorn things I don't want/need) to run Concourse builds? We use a combination of VMWare/KVM VMs, LXC and Docker containers for our builds and we have our own working deployment system (Puppet manages all our state successfully for VMs and LXC containers) which I would like to integrate with Concourse. I really hope I'm missing something because what I saw when I tried out Concourse for a week, made me swoon.


@vito from the Concourse team here.

We've recently started building standalone binaries which should lower the barrier to entry. Concourse itself has never been too tightly coupled to BOSH, it's just been the quickest feedback loop for us during development, so it ended up being the first thing we documented, primarily for internal use as we haven't really "launched" yet.

Binaries are available for download in the GitHub releases[1]. Check the README.md[2] for details. We'll be launching 1.0 very soon and part of this will include a major docs/website revamp which promotes the binaries to the "main stage". It also switches to BOSH 2.0, which drastically simplifies the deployment configuration necessary, but it still takes a backseat to the lower-upfront-cost distribution formats in the new site.

Glad you liked Concourse otherwise, and hopefully this helps. :)

[1]: https://github.com/concourse/concourse/releases [2]: https://github.com/concourse/bin/blob/master/README.md


Does this mean it will be (is?) possible to deploy Concourse on a single machine without the headache of BOSH Lite? I've wanted to use Concourse, but when all you've got is a Mac Mini, doing a full BOSH deploy (or even BOSH Lite) is quite a big ask.


Yup (is). You'd just run `concourse web` and then `concourse worker` on the same machine. If all you have is a Mac Mini there's one gotcha, though: currently none of the resources will run on OS X, as they're built as Docker images. So you'll still need at least one Linux worker somewhere.

I think the next step from us may be to start building Vagrant boxes that just spin up a worker, parameterized with credentials to register with a Concourse `web` instance. That way you can run Concourse on OS X for iOS testing/etc. and still have all your resources and Linux containerization when you need it via a tiny local VM.


OK, that makes sense. Anything that makes it easier to deploy would be awesome, particularly when dealing with iOS-related CI/CD.


Are there plans to support other container managers (other than Garden-based managers)?


The nature of Garden is to support container managers as Garden backends. Garden itself is just a client/server API spec.

For example, [Guardian](https://github.com/cloudfoundry-incubator/guardian-release) is in the works to replace the Linux backend with a thinner runC-based backend.

The main value we get from it is having a nice Go API and not having to overhaul everything using Garden every time some shiny new container tech comes out.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: