When Java came along I felt sad. I loved computers and software but I just didn't like Java. But this was the early 2000s and Java had taken corporate and web development by storm. Everything was Java.<p>So I felt flat. Computing was diminished not because Java was inherently bad, but it just didn't appeal to me personally.<p>As it is with Docker and containers. I'm sorry to go against accepted wisdom but I just don't like this technology. To me it is a complex kludge. I feel that it is simpler software technology that should succeed current overly complex technology.<p>It's my personal subjective opinion but I just feel that docker and containers are a big complex mess and I'm saddened that this is the direction of the entire industry.<p>Probably you love docker and containers. I don't knock that. It's just not to my preference.
Commenting to offset the negativity:<p>I'm looking forward to flatpak, and I currently use firejail + liberal use of `chromium --user-data-dir=~/.config/chromium-<website>`.<p>Because web-app based software and web-services I frequently interact with (slack, gitter, discord, twitter) should absolutely be separated from my general browser, and from each other. Most methods of web tracking and phishing/XSS attacks will be neutered in this setup.<p>And because my browser, and all of these separated services, should not have unfettered access to my system and personal files.<p>I don't think I will bother with containers for general software, but web services are an attack vector and should be treated as such, even at the expense of complexity over simplicity.<p>Frankly, the notion of simplicity was out the window the moment we started using the web as a development platform.
Perhaps containers are an amazing thing, but on trying to learn more about them, and Docker in particular, what I observed is that most of the documentation is full of enterprisy buzzwords coming out of marketing, rather than real technical information. The docker website and documentation, I feel is more a disservice in this regard.<p>I was looking at containers for maintaining a sane and replicable environment for software development without interference from changes on my host machine, yet most docker guides do not go into that workflow.<p>Difficult to find crucial info, like can linux containers run on windows and vice versa, licencing requirements and so on at a quick glance.
"Red Hat is working hard to make OS Containers easier by enabling systemd to run inside a container"<p>Redhat is still refusing to admit that containers highlight systemd's weaknesses.<p>Containers benefit from simple init. The systemd argument has become so religious iside RH now they are blind to the fact that, for all systemd's benefits on a laptop linux install, it complicates a container.<p>Its affecting their position on containers badly, because they have no middle ground between "full os" and "1 bin per container". Everyone else can see that sshd in a container is not _ideal_ but a handy stop gap sometimes, as long as you dont then stuff the container with stuff you dont actually use. Redhat are blind to that and, as a customer, its horrible. They refuse to "support" simple RHEL OS containers, i.e. a container without systemd.<p>Its a full RHEL vm or Docker, or your warranty is void. This makes migration to containers hard for us. Its probably counter productive for Redhat because when we do go full "bin per container", RHEL is out of the picture entirely.
`The second big argument for project-based learning is that it more closely resembles what students will actually do on the job`
I never understood this argument as this is so far from the truth. Most of the time working in professional environment you have to deal with legacy code, you are a lucky bastard if you can start a project from scratch.
it sounds like a lot of the negativity revolves around devops. that's understandable. it's part of a pendulum that swings back and forth. devops and docker as topics aren't really mutually inclusive.<p>docker, however, is more about the abstraction of complexity stemming from the industry's overall drive toward scalable, distributed applications and development teams. it's more analogous a developer saying, "why do we even use virtual machines?!? bare metal is way faster!"