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 panic a lot on errors in functions where you return a result. Almost all of these are due to input problems not programming logic errors. These really should be return from the functions as errors so higher up functions can handle them how they might need to rather than just imminently crashing the program. Really panics should only be used when the situation should never occur and if it does that indicates a bug in the program - or you are being lazy with small/test code/one off scripts (but in this case why return any errors at all, you might as well just .unwrap() on everything instead of ?.

This is a pet peeve of mine, but don't put main last. Its like opening a book to be greeted by a random chapter - probably one near the end and you have to hunt through it to find where the story actually starts, which is probably near the end.

This is a IMO horribly hangup from languages that require you to declare something before you can use it. You don't need to do that in rust. So put your functions in order that makes sense to read them from top to bottom. This typically means main should be one of the first functions you see - as it is the entry point to the code. In other files this might be the main functions a user is expected to use first. Sometimes you might want to see some datastructures before that. But overall things should be ordered by how it makes sense to read them to make it easier to make sense of the program.

You are not considered to be working somewhere until you have signed a contract and after the start date on that contract. Accepting a offer is not signing a contract. You are not working at the new place yet. You have no obligations to do anything at that point. You just need to have stopped working at your current employment before your start date. You definitely do not need to quit before accepting the offer. No where I have worked requires that.

You assume they don't already have a job and we're just looking for other opportunities. Not everyone is unemployed before they apply for other jobs. If anything that is a good time to look as it gives you stronger position to negotiate from.

The devs from ΔV: Rings of Saturn give a completely different story. Yeah, most bug reports come from Linux - but platform specific ones a vanishingly rare: https://www.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone - the thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

Not to mention the quality of the reports from the Linux users was vastly more details and useful to them.

They only need it to pass once, we need it to be rejected every single time.

I dont think multiple streaming platforms is a problem. The problem is exclusivity. I dont want to pay for every subscription service to watch popular things. I want to watch any show I want on one platform that I choose. Much like I do for music. But no, with TV shows everyone has their own walled garden of exclusives. Fuck that.

Ads are effective, sadly. And why so much money is poured into them. I believe there are a few effects at play but the direct, see and ad and want to go buy it now is only one ofbhem that mostly only affects some people, or a lot of people occasionally.

I think a bigger effect is familiarity. You are far more likely to pick a product you are familiar with or have seen before over something younjave never heard of. Even if you have only ever seen it on advets and completely forgotten that you have ever seen ads for it. So even if you don't think they work on you they likely do without you realizing, at least enough of the time on enough people that make them worth while running.

Not surprising since car manufacturers lobbied to get them classed as light trucks to dodge the stricter emissions and safety regulations that apply to general cars. Then marketed the hell out of them as there is more profit to be made due to them not needing to comply with as many regulations. And now they are everywhere and are way worst than cars in almost every way.

Funny how yet again the capitalist class chooses profits over any other metric leading to s shittier world overall. Almost like there is a pattern happening in every industry...

Almost like having companies track everything you do is not a good idea and easily raises many false flags that are hard to correct.

This is a bad response to this news. There are many reasons why you might want to run tor on Windows and gatekeeping people out of tor because they are not on a chosen OS is a terribly way to get more people into thinking about privacy and security practices. Yes if you have the highest threat model you might want to avoid Windows as well, but not everyone needs absolute privacy/security for what they do. But why should you not have access to a tool that can help improve things even if you are not able to switch everything to a more private/secure alternative?

Really you should want everyone and anyone to run on tor, even if they don't need it, even if they are on windows. The more people using it the more secure it is for those that do require it.