Hacker News Reader

Comment by turbinerneiter | Hacker News Reader

It's hard to keep a civil tone if you feel like the world around you is descending into madness, and this is exactly what the authors of this posts feel.

Its hard to have a civil discussion if everyone pulls into a direction you deem wrong and your words are never convincing anyone.

I have similar resentments when people in my company push for docker on embedded systems, because they are used to docker on the server, and whenever I ask them which problem they are solving on the embedded system with docker, they describe things that are wrong.

I don't share the authors strength of opinion on flatpak, although I see the same issues, and I don't want to advertise or excuse strong "tone" - but I understand the frustration.

View on HN

Docker on embedded systems. We really have come full circle.

It reminds me of a talk by Jonathan Blow - "Preventing the Collapse of Civilization" - https://www.youtube.com/watch?v=ZSRHeXYDLko. He makes the point that Docker is a solution to what was a non-problem.

This code-piling approach seems destined for failure.

Docker solves the problem of reliable deployment and dealing with dependencies.

This is a real problem an regular that regular Linux distros are not very good at.

tar solves that problem too, it's a matter of what type of abstraction is a good fit for the problem at hand.

And shell scripts solve the problem of starting and stopping daemon, but not particularly well.

The boundary between a binary tarball and the rest of the system is very poorly defined.

> Docker solves the problem of reliable deployment and dealing with dependencies.

Which, as noted, are problems that didn't used to exist and were created.

The thing that gets me is deploying JVM fat jars in Docker containers.

What an interesting video, he makes a lot of good points. However, I would definitely say that the current technology stack is more robust and capable than those of the 70s. It’s possible to have a simple system when there are hundreds of computers in the world, it is not possible when you have millions.

Interesting talk...one quote, however:

"How much functionality is added to Facebook year after year? It's not that much!"

This is in support of his argument that per programmer productivity is approaching zero, due to the over-use of abstractions.

Facebook is and has been hiring top talent software people for years, and in large numbers, but most of them aren't working on https://facebook.com/ or https://instagram.com/, at least in any visible way.

I've been programming on a nearly daily basis for over 40 years now, and my total productivity has never been higher. Not primarily because I'm smarter and more experienced, but because the tools available to me are just awesome.

I can write a functional app that allows a hand full of the billions of people around the world to interact, and I can do that in less than an hour, and on the cheap, perhaps even free.

40 years ago, that would have required a lot of time, up front money and ongoing maintenance costs.

There are countless examples.

I'm not dismissing the hazards of abstractions and the freakish amount of complexity that we face today. And I agree that a lot of it is done wrong.

> push for docker on embedded systems

Aaargh!

A particularly odd one as most embedded systems are handled as "images" of some sort - firmware blobs, ramdiscs, imaged HDDs for embedded PCs and so on.

What exactly is wrong with docker on embedded systems? Many have the memory and storage to afford containers and existing established distros like yocto are not very good.

I'd much rather deal with Dockerfiles than buildbake.

What is the problem docker solves?

Just to clarify yocto is not a distro but a project that allows you to create your own custom distro. Two yocto builds could be completely different from one another even using different package managers.

Yocto and various derivatives can be used to "build software" in the same way that Dockerfiles can be used to "build software" but using yocto is a much worse experience.

I actually think yocto solves the problem better then docker in many ways. Yocto goes to a large amount of effort to make for repeatable builds, something which docker is actually quite bad at for all that it is touted as a solution for not being able to replicate someone else's setup.

I think nix actually represents the next useful stop here: it avoids just piling another layer of abstraction/virtualisation on the pile and actually reinvents the package manager in a way which actually solves the problems docker exists to solve but in a more complete manner. Bitbake I think actually represents a much messier implementation of the same ideas: just like nix uses a functional language to express package configuration, so too have bitbake files grown the same kind of functionality. The main things which bring bitbake down are the language is ridiculously quirky, hard to debug, poorly documented, and has any number of soundness holes (as well as a good amount of action-at-a-distance akin to INTERCAL's COMEFROM statement which is simultaneously really useful and really frustrating)

> Yocto goes to a large amount of effort to make for repeatable builds, something which docker is actually quite bad at

Is this something that yocto itself helps with or just something accomplished by a thousand people hacking at .bb scripts? Last I checked features like the sstate cache came with big caveats.

Dockerfile layer caching seems much more effective at shrinking build times.

> It's hard to keep a civil tone if you feel like the world around you is descending into madness, and this is exactly what the authors of this posts feel.

It really has not, flatpak is not madness. It has issues, they are finite, they can be fixed, they should be fixed, but it is not madness. It is better than AppImage or just running random binaries you find or compiling it yourself.

I'm not saying it is, I'm saying this is what it feels like for him and that I can understand the feeling.

Also, flatpak doesn't only compete with "AppImage or just running random binaries you find or compiling it yourself". It competes with the package manager, that has worked well for decades. The package manager has issues as well.

Maybe from the authors perspective it looks like everyone wants to throw away the package managers because of some issue they have, instead of tackling these issues. If he then points out the flaws in flatpak, people say "sure it has some issue we need to fix".

Reply on news.ycombinator.com