[HN Gopher] Linux virtual machines, with a focus on running cont...
___________________________________________________________________
Linux virtual machines, with a focus on running containers
Author : udev4096
Score : 75 points
Date : 2024-05-27 12:30 UTC (10 hours ago)
(HTM) web link (lima-vm.io)
(TXT) w3m dump (lima-vm.io)
| amelius wrote:
| Anyone else getting totally bored from installing an reinstalling
| software environments over and over again into containers?
| gchamonlive wrote:
| Maybe try nix?
| evgen wrote:
| And now you have two problems...
| gchamonlive wrote:
| Isn't it always a matter of choosing which problems you
| prefer?
| max-privatevoid wrote:
| The problems that Nix gives you are much nicer to have than
| the problems of tbe FHS absurdity.
| amelius wrote:
| Does it have precompiled binaries for embedded systems?
|
| My problem is that embedded systems usually have little
| compute power so compiling stuff for them is really tiresome
| (and cross-compiling is another nightmare), so I apt-get what
| I can and compile as little as possible.
|
| Also, afaiu, Nix is tied to a particular version of libc
| which has a high probability of not working with the vendor-
| installed libraries on my systems.
| pxc wrote:
| Depends on the embedded system. It has precompiled binaries
| for aarch64-linux, but idk about others. There's definitely
| no public binary cache for bespoke, proprietary platforms
| though.
|
| > Also, afaiu, Nix is tied to a particular version of libc
| which has a high probability of not working with the
| vendor-installed libraries on my systems.
|
| Nix ships a whole dependency tree with every package, down
| to and including a libc. If you have another libc, Nix
| won't care.
|
| On the other hand, if your hardware isn't supported by the
| libc Nix ships, the natural path is probably to package
| whatever given libc in Nix and build against that. Then you
| are back to building from source via Nix.
|
| Nix has pretty good support for cross-compilation,
| multilib, and 'remote builders', though. You can set your
| embedded systems up so that Nix builds happen on more
| powerful machines and then get copied over.
|
| Nix evaluation itself requires a lot of RAM, though, so if
| you use Nix for embedded you probably still want to push
| packages to the weaker systems from the outside.
| gchamonlive wrote:
| So for you maybe not nix? I'd have never known given the
| original comment
| pa7ch wrote:
| I've been enjoying gokrazy. Makes cross compiling and
| updating my rpi server a breeze. Still an early project
| though but it works well for my needs.
| pjmlp wrote:
| Every time I am dealing with containers, I wonder myself about
| the irony of Linus discussion with Tanenbaum.
| UI_at_80x24 wrote:
| Ansible is directly your friend here. Puppet/Chef, and others
| help in other ways too.
|
| Unless your problem/complaint is deeper then that.
|
| Bored sysadmin: All I do is install X, Y, & Z over and over
| again. Surely there's more to life then this.
|
| or
|
| Resource-minded DevOps: Hey, it seems like we install the same
| 4 packages on these hundreds of containers! Surely there's
| something we can do to optimize this!
| amelius wrote:
| Even with scripting it is tedious because the scripts keep
| breaking with new versions of packages.
|
| And the number of required packages gets bigger and bigger.
| UI_at_80x24 wrote:
| very true.
|
| But with Nix!...Now you have two problems.
| hhh wrote:
| I haven't really ran into this issue that much, we've had
| the same setup across Ubuntu 18.04, 20.04, 22.04 and the
| only thing that has broken across that was setup of
| wireless.
| hagbard_c wrote:
| No, not really but that is because I use containers as a way to
| create multi-purpose machines, not single-purpose application
| hosts. No docker or any of its clones except for those few
| services which are wholly based around it - e.g. Kasm [1] - but
| (bottom to top) Debian - Proxmox - Debian containers running
| multiple services. This lets me parcel out that biggish server
| into smaller bits which each play their own role: a database
| server running anything database-related (Postgres, Mysql,
| Redis, Rabbitmq, etc), a mail server running mail-related
| stuff, a 'serve' server running all user-facing services
| (dozens of them on a single container), an authentication
| server running LDAP/Kerberos and a central Letsencrypt certbot
| instance which serves all other services in my domains, a few
| build servers for different environments and, yes, a separate
| 'docker' server where it truly is 'containers all the way down,
| sonny'. Using containers this way makes for an easily
| manageable system where components can be swapped or migrated
| without significant effort without overcomplicating things just
| for the sake of it.
|
| [1] https://kasmweb.com/docs/latest/index.html
| chrisweekly wrote:
| > "a 'serve' server running all user-facing services (dozens
| of them on a single container)"
|
| I'm no expert, but I've encountered the "stick to one process
| per container" rule of thumb many many times. Could you
| please share your perspective? Thanks in advance.
| stackskipton wrote:
| Because it's excellent rule of thumb. When you need to run
| more than one process in container, you are forced to write
| scripts/service handler. This introduces complexity to
| system and troubleshooting is much more difficult when
| things go wrong. However, on practical level, it has to be
| done occasionally especially when containerizing third
| party applications that were not designed for containers.
| stackskipton wrote:
| Ops here, bored is good. Bored means it's working properly and
| it's a solved problem. Also, I haven't seen a good alternative
| outside ConfigMgr like Puppet/Chef/Ansible or something like
| Nix which has another set of problems. Containers work well
| enough and their positives vastly outweigh negatives in most
| cases.
|
| It's also a solvable problem for most part. If you have a set
| of packages almost all the software needs, someone should
| probably create base image for everyone with everything pre-
| installed so your dockerfile starts with FROM
| companybaseimage:latest
| sunshine-o wrote:
| It's probably because everybody have been doing that for a
| decade and we have no good straight explanation on why.
|
| The most naive thought it was good for security reasons.
|
| It kept a lot of people busy during the ZIRP era when money was
| abundant or corporation were moving to the cloud.
|
| My guess is either the industry is gonna stagnate or a new
| simpler solution to package and run application is gonna appear
| sooner or later.
| indigodaddy wrote:
| Will this do any gui/X? (Didn't see any mention on the site faq)
|
| Also can it interact with the host microphone and play sounds
| thru host speaker etc?
| carwyn wrote:
| See "Adopters" section of the GitHub README:
|
| https://github.com/lima-vm/lima?tab=readme-ov-file#adopters
| indigodaddy wrote:
| Thanks. Although I didn't meant a gui front-end or management
| of Lima.. I meant can Lima do Linux gui/X applications?
| cube2222 wrote:
| I recommend checking out OrbStack[0] for containers and VMs on
| MacOS.
|
| It's really, really, really awesome and performant. And it seems
| to be a one-man show. Really impressive. I've switched from
| docker for desktop a year ago, and it's been a night-and-day
| difference.
|
| Most I've shown it to have very quickly switched to it as well.
|
| (I'm completely unaffiliated, just a very happy user)
|
| [0]: https://orbstack.dev/
| ElCapitanMarkla wrote:
| +1, the dev is fairly active on here too
| https://news.ycombinator.com/user?id=kdrag0n
| jFriedensreich wrote:
| I had really bad experience with orbstack, it is fast but the
| dev domains work half of the time and sometimes point to the
| wrong container. the "support" was not really reactive, that is
| when i figured it is probably one or two people behind it.
| Total no go for anything i have to pay money for and rely on at
| work. I spend the time building the dev domain feature i was
| missing from colima and never looked back. Performance seems to
| be on par, especially with vz and virtiofs virtualisation.
| fbn79 wrote:
| Can become an alternative to vagrant+vitualbox?
| breakingcups wrote:
| I genuinely wonder, who is this for? I'm having a hard time
| telling from the website.
| zokier wrote:
| Its basically building block for Docker Desktop replacements.
| The "adopters" section is informative, you got podman-desktop
| and finch there.
| teekert wrote:
| Looks like Incus/LXD/SystemD-nspawn.
|
| All nice if you need a system to try something quickly. But
| nowadays I just want to use infra as code. With Nix(OS) and
| docker/podman compose a system is clean and comprehensible. I
| feel like I don't really need VMs anymore.
___________________________________________________________________
(page generated 2024-05-27 23:01 UTC)