Researcher bags two-for-one deal on Linux bugs while probing GNOME component Researchers discovered a high-severity remote code execution (RCE) vulnerability in an inherent component of GNOME-based Linux distros, potentially impacting a huge number of users. Tracked as CVE-2023-43641, exploiting the vulnerability in the relatively small libcue library takes advantage of the tracker-miners application …
"Originally"? I still use locate. In fact, I overheard someone at work talking to someone else about options for running 'find', and I said "Don't forget about locate" and he didn't know what it was. He ran it and said "I'll have to remember that, you can teach an old dog new tricks". He's a few years younger than me, but higher up and quite technical.
I don't even like that (I don't have it installed anywhere, I detest that cron job, especially on servers), I just use the find command. It's not like I haven't got an idea where to start, I generally know the layout of a system.
For Windows, I used to keep a "locate32" (both 32 and 64 bit builds available) on my utilities thumb drive. It used the code from locate and its databases. If I had to search for things, it was worth it to let that thing take a few minutes to update its database on the spot. Because then, I had instant searches showing USEFUL results, like a listing showing the directories my matches are in. I don't work on Windows anymore though.
Mate libcue is a library hosted on GitHub
And who owns GitHub..?
Yes! The very same..
Join the dots. The truth can never stay hidden. This is clearly a false flag op designed to muddy the pristine reputation of Our Lord Linux. In reality just another Microsoft bug. Like always
In the very dim past, before a certain Finnish ever student came across UNIX, I worked for a branch of AT&T that had UNIX running on a pretty large (for the time) Amdahl mainframe (a 5890 model 300E).
The main system (MDF Domain, aka LPAR) regularly had over 200 concurrent users logged in, and even though it was a modern and quite large system, it still was resource-challenged quite frequently.
I was running the UNIX accounting systems, generating the usage graphs on a monthly basis to charge the departments for their usage of the system, and one of the reports broke down the amount of CPU and disk I/O by command. It was clear that once you had removed the build tools and things like emacs (it was a development environment writing telephone exchange software), one of the biggest users of resource, especially disk I/O was the 'find' command. When asking the biggest users how they were using 'find' we discovered that most people were just looking for names files, not using any date or other criteria that find can do.
So we introduced a cron job which ran a find into a flat file located in a common area of disk, and let the users grep this file for the names of files. Because this was a UNIX community through-and-through, the users could use grep proficiently, so this reduced the usage of find hugely, and for a time make the system less busy. This is all that is required. I actually feel that I want to go back to the original BSD source for 'locate' and the underlying collection tool to see whether it is much more than a file-tree-walk. I really can't see why the tool collating the data needs to do anything complicated other than recording the names and paths of files, and sticking it in a simple database.
Huh. In BSD 4.3 Ren locate-updatedb is a script! It runs find!
In this day and age, where UNIX-like systems are mostly single user, this should not really be an issue. Wiith solid-state disk and comparatively huge amounts of CPU and I/O power, the value of this likely to be less needed, so I understand what the purpose of locate is, but I find that if it is open to such issues, it's probably too large and too complicated to be running on a regular bases.
I blame the impatience of modern computer users. They want everything now.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
