Hi
Jump on the Build Service Mailing list and request it to be added?
openSUSE:Communication channels - openSUSE
Here is the container info…
https://en.opensuse.org/Kubic:MicroOS
I don’t know what your plan is for distributing and deploying the app you intend to build…
If you decided on Docker as an example which would mean that once your app is built, it could probably be found and deployed nearly instantly on any Linux or MSWindows HostOS, Of course a MSWindows HostOS would likely be running a linux environment hosted on Hyper-V to run your containers.
You would start by downloading and deploying the base image. For Alpine Linux, you would “pull” your image from any of the following
https://hub.docker.com/search?q=alpine&type=image
Then you would build your Docker file…
A Docker file essentially is a script that contains all the actions you want to be performerd on the base image… like updating (or upgrading), app installation, configuration, more.
TSU
Well, I would want a buildah (or docker file) or ansible playbook I can point to a public repo with my own apk’s made of custom builds, and assemble my parts from that. Ansible, in particular, because I already host a cloud server that runs alpine directly, I have considered similar uses on arm, and I am involved in a risc-v effort that is using alpine. So most of my use cases are not even containers.
The way Docker is set up, they encourage people to build containers of any type that that might be interesting, and are willing to host those containers for free… for public use(even if conceivably very few, maybe only you would have any interest). If you want to publish something privately, then you would have to host your own server…
Again, the attraction isn’t that you would deploy on bare metal, you would be building something that could be deployed on any machine running docker no matter the distro or even MSWindows.
TSU
I am actually mostly interested at the moment in building services on arm (like for raspberry pi for example), or even risc-v, that can be deployed and used at the edge / for IoT. OpenSUSE actually has a very good range of board support, in some ways is even more universal than Debian, and OBS can build opensuse arm packages easily and freely, though most people do not seem to make use of that, given that most people in the community do not seem to build beyond x86 and amd64 on OBS. But this kind of use was also why I had initially looked at the JeOS arm images. For containers, I did find what you had suggested about openSUSE MicroOS really fascinating, though, as I do also see eventually deploying services in the cloud that would then talk to edge endpoints.
Note that images for mobile devices aren’t directly related to JeOS, but at least in RaspPi,
It’s commonly known that Debian created a completely unique approach to build Raspbian… and it’s practically night and day how much better designed and easier to enhance and maintain than Uboot which all other distros use(eg try adding special hardware drivers on boot, on Raspbian you only need to add a 4-6 line config stanza, last I checked Uboot required massive convoluted configurations, commands and files)… Too bad the Raspbian approach supposedly uses some proprietary code which makes it off-limits for distros like openSUSE.
But otherwise,
I’m not sure that JeOS should necessarily be that different across its many possible implementations, there probably would have to be some platform considerations like the likely fact that no ARM device code is likely found in an upstream main kernel, but otherwise I’d assume that once a release has been refactored, the same methods can be applied to all other releases.
AFAIK MicroOS may be a kind of JeOS in its design but is not officially labeled as such. In fact, I’ve speculated that MicroOS may have been created from the ground up rather than a typical JeOS approach which is likely based on removing everything non-essential from a working release.
Note also that AFAIK MicroOS is distributed only for use in Kubic (SUSE CAASP which is own flavor of Kubernetes). If you build a “normal” Docker container, you’ll likely be using a different JeOS.
Note that much of this post is based on personal observation and speculation and not hard facts…
TSU
Yes, but they actually boot thru the gpu, and that is what the blob is for.
In my case, I have been exploring where I want to use openSUSE. For development workstations that’s a rather easy and clear choice to make. This is especially true now that I had figured out it is not all that hard to make my produceit package work on openSUSE. For more conventional enterprise servers and infrastructure needs, including telephony servers, it is clearly a good choice too. But for containers, for edge devices, it has the potential, but those do not feel as clear or compelling to me. It would be nice to unify around a single distro that really does it all, but I had already started using Alpine for those other more specialized roles.
Tsu, I did think about this a lot, actually. Of course I had looked at microOS, though it seems to only be a factory/tumbleweed thing at the moment. There is also opensuse busybox, too, which might be much better/smaller than JeOS, but again it is currently a tumbleweed experiment. So while I have thought of using docker much like you suggest, this actually also pushed me back to looking at Alpine and debmini for a small, and more important to me, longer term stable docker base images/build environments. If these get into a future leap type of support cycle, I will look at that again. But I am really happy with my leap desktop systems, and with the idea of using leap for other traditional enterprise server roles.
Since this thread started (and perhaps before), Tumbleweed releases JeOS images primarily as pre-built for various virtualization technologies… Which is interesting but I’ve never found a Use case. I’ve personally preferred to use regular x64 install media wherever it will work, and use pre-built images wherever using an install source would be impossible or extremely inconvenient (like mobile and embedded systems). I’m guessing someone found the need to create some JeOS for the cloud (OpenStack?) and decided as long as the work was done then might as well make them available to others, but to me it’s a rather narrow Use case.
The point I guess is that any person can create their own JeOS by removing whatever they want, likely starting with all documentation, unnecessary libraries and tools (used to be many tools were deployed as User Mode installed by packages but today basic system and networking tools are often integrated upstream in the kernel). You can even remove YaST (with its entire Ruby susbsystem dependency) if you wish. There’s a lot you can do on your own to create your “Golden Image” simply by using the libzypp Package Managers.
Only when or if you should want to trim more, then you’d have to look at a modified kernel and only then I’d maybe consider looking at another distro willing to support the time before kernel mode utilities integration.
When you make JeOS a requirement,
You’ll have to consider your reasons for doing so and only then identify exactly what you want or need.
Many people find that the “Server” install option which installs without a DE is minimal enough, although not nearly as slimmed down as a proper JeOS.
For all typical server or client use, I’ve so far found various openSUSE releases sufficient.
Maybe if I ran into an issue that can’t be satisfied like an embedded device with fixed and unexpandable storage, only then I’d look at alternatives and maybe consider something like Busybox (which strips common utilities to the minimum, then distributes as a single blob instead as individual files. Functionality emulating a Linux file structure is provided by symlinks. This is a common solution for inexpensive appliances) But for anything but other than such extreme scenarios, I’ve been able to use openSUSE, custom modified or not.
TSU
Well, I ended up in a long convo with Chris Brown, who feels the Tumbleweed busybox opensuse image could become as tiny as an alpine one for docker images, but also seriously believes everyone should/must only run Tumbleweed for all production uses, and made his clear intent to never offer/work on enabling kubic/microOS support in Leap/outside of Tumbleweed. This also was part of why I went back to Alpine and Debian for devices and container root images. On the other hand, it also did lead me to explore using Tumbleweed more seriously. So I had setup a Tumbleweed dev system over the weekend which I also have been rather happy with so far. Certainly I would be happy to hear his argument, but I do remain skeptical about that direction.
Given the statements you’re referring to, wasn’t this Richard Brown?
My typo, yes, you are absolutely correct.
If Richard Brown really opined as you described, I’d be curious to hear his reasons (maybe an article somewhere?).
This would be the first time I’d heard anyone much less someone as prestigious as Richard Brown recommending TW over LEAP for Production deployment. Maybe when Transactional functions were available only in TW there was reason but now that it’s an option in LEAP as well I don’t recognize where TW has an advantage over LEAP for Production use. Maybe Richard is not interested in doing the extra work himself but has no objection should someone else port his work to LEAP? I can understand that.
As for making TW as tiny as Busybox,
I’m sure there’s nothing that prevents that from being done should someone want to do that but then everything that differentiates a distro (including openSUSE) would have to be removed. I think many if not most would think that’s going too far.
TSU
You can start with this…
https://twitter.com/sysrich/status/1221777367716200448
And he says elsewhere in this thread he is going to write a blog post on his reasons.
As for a tiny busybox opensuse, this is about container images only. And there is already such tumbleweed images in the opensuse oci registry, as I learned from RB.
I await Richard’s comments!
Current reasons for preferring TW over LEAP or vice versa is currently based only on general perception and various experiences and not based on anything that is fundamental to either release, so I expect that whatever is posted will likely cover various changes to improve the accelerated QA timeline.
BTW - IMO there is no technical reason why any distro including openSUSE couldn’t be made as tiny as Busybox, I don’t know that it’s practical and it would likely require ripping out updating/upgrading capability so I doubt it would be done. For a quick summary of what makes Busybox different than “normal” Linux distros, the following presentation slide is from my “2016 - The Year of IoT and Taking Down the Internet” and its role in those events… which illustrates in a way your crucial role as the Developer in choosing the platform for you apps wisely
https://slides.com/tonysu/2016-the-year-of-iot-and-taking-down-the-internet#/3
TSU
If your building a docker or container image you do not need to carry the updating inside it, because after all, it will be atomically replaced/updated as an image. And if you have a lot of containers that is a lot of idle/never executed in production code to carry.
If I understand what you are saying,
When you create a Docker container, you do that by configuring a Dockerfile which contains all your customization, which typically includes not only the application installation and configuring but also adding any repos, system updating and more… beyond what is likely in the base image. A good developer never assumes a base image will contain current updates and be fully “best” and ensure all steps are included to ensure it’s “best.”
TSU
There are actually several different aspects. Most docker (or podman oci) containers are built for single function servers, and they do not share runtime between containers. So for example, I might create a docker container for mosquito mqtt, a seperate docker container for apache, a separate container for postgres, etc. mosquito might be a few megabytes in size, and docker then runs that executable inside the container directly; why do I need to place it in a 200meg+ base image just to run that? And another 200meg+ just to run apache? etc…