Re: mlocate - what is it good for?
On Fri, 31 May 2019, Brian Murray wrote: > On Thu, May 23, 2019 at 10:39:29AM -0500, Jamie Strandboge wrote: > > On Wed, 22 May 2019, Seth Arnold wrote: > > > > > Anyway, I believe locate can have great value to all our users, > > > experienced or brand new, huge systems or small systems. I'd like > > > us to keep it in default installs. > > > > > IMO, find has its place and so does mlocate. I still use locate myself > > fairly > > regularly (perhaps a couple/few times a month?) on my laptop and I have been > > known to adjust PRUNEPATHS. As said by another elsewhere, even if it was > > moved > > out of standard we would still want to address the bugs so I'd just assume > > it > > stay in standard. > > I'm not sure I understand the distinction between it staying in standard > versus it being in main but unseeded. The support for the package > doesn't change if it is part of standard as far as I know. Is there > something I'm missing? I was saying that if all we cared about was avoiding the few bug fixes that prompted this, there is no difference and so it should stay. A lot of interesting points have been made since I sent this and it is a difficult decision. I do think a developer will just install it if it is part of her workflow (she will be installing a bunch of other dev tools anyway). That leaves normal server, but considering the impact on cloud and desktop (that now requires tracker), it is hard (for me) to justify it in standard[1]. I would like to see it in main regardless of the decision. [1] I almost suggested a task in the installer, but that seems a bit much for one small package... -- Jamie Strandboge | http://www.canonical.com signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Thu, May 23, 2019 at 03:33:25PM -0700, Steve Langasek wrote: > On Thu, May 23, 2019 at 08:25:20PM +0200, Sebastien Bacher wrote: > > Le 22/05/2019 à 21:47, Julian Andres Klode a écrit : > > > containing about 1435134 files. mlocate foo takes 1s, find / -mount > > > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > > > (but there is a davfs mount of an internet server, so things might be > > > Well here on a few years old 80GB intel ssd doing > > > $ time find / -mount -name disco-desktop-amd64.iso > > > Takes over 30 seconds (on a machine which not doing any other work) > > where mlocate takes around 1 second on the same machine... and I do > > personally find 30 seconds to be too long. > > I agree that 30 seconds is too long, but as a user of find I find this usage > surprising, why would you be searching the whole root disk for the file? I > usually know a file like that is going to be in one of a few subtrees (my > homedir or /tmp or /var/lib/libvirt or something) and would be doing a more > targeted search. > > Also since the locate database is only updated once a day, locate doesn't > help with this if the file I've lost is one I've downloaded today, and it > seems likely to me that files I'm looking for that aren't part of the system > data are fairly likely to fall into this category. > > Anyway, agreed that 30s is too long. Would you be annoyed if the solution > to that 30s being too long was "get tired of waiting, run 'locate', get told > it's not installed, apt install mlocate, run 'locate' again"? Its worth noting that there is a step missing here - you also need to run updatedb after installing mlocate and that isn't obvious. Setting up mlocate (0.26-2ubuntu3.1) ... update-alternatives: using /usr/bin/mlocate to provide /usr/bin/locate (locate) in auto mode (disco-amd64)root@impulse:/tmp# locate ubuntu.py locate: can not stat () `/var/lib/mlocate/mlocate.db': No such file or directory If mlocate were to be removed from the standard installation then we should improve this situation. -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Thu, May 23, 2019 at 10:39:29AM -0500, Jamie Strandboge wrote: > On Wed, 22 May 2019, Seth Arnold wrote: > > > Anyway, I believe locate can have great value to all our users, > > experienced or brand new, huge systems or small systems. I'd like > > us to keep it in default installs. > > > IMO, find has its place and so does mlocate. I still use locate myself fairly > regularly (perhaps a couple/few times a month?) on my laptop and I have been > known to adjust PRUNEPATHS. As said by another elsewhere, even if it was moved > out of standard we would still want to address the bugs so I'd just assume it > stay in standard. I'm not sure I understand the distinction between it staying in standard versus it being in main but unseeded. The support for the package doesn't change if it is part of standard as far as I know. Is there something I'm missing? Thanks! -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Hi all, I am a very inactive member of this list, for years I have been in the "read-only" contingent, but I feel like I should give my impression on this... I think we shoud really distinguish if we are talking about multi-user installs, where there are a number of people logging in and using the command-line, or cloud-server scripted installs, where no more than one user with administrator capabilities is going to use the shell. If it is the former, I think including mlocate in the default install is the sanest decision, lest the weakest link in the chain, the shell user without the power to perform package installs, will be the one harmed. And Canonical can't avoid the effect of "officially de-endorsing" mlocate as a base system utility if they remove it from the default install: many institutions and businesses simply use the default install for their multi-user systems, and if mlocate is not there, it will just become one of thousands of "extra" utilities that the administrator could install or not, i.e., it will not be there if there is not a strong pressure for its use. But of course, this is for multi-user servers. I can't see one such server suffering from the "multiple instances having the file database updated at the same time" because ideally it would not be simply a shared cloud instance. On Tue, May 28, 2019 at 3:58 PM Doug Smythies wrote: > Hi, > > While there are lots of e-mails on this thread, > I decided to reply to this one. > > I use locate several times per day on every linux > computer I use, and I often manually update the database, > including after a new machine startup (VM, for example). > > I consider it to be one of the most useful commands available. > But yes, could install the package myself if I have to. However, > I will forgot this discussion and go through the "Oh ya, I have to > Install it now" moment that someone mentioned. > > On 2019.05.24 12:02 Steve Langasek wrote: > > On Thu, May 23, 2019 at 03:13:49PM -0400, Little Girl wrote: > > Steve Langasek wrote: > > >> I don't think the benefit of having locate available by default > >> justifies the daily disk thrashing / energy usage on every Ubuntu > >> machine everywhere. > > >> Just curious, but how bad (or excessive or whatever) is this disk > >> thrashing / energy usage that you mentioned? > > > It is difficult to answer this in aggregate because the data is hard to > come > > by, and it definitely varies by type of disk and by number of files on > the > > system. You can get a sense of the effect on your own system by running > > e.g. 'sudo iostat /dev/sda 30' in one window and 'sudo > > /etc/cron.daily/mlocate' in another. On my otherwise-idle desktop with > an > > SSD, that only takes 3 seconds to complete and it only reads a few > hundred > > MB of data off the disk (in order to open every directory and stat every > > file). > > > > I only have about 1.5 million files on my disk. > > > > On machines with a lot more files; or machines with spinning disks > instead > > of SSDs; or heavily loaded servers, the impact is bound to be much higher > > that 3 seconds of I/O. > > The "daily disk thrashing" is a very strong function of memory caching. > > Example 1: My main gateway/router/firewall Ubuntu server, with magnetic > disk: > > Number of files: ~ 0.80 million. > Time to update database starting from flushed memory: 10.7 seconds > Time to update database starting from approximately fully cached directory > stuff: 0.5 seconds. > Actual time for the cron daily mlocate task to run last night: 1 second. > Locate time (entire disk): 1.1 seconds > Find time (entire disk): 26.7 seconds > > Example 2: My main Ubuntu test server, with magnetic disk: > Number of files: 4.3 million and 6.3 million, after adding 2 million for > testing. > > Time to update locate database starting from flushed memory: > After adding 2 million files: 12 minutes 45 seconds. > With no/minimal file changes: 10 minutes 50 seconds. > > With no/minimal file changes and lots of cached directory stuff: 4.2 > seconds. > Time to update database starting from lots of cached directory stuff: > After adding 2 million files: fast (did not write it down) > With no/minimal file changes: 4.2 seconds. > Actual time for the cron daily mlocate task to run last night: 6 seconds. > Locate time (entire disk): 2.7 seconds > Find time (entire disk, memory flushed): 17 minutes 42 seconds > Find time (entire disk, lots of cached directory stuff): 14.2 seconds. > > For "energy usage": I think it is minimal and well worth it. > > My main test server processor seems to take about 1 extra watt while > the locate database update task is running. (I do have a good mains > power data logger, but didn't hook it up for this.) So, for > last nights 6 second run time that is 6 Joules of extra processor > power. Guess at 3 times that power back at the mains for 18 Joules. > (even with no caching it's < 2000 Joules for the 11 minutes.) > > ... Doug > > > > -- > ubuntu-
RE: mlocate - what is it good for?
Hi, While there are lots of e-mails on this thread, I decided to reply to this one. I use locate several times per day on every linux computer I use, and I often manually update the database, including after a new machine startup (VM, for example). I consider it to be one of the most useful commands available. But yes, could install the package myself if I have to. However, I will forgot this discussion and go through the "Oh ya, I have to Install it now" moment that someone mentioned. On 2019.05.24 12:02 Steve Langasek wrote: > On Thu, May 23, 2019 at 03:13:49PM -0400, Little Girl wrote: > Steve Langasek wrote: >> I don't think the benefit of having locate available by default >> justifies the daily disk thrashing / energy usage on every Ubuntu >> machine everywhere. >> Just curious, but how bad (or excessive or whatever) is this disk >> thrashing / energy usage that you mentioned? > It is difficult to answer this in aggregate because the data is hard to come > by, and it definitely varies by type of disk and by number of files on the > system. You can get a sense of the effect on your own system by running > e.g. 'sudo iostat /dev/sda 30' in one window and 'sudo > /etc/cron.daily/mlocate' in another. On my otherwise-idle desktop with an > SSD, that only takes 3 seconds to complete and it only reads a few hundred > MB of data off the disk (in order to open every directory and stat every > file). > > I only have about 1.5 million files on my disk. > > On machines with a lot more files; or machines with spinning disks instead > of SSDs; or heavily loaded servers, the impact is bound to be much higher > that 3 seconds of I/O. The "daily disk thrashing" is a very strong function of memory caching. Example 1: My main gateway/router/firewall Ubuntu server, with magnetic disk: Number of files: ~ 0.80 million. Time to update database starting from flushed memory: 10.7 seconds Time to update database starting from approximately fully cached directory stuff: 0.5 seconds. Actual time for the cron daily mlocate task to run last night: 1 second. Locate time (entire disk): 1.1 seconds Find time (entire disk): 26.7 seconds Example 2: My main Ubuntu test server, with magnetic disk: Number of files: 4.3 million and 6.3 million, after adding 2 million for testing. Time to update locate database starting from flushed memory: After adding 2 million files: 12 minutes 45 seconds. With no/minimal file changes: 10 minutes 50 seconds. With no/minimal file changes and lots of cached directory stuff: 4.2 seconds. Time to update database starting from lots of cached directory stuff: After adding 2 million files: fast (did not write it down) With no/minimal file changes: 4.2 seconds. Actual time for the cron daily mlocate task to run last night: 6 seconds. Locate time (entire disk): 2.7 seconds Find time (entire disk, memory flushed): 17 minutes 42 seconds Find time (entire disk, lots of cached directory stuff): 14.2 seconds. For "energy usage": I think it is minimal and well worth it. My main test server processor seems to take about 1 extra watt while the locate database update task is running. (I do have a good mains power data logger, but didn't hook it up for this.) So, for last nights 6 second run time that is 6 Joules of extra processor power. Guess at 3 times that power back at the mains for 18 Joules. (even with no caching it's < 2000 Joules for the 11 minutes.) ... Doug -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On 5/24/19 6:12 PM, Steve Langasek wrote: On Thu, May 23, 2019 at 04:32:24AM +0200, Gunnar Hjalmarsson wrote: On 2019-05-22 20:59, Brian Murray wrote: So we ended up questioning the usefulness of installing mlocate by default on systems at all. We believe that find is an adequate replacement for mlocate but want to hear from you about use cases where it may not be. As a volunteer contributor and involved in support, I tend to use locate() very often, and find() so seldom that I have to look up the syntax everytime. If mlocate would be dropped from default, it would be one of the first package I'd install when doing a fresh install. Suitable to be added to ubuntu-dev-tools? My $.02, I think it's orthogonal to ubuntu-dev-tools and is not used in support of any of the tools in that package, so should not be added there. There's a significant difference between find and locate... used for different purposes. Find will scan the drive on every search, while locate will scan the database, which will bring faster results. The OS would experience a decrease in functionality with the lost of either. -- L. James -- L. D. James lja...@apollo3.com www.apollo3.com/~ljames -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
I have been using mlocate to provide a simple and low traffic search index for users in an NFS home environment. (updatedb run on the file server, but db searchable from clients) However, having it enabled by default also caused trouble earlier e. g. when using automount or non-standard file systems not configured in the stock updatedb.conf. Not sure if my vote counts, but: locate has its use and I would install it on most servers, but having it on by default has bitten me already in the past. Sebastian -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Hey there, Steve Langasek wrote: >Little Girl wrote: >> Just curious, but how bad (or excessive or whatever) is this disk >> thrashing / energy usage that you mentioned? >It is difficult to answer this in aggregate because the data is hard >to come by, and it definitely varies by type of disk and by number >of files on the system. Okay. >You can get a sense of the effect on your own system by running e.g. >'sudo iostat /dev/sda 30' in one window and >'sudo /etc/cron.daily/mlocate' in another. On my otherwise-idle >desktop with an SSD, that only takes 3 seconds to complete and it >only reads a few hundred MB of data off the disk (in order to open >every directory and stat every file). > >I only have about 1.5 million files on my disk. Interesting. >On machines with a lot more files; or machines with spinning disks >instead of SSDs; or heavily loaded servers, the impact is bound to >be much higher that 3 seconds of I/O. That makes sense. >And in a cloud environment running many Ubuntu instances on top of >the same storage set, the fact that this job is kicked off by cron >simultaneously on all instances can have a much more noticeable >impact on server performance. (Indeed, the daily cron jobs causing >noticeable I/O storms is precisely what led us to examine what cron >jobs we have and question their utility.) Thank you for the detailed explanation. Your approach of no longer providing locate by default, but leaving it in the package manager for anyone who might want it, seems like the perfect solution. -- Little Girl There is no spoon. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Thu, May 23, 2019 at 04:32:24AM +0200, Gunnar Hjalmarsson wrote: > On 2019-05-22 20:59, Brian Murray wrote: > > So we ended up questioning the usefulness of installing mlocate by > > default on systems at all. We believe that find is an adequate > > replacement for mlocate but want to hear from you about use cases > > where it may not be. > As a volunteer contributor and involved in support, I tend to use locate() > very often, and find() so seldom that I have to look up the syntax > everytime. If mlocate would be dropped from default, it would be one of the > first package I'd install when doing a fresh install. > Suitable to be added to ubuntu-dev-tools? My $.02, I think it's orthogonal to ubuntu-dev-tools and is not used in support of any of the tools in that package, so should not be added there. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Thu, May 23, 2019 at 03:13:49PM -0400, Little Girl wrote: > Hey there, > Steve Langasek wrote: > >I don't think the benefit of having locate available by default > >justifies the daily disk thrashing / energy usage on every Ubuntu > >machine everywhere. > Just curious, but how bad (or excessive or whatever) is this disk > thrashing / energy usage that you mentioned? It is difficult to answer this in aggregate because the data is hard to come by, and it definitely varies by type of disk and by number of files on the system. You can get a sense of the effect on your own system by running e.g. 'sudo iostat /dev/sda 30' in one window and 'sudo /etc/cron.daily/mlocate' in another. On my otherwise-idle desktop with an SSD, that only takes 3 seconds to complete and it only reads a few hundred MB of data off the disk (in order to open every directory and stat every file). I only have about 1.5 million files on my disk. On machines with a lot more files; or machines with spinning disks instead of SSDs; or heavily loaded servers, the impact is bound to be much higher that 3 seconds of I/O. And in a cloud environment running many Ubuntu instances on top of the same storage set, the fact that this job is kicked off by cron simultaneously on all instances can have a much more noticeable impact on server performance. (Indeed, the daily cron jobs causing noticeable I/O storms is precisely what led us to examine what cron jobs we have and question their utility.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Hey Steve, Le 24/05/2019 à 00:33, Steve Langasek a écrit : >> Takes over 30 seconds (on a machine which not doing any other work) >> where mlocate takes around 1 second on the same machine... and I do >> personally find 30 seconds to be too long. > I agree that 30 seconds is too long, but as a user of find I find this usage > surprising, why would you be searching the whole root disk for the file? I just used the same example than Julian gave so we would compare the same things (but picked a file that I know existed on my disk), I agree that the command/example doesn't make much sense. > Anyway, agreed that 30s is too long. Would you be annoyed if the solution > to that 30s being too long was "get tired of waiting, run 'locate', get told > it's not installed, apt install mlocate, run 'locate' again"? No, I think it would be fine. Locate isn't going to be useful on "throw away" installations/VMs since on a fresh install the index is not going to be there, and if you have an installed machine you use then installing the machine is a one action easy action. > indexers on your desktop system - both tracker and mlocate. It looks like > nautilus currently depends on tracker, so I'm not sure how one would > uninstall it and usefully fall back to the mlocate backend anyway, but at > most I'd say this should be expressed as 'Depends: tracker | mlocate' in > nautilus, and not have mlocate kept around on the system updating its > database daily just in case a user removes tracker. Right, GNOME sort of forced our hands there since several features in nautilus now rely on tracker so yes I agree with you, our default Desktop indexer is tracker and it's probably good enough for most users. Those who need mlocate can go an install it from the archive, we probably don't need it pre-installed on the desktop image. Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Thu, 23 May 2019 at 09:07, Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I think this is a cattle vs pet sort of thing as well: on a system that being used for development or adminned by multiple humans, locate is quite useful. And the overhead of having to install it for systems like this seems acceptable (users like these are exactly the sort of users for whom installing a package is easy!). On systems that are part of a fleet of automatically maintained machines, all locate does is waste IO bandwidth -- which might well be a shared resource if the systems are VMs. My vote would be for removing it from the default install. Cheers, mwh -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Thu, May 23, 2019 at 08:25:20PM +0200, Sebastien Bacher wrote: > Le 22/05/2019 à 21:47, Julian Andres Klode a écrit : > > containing about 1435134 files. mlocate foo takes 1s, find / -mount > > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > > (but there is a davfs mount of an internet server, so things might be > Well here on a few years old 80GB intel ssd doing > $ time find / -mount -name disco-desktop-amd64.iso > Takes over 30 seconds (on a machine which not doing any other work) > where mlocate takes around 1 second on the same machine... and I do > personally find 30 seconds to be too long. I agree that 30 seconds is too long, but as a user of find I find this usage surprising, why would you be searching the whole root disk for the file? I usually know a file like that is going to be in one of a few subtrees (my homedir or /tmp or /var/lib/libvirt or something) and would be doing a more targeted search. Also since the locate database is only updated once a day, locate doesn't help with this if the file I've lost is one I've downloaded today, and it seems likely to me that files I'm looking for that aren't part of the system data are fairly likely to fall into this category. Anyway, agreed that 30s is too long. Would you be annoyed if the solution to that 30s being too long was "get tired of waiting, run 'locate', get told it's not installed, apt install mlocate, run 'locate' again"? > Note that nautilus has a mlocate search provider which we have been > using by default until bionic, to avoid depending on tracker. Now we use > tracker so it's less important but some users do uninstall tracker > because they don't like having an indexer (and it still does have some > bugs) so it's nice to have the UI still responsive for those users. Well, I don't think this is an argument for keeping mlocate installed by default on desktops, because effectively this means that you have TWO indexers on your desktop system - both tracker and mlocate. It looks like nautilus currently depends on tracker, so I'm not sure how one would uninstall it and usefully fall back to the mlocate backend anyway, but at most I'd say this should be expressed as 'Depends: tracker | mlocate' in nautilus, and not have mlocate kept around on the system updating its database daily just in case a user removes tracker. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
I don't know if anyone has said it already but I want to applaud you for asking rather than just doing. From: ubuntu-server on behalf of Steve Langasek Sent: Thursday, May 23, 2019 12:48:35 PM To: jim Cc: ubuntu-ser...@lists.ubuntu.com; ubuntu-devel@lists.ubuntu.com Subject: [EXTERNAL] Re: mlocate - what is it good for? Hi Jim, On Wed, May 22, 2019 at 03:51:14PM -0400, jim wrote: > Seems to me for an individual user such > as I (my laptop runs Ubuntu 18.04), locate > and (the cumbersome) find are sufficient. > To what extent does decision-making balance > net ops and large system administrators as > opposed to individual users? Currently, this is seeded as part of ubuntu-standard, which is common to all Ubuntu flavors. If the discussion led to a determination that this still made sense to include by default on desktops but not servers, or vice versa, we could seed this as part of one Ubuntu flavor or the other. My own sense is that this is not a server vs desktop thing; there are users of locate, to be sure, but I believe they are a very small minority on both desktop and server (small on desktop because the user will generally use the gui instead; small on server because most server use is not interactive at the shell). I don't think the benefit of having locate available by default justifies the daily disk thrashing / energy usage on every Ubuntu machine everywhere. I think it's not onerous for those who want to use locate to manually install it the first time they need it on a machine. But this thread is here to be a sanity check on that opinion, to understand if the locate db being available by default either affects so many users, or has so great an impact on some use cases, that we should consider leaving it enabled by default despite the daily disk usage for everyone not using it. Harriscomputer Leroy Tennison Network Information/Cyber Security Specialist E: le...@datavoiceint.com [cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG] 2220 Bush Dr McKinney, Texas 75070 www.datavoiceint.com<http://www..com> This message has been sent on behalf of a company that is part of the Harris Operating Group of Constellation Software Inc. These companies are listed here<http://subscribe.harriscomputer.com/>. If you prefer not to be contacted by Harris Operating Group please notify us<http://subscribe.harriscomputer.com/>. This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged or confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately by e-mail and delete all copies of the message. > On 5/22/19 3:47 PM, Julian Andres Klode wrote: > > On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > > > I use mlocate multiple times a day. > > > Find is way too slow and inconvenient for finding files in a big > > > set of filesystems, compared to properly configuring mlocate. > > Specifically, the filesystem must be huge or on a slow medium. It might make > > sense to move it out of standard and elsewhere, as I don't think it's > > necessarily needed everywhere, such as laptops. > > > > Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, > > containing about 1435134 files. mlocate foo takes 1s, find / -mount > > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > > (but there is a davfs mount of an internet server, so things might be > > screwed up a bit). > > > > 19s to find something is perfectly workable, also you don't usually > > find from /, but you have an idea where things are, so it will be much > > faster. > > > > I think mlocate only really makes sense on data storage servers with > > huge disks, or on machines with HDDs. I therefore do not think the > > overhead of building the index is warranted for most users. It might > > make sense to keep mlocate in always-on tasks, like servers, but get > > rid of it from desktop scenarios. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Le 22/05/2019 à 21:47, Julian Andres Klode a écrit : > containing about 1435134 files. mlocate foo takes 1s, find / -mount > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > (but there is a davfs mount of an internet server, so things might be Well here on a few years old 80GB intel ssd doing $ time find / -mount -name disco-desktop-amd64.iso Takes over 30 seconds (on a machine which not doing any other work) where mlocate takes around 1 second on the same machine... and I do personally find 30 seconds to be too long. Note that nautilus has a mlocate search provider which we have been using by default until bionic, to avoid depending on tracker. Now we use tracker so it's less important but some users do uninstall tracker because they don't like having an indexer (and it still does have some bugs) so it's nice to have the UI still responsive for those users. Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Hi Jim, On Wed, May 22, 2019 at 03:51:14PM -0400, jim wrote: > Seems to me for an individual user such > as I (my laptop runs Ubuntu 18.04), locate > and (the cumbersome) find are sufficient. > To what extent does decision-making balance > net ops and large system administrators as > opposed to individual users? Currently, this is seeded as part of ubuntu-standard, which is common to all Ubuntu flavors. If the discussion led to a determination that this still made sense to include by default on desktops but not servers, or vice versa, we could seed this as part of one Ubuntu flavor or the other. My own sense is that this is not a server vs desktop thing; there are users of locate, to be sure, but I believe they are a very small minority on both desktop and server (small on desktop because the user will generally use the gui instead; small on server because most server use is not interactive at the shell). I don't think the benefit of having locate available by default justifies the daily disk thrashing / energy usage on every Ubuntu machine everywhere. I think it's not onerous for those who want to use locate to manually install it the first time they need it on a machine. But this thread is here to be a sanity check on that opinion, to understand if the locate db being available by default either affects so many users, or has so great an impact on some use cases, that we should consider leaving it enabled by default despite the daily disk usage for everyone not using it. > On 5/22/19 3:47 PM, Julian Andres Klode wrote: > > On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > > > I use mlocate multiple times a day. > > > Find is way too slow and inconvenient for finding files in a big > > > set of filesystems, compared to properly configuring mlocate. > > Specifically, the filesystem must be huge or on a slow medium. It might make > > sense to move it out of standard and elsewhere, as I don't think it's > > necessarily needed everywhere, such as laptops. > > > > Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, > > containing about 1435134 files. mlocate foo takes 1s, find / -mount > > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > > (but there is a davfs mount of an internet server, so things might be > > screwed up a bit). > > > > 19s to find something is perfectly workable, also you don't usually > > find from /, but you have an idea where things are, so it will be much > > faster. > > > > I think mlocate only really makes sense on data storage servers with > > huge disks, or on machines with HDDs. I therefore do not think the > > overhead of building the index is warranted for most users. It might > > make sense to keep mlocate in always-on tasks, like servers, but get > > rid of it from desktop scenarios. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Wed, 22 May 2019, Seth Arnold wrote: > Anyway, I believe locate can have great value to all our users, > experienced or brand new, huge systems or small systems. I'd like > us to keep it in default installs. > IMO, find has its place and so does mlocate. I still use locate myself fairly regularly (perhaps a couple/few times a month?) on my laptop and I have been known to adjust PRUNEPATHS. As said by another elsewhere, even if it was moved out of standard we would still want to address the bugs so I'd just assume it stay in standard. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 11:25:45PM -0700, Bryan Quigley wrote: > The mentioned Debian bug #880507 is one of the advantages of moving from > cron to systemd units -see proposed unit file in [1]. The timers in > systemd are really perfect for this... > > I use locate all the time. I really like how much simpler it is then > find. I don't have to think to usually get what I'm looking for. I'm > going to experiment with using grep /var/lib/dpkg/info/*.list as > the majority of files I run locate for are from packages.. > > From a product perspective it does make sense to remove: > * Desktop has tracker installed by default. The majority of users will > use that instead as it's integrated with the GUI. Did this change? It's not installed by default in bionic; and no meta package depends on it, but it seems to have moved to main in disco. I think both tracker and locate can offer a terrible user experience for a lot of users, due to I/O load after resume/boot; but tracker also has a ton of CPU usage extracting stuff from documents and putting the text into its xapian (?) db. > * The majority of cloud/server deployments aren't interactive these days. > It's a waste there. ack - also, it sucks to have this I/O load once a day. > > They key group I can see wanting it are developers - who can install it. ack -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 09:47:22PM +0200, Julian Andres Klode wrote: > I think mlocate only really makes sense on data storage servers with > huge disks, or on machines with HDDs. I therefore do not think the > overhead of building the index is warranted for most users. It might > make sense to keep mlocate in always-on tasks, like servers, but get > rid of it from desktop scenarios. In my early days of using Linux, I used locate dozens of times a day. I might know the filename but not the pathname, or a part of a filename, etc. "locate XF86Config" was way easier than "find / -name '*XF86Config*' -print". Sure, the find command is simpler today, but it still spews loads of useless error messages unless you also add 2> /dev/null. (And maybe you care about some but not all errors. Unlikely but possible.) Now that I'm far more familiar with where files live I no longer use locate for this purpose. Now I fall firmly in the other camp, where locate is annoyingly slow and I will try my hand at writing a replacement someday: $ time locate thisdoesntexist real1m29.294s user1m27.649s sys 0m1.644s Anyway, I believe locate can have great value to all our users, experienced or brand new, huge systems or small systems. I'd like us to keep it in default installs. Thanks signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
The mentioned Debian bug #880507 is one of the advantages of moving from cron to systemd units -see proposed unit file in [1]. The timers in systemd are really perfect for this... I use locate all the time. I really like how much simpler it is then find. I don't have to think to usually get what I'm looking for. I'm going to experiment with using grep /var/lib/dpkg/info/*.list as the majority of files I run locate for are from packages.. >From a product perspective it does make sense to remove: * Desktop has tracker installed by default. The majority of users will use that instead as it's integrated with the GUI. * The majority of cloud/server deployments aren't interactive these days. It's a waste there. They key group I can see wanting it are developers - who can install it. My 2 cents, Bryan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882993 On Wed, May 22, 2019 at 7:09 PM Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I'll start > with a personal example: > > "I don't remember (because I need to know so infrequently) where the > meta-release file is cached on disk by update-manager and use locate to > find it. The find command itself is inadequate because the cached file > exists in both /home and /var." > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > [2] http://launchpad.net/bugs/827841 > [3] http://launchpad.net/bugs/1823518 > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On 2019-05-22 20:59, Brian Murray wrote: So we ended up questioning the usefulness of installing mlocate by default on systems at all. We believe that find is an adequate replacement for mlocate but want to hear from you about use cases where it may not be. As a volunteer contributor and involved in support, I tend to use locate() very often, and find() so seldom that I have to look up the syntax everytime. If mlocate would be dropped from default, it would be one of the first package I'd install when doing a fresh install. Suitable to be added to ubuntu-dev-tools? -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
I not search things all the time, but when I do I use find-pipe-grep. Not because "locate" is an inferior solution, not at all, just a matter of habit. On Wed, May 22, 2019 at 5:09 PM Andrea Corbellini < corbellini.and...@gmail.com> wrote: > On Wed, May 22, 2019 at 8:47 PM Julian Andres Klode < > julian.kl...@canonical.com> wrote: > >> On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: >> > I use mlocate multiple times a day. >> > Find is way too slow and inconvenient for finding files in a big >> > set of filesystems, compared to properly configuring mlocate. >> >> Specifically, the filesystem must be huge or on a slow medium. It might >> make >> sense to move it out of standard and elsewhere, as I don't think it's >> necessarily needed everywhere, such as laptops. >> > > There's also the case of a blazing-fast medium, but high I/O load. > That's the case that I'm often facing when working on production servers. > Using find there is very frustrating. > > Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, >> containing about 1435134 files. mlocate foo takes 1s, find / -mount >> -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points >> (but there is a davfs mount of an internet server, so things might be >> screwed up a bit). >> >> 19s to find something is perfectly workable, also you don't usually >> find from /, but you have an idea where things are, so it will be much >> faster. >> > > 19s for my standards are a lot, especially if I have to do multiple > searches. > There have been cases where I dumped the output of "find /" into a file > and resorted to search using grep. > > >> >> I think mlocate only really makes sense on data storage servers with >> huge disks, or on machines with HDDs. I therefore do not think the >> overhead of building the index is warranted for most users. It might >> make sense to keep mlocate in always-on tasks, like servers, but get >> rid of it from desktop scenarios. >> -- >> debian developer - deb.li/jak | jak-linux.org - free software dev >> ubuntu core developer i speak de, en >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Marcos H. Alano Linux System Administrator marcoshal...@gmail.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Hi Neal, On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > I use mlocate multiple times a day. > Find is way too slow and inconvenient for finding files in a big > set of filesystems, compared to properly configuring mlocate. Does "properly configuring mlocate" mean you are using something other than the default, generic config? If you are already configuring the mlocate package on your systems, it doesn't seem onerous to also have to install the package because it's not installed by default; do you agree? > It also seems that the bugs should be addressed (and have in some > cases been addressed) whether or not find is installed by default. > > Thanks, > > Neal McBurnett http://neal.mcburnett.org/ > > On Wed, May 22, 2019 at 11:59:57AM -0700, Brian Murray wrote: > > The Ubuntu Foundations team was recently looking at an issue with > > mlocate[1] and the effect it has on all users of Ubuntu. While that > > specific issue is fixable there are also issues[2,3] with keeping > > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > > questioning the usefulness of installing mlocate by default on systems > > at all. We believe that find is an adequate replacement for mlocate but > > want to hear from you about use cases where it may not be. I'll start > > with a personal example: > > > > "I don't remember (because I need to know so infrequently) where the > > meta-release file is cached on disk by update-manager and use locate to > > find it. The find command itself is inadequate because the cached file > > exists in both /home and /var." > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > > [2] http://launchpad.net/bugs/827841 > > [3] http://launchpad.net/bugs/1823518 > > > > Thanks, > > -- > > Brian Murray -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 8:47 PM Julian Andres Klode < julian.kl...@canonical.com> wrote: > On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > > I use mlocate multiple times a day. > > Find is way too slow and inconvenient for finding files in a big > > set of filesystems, compared to properly configuring mlocate. > > Specifically, the filesystem must be huge or on a slow medium. It might > make > sense to move it out of standard and elsewhere, as I don't think it's > necessarily needed everywhere, such as laptops. > There's also the case of a blazing-fast medium, but high I/O load. That's the case that I'm often facing when working on production servers. Using find there is very frustrating. Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, > containing about 1435134 files. mlocate foo takes 1s, find / -mount > -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points > (but there is a davfs mount of an internet server, so things might be > screwed up a bit). > > 19s to find something is perfectly workable, also you don't usually > find from /, but you have an idea where things are, so it will be much > faster. > 19s for my standards are a lot, especially if I have to do multiple searches. There have been cases where I dumped the output of "find /" into a file and resorted to search using grep. > > I think mlocate only really makes sense on data storage servers with > huge disks, or on machines with HDDs. I therefore do not think the > overhead of building the index is warranted for most users. It might > make sense to keep mlocate in always-on tasks, like servers, but get > rid of it from desktop scenarios. > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
On Wed, May 22, 2019 at 01:19:48PM -0600, Neal McBurnett wrote: > I use mlocate multiple times a day. > Find is way too slow and inconvenient for finding files in a big > set of filesystems, compared to properly configuring mlocate. Specifically, the filesystem must be huge or on a slow medium. It might make sense to move it out of standard and elsewhere, as I don't think it's necessarily needed everywhere, such as laptops. Consider my laptop, fairly standard, 512 GB NVME SSD, about 250G allocated, containing about 1435134 files. mlocate foo takes 1s, find / -mount -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points (but there is a davfs mount of an internet server, so things might be screwed up a bit). 19s to find something is perfectly workable, also you don't usually find from /, but you have an idea where things are, so it will be much faster. I think mlocate only really makes sense on data storage servers with huge disks, or on machines with HDDs. I therefore do not think the overhead of building the index is warranted for most users. It might make sense to keep mlocate in always-on tasks, like servers, but get rid of it from desktop scenarios. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
Hi Brian, I personally use 'locate' all the time, and rarely use 'find' if 'locate' is available. The major problem I have with find is that it's slow. Even restricting the search space to a specific directory (as opposed to searching everything under "/") can be slow. For example, searching my home directory takes a while, due to the large number of Python virtual envs that I have. Sometimes searching a specific directory simply does not work with find due to the presence of symlinks. You have to wait for find to complete (which might take a while), realize that maybe symlinks are involved (which is not obvious) and re-run find with -L, hoping it will work. Searching from the root directory "/" with find is not just slow, but also clobbers the terminal with "Permission Denied" or "Operation Not Permitted" errors. You must remember to use 2>/dev/null (hoping that won't hide any useful errors). With locate instead you can search the entire filesystem and get your results in a few milliseconds, without thinking about edge cases. Also, if you want to always exclude certain filesystems or directories, with find you have to play with -prune or -xdev or similar, and repeat the same arguments every time. With locate, you can just edit one configuration file once and you're done. In my locate configuration I exclude things like my LXC/LXD containers: I never want results involving those. Those are the reasons why I wish locate was enabled everywhere, not just Ubuntu :-) Hope this helps! On Wed, May 22, 2019, 20:00 Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I'll start > with a personal example: > > "I don't remember (because I need to know so infrequently) where the > meta-release file is cached on disk by update-manager and use locate to > find it. The find command itself is inadequate because the cached file > exists in both /home and /var." > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > [2] http://launchpad.net/bugs/827841 > [3] http://launchpad.net/bugs/1823518 > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: mlocate - what is it good for?
I use mlocate multiple times a day. Find is way too slow and inconvenient for finding files in a big set of filesystems, compared to properly configuring mlocate. It also seems that the bugs should be addressed (and have in some cases been addressed) whether or not find is installed by default. Thanks, Neal McBurnett http://neal.mcburnett.org/ On Wed, May 22, 2019 at 11:59:57AM -0700, Brian Murray wrote: > The Ubuntu Foundations team was recently looking at an issue with > mlocate[1] and the effect it has on all users of Ubuntu. While that > specific issue is fixable there are also issues[2,3] with keeping > PRUNEFS and PRUNEPATHS current in updatedb.conf. So we ended up > questioning the usefulness of installing mlocate by default on systems > at all. We believe that find is an adequate replacement for mlocate but > want to hear from you about use cases where it may not be. I'll start > with a personal example: > > "I don't remember (because I need to know so infrequently) where the > meta-release file is cached on disk by update-manager and use locate to > find it. The find command itself is inadequate because the cached file > exists in both /home and /var." > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880507 > [2] http://launchpad.net/bugs/827841 > [3] http://launchpad.net/bugs/1823518 > > Thanks, > -- > Brian Murray > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
