Comment 271 for bug 129910

@ andrew
> You have to understand that we normally don't fix bugs in a version that
> was released.

Then why do we claim that we "support" any release? I really hope that
you were speaking off-the-cuff. Deciding not to fix bugs (even with
the exception of security fixes) means that we DON'T support the
release, and every release is at the end of life the day it's
released.

The wiki page on Time Based Releases
(https://wiki.ubuntu.com/TimeBasedReleases) describes a policy that
is, fortunately, somewhat more flexible:

"What kind of changes are appropriate to make in a released version of Ubuntu?

"We only update packages for specific types of changes:
    * Fixes for security vulnerabilities
    * Other high-impact bug fixes, for example those which cause data loss
    * Very conservative, unintrusive bug fixes with substantial
benefit and very low risk"

This bug clearly falls into the second category, and I would argue it
falls into the third category as well.

I can't think of many more high-impact bugs than a broken console.
Despite our best efforts to making it more "user friendly", Ubuntu and
every other GNU/Linux system, needs the command line. This is
especially true when dealing with problems with graphics cards and
monitors, because the command line is all you have if you can't get X
to operate correctly.

My users run into this relatively frequently. Example:
Example 1: Pancho buys a slick new IYCC "Laredo Cuadrado" desktop
computer with 19" widescreen, preinstalled with Ubuntu and
preconfigured for the graphics card and monitor. He gives it to Dario,
his 15 year old son, who sets it up in his room. The family decides
they want to play an online game in the living room, so Dario
disconnects the monitor and carries it by the integrated front panel
handle to the living room and hooks it up to the 30" LCD
monitor/television in the living room. When he fires it up, everything
boots up, but when X starts, the monitor gives and "Out of Range"
error, meaning not even displayconfig-gtk is visible. He wants to use
the console to run "dpkg-reconfigure xserver-xorg", but alas, the
console doesn't show anything, just a black screen staring at him.

Example 2: Laredo Trucking Co. buys three Laredo Cuadrado desktops for
their offices, again with the 19" screens. The cleaning guy knocks
over the monitor one night, leaving it in a dozen pieces on the floor.
After cleaning it up, the boss sends his secretary out to Best Buy to
buy a monitor. She picks up another LCD monitor, but they were out of
19" wide screens, so she gets a 17" regular 4x3 LCD monitor. They fire
it up, but X won't start. The IT guy wants to configure the xserver,
but can't because the console doesn't work.

Example 3: Ubuntu ships an updated version of a driver, xserver-xorg,
displayconfig-gtk, or any of a number of packages needed to make X
work. Unfortunately, the update overwrites a configuration file or has
some other bug that prevents X from starting. Again, the console is
broken, so there's not much he can do.

Example 4: The upgrade script from Gutsy to Hardy breaks the computer
(like the script for Kubuntu broke many computers upgrading from
Feisty to Gutsy). Getting the computer working again merely requires
running "aptitude update" and "aptitude full-upgrade" from the command
line, but the console is invisible, so the user has to first fix the
console to be able to fix his system.

This bug also meets the second criteria, because a conservative,
unobtrusive, low-risk fix is available. From what I've seen here,
using the vesafb works very well, even with proprietary graphics
drivers. But assuming arguendo that they conflict and further assuming
that the community decided to let the proprietary tail wag the
open-source dog, it would not be too terribly hard to come up with
SOME sort of fix that at the very least allowed the user to work on
the console.

If the powers that be STILL have a problem with a default boot that
allows the user to operate a console when X is running, we could at
least make some accomodation by creating an option in GRUB that boots
up the system into a command line environment (with networking and
other background services loaded as usual), but doesn't start X. Then
the user could work on the command line to the user's content and if
necessary, execute "startx" to load X.

(BTW, if you really, really don't think the console is worth keeping,
then it would make more sense not to load tty 1 through 6 in the first
place. Running six tty sessions uses up memory and state, and loading
them slows down booting. If the console has no benefit, then there is
no reason to pay for it in system resources.)

I'm at a loss to understand why the kernel team is so adamently
hostile to getting the console working.

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
(956) 857-1172
<email address hidden>