Anaconda....

[kevmif]

I like that they have revamped it... but it falls short in my opinion. It is not at all intuitive and correct me if I am wrong but you don't get the same fine grained control over software selection you used to get!

Also partitioning is difficult to use.

Overall revamping it is a definite step in the right direction and I am sure further work is planned. I hope the developers can get to a point where it is both easy to use and has all the necessary features available.

[boydrice]

The new Anaconda is alright, but I am not sure it is as user friendly as they had hoped. I think the indications that you need to do something would look like an error message to average users. The reclaim space part seems confusing with having no real indicator where to select to delete a partition. I also find that having no option to set the host name irritatiing.

[Demz3]

i wouldnt mind betting they will adjust the New Anaconda to be user frienly as time goes by, but i have not installed it yet so i cant comment much more than this

[kevmif]

i wouldnt mind betting they will adjust the New Anaconda to be user frienly as time goes by, but i have not installed it yet so i cant comment much more than this

I did a netinstall of the beta inside a VM primarily to see what Anaconda was like. Once it is released I'll do what I usually do - give it a few weeks for the dust to settle then make it my primary OS.

Recommend giving it a go in beta form if you have the resources to do so.

[Demz3]

I did a netinstall of the beta inside a VM primarily to see what Anaconda was like. Once it is released I'll do what I usually do - give it a few weeks for the dust to settle then make it my primary OS.

Recommend giving it a go in beta form if you have the resources to do so.

think i'll wait for the final, though if i dont install F18 i will install F19, an idea im toying with atm

[bob]

Guys, it's over a month until the scheduled 'final', so there's plenty of time for improvement and plenty of time to submit issues to bugzilla, btw. And, as with any major change, there's bound to be lots of members with lots of questions and problems, so if you've got it working and have done something a bit different in the process, please keep detailed notes to help the next guy in the same situation.

[kevmif]

Bob one thing to bear in mind is that what we see in Anaconda is probably how it will be released as the 'feature complete' deadline has passed. Correct me if I am wrong but this means no more enhancements / changes to UI - only bug fixing.

So whilst the current version is more or less functional and definitely a step in the right direction, I think we'll have to wait til F19 until we see any nice enhancements. With a bit of work, Fedora will have an industry leading installer and I agree that there was a need to revamp the old one. Be interesting to see what F19 brings!

[bob]

Yes, you're correct, however it's the bug fixes that may make the difference. AdamW's been all over the Forum working on the issues and I'm hopeful that when Final gets here, it's near-perfect.

[AdamW]

kevmif: you're kinda wrong: the definition of 'bugfix' is fairly flexible, and it can include UI changes. post-beta anaconda UI is not the same as beta. This isn't terribly obvious from the documentation, sure, I know. We're usually stricter on post-Beta changes, but for newUI, it's more relaxed.

one thing boydrice mentioned specifically has already changed post-beta - the reclaim space dialog's options are much clearer now.

you cannot control installation package-by-package any more, no, that's correct. We are working on making partitioning more discoverable.

[jonathan47]

I had no luck with Anaconda when trying to install the beta using netinstall. Anaconda froze on me 3 times before I started partitioning. I understand it's getting a major overhaul for F18. I can wait for the final.

[AdamW]

jonathan: well, 'major overhaul' is kind of vague. I'm not aware off the top of my head that we're working on any 'freeze' bugs besides a couple. Could you be more specific about exactly what happened?

[kevmif]

kevmif: you're kinda wrong: the definition of 'bugfix' is fairly flexible, and it can include UI changes. post-beta anaconda UI is not the same as beta. This isn't terribly obvious from the documentation, sure, I know. We're usually stricter on post-Beta changes, but for newUI, it's more relaxed.

one thing boydrice mentioned specifically has already changed post-beta - the reclaim space dialog's options are much clearer now.

you cannot control installation package-by-package any more, no, that's correct. We are working on making partitioning more discoverable.

Thanks for the info Adam. Why don't we have fine grained control over packages anymore? I hope this is simply a case of 'not there yet' as opposed to 'by design'. I understand that dependency resolution is a bit of a pain, but I think having that level of control over what packages are installed is important.

[AdamW]

more or less by design: the thought is that it's kind of pointless to be maintaining two separate codebases for graphical package install (one of which is much worse than the other). One of the main goals of the anaconda revamp is to reduce the maintenance burden on the anaconda team, as it is currently far too high.

You can control the package set in as much detail as you like with yum or PackageKit. If you really, really need it to happen during installation - and you can't do it by installing minimal and building out what you need from there - you can use a kickstart.

I think a lot of people use the fine-grained install controls out of habit more than because they have any real *need* to. What's the practical requirement you have for the function, that isn't ultimately served just as well by tweaking the package set post-install?

[kevmif]

more or less by design: the thought is that it's kind of pointless to be maintaining two separate codebases for graphical package install (one of which is much worse than the other). One of the main goals of the anaconda revamp is to reduce the maintenance burden on the anaconda team, as it is currently far too high.

You can control the package set in as much detail as you like with yum or PackageKit. If you really, really need it to happen during installation - and you can't do it by installing minimal and building out what you need from there - you can use a kickstart.

I think a lot of people use the fine-grained install controls out of habit more than because they have any real *need* to. What's the practical requirement you have for the function, that isn't ultimately served just as well by tweaking the package set post-install?

Bandwidth for net installs is one. Install time is another and simply because many users like that feature and like to have choice! Very disappointed that this was by design. I hope they can find a way to integrate this feature in to both code bases with minimal effort.

[Palooka]

What's the big deal? Once it's installed you can add and remove packages to your heart's content.

[DBelton]

Well, why waste bandwidth to install a package that you are just going to turn around and remove?

For example, anaconda installs PackageKit and the first thing I do is turn around and remove it. Same thing with sendmail. On my latest F18 install, I removed over 50 packages right after the install finished because I did not want them installed.

If I had the option to not install them, then they wouldn't need to even be downloaded during the install.

Not everyone has unlimited bandwidth or a fast connection.

[AdamW]

kevmif: choice is lovely, but it's not free: every choice a software maintainer offers you comes with an attached maintenance cost.

The way I like to think about this is that it's essentially the job of *anyone* writing an application to make choices for you. The most choice-y interface is an assembler code editor: you can do anything with one of those. Anything beyond that - low-level programming languages, high-level programming languages, command-line tools, GUI apps - is in a sense someone else's attempt to extract a certain specific (and by definition limited) set of functionality out of that essentially infinite potentiality for your convenience.

This may be a highfalutin' way of putting it, but I find it rather illuminating as it relates to the issues of 'choice' and GUI complexity. It is inherent in the nature of anything but an editor into which you enter assembler code that your options are restricted in some way. Beyond that, all we're really having is a debate about _precisely_ how much to restrict them, and there are all sorts of parameters that input into that. Including how much work it is for the maintainer. The more of the infinite possibility space they attempt to open up to you in some sort of accessible way, the greater the effort for them.

In the bandwidth-for-net-installs case, as I mentioned briefly, an option is to install with a reasonably minimal package set - core, or standard, or standard-x - and then add on the extra stuff that you want post-install.

[smr54]

As I always do minimal, I'm not that concerned about choosing packages. I am more concerned about not being able to select partitions, and as I explained on the testing list today, my attitude about things that don't affect me can be summed up with this clip. (The two people in it are being given a head start before the bad guys hunt them.)


http://www.scottro.net/selfish.mp4

(That's my home computer and slow, so even though it's only 520k if it doesn't show up, just download it, assuming you trust me as a source.)

[nonamedotc]

What's the big deal? Once it's installed you can add and remove packages to your heart's content.

I think it's a personal preference.

Some people prefer to have a cleanly installed system in one go instead of minimal+yum while others might just want to use yum as you mentioned. There is nothing wrong with either approach - that, in my opinion, is the big deal.

---------- Post added at 10:08 PM ---------- Previous post was at 10:04 PM ----------



The way I like to think about this is that it's essentially the job of *anyone* writing an application to make choices for you. The most choice-y interface is an assembler code editor: you can do anything with one of those. Anything beyond that - low-level programming languages, high-level programming languages, command-line tools, GUI apps - is in a sense someone else's attempt to extract a certain specific (and by definition limited) set of functionality out of that essentially infinite potentiality for your convenience.


Ah! That's a nice way to think about software! Never thought about it in this aspect! :)

[Demz3]

personally i think it'll get more people used to using the groupinstall command which i wont mind doing but, lets say you choose to install Gnome only , once installed an tries to get to GDM, you then get that error which says " Oh No... Something has gone wrong"

[kevmif]

Adam, I don't disagree with the basis of your logic / argument but I do believe it is misapplied in this case. However I am happy to be proven wrong if any study / analysis was done beforehand to see what impact this would have to end users, or did the developers simply decide it was too much work and can it?

It could be that 99.9% of users don't make any modifications - if that is the case and the 0.1% have to work around it then so be it. No point investing a lot of work for 0.1% of the userbase. I doubt the percentage of users installing default package is that small though.

Manually removing packages will take longer to perform then simply not installing them in the first place. Going minimal then building up is also a lot of additional work. I understand the need to keep a consistent experience between text and graphical install but I think the effort required to maintain both and provide this functionality is worthwhile.

I hope this functionality is considered important enough to be implemented in future versions.

Thanks for the feedback you have provided on the topic.

[bob]

Oh yeah, gotta jump in with my two cents and, as usual, a totally impractical suggestion:

How about a 'minimal' or 'server' spin? If you check the stats here: http://spins.fedoraproject.org/ , it seems that anything below #3 has a very limited audience. Surely a bare-bones install could appeal to the guys with dial-up, limited bandwidth or who *shock* actually choose to run servers on Fedora.

Maybe one of the guys who have spent their time developing the bottom 3-4 spins might be tapped for it?

Yup, totally asinine suggestion. Old guy signing off of thread.

[jpollard]

Adam, I don't disagree with the basis of your logic / argument but I do believe it is misapplied in this case. However I am happy to be proven wrong if any study / analysis was done beforehand to see what impact this would have to end users, or did the developers simply decide it was too much work and can it?

It could be that 99.9% of users don't make any modifications - if that is the case and the 0.1% have to work around it then so be it. No point investing a lot of work for 0.1% of the userbase. I doubt the percentage of users installing default package is that small though.

Manually removing packages will take longer to perform then simply not installing them in the first place. Going minimal then building up is also a lot of additional work. I understand the need to keep a consistent experience between text and graphical install but I think the effort required to maintain both and provide this functionality is worthwhile.

I hope this functionality is considered important enough to be implemented in future versions.

Thanks for the feedback you have provided on the topic.

Not to mention that removing some packages cause the removal of nearly everything, and not installing that package causes no issues.

So installing a set, then removing one unwanted package could destroy your system.

[kevmif]

Not to mention that removing some packages cause the removal of nearly everything, and not installing that package causes no issues.

So installing a set, then removing one unwanted package could destroy your system.


Only if you don't pay proper attention to the dependencies... But yes, I would rather worry about what dependencies are required at install time, not when I am trying to remove crap I didn't want in the first place.

[jpollard]

The last time I saw this was with GDM. I don't know if it is still true.

GDM depends on Gnome+libraries. Gnome+libraries don't depend on GDM.

But once you install GDM, you can't remove it or it will try to remove everything gnome...

Dependencies are not reflexive. Yet that is how the system treats them.

[nonamedotc]

The last time I saw this was with GDM. I don't know if it is still true.

GDM depends on Gnome+libraries. Gnome+libraries don't depend on GDM.

But once you install GDM, you can't remove it or it will try to remove everything gnome...



In this specific case, it is not a problem anymore. I installed cinnamon desktop and removed GDM and installed lightdm recently (about 5 days ago). The only other package that yum wanted to remove with gdm was gdm-pulseaudio-hooks (I think this is the name).

But yes, there might be others that want to remove the entire system along with them ...