Next thing, you'll see announced a platform for reusable container services that can be dynamically linked from other containers - to avoid including them multiple times in your application containers that share the same version, and we'll have come full circle.
Is there a subtle detail about packaging software for distribution as isolated executables that I'm missing?
Containers are a middle-ground, and a useful abstraction -- where you can have a group of processes that can share some resources and be accounted for together, but without the need to emulate hardware or a second hypervisor (kernel).
For lots of workloads, though, processes would be enough. Some more could be done with additional work to kernels to help group processes together (Linux cgroups, Solaris contracts and zone facilities) and more container-aware schedulers (Not sure what Linux has, Solaris has a 2-layer scheduler for its containers).
I was heavily into containers in the 90s and 2000s, and then VMs when they became more viable with Xen 2, but I've been moving things back to just processes.
Speaking personally, I know how to write a proper Dockerfile, (and it's a skill that's learnable in a couple hours). I have no idea how to distribute packages through other formats and avoid footguns.
The problem is when using Docker, you can't tell what the dependencies are for your app. Telling me i need node or Go or php and/or what database or redis, etc etc gives me an instant feel for how the deployment, as well as how security updates, need to be applied. Docker is just a black box by comparison... at least to me. All my attempts at running docker solutions on small vms have ended badly (ports opened publically, rampant disk use, poor log files management, lack of security updates...). Seriously, I wish devs would at least list the tech stacks they're using in their apps in the readme.
However, i do grok that people who've embraced the ecosystem would like it that way... but not all techs like it.
For me, the best projects are those that lay it all out, warts and all and then have a separate repo that manages the docker state.
_if they're already bought into the docker ecosystem_, this is true. if not, then they first have to go read up on docker first: figure out how to install it (OS-specific), enable the docker system services (i think systemd more or less standardizes this step), configure a user that has permissions to manage docker deployments (also frequently OS-specific), etc.
not saying docker is or isn't a worthy tradeoff between balancing distribution work between the code authors and the OS packagers and the users. just don't blind yourself that it is another thing that users have to learn before they can use your stuff.
That unfortunately already exists; Kubernetes namespaces and Helm Charts.
To the extent that containers solve a problem, it's mostly a problem with package management, and with UI for process isolation/permissions/hardening.
In practice it's a nightmare, particularly for legacy software that demands a ton of dynamic linking to system-installed libraries.
Dependency heavy environments such as e.g. node or python make it a nightmare. But large stable base library environments with selectively chosen dependencies are usually easy to manage, e.g. .NET.
DLL --> JCL ... Joinable Container Libraries
I think that wouldn’t be a bad idea. It’s good for RAM and disk space usage while still isolating processes. Would be useful for IoT devices without much memory or space that still have to run docker.
- you will need a copy of each platform running in order to build the binary - it's X-times++ as much work to package for X number of platforms. - The code you chose might not compile well on all platforms without code changes. - Dependency conflicts can be a pain.
oh boy, i could go on.
I logged in using my Gmail. I assume a sizable number of people here have a throwaway Gmail. It didn’t need access to anything in the mailbox like with GitHub.
Neat project. Cool for a proof of concept, but not solving any needs I have.
It uses only Personal user data Profile information (read-only), just to display your user name in the top bar. The scope OAuth 2.0 has changed from ‘user’ to 'read:user' You can use a GitHub OAuth safely, it was a misunderstanding in GitHub doc OAuth
Note that I have never had a good experience using noVNC (the web-based solution used by this service) even over fast LAN - I think it's because of the additional overhead of the web browser.
I personally use SPICE for VDI which performs decently over LAN, but is not as good as RDP over WAN with constrained bandwidth.
It's using NoVNC.
I know very little about how the two compare.
It's possible for the server to detect that you're actually using curl (with the help of the user agent of other methods) and also that you're piping it to an interpreter.
Knowing that, the server could send you a malicious payload, that wouldn't be apparent when only downloading the file otherwise.
Some people think this isn't the real issue, that (the lack of) code signing is the real problem. I don't disagree with that, but really, people should look at the code they're going to execute, whenever possible.
And when I say "whenever possible", I sure believe a few lines of shell script deserves to be inspected. Even if you lose the 0.5 seconds of automation the pipe provided. I mean, we're not talking about millions of lines of kernel code, here.
I was thinking about a desktop that would be rendered on the browser, but applications would run actually on the remote server. So if you would log in from a different computer you would have exact same desktop opened. A bit like X with this difference, that the text rendering would be done straight on the browser without canvas.
But that's a good entry point.
> Because docker containers are lightweight and run without the extra load of an operating system, you can run many graphical applications on a single kernel.
This is an odd thing to say. Can't I already run many graphical applications on a single kernel even without docker containers? And wouldn't that be even more lightweight?
I think what is written between the lines is that they compare it to full OS virtualization. That need for that results from the desire to isolate multiple users from each other.
or old laptop/desktop
or maybe even a phone
Honestly I think it's about time to tell management that's nothing costly nor complicated in maintain desktops with custom deploys not just the default install by some vendor, and in supporting them instead of investing in servers with much more resources just to centralize for the point of merely centralize...
Sorry for being rude, I've used Apache Guacamole time ago and I still ask me why it was even though in the first place...
ABC + docker = Vnc + x1
Docker wraps to the next line. Very confusing
