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

> Every time someone reinvents the wheel, it becomes a little rounder.

Not sure if this particular library is an improvement, but even if it serves nothing but the author’s enjoyment, or education, it’s a win.


Being involved with software professionally and woodworking as a hobby, I can recommend that talk. The parallels he draws are so good that I was almost angry with myself for not seeing them before watching that talk.


Concourse has it right: You can ssh into a failed container, and debug in the exact environment where the failure occurred.

I don’t understand why people settle for less.


dimensioned[1] got me interested in Rust. I’m not far enough to recommend it, but the concept seems right.

[1] https://github.com/paholg/dimensioned


> Next to every incubator was […] a product that I had written a lot of software for.

That must feel like ultimate satisfaction - software that is making the world a better place. Congratulations!


That part where you have to make a commit in order to attempt to fix a CI problem was driving me nuts. It‘s the same with Travis.

Concourse gets this right - you can run a pipeline task as a one-off from your workstation until it’s done, and only then check it in. And even ssh into the build container in order to debug build failures.


https://sensor.community/

Used to be luftdaten.info (German), but seems more international now. They built a pretty accurate sensor based on an SDS011.

No soldering required.


I'm aware but they don't have clients in Linux distributions.


I leave the handling of those situations to Lastpass. My wife and kids may request access to my password locker, and if I don't reject within 30 days the locker is opened to them.


Thanks for sharing this, I had no idea Lastpass had such a feature.

I guess this means that your family already has access to your decryption keys and the Lastpass servers are merely restricting access to the encrypted data for the 30 day time period.


That's an ingenious system.


I am running https://concourse-ci.org on a cheap VPC and I am very happy with it.


I had a brief look at Concourse. It looks promising but seems to be very focused on running things in containers.

That approach is great when starting out fresh, but with our 1000 existing pipelines (that mainly use Makefiles as entrypoints, which then use docker with custom tooling) it would be a pain to migrate.

Does anyone have experience running Concourse at scale? Does it also support running tasks "old-school" (without any containers)?


Not sure how your current builds look like, but I tend not having to deal with containers per se. All they force you to do is be explicit about the build‘s dependencies, which I think is a useful thing.

My approach for migrating existing builds to Concourse is to start with a stock image (alpine or ubuntu), and gradually add things that are missing (`fly execute` is a big help for that).

Once I have a successful build, I extract the prerequisites into a task image (but that really is an optimization).


That seems like a good approach when you have only a few pipelines. Unfortunately we have roughly 1000 pipelines/repos that all our our somewhat custom tooling that spawns up more docker containers with various volume mounts. For better or worse we're stuck with that for now, and we don't really have the capacity or desire to migrate all these projects to a completely new way of doing things.

So ideally the worker would just run commands on the worker host directly (no containers) and lets the containerization up to the executed jobs themselves. I'm not sure that's possible with Concourse (it looks like it does that for windows+darwin, but not on linux).


> run commands on the worker host directly

I‘d think that Concourse is not the best fit for this requirement.


> how do you check your e-mail?

You don’t. That’s what breaks are for (assuming personal e-mail).

> What if there's documentation that needs to be read?

- Define an objective together (e.g. „We‘d like to understand how the HTML progress element works“)

- Optionally, agree an a timeout

- Split (both reading at their own pace, on their own device)

- Join and discuss results


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

Search: