4 ms·

Personally I find the FreeBSD package approach more elegant. We have the "pkg" package manager as standard on the system. If you want to install into a jail you

by clan 3y ago

Personally I find the FreeBSD package approach more elegant. We have the "pkg" package manager as standard on the system. If you want to install into a jail you simply add the -j flag. There has not been a lot of documentation on how to do service jails. Maybe because a full jail (with a full and reasonably sized OS) is so trivial to setup. But there is no denying that Docker have had great marketing and a good use case. I do however think the real reason no matter how much of a FreeBSD Jail or Solaris Zones fan boy you are - you know that Linux is the elephant in the room. That brand name alone without arguing distributions. Linux already had a huge market and mindshare compared to FreeBSD or Solaris. And when Linux got CGroups you had (within reason) feature parity. For anyone who are not daily distro switchers changing your base OS is no minor feat. So even if CGroups was not perfect the incentive to switch is not huge. But it does make me sad that Docker has become so prevalent that a Docker image is the only way some projects make releases. All too commonly without documenting the build steps. Do not be so hard on your posix friends, please!

nolist_policy 3y ago
> All too commonly without documenting the build steps. That's the great thing with Docker, all you need is documented in the Dockerfile.
- clan 3y ago
  You seem to be in the "read the code" camp. I am not. Rather than using plain language and reason about dependencies, limitations, workarounds and more or less informed choices you need to infer this from the Docker file. Pray that they have left even a single little comment regarding non obvious issues. Akin to saying everything is documented in the Makefile. Why not a quick glance a main() to see if we parse any args. You can give people step by step instructions on where to go. But you empower them with a map. Documentation is hard. Quality documentation even harder. A dockerfile is a very poor substitution for me. I do not mind projects who prefer Docker and they get all my love and appreciation if they document the manual building steps. And I am totally fine by them telling me I should probably not do that. But I am seeing more projects skipping this and instead spend effort and time on using and debugging with Docker. But I am old and my beard is getting grey. I have learned to fear the programmer who tells me to read the code to understand the system. I have been told that it is concise and is good for velocity. Not everything old is good and we should move on. I for one miss the days when documentation was considered a priority.

by clan 3y ago

nolist_policy 3y ago

> All too commonly without documenting the build steps. That's the great thing with Docker, all you need is documented in the Dockerfile.

clan 3y ago
You seem to be in the "read the code" camp. I am not. Rather than using plain language and reason about dependencies, limitations, workarounds and more or less informed choices you need to infer this from the Docker file. Pray that they have left even a single little comment regarding non obvious issues. Akin to saying everything is documented in the Makefile. Why not a quick glance a main() to see if we parse any args. You can give people step by step instructions on where to go. But you empower them with a map. Documentation is hard. Quality documentation even harder. A dockerfile is a very poor substitution for me. I do not mind projects who prefer Docker and they get all my love and appreciation if they document the manual building steps. And I am totally fine by them telling me I should probably not do that. But I am seeing more projects skipping this and instead spend effort and time on using and debugging with Docker. But I am old and my beard is getting grey. I have learned to fear the programmer who tells me to read the code to understand the system. I have been told that it is concise and is good for velocity. Not everything old is good and we should move on. I for one miss the days when documentation was considered a priority.