parse_oui_database takes in a file path as a &String that is used to open the file in a parsing function. IMO there are a number of problems here.

First, you should almost never take in a &String as a function argument. This basically means you have a reference to a owned object. It forces an allocation of everything passed into the function only to take a reference of it. It excludes types that are simply &strs forcing the caller to convert them to a full String - which involves an allocation. The function should just taking in a &str as it is cheap to convert a String to a &str (cheaper to use than a &String as well as &String have a double redirection).

Sometimes it might be even better might be to take in a impl<AsRef(str)> which means the function can take in anything that can be converted into a &str without the caller needing to do it directly. Though on larger functions like this that might not always be the best idea as it makes it generic and so will be monomorphised for every type you pass into it. This can bloat a binary if you do it on lots of large functions with lots of different input types. You can also get the best of both worlds with a generic wrapper function to a concrete implementation - so the large function has a concrete type &str and a warpper that takes a impl <AsRef<str>> and calls the inner function. Though in this case it is probably easier to just take in a &str and manually convert at all the one call sites.

Second. String/&str are not the write types for paths. Those would be PathBuf and &Path which both work like String and &str (so all the above applies to these as well). These are generally better to use as paths in most OSs dont have to be unicode. Which means there are files (though very rarely) which cannot be represented as a String. This is why File::open takes in a AsRef<Path> which your function can also.

Lastly. I would not conflate opening a file with parsing it. These should be two different functions. This makes the code a bit more flexible - you can get the file to parse from other sources. One big advantage to this would be for testing where you can just have the test data as strings in the test. It also makes the returned error type simpler as one function can deal with io errors and the other with parsing errors. And in this case you can just parse the file directly from the internet request rather than saving it to a file first (though there are other reasons you may or may not want to do this).

You cannot do that analysis with one sample. Why pick one day? That is an arbatary amount? Pick the 1 hour or minute that the CVE was released and you will find rust might be responsible for 100% of CVEs, Take a Week or year and that number drops dramatically. Pick the next day and that drops to 0%. You can select any % you want if you change what time period you are looking at.

The fact that there has been one cve in 5 years of rust in the kernel is a bigger tell. There will be more rust CVEs, and each one is going to be big news as they happen so rarely.

They changed it recently where you can have two members of a family able to play two different games at ones (or rather number of copies of the game at once).

But that requires different accounts even if one account owns all the games.

helps with issues like running out of diskspace

Or causes that problem if you don't manage to predict your usage patterns correctly. I have seen many people run out of space on one or the other but have plenty overall and would not have had a problem with a single partition.

You might want to checkout rust-script which essentially does the same but also lets you use it as a hashbang line to make executable rust scripts. And works with cargo/can install deps.

There is also an RFC for this feature.

I don't mind ads so much. What I don't want in invasive tracking and collection of every scrap of data they can to push ads on you. Give some dumb ads based on the damned contents of the page and I would be fine. But no, ads is basically a synonym for tracking these days.

Plus this applies to your family as well. DNA is shared and by you giving it up you give up info about those related to you as well.

The first actual sentence in the article clears that up.

Schools will be told not to teach children any form of sex education until year 5, when pupils are aged nine, according to reports, with some topics being delayed until pupils are 13.

Though that could have been the title and tagline...

You have failed at capitalism, STRAIGHT TO JAIL!! /s

This one?

Copyright laws and parents IMO do have a purpose and in the current state of the world IMO something like them is needed. But their current implementations last vastly too long and give far too many protections to the owners of them.

Personally I would rather see a world with a UBI and thus no need for artists and inventors to need to profit of their works (without others being able to just steal and profit for them selves). If we had a UBI then IMO we could likely do away with the copyright laws for the most part.

But we don't have that and artists/inventors do need to make a living. So some protections to allow them to do this are currently required. But they have been flipped to give large corporations far too much control and need a big revamp in how they work to rebalance them.

Also, this case does not make AI works uncopyrightable - only those that have no human input. So is not as big a deal as these articles are making it out to be.

I feel like some people made hating system-d a core element of their identity and personality.

Basically this these days. It started out with people not liking change, not liking the author and miss-understanding what systemd is trying to do. Then latching onto some aspects of it and refusing to let go or change their minds at all.

The tragedy of systemd talk goes over a bunch of the common reasons (and counter points) about why people don't like systemd as well as the history of init systems.