LWN: Comments on "Duffy: Improving the Fedora boot experience"

packaging

nix — Thu, 21 Mar 2013 17:58:24 +0000

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

packaging

micka — Wed, 20 Mar 2013 10:03:30 +0000

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

packaging

HelloWorld — Tue, 19 Mar 2013 22:42:58 +0000

> > 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

rahulsundaram — Tue, 19 Mar 2013 14:32:42 +0000

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

mathstuf — Tue, 19 Mar 2013 13:52:13 +0000

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

geuder — Tue, 19 Mar 2013 12:39:55 +0000

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

dlang — Tue, 19 Mar 2013 02:33:40 +0000

> 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)

packaging

raven667 — Tue, 19 Mar 2013 02:24:29 +0000

> 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.

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

rahulsundaram — Tue, 19 Mar 2013 00:02:22 +0000

There are tools you might not be aware of

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

packaging

geuder — Mon, 18 Mar 2013 23:27:02 +0000

> "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

mathstuf — Mon, 18 Mar 2013 22:42:47 +0000

> 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?

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

geuder — Mon, 18 Mar 2013 21:32:16 +0000

> 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.

Frequency of booting

pizza — Mon, 18 Mar 2013 19:58:01 +0000

>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?

Frequency of booting

spongy — Mon, 18 Mar 2013 18:54:52 +0000

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.

This is not (only) about prettyness

jwakely — Mon, 18 Mar 2013 17:42:56 +0000

Yes, obviously, I assumed that went without saying!

Duffy: Improving the Fedora boot experience

nye — Mon, 18 Mar 2013 14:13:11 +0000

>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.

This is not (only) about prettyness

nix — Mon, 18 Mar 2013 10:04:05 +0000

"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!

Frequency of booting

Yenya — Mon, 18 Mar 2013 08:05:19 +0000

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.

This is not (only) about prettyness

jwakely — Sun, 17 Mar 2013 21:16:09 +0000

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

HelloWorld — Sun, 17 Mar 2013 20:10:03 +0000

> 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

jwakely — Sun, 17 Mar 2013 17:33:59 +0000

> 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

tpo — Sun, 17 Mar 2013 11:34:27 +0000

>> 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.

Frequency of booting

duffy — Sun, 17 Mar 2013 00:56:10 +0000

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

This is not (only) about prettyness

duffy — Sun, 17 Mar 2013 00:55:25 +0000

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

duffy — Sun, 17 Mar 2013 00:54:29 +0000

"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.

Frequency of booting

jond — Sat, 16 Mar 2013 11:52:24 +0000

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.

Duffy: Improving the Fedora boot experience

ibukanov — Fri, 15 Mar 2013 10:03:34 +0000

The article does not mention the important point of total time wasted by a user including time spend for problematic boots. In case of boot problems an unhelpful GUI may force the user to spend extra hours while researching/solving the issue. That would kill any time savings from a faster boot unless one can assert that problems can happen only once per 1000 boots or so.

Duffy: Improving the Fedora boot experience

rgmoore — Thu, 14 Mar 2013 18:35:56 +0000

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

farnz — Thu, 14 Mar 2013 17:19:41 +0000

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

nye — Thu, 14 Mar 2013 15:59:14 +0000

Sooo... swings and roundabouts then really.

Regardless, it's interesting to know, thanks.

This is not (only) about prettyness

sebas — Thu, 14 Mar 2013 15:22:46 +0000

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).

Duffy: Improving the Fedora boot experience

tcourbon — Thu, 14 Mar 2013 14:33:43 +0000

The fact you ask if EFI help is proof you still have idealism.

Rejoice !

Duffy: Improving the Fedora boot experience

mjg59 — Thu, 14 Mar 2013 14:19:32 +0000

EFI does, in fact, help here! There's an entire section of the spec dedicated to this topic. Unfortunately, Microsoft's requirements for boot speed mean that most devices won't initialise USB in the firmware unless an application explicitly attempts to read a key, and doing that means adding a couple of seconds to boot time.

Duffy: Improving the Fedora boot experience

nye — Thu, 14 Mar 2013 13:46:35 +0000

>So in effect, this is a BIOS limitation.

I wish I still had enough idealism to be surprised :(.

Does EFI help here, or just add an additional set of possible bugs that need to be worked around?

Duffy: Improving the Fedora boot experience

pjones — Thu, 14 Mar 2013 13:24:44 +0000

There is! The general problem here is that BIOSes aren't terribly reliable in their handling of keyboard buffers - there are system firmwares that routinely leave the keyboard buffer full of junk, even when no keys have been pressed at all. So the first thing we do is clear the buffer and reset all the status flags, then check them again. That brings us to another issue - some firmwares won't start giving you new keypresses (or set the flag that a key has been pressed) once the flag is cleared unless you release the key and press it again.

So in effect, this is a BIOS limitation.

Duffy: Improving the Fedora boot experience

nye — Thu, 14 Mar 2013 13:01:16 +0000

I've never understood why the display of the boot menu is tied to whether you press a button within some timeout period, rather than just whether you're holding a button at the point the bootloader starts.

I'd much rather have grub never wait, and know that if I want the menu I need to hold control (say) while it's starting, than have my boot delayed *every time*, and know that if I want the menu I need to watch the process like a hawk so I can hit the right button at the precise time.

Is there a technical reason for this?

Duffy: Improving the Fedora boot experience

ovitters — Thu, 14 Mar 2013 10:49:29 +0000

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

Aissen — Thu, 14 Mar 2013 10:40:12 +0000

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

ovitters — Thu, 14 Mar 2013 10:30:13 +0000

File a bug please. Sounds interesting to support.

Duffy: Improving the Fedora boot experience

Aissen — Thu, 14 Mar 2013 09:59:43 +0000

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.

LWN: Comments on "Duffy: Improving the Fedora boot experience"

packaging

packaging

packaging

packaging

packaging

packaging

packaging

packaging

packaging

packaging

packaging

packaging

Frequency of booting

Frequency of booting

This is *not* (only) about prettyness

Duffy: Improving the Fedora boot experience

This is *not* (only) about prettyness

Frequency of booting

This is *not* (only) about prettyness

This is *not* (only) about prettyness

This is *not* (only) about prettyness

This is *not* (only) about prettyness

Frequency of booting

This is *not* (only) about prettyness

This is *not* (only) about prettyness

Frequency of booting

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

This is *not* (only) about prettyness

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

Duffy: Improving the Fedora boot experience

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness

This is not (only) about prettyness