fruitcantfly

I guess that the purpose of the one-line summary is to communicate the spirit of the policy. The details that you are asking for, is what constitutes the majority of the the policy document itself. While you could probably summarize the body of the policy in more detail, having multiple lists with different levels of details would likely lead to confusion. So I think that the approach they've taken makes sense

You are not going to accomplish that using a random selection of textbooks. It doesn't even look like there are that many textbooks in these piles. Realistically, you'd probably have better luck asking students taking intro-level courses to donate their old text books, or just pirating the textbooks you need

I'm guessing that the big books are old collections of scientific journals. Depending on the journal, you could have multiple of those tomes per year. These days scientists access journals digitally, so there's little benefit to keeping the physical copies around in most cases

But if that is the reason, then they should label most distros the same way. To give one example, Debian has bundled non-free firmware since Bookworm. It feels very odd for them to single out Mint like this, if that is in fact the reason.

Either way, they need to clearly spell out why they accuse Mint of this

It's appears to be from https://distrowatch.com/dwres.php?resource=major

Linux Mint does not adhere to the principles of software freedom and it does not publish security advisories.

I am, however, unsure why the author claims that mint does not adhere to the "principles of software freedom". Maybe because,

Mint's reputation for ease of use has been further enhanced by the inclusion of proprietary and patent-encumbered multimedia codecs that are often absent from larger distributions due to potential legal threats.

If it is just for your own (offline) reading pleasure, and it is not a too large a number of pages, then SingleFile is an easy way to archive pages in a semi-automated fashion: You can configure it such that it automatically saves every page you visit based on a pattern or just for a tab, so you'll just have to page through the threads to save them

In practice, that would require buy-in from the apartment/house association board, since the average resident would be unlikely to care about whether or not the software was open source or owned by the association. Cost would likely be a more important metric for most members, and here a company that serviced multiple associations would likely have an edge, especially since they could also provide general support to the end-users.

If it did get approved by the associations members, then the board would then likely have to hire a third party do carry out the actual development. If you're (very!) lucky, then one or more members might be willing to do it cheaper than a third party, but that would likely only last for however long they lived in one of the apartments or houses.

I would put this scenario down as possible in theory, but very unlikely to work out in practice. The vast majority of such associations would go with an existing (closed-source) SAS provider, since that would be a lot less work and since it would survive the constant turnover in such an association.

I honestly have an even harder time seeing how it would work out for OSS in general, since most software does not come with an existing organization, nor a community that is as directly invested as residents in an associations. For most projects, the work involved in setting up and managing such an association would greatly exceed the work involved in developing the software itself, which, similarly to the above, most of the users would not be able to contribute to

EDIT: A more plausible scenario for an house/apartment association, would be somebody setting up a company structured as a co-op and then recruiting multiple associations as co-owners/customers. Is that what you had in mind? Though that of course requires that somebody has both the funds and the interest to get it off the ground, which is unlikely to be an existing association

To add to that, in most cases you can't just move to some country and start looking for a job, even if you have money for the expenses:

You typically need to have a job offer before you can get permission to stay long term. Without that, the most you'll be able to get is probably a short-term tourist visa, which typically does not allow you to work in the country. And most places aren't going to hire somebody who isn't legally allowed to work for them. And if you do find somebody who would employ you (legally), while in the country on a tourist visa, then you'd likely have to leave the country to apply for a work visa.

The kind of job that is eligible for a work visa (and residency) also depends on the "prove you wont be a state burden" rules like the ones you mention, which typically means that you have to have the right qualifications. Most people don't. And you need to stay employed long-term, as you will likely be kicked out of the country if you lose your job and can't find something equivalent within a short period of time.

There are of course exceptions to all this, but those are just that: exceptions

Both find and xargs are POSIX commands, so there's something wrong with your OS if you are missing either, and find does not have an equivalent of -P. Granted, -P is an extension, but it is supported by GNU's, OpenBSD's, FreeBSD's, and BusyBox's xargs commands, and probably also by others, so it is reasonable to assume that it is available unless you are targeting some obscure OS

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