fyi, /home on a btrfs volume is just a subvolume and it shares the 20GB with subvolume /, all on a single partition. it’s not a separate partition, which forces you to allocate x GB to / and 20-x GB for /home, so actually quite handy for small vm disks.
Personally, I agree with you, the old anaconda is more intuitive and thus superior the get the job done compared to the new anaconda, which is maybe looking better, but hey, do you know how many people asked about partitioning in the new anaconda on ask.fpo? The hidden Storage Editor is a failed design, if people need to ask in a forum to find it.
A great functionality of the old installer was to Automatically create partiton layout and then manually adjust it. As far as I know, this is completely missing in the new installer.
One can //rant here, or one can get into touch with Anaconda devels and try to advocate for new features with them. I am surprised that the former is a “go to” option for long time users.
The discussion of anaconda is not limited to this topic. And I think we leave the realm of this topic, including that of my argument actually.
As you said, you are not involved in Anaconda development, so let’s leave it to them to consolidate and evaluate information, and not turn this topic into a consolidation of links to bug reports and such. My argument was merely that some data from feedback of earlier explanatory testing periods might have been interpreted based on false assumptions, in order to highlight the possibility so that the Anaconda team can consider it in the context, and decide if and/or to what extent it is applicable. I elaborated the background of this argument in the very post #16 above and in the very bug report. Let’s leave it to Anaconda to decide to make use of it or not.
That is neither related to my argument nor to this topic, and I think no one questioned that.
This is discussed somewhere else: again, I think no one questions that more explanatory testing of anaconda would be useful. Actually, the opposite is the case: that’s the very point → maybe it makes sense to ask in the existing channels if people who provided feedback also tested the partitioner and if not, if they are willing to do so. But I leave it to the Anaconda team to decide if that is necessary or not, as I have not all data available to them, so I can only highlight things to ensure they are considered
I did indirectly a lot of testing of anaconda in the recent few weeks, but got the feedback of the partitioner afterwards. When I test again, I will make use of it to see if my feedback applies to it in the same way as to other stuff.
It’s work in progress. The issue is now known (I think already a few days more than this topic), but it takes its time to get it somehow implemented in an effective/efficient manner. Repeating this here or in other channels does not add value.
Reports should go towards anaconda, and if someone is not sure if something is already known, or doesn’t know how a proper bug report for anaconda looks like, there is a Matrix channel to get in touch with them.
At the moment, I also prefer the old Anaconda from a sole UX perspective, and I fear that we create(d) for some users a Windows Vista feeling (so the “users being made testers without telling” feeling [I say feeling, the perception of people, I do NOT say that this is a fact!]), at the worst deterring some of them from using Fedora or so, or creating a denial of service that forces them to migrate (may it be for technical or non-technical reasons).
But just blaming the Anaconda team and their tool does neither help to improve the tool nor does it consider the complexity of the situation.
A discussion what to make of the situation in general (including alternatives if necessary), beyond just improving the web-ui anaconda, also does not belong here but to the very committee and its realm (which more likely is devel atm): again, any alternative needs to be discussed, processed, approved and go along with people doing the work → this is unlikely to start here in this tag. Consolidating disagreement without new data and without implementable alternatives does not help
Please stop accusing others of ranting or related terms: it just provokes and can facilitate escalations. If it is true or not is not relevant. If you think something breaks the rules, flag it.
I separate my rants from constructive feedback for a reason. Don’t like it, don’t read that section. I do believe however that fully explaining the POV and where people are coming from is important for the full picture and understanding of the different use-cases, different perspectives a developer did not consider.
For Virtual Machines? I personally use the default layout 9 times out of 10 as I don’t care about disk performance for my use-cases of testing future Fedora releases.
In regard to the wider topic - I don’t use the WebUI all that much as Fedora Everything & Atomic Desktop ISOs are still using the gtk version so I can’t really comment too much about that part.
I was not the first using that term. I just quoted it from the post I sent my response to. I do not get how much more it could provoke what has been provocative from the start.
I separate my rants from constructive feedback for a reason. Don’t like it, don’t read that section. I do believe however that fully explaining the POV and where people are coming from is important for the full picture and understanding of the different use-cases, different perspectives a developer did not consider.
Sure. Let’s do it. What I have been saying is let’s explore if the tool is capable of those use-cases and if it is, let’s perhaps help people to understand how they can use it in a better way. We can do it in this forum.
And if it is not capable, then let’s take it somewhere where it has a meaning.
Without finishing reading all the comments my next question is:
Why are we tied to a RedHat’s JIra? We are arguably RedHat independents, can we make a Change Proposal to go back to a really working anaconda version until the latest fit our needs?
Yes, but it has to pass FESCo, and someone has to be there to do the work, from implementing the proposal up to maintain whatever alternative is chosen, if it was accepted → I suggest to discuss things like that at the devel channels, may it be Matrix devel or devel mailing list, there had been already discussions about this, I had one with two FESCo members in the Matrix channel a few weeks ago when I was not able to install a web-ui-based Fedora, and because there was some interest in discuss and evaluate the situation, I was suggested to open a mailing list thread to see if something comes back (not necessarily to replace anaconda or so but to evaluate the situation and see if and what can be done), but the one I created subsequently died (it has to be said the information of this thread is obsoleted!). But as I said above …
What would remain is one of the traditional “protest” proposals, which had in other issues in the past facilitated discussions, not necessarily to replace something but to create a constructive development in whatever direction, and also accumulate knowledge, optimize compromises with knowledge of all involved, and to provide support to whoever needs it. Even if it is just to create reciprocal understanding it can help to make people work together rather than against each other… But I’m not sure if there is wider interest about this.
This was done knowing full well that the partitioning capabilities of the new UI were far below not only the GTK UI but all of our competition. There was a thread about it created when FESCo raised as a blocking issue in 2023 and 2024.
The sad fact is that there is not as much being put into the “front door” experience for the Red Hat family of distributions as there used to be. My understanding is that the Anaconda team is a small fraction of the size it was when the last redesign occurred with Fedora Linux 17/18. Incidentally, that redesign introduced the “gold standard” for partitioning features that all other installers have today.
There are some upsides with the new UI: since we are no longer using custom wonky GTK widgets, screen readers can more easily read the UI. Accessibility labels are more coherent. The navigation layout actually makes sense now.
But we lost a lot of power and capability in Anaconda for the time being. I don’t know if we’ll get everything back, but I hope we will someday. There’s some hope: they are gradually reimplementing other “lost” features in the new UI in anticipation for the switch for the netinstall media.
I don’t know all relations you refer to, but the issue might have worsened through the increasingly hostile user/developer relationship, making people not investing time in testing, bug reports, etc., including those otherwise active in the community.
I’m not sure if “investing” more in communications could bring a positive return on investment (though I’m surely no expert in this field). At the moment, the feeling of anaconda is often reduced to users’ perception in a moment they are angry (which is with a ~high likelihood transferred to the team), with no incentive available telling them it’s not just “abuse of users as testers” (so to speak). Again, perception and facts are often two different things, but contributions are shaped by the first
I recall in the discussions about the new anaconda that issues with blivet were one reason for replacing it. It may not be possible to put blivet back…
If it is only about partitioning and dissatisfaction with the web-ui tool, a “worst case” interim solution, that is easy to implement and easy to remove later (I assume?), is to add gparted or so to the live media (I think off the cuff it will not add many dependencies, though not 100% sure), and add just a link in the web-ui to start gparted, with some text in the web-ui or so: “we would be happy if you test this and give us feedback, but for the worst case, click here to open gparted”. It would just be necessary to refresh the partition table of web-ui once gparted is closed. That would also add a positive incentive about the team, making them perceived as people, not a tool. That makes a difference for people and their perception (it’s also a difference if people have a choice) → the perception could be changed from “I am used as tester” to “I decide to test”. An easier way to feedback would be helpful too though, to make volunteers able to feedback → entry barrier to bugzilla is very high, especially if data often cannot be preserved .
However, I am not sure if that can help to setup LVM and disk encryption → I know gparted can create LVM2, but don’t know if it also can setup the vg and lv. A comparable issue to setting up disk encryption, I think it cannot, but not sure. Just some thoughts…
Is the new anaconda in an open repo that people can colaborate on improving with PRs?
Also wonder if we could have an option to shell out to a partitioning tool that came from the Fedora side of the world rather then wait on the RH team to do the work?
That does beg the question of who will write that tool…
