When I’m looking at the web page and the documentation, part of it seems very welcoming. And I’m super interested in the distro.
However, if you need any package that’s not in the standard setup, it looks like things change. We don’t support this / we don’t want to support this. Most of the suggested solutions seem to circle around manually installing things to root, which breaks both the security aspect and the stateless aspect that clearlinux is clearly pushing.
What is the state/plan here? Are you only targeting the users who are able to use this without any extra packages? (flatpak/appimage covers user apps, but not anything requiring services/drivers for example). I see you can also use mixin to install extra packages, but from my understanding, when you do that you also don’t get updates any more. So that throws out the security aspect.
Speaking to the mixin bits. If you are using mix to create your own bundle you don’t lose any system updates, you can keep on keeping on. When it comes to updates for the software you packaged, it is up to you to provide the updates to that yourself.
There are way to push you bundles up into the project itself I believe, at that point though I am unsure who owns the maintenance of the bundle. I have not seen much/any docs yet about user contributed bundles and if this is going to be like the deb/gentoo world where a maintainer must be found first, or if this will be more of the Arch aur world where anyone can be their own maintainer and push stuff around for other to install at will. This is a topic discussion that should have already happened or needs to happen fairly soon. I for one may push some stuff up into the upstream but haven’t really devoted the cycles yet to figure out the distribution process.
Right! That was a very important piece of information that I had missed. When looking at the documentation here I noticed that it will take your OS version into account, and mark it as OS version * 1000. But I see this is for the specific bundle, and not for the OS itself.
I’m going to have to try this in a virtual machine now, thanks a lot!
I’m extremely interested in how things with mixins develop. The ability to maintain my own packages is great, but sharing those efforts is also essential. There’s seemingly still some holes in the documentation, which I’ll try to raise bugs for as and when I see them. I also add notes to my own website so I can quickly find them again (see here).
Migrate your Clear Linux OS to your custom mix. Check your version before and after the update to see the switch to your custom mix:
This statement confuses me in the mixin documentation. It makes it sound very much like you are now on a “newer” version of clear linux, and therefor wont get system updates for “previously updated” things.
That’s my understanding by looking quickly at how this works at least. It looks like these upgrades are a running number, and if they are adding *1000 will effectively stop updates.
I do like the focused approach the team is taking. Trying to be all things to everyone usually never works. Like, if the team can focus on the core of the OS and QA I am happy with having the desktop apps come from flathub and I’m a container person anyway so all my server apps only need a container runtime to work.
Though, at some point, someone is going to need to use Chrome for something. I would guess any one individual can’t just redistribute a chrome mixin without permission for Google.
It would be nice to have perhaps a crutch tool that lets us install a one off rpm and can use the metadata to snag updates from the upstream repo and then wedge it in a way that doesn’t interfere with the rest of the system. Or perhaps a recipe that lets me take an RPM and then automagically mixins it and serves it back to localhost as a workaround.
Random thoughts:
Building something that polls a repo and updates a rpm package in /opt/pkg isn’t super hard. So something like that should be fairly doable. (With probably some manual steps for some dependencies). That should work for say chrome/ffmpeg (although it’d need some LD_LIBRARY_PATH for the user in the case of ffmpeg).
Something that’s more complex that I’d like is:
snapd
This requires systemd services. So we’d need some way of hooking into making custom ones.
nvidia-drivers
The nvidia installer just really kills the stateless root aspect… Could install a lot of it jailed, but would still need a dkms hook + a lot of LD_LIBRARY_PATH (also for xorg itself probably…). I don’t see any way of doing this without breaking stateless…
One option of course is to intentionally break the stateless concept, but have a whitelist of files (from specific packages) that are known to be broken… That’d be reasonably easy…
This reminds me of Gentoo/Arch and takes a little getting used to. In a nutshell as I see it, ignore the version number as meaningless. Think of it like a git commit, the only time you need it is when bad stuff happens. Lets look at it a little differently, again I think I am on the right track here from the way I have been using it and watching it work.
I think, if I am correct on this, the OS version follows a git branch pattern where your mixin is a feature branch that you merge into master, which could be considered the running version. You just look at the version/commit hash before the merge and after. If this is the case then maybe they should just scrape or at the very least redo the docs to use a better diagram description.
Again, the version thing does not bother me and how they are doing updates from the code I have looked at makes sense. The system knows what is installed and what it is responsible for and it will ensure those bits are updated in the case where you did a mixin and side loaded your package.
A mix can be thought of as a fork. You took a clear linux install at a known point in time, add some stuff to it and continue on from that point, doing a pull from the upstream only when you want. This requires you to mange your own upstream/update path in effect. This could also be thought of something like an internal package repo where a company uses an LTS base distro but then turns off all external repos and says all updates have to come from the internal repos only and basically makes themselves the update path of record. The company may only update certain packages or pull in only what they want based upon their own schedule.
Again, I may in left field here but that is what I gather from the docs/code and what I have seen doing mixin’s in my system.
I think the team needs to have a discussion on allowing developers to upload new bundles ASAP if they haven’t already. They need to figure out a gatekeeper policy to ensure things don’t get broken. I love the AUR and I hate it. There are many reasons Debian is more stable then nearly anything out therefore, part of it is the package maintainer policys and what it takes to become one and get a new package into Debian.
On the flipside to that…what it takes to get a new package into Debian and what it takes to be a maintainer. There should be some sort of happy middle ground where users can submit custom packages easily with enforced guardrails to prevent dumb things from being done.
Just an aside, but the Red Hat / Debian style of stability is pretty context specific. If you’ve got a brand new hardware then an old kernel is not your friend, the moment you start having to hand roll your own stuff that perceived “stability” is at risk. In practise rolling release Linux distributions haven’t been significantly more problematic for me than those “stable” beasts.
There is a tool that will let you crack open an rpm, pull the spec file, and then rebuild it for clearLinux using autospec, and then sideload it as a mixin. It’s a little convoluted but it works good enough for now.
Yes, this is true, but in practise Chromium is perfectly legal to ship and meets most people’s requirements. If you really need Chrome you pretty much have to go to google to get it, and you have to be accepting of everything they bundle in with it. I don’t think we need hold Intel to a higher standard than say, Fedora or Ubuntu in this regard.
I can’t find it anymore, but if you look at the docs for autospec it will allow you to use an existing spec file or it will try to build one for you. One you have that you can create a mix or mixin to finish the work in a clean manner. Not as clear as just installing an rpm and my brain is still out on the additional effort needed but I was able to use spec files I wrote from some golang binaries I built and it was fairly painless.
You’d still need to deal with auto updates, but that’s reasonably easy (cron/anacron as user could take care of that). In order to get snapd to work it looks like you can run the snapd command in docker host. It looks like that communicates on localhost, so binding the right ports and copying the snap go-lang executable outside of the docker host will probably work as well.
Should give a fairly good isolation between system packages and installed ones. It’d probably take a performance hit though. Docker is not great at io, and I’d be curious to see how the snapd directory bind’ing will affect performance. Probably performance is limited to io though, which shouldn’t be the main problem anyway.
Andaag - you are definitely welcome here!
And yes, Clear Linux works well for people that can use the included bundles. If you have specific applications that would be generally useful, please make a request for those to be added on Github or through the mailing list.
We are in the process of re-evaluating our plans for how best to add in 3rd party content, so be assured we are reading your concerns and suggestions.
Lets look at it a little differently, again I think I am on the right track here from the way I have been using it and watching it work.