As usual with a new release, there are newcomers on the forums who can often have their problems solved by adding something to the kernel line.
(Of course, it's not only newcomers, but...)
I'm wondering if it's worth considering increasing grub's default timeout to 3 seconds or so. As it stands, one has to hover over the escape key, trying to time it correctly. (Or, if they're as lazy as I am, before rebooting, go to another terminal and edit the mounted grub.config.)
I don't feel strongly enough about it to wade through bugzilla, and most certainly do NOT want to cause a controversial bikeshed thread, but I wonder--do people generally feel it's worth considering, or just a waste of time.
The motive is that until we have a perfect world, when all computers will boot perfectly the first time after an installation, it would make it a bit easier to edit the kernel line if necessary.
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
On Mon, Nov 23, 2009 at 09:28:19PM -0500, Scott Robbins wrote:
As it stands, one has to hover over the escape key, trying to time it correctly.
Not weighing in with any opinion on your propositions but just try _before_ even a grub screen will show up, but not far before, to hit "Up" or "Down" arrow keys, or even "Escape", and patiently wait for what will happen.
Michal
Michal Jaegermann wrote:
On Mon, Nov 23, 2009 at 09:28:19PM -0500, Scott Robbins wrote:
As it stands, one has to hover over the escape key, trying to time it correctly.
Not weighing in with any opinion on your propositions but just try _before_ even a grub screen will show up, but not far before, to hit "Up" or "Down" arrow keys, or even "Escape", and patiently wait for what will happen.
I know all that, but several times in the past 24 hours I've found myself booting the wrong thing.
Increasing _to_ three seconds? Ten is nearer the mark, I think. Especially for those of us playing with virtual machines and windows popping up and going away
If I'm sitting at a machine, too impatient to await the timeout, it's trivial to hit the enter key.
Even better, if I can actually see the menu, I can see whether it's booting what I want to boot. Often, if there's a dud kernel (it happened on RHEL4-clone and presumably RHEL4 itself a while ago), it's the default selection.
Too much bling at the expense of function, I say.
On Tue, 2009-11-24 at 15:15 +0800, John Summerfield wrote:
Michal Jaegermann wrote:
On Mon, Nov 23, 2009 at 09:28:19PM -0500, Scott Robbins wrote:
As it stands, one has to hover over the escape key, trying to time it correctly.
Not weighing in with any opinion on your propositions but just try _before_ even a grub screen will show up, but not far before, to hit "Up" or "Down" arrow keys, or even "Escape", and patiently wait for what will happen.
I know all that, but several times in the past 24 hours I've found myself booting the wrong thing.
Increasing _to_ three seconds? Ten is nearer the mark, I think. Especially for those of us playing with virtual machines and windows popping up and going away
10 seconds? And what about those of us who boot into Fedora by default and don't want to wait? If I want to use my other install, I reboot , sitting right there. No problem pressing a key to stop the timeout.
People change the timeout according to their requirements.
System>admin>boot loader.
You should do the same
regards, Ankur
Ankur Sinha wrote:
On Tue, 2009-11-24 at 15:15 +0800, John Summerfield wrote:
Michal Jaegermann wrote:
On Mon, Nov 23, 2009 at 09:28:19PM -0500, Scott Robbins wrote:
As it stands, one has to hover over the escape key, trying to time it correctly.
Not weighing in with any opinion on your propositions but just try _before_ even a grub screen will show up, but not far before, to hit "Up" or "Down" arrow keys, or even "Escape", and patiently wait for what will happen.
I know all that, but several times in the past 24 hours I've found myself booting the wrong thing.
Increasing _to_ three seconds? Ten is nearer the mark, I think. Especially for those of us playing with virtual machines and windows popping up and going away
10 seconds? And what about those of us who boot into Fedora by default and don't want to wait? If I want to use my other install, I reboot , sitting right there. No problem pressing a key to stop the timeout.
If ten seconds seem interminable, you need to get a life!
People change the timeout according to their requirements.
System>admin>boot loader.
Doesn't work on most of my systems. This always does: vim /boot/grub/menu.lst
Let me see.
I have two real computers beside my desk with RHEL-clone or Fedora. One normally runs Windows and has half-a-dozen or more virtual machines with Linux (mostly Debian, but still with grub). Across the room my sever runes RHEL4-clone. in the house my internet gateway runs another RHEL4-clone. My wife's system runs RHEL-clone, I have two laptops with Fedora and one with opensuse, all with grub. Over there in the corner are a couple of test systems, those too have grub. As has my wife's previous system....
Yesterday, I got tired of installing broken Fedora (gosh, I hope F12 isn't the base for the next RHEL!!), and installed Ark linux instead. It happens it was on a DVD attached to a magazine.
I'm for ever updating grub menus!
Actually, there's a good reason I go for even longer timeouts sometimes. My work system has a one-hour timeout. The reason?
Sometimes, we have a power failure. It makes good sense for desktops to boot after servers, so the servers are good and ready to serve out IP addresses etc.
Sometimes, not often, there is a small succession of power failures. The one-hour delay ensures that the desktop gives the power supply ample time to settle down. If, as is often the case, I'm not there, it usually doesn't matter if it's down for a while, most times I don't notice.
OTOH if I really am present, pressing a key or two to boot appropriately really is trivial. Even if ten seconds does seem for ever!
In contrast, with short delays on some systems the screen hasn't even settled down from the graphics card being reinitialised and the grub display's not even visible.
When it is visible, it is still too easy for one's attention to wander while POST does its thing.
Especially on Fedora (and opensuse and debian testing), automatically booting the latest kernel is a recipe for disaster. It will happen that you will install a kernel that will not boot. It happened to lots of people with FC3, it happened (fortunately after I made an enormous fuss it got fixed before Golden Day) with Fedora 8 (or thereabouts) betas. Kernel 2.6.25 it was. 2.6.24 was fine.
On 2009/11/24 08:04 (GMT+0800) John Summerfield composed:
In contrast, with short delays on some systems the screen hasn't even settled down from the graphics card being reinitialised and the grub display's not even visible.
+10
I have a number of systems like this. Even setting POST type to normal/long isn't necessarily long enough for video to initialize prior to a Grub menu appearance.
The concept of least surprise here points to longest possible Grub menu delay. Those in a hurry can hit enter to speed the process at any time without risk of surprise. When others need to do something other than hit enter, they need more time to decide what and when.
On 11/24/2009 04:18 PM, Felix Miata wrote:
On 2009/11/24 08:04 (GMT+0800) John Summerfield composed:
In contrast, with short delays on some systems the screen hasn't even settled down from the graphics card being reinitialised and the grub display's not even visible.
+10
I have a number of systems like this. Even setting POST type to normal/long isn't necessarily long enough for video to initialize prior to a Grub menu appearance.
The concept of least surprise here points to longest possible Grub menu delay. Those in a hurry can hit enter to speed the process at any time without risk of surprise. When others need to do something other than hit enter, they need more time to decide what and when.
Whoa! I recognize that we're all nerds here (or we wouldn't be running cutting-edge versions of Linux in the first place), but everything I've heard in this thread bring up exceptions rather than rules.
Fedora 12 seems to "just work" for a hell of a lot of the people who've tried it and the boot sequence is just fine for them. It's those of us who do something "a little different" or are having issues that are complaining. To tweak Fedora in order to create a product that speaks to the, what, 5% of users with issues or doing oddball things is sorta silly, and the users with problems have resources (such as this very list) to help them adjust things like grub, the kernel parameters and such to get a working sytstem.
If there's an non-techie type trying to run Fedora, s/he is bound to have problems. It is the bleeding edge, after all, and anyone running Fedora should consider themselves, by definition, as a guinea pig.
Face it, at the best of times Fedora is really what the rest of the world would call a "beta". At some point, when we've all bled adequately, chewed enough fingernails and torn out sufficient amounts of hair, it becomes the basis for a "stable" release of RHEL (isn't RHEL 5 based on the work we did on Fedora 6?). If you're not willing to suffer these problems, you should run something stable like CentOS.
Ok, I'm butting out of this thread. -- Rick Stevens "Death is nature's way of dropping carrier"
Here is at least a partial list of language material that got installed unnecessarily and unwantedly when I installed F12 on a plain laptop.
bunch of packages names starting with m17n bunch of packages names starting with kacst packages names starting with un-core package names containing hangul, Canna, pinyin cjkuni-uming-fonts jomolhari-fonts khmeros-base-fonts khmeros-fonts-common abyssinica-fonts paktype-tehreer-fonts sinc-meera-fonts
Almost none of these have any dependencies requiring their presence. Would someone please investigate why all these get installed by default with recent distributions?
On 11/25/2009 05:53 AM, Jim Haynes wrote:
Here is at least a partial list of language material that got installed unnecessarily and unwantedly when I installed F12 on a plain laptop.
bunch of packages names starting with m17n bunch of packages names starting with kacst packages names starting with un-core package names containing hangul, Canna, pinyin cjkuni-uming-fonts jomolhari-fonts khmeros-base-fonts khmeros-fonts-common abyssinica-fonts paktype-tehreer-fonts sinc-meera-fonts
Almost none of these have any dependencies requiring their presence. Would someone please investigate why all these get installed by default with recent distributions?
It is installed by default to provide the broadest possible locale support out of the box. For users of these locales, doing it post-installation is often difficult.
Rahul
Rahul Sundaram wrote:
On 11/25/2009 05:53 AM, Jim Haynes wrote:
Almost none of these have any dependencies requiring
their presence. Would someone please investigate why all these get installed by default with recent distributions?
It is installed by default to provide the broadest possible locale support out of the box. For users of these locales, doing it post-installation is often difficult.
As I mentioned in another thread yesterday, currently it's not possible to prevent this.
I don't see why an Australian user (for example) should automatically get all the middle-eastern and asian fonts. It is true we have a significant Vietnamese community here in WA, they should be able to _ask_ for their language support during installed.
On 11/25/2009 06:10 AM, John Summerfield wrote:
As I mentioned in another thread yesterday, currently it's not possible to prevent this.
That depends on your method of installation.
I don't see why an Australian user (for example) should automatically get all the middle-eastern and asian fonts. It is true we have a significant Vietnamese community here in WA, they should be able to _ask_ for their language support during installed.
In the case of Live CD's there is no possibility of asking anything.
Rahul
Rahul Sundaram wrote:
On 11/25/2009 06:10 AM, John Summerfield wrote:
As I mentioned in another thread yesterday, currently it's not possible to prevent this.
That depends on your method of installation.
Not by anaconda-GUI. Apparently, not by ks. See my package list.
I don't see why an Australian user (for example) should automatically get all the middle-eastern and asian fonts. It is true we have a significant Vietnamese community here in WA, they should be able to _ask_ for their language support during installed.
In the case of Live CD's there is no possibility of asking anything.
I'm not talking about live CDs or live DVDs, I'm talking about an install where users are well known.
John Summerfield (debian@herakles.homelinux.org) said:
As I mentioned in another thread yesterday, currently it's not possible to prevent this.
That depends on your method of installation.
Not by anaconda-GUI. Apparently, not by ks. See my package list.
You should just be able to remove the fonts and input-methods groups.
(Note: if you remove the fonts group, you may need to add fonts for 'latin' coverage back by hand.)
Bill
On Wed, Nov 25, 2009 at 08:40:31AM +0800, John Summerfield wrote:
Rahul Sundaram wrote:
On 11/25/2009 05:53 AM, Jim Haynes wrote:
It is installed by default to provide the broadest possible locale support out of the box. For users of these locales, doing it post-installation is often difficult.
As I mentioned in another thread yesterday, currently it's not possible to prevent this.
I don't see why an Australian user (for example) should automatically get all the middle-eastern and asian fonts. It is true we have a significant Vietnamese community here in WA, they should be able to _ask_ for their language support during installed.
This is one I don't quite understand either--I had thought that someone was working on it though, to install for the locale being used. No?
On 11/25/2009 06:16 AM, Scott Robbins wrote:
This is one I don't quite understand either--I had thought that someone was working on it though, to install for the locale being used. No?
How do you do that exactly for Live images? There is no package selection. How do you determine which locales to include by default? The locale being used and wanted by users is not going to be easy to determine at all. If you want that level of control, you really need to use kickstart and be done with it.
Rahul
On Wed, Nov 25, 2009 at 06:15:39AM +0530, Rahul Sundaram wrote:
On 11/25/2009 06:16 AM, Scott Robbins wrote:
This is one I don't quite understand either--I had thought that someone was working on it though, to install for the locale being used. No?
How do you do that exactly for Live images? There is no package selection. How do you determine which locales to include by default? The locale being used and wanted by users is not going to be easy to determine at all. If you want that level of control, you really need to use kickstart and be done with it.
Oops, missed the part about live images. As the late, wonderful Gilda Radner used to say, "Never mind."
On Tue, 24 Nov 2009, Scott Robbins wrote:
Oops, missed the part about live images. As the late, wonderful Gilda Radner used to say, "Never mind."
I'll admit to not having thought of that either, since I never install that way; but still with live images the users of lots of other languages are left out too: Cyrillic, Greek, special characters used in European languages...
Rahul Sundaram wrote:
On 11/25/2009 06:16 AM, Scott Robbins wrote:
This is one I don't quite understand either--I had thought that someone was working on it though, to install for the locale being used. No?
You aside, nobody's talking about live media.
On 11/25/2009 01:13 PM, John Summerfield wrote:
Rahul Sundaram wrote:
On 11/25/2009 06:16 AM, Scott Robbins wrote:
This is one I don't quite understand either--I had thought that someone was working on it though, to install for the locale being used. No?
You aside, nobody's talking about live media.
So you agree that Live media should have all the fonts? ok, In the non-live media case, do you want everything except English unchecked by default or what exactly are you proposing?
Rahul
Rahul Sundaram kirjoitti viestissään (lähetysaika keskiviikko, 25. marraskuuta 2009):
So you agree that Live media should have all the fonts? ok, In the non-live media case, do you want everything except English unchecked by default or what exactly are you proposing?
The installer shouldn't install support for languages that aren't checked in the Languages category. This is the result after installing F12 using the standard non-live install DVD with only Finnish and English languages selected:
# LANG=en_US yum grouplist Loaded plugins: presto, refresh-packagekit Setting up Group Process Installed Groups: Administration Tools Arabic Support Armenian Support Assamese Support Base Bengali Support Bhutanese Support Dial-up Networking Support Editors Ethiopic Support Finnish Support Fonts GNOME Desktop Environment Games and Entertainment Georgian Support Graphical Internet Gujarati Support Hardware Support Hebrew Support Hindi Support Input Methods Inuktitut Support Japanese Support Java Kannada Support Khmer Support Korean Support Lao Support Legacy Fonts Mail Server Maithili Support Malayalam Support Marathi Support Network Servers Office/Productivity Oriya Support Printing Support Punjabi Support Server Configuration Tools Sinhala Support Sound and Video System Tools Tajik Support Tamil Support Telugu Support Text-based Internet Thai Support Urdu Support Venda Support Web Server X Window System
On 11/25/2009 06:58 PM, Markku Kolkka wrote:
Rahul Sundaram kirjoitti viestissään (lähetysaika keskiviikko, 25. marraskuuta 2009):
So you agree that Live media should have all the fonts? ok, In the non-live media case, do you want everything except English unchecked by default or what exactly are you proposing?
The installer shouldn't install support for languages that aren't checked in the Languages category.
So you want the default selection to be English only. I think 350 MB of disk space isn't worth the hassle for majority of Fedora users (yes, the majority is not English) but that's just me. I will stop here.
Rahul
On Wednesday 25 of November 2009 14:33:45 Rahul Sundaram wrote:
So you want the default selection to be English only. I think 350 MB of disk space isn't worth the hassle for majority of Fedora users (yes, the majority is not English) but that's just me. I will stop here.
ahem, but *the majority* does not need support for *all* the languages
the fact that I can speak not just English but also Czech and Slovak, and also a bit Russian, German and Polish, does *not* imply that I want to have installed support for e.g. Chinese, Arabic languages and whatever else
it is the same argument, as if you'd say "majority of our users use GNOME, so let's install all the GNOME packages by default to all despite the fact they have chosen KDE/XFCE/LXDE/whatever" (hey, that already happens with GNOME! - sad :-( )
and 350 MB multiplied by *all* the users is hell a lot of wasted space and bandwith
K.
On 11/25/2009 08:10 PM, Karel Volný wrote:
On Wednesday 25 of November 2009 14:33:45 Rahul Sundaram wrote:
So you want the default selection to be English only. I think 350 MB of disk space isn't worth the hassle for majority of Fedora users (yes, the majority is not English) but that's just me. I will stop here.
ahem, but *the majority* does not need support for *all* the languages
Sure but then you are back again to picking only English by default because you can't guess which languages are needed by which users and I don't think it is a good choice. Face it, packages are always going to contain locale information which you don't need.
Rahul
On Wednesday 25 of November 2009 16:17:28 Rahul Sundaram wrote:
On 11/25/2009 08:10 PM, Karel Volný wrote:
On Wednesday 25 of November 2009 14:33:45 Rahul Sundaram
wrote:
So you want the default selection to be English only. I think 350 MB of disk space isn't worth the hassle for majority of Fedora users (yes, the majority is not English) but that's just me. I will stop here.
ahem, but *the majority* does not need support for *all* the languages
Sure but then you are back again to picking only English by default because you can't guess which languages are needed by which users and I don't think it is a good choice.
well, you see that some of the people do not share the same opinion ... defaulting to English and having to check some checkboxes for adding other languages is more comfortable to me than having the system polluted with significant amount of things I never use
Face it, packages are always going to contain locale information which you don't need.
never say never ... or always :-)
I remember seeing some discussion if it is doable to split the localised data into separate packages - from what I recall, the answer is positive in principle, so now it is just waiting for someone to do the dirty job (btw, Gentoo already does this for a lot of packages)
K.
On 11/25/2009 09:17 PM, Karel Volný wrote:
Face it, packages are always going to contain locale information which you don't need.
never say never ... or always :-)
I remember seeing some discussion if it is doable to split the localised data into separate packages - from what I recall, the answer is positive in principle, so now it is just waiting for someone to do the dirty job (btw, Gentoo already does this for a lot of packages)
Do you even realize how many thousands of new sub packages your proposal would require and the cost of doing so in terms of metadata increase etc? I don't think so.
Rahul
On Wednesday 25 of November 2009 16:47:23 Rahul Sundaram wrote:
On 11/25/2009 09:17 PM, Karel Volný wrote:
Face it, packages are always going to contain locale information which you don't need.
never say never ... or always :-)
I remember seeing some discussion if it is doable to split the localised data into separate packages - from what I recall, the answer is positive in principle, so now it is just waiting for someone to do the dirty job (btw, Gentoo already does this for a lot of packages)
Do you even realize how many thousands of new sub packages your proposal would require
now when you ask ... yes
um, and I forgot that we are already splitting for some packages, for example KDE, OpenOffice, man-pages ... and also the input methods packages, and the fonts, are divided by the language, it is just the matter of not installing them by default (and making it convenient to do everything on demand)
and the cost of doing so in terms of metadata increase etc?
yes - still much less than 350 MB + size of the unused localisation support for each package :-p
out of curiousity, I just checked one of our rpm based rivals, and OpenSUSE seems being fine without e.g. the Malayalam support installed by default
K.
On 11/25/2009 09:49 PM, Karel Volný wrote:
yes - still much less than 350 MB + size of the unused localisation support for each package :-p
Do your calculation on the metadata increase (the impact of which is much more than disk space) and then post it. You have to split every single package into dozens of sub packages. After you have done this calculation, tell me again whether your proposal makes any sense at all.
Rahul
On Wednesday 25 of November 2009 17:19:33 Rahul Sundaram wrote:
On 11/25/2009 09:49 PM, Karel Volný wrote:
yes - still much less than 350 MB + size of the unused localisation support for each package :-p
Do your calculation on the metadata increase (the impact of which is much more than disk space) and then post it.
let me note that it was you who started the argumentation about too big metadata increase (I don't care, see below), so don't leave your homework to me and show us the maths, if you want to back up your original argument
You have to split every single package
simply not true, lot of packages don't seem to have localisation (yet), for example busybox, gzip, libzip, nspluginwrapper ...
into dozens of sub packages.
... and many of those that have some don't support dozens of languages (yet), for example cpufrequtils (5 translations), qmmp (14 translations, that's only one dozen and a bit)
After you have done this calculation,
see above
tell me again whether your proposal makes any sense at all.
which one do you mean? - not to force users to install what they don't want? - IMO yes, no matter of the maths (unless it won't make it physically impossible, which is hardly the case)
there is rpmdiff and deltarpms ... couldn't be there also deltametadata etc.?
but this begins to resemble too much of a flamewar, and also this is not the right list to discuss further Fedora development
I guess we know each others opinion well enough by now, let's stop it - feel free to answer, don't expect me to do so once again
K.
On 11/25/2009 10:54 PM, Karel Volný wrote:
On Wednesday 25 of November 2009 17:19:33 Rahul Sundaram wrote:
On 11/25/2009 09:49 PM, Karel Volný wrote:
yes - still much less than 350 MB + size of the unused localisation support for each package :-p
Do your calculation on the metadata increase (the impact of which is much more than disk space) and then post it.
let me note that it was you who started the argumentation about too big metadata increase (I don't care, see below),
The person requesting the change is the one who should be justifying it. Not me. You made the suggestion to split up packages and I told you why it wouldn't work and I am pretty sure you haven't thought through your proposal at all. Metadata is only one such problem with your proposal.
Rahul
If the goal is to separate locale-dependent data from packages that now contain data for multiple locales, it seems reasonable in many cases to combine locale-dependent data from multiple packages into single, new, locale-data packages.
Some arithmetic...
If there are 5000 packages with locale-dependent data, and 100 locales, creation of individual, new, locale-specific packages could produce 500,000 new packages - the explosion that rightly concerns Mr. Sundaram. Of course, all those 5000 packages might not have data for all 100 locales, but any significant fraction of 500,000 is a nightmare.
A different approach would be more manageable: combine locale-dependent data for many packages into one locale_data package. In the minimum case, this would result in only 100 new packages, each one containing data for one locale from all 5000 original packages.
A more practical scheme would probably group those 5000 packages into a small number of categories (perhaps aligned with translation group, distribution organization, etc.). There would then be a small_number * 100 new packages, instead of a Million Package March.
Organization of packages in this way makes addition of a new locale straightforward: just install the package (or small number of packages) for the desired locale.
Is this worth doing? I don't know. If enough people see the goal (a system contains data only for the desired locales) as worthwhile, they can do this for a small set of packages to learn what problems may manifest and what techniques are efficient to manage the data. If a standard, easy technology is developed, package authors or maintainers may be willing to move locale-dependent data out of their packages.
On Wed, 2009-11-25 at 22:55 -0500, Richard Ryniker wrote:
If the goal is to separate locale-dependent data from packages that now contain data for multiple locales, it seems reasonable in many cases to combine locale-dependent data from multiple packages into single, new, locale-data packages.
Some arithmetic...
If there are 5000 packages with locale-dependent data, and 100 locales, creation of individual, new, locale-specific packages could produce 500,000 new packages - the explosion that rightly concerns Mr. Sundaram. Of course, all those 5000 packages might not have data for all 100 locales, but any significant fraction of 500,000 is a nightmare.
A different approach would be more manageable: combine locale-dependent data for many packages into one locale_data package. In the minimum case, this would result in only 100 new packages, each one containing data for one locale from all 5000 original packages.
A more practical scheme would probably group those 5000 packages into a small number of categories (perhaps aligned with translation group, distribution organization, etc.). There would then be a small_number * 100 new packages, instead of a Million Package March.
Organization of packages in this way makes addition of a new locale straightforward: just install the package (or small number of packages) for the desired locale.
Is this worth doing? I don't know. If enough people see the goal (a system contains data only for the desired locales) as worthwhile, they can do this for a small set of packages to learn what problems may manifest and what techniques are efficient to manage the data. If a standard, easy technology is developed, package authors or maintainers may be willing to move locale-dependent data out of their packages.
Then we have the problem of 'I don't want all this data in my language for packages I don't have installed' rather than 'I don't want all this data in someone else's language for packages I do have installed'. Doesn't seem like a significant win, to me.
Then we have the problem of 'I don't want all this data in my language for packages I don't have installed' rather than 'I don't want all this data in someone else's language for packages I do have installed'. Doesn't seem like a significant win, to me.
Maybe so. I do not claim there is a physical benefit - less space, easier installation, whatever - though there might be. Is it emotionally less distressing to have unnecessary data in your language instead of unknown or irrelevant languages?
I am in the "Who cares about another GB, I have hundreds available on my system disk" camp. Others, who want to install a minimal system, may have a legitimate gripe.
In either case (packages contain data for many locales; packages do not contain locale data, but have a shared dependency on other packages to provide data for each individual locale), it is possible to consider a pruning utility that would delete unnecessary data, and perhaps leave some kind of metadata trace to facillitate re-installation of locale data when support is needed for a new locale or a new application. This sounds complicated. It could make sense to someone who builds for a very stable target, such as an embedded system.
If locale data from many packages is moved into a set of locale-specific packages, there would be a reduction in size and translation effort. How many times is a "File not found" message duplicated because hundreds of packages contain this message, in many languages? The opportunity to factor common messages, so there is only one copy shared by many applications, is appealing.
On Sun, Nov 29, 2009 at 08:06:47PM -0500, Richard Ryniker wrote:
In either case (packages contain data for many locales; packages do not contain locale data, but have a shared dependency on other packages to provide data for each individual locale), it is possible to consider a pruning utility that would delete unnecessary data
A "pruning utility" does exits. If you have various language packages, like "openoffice.org-langpack..." or "kde-l10n-..." then it is called "Customize now" during an installation and later on "yum remove ...". You can also use 'kickstart' if you do multiple installations.
If you are worried about an excess of locale data in individual packages then create /etc/rpm/macros.lang with a content like
%_install_langs C:en:fr
or whatever you deem reasonable in your case and see what will happen. There are the following problems with that: - AFAIK this is not documented or advertised in any way - it has no effect on packages already installed - it breaks yum-presto in a manifest way - savings may turn to be below your expectations - somebody else using your machine now or in the future may find out that a support for her/his desired locale is broken without obvious ways to fix it (all affected packages would have to reinstalled with new, possibly default, '%_install_langs' although '--force' option to rpm will help with that).
Try 'rpm --showrc | grep langs' to see how you have it set now. To see what happened to files in an installed package use 'rpm -qs <some_package>'.
Michal
--- On Sun, 11/29/09, Michal Jaegermann michal@harddata.com wrote:
From: Michal Jaegermann michal@harddata.com Subject: Re: Un-asked-for-language support To: "For testers of Fedora Core development releases" fedora-test-list@redhat.com Date: Sunday, November 29, 2009, 5:59 PM On Sun, Nov 29, 2009 at 08:06:47PM -0500, Richard Ryniker wrote:
In either case (packages contain data for many
locales; packages do not
contain locale data, but have a shared dependency on
other packages to
provide data for each individual locale), it is
possible to consider a
pruning utility that would delete unnecessary data
A "pruning utility" does exits. If you have various language packages, like "openoffice.org-langpack..." or "kde-l10n-..." then it is called "Customize now" during an installation and later on "yum remove ...". You can also use 'kickstart' if you do multiple installations.
If you are worried about an excess of locale data in individual packages then create /etc/rpm/macros.lang with a content like
%_install_langs C:en:fr
or whatever you deem reasonable in your case and see what will happen. There are the following problems with that:
- AFAIK this is not documented or advertised in any way
- it has no effect on packages already installed
- it breaks yum-presto in a manifest way
- savings may turn to be below your expectations
- somebody else using your machine now or in the future
may find out that a support for her/his desired locale is broken without obvious ways to fix it (all affected packages would have to reinstalled with new, possibly default, '%_install_langs' although '--force' option to rpm will help with that).
Try 'rpm --showrc | grep langs' to see how you have it set now. To see what happened to files in an installed package use 'rpm -qs <some_package>'.
Michal--
I do not know much about this issue(locales and support of many languages), but I would like to point out some possibilities to make more people happy
1) Fedora should continue to support as many languages as possible as it currently does,
2) It should allow users to remove the stuff that they don't want/need on their machines. This includes remove dependencies on packages that should not depend on others.
3) How about the lzma(xz) compression, does not it save space and allow for more of the locales/languages to be included in default livecd's/spins?
4) The DVD isos are being cut much space that had much more packages that are no longer there(texlive comes to mind as it was before on DVD and is no longer there :( ) This in my opinion is not good as opposed to the many locales/languages that are on the install DVDs and LiveCD's.
5) I know that this is *not a valid excuse* to leave locales the way that they are currently, but we already install many things that we don't need and hard disk space does not really matter given that hard drives are getting bigger and cheaper. It should not matter that locales/languages are taking much.
They took away the so-called "Everything install" once, so I see the point that many users out there want the "Everything locales" taken also away to make their systems, faster, leaner and meaner :) I respect this argument and is very valid :)
6) How are we(Fedora release engineering, Fedora team) going to accomplish this task in a way which does not tell its users, we CAN't, WON't remove the "unwanted Locales/Languages in its Fedora install media"? This is the more important question.
I hope I did not RANT/vent my opinions in a harmful way. Probably filing RFE's/Bugzilla's and not see "WON'T FIX", "CLOSED, NOT A BUG" will help, but with those responses, things will likely stay the SAME :(
Regards,
Antonio
On Sun, Nov 29, 2009 at 19:02:32 -0800, Antonio Olivares olivares14031@yahoo.com wrote:
- How about the lzma(xz) compression, does not it save space and allow for more of the locales/languages to be included in default livecd's/spins?
The live spins use squashfs which currently doesn't use lzma compression. There is a good chance that Phillip Lougher will be submitting a patch in the 2.6.33 merge window for the upstream kernel to do this. We'll know in a couple of weeks. If this happens then I think there is a reasonable shot that F13 will use lzma for the live spins.
On Sun, 2009-11-29 at 22:36 -0600, Bruno Wolff III wrote:
On Sun, Nov 29, 2009 at 19:02:32 -0800, Antonio Olivares olivares14031@yahoo.com wrote:
- How about the lzma(xz) compression, does not it save space and allow for more of the locales/languages to be included in default livecd's/spins?
The live spins use squashfs which currently doesn't use lzma compression. There is a good chance that Phillip Lougher will be submitting a patch in the 2.6.33 merge window for the upstream kernel to do this. We'll know in a couple of weeks. If this happens then I think there is a reasonable shot that F13 will use lzma for the live spins.
It's worth clarifying here for Antonio that the live CD does not in fact contain any RPM package files at all. It contains a compressed filesystem. So the compression of RPM package payloads with lzma/xz has no relevance to the live CD. Bruno is explaining that the filesystem on the live CD is not compressed using lzma/xz compression, but it may be possible to do that in future.
On 11/25/2009 04:17 PM, Rahul Sundaram wrote:
On 11/25/2009 08:10 PM, Karel Volný wrote:
On Wednesday 25 of November 2009 14:33:45 Rahul Sundaram wrote:
So you want the default selection to be English only. I think 350 MB of disk space isn't worth the hassle for majority of Fedora users (yes, the majority is not English) but that's just me. I will stop here.
ahem, but *the majority* does not need support for *all* the languages
Sure but then you are back again to picking only English by default because you can't guess which languages are needed by which users and I don't think it is a good choice.
Why not asking the user/installer for it?
Face it, packages are always going to contain locale information which you don't need.
Right, but this isn't an excuse for a bloated default package install set.
On 11/25/2009 10:37 PM, Ralf Corsepius wrote:
Why not asking the user/installer for it?
With a English only default, yes? I prefer comprehensive locale support of the box and since the default download in Fedora is a Live image, you don't get to choose packages during installation. Again, people who care or want that level of control should be using kickstart instead IMO.
Right, but this isn't an excuse for a bloated default package install set.
Bloat is a matter of perspective. What you consider bloat, I consider a useful feature. Apparently people who feel strongly otherwise haven't bothered to file a RFE on this and convince rel-eng of their case. The current status quo remains till then.
Rahul
On 11/25/2009 06:11 PM, Rahul Sundaram wrote:
On 11/25/2009 10:37 PM, Ralf Corsepius wrote:
Why not asking the user/installer for it?
With a English only default, yes?
Why not? This is what you currently are doing.
I prefer comprehensive locale support of the box and since the default download in Fedora is a Live image,
Pardon? The default for me is the DVD, the live image is negliable.
you don't get to choose packages during installation.
Design flaw - More accurately: Users should not have to take care about any packaging details for "languages support".
Anaconda should ask about which languages the user want to use/install - The rest must be accomplished by "magic".
Again, people who care or want that level of control should be using kickstart instead IMO.
Pardon? The people who care about this level is the "computer illiterate user".
Right, but this isn't an excuse for a bloated default package install set.
Bloat is a matter of perspective. What you consider bloat, I consider a useful feature.
Pardon?
How many languages do you speek? Normal people speak very few languages and are able to read very few scripts. Anything they can't read is bloat to them.
=> Only very few people actually need the plethora of "languages", "scripts" and "fonts" Fedora installs rsp. comes with.
=> It should be an installers duty to take care of this.
Apparently people who feel strongly otherwise haven't bothered to file a RFE on this and convince rel-eng of their case.
Well, I occasionally did so and have learnt my lesson:
The nature of this issue is beyond the scope of what individual maintainers, upstreams and a distro's release engineers can handle. Each of them prefers to shift around responsibilities or try to play down the issues.
On 11/26/2009 05:43 AM, Ralf Corsepius wrote:
The nature of this issue is beyond the scope of what individual maintainers, upstreams and a distro's release engineers can handle. Each of them prefers to shift around responsibilities or try to play down the issues.
Alright. Then we have settled on the status quo. You are pardoned :-)
Rahul
On 11/26/2009 01:17 AM, Rahul Sundaram wrote:
On 11/26/2009 05:43 AM, Ralf Corsepius wrote:
The nature of this issue is beyond the scope of what individual maintainers, upstreams and a distro's release engineers can handle. Each of them prefers to shift around responsibilities or try to play down the issues.
Alright. Then we have settled on the status quo. You are pardoned :-)
No, all I am saying is that Fedora is not equipped with the appropriate mechanisms/people/structures to handle this problem - It's a structural problem of the system.
On 11/26/2009 04:09 PM, Ralf Corsepius wrote:
On 11/26/2009 01:17 AM, Rahul Sundaram wrote:
On 11/26/2009 05:43 AM, Ralf Corsepius wrote:
The nature of this issue is beyond the scope of what individual maintainers, upstreams and a distro's release engineers can handle. Each of them prefers to shift around responsibilities or try to play down the issues.
Alright. Then we have settled on the status quo. You are pardoned :-)
No, all I am saying is that Fedora is not equipped with the appropriate mechanisms/people/structures to handle this problem - It's a structural problem of the system.
Sure, whatever your explanation is - the end result is status quo.
Rahul
On Wed, 2009-11-25 at 18:07 +0100, Ralf Corsepius wrote:
On 11/25/2009 04:17 PM, Rahul Sundaram wrote:
On 11/25/2009 08:10 PM, Karel Volný wrote:
On Wednesday 25 of November 2009 14:33:45 Rahul Sundaram wrote:
So you want the default selection to be English only. I think 350 MB of disk space isn't worth the hassle for majority of Fedora users (yes, the majority is not English) but that's just me. I will stop here.
ahem, but *the majority* does not need support for *all* the languages
Sure but then you are back again to picking only English by default because you can't guess which languages are needed by which users and I don't think it is a good choice.
Why not asking the user/installer for it?
Face it, packages are always going to contain locale information which you don't need.
Right, but this isn't an excuse for a bloated default package install set.
The distinction here is between languages which require input methods and languages which don't. If you want to add, say, Russian post-install, it's easy: install appropriate fonts - which you can do by just going to a Russian website, thanks to PackageKit - and set an appropriate keyboard layout.
For languages which require input methods, it isn't that simple. There's no mechanism in Fedora, KDE or GNOME for installing and configuring the input methods for languages which require them, post distribution installation. Just installing appropriate fonts and a keyboard layout isn't enough for writing in these languages.
The post-install case is simple enough: multi-user system, new user who speaks Korean (or whichever input-method based language you like). Or, as quite often happens, someone who has an existing Fedora installation and decides to start learning Japanese or something, and wants to write it on their computer.
There could be a better solution to this written, probably, if someone had the time and dedication, but it's not simple. (I'm not entirely sure why the input methods themselves need the fonts to be installed, though).
The distinction here is between languages which require input methods and languages which don't. If you want to add, say, Russian post-install, it's easy: install appropriate fonts - which you can do by just going to a Russian website, thanks to PackageKit - and set an appropriate keyboard layout.
For languages which require input methods, it isn't that simple. There's no mechanism in Fedora, KDE or GNOME for installing and configuring the input methods for languages which require them, post distribution installation. Just installing appropriate fonts and a keyboard layout isn't enough for writing in these languages.
The post-install case is simple enough: multi-user system, new user who speaks Korean (or whichever input-method based language you like). Or, as quite often happens, someone who has an existing Fedora installation and decides to start learning Japanese or something, and wants to write it on their computer.
There could be a better solution to this written, probably, if someone had the time and dedication, but it's not simple. (I'm not entirely sure why the input methods themselves need the fonts to be installed, though).
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
adam: as i proposed above, the english default can be completed by the choice made when selecting time zone. like choosing bucharest will give romanian, choosing berlin will give (aka select) german and so on. i don't really understand why adding input methods post install would be difficult. adn, of course, a rfe should be added to bugzilla :)
On Wed, 2009-11-25 at 19:23 +0200, cornel panceac wrote:
adam: as i proposed above, the english default can be completed by the choice made when selecting time zone. like choosing bucharest will give romanian, choosing berlin will give (aka select) german and so on. i don't really understand why adding input methods post install would be difficult. adn, of course, a rfe should be added to bugzilla :)
The fact that you don't understand, doesn't mean it's not true. Er, that was a lot of nested negative :)
Please take this discussion to the appropriate spins/SIG mailing list.
It's not up to QA crew to decide what should be or not to be on spins.
JBG
On Wed, 2009-11-25 at 09:13 -0800, Adam Williamson wrote:
The distinction here is between languages which require input methods and languages which don't. If you want to add, say, Russian post-install, it's easy: install appropriate fonts - which you can do by just going to a Russian website, thanks to PackageKit - and set an appropriate keyboard layout.
That assumes that you are able to navigate the UI without Russian support in order to be able to add Russian support. Ie if somebody cannot understand English, then giving them an English-only installation and saying 'just install Russian later' may not work at all. Even if they manage to get their Russian support installed somehow, it'll leave a very bad impression.
On Wed, 2009-11-25 at 13:46 -0500, Matthias Clasen wrote:
On Wed, 2009-11-25 at 09:13 -0800, Adam Williamson wrote:
The distinction here is between languages which require input methods and languages which don't. If you want to add, say, Russian post-install, it's easy: install appropriate fonts - which you can do by just going to a Russian website, thanks to PackageKit - and set an appropriate keyboard layout.
That assumes that you are able to navigate the UI without Russian support in order to be able to add Russian support. Ie if somebody cannot understand English, then giving them an English-only installation and saying 'just install Russian later' may not work at all. Even if they manage to get their Russian support installed somehow, it'll leave a very bad impression.
Um. But you already get Russian support if you select it during installation, which someone who doesn't speak English would no doubt have done.
The use cases for adding a new language post-installation are the same for Russian as I postulated for other languages in my other post: adding a new user to a multi-user system, and a speaker of a different language starting to learn a new one. In neither of those cases would the above be a problem. I can't think of a convincing case where a user who only spoke Russian would choose to install in English and then try to add Russian post-install...
the only difference here is that adding non-input-method-based language post installation is trivial, while adding input-method-based languages post-installation is not. That is why the stuff for input-method-based languages always gets installed by default, but stuff for non-input-method-based languages doesn't.
On Wed, 2009-11-25 at 11:01 -0800, Adam Williamson wrote:
The use cases for adding a new language post-installation are the same for Russian as I postulated for other languages in my other post: adding a new user to a multi-user system, and a speaker of a different language starting to learn a new one. In neither of those cases would the above be a problem. I can't think of a convincing case where a user who only spoke Russian would choose to install in English and then try to add Russian post-install...
Right.
the only difference here is that adding non-input-method-based language post installation is trivial, while adding input-method-based languages post-installation is not. That is why the stuff for input-method-based languages always gets installed by default, but stuff for non-input-method-based languages doesn't.
Not sure that is true, actually. Or do you mean by 'non-trivial' just that you have to open gpk-application and install the language suppport group for your language ?
IIRC, there was some discussion wrt to http://www.fedoraproject.org/wiki/Features/YumLangpackPlugin about doing that automatically if a user logs in with a language whose language support group is not installed.
On Wed, 2009-11-25 at 14:10 -0500, Matthias Clasen wrote:
the only difference here is that adding non-input-method-based language post installation is trivial, while adding input-method-based languages post-installation is not. That is why the stuff for input-method-based languages always gets installed by default, but stuff for non-input-method-based languages doesn't.
Not sure that is true, actually. Or do you mean by 'non-trivial' just that you have to open gpk-application and install the language suppport group for your language ?
IIRC, there was some discussion wrt to http://www.fedoraproject.org/wiki/Features/YumLangpackPlugin about doing that automatically if a user logs in with a language whose language support group is not installed.
Last time I tried it you had to go a bit beyond that point (there was manual work involved in actually getting an input method to start in your user session). That was a while back, though, admittedly. I should test again.
On Wed, 25 Nov 2009, Rahul Sundaram wrote:
It is installed by default to provide the broadest possible locale support out of the box. For users of these locales, doing it post-installation is often difficult.
OK, but why can't these users simply check the box under languages under customization at install time? Like the users of many other languages have to do.
On Tue, Nov 24, 2009 at 7:06 PM, Jim Haynes jhhaynes@earthlink.net wrote:
On Wed, 25 Nov 2009, Rahul Sundaram wrote:
It is installed by default to provide the broadest possible locale support out of the box. For users of these locales, doing it post-installation is often difficult.
OK, but why can't these users simply check the box under languages under customization at install time? Like the users of many other languages have to do.
My guess is that their languages are not left->right languages with standard inputs.
On Nov 24, 2009, at 16:23, Jim Haynes jhhaynes@earthlink.net wrote:
Here is at least a partial list of language material that got installed unnecessarily and unwantedly when I installed F12 on a plain laptop.
bunch of packages names starting with m17n bunch of packages names starting with kacst packages names starting with un-core package names containing hangul, Canna, pinyin cjkuni-uming-fonts jomolhari-fonts khmeros-base-fonts khmeros-fonts-common abyssinica-fonts paktype-tehreer-fonts sinc-meera-fonts
Almost none of these have any dependencies requiring their presence. Would someone please investigate why all these get installed by default with recent distributions?
They come from the "fonts" group.
-- Jes
Almost none of these have any dependencies requiring
their presence. Would someone please investigate why all these get installed by default with recent distributions?
They come from the "fonts" group.
-- Jes
can all these be optional except the fonts required/recommended for the chosen location, plus english? (like uk/us requires english, athens requires greek, paris requires french, etc)
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:https://www.redhat.com/mailman/listinfo/fedora-test-list
Hi,
On Wednesday 25 of November 2009 01:23:51 Jim Haynes wrote:
Here is at least a partial list of language material that got installed unnecessarily and unwantedly when I installed F12 on a plain laptop.
I guess you are talking about bug #518395 here ... https://bugzilla.redhat.com/show_bug.cgi?id=518395
Almost none of these have any dependencies requiring their presence. Would someone please investigate why all these get installed by default with recent distributions?
because the @input-methods group is selected by default
On Wednesday 25 of November 2009 01:28:36 Rahul Sundaram wrote:
It is installed by default to provide the broadest possible locale support out of the box. For users of these locales, doing it post-installation is often difficult.
IMO, this does not answer the question why _by default_
if it is difficult doing after the installation, the users of those locales could still select it during the installation
I prefer my system using Czech by default - for me, there's no problem to select the language manually at the beginning of the installation, and I don't want anyone not speaking Czech to be forced to have complete Czech support installed by default just for my convenience not having to select the language
K.
On 11/25/2009 05:34 AM, John Summerfield wrote:
Ankur Sinha wrote:
10 seconds? And what about those of us who boot into Fedora by default and don't want to wait? If I want to use my other install, I reboot , sitting right there. No problem pressing a key to stop the timeout.
If ten seconds seem interminable, you need to get a life!
You are unnecessarily being rude and doing it quite repeatedly. You are free to disagree but you can very well do without telling the other person to get a life just because he holds a different opinion from yours.
Rahul
On Tue, Nov 24, 2009 at 03:15:34PM +0800, John Summerfield wrote:
Michal Jaegermann wrote:
On Mon, Nov 23, 2009 at 09:28:19PM -0500, Scott Robbins wrote:
As it stands, one has to hover over the escape key, trying to time it correctly.
Not weighing in with any opinion on your propositions but just try _before_ even a grub screen will show up, but not far before, to hit "Up" or "Down" arrow keys, or even "Escape", and patiently wait for what will happen.
I know all that, but several times in the past 24 hours I've found myself booting the wrong thing.
Increasing _to_ three seconds? Ten is nearer the mark, I think. Especially for those of us playing with virtual machines and windows popping up and going away
I figure 3 seconds as a compromise. :) Yes, I had forgotten about how many VMs, especially ESX (as opposed to ESXi) won't work with that--for those who run ESX in an enterprise, you have probably experienced the console not really showing anything or accepting keystrokes till the progress bar begins to show.
Too much bling at the expense of function, I say.
That's the argument we should avoid in this case, IMVHO. (V for very). I've just resigned myself to the fact that the desktop oriented distributions all want to head that way and that it seem to be what the majority of users desire.
At any rate, it's easy enough to change once one can make that first boot. In this case, I'm talking about the situations where the user *must* add something to the grub line in order to boot. Otherwise, if they aren't aware of how to edit before the first reboot, some of them wind up having to boot with a rescue CD and fix it that way. Yes, it can be edited before that first reboot, but with a target audience of desktop user, a relative few will look at the release notes or know how to do it, especially with the first installation of a new system.
Scott Robbins wrote:
I know all that, but several times in the past 24 hours I've found myself booting the wrong thing.
Increasing _to_ three seconds? Ten is nearer the mark, I think. Especially for those of us playing with virtual machines and windows popping up and going away
I figure 3 seconds as a compromise. :) Yes, I had forgotten about how many VMs, especially ESX (as opposed to ESXi) won't work with that--for those who run ESX in an enterprise, you have probably experienced the console not really showing anything or accepting keystrokes till the progress bar begins to show.
Too much bling at the expense of function, I say.
That's the argument we should avoid in this case, IMVHO. (V for very). I've just resigned myself to the fact that the desktop oriented distributions all want to head that way and that it seem to be what the majority of users desire.
I support Linux, OS X and Windows. if there's a problem booting, I need the messages the user can't see.
Bling at the expense of function is exactly the term. A pretty face is all well and good as far as it goes. That's not far, on systems I manage. If The Boss has a problem booting his lappy (he runs OS X but never mind ...), there is some prospect I can fix the problem by phone if the relevant messages are on his screen.
At any rate, it's easy enough to change once one can make that first boot. In this case, I'm talking about the situations where the user *must* add something to the grub line in order to boot. Otherwise, if they aren't aware of how to edit before the first reboot, some of them wind up having to boot with a rescue CD and fix it that way. Yes, it can be edited before that first reboot, but with a target audience of desktop user, a relative few will look at the release notes or know how to do it, especially with the first installation of a new system.
Let me guess: Always, "Oh, how pretty!" Never "What happened to all those system messages? Doesn't linux tell us what's happening any more?"
My wife, a kindergarten teacher, has never complained about those messages.
On Wed, Nov 25, 2009 at 08:16:45AM +0800, John Summerfield wrote:
Scott Robbins wrote:
Let me guess: Always, "Oh, how pretty!" Never "What happened to all those system messages? Doesn't linux tell us what's happening any more?"
My wife, a kindergarten teacher, has never complained about those messages.
Heh John, you're preachin' the choir here. ::)
At least Mac has the s option. We too support Linux (though I configuure those, so it's not an issue), Mac and MS.
As well as AIX, but they're not going for bling yet, as neaar as I can see.
Scary thought though.
On Mon, 2009-11-23 at 21:28 -0500, Scott Robbins wrote:
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system. Yeah, unless you bypass the boot menu this isn't a particularly logical perspective, but people are not that logical =) so I don't believe we'd lose much in terms of people's perceptions of Fedora as 'booting fast' or otherwise, by making such a change.
On Tue, Nov 24, 2009 at 07:07:19AM -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 21:28 -0500, Scott Robbins wrote:
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system.
Then do you think it's worth filing an RFE (a RFE? Hrrm. ok a request for enhancement) or perhaps a bug against grub? If so, I'll try to get it done in the next few days, (unless someone else feels like doing it.) :)
On Tue, 2009-11-24 at 11:26 -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 07:07:19AM -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 21:28 -0500, Scott Robbins wrote:
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system.
Then do you think it's worth filing an RFE (a RFE? Hrrm. ok a request for enhancement) or perhaps a bug against grub? If so, I'll try to get it done in the next few days, (unless someone else feels like doing it.) :)
I highly doubt the timeout will be changed. We just need to work harder on propagating the information that holding shift will get you the grub menu (or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
On Tue, Nov 24, 2009 at 08:30:08AM -0800, Jesse Keating wrote:
On Tue, 2009-11-24 at 11:26 -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 07:07:19AM -0800, Adam Williamson wrote:
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system.
I highly doubt the timeout will be changed. We just need to work harder on propagating the information that holding shift will get you the grub menu (or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
For what it's worth, testing that this morning, I held down the shift key after booting and it still just booted with a 0 timeout. So, I'm not sure that solution is universal.
(I didn't try tapping other keys, don't ahve a chance right this moment.)
On Tue, 2009-11-24 at 11:37 -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 08:30:08AM -0800, Jesse Keating wrote:
On Tue, 2009-11-24 at 11:26 -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 07:07:19AM -0800, Adam Williamson wrote:
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system.
I highly doubt the timeout will be changed. We just need to work harder on propagating the information that holding shift will get you the grub menu (or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
For what it's worth, testing that this morning, I held down the shift key after booting and it still just booted with a 0 timeout. So, I'm not sure that solution is universal.
(I didn't try tapping other keys, don't ahve a chance right this moment.)
-- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Xander: I have my pride. Okay, so I don't have a *lot* of my pride, but I have enough so that I can't do this.
Odd. Every physical machine and virt machine I've tried it has worked. I suppose if you held it down too early you may have triggered your bios' stuck key loop.
On Tue, 2009-11-24 at 09:18 -0800, Jesse Keating wrote:
For what it's worth, testing that this morning, I held down the shift key after booting and it still just booted with a 0 timeout. So, I'm not sure that solution is universal.
(I didn't try tapping other keys, don't ahve a chance right this moment.)
Odd. Every physical machine and virt machine I've tried it has worked. I suppose if you held it down too early you may have triggered your bios' stuck key loop.
On my partner's machine, the BIOS initializes the USB keyboard some time after boot. So the sequence is power on, wait some seconds while POST screen is displayed, during this time it prints some message about USB, only *after* that will any input from the keyboard be recognized. So if you just hit power and hold down a key, it won't register for any purpose.
I imagine there are other systems like that out there, and you wouldn't notice this if you used a PS/2 keyboard...
On Tue, Nov 24, 2009 at 10:24:32AM -0800, Adam Williamson wrote:
On Tue, 2009-11-24 at 09:18 -0800, Jesse Keating wrote:
(Scott wrote) :)
For what it's worth, testing that this morning, I held down the shift key after booting and it still just booted with a 0 timeout. So, I'm not sure that solution is universal.
Odd. Every physical machine and virt machine I've tried it has worked. I suppose if you held it down too early you may have triggered your bios' stuck key loop.
On my partner's machine, the BIOS initializes the USB keyboard some time after boot. So the sequence is power on, wait some seconds while POST screen is displayed, during this time it prints some message about USB, only *after* that will any input from the keyboard be recognized. So if you just hit power and hold down a key, it won't register for any purpose.
I imagine there are other systems like that out there, and you wouldn't notice this if you used a PS/2 keyboard...
I tried it on a machine that uses a KVM with USB keyboard. If that's the case (that USB keyboards might give this error) I think the F8 key is the errm, key. That is, enough people use enough different systems so that there's a reasonable chance that the shift key might not work.
My opinion, for what it's worth, is that the user shouldn't be asked to have to time it perfectly. Jesse's method, of randomly tapping F8, a habit that we've all gained from helping our families with their computer, seems not only more consistent, but more familiar to the MS refugee.
On Tue, Nov 24, 2009 at 11:37:26AM -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 08:30:08AM -0800, Jesse Keating wrote:
On Tue, 2009-11-24 at 11:26 -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 07:07:19AM -0800, Adam Williamson wrote:
I highly doubt the timeout will be changed. We just need to work harder on propagating the information that holding shift will get you the grub menu (or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
For what it's worth, testing that this morning, I held down the shift key after booting and it still just booted with a 0 timeout. So, I'm not sure that solution is universal.
Follow up--tapping F8, just like Windows (I know you said it could be any key, but I saw no key on my keyboard marked "any") :), worked perfectly.
Follow up to the other issue--although, on the forums, someone said doing yum remove cups would have taken over 200 packages, trying it on my workstation only showed it making reasonable removals, various printing packages.
Scott Robbins on 11/24/2009 11:24 AM wrote:
(I know you said it could be any key, but I saw no key on my keyboard marked "any")
.......................................________ ................................,.-‘”...............``~., ..........................,.-”.............................“-., .......................,/.......................................”:, ....................,?............................................., .................../................................................,} ................./.............................................,:`^`..} .............../..........................................,:”........./ ..............?.....__..................................:`.........../ ............./__.(.....“~-,_.........................,:`........../ .........../(_....”~,_........“~,_..................,:`........_/ ..........{.._$;_......”=,_.......“-,_.......,.-~-,},.~”;/....} ...........((.....*~_.......”=-._......“;,,./`..../”.........../ ...,,,___.`~,......“~.,..................`.....}............../ ............(....`=-,,.......`......................(......;_,,-” ............/.`~,......`-.................................../\ .............`~.*-,...................................|,./.....,__ ,,_..........}.>-._.................................|..............`=~-, .....`=~-,__......`,...............................\ ...................`=~-,,.,............................\ ................................`:,,......................`............__ .....................................`=-..................,%`>--==`` ......................................_..........._,-%.......`\ .................................,<`.._|_,-&``................`\
On 2009/11/24 08:30 (GMT-0800) Jesse Keating composed:
... or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
Why shouldn't the escape key serve to escape from keep-the-clueless-clueless&pretend-nothing-is-happening mode?
On Tue, 2009-11-24 at 13:53 -0500, Felix Miata wrote:
On 2009/11/24 08:30 (GMT-0800) Jesse Keating composed:
... or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
Why shouldn't the escape key serve to escape from keep-the-clueless-clueless&pretend-nothing-is-happening mode? -- The husband should fulfill his marital duty to his wife, and likewise the wife to her husband. 1 Corinthians 7:3 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
Perhaps it's only syslinux, but I seemed to recall the esc key having some significance in the bootloader area, such as not displaying the graphics or something. But my brain, is foggy in these areas.
Felix Miata wrote:
On 2009/11/24 08:30 (GMT-0800) Jesse Keating composed:
... or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
Why shouldn't the escape key serve to escape from keep-the-clueless-clueless&pretend-nothing-is-happening mode?
I just tested esc Works fine for me. Tested in Debian in Microsoft Virtual PC.
However, that does not excuse poor default choices.
Jesse Keating wrote:
On Tue, 2009-11-24 at 11:26 -0500, Scott Robbins wrote:
On Tue, Nov 24, 2009 at 07:07:19AM -0800, Adam Williamson wrote:
On Mon, 2009-11-23 at 21:28 -0500, Scott Robbins wrote:
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system.
Then do you think it's worth filing an RFE (a RFE? Hrrm. ok a request for enhancement) or perhaps a bug against grub? If so, I'll try to get it done in the next few days, (unless someone else feels like doing it.) :)
I highly doubt the timeout will be changed. We just need to work harder on propagating the information that holding shift will get you the grub menu (or even tapping F8 will just like on Windows, it really doesn't matter which key you hit (as long as it isn't escape)).
I know all that, and it's still a problem. Three seconds is too short, especially when there's no visible menu and no instructions.
As for word of mouth, it's my guess that many new Linux users are pretty much alone.
On Wed, Nov 25, 2009 at 08:32:51AM +0800, John Summerfield wrote:
Jesse Keating wrote:
I know all that, and it's still a problem. Three seconds is too short, especially when there's no visible menu and no instructions.
Ok, I just said 3 seconds as an arbitrary compromise. I have no trouble with longer delays. :)
However, Jesse says that he doesn't think our arguments will change this. It would be great if one could actually edit grub.conf duuring installation--don't know how trivial or non-trivial that is.
The trouble is, as I like to quote here, when making things idiot proof, you can't, as nature will always build a better idiot.
Scott Robbins wrote:
On Wed, Nov 25, 2009 at 08:32:51AM +0800, John Summerfield wrote:
Jesse Keating wrote: I know all that, and it's still a problem. Three seconds is too short, especially when there's no visible menu and no instructions.
Ok, I just said 3 seconds as an arbitrary compromise. I have no trouble with longer delays. :)
However, Jesse says that he doesn't think our arguments will change this. It would be great if one could actually edit grub.conf duuring
It's a shame RH doesn't always listen to good arguments.
installation--don't know how trivial or non-trivial that is.
It's not hard to do during kickstart installs. A script on %post.
The trouble is, as I like to quote here, when making things idiot proof, you can't, as nature will always build a better idiot.
That's okay, I just want a system that won't trip up the innocent. I don't like surprises, and I especially don't like the surprise being followed by an enforce wait, maybe of minutes, before I get another chance.
On Wed, Nov 25, 2009 at 08:49:58AM +0800, John Summerfield wrote:
Scott Robbins wrote:
On Wed, Nov 25, 2009 at 08:32:51AM +0800, John Summerfield wrote:
Jesse Keating wrote:
However, Jesse says that he doesn't think our arguments will change this. It would be great if one could actually edit grub.conf duuring
It's a shame RH doesn't always listen to good arguments.
Well, I really didn't mean to raise a furor with this one. I just wondered if it was a Just Me (TM) suggestion, but it appears not to be.
What I would say is that, as someone active on the forums, I see a of folks who have issues at boot, that could be more easily solved if they had a delay during boot. My only real run in with it was putting F10 on a server that had either SCSI or a host RAID--my memory escapes me. At that time, the released image wouldn't boot off of it and one had to add a scan something line to grub.
On the other hand, as a rule, people who deal with machines like that usually know enough to, before rebooting, go in and edit grub from the mounted image--after the first time. Well, in fairness, the first time would have caught me anyway, and I would have had to go back and google.
So, as I see it, the main purpose would be for the desktop user, as we'll assume sysadmin types will figure out a way to deal with it.
I did note that Adam, who interacts with users all over the place (if one of his bosses is reading this, he and Rahul deserve raises for putting up with frequently obnoxious users), didn't feel this was a bad idea.
I do apologize to all for doing what I was hoping to not do, raise a bikeshed thread.
On Tue, 2009-11-24 at 19:41 -0500, Scott Robbins wrote:
The trouble is, as I like to quote here, when making things idiot proof, you can't, as nature will always build a better idiot.
If you're aiming for the Douglas Adams quotation, it's "A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." :)
On Tue, Nov 24, 2009 at 07:32:53PM -0800, Adam Williamson wrote:
On Tue, 2009-11-24 at 19:41 -0500, Scott Robbins wrote:
The trouble is, as I like to quote here, when making things idiot proof, you can't, as nature will always build a better idiot.
If you're aiming for the Douglas Adams quotation, it's "A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." :)
No, I was thinking of this one--from FreeBSD's fortune. (Probably Linux's fortune as well, but I only have it on FreeBSD.)
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
-- Rich Cook
Once upon a time, Scott Robbins scottro@nyc.rr.com said:
On Tue, Nov 24, 2009 at 07:32:53PM -0800, Adam Williamson wrote:
If you're aiming for the Douglas Adams quotation, it's "A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." :)
No, I was thinking of this one--from FreeBSD's fortune. (Probably Linux's fortune as well, but I only have it on FreeBSD.)
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
-- Rich Cook
I prefer Einstein's:
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
On Tue, 2009-11-24 at 11:26 -0500, Scott Robbins wrote:
Then do you think it's worth filing an RFE (a RFE? Hrrm. ok a request for enhancement) or perhaps a bug against grub? If so, I'll try to get it done in the next few days, (unless someone else feels like doing it.) :)
I fully understand that the current behavior may be preferable for mainstream desktop use.
I also fully understand that it is not a good solution for visualization, and especially for servers.
So, how about this proposal:
Default behavior when initlevel is 3 (or just base is installed) is the good old menu with 10 second timeout.
Default behavior if runlevel is 5 (or if the main gnome, kde, xfce, moblin or whatever packages are installed) is the current behavior.
The tricky one? Revert to menu and 10 second timeout again if running as a virtual guest, even if runlevel is 5. It may be easier and/or more intuitive to leave this one out.
I guess it could be done by modifying grub.conf at shutdown if default initlevel has changed.
birger
On 2009/11/24 07:07 (GMT-0800) Adam Williamson composed:
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system.
+1
I always change my own timeouts to at least 15 seconds, and for installations for others, usually in the 8-12 range if they have only two installed OSes, longer if more.
On Tuesday 24 November 2009 10:07:19 Adam Williamson wrote:
On Mon, 2009-11-23 at 21:28 -0500, Scott Robbins wrote:
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system. Yeah, unless you bypass the boot menu this isn't a particularly logical perspective, but people are not that logical =) so I don't believe we'd lose much in terms of people's perceptions of Fedora as 'booting fast' or otherwise, by making such a change.
+1
I routinely switch to the "F2" terminal to change the grub configuration. I change the timeout to 9 because I have been bitten too many times by an install which then has bootup problems.
I have an additional incentive to change the grub.conf. I use a KVM switch and I need to add "psmouse.proto=imps" for my wheel-trackball to work properly.
Gene
Adam Williamson wrote:
On Mon, 2009-11-23 at 21:28 -0500, Scott Robbins wrote:
I really don't see a good reason not to have it. I know that Windows refugees like quick boots, but don't see 3 seconds making that big a difference.
(Dinosaur that I am, I've always thought that there is too much emphasis on quick boots with pretty splash screens, but that's just the old vs. the new and all that rot.)
FWIW, I would support this. As a data point, in my experience people don't count the bootloader time in deciding if a system 'boots fast' or not. If they see a fast boot from _after_ the bootloader to desktop, they consider it to be a fast booting system. Yeah, unless you bypass the boot menu this isn't a particularly logical perspective, but people are not that logical =) so I don't believe we'd lose much in terms of people's perceptions of Fedora as 'booting fast' or otherwise, by making such a change.
Sees to me sensible to count boot time from when the choice of what to boot is made.
If the menu's visible and the user is asked to make a choice, there's a clear time from which to measure.
To me, the long wait is not actually the time to boot, but the time to run the initialisation scripts, checking filesystems and starting services and such.
I know Mrs S the Kindergarten teacher doesn't have such a discriminating view though.
I'm wondering if it's worth considering increasing grub's default timeout to 3 seconds or so. As it stands, one has to hover over the escape key, trying to time it correctly. (Or, if they're as lazy as I am, before rebooting, go to another terminal and edit the mounted grub.config.)
+1 for increasing the default timeout
there were mentioned systems, where the graphics does not show up early enough ... well, on my system, BIOS seems to "eat" some of the early keypresses, the shift key method is not an option
K.
Went ahead and filed a bug/rfe for this just to get it over with. Go ahead and add your comments/thoughts there to help with email flow and to make it officially discussed? LOL
https://bugzilla.redhat.com/show_bug.cgi?id=541315
On Wed, Nov 25, 2009 at 07:51:48AM -0600, Mike Chambers wrote:
Went ahead and filed a bug/rfe for this just to get it over with. Go ahead and add your comments/thoughts there to help with email flow and to make it officially discussed? LOL
Thanks Mike. I might even mention this one on the forums. The users who bother to get a bugzilla account are (usually) diligent enough to add intelligent comments.
-
"Jóhann B. Guðmundsson" -
Adam Williamson -
Ankur Sinha -
Antonio Olivares -
Bill Nottingham -
Birger Monsen -
Bruno Wolff III -
Chris Adams -
cornel panceac -
Felix Miata -
Gene Czarcinski -
Jesse Keating -
Jesse Keating -
Jim Haynes -
John Summerfield -
Karel Volný -
Markku Kolkka -
Matthias Clasen -
Michael Cronenworth -
Michal Jaegermann -
Mike Chambers -
Rahul Sundaram -
Ralf Corsepius -
Richard Ryniker -
Rick Stevens -
Scott Robbins -
Stephen John Smoogen