Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abcdesktop – a cloud native desktopless system

abcdesktop.io

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Abcdesktop – a cloud native desktopless system

#61

Post by Sophistifunk »

TuringTest wrote: post #21

Why do I keep getting this distinct impression that people use containers to keep reinventing OS processes, but "in the cloud!"? 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 abo…

No you're not wrong, it's the constant churn of "our current isolation between users/processes/apps isn't as good as we hoped, so lets just run virtualise the whole OS" that has been driving multiprocessing since the 70s.

Re: Abcdesktop – a cloud native desktopless system

#62

Post by wallacoloo »

chrisshroba wrote: post #35
TuringTest wrote: post #21

Why do I keep getting this distinct impression that people use containers to keep reinventing OS processes, but "in the cloud!"? 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 abo…

If I give someone a sample docker-compose file, they can immediately run my service regardless of OS. If I distribute manually, I need to provide instructions for setting up the proper dev environment and packages for several common OSes and distros (brew maybe, apt, rpm, etc.). 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 d…

> If I give someone a sample docker-compose file, they can immediately run my service regardless of OS

_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.

Re: Abcdesktop – a cloud native desktopless system

#63

Post by dwild »

cmroanirgo wrote: post #42
chrisshroba wrote: post #35

Earlier quoted context omitted.

If I give someone a sample docker-compose file, they can immediately run my service regardless of OS. If I distribute manually, I need to provide instructions for setting up the proper dev environment and packages for several common OSes and distros (brew maybe, apt, rpm, etc.). 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 d…

There's a lot more to running a service than getting it running easily. Longevity/stability through applying updates should be engineered too. 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 j…

> The problem is when using Docker, you can't tell what the dependencies are for your app.

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?

Re: Abcdesktop – a cloud native desktopless system

#66

Post by gowld »

chunk_waffle wrote: post #30
10000truths wrote: post #25

Earlier quoted context omitted.

No worse than downloading a pre-built binary off the internet and running it.

If you follow that to it's logical conclusion then "everything is terrible and nothing is secure" (which is probably the reality) 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 _shoul…

Makefile, RPM , and shell all essentially do the same thing and have the same power to violate your system.

Re: Abcdesktop – a cloud native desktopless system

#68

Post by tehlike »

hawski wrote: post #37

For a cloud native desktopless system I was thinking it should not be remote desktop based. Is there a cloud desktop, that is a bit more like NeWS? I mean text rendering client side as HTML/CSS, image and video view via img/video tags. A sprinkle of JS to make it smooth and dynamic. With normal windows and maybe even a taskbar would be splendid. Possible X or Wayland integration, but as separate windows in such a sys…

https://os-js.org/ https://dustinbrett.com/

Re: Abcdesktop – a cloud native desktopless system

#69

Post by hackerfromthefu »

qbasic_forever wrote: post #34
TuringTest wrote: post #21

Why do I keep getting this distinct impression that people use containers to keep reinventing OS processes, but "in the cloud!"? 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 abo…

> Is there a subtle detail about packaging software for distribution as isolated executables that I'm missing? In practice it's a nightmare, particularly for legacy software that demands a ton of dynamic linking to system-installed libraries.

Whether its a nightmare or not depends on what you practise.

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.

Re: Abcdesktop – a cloud native desktopless system

#70

Post by mzi »

dwild wrote: post #63
cmroanirgo wrote: post #42

Earlier quoted context omitted.

There's a lot more to running a service than getting it running easily. Longevity/stability through applying updates should be engineered too. 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 j…

> The problem is when using Docker, you can't tell what the dependencies are for your app. 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 ope…

The dependencies in your Dockerfile is as opaque as you wish. I've seen a lot of public available images built "FROM base" or similar, hidden somewhere in their maybe public CI. There is nothing in Dockerfile that actually shows your dependencies.

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.

Post reply on HN