Re: regular fsck runs are too disturbing
* [Waldemar Kornewald] Isn't a hardware defect the main reason a file system can be corrupted without a crash? There can be serious FS bugs, but aren't those very rare, anyway? What else could lead to FS corruption? SMART only catches hard drive defects. Some other things that (I think more frequently) can lead to file system corruption, even on a system that seems to be running just fine, are: - Small RAM errors - Overheating components - Overclocked components - Software bugs (kernel/VFS/filesystem driver) - Hardware bugs SMART won't help you there. Only fsck will. Currently, I believe there is a check during boot to see if the system is running on battery power, and if so, delay the fsck for 10 more mounts or until the system is booted with mains power again. Other suggestions have been to have a (kernel?) thread/process in the background constantly checking your filesystem when the system is otherwise idle. The same type of process for background defragging has also been suggested. However, I am not aware of anyone ever implementing a workable prototype of such a system for Linux. Øystein -- Ebg13 arire tbrf bhg bs fglyr.. -- 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: xmms into universe?
* [Jan Claeys] The Gtk1 XMMS has been ported to Gtk2 under the name beep-media-player. Some time ago the beep-media-player people started a new project (BMPx), but the classic BMP was forked to become the Audacious project, which is essentially the latest version of XMMS now. (XMMS en classic BMP aren't supported by their upstreams anymore, but Audacious is.) See: http://audacious.nenolod.net/Main_Page (Audacious is available in Ubuntu 7.04 Feisty.) As for basic functionality (my personal use case), it seems Audacious is a perfectly fine drop-in replacement for xmms. The functionality I use is: * Codecs: mp3, vorbis, flac, musepack. * xmms directory/ playing all music files in the directory in reasonable (alphabetical) order. * Same as above, but xmms -e directory/ for enqueuing. * Song change plugin runs a shell script that updates one of those now playing macros everyone hates. The basic conversion from xmms to audacious seems to have taken me all of 10 minutes, including porting the configuration for the song change plugin and browsing through the preferences dialog. Only problems I've run into so far: * Default skin of audacious is fugly to my eyes (easily fixable) * Need to retrain my fingers to type audacious instead of xmms. I suppose an alias of sorts might be in order, not to mention uninstalling xmms. Conclusion: Pointless post, but popcon --xmms ++audacious. Øystein -- Nobody really reads these signatures anyway. -- 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: ReadyBoost Technology for Ubuntu and Linux
* [Florian Zeitz] Linux has been able to do this for ages, but it has been considered a bad idea, because it wears the memory sticks flash. In theory all it takes is: 1. # mkswap /dev/sdX (where sdX is your memory stick) 2. Edit your fstab to say: /dev/sdX none swap sw,pri=2 0 0 UUID=stuff none swap sw,pri=1 0 0 instead of UUID=stuff none swap sw 0 0 3. # swapon -a Then again, this is nothing at all like ReadyBoost. What ReadyBoost apparently does is to use the flash drive as a secondary disk cache (note: disk cache, not swap) for often read, rarely written data. The point being that while the disk can deliver 50MBps and the flash drive can only deliver maybe 20MBps, you still read a 4k block of data faster from the flash drive because the much lower seek time makes up for the lower sustained data rate. Of course, the most read data will be present in the disk cache in RAM anyway, so ReadyBoost only provides an advantage for not-quite-as-often read data, or maybe during boot. It is also quite clearly more beneficial (except maybe during boot) to add the same amount of RAM instead of ReadyBoost flash drive to your system, but 2GB flash drive is cheaper than 2GB RAM. There's also little reason to think that this needs to wear out the flash drive very quickly. If you store system files (or more correctly, blocks from system files) like the contents of /bin, /lib, /etc, and most of /usr, these are files that hardly ever change (except during dist-upgrade or the occasional security update), but still represent a lot of small reads and would as such benefit from being read from a 1ms seek time flash drive instead of a 10ms seek time hard drive. To answer the original question, I've not heard of anything like ReadyBoost for Linux. Googling for it, I mostly find explanations from people who did not understand ReadyBoost, and present solutions like the one I quoted. Øystein -- Outgoing mail is certified Virus Free. ..of course, the virus would tell you the same thing.. -- 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: we should set a grub password by default
* [Sven] Iam allready averted from the request of setting it by default. My proposal is: Making grub password an optional but easy to configure feature. The setup of the grub password should assist people, inform them about the additional step of bios-boot configuration, inform them about the remaining risk of physical access. I claim bike shed discussion on this thread. That is, lots of discussion about an issue because it's unimportant and easy to understand, so everyone sees a chance to state their opinion with little risk of having to defend a bad decision later. As has been stated in the thread, people who care either way can easily change the default after install. For home users, grub passwords are likely to be confusing, and I'd personally forget it after a while since it's unlikely to be automatically changed when I change the user password. Support for adding grub passwords when scripting the installer for large deployments would be useful. And the bike shed should be red, I think. Goes well with my coat. Øystein -- ssh -c rot13 otherhost -- 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
