This is awesome work on the part of the openSuse team! I have always liked the steady improvement openSuse and SuseEL have made over the last 5 years or so. While they are sort of the underdog still (just look at their numbers compared to RH), the fact that at least we have an alternative to RHEL in SEL for when companies require support contracts, is a huge benefit to users. I try not to talk about Canonical for... reasons.
As for microOS, I hope that SEL takes it up with a supported version, as I think this sort of "heres a small, minimal OS suited well to being treated as cattle" approach still has lots of mindshare to capture (soorry alpine, I'll stick to gnuland!), and a large part of that mindshare is in corporations. Although, that said, I do find myself pondering nix and guix a lot more lately than just minimal installs. For some cases I know it's a bad idea, but I have settled on rolling release being the better update model for linux when not stopped by business requirements, and the more minimal the install the less likelyhood of rolling release versions having issues, plus that sort of thing should be caught in testing right? Cool stuff, gonna have to give this a space in my vps list.
You're most probably right. I run my system on a 20gb btrfs partition and I have run into issues before where I ran out of space because of one big binary file that was in every snapshot.
That is what I was thinking, a very heavy "micro" instance.
I am curious what exactly this is envisioned for. Running micro services do not require such things and the system requirements are so heavy, it would need more hardware to run that just running them all in a normal distro.
I never jumped on the container bandwagon since it seems like it adds overhead for very little gain that can't be done with much lighter solution.
JeOS is the SUSE OS for small footprint virtualized environments.
I'm not too sure what niche MicroOS is supposed to fill that JeOS and the full-weight Leap don't already cover.
MicroOS just seems to be answer to RedHat's Silverblue, but with no clear use case in the SUSE/openSUSE product lineup. It makes some sense as a tech demo for an immutable OS, but not much sense as an operational product.
JeOS it's a striped down version of a full blown linux bistro. Think Like RH,Centos. Can be used as a VM os or for anything else.
MicroOS it's a cloud OS linux, more like: CoreOS, RancherOS, AtomicOS. I think it's a default choose for Kubernetes environments.
I've been using JeOS for k8s hosts of Rancher environments since RancherOS was deprecated and I'm glad that they finally released a cloud OS like MicroOS. In case of k8s upgrades, rollbacks and upgrades need to me minimised as much as possible. This OS allow to have all of that in a breeze since it's all based on static images.
JeOS is just a minimal installation into a VM harddisk, that's where the differences end. So it's actually more of a different installation/deployment method than a different distro.
This is 'almost' what Atomic did, which is now rolled into Fedora CoreOS and related derivatives and Silverblue. The eventual idea was not to rely on btrfs snapshots, so it uses ostree instead.
The underlying technology (read-only btrfs system snapshots) is actually much older than CoreOS (in SLE it was introduced somewhere in SLE 11 IIRC) and the idea to use it in a similar way as this is almost as old.
It has multiple advantages over rpm-ostree's approach:
- Much faster (no need to manage thousands of hardlinks)
- Arbitrary modifications can be done easily in a chroot
- Not only /usr is snapshotted
- No need for layering and rebases (rpm-ostree has a base image + rpms on top, which this doesn't need)
- RPMs just work as-is, there are no hacks with %post scripts and so on
Does anyone know any VPS providers that are planning to support this? I'm using Linode primarily because they are one of the few providers that provides openSUSE images, but they haven't said anything about supporting MicroOS yet.
Do it seems like a Fedora Silverblue with the architecture and like CoreOS with the goals. That's interesting - I'd like to play with it in the future, but I don't see a feature that would excite me right now.
I know this is going to sound like a typical missing-the-point HN comment (and possibly deserves to end up on n-gate) but - I do hate the trend of 'xxxOS' meaning not an OS but rather a distribution of linux.
I think it adds confusion as there are xxxOS projects which are indeed separate OSes and it dilutes the meaning of an 'OS'. Probably the GNU/-prefix crowd find it especially egregious as the work put in to the distribution exists more so around tooling than any kernel-specific aspect.
From the name I expected it to be an interesting new microkernel from OpenSUSE (the concept of which surprised me) so I have direct experience of the confusion this naming convention causes :)
A filesystem should systematically from the ground up be designed to be safe, specially one making the claims of BTRFS.
BTRFS however went threw a number of cycles where it was considered save and then end up having issues. Of course there were always features considered unstable. It eating my own data, using non of the unstable features at the time. Maybe I could have recovered it but neither me nor the best IT person I know could recover anything.
My file system rule is simple, eat my data once and I will never use you again.
Maybe its all fine now, and all these issues are gone. Likely this is the case, however I will not use it again.
I would not recommend people not use it, but I'm simply not going to.
Micro-OS uses BTRFS for operating system only. User data defaults to XFS.
The transactional-server role mounts the operating system as read only with /var and /etc being virtual file systems that are committed each shutdown. You can use whatever you want including ZFS for your data.
Things change, new stuff always takes awhile to stabilize. ZFS went into Solaris n 2001, Btrfs went into the Linux kernel in 2013. I've been using it for at least 5 years with no issues.
Not the OP, but I used btrfs till a couple of years ago for my root partition.
Because of the nature of snapshots, the partition gradually fills up after big system updates. The usual `df` command is inaccurate with btrfs. Instead there's a set of btrfs specific tooling that you need to learn which can show the actual space in use.
Freeing up unused space from older snapshots also requires manual work. I often had to start removing the oldest snapshot and it'd turn out that it didn't free up enough space. Continue repeating the step of deleting oldest snapshot and hoping it frees up enough space.
It's possible the tooling is better/convenient now, but I prefer to stick with ext4 now.
I used to work for Suse. During my time there MicroOS was broadly considered to be a joke and abandonware by my coworkers. I worked on the very team developing their k8s solution ( the entire team of which was fired due to the recent acquisition )
My recommendation, which is, of course, my personal opinion, is to stay away from MicroOS.
As for microOS, I hope that SEL takes it up with a supported version, as I think this sort of "heres a small, minimal OS suited well to being treated as cattle" approach still has lots of mindshare to capture (soorry alpine, I'll stick to gnuland!), and a large part of that mindshare is in corporations. Although, that said, I do find myself pondering nix and guix a lot more lately than just minimal installs. For some cases I know it's a bad idea, but I have settled on rolling release being the better update model for linux when not stopped by business requirements, and the more minimal the install the less likelyhood of rolling release versions having issues, plus that sort of thing should be caught in testing right? Cool stuff, gonna have to give this a space in my vps list.