Tip: verwijder de gegevensbank voor zoeken

[Pjotr]

Het programma mlocate (of het alternatief locate) werkt periodiek een systeembrede gegevensbank bij voor bestanden en mappen. Zeker op zwakkere apparatuur kan dat prestatieproblemen veroorzaken.

Aangezien die gegevensbank sowieso niet erg nuttig is, kun je mlocate / locate gewoon verwijderen. En wel als volgt:
https://makkelijkelinuxtips.blogspot.com/p/snelheid-mint.html#ID13
(punt 13)

Doe er je voordeel mee!   

[Paul Matthijsse]

Prestatieproblemen? Nooit iets van gemerkt. Locate is een heel handig programmaatje om gauw even een bestandje te lokaliseren. De database van locate vernieuwen doe je met $ upgradedb en dat is binnen enkele seconden gepiept.

Dus ik begrijp niet waarom je voorstelt dit programma te verwijderen. Ik doe het alvast niet, gebruik het geregeld.

En edit: hoezo niet nuttig?

[Pjotr]

De merkbaarheid van prestatieverlies is uiteraard apparatuurafhankelijk. Op snelle moderne bakken maakt het niks uit. Overigens kun  je met find ook vinden wat je zoekt, zonder gegevensbank die dagelijks moet worden bijgewerkt....

[vanadium]

Deze databank wordt bij systeemstart bijgewerkt, is zo oud als de straat en juist ontworpen om zoeken op die trage systemen sneller te maken. Het levert geen voelbaar voordeel op locate te verwijderen. Ook nu nog is het zoeken via locate de snelste manier. De databank wordt nog steeds gebruikt door catfish, Unity Shell (voor wie dat nog gebruikt) en mogelijk andere toepassingen.

Als je niet zoekt via de terminal of catfish niet gebruikt, kan je dit inderdaad wel weghalen zonder gevolg, maar dat kan je met heel wat andere geïnstalleerde services in Ubuntu ook. Op sommig distributies (voormalig Antergos bijvoorbeeld) is het inderdaad niet standaard aanwezig.

[Pjotr]

De databank wordt nog steeds gebruikt door catfish

Catfish werkt ook zonder de gegevensbank van locate / mlocate....

[vanadium]

Zal dan alleen ietsje langzamer resultaten genereren.

[Paul Matthijsse]

Catfish werkt ook zonder de gegevensbank van locate / mlocate....

Weet je dat zeker?
Op https://git.xfce.org/apps/catfish/about/ lees ik:

Dependencies

    Python 2 or 3
    GLib / GObject Python bindings: GdkPixbuf, GLib, GTK 3, Pango, Cairo
    Pexpect
    locate or mlocate

[Pjotr]

Catfish werkt ook zonder de gegevensbank van locate / mlocate....

Weet je dat zeker?
Op https://git.xfce.org/apps/catfish/about/ lees ik:

Dependencies

    Python 2 or 3
    GLib / GObject Python bindings: GdkPixbuf, GLib, GTK 3, Pango, Cairo
    Pexpect
    locate or mlocate

Slechts aangeraden, geen "harde" afhankelijkheid:

[vanadium]

locate "versnelt" Catfish alleen een beetje. Catfish werkt ook zonder locate, maar gaat dan meteen over naar tragere methoden (zelf de schijf afzoeken) voor het vinden van resultaten. Hiervoor gebruikt Catfish niet locate, maar een in python beschikbare zoekfunctie os.walk(). Indien geïnstalleerd, wordt ook Zeitgeist gebruikt.

[Paul Matthijsse]

Volgens mij is dit een broodje 'Much ado about nothing'!

[Pjotr]

Volgens mij is dit een broodje 'Much ado about nothing'!

Sowieso niet "much ado", althans niet van mijn kant. En "nothing": dat hangt van je apparatuur af. Ik herhaal nog maar eens: op snelle moderne bakken maakt het niks uit, maar op oude zwakke machines kun je het wel merken. Zeker als je ook nog eens veel doet met Timeshift.

[vanadium]

Verschil op een oude machine, mischien wel. Doch ook daar niet van die aard om ingrijpend de gebruikerservaring te veranderen. Misschien 2 s langere opstart tijd? Net op die oude machines zal Catfish zoveel sneller resultaten weergeven *met* locate geïnstalleerd. De balans lijkt mij, dat deze ingreep juist de ervaring met oudere machines beduidend zal verslechten voor die gebruikers die graag een bestand openen door het te zoeken in plaats van ernaar toe te navigeren.

[Pjotr]

Verschil op een oude machine, mischien wel. Doch ook daar niet van die aard om ingrijpend de gebruikerservaring te veranderen. Misschien 2 s langere opstart tijd? Net op die oude machines zal Catfish zoveel sneller resultaten weergeven *met* locate geïnstalleerd. De balans lijkt mij, dat deze ingreep juist de ervaring met oudere machines beduidend zal verslechten voor die gebruikers die graag een bestand openen door het te zoeken in plaats van ernaar toe te navigeren.

Nou, hier zorgde het (in combinatie met een overdreven actief ingestelde Timeshift) voor problemen:
https://forums.linuxmint.com/viewtopic.php?f=18&t=296698

[h2o]

Nou, hier zorgde het (in combinatie met een overdreven actief ingestelde Timeshift) voor problemen:
https://forums.linuxmint.com/viewtopic.php?f=18&t=296698

Juist, timeshift, maar dit topic gaat over mlocate en locate. Als Timeshift voor die gebruiker een probleem is, wat dan als locate en mlocate gewoon blijven werken? Dat lees ik in jouw aangehaalde topic van dat andere forum niet.

[Pjotr]

Nou, hier zorgde het (in combinatie met een overdreven actief ingestelde Timeshift) voor problemen:
https://forums.linuxmint.com/viewtopic.php?f=18&t=296698

Juist, timeshift, maar dit topic gaat over mlocate en locate. Als Timeshift voor die gebruiker een probleem is, wat dan als locate en mlocate gewoon blijven werken? Dat lees ik in jouw aangehaalde topic van dat andere forum niet.

Het gaat over mlocate / locate, dat *onder bepaalde omstandigheden* (apparatuur, combinatie met andere programmatuur) voor prestatieverlaging kan zorgen. Terwijl mlocate / locate nou niet bepaald essentieel spul is.

Deze knaap (rene) verwoordt het vrij aardig:
https://forums.linuxmint.com/viewtopic.php?f=18&t=296698#p1651235

[h2o]

Wat zegt die Rene dan eigenlijk?
Even in Google translate:

Als updatedb de boosdoener is, zei de 'onderliggende oorzaak' waarschijnlijk een groot aantal timeshift-back-ups die het doorkruist. En aan de andere kant, heb ik mezelf verteld dat updateb een wandeling gaat maken voor meer dan een enkel decennium, en het zelf noemen ervan "de onderliggende oorzaak" is ook nog steeds goed voor mij. De use-case voor dat ding is me nooit enig zinnig idee geweest; als ik weet wat er wordt genoemd, weet ik of het al is of is het nieuw genoeg zodat het nog niet in de database staat; een simpele vondst helpt in dat geval en ziet af van de noodzaak van dagelijkse rondes van getimede diskshrashing ...

[Paul Matthijsse]

Wat zegt die Rene dan eigenlijk?
Even in Google translate:

Wil je zo vriendelijk zijn dat even te vertalen naar het Nederlands?

[Bloom]

Ja, Google Translate heeft nog héél wat te leren alvorens het een perfecte vertaling kan afleveren.
Engelse tekst:
If updatedb is the culprit then said "underlying cause" is probably a lot of timeshift backups it's trawling through. And then again, having myself told updatedb to go take a hike for more than a single decade by now, calling it itself "the underlying cause" is still fine by me as well. The use-case for that thing has never managed to make any sort of sense to me; if I know what something's called I either know where it is already or it's new enough that it's not yet in the database to start with; a simple find helps in that case and foregoes the need for daily rounds of timed disk thrashing...

Nederlandse vertaling door Yours Truly:
Als updatedb de boosdoener is dan is de zogezegde "onderliggende oorzaak" waarschijnlijk een bende timeshift-backups die het moet doorworstelen. Langs de andere kant heb ik mezelf gedurende meer dan een decade tot nu tot voorgehouden dat updatedb de boom in kan. Dat het zichzelf de "onderliggende oorzaak" noemt is wat mij betreft prima. De gebruiksnoodzaak voor dat ding is me nooit zinvol gebleken; als ik weet hoe iets heet dan weet ik ofwel waar het zich al bevindt of als het nieuw genoeg is zodat het om mee te beginnen nog niet in de database zit, dan helpt een eenvoudige find in dat geval en is er geen noodzaak voor dagelijkse ronden van schijfaframmelingen op vaste tijdstippen...