Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Containers Don't Solve Everything

blog.deref.io

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Containers Don't Solve Everything

#61

Post by csande17 »

jzoch wrote: post #35
AnIdiotOnTheNet wrote: post #23

Earlier quoted context omitted.

Nix strikes me as the Linux community looking at an overly complicated problem of their own making and deciding that the solution is to add even more complexity. Don't get me wrong, from what I hear Nix actually does deliver on the promise for the most part, it's just that you have to learn a new language to use it effectively and of course it has its own quirks.

What solution wouldn't require its own specification + quirks? Whether its a Dockerfile or nix package I don't see the difference besides people tend to be familiar with only 1 of the many options. Im not comparing whether Dockerfiles or buildpacks or nix packages are more ergonomic than one another but i do think your comment is...misguided. From what I have heard Nix is pretty wonderful to use and simplifies the pr…

You're right that Docker is similar to Nix, at least in the sense they both seem to be trying to work around problems with the Linux packaging and library ecosystem by piling more of their own complexity on top. I suspect the comment you replied to wants to see the actual underlying problem solved.

To use an example from another community, no amount of performance improvements to NPM will ever make it a good idea to depend on hundreds of one-liner "is number odd" or "left pad" packages. Papering over the problem with yet more technology only ossifies it, making it harder to solve for real.

Re: Containers Don't Solve Everything

#63

Post by cormacrelf »

jzoch wrote: post #35
AnIdiotOnTheNet wrote: post #23

Earlier quoted context omitted.

Nix strikes me as the Linux community looking at an overly complicated problem of their own making and deciding that the solution is to add even more complexity. Don't get me wrong, from what I hear Nix actually does deliver on the promise for the most part, it's just that you have to learn a new language to use it effectively and of course it has its own quirks.

What solution wouldn't require its own specification + quirks? Whether its a Dockerfile or nix package I don't see the difference besides people tend to be familiar with only 1 of the many options. Im not comparing whether Dockerfiles or buildpacks or nix packages are more ergonomic than one another but i do think your comment is...misguided. From what I have heard Nix is pretty wonderful to use and simplifies the pr…

Anyone can build their first Dockerfile and deploy it for Node.js or similar in like 5 minutes. The tricks that make images smaller later use the same concepts and syntax. There is a reason it took over the world so quickly.

Nix ... I have so far spent about 10 hours learning it to manage my machine. I have forgotten about 98% of it and abandoned the project. You feel like you're sitting in the middle of a spider web, and you can sense the whole system at once. Literally none of your prior knowledge of how to use a computer will help you. None of your existing build tool CLI can be used. Every package manager needs a nix-ifier, like node2nix. Everything you see in a nix file will have to be googled, searched in the documentation, searched in GitHub repos for some kind of example. Nix has rebuilt the world from scratch.

If you're trying to make the next big thing, try to make it leverage people's existing knowledge. One truly excellent example is `compile_commands.json`. It does a very similar thing to Docker, where it extracts information from your existing build process, without actually changing the build process. The problem statement was that people wanted LSP (and predecessors) implementations to have access to a list of input files to a C/C++ compiler, but they didn't want to abandon Make and CMake etc. So they basically made a structured log of all the CC invocations, and a wrapper around CC that would parse the arguments and write to the log in JSON format. These days you get it for free with CMake[0]. You can use it with nearly every C/C++ build system on earth with a single CC=... argument to make.

[0]: https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_CO...

Re: Containers Don't Solve Everything

#64

Post by bob1029 »

moonchrome wrote: post #48
bob1029 wrote: post #31

Earlier quoted context omitted.

> getting devs to actually care if their software runs on platforms more than a year old. This is why we don't play games with siloing responsibilities on the tech stack. Every single developer on the team is responsible for making the entire product work on whatever machine it is intended to work on. No one gets to play "not my job", so they are encouraged to select robust solutions lest they be paged to resolve the…

So you don't support M1 Macs ?

No - the part of the product implicitly discussed above does not. We don't really have any intentions of running our services on piles of macbooks at the moment.

That said, we do have an iOS client which is intended to run on such classes of devices. I loathe the fucker so much (dev experience is garbage) but our customers like it a lot so... here we are. 99% of the complexity lives on the server, so the app is not a daily struggle. We also have a UWP client, but it has its own set of "difficulties" that I won't get into at the moment.

At some point I want to try to build a pure HTML5/canvas solution that can be served from a cheap-ass linux box and consumed by any device with a reasonable web browser implementation.

Re: Containers Don't Solve Everything

#65

Post by gumby »

superkuh wrote: post #3

It depends on the context, I don't know about corporate persons with profit incentives but if we're talking human persons then containers don't solve anything. They're just the symptom of the disease that is future shock. The underlying libraries we depend on just change too fast now and no devs care about forwards compatibility so we end up with all OS/Distros having libs that stop working in about a year (or more l…

Containers just moved the compatibility barrier up the abstraction stack. That’s not terrible (fewer and fewer understand how their computer actually works) but all those same problems still remain. Now they just apply to remote APIs instead

Re: Containers Don't Solve Everything

#66

Post by messe »

5e92cb50239222b wrote: post #30
colechristensen wrote: post #16

Earlier quoted context omitted.

Containers halfway solved some big existing problems that most people don't seem to see very well. Packaging is hard, and both debian-based and rpm-based (and really most other's I've seen) are pretty awful. (except BSDs, which I've had a lovely time with) They're slow, they're stateful, writing them involves eldritch magic and a lot of boilerplate, and they're just frequently broken. Unless you're installing an enti…

(Almost) nobody is using Arch Linux on servers, but I find its package system to be very good (not surprising since it was mostly copied from BSD ports). A few random examples (not the best you could find, just something I've used recently): - re-packaging pre-built binaries: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=visua... https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nomad... - building C fr…

Alpine (apk) and Void (xbps) have similarly nice packaging systems.

Re: Containers Don't Solve Everything

#67

Post by tomjakubowski »

curt15 wrote: post #45
5e92cb50239222b wrote: post #30

Earlier quoted context omitted.

(Almost) nobody is using Arch Linux on servers, but I find its package system to be very good (not surprising since it was mostly copied from BSD ports). A few random examples (not the best you could find, just something I've used recently): - re-packaging pre-built binaries: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=visua... https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nomad... - building C fr…

Does Arch support installing multiple versions of libraries?

Yes, but only if they're packaged separately. PKGBUILD is easy, so it takes very little effort to repackage older library versions under a new name (and patch dependents to use the new name) if you need them.

Re: Containers Don't Solve Everything

#68

Post by KingMachiavelli »

curt15 wrote: post #45
5e92cb50239222b wrote: post #30

Earlier quoted context omitted.

(Almost) nobody is using Arch Linux on servers, but I find its package system to be very good (not surprising since it was mostly copied from BSD ports). A few random examples (not the best you could find, just something I've used recently): - re-packaging pre-built binaries: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=visua... https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nomad... - building C fr…

Does Arch support installing multiple versions of libraries?

Not really. There are a few applications that can be installed because the install path different for each version, things like Java support this. But libraries like glibc, etc. are tied to one version so anytime those libraries change it triggers a rebuild of many packages.

Re: Containers Don't Solve Everything

#69

Post by dahfizz »

rualca wrote: post #21
encryptluks2 wrote: post #9

Earlier quoted context omitted.

I don't think dependencies is the only benefit of containers. I personally like the isolation they provide and generally prefer running services in containers, even if they are using the same dependencies as my OS. I run Linux too, so I don't have to worry about any virtualization framework overhead.

> I personally like the isolation they provide and generally prefer running services in containers, even if they are using the same dependencies as my OS. I would also not downplay the importance of Docker's support for software-defined networks and it's ability to arbitrarily configure networking at the container level. I firmly believe that networking doesn't pop up so often while discussing Docker because Docker s…

Having to define complex networking completely internal to a server is a problem that docker created, not one they solved.

Re: Containers Don't Solve Everything

#70

Post by tracker1 »

I think the next step(s) will be something closer to what the combination of Cloudflare Workers + KV + Durable Objects gives you... I think there also needs to be some implementation of PubSub added to the mix as well as a more robust database store. Fastly has similar growing options, and there are more being advanced/developed.

In the end, there's only a few missing pieces to offer a more robust solution. I do think that making it all webassembly will be the way to go, assuming the WASI model(s) get more flushed out (Sockets, Fetch, etc). The Multi-user web doom on cloudflare[1] is absolutely impressive to say the least.

I kind of wonder if Cloudflare could take what FaunaDB, CockroachDB or similar offers and push this more broadly... At least a step beyond k/v which could be database queries/indexes against multiple fields.

Been thinking on how I could use the existing Cloudflare system for something like a forum or for live chat targeting/queries... I think that the Durable Objects might be able to handle this, but could get very ugly.

1. https://blog.cloudflare.com/doom-multiplayer-workers/

Post reply on HN