Reproducible w3m bug
This is a quick heads up about a w3m bug that was reported many years ago and has not seen any responses. As w3m is installed by default and the bug has easy steps to reproduce the problem I'm making a last ditch effort to raise the bugs visibility: https://bugs.launchpad.net/ubuntu/+source/w3m/+bug/123876 A brief question - is this the sort of thing that people _don't_ want to hear about? Whenever I am drowned in Is this still a problem? emails (and bear in mind it takes ages to type up these reports in the suggested style precisely so OTHERS can reproduce the problem) it occurs to me that perhaps I've misunderstood the purpose of the Ubuntu bug tracker (it seems to most punish those people who spend the most time on bugs). The most vivid example was this: https://bugs.launchpad.net/ubuntu/+source/rrootage/+bug/261189 (there was even a patch and an explanation). As the years go by I am finally realising that I am no longer willing to spend considerable effort only to see it wasted. I think it would help immensely if bug standards were lowered so that when nothing happens the contributor does not feel like anything of significance has been given (in terms of time/effort). Alternatively it should be made clear that Ubuntu is only capable of repackaging upstream and that if you aren't reporting bugs upstream then all you are doing is entering a is it still there? cycle until the issue is fixed upstream or you run out of time. -- Sitsofe -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Reproducible w3m bug
Martin Olsson mnemo at minimum.se writes: For the first bug I recommend that you upstream it. There is not a lot That's an extremely useful reply and is the sort of information I could have done with a few years ago. I won't follow that suggestion at the moment though as prior to my original post I checked and upstream of w3m is not looking to healthy - http://www.sic.med.tohoku.ac.jp/~satodai/w3m-dev-en/200903.month/1112.html . of people in the Ubuntu project that fix bugs themselves, most people spend their time on packaging and integration (even though some people also do upstream work separately from their Ubuntu work). Filing an Ubuntu bug is nice for tracking (in case we have time to cherry pick it for release or maybe even do an SRU) but the bug report that really counts is the upstream one for sure. That said, there is also packages that are unmaintained and just as you point out sometimes it's just a waste of time; the fix is just to be careful about where specifically to invest your time. That seems very reasonable but in that case can such packages where it is not worth reporting bugs be marked as such? There's nothing worse than finding a problem and then tracking it for years... That sort of wastage can be headed off by a simple Ubuntu only repackages this particular product - we will not do any development or passing of issues upstream on it. It raises a question as to whether it makes sense for those types of product to be in the Ubuntu launchpad at all (other than for following upstream issues). Keep in mind that different packages have different number of users that are interested in having it fixed. Suppose Linux has 1% market share and that w3m has 1% of share among Linux users, now that's not a lot of people. People needs to prioritize between lots of different bugs/work and in that case fixing bugs in Firefox/Xorg/kernel (which is used by far more people) is probably more useful. It's not that people don't care about your bugs, it's just that there is so many of them that choices have to be made and priorities have to be set. That's reasonable too but w3m is installed by default and if it's used by so few perhaps it shouldn't be there by default - it strikes me as unsafe to be putting packages that can't be supported on people's systems out of the box. Wouldn't it be better to migrate to products that were actively maintained? Your comment clearly stands for rrootage though. And does Ubuntu really fix Xorg and kernel bugs above others? I had a kernel bug that remained open for over a year which did not receive much attention - https://bugs.launchpad.net/ubuntu/hardy/+source/linux/+bug/86099 . For me 9.04 is currently unusable on my EeePC 900 due to a Xorg / kernel issue - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/349314 which is currently unresolved. Does Ubuntu have developers doing active (new?) development to fix it or is Ubuntu in a similar situation to others where it can only wait for a fix to come from the Intel Xorg folks? As for the second bug, learning how to analyze and fix bugs is a long and hard process. It's not just about learning the immensely complicated ins and outs of gdb, VCS tools and compilers but it's also about learning the how the community works. Just as there is a technical learning curve there is also a community learning curve where you learn where to file bugs, who is the right person to ask, what info to include, which bugs are worth your time and so on. Both of these learning curves are in the marathon rather than sprint department so don't stretch yourself too far because you can't win on strength alone, you _need_ to be patient. I've been waiting for years on some bugs. What sort of period is the marathon we are we talking about taking place? The best way to do it is to make sure you work on stuff you think it _fun_ and interesting to mess around with, otherwise it just won't work. I guess that's the major point. What I'm trying to say is providing extra information will help people gauge the fun factor better. Helping to make a product better seems fun but not getting feedback for years or repeatedly asked to check whether a well described bug is still there is not fun. If people know the later is going to happen they will be able to act in a better fashion from the outset. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu boot speed fall in Hardy
posted mailed (``-_-´´) -- Fernando wrote: Olá Mackenzie e a todos. On Wednesday 14 May 2008 05:14:51 Mackenzie Morgan wrote: The results of using Bootchart to map the GNOME startup process, for the many users that did it, consistently showed gnome-panel as the culprit. How does one use bootchart to map GNOME? mine ends on X11. I just did a quick edit of /etc/init.d/stop-bootchart and added a sleep 30s just after start) . -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu boot speed fall in Hardy
On Sun, 2008-05-11 at 03:37 -0400, Mackenzie Morgan wrote: On Sun, 2008-05-11 at 08:28 +0100, Sitsofe Wheeler wrote: Do you have a link to the discussion? Were things suposed to be any better in Hardy? https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/128803 Someone said they'd heard it was fixed in Hardy, but subscribers say that is far from the case. Hmm I think that bug is rather different to what I'm reporting. That seems to be about GNOME being abnormally slow to the point where it takes minutes to start. Further, it seems to have become unfocused and extremely large potentially covering lots different issues. Sadly I don't think a bug like that can be resolved because too few can do the testing and report the information that would show where the real problem lies... -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu boot speed fall in Hardy
On Sat, 2008-05-10 at 17:34 +0200, Markus Hitter wrote: Am 10.05.2008 um 11:58 schrieb Sitsofe Wheeler: I've noticed that Ubuntu's boot speed seems to have taken a fall in Hardy. How would one notice? Is Hardys hibernating/standby still so flaky one is forced to shut down the computer more than once a month? You notice if you ever start a live CD (although really that's a different case). I notice because suspend to ram has never worked on my machine (there's already a year old bug in launchpad about it) and I like to know that any problems I find aren't due to a bad resume. Then there are machines using the open source NVIDIA drivers can't resume after suspend to ram in X due to a lack of information - http://katzj.livejournal.com/407566.html?thread=350990#t350990 . There are also machines that are used for shared logins. While they might not be shutdown you are affected by the time it takes for your desktop to appear after GDM... Maybe such questions appear not serious to some and maybe it even looks like I want to disencourage you, but I'd be much more concerned about standby stability as about boot times. Hey by all means fix my suspend to ram / resume issue - if you want to know more let me know. However there are always going to be times when you do a cold boot (e.g. after doing a kernel upgrade) and some people just prefer doing shutdowns. Ubuntu has focused on speedy boots in the past so it seems a shame to quietly erode that work. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu boot speed fall in Hardy
On Sat, 2008-05-10 at 09:48 -0400, Mackenzie Morgan wrote: Issues with slow-loading GNOME popped up in Gutsy. There's been a lot of discussion on that bug. It seems the gnome-panel just hangs for a while opening and closing something. Do you have a link to the discussion? Were things suposed to be any better in Hardy? -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu boot speed fall in Hardy
On Sat, 2008-05-10 at 12:53 -0700, Bryce Harrington wrote: It's curious Fedora 9 showed such poor results compared with Ubuntu (and compared with Fedora 8), given that they are listing fast Xorg boot as a feature. http://fedoraproject.org/wiki/Features/OneSecondX I wouldn't say it is surprising compared to Ubuntu - if you look at the Fedora chart ( the dates link to charts like https://wiki.ubuntu.com/BootCharting?action=AttachFiledo=gettarget=SitsofeWheeler-fedora-9-beta.png ) you can see the machine is massively CPU bound throughout and peak I/O throughput isn't that great (at least compared to distros with some sort of preload/readahead although one would need test the benefit of that versus the time it takes to do). Additionally some of its boot services seem to do a fair amount of writing to the disk causing kjournald to use up IO. Now Fedora are well known for including huge amounts of debugging in their kernels while the distro is in alpha/beta testing so perhaps this isn't yet representative of the true final speed. Compared to Fedora 8... something funny seems to be happening around udevsettle though (9s seconds versus 14s) and the time it takes for kernel to start appears to be longer in the F9 chart. Further the new gdm just isn't as fast at starting autologin as the old gdm (but you can't see that on the chart). Unlike the chart for Hardy though, there is only one small gap of no CPU/IO usage once userland has started so the long times don't seem to be predominantly due to a slow X (although Xorg is started twice so X speed will matter more in Fedora than Ubuntu). Rather, Fedora just seems to start and do a huge amount. It's definitely a distro for higher spec machines capable of crunching through stuff at a better. Looking at the services it starts it seems geared towards more traditional *nix corporate desktops / servers. I'll be interested to see if the fast Xorg boot stuff in the upcoming Xorg 1.5 will boost our boot numbers, or if the Xorg boot time just gets lost in the noise. I should think it would help (at least in the time to the clock test rather than to gdm) as GNOME tasks should be kicked off sooner. However fake gains could be made by allowing GNOME to be responsive even when the clock (which is often the last applet to load) hasn't finished loading. However if more GNOME utilities need to be started any gains will be washed away in the autologin case. Some more boot comparisons can be seen on http://www.harald-hoyer.de/linux/boot-time-distro-comparison . -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Ubuntu boot speed fall in Hardy
Hi, I've noticed that Ubuntu's boot speed seems to have taken a fall in Hardy. Anecdotally I believe that Gutsy was the fastest but from a viewable stats perspective the fall can be seen in Feisty versus Hardy on https://wiki.ubuntu.com/BootCharting#head-dca0372aa8fd490a9717ad0c72c9b400c236a581 . While not as slow as other distros it is a shame to see things slow down a bit. Of special interest to me is the fall in time to usable auto-login desktop case as this is something I use regularly. It seems that modern Ubuntu simply has more to do/start after a user logs in... Before I forget back in the Gutsy days I ran various timing tests to see what would help boot speed. I think I found that doing a profile boot helped the most (although you may never get back the time it took to do the profile boot :) followed by disabling appropriate modules in /etc/default/linux-restricted-modules-common (if you use restricted drivers) and finally a very slight improvement by not starting services for things you don't have (e.g. this machine doesn't have bluetooth) but one must take care when doing this. The difference between disabling services using /etc/default/ and update-rc.d remove seemed very small. I had more benefit tuning readahead to read files that were used during user log in too. Shutdown speed also seems to have fallen in Hardy with gdm often hanging for 30 seconds when it stopped and the first stage of the shutdown animation is often not displayed. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Launchpad bug retesting
Many bugs reported turn out to be hit and run reports where something is filed and never followed up. As such it is good that bugs are aggressively closed where possibly to prevent launchpad cluttering up. Unfortunately there are scenarios where this becomes problematic. These days I see people romping through launchpad asking for bugs to be retested on pre-releases of Ubuntu (which may be months away from their final release). These bugs are stuffed into a Incomplete state and then one month later closed (due to lack of response) before the final release of Ubuntu is ever released. Sometimes these are bugs with very thorough descriptions which are reproducible all the time so there is nothing stopping the launchpad gardener checking the problem. A flip side of this is that sometimes a bug is reported and again at some point before the next major release a request for testing is put out. The reporter goes away, tries the pre-release and tests the bug and reports back. Then another request to test another pre-release comes up because maybe it's been fixed but without any firm reason for this other than a minor point release change. Thus the bug is turned into a game of how many pre-releases the reporter can keep up with. The problem with all these requests for retesting is that the more bugs someone files the more retests they will be asked to do thus punishing those who file real bugs that are not resolved. In order to keep bugs.launchpad.net manageable perhaps collateral damage is inevitable but if you are expecting people to be repeatedly testing things every month (or see their bug closed) then it would be nice if this was stated up front. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Spelling library consolidation
On Fri, 2008-02-01 at 11:11 +0100, Szilveszter Farkas wrote: I've just discovered an old blueprint on Launchpad[0] and the corresponding wiki page[1], that Ubuntu was planning to consolidate I also filed a bug alluding to this a few years ago: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/3219 . -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing
On Mon, 2007-10-01 at 20:13 +0200, Thilo Six wrote: There are two parts of computer users. The first one do backups, and second ones never had a harddisc failure. Here's a variation on your theme. There are three types of people in the world: Those who don't do backups. Those who do backups. Those who do backups and test them. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: regular fsck runs are too disturbing
On Thu, 2007-09-27 at 09:46 +0200, Waldemar Kornewald wrote: I once reported a bug about this, but Justin Wray suggested that I discuss this on a mailing list, first. Curious. I filed a bug about disabling periodic fscks (as most other operating system like Windows 95 and above along with OSX don't do them) over on https://bugs.launchpad.net/ubuntu/+source/partman-ext3/+bug/3581 back in October 2005. I am starting to wonder if this was the correct thing to do... -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: State of cleanup-audio-jumble
On Tue, 2007-07-24 at 01:49 -0400, Daniel T. Chen wrote: Hi, On Mon, 2007-07-23 at 15:15 +0200, Alexandre Franke wrote: pulseaudio instead. As far as I can see, esd is still used in Feisty and I wonder if someone still cares about it. Moreover pulseaudio esd will still be used in gutsy. Whether it's also used in gutsy+1 (the next LTS) remains in the air. PulseAudio should be a fairly straightforward drop-in in its current state; Edubuntu has been using it since feisty. libflashsupport is the most significant missing piece, and pavucontrol should be promoted to main. I thought PulseAudio had gained libflashsupport already - http://pulseaudio.vdbonline.net/libflashsupport/ ? -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Disabled Intel SATA bug policy (Bug #117314)
On Mon, 2007-06-04 at 09:37 +0100, Scott James Remnant wrote: Could you point out where this was advocated as a fix? The only supported configuration for /etc/fstab is using UUID= and LABEL= for all devices. OK, here's a bug where the reporter advocated a rename to /dev/h??? - https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/117373 . -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Disabled Intel SATA bug policy (Bug #117314)
On Mon, 2007-06-04 at 09:37 +0100, Scott James Remnant wrote: On Sun, 2007-06-03 at 11:43 +0100, Sitsofe Wheeler wrote: Are people that relabeled their partitions with /dev/h??? syntax (rather than UUIDs) going to get notice that things are going back the other way? Are people whose systems were allegedly fixed going to be forewarned that they may be broken again? Could you point out where this was advocated as a fix? The only supported configuration for /etc/fstab is using UUID= and LABEL= for all devices. The only place I can currently find that people actively advocating this is the forum (e.g. http://ubuntuforums.org/showthread.php?t=456662page=6 ). It's hard to retrace all the pages I've seen though as this topic has become very popular and consequently I've looked at a lot of different pages related to it. Hard-coded names such as /dev/hd?? and /dev/sda?? are inherently unstable, as they are prone to change by not just driver changes, but also hardware changes inside the computer (or even timing changes based on sun spots). I'm aware of this but those pesky /dev/blockdev names have infested Ubuntu in a deep seated way. The machine I am using at the moment had a fresh install of Feisty (via the alternate CD) but has a resume device set to RESUME=/dev/hda6 in /etc/initramfs-tools/conf.d/resume . On the same machine all the partitions have UUIDs, but the CDROM/DVD device is still being referred by /dev/hdc (nor is referencing CD/DVD/Floppy disk drives in this fashion uncommon with fresh Feisty installs). I've suggested people use the /dev/cdrom symlink in bugs like https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/118188 but I have no idea whether this advice is good or whether it produces unwanted side effects. Further, /dev/blockdev names still have a hold on hddtemp ( https://bugs.launchpad.net/ubuntu/+source/hddtemp/+bug/117621 ) along with dmcrypt+LUKS ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117979 ) not to mention things like /boot/grub/device.map along with who knows what else. There is also an issue surrounding swap and UUIDs ( https://bugs.launchpad.net/bugs/118199 ). I've just done some more searching and I neither of the two release notes for either Edgy ( https://wiki.ubuntu.com/EdgyReleaseNotes ) nor Feisty ( http://www.ubuntu.com/getubuntu/releasenotes/704 ) mention that /dev/blockdev names should no be used in configuration files. Contrast this with the latest Fedora release notes (http://docs.fedoraproject.org/release-notes/f7/en_US/sn-Installer.html#id3152635 ). I mentioned it in my previous mail but I'm going to ask again - is it possible to have a second set of release notes that has similar technical information to the Fedora release notes within it? -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Release notes should warn against installing Ubuntu on old machines
On Wed, 2007-03-07 at 00:27 -0500, Michael R. Head wrote: On Wed, 2007-03-07 at 16:09 +1100, David Dean wrote: From memory the old way to deal with this was to create a tiny slice at the start of the disk, and install boot there - whether the user This was the so called /boot partition. Useful for working around hardware deficiencies. Works great until you 2 or 3 2.6 kernels installed (which is entirely possible if you get a kernel security update or two). That 10MB will quickly be overcome and cause bizarre package installation failures, That's why in this case I am not asking for a /boot partition to be created (Fedora has a 100MB /boot and manages this by deleting all but the currently running kernel when a new kernel is installed). See https://launchpad.net/ubuntu/+source/grub-installer/+bug/9006 for that request. We are too late into Feisty's testing period for such invasive change. The best we can hop for now is to warn people about potential problems as soon as possible. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Desktop responsiveness in Feisty (vs Edgy)
Hi, Has there been a change to which preemption patches are included in the default Ubuntu kernel used in Feisty? I ask because I seem to have noticed far more stutters (both when sound is played and when moving things like the mouse pointer in X) and periods of up to half a second where interaction is not possible. My sound card is an SBLive with hardware mixing and it was quite rare for sound to be interrupted. My desktop is an ageing Athlon 850 and I don't do anything that requires realtime response (like audio editing). -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Desktop responsiveness in Feisty (vs Edgy)
On Tue, 2007-03-06 at 04:28 -0500, Daniel T. Chen wrote: On Tue, 2007-03-06 at 08:37 +, Sitsofe Wheeler wrote: Has there been a change to which preemption patches are included in the default Ubuntu kernel used in Feisty? I ask because I seem to have noticed far more stutters (both when sound is played and when moving things like the mouse pointer in X) and periods of up to half a second where interaction is not possible. Similar symptoms were reported on local systems when esound was enabled. esound is certainly enabled but does that also affect X mouse cursor movement? Also the sound card does hardware mixing and I'm sure the hold ups were never this bad on Edgy. It's not locking up every 5 minutes but you do notice it on startup just after booting finishes and sometimes when you go to shutdown along with when the computer is under load (e.g. computing package dependencies). -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Desktop responsiveness in Feisty (vs Edgy)
On Tue, 2007-03-06 at 16:37 -0500, Daniel T. Chen wrote: Are all of your detected audio devices capable of hardware muxing? Perhaps not the microphone but all output devices are, yes (just the one SBLive sound card). -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Release notes should warn against installing Ubuntu on old machines
Ubuntu can have serious problem when installed on machines whose BIOSes cannot read files past the 1023rd cylinder. This is a well known problem and there have been a fair few reports of this problem listed on the forums as well as within launchpad. One of the more recent version of these reports was marked as rejected: https://launchpad.net/ubuntu/+bug/88633 I feel this is wrong as there is no indication that Ubuntu is a poor fit for old machines. The installer should check to see if the BIOS is older than 2001 and if so, put up a warning saying that Ubuntu is not suitable for such an old system. Additionally, the release notes should also mention that Ubuntu is not designed for old systems to save people the negative experience of going all the way through the install and then being unable to boot the machine at the end. Perhaps a force option can be used at grub/isolinux for those who want to go ahead anyway... -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
