Re: Low latency kernel in Karmic to help with PulseAudio?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 6 May 2009, I wrote: > For Hardy, this was a significant problem. New versions of ALSA necessary for > improved PulseAudio integration were released immediately after 8.04 > released. And it has happened again - ALSA 1.0.20 was released hours ago. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKAaqye9GwFciKvaMRAmSZAKCNNbckqdKu76FWc31F0GhdYluGugCgipIM bMm7vbwbAtaPzzy0vojMW30= =5+NG -END PGP SIGNATURE- -- 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
9.04, ext4 and the open-write-close-rename debacle
I'm not sure if this is the right forum for this question, but I've been unable to find a definitive answer to this question. Probably everyone is familiar with the lengthy discussion that has revolved around the first stable implementation of ext4, namely that all data in a file can be zeroed out (including the original copy) in the event of a system crash even for the presumably safe open-write-close-rename paradigm; e.g. https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781?comments=all In his blog, Ted Ts'o comments that the 2.6.30 patch for this has been backported by Canonical to 9.04 (I think somewhere in the comments to this entry) http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ Can anyone confirm that if I start formatting file servers with 9.04-based ext4 partitions users won't be faced with losing dozens of recently saved files if the server happens to crash? -- 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
glibc vs. eglibc
Taking a page from Redhat's "let's break it if we can" upgrade policy, Debian appears to be switching from glibc to eglibc: http://www.reddit.com/r/programming/comments/8i8os/debian_is_switching_to_eglibc/ Of great concern is that this library is not guaranteed to be binary compatible with glibc. I'm all for progress, not so much of a fan of pointless changes that lead to regressions and broken code. What are Canonical's plans for 9.10+? Follow Debian into the abyss, hoping for greener pastures in the Great Beyond? Does anyone think maybe it's time to provide some stability for the corporate/institutional IT folks who have stuck their necks out to argue for open source solutions? -- 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: 9.04, ext4 and the open-write-close-rename debacle
On Miércoles 06 Mayo 2009 12:14:47 PM Patrick Goetz wrote: > In his blog, Ted Ts'o comments that the 2.6.30 patch for this has been > backported by Canonical to 9.04 (I think somewhere in the comments to > this entry) > http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero- length-file-problem/ > > Can anyone confirm that if I start formatting file servers with > 9.04-based ext4 partitions users won't be faced with losing dozens of > recently saved files if the server happens to crash? Are you looking for a guarantee that no data loss will happen with ext4? It's still a new filesystem, and no filesystem is 100% safe to begin with... If you're just looking for "yes that patch is applied so the common case is fixed" ...then yeah, you're relatively safe. What I did on my laptop is I put / as ext4 for the fast boot and /home is still ext3 (1. didn't want to go through migration 2. it *is* a new filesystem after all...). The user's data is just as safe or unsafe as before because user's data is still on ext3. A bug *may* crop up that harms the system itself, but a reinstall is nothing compared to user-data-loss. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo signature.asc Description: This is a digitally signed message part. -- 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: glibc vs. eglibc
On Wed, 06 May 2009 11:21:34 -0500 Patrick Goetz wrote: > Taking a page from Redhat's "let's break it if we can" upgrade > policy, Debian appears to be switching from glibc to eglibc: > > http://www.reddit.com/r/programming/comments/8i8os/debian_is_switching_to_eglibc/ > > Of great concern is that this library is not guaranteed to be binary > compatible with glibc. I'm all for progress, not so much of a fan of > pointless changes that lead to regressions and broken code. > > What are Canonical's plans for 9.10+? Follow Debian into the abyss, > hoping for greener pastures in the Great Beyond? Does anyone think > maybe it's time to provide some stability for the > corporate/institutional IT folks who have stuck their necks out to > argue for open source solutions? > > Having seen this: http://blog.aurel32.net/?p=47 , it appears to be an attempt to fix things. Apparently the maintainer of glibc is not cooperative when things do break. Of course, all I am basing this on is the blog entry I read. -- Charlie Kravetz Linux Registered User Number 425914 [http://counter.li.org/] Never let anyone steal your DREAM. [http://keepingdreams.com] -- 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
The creeping religion of click on this
After an ongoing now 2-week long discussion with Canonical support regarding some strange behavior involving the use of the proprietary Broadcom STA driver documented here: http://ubuntuforums.org/showthread.php?t=1134631 it occurred to me that I have no idea what is actually going on when I click on various menu options and GUI applets enabling this or turning off that. This makes it nearly impossible to debug problems like the one described above. Although such system administration applets are obviously needed to make the system usable by ordinary users, it seems clear that by providing only such an interface, Canonical is effectively taking experienced users/administrators like myself out of the debugging loop by creating a huge hurdle between the administrator and the actual kernel modules/configuration files/etc. that are being loaded/manipulated/changed; i.e. I don't have time to forensically determine what is actually going on when I click on those buttons. Perl/Python/shell scripts are self-documenting; GUI applets are not. Solution: Provide a text-based narrative documenting each systems' administration applet which describes exactly what is being done and in what order when the applet is used. I claim that the very requirement for such a narrative will vastly improve the functionality of SA applets, since it will require developers to "think through" the task being addressed. The upfront cost of adding such a feature will be tiny compared to the time saved in debugging/maintaining/upgrading it subsequently, if only because more people will know what is going on and can contribute to improving/fixing it. In the particular example described above, if there were a file(s) which explained what is happening when proprietary drivers are enabled/disabled some user who can't stand this kind of entropy would have tracked down this bug a long time ago and a fix would already be scheduled rather than having it languishing around forever as an annoyance to the experienced and a deal killer for those who are trying Ubuntu for the first time. Precedent: Old timers who have worked with IBM AIX will remember "smitty" or SMIT (System Management Interface Tool), a menu-based SA tool supplied with AIX. One of the selling points of SMIT was the administrator always had access to a screen which showed precisely which commands SMIT was executing to accomplish some task. -- 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: The creeping religion of click on this
On Wed, 2009-05-06 at 12:42 -0500, Patrick Goetz wrote: > After an ongoing now 2-week long discussion with Canonical support > regarding some strange behavior involving the use of the proprietary > Broadcom STA driver documented here: > > http://ubuntuforums.org/showthread.php?t=1134631 > > it occurred to me that I have no idea what is actually going on when I > click on various menu options and GUI applets enabling this or turning > off that. This makes it nearly impossible to debug problems like the > one described above. > > Although such system administration applets are obviously needed to make > the system usable by ordinary users, it seems clear that by providing > only such an interface, Canonical is effectively taking experienced > users/administrators like myself out of the debugging loop by creating a > huge hurdle between the administrator and the actual kernel > modules/configuration files/etc. that are being > loaded/manipulated/changed; i.e. I don't have time to forensically > determine what is actually going on when I click on those buttons. > Perl/Python/shell scripts are self-documenting; GUI applets are not. > > Solution: Provide a text-based narrative documenting each systems' > administration applet which describes exactly what is being done and in > what order when the applet is used. I claim that the very requirement > for such a narrative will vastly improve the functionality of SA > applets, since it will require developers to "think through" the task > being addressed. The upfront cost of adding such a feature will be tiny > compared to the time saved in debugging/maintaining/upgrading it > subsequently, if only because more people will know what is going on and > can contribute to improving/fixing it. In the particular example > described above, if there were a file(s) which explained what is > happening when proprietary drivers are enabled/disabled some user who > can't stand this kind of entropy would have tracked down this bug a long > time ago and a fix would already be scheduled rather than having it > languishing around forever as an annoyance to the experienced and a deal > killer for those who are trying Ubuntu for the first time. > I must say I concur. It would be great to have this info. It can be fairly short and simple, just a paragraph or two but would be a great help. George -- 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
Syslinux HDT
This sounds like something that might be useful for the live-CDs http://syslinux.zytor.com/wiki/index.php/Hdt_(Hardware_Detection_Tool) -- Jan Claeys -- 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
