Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
ejholmes
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
31.
▲
by
ejholmes
9y ago
Good question. It's not a concern of walk(1) itself, since it's impossible to generalize for every use case. walk(1) _always_ executes the target, but the target itself can decide whether it actually needs to do work. For a C proj
32.
▲
by
ejholmes
9y ago
A true build system really needs to build out a DAG of dependencies to be efficient and fast. Compose this with https://github.com/ejholmes/walk and you're good.
33.
▲
by
ejholmes
9y ago
walk is built with Go, which also means it's a single statically linked binary with no dependencies if you download the pre-compiled binary. If you don't like bash syntax, you can use Python, or Ruby, or Perl, etc. Any executable
34.
▲
by
ejholmes
9y ago
This looks awesome! Definitely very similar to walk(1). Thanks for sharing!
35.
▲
by
ejholmes
9y ago
Consider yourself lucky! If I had a penny for everytime I had to explain automatic variables...
36.
▲
by
ejholmes
9y ago
1. Yeah, hash functions are deterministic, but your input needs to be determinsitic across machines too. For example, on a unix system, you may want to conditionally build if any files have changed. To do that, you could generate a determin
37.
▲
by
ejholmes
9y ago
That works, until your build system is sufficiently large or time consuming or not C/C++ like make was originally built for. For example, at my company we have a build system for building all of our Amazon Machine Images (AMIs). It doe
38.
▲
by
ejholmes
9y ago
Also, I'm always surprised how little mention there is of graphs when we start talking about build systems. If you're making a build system (for literally anything) the DAG is your best friend. This is how all major build system t
39.
▲
by
ejholmes
9y ago
Make's underlying design is great (it builds a DAG of dependencies, which allows for parallel walking of the graph), but there's a number of practical problems that make it a royal pain to use as a generic build system: 1. Using m
40.
▲
by
ejholmes
9y ago
I think I remember hearing that they were on EngineYard back in the day, but never Heroku.
41.
▲
by
ejholmes
9y ago
> A single level perceptron classifier with weights estimated from sonar training data set using stochastic gradient descent. I don't have a clue what any of those words mean. Neat!
42.
▲
by
ejholmes
9y ago
If we distribute OCI images via IPFS, problem solved.
43.
▲
by
ejholmes
9y ago
This is great. I really wish the container boom started with a more Unix philosophy around containers; package "images" as a tarball, run the container with a wrapper like runc. The container inherits Stdout, Stderr, Stdin, etc. Y
44.
▲
Show HN: Walk – A fast build system for anything
(github.com)
1 points
by
ejholmes
10y ago
|
0 comments
45.
▲
by
ejholmes
10y ago
Awesome article and really well written. I am curious why people choose to go with overlay networking. To me, it seems like an extremely complex solution to a non-problem (source, I run a 700+ container cluster without any overlay networkin
46.
▲
Show HN: Walk(1)
(github.com)
2 points
by
ejholmes
10y ago
|
0 comments
47.
▲
by
ejholmes
10y ago
Great article. I'd also recommend people take a look at ThreatStack for aggregating syscall events: https://www.threatstack.com/ .
48.
▲
by
ejholmes
10y ago
This has been one of my favorite new additions to Go 1.7. Incredibly useful for debugging persistent connection pool efficiency.
49.
▲
by
ejholmes
10y ago
I'm assuming you're referring to instabilities in Docker networking. I can't point to anything specific, but that's because we've seen it as an unnecessary layer of complexity, that's trying to solve a problem
50.
▲
by
ejholmes
10y ago
Having been running a large scale production system on ECS for well over a year now, I'd like to say that ECS is hardly a bad choice; it's incredibly stable, integrates with proven AWS technologies (CloudFormation, ELB, etc) and i
51.
▲
Show HN: Migrate – Sane database/sql migrations for Go
(github.com)
7 points
by
ejholmes
10y ago
|
2 comments
52.
▲
by
ejholmes
10y ago
You know, if you move out of San Francisco and let your employees be remote you can save an insane amount of money on office space, pay employees less and allow them to have a higher quality of life. Tech's insitence on being in one of
53.
▲
Show HN: Easily assume AWS roles from the terminal
(github.com)
7 points
by
ejholmes
11y ago
|
0 comments
54.
▲
by
ejholmes
11y ago
Having been running Docker in a production system now for 6+ months, the size of the images is really a non-issue if you're using the Docker layer cache effectively. We use all of the official language images and builds are under a min
55.
▲
Show HN: Treat CloudWatch logs as io streams with Go
(github.com)
6 points
by
ejholmes
11y ago
|
0 comments
56.
▲
by
ejholmes
11y ago
One of the great things about stuff like Convox and Empire is that, because they're built on existing stable technologies and utilize AWS managed services, you're basically asking if ELB, EC2 and ECS can scale. The most unstable c
57.
▲
by
ejholmes
11y ago
Hey! Creator of Empire here. The demo stack we provide isn't suitable for production use as you found out already. Empire can definitely be deployed in a production ready manor where you can have internal and external services, which i
58.
▲
by
ejholmes
11y ago
Creator of Empire here. Empire and Convox are kinda like brothers and sisters, both really similar in implementation and philosophy. There's a couple of subtle differences, like how Empire expects that you've already built a Docke
59.
▲
by
ejholmes
11y ago
Our approach was to re-use as much existing technology as possible, which is not the case for most others. That's the "complication" I'm referring to here. Empire grew from the need for a production grade platform that w
60.
▲
by
ejholmes
11y ago
Thanks for the kind words. As a shameless plug, we are hiring: https://www.remind.com/careers :)
More ›