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 +0000, 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
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
Re: Release notes should warn against installing Ubuntu on old machines
Matt, your reply is the best so far - it has addressed every point. On Wed, 2007-03-07 at 15:08 -0800, Matt Zimmerman wrote: > Most GRUB failure modes only provide a numeric error code, and so it's > difficult to determine the cause of the issue. You may see many similar > reports, but it isn't necessarily true that they're all caused by a > particular BIOS issue. We know that there are situations where Ubuntu will > install to the hard drive and then fail to boot, but the range of causes and > solutions is not very well understood by the development team. > > Your proposed solution, to draw an arbitrary cutoff point and discourage > users from using Ubuntu on systems over a certain age, would unnecessarily > exclude a large number of systems capable of running Ubuntu without a > problem. I have personally run Ubuntu on several systems older than 2001, > and of various ages with hard drives with more than 1024 cylinders, and not > had a problem. I am slowly becoming aware of the complexity of these "unable to boot" issues. > Whether the system can boot a default Ubuntu configuration depends on a > number of factors other than the number of cylinders on the disk, such as > whether the BIOS supports LBA mode. Furthermore, the solutions to the > problem also vary. Often, changing the BIOS configuration is sufficient. > Sometimes (such as when another installed operating system is relying on the > current BIOS configuration), this is not an option. Indeed. Even creating a /boot partition is not an option in such circumstances. > A much better step would be to develop a test which could detect whether the > system has this problem. As a first step, this could be used in the > installer to warn the user of a potential problem before they take any > destructive steps. Later, it may be possible to work around the problem > automatically by using a different partition layout, so that the kernel is > always near the beginning of the disk, in which case the earlier work to > detect it would continue to be useful. > > We know that Ubuntu, in various flavours and configurations, *is* suitable > for older systems, so we should not exclude them out of hand. I believe that is a fantastic long term solution but I would be amazed if it could be developed before Feisty is released. I guess the only suggestion that is currently feasible is a warning within the release notes (this can serve as a hint to more expert users who wish to live the problems that creating a /boot may potentially create). I can only imagine the frustration of sitting through an install only to have the thing not boot at the end and my guess is that the number instances when this happens increases the older the BIOS. (PS: Can you also list the minimum requirements in the release notes too?) -- 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 Policy on binary driver bugs
Hello, After reading yet another series of threads regarding the NVIDIA binary drivers I would like to ask: "What the Ubuntu position is towards binary driver bugs?". Does Ubuntu take a similar stance to Red Hat whereupon the moment you taint your kernel your bug will be closed and you will be directed towards NVIDIA for help ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73733 / http://fedorasolved.org/video-solutions/3rd-pty-video ) or is Ubuntu going invite NVIDIA engineers to review NVIDIA related bugs within Launchpad the way Novell/SUSE currently does (e.g. https://bugzilla.novell.com/show_bug.cgi?id=147009 - Andy Ritger works for NVIDIA)? Perhaps Ubuntu is going to encourage a halfway house where people are requested to post over in the bugs.freedesktop.org closed NVIDIA component? I only ask out of curiosity. I am a Geforce 1 owner who was mostly ( http://www.uwsg.iu.edu/hypermail/linux/kernel/0108.0/1127.html ) unconcerned all the way up until NVIDIA marked my card legacy in their "unified" drivers. Things haven't been quite as sweet since and I have seen the confusion the "new-legacy" 96xx drivers have caused on another distribution in my workplace. However I will hastily add that I am not ungrateful for the support NVIDIA gives to legacy hardware - I gather sometimes binary driver vendors simply stop supporting old hardware entirely in their drivers... NVIDIA seem to fix bugs in their drivers while your card is "non-legacy" but they will not necessarily fix every bug and it's not clear whether a reported bug will ever be fixed once your card becomes legacy. In my case the rate of new legacy releases has slowed considerably (with regard to kernel releases) and it is unclear whether features which were unstable in the last driver (like RenderAccel and Composite) will be fixed. It's also not clear whether the legacy drivers were affected by the same Render exploit in the new drivers a while back. I suspect it's too much to ask for support of new Xorg features like texture_to_pixmap but I kinda hope NVIDIA will add support for it in their 71xx series. At any rate this only affects Ubuntu if these binary only bugs are going to be seen by NVIDIA (since to paraphrase someone else "nobody else can help"). -- 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: Bug #96084
On Sat, 2007-04-28 at 12:44 +0100, Michael wrote: > Which prompts the question: why isn't ndiswrapper included in the Feisty CD? Well it's not all that supportable (you are at the mercy of whoever wrote the Windows driver) and doesn't it need the user the extract the Windows driver before it can be used? -- 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: cupsd in infinite loop, feisty amd64 canon
On Sat, 2007-05-12 at 17:55 +0200, Daniele wrote: > I had a problem with my cups daemon. You might be better off posting your bug report on https://bugs.launchpad.net/ ... -- 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
Disabled Intel SATA bug policy (Bug #117314)
Hi, The "SATA disk is in PATA mode with kernel 2.6.20-16-generic (piix claiming SATA controller on ICH4/ICH5 Intel chipsets)" aka "the great renaming" ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117314 ) has been around for a week and it appears that the patch that led to this is going to be reversed. However it is unclear what the current advice/policy surrounding this issue is. 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? Is there going to a note indicating how a kernel option can be used to disable ata_piix? What does it mean when an update is -security? Is the updated kernel reversing this patch going to be in -security even though it won't be a security fix? Will advanced warning of this update be passed through the forums? What is the current advice to people to people who haven't updated to 2.6.20-15 yet - wait until 2.6.20-17 is released? What is the policy on the various spinoff/variant bugs like https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996 , https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117447 and https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/117413 ? Should piix problems just be closed once the updated kernel is out and the problems are hidden by the use of the SATA driver? Will the release notes (http://www.ubuntu.com/getubuntu/releasenotes/704 ) be updated to warn about this kernel? Is it possible to have a second more technical release notes/errata page in the style of http://docs.fedoraproject.org/release-notes/f7/en_US/ (the F7 page talks about how partitions must be labeled)? What systems were affected by this? I fear that there may be some additional subset of ICH3, ICH6 and ICH7 owners also affected - is this right? I'm reposting here because I'm out of ideas about where else to raise this (I've tried IRC a few times since Martin's comment but I think I've been around at the wrong time). If this is the wrong list I apologise - please point me in the right direction. -- 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=456662&page=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/ 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/ 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/ 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: 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: 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
SVG Ubuntu logo, Company/Project vector logos
I've just stumbled across this page http://en.wikipedia.org/wiki/Image_talk:Ubuntu_Logo.svg on Wikipedia which is debating whether the Ubuntu SVG logo should be pulled. It would be good if someone from Ubuntu could weigh in on this one. Additionally I just made this SVG Brief Logo Guide detailing some of SVG benefits and pitfalls with regard to logos: http://sucs.org/~sits/logo/brieflogoguide.svg (it doesn't look quite right in Firefox but looks fine in Inkscape). This is rather important because more and more logos are being turned into SVGs on places like Wikipedia or winding up on sites like http://www.brandsoftheworld.com/ . If you are running an open source program with a vector logo (or even an open source company) you need to be aware that this is happening and help people along. The common problems seem to be: Failing to link to the logo usage guidelines. Guidelines are not linked to or in some extreme cases no guidelines cannot be found in a Google search. This also ties in with a the difficulty of finding web pages detailing how to get official vector versions of the logo. An example of a good logo page is http://marketing.openoffice.org/art/galleries/marketing/logos/ . Thinking that a vector version of your logo won't become public. If you ever put a vector form of your logo in a PDF you may have already lost. People are converting SVG logos out of any vector file they can find. In some extreme cases some people may trace a bitmap of the logo from scratch to make an SVG of it. At this point various dimensions or attributes might be missing or wrong. Details like trademarks, registered marks or copyright logos are vanishing away on reproduced logos. It makes sense for these details to already be in your SVG logo to reduce the chances of them going missing in duplicates. Current versions of the logo are too complicated for programs like Firefox to display. This can lead to recreation of the logo by third parties. It's worth checking that these recreations are faithful enough. The vector logo problem is definitely not going to go away and I suspect the best thing a company or project can do is ensure that the SVG version of its logo is faithful enough for web and minor print use. The special ink EPS files can still be kept private but I suspect those SVGs will be seen in more as time (and monitors) move on. -- 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
gvim menu icon is hidden
Over in https://bugs.launchpad.net/ubuntu/+source/vim/+bug/3222 there is a bug concerning gvim and it's hidden by default menu icon. I feel this change is unnecessary because gvim is not installed by default and so long as its desktop item is only installed when gvim is there is no harm. Additionally, in the current state, upon installing gvim using Add/Remove you will be told to look for a menu item that won't exist (see http://launchpadlibrarian.net/7332788/post-gnome-vim-install.png for a screenshot of this). Given that the bug has been opened and closed several times I'm posting here to see whether it is an issue that should be fixed. -- 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
Thinkpad T60 power usage
I've been sitting on some power results for a while because I haven't had time to tidy them up but by posting them perhaps they will turn out to be useful to someone. This email is quite long and the results are somewhat raw and in no particular order. Rough conclusions are at the end. On Linux I used powertop and on Windows I used the Lenovo battery tool to measure draw when on battery with no mains. A "watt meter plug" was used to measure draw through the mains with no battery physically in the laptop. The laptop was a borrowed T60 laptop with an Intel graphics card and a 1024x768 flat screen. The purpose of the exercise was to give me a better idea of what draw to expect under particular conditions. I didn't test especially rigorously but I did try and let readings settle and where I would get multiple readings I would err on the side of least power if I could reproduce the readings or put a range. Unless indicated otherwise, results here are for a Gutsy Tribe 5 install on the Linux side and an IBM/Lenovo customised Windows XP Professional on the Windows side. I almost certainly won't do any extra tests as I simply don't have the time (all this has had to happen in my unpaid spare time). However others are free to post their results and I am happy to discuss what I did to get a particular result. Linux power usage (In the following results a heading will continue apply unless overridden by a later heading) All wake up hog programs killed, laptop mode on, backlight off powersave governor max 16.5 wakeups per second, 11W powersave governor ondemand 21.7 wakeups per second, 10.9W Backlight on at maximum brightness, powersave governor ondemand 20.8 wakeups per second, 13.0W Bluetooth and wifi on (via soft killswitch) 175.6 wakeups per second, 15.4W Bluetooth and wifi on, compiz on 240.5 wakeups per second, 15.4W Bluetooth and wifi off, compiz on 94.0 wakeups per second, 13.1W Bluetooth and wifi off, compiz off (once AIGLX is turned on your interrupts will seemingly rise until Xorg is restarted) 80.2 wakeups per second, 13.0W (reboot, default programs running) Brightness 100%, metacity, wifi on, bluetooth on 231.1 wakeups, 15.5W Hardware killswitch on 69.9 wakeups, 13.2W killall thinkpad-keys 51.7 wakeups, 13.0W 55.4 wakeups, 13.1W kill hald-addon-storage 21.4 wakeups, 13.0W (could try killing mixer_applet2 but it doesn't seem worth it) 101.4 wakesups, 13.1W (blinking cursor in vi seems to use up 0.1W) (reboot) hardware killswitch, killall thinkpad-keys, kill hald-addon-storage, disabled laptop-mode 19.0 wakeups, 13.4W Linux power usage on A/C Playing music over DAAP in rhythmbox. 22/23W Windows power usage On the Windows side this laptop came with extra tools that seem to allow more sophisticated battery vs speed trade offs. The initial wattage measurements are those reported by the IBM/Lenovo battery tool and are the lowest seen reading. Idle laptop, default battery settings 9.97W Starting notepad and typing, default battery settings 14.12W Idle laptop, optimal powersave battery settings (this seems to allow the hard disk to still remain constantly spinning but in perhaps in some sort of low power mode) 8.03W Idle laptop, maximum powersave battery settings (this seems to allow the hard disk to still remain constantly spinning but in perhaps in some sort of low power mode) 7.93W Idle laptop, hardware killswitch on, maximum powersave battery settings 7.63W (Strangely, I found that the laptop would emit a whine while it was powersaving on battery while Bluetooth was on) Windows power usage on A/C The following wattage measurements were produced by my wall watt meter. Idle laptop, wireless off, powersave maximum on A/C disk spinning 16-17W Typing in notepad, wireless off, powersave maximum on A/C disk spinning 16-17W Idle laptop, wireless on (connected to AP), powersave maximum on A/C disk spinning 20W Playing music in iTunes via DAAP, wireless on (connected to AP), powersave maximum on A/C disk spinning 20W Idle laptop, wireless on (disconnected from any AP), powersave maximum on A/C 18-19W (It is worth noting that the IBM/Lenovo Windows wireless software tries hard not to remain in scanning mode) Playing a 3D game with sound, wireless state unknown, powersave maximum on A/C 23-25W Conclusions At least on Linux (but I'd imagine these apply to other OSes too) there are some things you should try and do first as these seem to yield the biggest savings. I've ordered them with the items in descending order here: Disabling wifi and Bluetooth - 2.4W! Turning off the backlight - 2.1W. If this isn't happening automatically you might be missing out on a big saving but I've read someone saying that laptop screens can't cope with their backlight constantly being turned on and off so I guess caution is needed. However I've noticed that Apple laptops running OSX seem to dim their screens fairly aggressively... Turning on laptop mode and letting the hard disk spin down - 0.4W. Again I've been told this is dan
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: 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: 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
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
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
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=AttachFile&do=get&target=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
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
(``-_-´´) -- 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
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 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
