6 ms·

My first thought on this was good riddance. The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well. However

My first thought on this was good riddance. The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well. However it looks like the main effect is going to be moving more of open source onto GitHub, aka under Microsoft's control, and the level of faith people have in Microsoft not destroying their competitor for profit is surreal.

Sebb767 4y ago
> The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well. Docker, the company, is failing. Docker, as in containerization technology, is alive and very well. (edited for clarity)
- osigurdson 4y ago
  >> Docker, the company, is failing. Docker, the container technology, is alive and very well. Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more. I don't think it matters much that k8s uses CRI-O but docker needs to be #1 for running a container on a single machine. Yet, they seem to be letting that slip away because it is not directly monetizable. Software businesses need to be creative - invest a lot into free things, which support monetization of others. If you want low risk returns, buy T-bills.
  - cybrox 4y ago
    The docker runtime is not supported by k8s anymore but docker built containers do still and will very likely continue to work for a long time.
  - Zensynthium 4y ago
    Tell that to svb
  - Sebb767 4y ago
    > Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more. I've used "Docker" as in "containerization", since they are often used synonymously and the grandparents intent was definitely to criticize the latter. Docker itself will quite likely stay around as a name, but I have no faith in the company.
    - imdsm 4y ago
      The company has never been good though. The technology was great, but they never found a way to monetise it properly, and their whole approach to outreach, community, and developer experience was terrible. Their support, non-existent. In fact, I'd go as far as to say that, given the ubiquity of their product, I can't think of a worse way a company could have performed. It's been about 10 years now since it really took off, and in that time, the technology has been great, but dealing with the company, always been difficult.
      - yencabulator 4y ago
        > The technology was great Nah, you just didn't look carefully enough. Docker the technology has been recurring amateur hour of screwups. For example, they hashed the downloaded data but forgot to compare the hash to expected value. The only thing "great" about Docker was the rough idea of easy-to-transport filesystem images that could run just about anywhere, and the fact that they managed to make that kind of thinking mainstream.
        osigurdson 4y ago
        Docker either came up or popularized the idea that completely dominates how almost all services work today. That is something imo. It is obvious in hindsight maybe but not in 2012.
        imdsm 4y ago
        I disagree with you. I've used it in production for almost a decade now. There have been issues sure, but name me a single production-level technology that hasn't had problems? - Microsoft Windows: Various versions of Windows have had critical security vulnerabilities over the years, leading to widespread malware outbreaks like WannaCry and NotPetya. - OpenSSL: In 2014, the Heartbleed bug was discovered in OpenSSL, which left millions of websites vulnerable to attacks that could steal sensitive data. - Apache Struts: In 2017, the Equifax data breach was caused by a vulnerability in Apache Struts, a popular open-source framework for building web applications. - Boeing 737 Max: In 2018 and 2019, two deadly crashes were caused by a software flaw in the flight control system of the Boeing 737 Max airplane. - Google Cloud: In 2020, a widespread outage of Google Cloud services caused disruptions for many businesses and organisations that rely on the platform for their operations. Should I continue?
CGamesPlay 4y ago
What state are you thinking of? The containers are ephemeral and the dependencies are well specified in it. You can complain about shipping Ubuntu, but the rest of this doesn’t make sense.
- vilunov 4y ago
  Makes perfect sense to me, sadly. The dependencies are specified in excessively, that's why everyone is shipping Ubuntu. This is caused by and further facilitates the development style of "do not track what we use, just ship everything". Also, the dependencies are specified in container images, which themselves are derivative artifacts and not the original source code, and these dependencies often change in different container builds with no explicit relevant change. There are three practical problems as a result: - huge image sizes with unused dependencies delivered as part of the artifact; - limited ability to share dependencies due to inheritance-based model of layers, instead of composition-based model of package managers; - non-reproducibility of docker images (not containers) due loosely specified build instructions. Predicting future comments, nix mostly fixes these issues, but it has a bunch of issues of its own. Most importantly, nix is incredibly invasive in development process, adopting it requires heavy time investments. Containers also provide better isolation
  - earthling8118 4y ago
    It doesn't have to be a choice of containers or nix though. You can put your nix built applications into a container just fine. You can also pull an image from somewhere else and shove nix stuff into it as well. There is definitely a bit of a learning curve but the time investment is frequently over exaggerated. I see it as similar to the borrow checker in rust. Yes, you have to spend some time and also learn about the rules. But it helps you build software that is more robust and correct. Plus once you're into it you save significant time not having to deal with dependencies especially when bringing on new people
    - vilunov 4y ago
      This is true, I can put nix apps in a container. It improves the reproducibility of builds, but it still wastes disk space, because the container is still based on layers and not packages. > There is definitely a bit of a learning curve but the time investment is frequently over exaggerated I'm not talking about the learning curve and its time investment, I'm talking about design problems. Nix's invasiveness is completely unnecessary in modern Linux, it makes its installation a very special case and requires lots of patches to just get stuff to work in nix. The fact that nix patches built binaries so that they point to correct shared libraries locations is a crutch which shouldn't be there in the first place. It also tries to reimplement pretty much every package manager and build tool, even if they already work well and provide the reproducibility guarantees, including cargo, poetry, npm/yarn. This is a time investment, but it doesn't help me build software that is more robust and correct, that part is already handled for me. Instead, it just worsens the DX, as it forces me to use tools non-native to the ecosystem without first-class support for commonly used features.
hospitalJail 4y ago
>The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well. This was my first thought when I learned of Docker. I have a hard time calling myself an 'Engineer' when there are so many unknowns, that I'm merely playing around until something works. I insist on being called a Programmer. It pays better than 'real' engineering. Why not embrace it? (Credit toward safety critical C and assembly though, that's engineering) EDIT: Programmer of 15 years here
- 0xDEF 4y ago
  I doubt the real™ engineers at NASA and SpaceX know everything their proprietary closed-source Matlab-to-FPGA tooling is actually doing under the hood.
  - ijaeifjzdi 4y ago
    can't say for spaceX, but most NASA glue is built in house. close to zero proprietary ones. maybe the vlsi is closed. but that is "industry standard" i guess. rest is a bunch of mathy-language du jour held together with python or something. ...opaque docker containers going to prod doesn't have a excuse other than inefficient orgs fulled by VC or Ad money. Or maybe they do, but you won't excuse them using NASA as an example :)
- Clubber 4y ago
  Developer/Programmer/Engineer titles are mostly meaningless because they mean different things at different companies. You can go wayback and call yourself a coder.
  - freedomben 4y ago
    what's old is new again. the teenagers nowadays call themselves "coders" because "programmer" is for old people.
- AlotOfReading 4y ago
  As someone that does what you consider "engineering", my current project is containerized because I've lost too much of my life to debugging broken dev environments. The person who ships safety critical releases at most companies isn't a developer that's deeply familiar with the code, it's usually a distracted test engineer with other things to do that may not be very tech-saavy. Anything I can do to help them get a reproducible environment is great.

Sebb767 4y ago

> The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well. Docker, the company, is failing. Docker, as in containerization technology, is alive and very well. (edited for clarity)

osigurdson 4y ago
>> Docker, the company, is failing. Docker, the container technology, is alive and very well. Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more. I don't think it matters much that k8s uses CRI-O but docker needs to be #1 for running a container on a single machine. Yet, they seem to be letting that slip away because it is not directly monetizable. Software businesses need to be creative - invest a lot into free things, which support monetization of others. If you want low risk returns, buy T-bills.
- cybrox 4y ago
  The docker runtime is not supported by k8s anymore but docker built containers do still and will very likely continue to work for a long time.
- Zensynthium 4y ago
  Tell that to svb
- Sebb767 4y ago
  > Is it though? Podman is more well liked (no daemon / non-root) and Kubernetes doesn't have direct support for it any more. I've used "Docker" as in "containerization", since they are often used synonymously and the grandparents intent was definitely to criticize the latter. Docker itself will quite likely stay around as a name, but I have no faith in the company.
  - imdsm 4y ago
    The company has never been good though. The technology was great, but they never found a way to monetise it properly, and their whole approach to outreach, community, and developer experience was terrible. Their support, non-existent. In fact, I'd go as far as to say that, given the ubiquity of their product, I can't think of a worse way a company could have performed. It's been about 10 years now since it really took off, and in that time, the technology has been great, but dealing with the company, always been difficult.
    - yencabulator 4y ago
      > The technology was great Nah, you just didn't look carefully enough. Docker the technology has been recurring amateur hour of screwups. For example, they hashed the downloaded data but forgot to compare the hash to expected value. The only thing "great" about Docker was the rough idea of easy-to-transport filesystem images that could run just about anywhere, and the fact that they managed to make that kind of thinking mainstream.
      - osigurdson 4y ago
        Docker either came up or popularized the idea that completely dominates how almost all services work today. That is something imo. It is obvious in hindsight maybe but not in 2012.
      - imdsm 4y ago
        I disagree with you. I've used it in production for almost a decade now. There have been issues sure, but name me a single production-level technology that hasn't had problems? - Microsoft Windows: Various versions of Windows have had critical security vulnerabilities over the years, leading to widespread malware outbreaks like WannaCry and NotPetya. - OpenSSL: In 2014, the Heartbleed bug was discovered in OpenSSL, which left millions of websites vulnerable to attacks that could steal sensitive data. - Apache Struts: In 2017, the Equifax data breach was caused by a vulnerability in Apache Struts, a popular open-source framework for building web applications. - Boeing 737 Max: In 2018 and 2019, two deadly crashes were caused by a software flaw in the flight control system of the Boeing 737 Max airplane. - Google Cloud: In 2020, a widespread outage of Google Cloud services caused disruptions for many businesses and organisations that rely on the platform for their operations. Should I continue?

CGamesPlay 4y ago

What state are you thinking of? The containers are ephemeral and the dependencies are well specified in it. You can complain about shipping Ubuntu, but the rest of this doesn’t make sense.

vilunov 4y ago
Makes perfect sense to me, sadly. The dependencies are specified in excessively, that's why everyone is shipping Ubuntu. This is caused by and further facilitates the development style of "do not track what we use, just ship everything". Also, the dependencies are specified in container images, which themselves are derivative artifacts and not the original source code, and these dependencies often change in different container builds with no explicit relevant change. There are three practical problems as a result: - huge image sizes with unused dependencies delivered as part of the artifact; - limited ability to share dependencies due to inheritance-based model of layers, instead of composition-based model of package managers; - non-reproducibility of docker images (not containers) due loosely specified build instructions. Predicting future comments, nix mostly fixes these issues, but it has a bunch of issues of its own. Most importantly, nix is incredibly invasive in development process, adopting it requires heavy time investments. Containers also provide better isolation
- earthling8118 4y ago
  It doesn't have to be a choice of containers or nix though. You can put your nix built applications into a container just fine. You can also pull an image from somewhere else and shove nix stuff into it as well. There is definitely a bit of a learning curve but the time investment is frequently over exaggerated. I see it as similar to the borrow checker in rust. Yes, you have to spend some time and also learn about the rules. But it helps you build software that is more robust and correct. Plus once you're into it you save significant time not having to deal with dependencies especially when bringing on new people
  - vilunov 4y ago
    This is true, I can put nix apps in a container. It improves the reproducibility of builds, but it still wastes disk space, because the container is still based on layers and not packages. > There is definitely a bit of a learning curve but the time investment is frequently over exaggerated I'm not talking about the learning curve and its time investment, I'm talking about design problems. Nix's invasiveness is completely unnecessary in modern Linux, it makes its installation a very special case and requires lots of patches to just get stuff to work in nix. The fact that nix patches built binaries so that they point to correct shared libraries locations is a crutch which shouldn't be there in the first place. It also tries to reimplement pretty much every package manager and build tool, even if they already work well and provide the reproducibility guarantees, including cargo, poetry, npm/yarn. This is a time investment, but it doesn't help me build software that is more robust and correct, that part is already handled for me. Instead, it just worsens the DX, as it forces me to use tools non-native to the ecosystem without first-class support for commonly used features.

hospitalJail 4y ago

>The dev model of "we've lost track of our dependencies so ship Ubuntu and a load of state" never sat well. This was my first thought when I learned of Docker. I have a hard time calling myself an 'Engineer' when there are so many unknowns, that I'm merely playing around until something works. I insist on being called a Programmer. It pays better than 'real' engineering. Why not embrace it? (Credit toward safety critical C and assembly though, that's engineering) EDIT: Programmer of 15 years here

0xDEF 4y ago
I doubt the real™ engineers at NASA and SpaceX know everything their proprietary closed-source Matlab-to-FPGA tooling is actually doing under the hood.
- ijaeifjzdi 4y ago
  can't say for spaceX, but most NASA glue is built in house. close to zero proprietary ones. maybe the vlsi is closed. but that is "industry standard" i guess. rest is a bunch of mathy-language du jour held together with python or something. ...opaque docker containers going to prod doesn't have a excuse other than inefficient orgs fulled by VC or Ad money. Or maybe they do, but you won't excuse them using NASA as an example :)
Clubber 4y ago
Developer/Programmer/Engineer titles are mostly meaningless because they mean different things at different companies. You can go wayback and call yourself a coder.
- freedomben 4y ago
  what's old is new again. the teenagers nowadays call themselves "coders" because "programmer" is for old people.
AlotOfReading 4y ago
As someone that does what you consider "engineering", my current project is containerized because I've lost too much of my life to debugging broken dev environments. The person who ships safety critical releases at most companies isn't a developer that's deeply familiar with the code, it's usually a distracted test engineer with other things to do that may not be very tech-saavy. Anything I can do to help them get a reproducible environment is great.