| |||||||||||||
Frequency of bootingFrequency of bootingPosted Mar 13, 2013 15:02 UTC (Wed) by jreiser (subscriber, #11027)In reply to: Duffy: Improving the Fedora boot experience by Yenya Parent article: Duffy: Improving the Fedora boot experience 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.
(Log in to post comments)
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 (guest, #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 (guest, #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)
> 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)
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
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
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]
> 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
> 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)
|
|||||||||||||