Starting Point Thread
It may be worth starting a thread (and issue) about how we can improve starting point. I think I like the concept, but it might be nice to have a clear picture of what users are struggling with and what we will and won't do as far as supporting them.
52 Replies
Goals of Starting Point
What is working?
What is not working?
Scope of Starting Point
I agree.
Currently, the one who made startingpoint & is the most active in it is @xyny.
I started to actively contribute to it a month ago, with making some useful modules & enhancing the existing ones.
I Enhanced
default-flatpaks module with some 1 minor issue to completely fix it.
I am in progress on making akmods & custom-kernel module).
This one is the most needed to enhance the ease of use, as current state of modules cannot compare to pure Containerfile modification.
While some Ublue maintainers, especially @EyeCantCU, contribute to startingpoint ocassionally, I think that it can be better if other members contribute to it. Even if they use/prefer Containerfile in their image.
Advantage of this is standardized use of modules, compared to Containerfiles, along with easier contribution from end-users, thanks to simple yml scripting.
Of course, I don't force anyone to contribute. I'm just explaining the advantages if they do.
Easy setup of startingpoint for regular users means
more users = more contributionsI think the thing that is misunderstood is the need to check frequently with upstream on Starting Point.
I've predominately switched to bluefin simply because I saw my build slowly get closer to it and thought small changes after the fact would be better.
I see a lot of dead starting points in the fork. And while it's really easy to get up and running, I think most users don't get that there will be a maintenance burden.
Also, I think the starting point recipe needs to disappear a bit. Or explicitly have it be an example that is not named the same thing. After taking my repo a different direction, syncing back changes from upstream was tedious and even after rejecting some of those commits they keep wanting to merge back in those changes.
I think the module idea is great. I think using the from-files pattern makes a ton of sense. But there is definitely some differences on hardware-setup and image-info.
The big issue with starting point is it handles everything via abstractions that aren't necessarily easier to understand when presented with documentation
This paradigm actually breaks things like building your images locally with Podman which I'd argue is a huge loss as a lot of the debugging often has to happen over GitHub
The modules concept is already supported via Containerfile as a COPY. Better documentation on how COPY needs to be used to bring these components in might be better than the modules concept because people would see firsthand what's going on.
Documentation on the use of container technologies in starting point would be preferred, at least to me, to pointing people towards a yaml file for configuration in my eyes as I'm really partisan to something we call "starting point" being a starting point for people that want to learn more about how our other images work. I think it's incorrectly advertised in that way
I commend the work that's gone into trying to make this process easier for other people, but I think we should be teaching them about the underlying technology rather than running from it and I think we can do that with solid documentation
It depends if you look on startingpoint as "just make your own image if you don't like main, bluefin or bazzite" or you look at it like "a way to standardize all Ublue images".
I agree that it is easier to just use an image if your modifications are closer to it, as it gets rid of maintainance burden.
That is true & I agree. It will be good to document that "if you are using startingpoint, you should know that you are a maintainer now, so it is your worry on how end-user experience will be".
But, I would say that making & maintaining startingpoint image is far easier than forking regular ones, so you will have less maintainance burden. I would argue that forks on Containerfile-based images would die faster.
It is true that there are more merge conflicts if you are not following the standards of starting-point. Containerfile is better if you want to be creative & to break the rules. However, if you think that something should be handled better, make an issue where we can discuss why "rules had to be broken".
This one I don't understand. What is hardware-setup & image-info in this context? I know hardware-setup service which exists on Bluefin & Bazzite. Am I thinking in wrong direction?
That's right. They seem to rely a bit on knowing which image was used. Startingpoint nukes those files. They don't track if you are on an nvidia image or not so kargs get screwed up. Just small knicks
I agree that there should be a hybrid setup to satisfy all users.
This one is also true. Hence, why hybrid setup is needed.
That is true, but I find yml scripting easier than COPY imo. Documentation for Container-based custom images would be great.
Current advertisement is "startingpoint if you don't like bluefin or bazzite", but I would like it to be transition to "startingpoint, make custom Fedora images". So I'm thinking that main, Bazzite, Bluefin & all others would be based on startingpoint in the future. That transition would be slow though.
I believe that hybrid-setup would be the future. I believed in "mostly yml approach only", but your arguments made me rethink & agree to most of your points.
I believe this can be easily solved
i am also not a fan of starting point, in my opinion its an abstraction that makes things harder not easier but then again im also not a fan of forking a repo to make your own image either
I do think things can be shared. I'm not against the idea. I think the "how" comes more into play here though as though Bazzite and Bluefin may share bits, they differ quite a lot. Using modules/a bunch of copies will result in larger Bazzite images (that are already huge) so I don't think that's quite the answer
I really appreciate that this conversation has remained constructive
whether we should make tooling to write and edit containerfiles easier is another question entirely, think a good UI tool to create and maintain a containerfile
I don't think we should be concerned with either
for right now agreed
I have a question about this:
It depends if you look on startingpoint as "just make your own image if you don't like main, bluefin or bazzite" or you look at it like "a way to standardize all Ublue images".How do you look at it? Months ago, before startingpoint first had an official repo, my understanding was that startingpoint would be exactly a simple foundation for extending main/nvidia images... essentially, a Containerfile with some README. Perhaps I misunderstood, but It has clearly evolved into much more, and I don't believe all of the abstracted scripts are what original core maintainers expected. There's clearly been a lot of loving effort poured into startingpoint, but the bigger questions are: "what's the purpose?" "how does it fit in our overall project scope?"
Current startingpoint doesn't pull a lot, but it absolutely could in the future. Storage is unfortunately a valid point.
Maybe some of these things are things we could package 🤷♂️
I feel exactly the same. I know a lot of hard work went into this project and I appreciate that but I feel like it deviates far from scope
It is that still. Not a lot of it fundamentally changed since its rewrite. It just added couple of more modules + GitHub actions like current Universal Blue builds (except just syntax checker). And that's it.
But, I am actually thinking into it evolving much more. I don't mind if something changes scope without affecting current users.
Currently, it doesn't fit the project scope, as it needs to be worked to achieve that (see hybrid approach between abstractive yml & Containerfile).
Purpose:
- Standardization (less fragmentation of useful modules/tools, upstream would be more upstream, not fragmented into 2 projects like bluefin & bazzite which are not 100% synced between each other. Every user would have those modules available, if they wanted to make an image, without need to edit Bazzite/Bluefin components to fit their image)
- Abstraction (ease-of-use)
- Still having freedom (Containerfile would remain in its original form)
It is clear that current Containerfile users would have no benefits as they would not care for those benefits (they don't affect them) + the storage argument mentioned when images are big
so it's a hit & miss to satisfy anyone
Here's another question: does startingpoint get used because of its own merit or because users see it as "the official way" due to how it's presented on the website and in Discord?
honestly i dont think internally (aka bazzite and bluefin) should use starting point at all
Examples:
- Bluefin, Jorge's project, already existed in a different implementation but with the same goals before we built this project/implementation
- Bazzite also was being worked on...
- ucore started as a repo that Kyle created and added to
All these were projects that had at least some momentum and came together with a common or related core.
I look at them as downstream independent projects so I agree. If things need to be more interconnected, I think the best way to handle that is to package things that are shared
I see startingpoint as a good (for those interested) project, but I'm concerned that it's seen as official. Thus maintainers of other of ublue-os repos feel pressured to fix things on it, and support it, but really, it more and more seems like an externally related project.
bluefin is the reason ublue exists afterall
I can speak to personal experience with this one. When I first heard about this project, I ended up using starting point as that's what was recommended for use in the "Make your own" guide with forking main/other approaches looking like an afterthought
I think they see it as something official. Should it be like that? I'm not sure. I don't mind if it has the unofficial status at this moment.
That would be a great start
I think that this is true if the issue is startingpoint related only (working on other images). But if it's something that affects everything, than I think it's beneficial to have more reports on it (or maybe even pull requests)
yes, there are good examples of that now.
Yafti: in bazzite/bluefin but not main
updater: in bazzite/bluefin but not main
config (justfiles/secureboot stuff): in main, thus also bazzite/bluefin
Thanks for opening this discussion and being constructive!
I need to step away for some meetings; I intend to come back and follow up on further comments. 👋
This is exactly how I started as well.
I enjoy this conversation. I like how all of you leave personal feelings/agendas aside & focus on a goal
It went great! We covered a lot of ground 🙂
I started with silverblue-main, because it contains good stuff compared to vanilla Fedora. I think it's something that most users see as official compared to startingpoint
Average end-users are the ones who are the most interested in this project after all
i started from my own image then went with bluefin and just created a Containerfile with from ghcr.io/ublue-os/bluefin line and here we are still running that
I forgot Bazzite, which is most popular Universal Blue project I think
you can look at the image pulls to see which ones are popular and which ones are not
silverblue nvidia and in general silverblue is most popular
just getting to this thread now, what is the ask?
Initial jumping off point was folks having issues with Starting Point. And I figured it would be good to get a good discussion about the state of it in general.
I haven't had a chance to read through everything yet, but I'll make a summary and hopefully be able to ask some follow up quetsions.
Mainly gathering it in this context:
Goals of Starting Point
What is working?
What is not working?
Scope of Starting Point
Clarification on “Scope of Starting Point”
I think the question was if starting point is in scope for ublue at all. I thought we said “no not really” above.
For sure. Sorry, I have to touch grass for a bit before reading through this 😛
OK, here are my thoughts on this to answer my original ask on this thread.
Goals of Starting Point
Historically, this project was seen as an extension of the main images and more of a jumping off point for those interested in starting their own downstream images. It is meant to simplify starting to a create-your-own "Bazzite" or "Bluefin"
Scope of Starting Point
Scope has increased from what was originally proposed due to additional features and divergence from well established standards.
What is working?
- There have been new tools and extensions introduced in the rewrite that have made it easier to work with the project
- This draws new people to the project due to the novelty (or desire) of "creating your own distribution"
What is not working?
- There are concerns it is incorrectly advertised since it diverges from standards that have been defined by Bazzite and Bluefin, making it more difficult for new contributors to contribute on main, bluefin, and bazzite.
- There is a lack of documentation regarding the new features that have been implemented
- Increased support burden on maintainers in Universal Blue due to not actively working on the project as much
- Lots of dead forks of the project due to frustration or lack of available time
- Users may potentially get pushed away by not having their questions or concerns answered due to the divergence
Proposed Ideas
- We may want to consider making Starting Point an unofficial project due to the increased scope and differing goals of the project
- If above is done, we will want to fix up the language we use for starting point on the Official Universal Blue Website
- Should we consider creating a more simple starting point project and have it follow our well established practices?
- I do think there are benefits to this, but we will need to be more clear on what level of support we will provide. I think it should be treated more as a framework for folks to use to learn how our projects work at a deeper level.
I agree up to "what is working".
"What is not working" answer:
1. Downstream projects like Bazzite & Bluefin being the only standard is exactly my concern & why my idea is to make startingpoint an upstream standard for everyone (in the future, it's not ready now). If all of this is standardized, everyone would benefit, including Bazzite & Bluefin. Providing more packages in another repo (like ublue-update) is a good start though.
2. This is not true, at least for modules. They are regularly documented in Ublue-OS website whenever new module comes in. If you think about rewrite, there is a blog post which mentioned this stuff.
3. This would not be the case if startingpoint would be the prefered standard (but not in this state). So this concern is valid. In transition period, more burden is expected if you want smooth sailing.
4. As I said earlier in 1 post before, forks also die when using the forked Containerfile method (in a worse manner). Some may ditch startingpoint because of frustration (they added too much stuff), some may ditch it because of laziness, not because they specifically, do not like startingpoint. It is documented in "Tinker on your own" that you should be aware of how many & what changes you are putting in the image to prevent this case.
5. Less userbase for startingpoint means less potential for answered questions. That is a valid concern. However, in my experience, when looking in Discord & github, I see that people are active in answering questions, including myself here on Discord.
Proposed ideas:
1. I agree. When we get hybrid structure of Containerfile & yml abstraction working perfectly, we may consider applying for official project again.
2. My answer in 1. point contradicts this one, as it is trying to provide something more advanced, but still easy, in the future.
However, this gave me an idea. We could maybe have presets: easy, classic & advanced (Containerfile). Something like that. It would be easily selectable in GUI & modifiable in config. Xyny's GUI web is something that comes in my mind.
This would avoid yet another fork like "startingpoint-easy", which fragments things even more
I appreciate your thorough response and constructive feedback! I'm still very new to the project, so I don't have all of the historical context that most members do.
I think this warrants a next step of having an open discussion when all members (and interested parties) are available to voice their opinion. I'm not exactly sure what that looks like just yet.
Yeah.
All opinions matter.
However, we shall not miss xyny's opinion on all of this as he is the one who made the startingpoint concept into a reality.
I 100% agree with this. We still have not seen @xyny's opinion on the matter.
Sorry but i just cant agree with the idea that we would be better off using starting point for stuff like bazzite and bluefin. Lets consider history we wenr fron a bespoke standard aka treefiles to a more widely accepted atandard of OCIs and dockers container/dockerfile and starting point essentially creates another treefiles situation(a bespome standard) except now you have a concept of containerfile to define a process, burden of maintenance will always be high but at the same time but at the same time not everything has to match between bazzite and bluefin
In regards to forking i have already made my position clear that i dont think that should be our main position for custom work, it should be making a image based on one of our images.
Now when it comes to uis my opinion is simple if we are going to have an UI of some sort it should create a containerfile/repo based on your selections essentially compile it for you and even give you ability to search certien repos and/or copr basically it needs to either be a good tool or UX of it wont be there
Documentation for Containerfile-based custom images would be great.Exist, but hasn't been merged. https://github.com/ublue-os/website/pull/688
GitHub
feat: syncing page and minimal setup page for tinkerer's guide by x...
Tackles #331 while adding some syncing instructions. The minimal setup stuff has been tested here: https://github.com/xynydev/test-minimal-oci
I'm back in school for the spring, so the attention I am able to provide to ublue has really decreased.
Though I only found out about this thread, because I reflixively open discord, I would've probably preferred this as a forum thread.
I don't have any more time right now, but I will give out my opinions later.
I can open a discourse thread for a larger discussion if that would be preferred.
or github
dev -> github
When this Discord thread gets indexed, link that too
would we prefer github? I can open an issue on Starting Point
sure
I just want to try and keep discussion in one place if possible.
GitHub
Discuss Starting Point · Issue #223 · ublue-os/startingpoint
I opened this thread at the request of @xynydev Here is what has already been discussed on Discord: https://www.answeroverflow.com/m/1195027063040643154 I want this to be an open (and constructive)...
aight, will write tmrw
done