Duffy: Improving the Fedora boot experience [LWN.net]

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 14:03 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> I'd rather see Fedora to focus on restoring Anaconda into usable state (i.e. supporting more than one DE install, and support for custom disk layout including MD RAID and LVM on top of each other, etc.). There are _way_ bigger problems to solve in Fedora than how many graphics mode changes occur during the system boot.

I installed F18 from scratch in a VM recently and the new Anaconda wasn't really compelling (all my other Fedora machines are either yum upgrade'd or Rawhide). I couldn't convince the partitioning step to set the default layout then let me edit it. Even when I did do it manually, I didn't see any way to order partitions on the disk (/boot should certainly be first), it just listed them. Other than that, buttons weren't in consistent places. Sometimes there was a "Done" where I would expect "Back" and others "Done" was at the bottom (at least I think so).

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 15:16 UTC (Wed) by drag (subscriber, #31333) [Link]

The disk dialog is for F18's installer is certainly a low point.

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 15:30 UTC (Wed) by duffy (subscriber, #31787) [Link]

I'm real confused - what does the parent article have to do with the installer?

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 15:40 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

From Yenya above:

> I'd rather see Fedora to focus on restoring Anaconda into usable state

I was agreeing, with some more details as to what, specifically, I saw that weren't the best.

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 16:35 UTC (Wed) by duffy (subscriber, #31787) [Link]

I think we have plenty of feedback on the installer interface to be muddying the waters on a boot experience discussion with yet more.

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 22:58 UTC (Wed) by drag (subscriber, #31333) [Link]

> I'm real confused - what does the parent article have to do with the installer?

It would certainly be useful to my boot experience to have a installer that actually is able to select and install a bootloader properly.

My motherboard is unfortunately made to be retarded by having a BIOS-only interface on some sort of gimped EFI firmware. Only BIOS functions are exposed. It is part of some sort of multi-level marketing scam or something.. I suppose the manufacturer is trying to differentiate this relatively low-end motherboard with their high-end stuff with fancy graphical firmware UI.

Basically, Fedora tries to install a EFI bootloader to a system that can't actually boot it. You have to use a BIOS bootloader.

Which is no big deal.

I normally have no problem setting up a bootloader.

Unfortunately I am also using large drives so I need to use GPT partition scheme, which then requires me to have small Bios partition at the beginning of the system to be compatible with BIOS systems.

This is a configuration I couldn't figure out how to coax Fedora into using. Fedora can install to a BIOS system just fine and setup the grub-bios partition for GPT drives, but since it was thought that it was a EFI system it did no such thing.

And thus it rendered my system unbootable.

I spent a day trying to figure this out. I tried various approaches, including trying to use parted from the installer's command line to setup partitions... which still wasn't accepted by Fedora's installer.

The solution was to let the baby have it's bottle: Let Fedora setup a EFI boot partition, boot partition, swap partition, then a data partition. Let it install and leave me with a nice brand new install on a completely unbootable PC.

Then boot the cd back up using the installer, copy the data off the boot partition, use blow away the first 2 partitions and then the new bios grub and boot partitions. Chroot insto the drive, restore the /boot contents to their proper locations, uninstall the efi bootloader, install the grub boot loader, install the grub boot loader, and then everything was all happy-joy-joy from then on.

I also took the opportunity to setup the boot and swap partitions on MD raid and extending my BTRFS system to be mirrored on my second drive so that the system could boot from either drive and quite happily survive a disk failure.

So that is what I was thinking when I replied:

"It would improve my boot experience to have a system that after I installed it could actually boot".

Besides the drive partition bit I am actually quite satisfied by the installer. I don't have too much angst over the issue because I know the partition druid (or whatever they are going to call it now) is going to be MUCH MUCH better in the next release. They have to start somewhere and disk partitioning is NOT a easy thing to do.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 3:32 UTC (Thu) by doogie (subscriber, #2445) [Link]

Tbh, if the bios supports loading /boot files from anywhere on disk, you should probably place it on the *slowest* part of the disk. Place often-used files on the faster parts.

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 14:06 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Although you are engaging in the fallacy of thinking that you can take people who have expertise and interest is say GRUB and magically make them work in the installer instead, RAID UI is being redesigned as well

http://blog.linuxgrrl.com/2013/03/11/raid-re-do-for-anaco...

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 18:21 UTC (Wed) by jke (guest, #88998) [Link]

He's also engaging in the fallacy of believing his personal experience is parity with most users. His personal experience doesn't answer the question he asked (the first line) any more than mine does. (I boot at least daily.)

Even if he's right about what most users do, he still has to establish that ignoring the minority is the right thing to do. Linux operating systems have an extensive history of being good for the long tail. We owe much of its success to it.

Also, if booting is not important because of its frequency then it stands to reason that installation (Anaconda) is not important for the same reason, right? How often do people install Fedora anyway? Certainly less often than they boot.

At any rate, unless one thinks that Anaconda's shortcomings were really the result of it being developer starved, there's no reason to wave the "Priorities Now!" flag (even if developers were a generic blanket resource that could allocated willy nilly).

This is *not* (only) about prettyness

Posted Mar 13, 2013 14:20 UTC (Wed) by HelloWorld (guest, #56129) [Link]

There are quite a few points in that article that aren't about making stuff prettier, such as localisation, accessibility and usability issues. Also Fedora doesn't currently adhere to the boot loader spec.

This is *not* (only) about prettyness

Posted Mar 13, 2013 14:58 UTC (Wed) by Yenya (subscriber, #52846) [Link]

Again: how often do Fedora users boot their systems? I think l10n of the boot process is pretty pointless compared to being able to see the GRUB screen and actually solve the problems when they occur. Untranslated messages during the clean boot process can be ignored, but not seeing the _error_ messages (even untranslated) and the GRUB menu at all is much worse.

In my opinion the "Outright bugs" section in the original article contains a single outright bug, which is #9 about the boot loader spec. All the others are minnor usability/polish problems, or even enhancement requetsts (#5 about brltty). And in my opinion it is not wise to trade enhancements (for some users) or even polish for something that is outright regression for other users.

This is *not* (only) about prettyness

Posted Mar 13, 2013 15:10 UTC (Wed) by duffy (subscriber, #31787) [Link]

"Again: how often do Fedora users boot their systems?"

Livemedia users boot their systems everyday. They also use syslinux instead of grub2 as a bootloader, but the same exact arguments apply.

This is *not* (only) about prettyness

Posted Mar 13, 2013 17:49 UTC (Wed) by Yenya (subscriber, #52846) [Link]

Nope.

I have never used Fedora Live CD except for rescue purposes, but as I understand it, it has only one kernel, so going into the boot loader prompt to choose another one or set the boot parameters differently than the previous time is not used very often.

Anyway, how would the live media bootloader determine whether the previous
boot was successful or not?

This is *not* (only) about prettyness

Posted Mar 13, 2013 18:01 UTC (Wed) by duffy (subscriber, #31787) [Link]

"Nope."

Um, yes! There are people who use live media to boot into Fedora on a regular basis. You may not be one, but that doesn't mean that they don't exist.

This is *not* (only) about prettyness

Posted Mar 13, 2013 19:56 UTC (Wed) by Yenya (subscriber, #52846) [Link]

Would you mind to read the rest of the comment you reply to as well?
I did not say that live-cd users do not exist.

This is *not* (only) about prettyness

Posted Mar 17, 2013 0:55 UTC (Sun) by duffy (subscriber, #31787) [Link]

You should have read the comment you were replying to in the first place :) I was referring to regular live-media users, of which there are quite a few.

This is *not* (only) about prettyness

Posted Mar 13, 2013 15:12 UTC (Wed) by duffy (subscriber, #31787) [Link]

"All the others are minnor usability/polish problems, or even enhancement requetsts (#5 about brltty). And in my opinion it is not wise to trade enhancements (for some users) or even polish for something that is outright regression for other users."

In my opinion, refusing to support vision-impaired users who have Braille readers and casting off their concerns as an 'enhancement' is pretty cruel.

This is *not* (only) about prettyness

Posted Mar 13, 2013 17:25 UTC (Wed) by Yenya (subscriber, #52846) [Link]

Well, my previous post did not use the best possible wording. There are two _independent_ claims which I have joined together more than was necessary, and which you have quoted:

1) #5 is an enhancement request

2) it is not wise to trade enhancement and polish requests for regressions for other users

I still think both are true despite your (unnecessary) notes about cruelty. What does matter is how many users (on both sides) are affected, and how severely are they affected.

For the #5 brltty issue, I have no problem with that, because it could probably be done with no affected users on the other side. It should even be possible to install the screenreader stuff (as a GRUB module?) to /boot only for users who need them.

Moreover, for the other problems - whether to see the GRUB menu or not, and whether to do three or two video mode switches during boot, the screenreader users are on "my" side - they would need to get the GRUB menu with sufficient timeout anyway, and the number of mode switches does not matter for them.

What does matter is, that solving the majority of the "Outright bugs" (in fact mostly polish issues) from the list in the original article can lead to inconveniencing users who do not mind one or two mode switches and a few seconds delay in the GRUB menu, but who do mind when they are unable to see what is currently going on in the system, because somebody has decided that it is not "pretty enough", and "might confuse the ordinary users". This is Apple-style approach to UNIX, and I have to say I am not very happy to see Fedora going this way.

This is *not* (only) about prettyness

Posted Mar 13, 2013 18:02 UTC (Wed) by duffy (subscriber, #31787) [Link]

"I am not very happy to see Fedora going this way."

I'm sorry you feel that way.

This is *not* (only) about prettyness

Posted Mar 13, 2013 18:48 UTC (Wed) by tpo (subscriber, #25713) [Link]

>> I am not very happy to see Fedora going this way."
>
> I'm sorry you feel that way.

What's exactly the point of that reply? Is its purpose maybe to "win" the argument?

In case your goal is to find important problems and solutions to them then I'm under the impression that Yenya's contribution here has the potential for some useful insights.

This is *not* (only) about prettyness

Posted Mar 13, 2013 20:01 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

I know this might be difficult for some of us in this community, because we have our "tact filters" installed backwards when we were built at the factor....

If this were a face-to-face conversation, and someone expressed disappointment with another person's decision making, the person receiving the complaint could easily be genuinely sorry that the decision made the other person unhappy and trying to express that. If you could see Mo's facial expression, body language and could hear the tone of her voice you could know whether or not this was meant as a genuine attempt to show either sympathy and/or empathy.

Text as a medium is very difficult when it comes to handling emotive language, or the things you humans call "feelings". It's very difficult to know for sure if the person making an emotive statement is doing so in a genuine fashion or is being patronizing or dismissive. Its just as easy to read both sides of the conversation as trollish regardless of either person's intent.

Unfortunately we tend to project our out state of mind when we read these sort of conversations. If we are angry or upset, we will read responses as if they were intended to be angry or upset. We don't of correlating tone and body language context to help us sort it out.

Be wary, and give everyone the benefit of the doubt with regard to emotional intent.

-jef

This is *not* (only) about prettyness

Posted Mar 14, 2013 8:47 UTC (Thu) by Company (guest, #57006) [Link]

I don't agree with this. It's as hard in the real world as it is with text to figure out if somebody is being sarcastic or honest. Usually what we rely on is a bunch of unwritten rules for communication, and those exist for online communication just as they exist for face-to-face.

The only reason why you (and I) didn't read it as a passive-aggressive trolling comment was because we know the person who wrote the comment. Because it said "duffy" and not "slashdot".

This is *not* (only) about prettyness

Posted Mar 14, 2013 15:22 UTC (Thu) by sebas (subscriber, #51660) [Link]

I disagree, and agree very much with Jef. We'll end up being in a pretty bad place if the default interpretation of something that can easily be interpreted as genuinely nice becomes sarcastic and dismissive.

I don't want to be in this place, it helps nobody.

I do want to be in a place where you can express being personally sorry when disagreeing over a technical issue without being mistaken for a sarcastic disk who just wants to pour some extra salt into the wound.

Being friendly is not a bad thing at all, in fact it's often missing in the discourse in Free software communities, and probably makes quite some people stay away, or leave, because they just don't possess the time and energy to put up with discouragement.

In KDE (and a few other communities I know of), this has even been codified in a code of conduct, read for example http://www.kde.org/code-of-conduct/ or, maybe more relevant here, Fedora's: http://fedoraproject.org/code-of-conduct (although the latter is not very clear on this assume-positive directive).

This is *not* (only) about prettyness

Posted Mar 17, 2013 0:54 UTC (Sun) by duffy (subscriber, #31787) [Link]

"What's exactly the point of that reply? Is its purpose maybe to "win" the argument?"

No, I'm sorry that the project isn't going the direction you would have liked. It's disappointing and frustrating when you follow a project for a while and then it veers away from what you liked about it. That doesn't mean the project is doing anything wrong, just that for you personally it's not working out anymore. I'm sorry.

This is *not* (only) about prettyness

Posted Mar 17, 2013 11:34 UTC (Sun) by tpo (subscriber, #25713) [Link]

>> What's exactly the point of that reply? Is its purpose maybe to
>> "win" the argument?
>
> No, I'm sorry that the project isn't going the direction you would have
> liked. It's disappointing and frustrating when you follow a project for a
> while and then it veers away from what you liked about it. That doesn't
> mean the project is doing anything wrong, just that for you personally
> it's not working out anymore. I'm sorry.

Your reply answers the second question ("Is its purpose maybe to 'win' the argument?"), not however as far as I understand the first one.

I am assuming that designing an OS is foremost /not/ a question of personal likes or playing the psychosocial instruments of the community to advance one's agenda, ego or ideas.

Certainly, us all being human (apart from the dogs collaborating incognito on various projects), tastes and social mechanisms also need to be considered ("I'm sorry"), but they should be secondary and only means to the end of creating a system that is technically and objectively as good as possible [1][2].

That's my assumption of what Gnome and most fundamental and large open source projects are about.

So under the stated assumption, answering "No, I'm sorry that the project isn't going the direction you would have liked" to a person that is trying to point out in detail what's wrong from a technical and usecase standpoint about the direction that some software solution is taking does not make any sense to me.

It's like saying "No, I'm sorry that the project isn't going the direction you would have liked" to a colorblind person that is trying to explain, why choosing a red on green font is not a good choice for his use case.

Is my limited understanding preventing me to comprehend it all?
*t

[1] Also, as shown by many benevolent dictators "taste" can be an effective mechanism of choice in the face of "unresolvable complexity".
[2] That doesn't imply that the primarily goals would unconditionally justify all means or universally trump the secondary goals.

This is *not* (only) about prettyness

Posted Mar 17, 2013 17:33 UTC (Sun) by jwakely (subscriber, #60262) [Link]

> It's like saying "No, I'm sorry that the project isn't going the direction you would have liked" to a colorblind person that is trying to explain, why choosing a red on green font is not a good choice for his use case.

Oh come off it!

Look at the post again: http://lwn.net/Articles/542734/

It was in response to "I am not very happy to see Fedora going this way."

"I'm sorry the project isn't going the way you like" is a perfectly valid response to "The project isn't going the way I like". What other response do you expect? "Oh, OK, we'll change the project's direction to please one commenter on LWN?" Maybe the direction *should* change, but presumably it's been decided by Fedora contributors on Fedora lists for various good and bad reasons, changing it based on one commenter on a non-Fedora site, no matter how well reasoned the points, would be a strange way to run the project.

This is *not* (only) about prettyness

Posted Mar 17, 2013 20:10 UTC (Sun) by HelloWorld (guest, #56129) [Link]

> Maybe the direction *should* change, but presumably it's been decided by Fedora contributors on Fedora lists for various good and bad reasons, changing it based on one commenter on a non-Fedora site, no matter how well reasoned the points, would be a strange way to run the project.
Oh, so nowadays it doesn't matter whether a point makes sense but where and by whom the point was made? I'd call *that* a strange way to run a project.

This is *not* (only) about prettyness

Posted Mar 17, 2013 21:16 UTC (Sun) by jwakely (subscriber, #60262) [Link]

No. I didn't say it doesn't matter. I implied one person's opinion generally matters less than the combined opinions of all the other users and contributors who've participated in the project and the discussions that have already taken place. If that one person changes the rest of the project's opinion by well-reasoned arguments then by all means change the direction, but don't do it just because one person makes some good points somewhere on the web, which most of the contributors haven't read.

This is *not* (only) about prettyness

Posted Mar 18, 2013 10:04 UTC (Mon) by nix (subscriber, #2304) [Link]

"Oh, OK, we'll change the project's direction to please one commenter on LWN?"

But of course!

But only if the commenter is me. Have a sense of proportion here!

This is *not* (only) about prettyness

Posted Mar 18, 2013 17:42 UTC (Mon) by jwakely (subscriber, #60262) [Link]

Yes, obviously, I assumed that went without saying!

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 14:34 UTC (Wed) by duffy (subscriber, #31787) [Link]

"How often do Fedora users boot their systems to even justify the discussion about making the boot process prettier?"

You must have not read the thread or the blog post summary. Um, we're dealing with at least 9 outright bugs, and 3 big-picture issues. There were exactly 2 polish items in the list of issues that came up during the thread, and only one of them was really aesthetic in nature. The entire impetus behind this effort isn't to make the boot up 'prettier' nor do I see anywhere where anybody working on it has said as much.

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 14:37 UTC (Wed) by ryanlerch (subscriber, #87600) [Link]

Most analogies are flawed. However, one could say that the removal of the hood does create aerodynamical issues too. Having the grub screen shown for 5 seconds does take longer and *drags* out. (pun intended also). I'm sure we could go all day with you picking holes in the analogy, and me plugging them up until we have an analogy that is as complex than the issue itself.

Also, this was a thread about the bootloader. Not sure why you bring up the installer. Did i mention that I want icecream?

--ryanlerch

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 14:55 UTC (Wed) by lkundrak (guest, #43452) [Link]

Just to address your question: I do boot it often enough to care about fast and streamlined experience.

Reboot frequency?

Posted Mar 13, 2013 14:56 UTC (Wed) by dowdle (subscriber, #659) [Link]

You run Fedora, right? Then you have noticed how frequently they update the kernel... so I'm usually rebooting at least once a week... sometimes more... sometimes less... so shaving 10 seconds off of it would be nice. I saw somewhere that if you aren't using RAID nor LVM... with Fedora 19... it should be possible to boot in about 2 seconds... depending on the hardware of course... and the BIOS post takes longer than that... but anyway.

Eventually Fedora will be on more mobile devices and having a uber-fast boot will be seen as a must. Of course you and I might not be using it on mobile, but we too can benefit from a faster boot even if it isn't that important to us.

Reboot frequency?

Posted Mar 13, 2013 16:07 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

To be honest, if each reboot is the result of a 'yum update', then I'd rather we try to shave five or ten minutes off the time that it takes yum to initialise itself and *start* looking for things to update, than bother speeding up the boot itself.

Reboot frequency?

Posted Mar 13, 2013 16:31 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

We should get all the bootloader and early userspace developers to start working on the package manager instead?

Reboot frequency?

Posted Mar 13, 2013 16:50 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

Heh. Well that wasn't what I meant, as you well know. But now you come to mention it, it might be quite a good idea. At least they might be able to understand locking, and come up with a way for it to handle Ctrl-C. And have some vague understanding of efficient ways to handle data structures.

Yeah, why not?

Reboot frequency?

Posted Mar 13, 2013 18:11 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

They're already working on a replacement/improvement to yum: DNF. My impression has been mostly positive; it's certainly a lot faster at the dependency resolving part. I'm not sure if it's any better at the initialization and cache refreshing.

Reboot frequency?

Posted Mar 13, 2013 18:31 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

It is definitely better however it is still experimental and there are some serious bugs and you might want to be careful.

https://admin.fedoraproject.org/pkgdb/acls/bugs/dnf

Since it is command line compatible, I have a bash alias and just pretend it is yum. Works well mostly.

Reboot frequency?

Posted Mar 14, 2013 2:07 UTC (Thu) by dowdle (subscriber, #659) [Link]

Dude, while you are running yum you and your system can do lots of other things... so if yum is slower than you want, do can do other things with that time. The boot process... not so much.

Reboot frequency?

Posted Mar 14, 2013 8:53 UTC (Thu) by dwmw2 (subscriber, #2063) [Link]

Perhaps you're cleverer than I am, but I find the problem with that approach is that by the time it is actually doing something useful, I'll forget it's there. So it'll be sitting at a [y/n] prompt in a long-lost terminal when I next run yum from somewhere else, a few days later.

And because of its broken approach to locking, the dormant background one is still holding the lock, rather than dropping it before asking the question and then re-acquiring it when I respond. Meaning that the new one refuses to work, and I end up having to play hunt-the-xterm to find the original invocation of yum.

We've strayed quite a long way from the original topic now, I concede. But to try to drag us back in that direction... if the user interaction folks want to point at something an say "this is a really bad user experience. Here's a design for how you fix it", then they could do worse than looking at yum.

Frequency of booting

Posted Mar 13, 2013 15:02 UTC (Wed) by jreiser (subscriber, #11027) [Link]

How often do Fedora users boot their systems ... An important subset of Fedora users, namely Fedora developers, boot their systems quite often. Instantiating a virtual machine (VM) involves significant chunks of booting: getting from nothing to a "login" dialog or shell prompt. VMs can be used tens of times per day when fixing bugs or developing in the first place, because they help provide a controlled environment.

There are many Fedora users who use one-person machines of various kinds only while awake, and for whom cold booting on a weekly or daily basis is [should be] a reasonable choice.

Frequency of booting

Posted Mar 13, 2013 17:44 UTC (Wed) by Yenya (subscriber, #52846) [Link]

Well, Fedora developers by definition count as power-users. What I do is to set the GRUB delay to zero on testing VMs where it does matter. Anyway, for testing and developing on VMs it is better to not boot the system from scratch, but start from a snapshot of an already-booted system.

Well, as I see it, I am probably one of the last Fedora users, who also use Fedora on servers. For me, it really matters whether I would be able to get into GRUB every time _I_ want, independent on whether the system _thinks_ the last boot finished correctly. Especially on those pesky HP ProLiants DL125, which take three+ minutes to go through various BIOS stages. The advantage of being able to stop the GRUB when I want instead going through another system reboot is bigger than saving 5 seconds out of about 200 in the ordinary system boot.

Frequency of booting

Posted Mar 13, 2013 17:47 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

You have a specific requirement and fall on the other side of this tradeoff which doesn't seem to be shared by the majority of users. You are better off configuring the bootloader along with the rest of the server configuration. Kickstarting it is the most efficient method.

Frequency of booting

Posted Mar 13, 2013 20:22 UTC (Wed) by Yenya (subscriber, #52846) [Link]

In general, you are right. _I_ can definitely cope with this particular issue. But still, this is one small part of a bigger picture of where Fedora is heading to. Focusing on single-user desktops and even tablet interfaces like GNOME 3, and making the server or power-user desktop use-cases increasingly more difficult to deploy.

If using Fedora on servers was at least considered as a valid use case, they would never release F18 with Anaconda in its current state. Fedup would display something meaningful about the progress of the system upgrade, instead of its tiny meaningless progress bar. And they would probably not discuss such insane proposals as saving five seconds of GRUB prompt delay or a single display mode switch or hiding even more things in the boot process from the user because of purely aesthetic purposes, instead of thinking about more important things such as getting the display manager to actually handle the X server options to allow true multiseat, or the above mentioned Anaconda problem with custom RAID/LVM setups.

I am well aware that Anaconda developers are different people than the boot process polishers, but it sill shows something about the focus of the Fedora project. I wonder what problems Alan Cox had with Fedora that he annnounced he will use Ubuntu instead. As for me, I have been Red Hat Linux and then Fedora user since RH 3.0.3 on all my desktops, laptops, and most of my servers, but I have to say I am seriously considering to abandon Fedora as well.

Frequency of booting

Posted Mar 13, 2013 21:24 UTC (Wed) by duffy (subscriber, #31787) [Link]

"it sill shows something about the focus of the Fedora project."

It's not really any sort of hidden thing...

"The Fedora Project is the name of a worldwide community of people who love, use, and build free software. We want to lead in the creation and spread of free code and content by working together as a community."

--https://fedoraproject.org/en/about-fedora

If you want to spread free code and content, you have to make it accessible to a wider audience.

"The Fedora Project creates a world where (1) free culture is welcoming and widespread, (2) collaboration is commonplace, and (3) people control their content and devices."

-- https://fedoraproject.org/wiki/Vision_statement

You can't spread free culture far and wide if you limit who can access it.

"Among our other goals, we strive to create a distribution that is not only open to contribution but also serves the needs of a wide audience of users. By meeting the common needs of a wide audience, Fedora encourages the spread of free software, understanding of its methodologies, and participation in its processes."

-- https://fedoraproject.org/wiki/Overview

If you were upset about where the project was heading it would have been better if you spoke up back in 2006-2008 when those statements were developed by the project board.

Frequency of booting

Posted Mar 16, 2013 11:52 UTC (Sat) by jond (subscriber, #37669) [Link]

this could be read to support Yenya's argument as much as refute it (widening access by not locking out the server users).

Perhaps I'm jumping at shadows but you seem to be very passive aggressive towards yenya and I can't see why. It's as if I'm only seeing half of the conversation. They seem to at least be trying to offer constructive input.

Frequency of booting

Posted Mar 17, 2013 0:56 UTC (Sun) by duffy (subscriber, #31787) [Link]

I'm not - but you know, Yenya seems pretty capable of speaking for him or herself.

Frequency of booting

Posted Mar 18, 2013 8:05 UTC (Mon) by Yenya (subscriber, #52846) [Link]

Well, I didn't intend to hold a one-to-one exclusive discussion with you. Other readers are of course welcome to join. So saying "Yenya seems pretty capable of speaking for him or herself" is not the best way how to refute jond's point.

I have intentionally not posted a reply to your quotations - I have wondered whether the other readers could also see that the high-level "visionary" phrases you have quoted from the Fedora website have in fact nothing to do with the topic of the previous discussion - i.e. whether Fedora should also support server and power-desktop use cases. I am glad at least some of them do.

Frequency of booting

Posted Mar 13, 2013 22:30 UTC (Wed) by ovitters (subscriber, #27950) [Link]

GNOME 3 is not a tablet interface.

Did you read the blog post at all? The long list of use cases being considered and taken into account?

Frequency of booting

Posted Mar 18, 2013 18:54 UTC (Mon) by spongy (guest, #59953) [Link]

I agree with Yenya entirely. RedHat seems to have lost its way, slanting its focus entirely towards pleasing Wall Street. This seems to mean spending as little on Fedora to maximise the RHEL investment.

My biggest complaint with Fedora has been RedHats pervasive tendency to introduce some new replacement functionality at the same time that they removed the predecessor appliance. Also irritating is RPM/YUM which has fallen way behind the competitors apt/dpkg, and YAST. I now find my primary community of Linux servers having SLES, and openSUSE installed as the most polished, most stable, yet complete distros available. I also have many clients using Ubuntu, Mint, and Debian. And I support three clusters running Debian. A few of our desktop clients still use Fedora, RHEL or CentOS, but they are slowly moving away. FWIW, I too began my Linux adventure with RedHat 3.0.3 in 1996, starting with the 2 CD set from WGS. That continued thru 4.x, 5.x, 6.x, 7.x, 8.x, FC1, 2, 4, 6, 8, 10, 11, 13. I ran a few servers from time to time using FC but no longer do so, due to its lifecycle.

Frequency of booting

Posted Mar 18, 2013 19:58 UTC (Mon) by pizza (subscriber, #46) [Link]

>Also irritating is RPM/YUM which has fallen way behind the competitors apt/dpkg, and YAST.

At the risk of starting another mini flame fest, I'm wondering if you can elaborate here; how is RPM "way behind" dpkg, and how is yum "way behind" apt or YAST?

packaging

Posted Mar 18, 2013 21:32 UTC (Mon) by geuder (subscriber, #62854) [Link]

> how is RPM "way behind" dpkg, and how is yum "way behind" apt or YAST?

I haven't worked that much using yum, but I have failed to find the concept of recommended in yum. Does it exist?

zypper has recommended and apt even has recommended and suggested.

zypper has the concept of vendor change, in yum I have at least never hit it.

dpkg distinguishes configuration of the package. In the first installation this is probably similar to rpm %post%. But with dpkg you have to chance to reconfigure later, to my understanding with rpm you don't have that.

Debian supports multi-arch now. Does anything like this exist in rpm?

Debian seems to have more additional tools than the others. apt-file, debfoster, and debtree come to my mind, I've used all of them occasionally (I'll be glad to hear what are the equivalent tools on the other side of the fence)

So yes the order yum, zypper, apt for increased functionality reflects my experience. However, in my daily life the "deficencies" at the tail of the list haven't caused major trouble. (I haven't worked with any kind of multi-arch related stuff for a while)

On the other side the automatic mirror selection in yum and believe also in zypper is superior what I'm used to in Ubuntu. There I end up manually editing the apt source list each time my country mirror suffers from some hickup.

packaging

Posted Mar 18, 2013 22:42 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> I haven't worked that much using yum, but I have failed to find the concept of recommended in yum. Does it exist?
> zypper has recommended and apt even has recommended and suggested.

I think rpm5.org's RPM has Recommends/Suggests (which OpenSUSE uses), but Red Hat's RPM (4.x) does not. I don't know the status of it.

> zypper has the concept of vendor change, in yum I have at least never hit it.

"Vendor change"? Which repo provides which package or vendor in .desktop files?

> dpkg distinguishes configuration of the package. In the first installation this is probably similar to rpm %post%. But with dpkg you have to chance to reconfigure later, to my understanding with rpm you don't have that.

What do you mean by "reconfigure"? Reset to RPM-shipped defaults? The UIs that appear when installing server packages on Debian? IME, in RPM-land, other than defaults, it's usually up to $EDITOR.

> Debian supports multi-arch now. Does anything like this exist in rpm?

Fedora does biarch, but I'd fully support Debian-style multi-arch coming to Fedora. It's a much cleaner setup overall.

> Debian seems to have more additional tools than the others. apt-file, debfoster, and debtree come to my mind, I've used all of them occasionally (I'll be glad to hear what are the equivalent tools on the other side of the fence)

There is rpmdevtools which contains things like rpmdev-extract, rpmdev-diff, etc. As for the apt-* commands, I always forget which is used where. Most of those have analogues as subcommands of yum or flags to "rpm -q" (`rpm -qf /path/to/file` gives package(s) which installs the path).

> On the other side the automatic mirror selection in yum and believe also in zypper is superior what I'm used to in Ubuntu. There I end up manually editing the apt source list each time my country mirror suffers from some hickup.

Broken mirrors (404, hash mismatches, etc.) are handled gracefully by yum, but getting yum to stop using a slow mirror isn't the easiest. Ctrl-C is supposed to make yum stop its current download and restart it (preferably with a different mirror), but sometimes it gets all the way through and yum quits instead. Unfortunately, Ctrl-C to cancel things doesn't always work either (this is one of my gripes with Python in general).

packaging

Posted Mar 18, 2013 23:27 UTC (Mon) by geuder (subscriber, #62854) [Link]

> "Vendor change"? Which repo provides which package or vendor in .desktop files?

If the attribute displayed by

rpm -q --qf "%{VENDOR}\n" <package>

changes during upgrading an package changes zypper will warn you. It typically happens if you pull in dependencies built by yourself or from some independent repo. Not really sure how important that is, but it might be nice to know just in case something breaks.

> What do you mean by "reconfigure"?

It's not me, it's Debian that means...

http://manpages.ubuntu.com/manpages/precise/man8/dpkg-rec...

I have used to to change the keyboard layout of installed systems (it can be a major annoyance if they sell you only computers with non-US keyboards in your country and all software assumes US layout). I'm sure there are other uses, but probably not everybody's everyday stuff.

> The UIs that appear when installing server packages on Debian?

I guess we could mean the same. If the dialogs cause trouble check

http://manpages.ubuntu.com/manpages/precise/man7/debconf....

> There is rpmdevtools which contains things like rpmdev-extract, rpmdev-diff,

Without knowing exactly what they do after a quick glance to the man page, I don't think they are comparable to the ones I mentioned

- debfoster: helps to remove unnecessarily packages (stuff that nobody depends on anymore)
- apt-file: search for which not yet installed package contains a certain file.
- debtree: produce graphical dependency trees of installation or build time dependencies.

> Most of those have analogues as subcommands

I fully agree as far as basic set of rpm/zypper/yum vs. dpkg/apt commands is concerned. The more advanced, optional things as the 3 examples above I have never seen in the rpm world (I don't absolutetly claim they don't exist)

> but getting yum to stop using a slow mirror isn't the easiest

It gives up if less than 1 Byte/sec (I believe) is transferred for some time (which might be a bit too long) That is OK-ish if I do installations on the train and the network freezes. It might not be godd enough if you are on a fixed network and server is just really overloaded. Yes, I remember some buggy behaviour when using Ctrl-C.

packaging

Posted Mar 19, 2013 0:02 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

There are tools you might not be aware of

localectl (standard part of systemd)
package-cleanup --orphans
repoquery
rpmorphan package has rpmdep

packaging

Posted Mar 19, 2013 12:39 UTC (Tue) by geuder (subscriber, #62854) [Link]

Thanks, these are useful pointers.

Currently I use on RHEL/CentOS, maybe Fedora some day again in connection with some distro hopping...

> localectl (standard part of systemd)

If it's systemd I guess it's Fedora only

> package-cleanup
> repoquery

Contained in package yum-utils

> rpmorphan

Doesn't seem to be in RHEL or EPEL.

packaging

Posted Mar 19, 2013 14:32 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

This discussion was about Fedora originally but you can easily take the srpm from Fedora and build it for RHEL if you would like to, esp for rpmorphan.

http://koji.fedoraproject.org/koji/packageinfo?packageID=...

There are other alternatives for RHEL that might be available in EPEL. I haven't checked since I am not running EL.

packaging

Posted Mar 19, 2013 22:42 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> > localectl (standard part of systemd)

> If it's systemd I guess it's Fedora only
Why do you think that? Quite a few distros have switched to systemd already, including openSUSE, Arch Linux, Mageia and others.

packaging

Posted Mar 20, 2013 10:03 UTC (Wed) by micka (subscriber, #38720) [Link]

I guess it's fedora only v.s. fedora+rhel/centos.

packaging

Posted Mar 21, 2013 17:58 UTC (Thu) by nix (subscriber, #2304) [Link]

rhel hasn't switched yet, though it will. :)

packaging

Posted Mar 19, 2013 13:52 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

I think that Fedora doesn't use Vendor in its RPMs. I usually just get watchcommit permissions on packages I have persistent patches no one will accept. Sure, it only works for Fedora packages (not RPMFusion, etc.), but that's been sufficient for me. A plugin to yum which warns when the repo changes shouldn't be too hard.

packaging

Posted Mar 19, 2013 2:24 UTC (Tue) by raven667 (subscriber, #5198) [Link]

While RPM packages can have interactive scripts in pre/post handlers, it is not allowed by most packaging guidelines so you rarely see it. Allowing for interactive packages complicates centralized management, such as with RedHat Network/Spacewalk, because there is no one to show the UI to. So the tools are there to work that way but most distros have chosen not to do so.

> zypper has [...]

We should probably differentiate between features in the package format and features in the higher level manager because zypper is also working with RPM packages behind the scenes.

> zypper has the concept of vendor change, in yum I have at least never hit it.

That could be useful, yum does show which repo its pulling a package from when it presents the install/upgrade job to you for approval so if you are familiar with the system you can spot an upgrade coming from an unintended
place but that's clearly not as good as explicitly pointing it out.

> Debian supports multi-arch now. Does anything like this exist in rpm?

That's more of a distro question than a package manager one, RPM doesn't have any problem with bi-arch hosts and doesn't require special package builds to support it as long as the different arch packages don't have file conflicts. This is different than dpkg bi-arch which required separate 32bit packages with a different name to not conflict with the native arch packages.

I don't know if there are any distro plans to transition to multi-arch.

> Debian seems to have more additional tools than the others

As someone else pointed out these tools also exist in RPM land but I find that the functionality is spread out over fewer different tools and the UI is more consistent, for example yum does the job of both apt-get and apt-cache.

packaging

Posted Mar 19, 2013 2:33 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

> While RPM packages can have interactive scripts in pre/post handlers, it is not allowed by most packaging guidelines so you rarely see it. Allowing for interactive packages complicates centralized management

with apt the installation process can be given a parameter indicating how much the user is willing to be bothered by interactive scripts (including, not at all for the enterprise situation you describe), and if they want a text-only display or prettier menu, etc.

> RPM doesn't have any problem with bi-arch hosts and doesn't require special package builds to support it as long as the different arch packages don't have file conflicts. This is different than dpkg bi-arch which required separate 32bit packages with a different name to not conflict with the native arch packages.

multi-arch allows for the package name to be the same for all the arches that are installed. It's significantly better than bi-arch (except when you run into one of the broken packages :-) and it can handle the idea that some packages are going to the same across all arches (mostly for scripting language based packages or artwork packages)

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 16:56 UTC (Wed) by farnz (guest, #17727) [Link]

As a Fedora user forced to dual-boot Windows, I boot Fedora on a daily basis. I can't simply not boot Windows 8 - it's not me who uses it, it's another member of my family who has no choice due to third parties mandating certain pieces of Windows software.

The ideal fix would be for me to buy a second laptop, just for Fedora. In the meantime, Fedora boot time matters to me - I see it whenever I want to use the laptop for something serious.

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 22:47 UTC (Wed) by ovitters (subscriber, #27950) [Link]

The systemd developers demonstrated a 2 second boot for kernel+userspace (GDM). This required removing some stuff like LVM, etc. If the firmware of your laptop is quick, a 4 second boot to GDM is realistic (firmware on new laptops can take max 2 seconds if they want to show that shiny Windows logo).

Though if you really have 2 operating systems on there, I think showing a boot menu is good (IIRC that is also the plan).

Duffy: Improving the Fedora boot experience

Posted Mar 13, 2013 22:52 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

Essentially, if you are using a SSD and no LVM, it is likely that your system itself will boot faster than your login time from GDM.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 9:59 UTC (Thu) by Aissen (subscriber, #59976) [Link]

In this case auto-login with automatic screen locking is very useful. Something I use with kdm/KDE, but can't seem to be done with gdm/Gnome.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 10:30 UTC (Thu) by ovitters (subscriber, #27950) [Link]

File a bug please. Sounds interesting to support.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 10:40 UTC (Thu) by Aissen (subscriber, #59976) [Link]

I went ahead and created an account on Gnome's bugzilla, only to find this was not new:
https://bugzilla.gnome.org/show_bug.cgi?id=469571

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 10:49 UTC (Thu) by ovitters (subscriber, #27950) [Link]

GDM almost fully handles the lock screen now, IIRC. So I hope it is now way easier to implement. Before we relied on gnome-screensaver, etc. That is all messy. GDM in 3.8 still has a fallback thing because we removed it too late.

I'll try and convince people that this makes sense. Which I guess means convincing Lennart to convince others :P

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 17:19 UTC (Thu) by farnz (guest, #17727) [Link]

I've actually got a simpler setup that works for me, without a boot menu.

From Windows, holding shift while choosing restart gets me a menu from which I can choose Fedora. It takes about 10 seconds from there (BTRFS on dm-crypt on a slow HDD - so some of the time is eaten up by waiting for the passphrase) to get to the greeter. From Linux, I can either just reboot and end up in Windows, or run a script that just invokes efibootmgr --bootnext 0002 && reboot to reboot back into Fedora.

Windows 8 boots in about 5 seconds, and it takes me around 5 seconds to enter my passphrase for the disk, so I don't think Fedora is doing badly; however, I wouldn't object to ever faster Fedora boots. My ideal would be to get back to the boot time of 8-bit home computers - reboot in under a second, but I appreciate that that's outside Fedora's control due to the 2 second BIOS delay.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 8:06 UTC (Thu) by eduperez (guest, #11232) [Link]

Am I the only one around here who owns a desktop computer, and shuts if down at the end of the day, every day?
What is everybody else doing, hibernate / suspend exclusively?

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 9:38 UTC (Thu) by Yenya (subscriber, #52846) [Link]

As for me, my workstation at work stays on all the time (I use it for remote access as well), my multiseat desktop at home stays also on all the time (I use it as mail/http/... server for my personal domains, as a router for my home network, and as a data server for home theatre). My laptop gets suspended when I don't use it.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 9:58 UTC (Thu) by Aissen (subscriber, #59976) [Link]

You're not. I use both a desktop and a laptop with Fedora, that I shut down when I'm done. Make no mistake, I also use suspend (on both), but it's not the same use case.

Side note: thanks a lot to Máirín Duffy for taking the time to do this summary. I didn' see any reference to the impact of LVM by default in the installer though. Probably something to fix as well.

Duffy: Improving the Fedora boot experience

Posted Mar 14, 2013 18:35 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

I have mine set to suspend after a 10 minute timeout. I hate having to reboot and log in again, both because it's an older BIOS machine that takes much longer to boot than to restore from suspend and because my desktop setup doesn't restore perfectly (thanks a lot, Evolution). The suspend is deep enough that I don't think there's a lot of power savings from powering it all the way off.

Duffy: Improving the Fedora boot experience

Posted Mar 18, 2013 14:13 UTC (Mon) by nye (guest, #51576) [Link]

>The suspend is deep enough that I don't think there's a lot of power savings from powering it all the way off.

For what it's worth, on my desktop I clocked 'off' at around 0.2W, and standby at around 0.5W IIRC (actually, they may have been even closer). This is after suspending in Windows, but presumably Linux would be leaving the hardware in the same state (?).

I was pretty impressed by this and hence basically never turn the thing off now. YMMV, etc.