Here are a few random thoughts based on skimming the source:

• I'd advice againsts using -Weverything. Many of the warnings it enables are not very useful, and you are going to get a lot of them. And if you enable warnings, then fix them, or you'll just miss it when your changes cause new warnings.
• A couple of your check functions may reach the end of the function without returning, if type is not on of the expected values. That is undefined behavior. One simple way to avoid this, is to move the common return out of the ifs.
• That const std::string type argument in the above functions should be enums, since you are just checking againts one of three fixed values ("name", "ext", and "date").
• Speaking of which, I can't think of any situation where you'd want to have an const std::string argument. Either use a const reference (const std::string&) or a string_view (const std::string_view). The latter has the advantage that it doesn't create a new std::string if you call the function with a C-string and it can be sliced cheaply.
• You have const std::string &df = df_str; in a couple of places, where df_str is a std::string passed by value. That is of course utterly pointless, and you should simply change df_str to be passed by const reference or as a string view.
• You define main with an int return type, but use std::exit to exit the function. Those std::exit calls could all be replaced with return, which does the same thing in main.
• Don't do work before you need the results. For example, in check_type you perform two checks (saved as starts_with_dot and has_dash), that are not used if name == "name".
• Nobody who sees a function named check_exists would expect it to create a directory, so it should be renamed to something more descriptive. It is also redundant, since you already check that the directory exists in main.cpp via is_directory, but unlike that check check_exists doesn't actually verify that the path is a directory.
• is_founded is Engrish

The only thing that sucks worse than paying for your search engine, is all the other search engines

ls can be piped safely if you use --zero:

ls --zero *.txt | xargs --null -I {} mv {} /home/user/Documents

While the above is a pretty silly example, one reason why you might want to do this is that xargs has a -P/--max-procs argument, that runs N commands in parallel. So you could do something like the following to gzip four files in parallel:

ls --zero *.txt | xargs --null -n1 -P4 gzip

This is a bit simpler than using the equivalent

find . -maxdepth 1 -name '*.txt' -print0 | xargs --null -n1 -P4 gzip

To share a chat via https://claude.ai/, you first have to click on the "Share" button in the top right corner of the chat window. On mobile you first have to click the ... button in the same location, before that button appears. You then have to click the "Create public link" button. That creates a link to that chat that allows anyone to view it.

However, each chat is identified by an UUID4 in the URL (e.g. https://claude.ai/share/01234567-890a-bcde-f012-34567890abcd)*. That means that the URL cannot be guessed even if you accidentally make a chat public, and search engines cant index it either. For anyone else to actually access the chat, you have share the URL with them.

While it is theoretically possible that somebody went through all those steps purely by accident, it seems is very, very unlikely to me

* Additionally, this public URL is different from the URL you use to access the chat, meaning that sharing your private URL by accident and later creating a shared URL does not allow anyone else to access the chat from the private URL

Even if you somehow didn't realize that search engines would index the stuff you share publicly on the internet, you should realize that if you create a link that gives anyone with that link access to something and share it in public, then you no longer have any control over who has access to whatever you shared.

I would expect that most people do realize this, and that the vast majority of chats that have been indexed do not include anything that the owner considers to be sensitive. But that doesn't make for as exciting an article

The author probably didn't know. I believe that the 1.4 build is only available via the bun self-updater as a "canary" release. It hasn't been officially released yet

It can't be quite that bad; they've been shipping the rust version of Bun with Claude Code since v2.1.181 (released June 18th), and I haven't seen an outcry over all related functionality breaking

Those can all be separate partitions on any Linux system. But defaults matter, and if the defaults are insecure then you can expect most systems to be insecure

XFS is the default filesystem for RHE, and while I believe that /tmp is a tmpfs on RHE and should therefore be safe, it is my understanding that /var/tmp needs to be accessible on boot and is therefore typically on the root FS. EDIT: Can confirm for the RHE server I have access to, that this is the case

Those root privileges being able to edit a root-owned file if it’s in a directory that allows writes by all users. How common is that?

The file doesn't need to be in a world-writable directory, there just needs to be a (world-)writable directory on the same partition, such as /tmp on the root partition. The attacker then uses a XFS specific feature (reflink) to create a clone of the target file (e.g. /etc/passwd) in the writable directory, and then they can modify the content of the target file via their clone due to the race-condition

The advisory has a more detailed description: https://cdn2.qualys.com/advisory/2026/07/22/RefluXFS.txt

Other git hosts are also getting scraped, and have had to implement counters because of it. For example, this is the kind of thing Codeberg shows crawlers. I've even seen people who self-host complaining about getting overloaded because of bots scraping their forge

For me, and a few other projects I checked, it only has non-GPL repos. But it also does not have everything that isn't GPL, despite the repos being much older than the cut-off date. But it does have repos without a license, which they are simply not allowed to copy.

I wonder if those repos have been deduplicated, and one of the forks (on some other person's account) is included instead. Unfortunately you can only search the first 5M records via the website, and I don't have time to play around with the API at the moment, so I could neither confirm nor deny that possibility