you can get about 90% of the way to this cloud-independence nirvana
with just docker-compose... ECS command-line tools accept
docker-composse files as input...

What about service discovery? Doesn't a container have to announce itself somehow, so other components know where to find the service it provides?

(Yes this is probably a newbie question. I am somewhat container IGnorant.)

No. You'd use something like Docker-Compose or the Docker network bridge.

Hello from IG using an old Raspberry Pi 2B with the latest Raspbian.

It's slow. But it looks damn good. LXDE actually looks like a DESKTOP.
It behaves like a desktop. Everything is where you expect it to be and behaves the way you expect it to.

Why can't any of the mainstream people build environments like this anymore?

This is actually a bit of an experiment. I'm basically taking VDI for a spin, seeing if I can use it as my daily driver. Since I have 1 Gbps Internet at home now, it might be feasible. I would also be able to keep completely separate desktops for different purposes (such as work and personal ones) which is something I've been wanting to do anyway.

The pi is slowing it down, but if it works in concept, I might go for an Intel NUC or even an old HP thin client off eBay.

I just bought a couple of HP thin clients. If you need any add-ons, it's not great. But as a generic RDP client, it's fine. I'm using it with Citrix too.....


You may want to check out the Intel Compute Stick.... They're pretty cool.

New HP thin clients or older ones? Most of the ones built in the past decade seem to be just small computers. People are reloading them with Linux or Windows and using them for low end computing tasks -- home servers, media servers, NAS boxes, etc.

My needs are more traditional; I really do want to use it as a thin client even if I don't use the factory-supplied software. What I'm seeing so far is that running the desktop remotely has very little performance penalty over a multi-megabit network, but the Pi can't update the screen fast enough. Even my six year old tablet does it better.

This wouldn't be the first time either. I ran ThinStation at home for a long time and loved it.

Brand spanking new.....

2019-02-27 14:28 from IGnatius T Foobar

you can get about 90% of the way to this cloud-independence nirvana

with just docker-compose... ECS command-line tools accept
docker-composse files as input...

What about service discovery? Doesn't a container have to announce
itself somehow, so other components know where to find the service it

provides?

On Amazon ECS, there are generally two different ways we handle this, depending on the use case:

(1) Set up an ALB - Application Load Balancer. The client discovers the service by looking up an A record for the ALB. As docker containers come and go during scale-in/scale-out events, ECS transparently handles registering their host+port with the ALB. In cases where said docker containers are co-located on the same physical Linux kernel, it's possible to set it up such that the port is a dynamically allocated ephemeral port.

I don't know, off the top of my head, whether the ECS command-line tool which ingests docker-compose files, supports this style of setup in a standardized way, so this is a case where, maybe, Kubernetes might provide better cloud-vendor independence in theory. (But I don't think this really matters, as K8s has its own set of problems. Y'all should also be thinking about stack-independence and building apps that can be deployed to either ECS or K8s or similar.)

(2) Sometimes you don't want to use a load balancer because services want to have direct knowledge of how many peer instances are out there, and the addresses of those peers. In such a case, ECS can be configured to do service discovery via DNS SRV records, which resolve to a a list of A record + port number combinations. This is something that ECS also supports natively and it's exposed in the command-line tool which ingests docker-compose files. So there's some degree of standardization here (though the tool is not fully conformant with the latest version of docker-compose syntax, it supports a meaningful subset.)

That's great, but I build clouds, I don't consume them. I'm more interested in the generic technology.

The ALB idea sounds like the right approach, though. I need to get more container savvy.

I have a Linux computer on my desk again. As a very patriotic frog once said: "Feels good, man."

The mainstream desktops are a bit too bloated for my taste, so I switched to LXDE (which is using OpenBox as its window manager). All of the chrome is 2-D but not "flat", which I think is perfect. And it's built to work like a desktop, not like a tablet or phone.

It found and configured all of my hardware without my help, right down to being able to tell me how much battery life is left in my cordless mouse.
Bluetooth just works, the screen just works, sound just works, and it even found and configured my network printer by itself. That last one isn't possible on Windows, which needs strong admonition to be convinced that my HP LaserJet 5 is not actually an HP ExpensiveInk 9999.

It's been too long. I'm enjoying this.

mv

Yeah that's about it. Looks like this person is just plugging a web site, but with content like "how to rename a file" I'm not sure who exactly is going to go there. :)

Debian should consider modifying their install to ask everything it needs of the user up front, then kick off the install of the OS with the stored information.

This business of having to nurse a Debian install is rather annoying.

You can do a pre-seeded installation:

[ https://wiki.debian.org/DebianInstaller/Preseed ]

It's intended for unattended installations though, so you might find it's more trouble than it's worth.

Yeah, I'm more interested in answering the questions I need to ask, then walking away while it finishes building.

Right. You'd think that if they can handle a pre-seeded installation, they could build a UI that creates the instructions to drive it.

Or at least do that for the most basic installations. Mine tend to be really complicated because I am an insane nerd. For example, when installing Linux on top of KVM or VMware, I put the boot volume on its own 1GB virtual disk, and the swap space on its own virtual disk, then the main virtual disk for LVM. Why bother with partitions when the hypervisor gives you that kind of granularity? But try finding an easy way to tell the installer to do that for you. It involves A LOT of steps, even though the end result is much simpler.

And I'm seeing a similar problem right now. I've got a machine that I'm upgrading from Stretch to Buster:

apt-get -y update && apt-get -y upgrade

The full upgrade takes a long time. It's the kind of operation you want to walk away from until it's finished. But you can't, because dpkg jumps in every now and then to ask a question about how you want so-and-so package reconfigured.

But at least you only have to reboot once.

Ugh... yeah, the upgrade process would be that way, I suppose, because each package can individually request some kind of information to assist it in knowing how to reconfigure your machine from what it was, to what it will be, where such a need exists.

OTOH, if you know all the questions that'll get asked, and you know how to answer them (as in, the names of all the various variables, etc), you can tell Debian all the answers in advance of running the upgrade, I think, and it'll Just Do It.

But... Debian doesn't provide a very good way to collect all these Q&As in advance of running the upgrade. Perhaps that's something they could work on. Heh.

Upgrades can call dpkg-reconfigure to ask questions, and they frequently do.
I'm not sure if it's feasible to do all of those ahead of time, but it might be possible to save them all for the end, and run all of the dpkg-reconfigure operations at once.

The biggest one is the "so-and-so wants to upgrade /etc/somefile but the local version has changed" and you have to tell it whether to replace the file or keep your own. On the Red Hat family of distributions, it simply saves the file next to your existing one with an ".rpmnew" suffix. I think that's fine for most circumstances. Red Hat seems to understand that people want to do unattended upgrades.