Earlier quoted context omitted.
Doesn't matter, rewrite it and make the name a gortmanteau.
take your upvote and get out :))
I think you mean, take your upvote and go. ;)
Gocker: Docker implemented in 1.3k lines of Go
21–30 of 89 posts
Re: Gocker: Docker implemented in 1.3k lines of Go
#22Here's one in 100 lines of bash called, what else, "bocker": https://github.com/p8952/bocker
previous discussion: https://news.ycombinator.com/item?id=22244706
Re: Gocker: Docker implemented in 1.3k lines of Go
#23Here's one in 100 lines of bash called, what else, "bocker": https://github.com/p8952/bocker
Now someone make one for fortran
Re: Gocker: Docker implemented in 1.3k lines of Go
#24Honestly, I don't like lines of code as a metric for anything over the novelty amount of 1. And even then, that's usually some demonic Python list comprehension code. That being said, the code here is pretty approachable and they weren't noticeably trying to cram it into fewer lines. Like the library, not this marketing.
While I tend to agree, I think LoC can give a sense of scale for large systems and at least a tiny bit of insight about its potential complexity.
I recently worked with a client on an integration effort that had to touch many different points on a (massive, for me) codebase with tens of millions of LoC. For that, LoC was the only reasonable metric I could come up with to try and convey the scale and complexity of the task at hand--being quite ignorant of the system's (and subsystems') architecture(s) at the time.
That was further complicated by the way the massive codebase supported all sorts of dynamic compositions and certain interactions needed to work with baseline compositions expressed in a form of markup totaling about about 5 times the amount of the actual code base, amongst other things.
These folks thought the integration could be done for $80k tops and in a couple months. It took LoC metrics to get them to understand the potential complexity at hand and that a lot more time needed to be spent in assessment and design before jumping in.
Re: Gocker: Docker implemented in 1.3k lines of Go
#25Can someone explain the value/purpose of docker to someone who (easily) deploys regular apps to a Digital Ocean droplet?
Re: Gocker: Docker implemented in 1.3k lines of Go
#26Can someone explain the value/purpose of docker to someone who (easily) deploys regular apps to a Digital Ocean droplet?
Reproducibility is the biggest value in my opinion. A Dockerfile encapsulates all the messy dependencies in a single isolated environment. This also makes deployments easier too.
Re: Gocker: Docker implemented in 1.3k lines of Go
#27Honestly, I don't like lines of code as a metric for anything over the novelty amount of 1. And even then, that's usually some demonic Python list comprehension code. That being said, the code here is pretty approachable and they weren't noticeably trying to cram it into fewer lines. Like the library, not this marketing.
While I tend to agree, I think LoC can give a sense of scale for large systems and at least a tiny bit of insight about its potential complexity. I recently worked with a client on an integration effort that had to touch many different points on a (massive, for me) codebase with tens of millions of LoC. For that, LoC was the only reasonable metric I could come up with to try and convey the scale and complexity of the…
Hopefully you’ll forgive this potentially obvious question- is LoC (still?) generally accepted to be bounded ar 80 col?
Re: Gocker: Docker implemented in 1.3k lines of Go
#28Can someone explain the value/purpose of docker to someone who (easily) deploys regular apps to a Digital Ocean droplet?
Reproducibility is the biggest value in my opinion. A Dockerfile encapsulates all the messy dependencies in a single isolated environment. This also makes deployments easier too.
I would say that's portability rather than reproducibility. Docker increases the extent of, but doesn't guarantee, reproducibility.
Re: Gocker: Docker implemented in 1.3k lines of Go
#29Very nice! I love projects like this that return to first principles, and rebuild the core without the cruft. It is refreshing.
The dependency on netlink adds a little to the code weight. Some of this also feels like it could just be a shell script (sh, unlike Go, ships with built in Linux support for netlink, and sticks with dotted-quad-string types for IP addresses instead of mixing with int32!)
I did not realize cgroups were this simple to manipulate. Thank you for the enlightenment.
Re: Gocker: Docker implemented in 1.3k lines of Go
#30Can someone explain the value/purpose of docker to someone who (easily) deploys regular apps to a Digital Ocean droplet?
The joke that I think actually explains it pretty well is that it eliminates the "well it works on _my_ machine" problem, by not just shipping the code, but shipping the machine.