Abcdesktop – a cloud native desktopless system
abcdesktop.io
abcdesktop.io
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
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.
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.
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.
That's all in the Dockerfile though... it's a simple and standard way to show how to install something. It's just like a makefile, but it's one that always works whatever the environment you are in, whatever the dependencies that you already got in your system and in most case, whether it has been maintained or not.
> ports opened publically
... and that wouldn't have happened if you used something else? How so? Unlike any other solution where each application choose how ports are configured, on Docker you actually need to be aware of the port to open and specify it. I means sure you could have not known that by default it does it over 0.0.0.0 but that would be true for almost any applications (and that's when you are even aware of the ports, that's a basic CTF challenge to have an unknown port open).
> rampant disk use
That's a good point, I agree that the storage can be quite annoying, but at the same time, you handle that the same way you would handle that with any other software, simply by knowing where the storage goes and why.
> poor log files management
I love how log is handled with Docker, there's a single log output and that's it. It's the source of truth for logging, easy peasy. You want your logs to be pushed to another system? Well connect it to the Docker logging system and that's it.
> lack of security updates
Could you develop that one? You are responsible to keep updating whatever you use, whether it's a docker container or an application. One or the other doesn't change that. Maybe you means that it's so easy to make a Docker image that it's just as easy to stop updating it thus making it less secure for whoever use it? I means sure... that would make it less secure but it's still possible for any application to be abandoned, it is your responsibility to make sure whatever you use will be maintained.
> Seriously, I wish devs would at least list the tech stacks they're using in their apps in the readme.
I haven't seen many Docker images that doesn't do that. I do have seen a few that doesn't go into depth on how to setup the environment, but the tech stack, that's mostly a given.
Any good examples of that?
The same with logfiles. Some images contains everything, and the instructions is to have volumes for their poorly written applications log output. Just because Docker-the-application does stdout doesn't mean that the processes running in a container does stdout.
For security updates you need to be sure that the maintainer of the image is not only looking for updates to the application, but also all explicit and transient dependencies. In a classic setup with a package manager and explict dependencies those are the responsibility of other teams/individuals.
That said, Docker with friends has very much changed the landscape for the better, and I would have a hard time going back to maintaining least denominator java versions, python virtualenvs and tracking down incompatible shared libraries.
_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.
- 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.
DLL --> JCL ... Joinable Container Libraries
That unfortunately already exists; Kubernetes namespaces and Helm Charts.
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.
> 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.
It's using NoVNC.
I know very little about how the two compare.
My personal gripe with piping curl output to sh is about expectations. If I have some binary I'm running, I have _some_ expectations about what it will do, same for a Makefile, and RPM, etc. None of those things are guaranteed to do what they're supposed to but I have some idea what _should_ happen.
Unless I read through the script, I have less expectations about what the script is going to do. It says it will install my program but is it going to pull in dependencies from my package manager? Download and compile something, shove binaries in my $PATH, edit dot files in $HOME?
If someone places a shoe box on your doorstep you might expect shoes to be inside. Of course, there's a non zero chance its full of bees. But shoes are a reasonable guess.
If someone places a cardboard box on your doorstep with no writing on it whatsoever, there's no expectation about whats in the box. (Unless you hear the bees buzzing from a distance.)
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.
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...
or old laptop/desktop
or maybe even a phone
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.
ABC + docker = Vnc + x1
Docker wraps to the next line. Very confusing
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.