4 ms·

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 h

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.

pjc50 6y ago
> 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.
kanox 6y ago
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.
- turbinerneiter 6y ago
  What is the problem docker solves?
- Obsnold 6y ago
  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.
  - kanox 6y ago
    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.
- rcxdude 6y ago
  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)
  - kanox 6y ago
    > 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.
sebmellen 6y ago
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 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.
- kanox 6y ago
  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.
  - xorcist 6y ago
    tar solves that problem too, it's a matter of what type of abstraction is a good fit for the problem at hand.
    - kanox 6y ago
      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.
  - AnIdiotOnTheNet 6y ago
    > 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.
  - fiddlerwoaroof 6y ago
    The thing that gets me is deploying JVM fat jars in Docker containers.
- toxik 6y ago
  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.
cheph 6y ago
> 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.
- turbinerneiter 6y ago
  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".

pjc50 6y ago

> 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.

kanox 6y ago

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.

turbinerneiter 6y ago
What is the problem docker solves?
Obsnold 6y ago
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.
- kanox 6y ago
  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.
rcxdude 6y ago
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)
- kanox 6y ago
  > 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.

sebmellen 6y ago

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 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.

kanox 6y ago
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.
- xorcist 6y ago
  tar solves that problem too, it's a matter of what type of abstraction is a good fit for the problem at hand.
  - kanox 6y ago
    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.
- AnIdiotOnTheNet 6y ago
  > 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.
- fiddlerwoaroof 6y ago
  The thing that gets me is deploying JVM fat jars in Docker containers.
toxik 6y ago
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.

cheph 6y ago

> 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.

turbinerneiter 6y ago
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".