Maybe I'm just really out of my depth on this, but it feels like there's not a lot of information about _why_ these particular steps and tools are used. Why are 4 different Linux images needed? Why are there all of these steps to create a one-time use "init.iso"? Is it just so the cloud-init script can run? I see the call to mkisofs is referencing "cidata", but it's the only place in the whole page that "cidata" shows up. Does that mean mkisofs is cloud-init aware? And why use emulation instead of virtualization?
I guess part of why I'm asking is because I've set up virtual machines in UTM on Apple Silicon before, and I never had to go through all of this just to get Linux installed and configured. The post makes me wonder if there's something I'm maybe missing, but it doesn't give any explanation for me to be able to figure out if that's the case. Maybe the post is meant more just as a checklist for the person that wrote it, for their own reference? But the way the post reads doesn't quite sound that way.
Hmm... that's all coming out sounding more critical than I mean to. I just want more info and I am curious about the approach.
If you just need a single Linux VM, you don't need to fiddle with cloud-init. If you want repeatability or automation, that's when you'd reach for it, whether for setting up per-project VMs, shareable VM configs between developers etc.
Also, you don't need all 4 Linux images, just the one you want to run as your guest OS. Emulation / virtualization depends on the guest OS CPU architecture.
From my understanding, you really need only one image – the article is just providing four for your tastes (Fedora/Ubuntu, aarch64/x86_64). The images are linux installers, which “understand” cloud-init (because it’s “industry standard”), so if you place the {user,meta}-data file in the right place (a volume named CIDATA, it seems[0]), they can configure your installation without really having to go through the tedious process of configuring through the installation process, install packages, and so on.
I don’t understand why anyone would go to the route of emulation in 2025, but if someone wants to run an x86_64 image with UTM, well that’s the only route – I’d suggest just going to an aarch64 image. Things were a bit more rough back in 2020, but stuff got much better and I don’t remember any compatibility problems these days.
My thought was why use UTM? Most of this can be achieved with qemu alone :). But it showed me something new. The cloud init tool was new to me. From my toolbox I would have used ansible or something. But I think it very interesting that this runs all automatically during first boot.
But I agree one needs to read between the lines to understand what the purpose of this post is. As you said it reads like a overcomplicated install setup.
> My thought was why use UTM? Most of this can be achieved with qemu alone
Afaik UTM uses Qemu under the hood, but provides a nice UI on top for the basic use cases. It also has a library of prepared images, so that your VM is a few clicks away from intention to have one.
It can also modify the VM, resize storage after creation etc.
Of course all of it can be done with QEMU alone, but this makes it easier to deal with than remembering tons of QEMU command line arguments.
Guess you misunderstood me. I know that UTM is built on top of qemu. I use it as well. I mean when already using this init image tooling etc why clicking through the UI to setup a VM. One would think to offload this also to a script. Because in the posts steps UTM is just a means to start the resulting image.
> My thought was why use UTM? Most of this can be achieved with qemu alone :)
qemu needs to be studied a bit, UTM is fairly intuitive.
I recently decided to learn how to create VMs with bare qemu (using the command-line).
As I have an arm macbook for work, UTM helped me a ton with aarch64 virtual machines because I could enable debug log and see what qemu options/flags/switches would UTM use.
Unrelated: I have some ideas about writing a tool that aims at being a "spiritual successor" to vagrant (from hashicorp), but focused on targeting qemu rather than virtual box.
Anyone interested? Please let me know (upvote or comment)
Theoretically the entire docker workflow can be translated to VMs. In practice it is a shit show.
The biggest problem by far is building a VM image, because it consists of multiple highly irritating steps.
1. Building custom packages for the target distribution.
Since we aren't using containers, we would in principle need a full VM per application. This is not a good idea in practice. We want to avoid containers, but we still want something very much like docker images on the application level. The obvious answer is building distro specific packages.
Building distro packages is annoying, because the developer machine doesn't necessarily run the same OS as the servers. This means that building the package requires you to spin up a temporary virtual machine or a docker container. Let me tell you, it is by far easier to build your packages inside a docker container and that's why I never even bothered with the VM route, even in situations where I'm deploying VM images. There needs to be a VM based alternative to "docker build" that doesn't necessarily spit out a VM image, but rather it spits out the result of your build (e.g. packages) onto a mounted directory on the host.
If you never built your own alpine packages. Try writing an APKBUILD. It is very easy.
2. Building VM images
Now let's say we are done and just want to build our VM images. There are already distro specific tools like https://github.com/alpinelinux/alpine-make-vm-image. What you want to do is install the packages created in the first step, run a simple bash script for finishing touches and setup cloud-init for the first boot. Unlike a Dockerfile, this should be kept very simple, because the packages are already doing everything the Dockerfile is expected to do. The only thing I would overcomplicate here is directly integrating a package repository into the tool to make it effortless.
3. Running the VM
At this point everything should be quite simple. The primary use case is to run the VM image locally on a developer computer before deployment. Some quality of life features like docker style port proxying and mounting directories would be nice. This is by far the easiest part because tools like virt-manager already exist.
Cloud-init isn't a replacement for ansible unless you're building your own VM images. cloud-init only runs on the first boot. You would use it to install and setup ansible.
> I ask our clients to build a list of their impressions for the first month (or even more) and then revisit that list after a month. A lot of requests magically vanish off that list.
That's a really great and simple idea. Change is hard and it takes time for people to adjust, even if they requested change in the first place. Things like muscle memory and habit can cause a lot of up front discomfort, but basically requesting that they take the time to allow those things to catch up can really shift their perspective of the new normal.
I'm probably an oddball compared to most, but I use a VM as my main work environment. My main reason is because it's super easy to create a backup and test anything like OS or major software updates there first to make sure it doesn't hose anything. Or if I just want to tinker and try new things without risking breaking anything. Also, where I work they get us new hardware every 3 years, and it means I don't have to spend a long time trying to set my environment up on a new computer. I just copy over the VM and jump right in.
I just tried it out, but for some reason it's complaining about missing a pivot_vtab module when I try to open an existing database. (MacOS ARM/Ventura)
This is pretty cool! I recently started keeping "one text file per month" for my work stuff, and it's been really helpful to have one place to go to see what my next plans are, what I was doing recently, picking up on old trains of thought, and finding those lost examples or exceptions that I made note of previously, but could never remember where I kept them before. I don't have any of the rust ecosystem installed currently, and I know nothing about it, which is a little bit a of a limiting factor for me, but this may give me the push to try it out.
Disclaimer: I'm not a developer, but a data analyst in a very small ecommerce company and fulfillment center. I do quite a bit with light-to-medium automation and "development", as needed, but my skill level at anything development related is probably at the level of a hobbyist.
For the workers that are capable of working from home, my workplace asks us to be in the office only on Thursday morning each week. This gives us a consistent time to do things like having our company-wide meetings or social events like company sponsored meals, fun events, etc.
During COVID, I was perfectly happy working at home. My workplace ensured that I had a desk setup that matched what I had in the office, and my home "office" was removed enough from the chaos of the rest of the house that it worked well.
My decision to start going back to the workplace was in the middle of 2022, when all the COVID related stuff finally started calming down and things like mask regulations started to relax. Some of my decision was due to needing to work in a location where I couldn't distract myself by going and doing things around the house. I had started to do that more and more frequently, mostly due to my ADHD and the fact that the novelty of working from home had worn off.
But another really big part of my decision was because I REALLY did miss seeing my coworkers in person. I'm in this rare unicorn situation where I absolutely love what I do, I love the company I work for, and I love the people I work with. Being there just makes me happy at all levels. This isn't even about an "ideal office setup" in the strict sense you're thinking of. I'm currently in my own office, but I spent the first 3.5 years working in an open office with 3 to 5 others, and that was just as good.
I know a lot of people that have that "Sunday Dread" about having to go to work on Monday, but I honestly get almost giddy Sunday evening knowing that I'll get to go to work the next morning. The really funny thing is that I consider myself to be a pretty extreme introvert. But all in all, I'm well aware that this whole outlook is extremely uncommon, so it's probably not truly considered a "blind spot" on your part, but more that I'm just an outlier.
I've seen the "workspaces" thing in a few different browsers now. I know Vivaldi and Arc have them, and it sounds like it's a separate thing from profiles, but I don't quite grok what the difference is between workspaces and profiles. Can anyone help enlighten me? If you use both workspaces and profiles, what do you do differently between them?
I use workspaces in Vivaldi and they are pretty much a set of tabs that I can switch as a set, but all under the same profile. As an example, in my dev workspace I have GitHub, localhost, and a few other things I might need. In another workspace in have Google calendar, Jira, gmail, etc… I can switch workspaces and it will switch all of the current tabs in my browser.
But, I’m logged in, say, in the same GitHub or Google account across workspace.
Profiles on the other hand (I’ve used those on Arc) change where you are logged in… so I can be logged in to my work gmail on one profile, and to my personal gmail on another.
Personally I don’t find profiles that useful just for the fact that I simply use different browsers for personal and work… but a use case for profiles is, for example, to be signed in as admin and user to your local dev web application and test things between the two just by changing tabs instead of having to logout and login
Arc spaces have transient and pinned tabs, which in turn can be organized as needed into folders. Some tabs are actually multi-tab (split screen). The folders themselves have a neat feature whereby active tabs can be shown while hiding inactive tabs located in the same folder. I can also switch to a specific space with a user defined hotkey, and customize the color of each workspace. Each workspace can have its own profile (and history) or you can share profiles between workspaces. You choose.
None of those on their own are groundbreaking, but all together they make for a compelling differentiator (for me anyways, but I have ADHD so prioritize different things than most).
Describing all that as "absolutely nothing [other than a new window]" is not accurate at all.
thanks for the excellent description... but the question was how it's different from profiles, which is used for isolation and settings change. what you described is still nothing more than moving windows around.
I don't know what to say to that. I just described 5 or so features that are objectively more than simply "moving windows around".
Maybe it's because I wasn't clear that many of those features work on per workspace basis - transient tabs (unique to each workspace), unique folder organization features (customized for each workspace), built in split screen (again - with custom arrangements per workspace), hotkey switching between workspaces, different color theme per workspace (so it's easy to know which workspace I'm in, or select another window quickly with Mission Control).
Then there's the fact that profiles are a separate thing from workspaces so you can mix and match profiles to workspaces according to your needs. So you can have three workspace and have two share a single profile.
If those features aren't compelling to you that's fine. Just say so. But please comment constructively or not at all. I genuinely have no interest in trying to "sell" anyone on this workflow. I was just answering the question.
>what you described is still nothing more than moving windows around.
Ok, even if that were true (it objectively isn't), I like wrangling less windows. How's that? Good enough for you? Why would I want four windows open, when I can have one or two (did I mention that I have ADHD)?
If it helps, you can think of workspaces like another level of tabs. Tabs are objectively good right? Yet everything you can do with a tab can be done with a window. Right?
I've used both DB Browser and SQLiteStudio, and I prefer the flow and interface of SQLiteStudio.
It's been a few years since I've used DB Browser, so I forget exactly what I didn't like about it. Maybe I should download it again and try it out one more time and see if I still feel the same way.
