OpenSUSE MicroOS(microos.opensuse.org)
microos.opensuse.org
OpenSUSE MicroOS
https://microos.opensuse.org/
34 comments
I assume you mean SLE instead of "SEL"?
Indeed, but its pretty obvious how one can make that mistake. I've been in Redhat land too much lately.
Yeah, we have SLE -> SUSE Linux Enterprise , then S or D or others stuff. Server, Desktop, 4SAP, etc.
This sounds neat, but the system requirements seem a little odd. Minimum 20 GB of disk space for a stripped down Linux distro?
The space is probably required for btrfs snapshots and to keep the last "good" image around in case a rollback is needed.
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 shouldn't be an issue. Btrfs snapshots are copy-on-write, so unless all blocks changed the big binary file should be there just once.
Yeah.. It happened to be a qcow2 image for a virtual machine. I meant to put it on another disk but accidentally forgot to set the right path.
Well..that's been addressed now:
https://kubic.opensuse.org/blog/2020-11-23-requirements/
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.
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.
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.
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
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 :)
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 :)
So this is their alternative to fedora CoreOS and RH CoreOS ?
Yep. This is openSUSE's answer to the CoreOS family of operating systems.
Fantastic, I'm looking forward to testing this out.
Wow I cant wait to play with this asap.
Love it, I just not gone use anything with BTRFS. Any chance I can get the same with ZFS instead?
> just not gone use anything with BTRFS.
Why? (Legitimately asking, I haven't played around much with using different filesystems.)
Why? (Legitimately asking, I haven't played around much with using different filesystems.)
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.
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.
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.
That's not true. User data has defaulted to Btrfs for over two years now. This change occurred across the entire family of openSUSE distributions.
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.
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.
Same thing happens with ZFS to be fair.
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.
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.